prop `epcis:id` is superfluous

[VladimirAlexiev]

epcis:id is described at https://ns.mh1.eu/epcis/ as "xsd:anyURI: An identifier that denotes a specific ReadPoint or BizLocation", and then those classes show epcis:id as their sole attribute.

Following existing examples, we'd have to use epcis:id as follows:

# in message:
<ni:///sha-256;00e1e6eba3a7cc6125be4793a631f0af50f8322e0ab5f2c0bab994a11cec1d79?ver=CBV2.0>
        a                          epcis:ObjectEvent ;
        epcis:bizLocation          <urn:epc:id:sgln:0012345.11111.0> ;
        epcis:readPoint            <urn:epc:id:sgln:0012345.11111.400> .

# in master data:
<urn:epc:id:sgln:0012345.11111.0>   a epcis:BizLocation; epcis:id <urn:epc:id:sgln:0012345.11111.0> .
<urn:epc:id:sgln:0012345.11111.400> a epcis:ReadPoint;   epcis:id <urn:epc:id:sgln:0012345.11111.400> .

Now you see that epcis:id is redundant because it's nothing else but the URN of the object. Please delete it.

(Instead, business locations should describe their CBV/master data like name, address, etc)

[mgh128]

From a Linked Data perspective, I agree. However, within the XML data binding we have a field called eventID which was optional in v1.2. The standard also makes reference to the eventID field, particular for handling of error declarations. This is another example where we have a potential conflict between:

1. strict alignment with the XML data binding for nomenclature (i.e. use 'eventID' rather than 'id')
2. simplifying and aligning with JSON idioms (e.g. 'id' rather than 'eventID')
3. deciding which of these to map to @id in JSON-LD

[mgh128]

There's a further complication here, because ReadPoint or BizLocation also permit user-defined / vendor-defined data from other namespaces to be included. In the XML data binding, the <id> child element contains the SGLN URI whereas other child elements from other namespaces express any extension fields.

[VladimirAlexiev]

@mgh128 this issue talks about the RDF prop. It should have no effect on XML and JSON.

Adding extra data to BizLocation or an Object (the thing identified with an EPC) will not be a problem. It will be added against the URI and doesn't require an RDF prop id. We should add examples for both situations if we don't have such (can you add a separate issue?).

eventID is the same situation: it's present in JSON, mapped to @id, but doesn't need an rdf prop (i think the link in ErrorDeclaration is called correctiveEvent)