SHACL to use sh:targetObjectsOf (not RDFS reasoning)

[VladimirAlexiev]

Does EPCIS RDF require RDFS reasoning? We should specify that in the "semantics" section.

I tend to say Yes because there are various Json nodes that don't carry isA but having a type on every node is a good practice. The EPCIS ontology has mostly single-class ranges, so rdfs:range reasoning will infer a useful type.

This will keep SHACL attachment consistent and simple.

The one disadvantage is that a few useless anonymous owl:union classes will also be inferred. (TODO: count them)

[VladimirAlexiev]

Two options for the doc:

• "A semantic repository storing EPCIS data should support RDFS reasoning (in particular rdfs:range), because EPCIS SHACL shapes rely on nodes having rdf:type to target them for validation"
• "A semantic repository storing EPCIS data does not need to support any reasoning, because EPCIS SHACL shapes use sh:targetObjectsOf to find nodes for validation, even when they don't have a rdf:type"

[CraigRe]

@VladimirAlexiev will reformulate SHACL to leverage sh:targetObjectsOf (instead of sh:targetClass ) in most situations except for rules applying to specific subclasses of EPCISEvent. @CraigRe might need to add normative sentence to the effect that "EPCIS RDF requires RDFS reasoning", in which case @VladimirAlexiev will add a SMALL explanatory passage and draft 2 options.

[VladimirAlexiev]

1. Current targeting in EPCIS-SHACL.ttl is mostly by class. I marked ??? nodes that may not have that class, and !!! cases where the class is wrong

    14:    sh:targetObjectsOf epcis:eventList;
    35:    sh:targetClass epcis:ObjectEvent ;
    67:    sh:targetClass epcis:AggregationEvent ;
    96:    sh:targetClass epcis:AssociationEvent ;
   127:    sh:targetClass epcis:TransactionEvent ;
   162:    sh:targetClass epcis:TransformationEvent ;
   193:    sh:targetClass epcis:BusinessTransaction ; ???
   201:    sh:targetClass epcis:ErrorDeclaration ;    ???
   213:    sh:targetClass epcis:SourceList ;          !!!
   222:    sh:targetClass epcis:DestinationList ;     !!!
   231:    sh:targetClass epcis:QuantityElement ;     ???
   514:    sh:targetClass epcis:EPCISDocument  ;      ???
   647:    sh:targetClass epcis:SensorMetadata ;      ???
   660:    sh:targetClass epcis:SensorReport ;        ???

2. It has 17 sh:NodeShape but only 14 sh:target. Eg epcis:SensorElementListShape is missing target
3. The UML diagram has 15 nodes, plus 2 missing (Document, DocumentBody), such shapes should be added
4. Messages mentioning xsd:anyURI must be fixed because that's different from sh:IRI (an IRI/URI) sh:nodeKind sh:IRI ; sh:message "readPoint must be an xsd:anyURI"

[VladimirAlexiev]

nodes that may not have that class

Because isA field is optional in these nodes

@CraigRe or @RalphTro or @mgh128 Who can make these fixes?