Disjointedness already denoted in UCO should be enforced

[ajnelson-nist]

Disclaimer

Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose.

Background

UCO Issue 430 introduced core:UcoInherentCharacterizationThing, a top-level abstract class to denote some classes within UCO as disjoint with core:UcoObject. For instance, no object should be both a observable:File and observable:FileFacet. Introducing that class was the first use of OWL disjointedness in UCO. A few other uses of disjointedness are in UCO as well, found by scanning the ontology directory tree for the word "disjoint":

• Some of the OWL structural specification classes are disjoint, per the OWL specification. They are all currently checked by UCO, so no change is needed here.
  • The three OWL property classes used to define ontologies (ObjectProperty, DatatypeProperty, and AnnotationProperty) are disjoint. This is enforced with the shapes uco-owl:Disjointedness-AP-DP-shape, uco-owl:Disjointedness-AP-OP-shape, and uco-owl:Disjointedness-DP-OP-shape.
  • OWL classes and datatypes are disjoint, inherited from the OWL specification. This is enforced with the shape uco-owl:Disjointedness-C-DT-shape.
  • OWL classes and any of the property classes are NOT disjoint in OWL 2 DL. And likewise with datatypes and any of the property classes.
    • This was a surprise, but on review of the Punning documentation in the OWL 2 features document, and on testing with ROBOT 1.9.5, it is indeed conformant to OWL 2 (in the "default" profile, DL) to define a single IRI as a class and object property, and datatype and datatype property, etc. The EL, QL, and RL OWL 2 profiles each seem to disallow this through more limited grammars. A Gist will be linked after this issue is posted to show the test.
• action:Action and core:Event are designated disjoint with one another, as a result of Issue 563. This is enforced with the shape uco-action:Action-disjointWith-Event-shape.
• observable:File and observable:URL are designated disjoint with one another, as a result of Issue 536. This is enforced with the shape uco-observable:File-disjointWith-URL-shape.
• uco-types:Thread and co:List were designated disjoint with the introduction of uco-types:Thread in Issue 393. The disjointedness is not currently enforced with a shape.
  • And likewise for uco-types:ThreadItem and co:ListItem.

I specifically noticed core:UcoObject and core:UcoInherentCharacterizationThing when I was testing a new class under proposal (Qualities, in Issue 535) and how it interacts with the proposed endurant/perdurant divide (Issue 544). Details aside (they'll be discussed on at least the Qualities proposal), I'd ended up instantiating a node that was an eventual subclass of core:UcoObject and core:UcoInherentCharacterizationThing, and got no SHACL errors.

UCO should add new shapes, in the style of the current disjointedness-enforcement shapes, to enforce the expectations already encoded in its OWL. The reason for continuing the current disjointedness-enforcement shapes style is that those shapes are independent of the class IRI, and are singly devoted to use of sh:not, for the sake of controlling the SHACL violation message. (Message reporting doesn't quite work as would be desired from embedding sh:message in the node linked by sh:not.)

Requirements

Requirement 1

UCO must enforce the already-encoded disjointedness for core:UcoObject and core:UcoInherentCharacterizationThing.

Requirement 2

UCO must enforce the already-encoded disjointedness for types:Thread and co:List.

Risk / Benefit analysis

Benefits

• Continues the pattern of use of SHACL to align with OWL encodings in certain set-separations.
• Prevents downstream modeling issues, as uncovered in reviewing Qualities versus Endurants.

Risks

• Because this introduces potentially new sh:Violations on existing data, the shapes will need to be introduced with a sh:Warning severity for UCO 1.x.0, and can be escalated to sh:Violation severity for UCO 2.0.0. This is as with the observable:File vs. observable:URL proposal.

Competencies demonstrated

Competency 1

The Quality class design that triggered this proposal basically followed this subclass structure, which came together across a few different test spaces:

drafting:Endurant
	rdfs:subClassOf uco-core:UcoOjbect ;
	.

drafting:Quality
	rdfs:subClassOf
		drafting:Endurant ,
		uco-core:UcoInherentCharacterizationThing
		;
	.

Competency Question 1.1

Should this trigger a SHACL violation?

kb:Quality-328166c0-cc7d-4a96-9fd1-25eb3b7bf5b0
	a drafting:Quality ;
	.

Result 1.1

Yes.

Solution suggestion

Add the following shapes:

################################
# For core.ttl

core:UcoInherentCharacterizationThing-disjointWith-UcoObject-shape
	a sh:NodeShape ;
	sh:message "observable:UcoInherentCharacterizationThing and observable:UcoObject are disjoint classes.  Assigning both types to a single node will be an error in UCO 2.0.0."@en ;
	sh:not [
		a sh:NodeShape ;
		sh:class core:UcoObject ;
	] ;
	sh:severity sh:Warning ;
	sh:targetClass core:UcoInherentCharacterizationThing ;
	.

################################
# For types.ttl

types:Thread-disjointWith-co-List-shape
	a sh:NodeShape ;
	sh:message "types:Thread and co:List are disjoint classes.  Assigning both types to a single node will be an error in UCO 2.0.0."@en ;
	sh:not [
		a sh:NodeShape ;
		sh:class co:List ;
	] ;
	sh:severity sh:Warning ;
	sh:targetClass types:Thread ;
	.

types:ThreadItem-disjointWith-co-ListItem-shape
	a sh:NodeShape ;
	sh:message "types:ThreadItem and co:ListItem are disjoint classes.  Assigning both types to a single node will be an error in UCO 2.0.0."@en ;
	sh:not [
		a sh:NodeShape ;
		sh:class co:ListItem ;
	] ;
	sh:severity sh:Warning ;
	sh:targetClass types:ThreadItem ;
	.

In UCO 2.0.0, remove the sh:severity and future-tense remarks in the sh:messages.

Coordination

• Tracking in Jira ticket OCUCO-305
• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2024-02-01
• Requirements to be discussed in OC meeting, 2024-02-15
• Requirements Review vote occurred, passing, on 2024-02-15
• Requirements development phase completed.
• Solution announced to OCs on 2024-04-29
• Solutions Approval to be discussed in OC meeting, 2024-05-30
• Solutions Approval vote occurred, passing, on 2024-05-30
• 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
• Milestone linked
• Documentation logged in pending release pages
• 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

[ajnelson-nist]

The Gist I mentioned in the Issue is here.