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.
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.
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.
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:
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.
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 withcore:UcoObject
. For instance, no object should be both aobservable:File
andobservable: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":ObjectProperty
,DatatypeProperty
, andAnnotationProperty
) are disjoint. This is enforced with the shapesuco-owl:Disjointedness-AP-DP-shape
,uco-owl:Disjointedness-AP-OP-shape
, anduco-owl:Disjointedness-DP-OP-shape
.uco-owl:Disjointedness-C-DT-shape
.action:Action
andcore:Event
are designated disjoint with one another, as a result of Issue 563. This is enforced with the shapeuco-action:Action-disjointWith-Event-shape
.observable:File
andobservable:URL
are designated disjoint with one another, as a result of Issue 536. This is enforced with the shapeuco-observable:File-disjointWith-URL-shape
.uco-types:Thread
andco:List
were designated disjoint with the introduction ofuco-types:Thread
in Issue 393. The disjointedness is not currently enforced with a shape.uco-types:ThreadItem
andco:ListItem
.I specifically noticed
core:UcoObject
andcore: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 ofcore:UcoObject
andcore: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 embeddingsh:message
in the node linked bysh:not
.)Requirements
Requirement 1
UCO must enforce the already-encoded disjointedness for
core:UcoObject
andcore:UcoInherentCharacterizationThing
.Requirement 2
UCO must enforce the already-encoded disjointedness for
types:Thread
andco:List
.Risk / Benefit analysis
Benefits
Risks
sh:Violations
on existing data, the shapes will need to be introduced with ash:Warning
severity for UCO 1.x.0, and can be escalated tosh:Violation
severity for UCO 2.0.0. This is as with theobservable: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:
Competency Question 1.1
Should this trigger a SHACL violation?
Result 1.1
Yes.
Solution suggestion
Add the following shapes:
In UCO 2.0.0, remove the
sh:severity
and future-tense remarks in thesh:message
s.Coordination
develop
for the next releasedevelop
state with backwards-compatible implementation merged intodevelop-2.0.0
develop-2.0.0
develop
branch updated to track UCO's updateddevelop
branchdevelop-2.0.0
branch updated to track UCO's updateddevelop-2.0.0
branch