improve SHACL shapes

[VladimirAlexiev]

We haven't looked at SHACL shapes for a while, and I'd guess they can take improvement. (@mgh128 what's your assessment?)

We also must address the following issues:

• avoid using owl:sameAs in SHACL shape  #196 avoid owl:sameAs (@mkotoff)
• decimal, float or double? (Lexical form not valid for datatype XSD decimal) #201 (comment): get rid of decimal, float
• SHACL to use sh:targetObjectsOf (not RDFS reasoning) #278 use sh:targetObjectsOf to avoid the need for reasoning (@mkotoff)
• capture field dependencies; express them in SHACL #255 more cross-field validation rules (POSTPONE)
• basic field validations (Vladimir), following the ontology/UML diagram
  (currently EPCIS-Ontology-20210907.pdf, EPCIS-Ontology-alternativeVersion-2021-09-14rev2.pdf)
  • Eg epcis:EventListShape currently checks only rdf:type (epcis:EventType_Constraint) but should also check:

eventTime : xsd:dateTimeStamp [1]
eventTimeZoneOffset : xsd:string [1]
recordTime : xsd:dateTimeStamp [0..1]
eventID : node constraint (sh:BlankNode or sh:IRI with pattern "ni:"):
  sh:or (
    [sh:nodeKind sh:BlankNode]
    [sh:nodeKind sh:IRI; sh:pattern "ni:///sha-256;.*\\?ver=CBV2\\.0"]
  )
certification : gs1:CertificationInfo

[VladimirAlexiev]

Some more ideas for validating the shapes:

• validate with the SHACL-SHACL shapes: https://www.w3.org/TR/shacl/#shacl-shacl
• visualize with https://shacl-play.sparna.fr/play/draw
• validate each Turtle example with the EPCIS shapes
• make some invalid examples and ensure that the EPCIS shapes catch those errors

[mgh128]

We haven't looked at SHACL shapes for a while, and I'd guess they can take improvement. (@mgh128 what's your assessment?)

We also must address the following issues:

• avoid using owl:sameAs in SHACL shape  #196 avoid owl:sameAs (@mkotoff)

• decimal, float or double? (Lexical form not valid for datatype XSD decimal) #201 (comment): get rid of decimal, float

• SHACL to use sh:targetObjectsOf (not RDFS reasoning) #278 use sh:targetObjectsOf to avoid the need for reasoning (@mkotoff)

• capture field dependencies; express them in SHACL #255 more cross-field validation rules (POSTPONE)

• basic field validations (Vladimir), following the ontology/UML diagram
  (currently EPCIS-Ontology-20210907.pdf, EPCIS-Ontology-alternativeVersion-2021-09-14rev2.pdf)

  • Eg epcis:EventListShape currently checks only rdf:type (epcis:EventType_Constraint) but should also check:

eventTime : xsd:dateTimeStamp [1]
eventTimeZoneOffset : xsd:string [1]
recordTime : xsd:dateTimeStamp [0..1]
eventID : node constraint (sh:BlankNode or sh:IRI with pattern "ni:"):
  sh:or (
    [sh:nodeKind sh:BlankNode]
    [sh:nodeKind sh:IRI; sh:pattern "ni:///sha-256;.*\\?ver=CBV2\\.0"]
  )
certification : gs1:CertificationInfo

According to section 8.9.1 of CBV 2.0 public review draft, we're still permitting the use of UUIDs, so we would need to also permit a third options within the sh:or above to allow:

eventID :
sh:or (
[sh:nodeKind sh:BlankNode]
[sh:nodeKind sh:IRI; sh:pattern "ni:///sha-256;.*\?ver=CBV\d+\.\d+(\.\d+)?"]
[sh:nodeKind sh:IRI; sh:pattern "urn:uuid:[0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-[14][0-9A-Fa-f]{3}-[89ABab][0-9A-Fa-f]{3}-[0-9A-Fa-f]{12}"]
)

I have also generalised the pattern for the value of 'ver' to support forward-compatibility, aligned with what is described in bullet point 22 of section 8.9.2 of CBV 2.0 public review draft.

[mgh128]

https://github.com/gs1/EPCIS/blob/master/Ontology/EPCIS-SHACL.ttl now uses xsd:double for all floating-point values except for the following, for backward-compatibility with v1.2:

epcis:Quantity_TypeConstraint
sh:path epcis:quantity ;
sh:datatype xsd:decimal ;
sh:name "quantity type constraint" ;
sh:message "quantity must be an xsd:decimal"
.

It has also been used to use sh:targetClass sparingly, using sh:targetObjectsOf (and mentioning the property/properties that expect the class), although sh:targetClass is still used for EPCISDocument and the five event types, since there is no appropriate property that could be used with sh:targetObjectsOf (as an alternative for these).

The following checks were already implemented:

eventTime : xsd:dateTimeStamp [1] - see epcis:EventTime_IsMandatory and EventTime_TypeConstraint
eventTimeZoneOffset : xsd:string [1] - see EventTimeZoneOffset_IsMandatory and EventTimeZoneOffset_TypeAndFormat
recordTime : xsd:dateTimeStamp [0..1] - see epcis:RecordTime_TypeConstraint

These are currently checked within each event type - we could move those to being checked within lines 16-18, within the part of epcis:EPCISDocumentShape that validates the values of epcis:eventList

[VladimirAlexiev]

@mgh128 EPCIS-SHACL.ttl requires a serious review against changes to the semantic representation done in the last 6 months (I'm looking at EPCIS-Ontology-20210907-VA-comments-20210921.pdf).

Here are some comments from a brief review (20 minutes):

1: "backward-compatibility with v1.2": that had only a XML representation, so why is such compatibility needed?

2: indentation

epcis:EventID_Constraint
    a sh:NodeShape ;
    sh:message "Must be a blank node or ni or urn URI";
    sh:or (  #### following 3 lines shoul dbe indented
    [ sh:nodeKind sh:BlankNode ]
    [ sh:nodeKind sh:IRI; sh:pattern "^ni:\\/\\/"]
    [ sh:nodeKind sh:IRI; sh:pattern "^urn:uuid:"]
    );

3: syntax check: the last line above should end in ".". Always do riot --validate before committing

4: specific patterns:

• EventID_Constraint checks only the beginning but not the more specific patterns in your comment above
• epcis:bizTransactionType should have pattern "^https://ns.gs1.org/cbv/BTT-" or "^urn:epcglobal:cbv:btt:" with severity Warning
• epcis:bizStep should have pattern "^https://ns.gs1.org/cbv/BizStep-" or "^urn:epcglobal:cbv:bizstep:" with severity Warning
• epcis:disposition, epcis:set, epcis:unset should have pattern "^https://ns.gs1.org/cbv/Disp-" or "^urn:epcglobal:cbv:disp:" with severity Warning
• epcis:component should have pattern "^https://ns.gs1.org/cbv/Comp-" or "^urn:epcglobal:cbv:comp:" with severity Warning
• epcis:measurementType should have pattern "^https://gs1.org/voc/" with severity Error

5: Unnecessary quoting: "^ni:\/\/" better written as "^ni://"

6: EPCISDocumentBody shape needed: This is wrong because there's an intermediate node: EPCISDocument-> epcisBody -> EPCISDocumentBody -> eventList.

epcis:EPCISDocumentShape
    a sh:NodeShape ;
    sh:targetClass epcis:EPCISDocument ;
    sh:property [
        sh:path epcis:eventList ;

7: wrong props

• 290: epcis:BizTransactionType_TypeConstraint sh:path epcis:type ; -> epcis:bizTransactionType
• 297: sh:path epcis:bizTransaction : that's now the URL, not a prop
• 629: epcis:SourceDestType_IsMandatory sh:path epcis:type ; -> epcis:sourceOrDestinationType
• 637: epcis:SourceDest_TypeConstraint sh:path epcis:type ; -> same
• epcis:measurementType -> missing

8: Specify small nomenclatures:

• this below is one of (cbv:SDT-location cbv:SDT-owning_party cbv:SDT-possessing_party) so make a sh:in

epcis:SourceDest_TypeConstraint
    sh:path epcis:type ;
    sh:nodeKind sh:IRI ;

• same for ErrorReason

9: This is wrong because sh:nodeKind is a nomenclature fixed in SHACL, and because we don't expect EPCIS docs to carry the type epcis:ILMD. I think remove this constraint.

epcis:ILMD_TypeConstraint  
    sh:path epcis:ilmd ;
    sh:nodeKind epcis:ILMD ;
    sh:name "ilmd type constraint" ;
    sh:message "ilmd expects an epcis:ILMD class"

10: Object vs Datatype prop:

• this is not string but NodeKind IRI

epcis:SensorReportComponent_TypeConstraint
    sh:path epcis:component ;
    sh:datatype xsd:string ;