Closed ajnelson-nist closed 2 years ago
PR 407 is posted to help with review, but it will be replaced with another patch series after tomorrow's meeting.
An objection to this proposal's Solution was made in a committee meeting, and has been logged here.
For the OCs' awareness - there is another effect of adding OWL review using pyshacl
. It is noted in this comment.
Background
Many questions have come up over the years of UCO's development related to whether its usage of OWL 2 DL is correct. Development since the UCO and CASE prototypes has been performed without using an OWL review mechanism that could determine elementary issues such as whether the Turtle syntax was correct (resolved once a syntax normalizer was adopted for Continuous Integration), through advanced issues such as whether the ontology defines unsatisfiable classes (i.e. classes that constrain themselves, intentionally or otherwise, to always be empty).
Some engines have been tried to determine UCO's OWL 2 DL conformance, but have frequently met issues with being incompatible in some way or another with UCO's usage of SHACL. Most pointedly, SHACL is not defined as an OWL ontology in any way that exercises OWL classes or properties, which causes OWL validation of a SHACL ontology to halt due to considering
sh:
-prefixed concepts to be incompletely defined.UCO needs some constraints from OWL 2 DL, such as ensuring disjointedness of object-properties from datatype-properties. There are also significant node constraints within OWL 2 DL that have proven difficult to determine even after several read-throughs of specifications, and misunderstanding those constraints could accidentally move a UCO graph from OWL 2 DL into OWL FULL where behaviors are undefined. To wit, prior considerations for ontology versioning and for reification of triples both encountered significant strategic revisions after finding part of the intended strategy was disallowed in OWL 2 DL.
SHACL provides SPARQL-based mechanisms (in SHACL-SPARQL; see examples) to identify triple combinations that should not appear in an ontology-graph or data-graph. UCO should make best-effort usage of SPARQL-based constraints to validate its OWL usage.
Requirements
Requirement 1
UCO must be able to validate its conformance against OWL 2 DL, in at least partial degree.
Requirement 2
Extensions to UCO (such as ontology revisions under draft outside of this Git repository, and private extensions) must be able to use UCO's OWL 2 DL conformance-review mechanism.
Requirement 3
The transitive closure of UCO's imports must be testable with at least the same OWL 2 DL stringency as is applied to UCO.
Risk / Benefit analysis
Benefits
Risks
tests/examples/
in this repository are examples of "ABox" graphs.)rdf:List
for the purpose of easing maintainability of OWL enumerant-based datatypes and UCO's semi-open vocabularies needing to be able to reference member lists in SHACL shapes. This shortcut was called out as a known act of delaying a OWL 2 DL conformant implementation. For better or worse, the SHACL shapes accompanying this proposal flag that as an error, inducing the need to undo that shortcut. This causes two risks:make -j
), and triple non-parallel testing time (make
without-j
, as the CI runs it), becauserdf-toolkit
takes an extensive amount of time to sort longrdf:List
s, especially those in the vocabulary namespace, and they will now be duplicated in the observable namespace. This does not currently cause a risk of timeouts on Github Actions, as the default timeout is currently 6 hours.rdfs:Datatype
s.Competencies demonstrated
Competency 1
As part of CI testing, UCO can now review its conformance with OWL 2 DL.
Competency Question 1.1
What does UCO define as best-effort conformant with OWL 2 DL?
Result 1.1
A review of the
uco-owl
namespace shows shapes that quote and link the OWL 2 specification.Competency Question 1.2
How does UCO test that its (TBox) ontology is conformant with OWL 2 DL?
Result 1.2
Within the CI, a monolithic build of UCO is constructed, combining all of the Turtle files under the
ontology/
directory. Before that file is syntax-normalized,pyshacl
is used to review the combined file with theuco-owl
namespace's shapes. Seetests/Makefile
, targetuco_monolithic.ttl
.Competency Question 1.3
What other ontologies can be reviewed with the
uco-owl
namespace?Result 1.3
The
uco-owl
namespace tests conformance versus OWL 2 DL, as well as some implications for SHACL shapes, such as confirming thatDatatypeProperty
s used inPropertyShape
s aren't constrained to match non-Literal
s. This can apply to ontologies that are more focused on TBoxes (classes/properties/datatypes), or broader ABox knowledge-bases such as tool output mapped into UCO.The support done for the broader ABox-oriented knowledge bases is currently review of ontology imports' transitive closure, and
owl:Axiom
s for assertion-annotations. See especially the shapes pertaining toowl:Axiom
,owl:ontologyIRI
, andowl:versionIRI
.Solution suggestion
https://ontology.unifiedcyberontology.org/owl
, prefixuco-owl:
.rdfs:seeAlso
) to OWL 2 documentation.sh:severity
(sh:Violation
) for "MUST NOT" pattern matches.sh:severity sh:Warning
for "SHOULD NOT " pattern matches.rdf:List
s done to ease semi-open vocabulary synchronization.uco-owl:
shape.Coordination
develop