UCO's OWL syntax review should test cardinality restrictions

Question

UCO's OWL syntax review should test cardinality restrictions

ajnelson-nist opened this issue a year ago · 1 comments

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 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:

ex:Hand
	rdfs:subClassOf
		[
			a owl:Restriction ;
			owl:onProperty ex:digit ;
			owl:cardinality "5"^^xsd:nonNegativeInteger ;
		] ,
		[
			a owl:Restriction ;
			owl:onProperty ex:digit ;
			owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;
			owl:onClass ex:Thumb ;
		] ,
		[
			a owl:Restriction ;
			owl:onProperty ex:digit ;
			owl:qualifiedCardinality "4"^^xsd:nonNegativeInteger ;
			owl:onClass ex:Finger ;
		]
		;
	.

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:

ex:Hand
	rdfs:subClassOf
		[
			a owl:Restriction ;
			owl:onProperty ex:digit ;
			owl:maxCardinality "5"^^xsd:nonNegativeInteger ;
		] ,
		[
			owl:maxQualifiedCardinality "1"^^xsd:nonNegativeInteger ;
		]
		;
	.

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.)

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 (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.

Coordination

Tracking in Jira ticket OC-306

Administrative review completed, proposal announced to Ontology Committees (OCs) on 2024-02-08
Requirements to be discussed in OC meeting, date 2024-02-15
Requirements Review vote occurred, passing, on 2024-02-15
Requirements development phase completed.
Solution announced to OCs on TODO-date
Solutions Approval to be discussed in OC meeting, date TBD
Solutions Approval vote has not occurred

Solutions development phase completed.
Backwards-compatible implementation merged into develop for the next release
develop state with backwards-compatible implementation merged into develop-2.0.0
Backwards-incompatible implementation merged into develop-2.0.0 (or N/A)
Milestone linked
Documentation logged in pending release page
Prerelease publication: CASE develop branch updated to track UCO's updated develop branch
Prerelease publication: CASE develop-2.0.0 branch updated to track UCO's updated develop-2.0.0 branch

Answer 1 · 2024-02-15T20:29:04.000Z

The Requirements Review vote passed this morning. Some testing matters need to resolve before the implementation of this proposal is announced for a vote.