UCO semi-open vocabularies seem to use `owl:onDatatype` incorrectly

[ajnelson-nist]

Bug description

The document OWL 2 Mapping to RDF Graphs specifies the subtractive parsing process used to parse an RDF graph as an OWL ontology.

When using an externally-developed tool to try reviewing UCO's current OWL conformance, I saw some issues reported around the semi-open vocabularies. See e.g. vocabulary:BitnessVocab, chosen for illustration here only because it is short:

vocabulary:BitnessVocab
	a rdfs:Datatype ;
	rdfs:label "Bitness Vocabulary"@en-US ;
	rdfs:comment "Defines an open-vocabulary of word sizes that define classes of operating systems."@en ;
	owl:equivalentClass [
		a rdfs:Datatype ;
		owl:onDatatype xsd:string ;
		owl:oneOf (
			"32"^^vocabulary:BitnessVocab
			"64"^^vocabulary:BitnessVocab
		) ;
	] ;
	.

It appears owl:onDatatype is incorrect to use in this definition. From reviewing the OWL2--RDF document noted above, the only OWL construct that predicate appears in is DatatypeRestriction (Table 12, last row; Table 1, a sole row in the middle).

Due to the subtractive nature of the OWL parsing process (described recently in the competencies under Issue 591, Result 1.1), that predicate will be left "dangling" after the structure pertaining to owl:oneOf is consumed and removed from the graph. (The reverse seems unlikely, because no owl:withRestrictions predicate is present.)

It appears it is necessary to remove all occurrences of [] owl:onDatatype xsd:string . from the UCO (and CASE) vocabulary namespaces.

Steps to reproduce

This is among the issues reported from ROBOT 1.9.5¹², using the following command from UCO's root directory:

java -jar robot.jar validate-profile \
  --input ontology/uco/vocabulary/vocabulary.ttl \
  --profile DL

The change proposal form is posted in a comment below.

Coordination

• Tracking in Jira ticket OCUCO-322
• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2024-08-09
• Requirements to be discussed in OC meeting, 2024-08-20
• Requirements Review vote occurred, passing, on 2024-08-20
• Requirements development phase completed.
• Solution announced to OCs on 2024-09-11
• Solutions Approval to be discussed in OC meeting, 2024-09-26
• Solutions Approval vote occurred, passing, on 2024-09-26
• Solutions development phase completed.
• Backwards-compatible implementation merged into develop for the next UCO release
• Backwards-compatible implementation merged into develop for the next CASE release
• develop state with backwards-compatible implementation merged into develop-2.0.0 for UCO
• develop state with backwards-compatible implementation merged into develop-2.0.0 for CASE
• Backwards-incompatible implementation merged into develop-2.0.0 (N/A)
• Milestone linked
• Documentation logged in pending UCO release page
• Documentation logged in pending CASE 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

Footnotes

1. 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. ↩

2. This Issue is not a suggestion to add that tool to UCO's test suite. ↩

[ajnelson-nist]

PR 628 has been posted implementing the bugfix pertaining to this Issue.

A PR adding a shape for OWL syntax review will come in a future PR.

The change proposal form is in this comment, for the sake of generating email notices.

Requirements

Requirement 1

• UCO rdfs:Datatypes that implement semi-open vocabularies must conform to the OWL syntax requirements pertaining to DatatypeRestriction and DataOneOf.

These syntactic requirements are given in OWL 2 Web Ontology Language Mapping to RDF Graphs (Second Edition). See Table 1 for the constructs' translations to RDF, and note the requirements on blank nodes and accompanying properties.

• DataOneOf translates to a blank node, typed rdfs:Datatype and having a RDF List linked with owl:oneOf.
• DatatypeRestriction translates to a blank node, typed rdfs:Datatype AND that uses both owl:onDatatype and owl:withRestrictions.
• The subtractive OWL parsing process would consume (delete) enough constructs to satisfy exactly one of these structures, and the other would be unsatisfiable because _:x rdf:type rdfs:Datatype would be part of what was consumed.

Non-requirement

This proposal does NOT include a SHACL test for these OWL syntax constructs, but one is planned for a future date.

Risk/benefit analysis

Benefits

• This removes a barrier in UCO to adoption by other ontologies that require strict OWL syntax conformance.
• This brings UCO closer to being able to be tested with OWL-reviewing tools, and used with OWL inferencing engines. Currently, at least one tool is known to raise OWL syntax concerns with any attempt to use UCO's Vocabulary namespace.
• There is no known impact on user data (i.e., "ABox" graph individuals) from adoption of this proposal. E.g., types:Hash individuals are not known to be impacted.

Risks

• This proposal removes references to xsd:string from the vocabularies, which in a way decouples the enumerations from xsd:string. However, this appears to be a moot concern, due to another syntax issue also described by ROBOT (the tool noted in the original Issue; also, please see NIST disclaimer): The definitions are circular in a manner that OWL considers invalid syntax. Addressing this circular definition is left for a separate proposal due to a significant impact on user data.
• This proposal would impact CASE and any other adopters who have implemented a semi-open vocabulary: Their vocabulary definitions would also need to have owl:onDatatype in the described circumstances removed. Vote(s) for this proposal should be considered to apply to CASE as well as UCO.

Solution suggestion

Delete owl:onDatatype from the vocabulary namespace, due to usage only occurring in one consistent pattern.

[ajnelson-nist]

This proposal also has an impact on the implementation of Issue 549, as that issue adds a new vocabulary.