Closed mgh128 closed 3 years ago
I've now updated the examples and the EPCIS @context file. It looks as though the JSON Schema and SHACL file don't need updating - but I'll test this.
Hi @mgh128, One more observation regarding id. Is it good idea to keep id field at epcisDocument level? I believe it should rather be generated by repository.
It is needed as an alias to @id so that the JSON-LD works correctly - it indicates that its value (a URI or blank node) is the RDF Subject whose value is of type epcis:EPCISDocument. However, I think you're correct that the value may be set (overwritten) by the repository if supplied as a blank node value.
@dakbhavesh asked about the 'id' fields that appear within the JSON/JSON-LD examples of event data.
'id' now appears within readPoint and bizLocation to distinguish the URI value for readPoint / bizLocation from any other user-defined / vendor-defined extension fields. We are not talking about any change to that.
We are talking about the 'top-level' field within each event shown as 'id'. This should be renamed 'eventID' for consistency with the abstract data model. 'eventID' would be mapped to "@id" within https://gs1.github.io/EPCIS/epcis-context.jsonld because it expects a URI (even in EPCIS v1.2 / CBV v1.2, a UUID value for eventID is expected to be expressed as a UUID URI, e.g.urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ) and because the eventID URI serves as the RDF Subject for the event data. It is the eventID URI that identifies the event and the other fields within the event act as RDF properties/predicates, using the eventID URI as RDF Subject in order to form RDF triples that express the event type, the readPoint for that event, the epcList etc.
@mgh128 to update the examples and the standard EPCIS @context file accordingly.