Open VladimirAlexiev opened 3 years ago
Some more ideas for validating the shapes:
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.
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
@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:
severity Warning
severity Warning
severity Warning
severity Warning
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
epcis:measurementType
-> missing8: Specify small nomenclatures:
(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 ;
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:
NodeKind IRI
epcis:SensorReportComponent_TypeConstraint
sh:path epcis:component ;
sh:datatype xsd:string ;
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:
196 avoid
owl:sameAs
(@mkotoff)decimal, float
278 use
sh:targetObjectsOf
to avoid the need for reasoning (@mkotoff)255 more cross-field validation rules (POSTPONE)