Use cases are starting to appear suggesting restoring some OWL modeling practices around cardinality. For instance, CASE Issue 146 introduces owl:Restrictions to suggest objects should exist, separately from (and complementary to) the SHACL shapes requiring that they must. Another proposal seems to be suggested from CASE 146 on changing part of the implementation of uco-core:ContextualCompilation away from SHACL. Separately, another proposal is coming soon pertaining to a significant revision to Facet specifications, where owl:Restrictions may fulfill a need where SHACL might or might not be appropriate to use.
In support of processing those proposals, UCO should begin testing cardinality syntax.
Requirements
Requirement 1
UCO must maintain its stance of conformance with OWL 2 DL syntax where OWL constructs are used. (Since transitioning to SHACL, nuances around this requirement have mostly been exercised in custom datatypes in the vocabulary: namespace.)
Requirement 2
UCO must assure conformant usage of OWL cardinality restrictions.
Risk / Benefit analysis
Benefits
These shapes catch syntax issues that might reasonably arise from attempts to transliterate SHACL constraints to OWL restrictions.
Continued review of the effects of OWL's parsing subtractive model are proving beneficial to UCO. (Another proposal is coming soon on an another issue with the vocabulary: namespace.)
These shapes also catch qualified vs. unqualified cardinality specifications.
As a data point / aside, UCO's usage of owl:Restriction in 0.6.0, the last version posted before the transition to SHACL in 0.7.0, had one issue according to these and the other OWL-review shapes, outside of the issues in the vocabulary namespace that were addressed near 1.0.0. Some restrictions on observable:addressValue used an unqualified cardinality of exactly-1 on observable:addressValue, but specified a data range as is only done on qualified cardinalities. See e.g. observable:DigitalAddressFacet. This restriction issue occurred four times total.
Risks
Further development of OWL review shapes risks identifying issues in other ontologies as they are reviewed for potential adoption by UCO. However, the shapes were initially developed to assist with confirming adoption of some ontology would not induce syntax or consistency issues when loading the transitive import closure. Hence, overall, there is no change in risk from adoption of this proposal.
This proposal limits its implementation to the subjects of OWL cardinality predicates (especially using sh:targetSubjectsOf). Deeper review of the predicates' objects seems to present unrelated challenges, left out of scope.
The naming style of some of the shapes in the proposed implementation uses elements of the OWL structural specification, such as ObjectMinCardinality. This saves on name invention, but might be confusing to those looking for sh-owl: IRIs that repeat owl: IRIs.
Competencies demonstrated
Competency 1
OWL and SHACL have different ways of specifying expectations about counts of properties. For instance, take the SHACL specification's example for a shape validating usage of a class called "hand" (from Section 4.7.3):
ex:HandShape
a sh:NodeShape ;
sh:targetClass ex:Hand ;
sh:property [
sh:path ex:digit ;
sh:minCount 5 ;
sh:maxCount 5 ;
] ;
sh:property [
sh:path ex:digit ;
sh:qualifiedValueShape [ sh:class ex:Thumb ] ;
sh:qualifiedMinCount 1 ;
sh:qualifiedMaxCount 1 ;
] ;
sh:property [
sh:path ex:digit ;
sh:qualifiedValueShape [ sh:class ex:Finger ] ;
sh:qualifiedMinCount 4 ;
sh:qualifiedMaxCount 4 ;
] .
# Note: sh:qualifiedValueShapesDisjoint was trimmed to focus discussion.
# Note: ex:digit shape set to exactly 5, also for this discussion.
This shape sets up rules around classes ex:Hand, ex:Digit, ex:Thumb, and ex:Finger. The brief hierarchy for those is (guessing the spelling with OWL):
ex:Hand
a owl:Class ;
.
ex:Digit
a owl:Class ;
.
ex:Thumb
a owl:Class ;
rdfs:subClassOf ex:Digit ;
.
ex:Finger
a owl:Class ;
rdfs:subClassOf ex:Digit ;
.
ex:digit
a owl:Class ;
rdfs:domain ex:Hand ;
rdfs:range ex:Digit ;
.
OWL has its own way of specifying specialized behaviors for the property ex:digit, which differs in semantics and syntax. (The semantics, on OWL being open-world and SHACL closed-world, and impacts on inference, are not planned to be discussed in this proposal focused on syntax-checking.) This supplementary OWL graph describes the gist of the SHACL shapes, that a hand in this (simplified) worldview has exactly five digits, exactly 1 thumb, exactly 4 fingers:
The translation in the min-and-max-being-equal case is straightforward: sh:minCount and sh:maxCount reduce to exactly owl:cardinality.
Competency Question 1.1
Is this a correct spelling in OWL?
ex:Hand
rdfs:subClassOf
[
a owl:Restriction ;
owl:onProperty ex:digit ;
owl:cardinality "5"^^xsd:nonNegativeInteger ;
] ,
[
a owl:Restriction ;
owl:onProperty ex:digit ;
owl:onClass ex:Thumb ;
# **Example focus: These next two lines.**
owl:maxQualifiedCardinality "1"^^xsd:nonNegativeInteger ;
owl:minQualifiedCardinality "1"^^xsd:nonNegativeInteger ;
]
;
.
Result 1.1
No. Both of those cardinality predicates cannot appear in the same owl:Restriction.
The reason for that spelling restriction is in the "consumptive" nature of the parsing process in the OWL 2 Mapping to RDF specification. Namely, that owl:Restriction with the multiple cardinality predicates is consumed to match either the ObjectMinCardinality OWL construct, or the ObjectMaxCardinality construct (see Table 13), depending on whichever of the two the parser happens to have picked first; and the matched set of triples is then subtracted from the graph. So, assuming ObjectMinCardinality is matched first, this is left in the graph:
The isolated triple containing owl:maxQualifiedCardinality can't match any other parser rules by itself. This causes the parsing process to fail, because the OWL reserved vocabulary IRIs need to be consumed entirely by strict matches according to that document. (From testing with another tool, the specific parsing failure appears to be the unconsumed triple being treated as an annotation, with the annotation predicate being a member of the reserved vocabulary. Re-definition of reserved vocabulary IRIs is disallowed in OWL 2 DL.)
One shape entailed from development starts on generically capping counts of predicates usable in owl:Restriction (in uco-owl:Restriction-shape). One thing this prevents is another potential from-SHACL translation error: A SHACL shape can have two sh:class usages (inducing an "intersection" test), but an owl:Restriction can't have two owl:onClass usages, for the same consumptive explanation given in Result 1.1.
Background
Use cases are starting to appear suggesting restoring some OWL modeling practices around cardinality. For instance, CASE Issue 146 introduces
owl:Restrictions to suggest objects should exist, separately from (and complementary to) the SHACL shapes requiring that they must. Another proposal seems to be suggested from CASE 146 on changing part of the implementation ofuco-core:ContextualCompilationaway from SHACL. Separately, another proposal is coming soon pertaining to a significant revision toFacetspecifications, whereowl:Restrictions may fulfill a need where SHACL might or might not be appropriate to use.In support of processing those proposals, UCO should begin testing cardinality syntax.
Requirements
Requirement 1
UCO must maintain its stance of conformance with OWL 2 DL syntax where OWL constructs are used. (Since transitioning to SHACL, nuances around this requirement have mostly been exercised in custom datatypes in the
vocabulary:namespace.)Requirement 2
UCO must assure conformant usage of OWL cardinality restrictions.
Risk / Benefit analysis
Benefits
vocabulary:namespace.)As a data point / aside, UCO's usage of
owl:Restrictionin 0.6.0, the last version posted before the transition to SHACL in 0.7.0, had one issue according to these and the other OWL-review shapes, outside of the issues in the vocabulary namespace that were addressed near 1.0.0. Some restrictions onobservable:addressValueused an unqualified cardinality of exactly-1 onobservable:addressValue, but specified a data range as is only done on qualified cardinalities. See e.g.observable:DigitalAddressFacet. This restriction issue occurred four times total.Risks
sh:targetSubjectsOf). Deeper review of the predicates' objects seems to present unrelated challenges, left out of scope.ObjectMinCardinality. This saves on name invention, but might be confusing to those looking forsh-owl:IRIs that repeatowl:IRIs.Competencies demonstrated
Competency 1
OWL and SHACL have different ways of specifying expectations about counts of properties. For instance, take the SHACL specification's example for a shape validating usage of a class called "hand" (from Section 4.7.3):
This shape sets up rules around classes
ex:Hand,ex:Digit,ex:Thumb, andex:Finger. The brief hierarchy for those is (guessing the spelling with OWL):OWL has its own way of specifying specialized behaviors for the property
ex:digit, which differs in semantics and syntax. (The semantics, on OWL being open-world and SHACL closed-world, and impacts on inference, are not planned to be discussed in this proposal focused on syntax-checking.) This supplementary OWL graph describes the gist of the SHACL shapes, that a hand in this (simplified) worldview has exactly five digits, exactly 1 thumb, exactly 4 fingers:The translation in the min-and-max-being-equal case is straightforward:
sh:minCountandsh:maxCountreduce to exactlyowl:cardinality.Competency Question 1.1
Is this a correct spelling in OWL?
Result 1.1
No. Both of those cardinality predicates cannot appear in the same
owl:Restriction.The reason for that spelling restriction is in the "consumptive" nature of the parsing process in the OWL 2 Mapping to RDF specification. Namely, that
owl:Restrictionwith the multiple cardinality predicates is consumed to match either theObjectMinCardinalityOWL construct, or theObjectMaxCardinalityconstruct (see Table 13), depending on whichever of the two the parser happens to have picked first; and the matched set of triples is then subtracted from the graph. So, assumingObjectMinCardinalityis matched first, this is left in the graph:The isolated triple containing
owl:maxQualifiedCardinalitycan't match any other parser rules by itself. This causes the parsing process to fail, because the OWL reserved vocabulary IRIs need to be consumed entirely by strict matches according to that document. (From testing with another tool, the specific parsing failure appears to be the unconsumed triple being treated as an annotation, with the annotation predicate being a member of the reserved vocabulary. Re-definition of reserved vocabulary IRIs is disallowed in OWL 2 DL.)Solution suggestion
See the linked Pull Request 592 for the implementation.
One shape entailed from development starts on generically capping counts of predicates usable in
owl:Restriction(inuco-owl:Restriction-shape). One thing this prevents is another potential from-SHACL translation error: A SHACL shape can have twosh:classusages (inducing an "intersection" test), but anowl:Restrictioncan't have twoowl:onClassusages, for the same consumptive explanation given in Result 1.1.Coordination
Coordination