ajnelson-nist
commented
2 years ago This nudges UCO into an interesting testing space. The owl:disjointWith statement is a commitment, but in the context of SHACL, means nothing quiet yet. It is meant to be verified by an OWL engine, and on finding an error case (an object that is both a UcoObject and Facet), the engine would likely return a result that "the ontology" is inconsistent, hopefully with an explanation of which non-inferred triples caused the inconsistency. "The ontology" could be a user's knowledge graph, containing an inconsistent individual.
With UCO's testing how happening with SHACL, what is a reasonable way to implement this consistency check?
The SPARQL test to detect violations of this disjointedness commitment in a user's knowledge graph would be:
SELECT $this
WHERE {
$this a/rdfs:subClassOf* core:UcoObject .
$this a/rdfs:subClassOf* core:Facet .
}The test to detect violations "upstream" of instance data (i.e. something UCO could include in its unit testing) would be:
SELECT $this
WHERE {
$this rdfs:subClassOf* core:Facet .
$this rdfs:subClassOf* core:UcoObject .
}Either of these could be added to a sh:NodeShape using a SHACL-SPARQL rule. (Here is an example. One thing that tripped me up initially - the SELECT query returns all non-conformant nodes, not all conformant nodes.)
These could be significantly compute-expensive tests to incorporate into the ontology. However, with some judicious use of sh:deactivated we might be able to leave it in the ontology, and let users opt in by deleting the sh:deactivated triple.
sbarnum
plbt5
Background
The distinction between
UcoObjects andFacets, and particularly its use in an ontological artefact, is insufficiently understood by, and creates confusion for, the community members. Any class that is defined in UCO (or CASE) cannot have both acore:UcoObjectand acore:Facetin its superclass hierarchy, specified or inferenced alike.Requirements
Requirement 1
Clarify the distinction between an ontological
core:UcoObjectand an ontologicalcore:Facet, and how each of them are used appropriately. This requirement pertains to design documentation.Requirement 2
Prevent incorrect use of the
Facetand theUcoObject, particularly that inferencing might decide that a Class has both aFacetand aUcoObjectin its supertype hierarchy. This requirement pertains to the ontology's inferencing capabilityRisk / Benefit analysis
Benefits
Risks
The submitter is unaware of risks associated with this change
Competencies demonstrated
Competency 1
A community member wants to get informed about the distinction and use of
core:UcoObjectand ofcore:Facet.Competency Question 1.1
Where can I find appropriate information about the distinction and use of
core:UcoObjectand ofcore:Facet?Result 1.1
In the UCO Design Document
Competency 2
Specify a particular Class directly as a subclass of
core:UcoObjectand ofcore:Facet.Competency Question 2.1
Is the ontology consistent?
Result 2.1
No
X-Ref matrix: Requirements - Competencies
Solution suggestion
Disjointness has to be explicitly stated for a reasoning system to make use of it. Therefore, add the triple:
core:UcoObject owl:disjointWith core:Facet .to uco-core.
Coordination
developmasterof UCO website