search

gs1 / EPCIS

Draft files being shared for EPCIS 2.0 development
Other
20 stars 7 forks source link

bugs caused by new JSONLD context (#275) #307

Closed VladimirAlexiev closed 9 months ago

VladimirAlexiev commented 3 years ago

@jmcanterafonseca-iota I'll report here bugs caused by PR #275 (new JSONLD context) that was accepted yesterday. I hope you can fix them very quickly: this is higher prio than completing the JSON schema task because it blocks downstream tasks (Turtle and Diagrams). cc @CraigRe @mgh128 @mkotoff

Please test your changes:

Bug 1 (fixed)

Tried "make", got error on the first file:

jsonld format -q ../JSON/Example_9.6.1-with-comment.jsonld | cat prefixes.ttl - | riot -syntax ttl -formatted ttl > Example_9.6.1-with-comment.ttl
09:19:15 ERROR riot :: [line: 23, col: 95] Triples not terminated by DOT
make: *** [Makefile:12: Example_9.6.1-with-comment.ttl] Error 1

Tried just the first step:

jsonld format -q ../JSON/Example_9.6.1-with-comment.jsonld 

# these are triples
_:b0 <http://purl.org/dc/terms/created> "2005-07-11T11:30:47.0Z" .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://ns.gs1.org/epcis/EPCISDocument> .
_:b0 <http://www.w3.org/2002/07/owl#versionInfo> "2.0" .
_:b0 <https://ns.gs1.org/epcis/epcisBody> _:b1 .
_:b1 <https://ns.gs1.org/epcis/eventList> _:b2 .
_:b1 <https://ns.gs1.org/epcis/eventList> _:b5 .

# QUADS start here
_:b3 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://ns.gs1.org/epcis/ObjectEvent> _:b2 .
_:b3 <https://ns.gs1.org/epcis/action> "OBSERVE" _:b2 .

Noticed the result first has triples but then QUADS. EPCIS JSON doesn't use any named graphs, so where did this came from?

We have epcis:eventList _:b2, so we should have _:b2 rdf:type epcis:ObjectEvent. Instead, the subject is a new blank node _:b3 whereas _:b2 is relegated to the named graph position (blank-node named graph).

Bug2 (fixed)

Example_9.6.4-TransformationEvent.ttl has

"eventID": "ni:///sha-256;...?ver=CBV2.0"

This results in a blank node with a wrong property and wrong value:

[ rdf:type epcis:TransactionEvent;
  epcis:eventID "ni:///sha-256;e65c3a997e77f34b58306da7a82ab0fc91c7820013287700f0b50345e5795b97?ver=CBV2.0" ;
  ...
]

That should be resolved to the node's URI (not separate property, and URI not string):

<ni:///sha-256;e65c3a997e77f34b58306da7a82ab0fc91c7820013287700f0b50345e5795b97?ver=CBV2.0>
  rdf:type epcis:TransactionEvent;
  ...

Change this in the context

"eventID": {
      "@id": "epcis:eventID"
    },

To this:

"eventID": "@id"

Bug 3 (canceled)

"isA":"EPCISMasterDataDocument" is resolved to a relative URL:

jsonld format -q ../JSON/Example_9.8.1-MasterData.jsonld
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <file://C:/EPCISMasterDataDocument>

The reason is that @vocab was removed, so the context now has only "isA": "@type".

One way to resolve is to add a term shortcut as exists for event types:

 "ObjectEvent": "epcis:ObjectEvent",
 "EPCISMasterDataDocument": "epcis:EPCISMasterDataDocument"

But this also applies to other nodes that are allowed to have isA:

grep -hrF isA  *.jsonld */*.jsonld|sort|uniq

9-Dec-2021: MasterData now is not transmitted in JSON, canceled

Bug 4 (fixed)

Move out EPCIS-JSON-Schema.json, EPCIS-JSON-Schema-single-event.json from JSON to JSON-Schema (I guess that's done in the PR that's still pending)

Bug 5 (fixed)

Wrong prop names. All prop names start with lowercase:

    "sensorReport": {
      "@id": "epcis:SensorReport",
    "sensorMetadata": {
      "@id": "epcis:SensorMetadata",

Bug 5a (fixed)

The terms sensorReport, sensorMetadata are defined twice, both cases carrying nested context: once in sensorElementList and secondly at a higher level.

Don't know whether this will work, but it's certainly confusing (I think prev bug is caused by this confusion). Merge the two definitions.

Bug 5b (fixed)

type is wrong here because the rdf:type of a node is denoted isA:

    "sensorReport": {
      "@context": {
        "type": "@type",

Bug 6 (new) duplication

Unnecessary duplication:

Bug 7 (fixed)

This is wrong:

    "bizTransactionList": {
      "@id": "epcis:bizTransaction",

Should resolve to epcis:bizTransactionList

Bug 8 (new) leak

The BTT enumeration is outside of the bizTransactionType field (it is one level higher):

      "@context": [
        {
          "@protected": true,
          "@version": 1.1,
          "cbv": "https://ns.gs1.org/cbv/",
          "bol": "cbv:BTT-bol",
          "cert": "cbv:BTT-cert",
          ...
        },
        {
          "type": {
            "@id": "epcis:bizTransactionType",
            "@type": "@vocab"
          }

The problem is that these bare word definitions will leak into any custom fields in the enclosing field bizTransactionList. Try https://tinyurl.com/73e7c8wj, which shows 3 problems:

{"@context": [
  "https://gs1.github.io/EPCIS/epcis-context.jsonld",
  {"ex": "https://example.org/ns/"},
  {"ex2": "https://ns.gs1.org/cbv/"},
  {"ex:type": {"@type": "@vocab", "@context": {"@vocab": "ex:"}}}],
"@graph": {
  "https://example.org/event/1": {
    "bizTransactionList": {
      "ex:type": "bol",      // LEAK
      "type":    "ex2:foo",  // INJECT
      "type":    "foo"       // RANDOM
}}}}

Bug 8a (new) leak

Same problem as 8:

    "errorDeclaration": {
      "@context": [
        {
          "@protected": true,
          "@version": 1.1,
          "cbv": "https://ns.gs1.org/cbv/",
          "did_not_occur": "cbv:ER-did_not_occur",
          "incorrect_data": "cbv:ER-incorrect_data"
        },
        {
          "@protected": true,
          "epcis": "https://ns.gs1.org/epcis/",
          "reason": {
            "@id": "epcis:reason",
            "@type": "@vocab"
          },

Bug 8b (new) leak

Same problem as 8 (appears twice):

      "@context": [
        {
          "@protected": true,
          "@version": 1.1,
          "cbv": "https://ns.gs1.org/cbv/",
          "owning_party": "cbv:SDT-owning_party",
          "possessing_party": "cbv:SDT-possessing_party",
          "location": "cbv:SDT-location"
        },
        {
          "type": {
            "@id": "epcis:sourceOrDestinationType",
            "@type": "@vocab"
          }

Bug 9 (fixed)

We don't use xsd:anyURI but real URLs, see #206. So these:

          "bizTransaction": {
            "@id": "epcis:bizTransaction",
            "@type": "xsd:anyURI"
          },
        "uriValue": {
          "@id": "epcis:uriValue",
          "@type": "xsd:anyURI"
        },

Should be changed to "@type":"@id"

Bug 9a (new) @id alias

This is wrong, in particular "@id": "@id" doesn't mean anything.

"bizTransaction": {
            "@id": "@id",
            "@type": "@id"
          },

Change to 

"bizTransaction": "@id"

Bug 10 (fixed)

These terms resolve to wrong prop names (copy-paste error)

        "chemicalSubstance": {
          "@id": "epcis:microorganism",
          "@type": "@id"
        },
        "value": {
          "@id": "epcis:microorganism",
          "@type": "xsd:double"
        },

Bug 11 (fixed)

This doesn't cast eg Temperature into gs1:MT-Temperature but should. I think you need to add "@vocab":"gs1:MT-" but please check.

        "sensorReport": {
          "@context": {
            "@protected": true,
            "type": {
              "@id": "epcis:measurementType",
              "@type": "@vocab"
            }
          }
        },

Bug 12 (fixed)

This doesn't cast eg X to cbv:Comp-X. You also need to declare it to be @id:

        "component": "epcis:component",

Bug 12a (fixed)

epcis-context-simple.jsonld: component now resolves to cbv:Comp- not cbv:COMP- (WithSensorData/SensorDataExample10.ttl)

Bug 13 (fixed)

This lacks a datatype:

    "creationDate": "dcterms:created",

Improvement 14 (fixed)

As per latest decision, these two terms should be mapped to the same RDF prop (allowing reuse of SourceOrDestination nodes).

Change

"source": {
            "@id": "epcis:source",
"destination": {
            "@id": "epcis:destination",

To:

"source": {
            "@id": "epcis:sourceOrDestination",
"destination": {
            "@id": "epcis:sourceOrDestination",

Bug 15 (fixed)

correctiveEventIDs produces string not URI

Bug 16 (canceled)

Example_9.8.1-MasterData.ttl and Example_9.8.1-MasterData-complying-with-schema.ttl produce no useful data:

[ rdf:type           epcis:EPCISDocument ;
  dcterms:created    "2005-07-11T11:30:47.0Z" ;
  owl:versionInfo    "2.0" ;
  epcis:epcisBody    []  ;
  epcis:epcisHeader  [] 
] .

I think the reason is that you removed the @vocab declaration, so vocabularyList and deeper are not resolved.

9-Dec-2021: master data is not carried in JSON

Bug 17 (fixed)

prop epcis:PersistentDisposition is wrong (should start with lowerCase)

Bug 18 (fixed)

Wrong prop (copy-paste error):

    "readPoint": {
      "@id": "epcis:bizLocation",
      "@type": "@id"
    },

As a result, epcis:readPoint is missing in all examples

Bug 19 (fixed)

Wrong prop, should be epcis:bizTransactionList:

    "bizTransactionList": {
      "@id": "epcis:bizTransaction",

Bug 20 (fixed)

This in sensorReport is wrong, should be epcis:measurementType

              "type": {
                "@id": "epcis:type",
                "@type": "@vocab"
              },

Bug 21 (fixed) enumerate barewords

Bug 22 (fixed) missing bizStep and disposition values

@jmcanterafonseca-iota @CraigRe @RalphTro @mgh128 This is clear proof that the "enumerate all barewords" approach is not only unnecessary, but also brittle and error-prone.

Bug 23 (canceled) Missing Class

9-Dec-2021: isA removed from example

Enhancement 24 (new) SBDH

Example_9.6.1-ObjectEvent-with-pseudo-SBDH-headers.ttl is misisng the following fields because they are not in context. Maybe they are unofficial/experimental?

+  epcis:instanceIdentifier  "1234567890" ;
+  epcis:receiver            "urn:epc:id:sgln:5012345.00001.0" ;
+  epcis:sender              "urn:epc:id:sgln:0353579.00001.0"

Bug 25 (fixed) gs1 namespace

ALARM_CONDITION is mapped to <https://ns.gs1.org/voc/ALARM_CONDITION> but the correct namespace doesn't have "ns"

Bug 26 (new) cbvmda namespace

cbvmda: is not defined so it results in URLs like <cbvmda:countryOfExport> (WithFullCombinationOfFields/object_event_all_possible_fields). As decided in discussion about the openepcis tool, we should define that namespace.

VladimirAlexiev commented 3 years ago

hi @jmcanterafonseca-iota can you please address this before tomorrow's meeting?

jmcanterafonseca-iota commented 3 years ago

I will look into this along the week.

On Mon, Jun 28, 2021 at 1:41 PM Vladimir Alexiev @.***> wrote:

hi @jmcanterafonseca-iota https://github.com/jmcanterafonseca-iota can you please address this before tomorrow's meeting?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gs1/EPCIS/issues/307#issuecomment-869612755, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQEZJLX3BXIWBIQZWAAZOFLTVBNV5ANCNFSM47FD4VMA .

-- IOTA Foundation c/o Nextland Strassburgerstraße 55 10405 Berlin, Germany

Board of Directors: Dominik Schiener, Serguei Popov, Navin Ramachandran ID/Foundation No.: 3416/1234/2 (Foundation Register of Berlin)

jmcanterafonseca-iota commented 3 years ago

Proposed fix PR #315

@VladimirAlexiev

VladimirAlexiev commented 3 years ago

@jmcanterafonseca-iota Have you tested?

jmcanterafonseca-iota commented 3 years ago

@jmcanterafonseca-iota Have you tested?

@VladimirAlexiev yes, indeed. I've tested with your makefile and generates all the Turtle. The same with #316

VladimirAlexiev commented 3 years ago

Hi @jmcanterafonseca-iota (cc @CraigRe @mgh128)! I checked the new context and added more bugs in the very first comment.

jmcanterafonseca-iota commented 3 years ago

thank you @VladimirAlexiev for this input.

Some of the bugs had already been spotted and are already solved by #321 I will investigate the other ones and provide a patch.

VladimirAlexiev commented 3 years ago

@jmcanterafonseca-iota commented on some of the bugs in this gdoc and fixed several of the problems. I also replied there (search for "VA"), but I think the discussion should be here.

I'll only comment on Enhancement 14 here #230 cc @mgh128: see https://github.com/gs1/EPCIS/issues/230#issuecomment-857596033

VladimirAlexiev commented 3 years ago

@jmcanterafonseca-iota:

mgh128 commented 3 years ago

Regarding Bug 1, when I paste the contents of https://github.com/gs1/EPCIS/blob/master/JSON/Example_9.6.1-with-comment.jsonld into https://json-ld.org/playground/ I'm still seeing only triples under the N-Quads or Normalized tab, so I'm not sure why the approach with the jsonld / riot tools is producing quads, while JSON-LD playground is producing triples.

VladimirAlexiev commented 3 years ago

@mgh128 as it says Bug 1 (fixed) (13 Jul, https://github.com/gs1/EPCIS/pull/315)

VladimirAlexiev commented 3 years ago

@CraigRe merge #321 so I can retest.

mgh128 commented 3 years ago

Regarding bug 2, we probably still need to carefully think about whether this works acceptably in the case of an error-declaring event that echoes the original event ID. It's probably OK to merge the original event with the near-replica that also includes the ErrorDeclaration - because it is the referenced correctiveEventIDs that point to the correction, so maybe it is OK to set "eventID": "@id" as Vladimir suggests

mgh128 commented 3 years ago

I agree that we need to fix bug 3 so that ObjectEvent, EPCISDocument etc. have their correct absolute URIs. when the context resource is resolved/applied.

mgh128 commented 3 years ago

Re bug 6, I agree with Vladimir that it is better to declare the namespaces for epcis: and cbv: and gs1: once only, at the top.

mgh128 commented 3 years ago

Re bug 8, I agree that there should be consistency. I'm not aware of a good reason for BTT to be handled differently from enumerations for bizStep, disposition, SDT etc.

mgh128 commented 3 years ago

Re bug 9, I think I agree with Vladimir that we should declare "@type":"@id" - not "@type":"xsd:anyURI" See https://www.w3.org/TR/json-ld11/#example-4-context-for-the-sample-document-in-the-previous-section

mgh128 commented 3 years ago

Re bug 12, yes, we still need to submit the work request to add these values for component - but Vladimir is correct that we also need to declare "@type": "@id" anyway, to cast it from a string to a URI. We can make that update already.

mgh128 commented 3 years ago

Re bug 15, we need to declare "@type": "@id" (as in bug 12)

VladimirAlexiev commented 3 years ago

@mgh128 Bug 12: should be @vocab (which is more than @id) because component values are bare strings.

mgh128 commented 3 years ago

@mgh128 Bug 12: should be @vocab (which is more than @id) because component values are bare strings.

In that case, we need to think about whether this also applies to any other fields where we might be recommending use of bare strings from a JSON-only perspective. Not sure I'm seeing the difference between how we handle bare strings for component vs bare strings for bizStep or disposition.

I think we were intending that we'd have a Linked Data code list for the standard values including x, y, z, azimuth, spherical radius, cylindrical radius etc. - with a definition and maybe a link to a diagram.

VladimirAlexiev commented 3 years ago

@mgh128 Look in Jose's context: bizStep, disposition also use @vocab

VladimirAlexiev commented 2 years ago

@mgh128

no difference between how we handle bare strings for component vs bare strings for bizStep or disposition

True: it can be implemented with an enumeration (Jose's approach) or as @vocab (as already implemented in my approach).

we'd have a Linked Data code list for the standard values including x, y, z, azimuth, spherical radius, cylindrical radius etc. - with a definition and maybe a link to a diagram.

Yes, these should be added to CBV: #264.

VladimirAlexiev commented 2 years ago

@mgh128 made Turtle-diff to compare Turtle files from both context approaches

@CraigRe Make a new issue to discuss the diff, the global README explanation of the two "branches", and copy Manu Sporny's advice

@jmcanterafonseca-iota Please look there to find more fixes needed

I made some fixes in my context:

mgh128 commented 2 years ago

Thanks for the feedback re the diffs. I've added the PERL script to the Turtle-diff directory, re-ran it and have committed the updated .diff files with improved formatting options, as you recommended. Not yet made a make file but at least the PERL script is there in the meantime, as well as a log file of allDiffs.txt (just concatenates all of these diffs, indicating the filename before the diff content for each). I've already noted some of the issues and will work with @jmcanterafonseca-iota to fix the remaining changes in his modular JSON-LD context.

VladimirAlexiev commented 2 years ago

@mgh128 See last 2 bugs in the very first comment.

mgh128 commented 2 years ago

@VladimirAlexiev - if you're referring to Bug 23 (new) Missing Class and Bug 25 (new) gs1 namespace I think these have already been corrected by the current file https://github.com/gs1/EPCIS/blob/master/epcis-context.jsonld

Please let me know if you're still seeing a problem with this. If so, you or I can submit a public review comment to ensure that this is corrected.

VladimirAlexiev commented 2 years ago

At some point I'll regen all examples and recheck the diffs.

@jmcanterafonseca-iota and @mgh128 how about Enhancement 24 (new) SBDH? I think these SBDH props are kind of made-up and not really in the EPCIS spec? So that issue is irrelevant?

mgh128 commented 2 years ago

Thanks, @VladimirAlexiev . I think I caught most of the remaining issues when I checked the diffs but it's helpful if you can double-check and let us know if anything is still inconsistent.

Regarding SBDH, those SBDH-like properties are invented by us because there is no formal mapping of SBDH to JSON but some sectors (particularly pharma / healthcare) are either using EPCIS in more of an EDI / messaging approach and/or they need those SBDH fields for an audit trail of the various EPCIS data exchanges - so we need to support this in JSON/JSON-LD to provide them an opportunity to adopt JSON/JSON-LD when they are ready to do so. They are optional fields for most users - but they do need to be present in at least one example and also supported by the validation schema (which might not yet be the case and almost certainly is not yet the case for the SHACL validation), so some validation schema updates may be needed by @jmcanterafonseca-iota (modular JSON Schema) and by @mgh128 (SHACL)

VladimirAlexiev commented 2 years ago

I regenerated Turtle\ Turtle-simple-context\ Turtle-diff\ fully

I now see https://github.com/gs1/EPCIS/pull/346 and I think it'd have most of these fixes. Can you please accept it?

@mgh128 I updated the status of bugs (in the very first comment).

Cheers!

VladimirAlexiev commented 2 years ago

@mgh128 @jmcanterafonseca-iota Just checked: bugs 6, 8,a,b, 9a are still not fixed.

In particular the use of @vocab casts random strings into CBV namespaces:

          "type": {
            "@id": "epcis:bizTransactionType",
            "@type": "@vocab"
          }

NOT using @vocab was cited as the main reason for making epcis-context.jsonld (which is 5.5x more complex than epcis-context-simple.jsonld).

mgh128 commented 2 years ago

@VladimirAlexiev Not sure I can reproduce this error you're still seeing. When I paste the contents of https://github.com/gs1/EPCIS/blob/master/JSON/Example_9.6.1-ObjectEvent.jsonld into https://json-ld.org/playground/ and look at the extracted N-Quads, I see that standard CBV code values for bizTransactionType such as "po" and "desadv" are correctly mapped to https://ns.gs1.org/cbv/BTT-po and https://ns.gs1.org/cbv/BTT-desadv but if I change "desadv" to "desadvice" (i.e. a random string that is not one of the standard CBV code values for BTT), then the resulting quad maps to https://json-ld.org/playground/desadvice (or a URI with whichever base URI is assumed by the tool) - but importantly, it's not casting the 'random string' values into the CBV namespace, as far as I can see.

@jmcanterafonseca-iota - could you please also take a look and see if you can reproduce the problem that @VladimirAlexiev mentions?

VladimirAlexiev commented 2 years ago

@mgh128 Sorry, I should have said "casts strings to random URLs since the @vocab URL is not defined`.

You can see an example of injecting a "random term" to the CBV namespace in Bug 8: ex2:foo is cast to https://ns.gs1.org/cbv/foo

mgh128 commented 2 years ago

@VladimirAlexiev - thanks for the clarification. I did some further tests based on the examples you identified in bug 8, applied within the value of bizTransactionList

"ex:type": "bol" - does not map ex:type to CBV namespace but just as a CURIE but with ex unspecified.  Seems like acceptable behaviour.

"type": "ex2:foo" - does not map ex:type to CBV namespace but just as a CURIE but with ex2 unspecified.  Seems like acceptable behaviour.

"type": "foo" - does not map ex:type to CBV namespace but just as random URL (because base is unspecified).  JSON Schema detects that as a validation error, since epcis:bizTransactionType is required to be a URI or a 'bare word' string if using a standard CBV code value defined for BTT (see definition of bizTransaction-type starting at line 1016 of https://github.com/gs1/EPCIS/blob/master/EPCIS-JSON-Schema.json) SHACL also detects that as a validation error - (see epcis:BizTransactionTypeShape starting at line 613 of https://github.com/gs1/EPCIS/blob/master/Ontology/EPCIS-SHACL.ttl )

If I've still misunderstood or overlooked what you're reporting, could you please attach an example of an event where you're seeing a random term being cast to something in the CBV namespace. Thanks for doing these further checks - I fully agree that it's very important that we fix it if this is still happening - but I'm just not seeing that when using the three examples above and testing in http://json-ld.org/playground/ but maybe I'm not looking in the right place, so seeing your example would really help. Thanks in advance!

VladimirAlexiev commented 2 years ago

Did you try the link cited in "bug 8" https://tinyurl.com/73e7c8wj ?

mgh128 commented 2 years ago

Hi @VladimirAlexiev - thanks for clarifying.

So for the problem illustrated by "ex:type": "bol" are you suggesting that we should move the scoped context with the enumeration for 'bol', 'po' etc. one level deeper, scoped solely within "type" (epcis:bizTransactionType) to avoid this problem, something like this: https://mgh128.github.io/EPCIS/epcis-context-alt.jsonld

Regarding the problem illustrated by "type": "ex2:foo" I can't see a way to prevent that aliasing of the cbv: prefix - at least not in a machine-enforceable way. We could include a normative statement in the draft standard to state that users / implementations SHALL NOT use CURIE prefixes other than "cbv" as an alias of https://ns.gs1.org/cbv/ . Would that address your concern?

Regarding "type": "foo" if we move the protected scoped context that enumerates the expansion of the 'bare word' standard terms so that it is defined for "type" (epcis:bizTransactionType) instead of for bizTransactionList, would this address your concern regarding use of @type: @vocab ? It appears that "type" (epcis:bizTransactionType) is anyway inheriting the @context currently defined for bizTransactionList

At https://mgh128.github.io/EPCIS/epcis-context-alt.jsonld I've done just that and it looks like it still correctly expands the bare word values for the standard BTT code values in CBV.

I'm tagging @jmcanterafonseca-iota so he can take a look and comment if he agrees with moving that protected scoped context as I've done at https://mgh128.github.io/EPCIS/epcis-context-alt.jsonld .

VladimirAlexiev commented 2 years ago

scoped solely within "type" (epcis:bizTransactionType)

Yes.

SHALL NOT use CURIE prefixes other than "cbv"

Doesn't sound reasonable to me. Prefixes are a purely local convention, so it's not up to someone to restrict them. Furthermore, they have a legitimate use for this prop, eg cbvBTT: https://ns.gs1.org/cbv/BTT- and then cbvBTT:myNewDocType

would this address your concern regarding use of @type: @vocab

No. That declaration means "interpret a bare word in that field by prepending @vocab", which however is undefined. @type: @vocab has been called a "bomb" by Manu Sporny and was the main argument against EPCIS-context-simple.jsonld.

My proposal is to replace all @type: @vocab with @type: @id. That will cause "interpret a bare word by prepending @base" and @base is also undefined, but it somehow sounds better to me.

jmcanterafonseca-iota commented 2 years ago

I think the current LD @context works just fine and no need to go back. We discussed this long time ago and @type @id has also its counter-examples and edge cases. However, all the edge cases given here against @type @vocab seem to be opportunistic and unrealistic or even causing the JSON Schema not to validate.

This issue should be closed IMHO.

mgh128 commented 2 years ago

Hi @jmcanterafonseca-iota - did you take a look at https://mgh128.github.io/EPCIS/epcis-context-alt.jsonld i which I've moved the enum for BTT closer to the property? What are your thoughts on that? Do you see a downside of making that change?

I agree that "@type":"@vocab" already is used extensively within the JSON-LD context file at https://www.w3.org/2018/credentials/v1 (referenced within https://www.w3.org/TR/vc-data-model/ in which Manu Sporny is one of the editors and co-authors - which seems highly inconsistent with the claim above (https://github.com/gs1/EPCIS/issues/307#issuecomment-1082690856 ) by @VladimirAlexiev that @msporny discouraged use of "@type" : "@vocab"

@CraigRe and I checked the use of scoped contexts and use of "@type" : "@vocab" with Manu Sporny, Gregg Kellogg, Markus Lanthaler and Pierre-Antoine Champin (as editors / co-authors of the JSON-LD 1.1 technical recommendation) back in September 2021 and also had a call with many of them. They clearly supported the use of protected scoped contexts, as implemented by @jmcanterafonseca-iota . I still have the e-mails.

Markus Lanthaler did warn us that these protected scoped contexts would not work with JSON-LD 1.0 processors, which I think is why we're needing to now use https://zazuko.github.io/shacl-playground/ rather than https://shacl.org/playground/ (which appears to only support JSON-LD 1.0) last time I checked a month or two ago.

What Manu Sporny was discouraging was the use of specifying an overall default vocabulary (using something like "@vocab" : "https://ns.gs1.org/epcis/" ) - exactly the approach taken by @VladimirAlexiev in https://github.com/gs1/EPCIS/blob/master/epcis-context-simple.jsonld but he did support the protected scoped approach as implemented at https://github.com/gs1/EPCIS/blob/master/epcis-context.jsonld by @jmcanterafonseca-iota , aligned with the approach taken in https://www.w3.org/2018/credentials/v1

jmcanterafonseca-iota commented 2 years ago

@mgh128 if by restricting the scope we avoid edge cases I am fine with the approach.

Do you envisage other cases where it could be worth restricting the scope of terms?

mgh128 commented 2 years ago

Yes - it's only to avoid edge cases - so thanks to @VladimirAlexiev for alerting us to those, some of which we can address using this approach.

Looking at JSON Schema to see if there are other situations where the protected scoped contexts with enumerated 'bare word' values could be moved closer to the property that makes use of them. Looks like we could take the same approach to move the enumeration at lines 156-159 (for source destination type) to between lines 170-171 of https://github.com/gs1/EPCIS/blob/master/epcis-context.jsonld - and similarly, for destination list by moving lines 182-185 to between lines 196-197.
Also for reason within errorDeclaration, moving lines 572-574 to between lines 581-582. Also potentially within persistentDisposition, moving lines 208-241 to between lines 249-250 and a copy also between lines 254-255.

I hope that suggestion is clear enough for you to try - but if not, I can prepare an alternative version that we can test.

jmcanterafonseca-iota commented 2 years ago

I can have a look at it, @mgh128

msporny commented 2 years ago

What Manu Sporny was discouraging was the use of specifying an overall default vocabulary (using something like "@vocab" : "https://ns.gs1.org/epcis/" ) but he did support the protected scoped approach as implemented at https://github.com/gs1/EPCIS/blob/master/epcis-context.jsonld by @jmcanterafonseca-iota , aligned with the approach taken in https://www.w3.org/2018/credentials/v1

Yes, exactly. Can confirm. :)

jmcanterafonseca-iota commented 2 years ago

@mgh128 I have provided a tentative PR at #416 .

For persistentDisposition wouldn't it be a better fix if in the JSON Schema we just prohibit additional properties?

mgh128 commented 2 years ago

@jmcanterafonseca-iota - agreed. I can't see any good reason to permit properties other than set and unset within persistentDisposition

jmcanterafonseca-iota commented 2 years ago

persistent disposition fixed at #417

jmcanterafonseca-iota commented 2 years ago

this can be closed

VladimirAlexiev commented 2 years ago

@msporny Can you explain the benefit of using type:vocab rather than type:id in the EPCIS context? Please reply to https://github.com/gs1/EPCIS/commit/aed5c4564fdf3eb6eb8f289df186eaf54c132ed2#commitcomment-57982622.

VladimirAlexiev commented 2 years ago

@mgh128 @jmcanterafonseca-iota I checked the list on top:

mgh128 commented 2 years ago

Hi @VladimirAlexiev,

If you look at a modified version of https://www.w3.org/TR/json-ld11/#example-65-term-expansion-for-values-not-identifiers such as this:

{ "@context": { "@base": "http://example1.com/", "ex": "http://example.com/", "vlad": "https://example3.com/Vladimir", "ex:knows": {"@type": "@vocab"} }, "@id": "ex:fred", "ex:knows": [ "vlad" ] }

you'll see that with "@type":"@vocab" the result is the following RDF triple:

http://example.com/fred http://example.com/knows https://example3.com/Vladimir .

whereas if you change the "@type": "@vocab" to "@type": "@id" in the example above, the RDF triple changes to:

http://example.com/fred http://example.com/knows http://example1.com/vlad .

So, the behaviour with "@type": "@id" is to simply append the string to whatever @base URI stem is specified, whereas the behaviour with "@type": "@id" is to actually use the string-to-URI mappings specified in the context resource.

Translating this to our EPCIS scenario, we want to be able to map "shipping" to cbv:BizStep-shipping ( https://ref.gs1.org/cbv/BizStep-shipping ) while at the same time mapping "in_transit" to cbv:Disp-in_transit ( https://ref.gs1.org/cbv/Disp-in_transit ) so that's why @jmcanterafonseca-iota has carefully used "@type": "@vocab" instead of "@type": "@id" for the expansion of the diverse lists of enumerated bare strings, in which each list generally needs to be appended to a different URI stem.