You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is more of a discussion than an issue, but this was the right place to raise this.
From the V1 credential context, the "id" field in the EPCIS event maps to @id. Also, the eventID field of the EPCISEvent maps to @id. So this serves as both the EPCISEvent.eventID and the credentialSubject.id in the graph data from this event. The document could contain either an EventID or an ID, which would both map to @id and identify the graph node.
I like this mapping because the optional eventID becomes the credential subject (The issuer is making a claim regarding an EPCIS event with a specific ID).
But would this cause trouble for parties processing this in a more traditional JSON way? Should we specify that folks use the eventID name to be consistent with EPCIS processing rather than the id name used in the example above?
The text was updated successfully, but these errors were encountered:
It is more of a discussion than an issue, but this was the right place to raise this.
From the V1 credential context, the "id" field in the EPCIS event maps to @id. Also, the eventID field of the EPCISEvent maps to @id. So this serves as both the EPCISEvent.eventID and the credentialSubject.id in the graph data from this event. The document could contain either an EventID or an ID, which would both map to @id and identify the graph node.
I like this mapping because the optional eventID becomes the credential subject (The issuer is making a claim regarding an EPCIS event with a specific ID).
But would this cause trouble for parties processing this in a more traditional JSON way? Should we specify that folks use the eventID name to be consistent with EPCIS processing rather than the id name used in the example above?
The text was updated successfully, but these errors were encountered: