Closed ajnelson-nist closed 1 year ago
The actual PR of the proposed solution for this issue contained a significant and widespread change that was not identified or addressed in the actual change proposal. The CP identified needed changes to the vocabulary datatype definitions in the vocabulary namespace. These were clearly identified and explained in the CP and were widely discussed and agreed to in the ontology committee. The solution PR included the additional significant change of duplicating out all vocabulary value lists from not only their position within the vocabulary datatype definition (as identified in the CP) but also into the property shapes for EVERY point of use for any vocabulary throughout all of UCO. The current approach in UCO supported simple maintenance and evolution of vocabularies as they are all located in one namespace so you always know where to find them and their value space are defined in one place (their datatype definition) so that changes/additions/deletions can be made in one place eliminating the risk of conflicting definitions due to changes being made in some places and not in others. The proposed changes in the PR eliminate this practicality. With the proposed change there is now significantly more work required and risk imparted to manage vocabularies. Now for any changes/additions/deletions the entire ontology must be searched and ALL occurrences must be maintained consistently. This becomes increasingly problematic when application domain ontologies using UCO utilize UCO vocabularies resulting in required consistency across multiple scopes of authoritative control. OWL DL is a significant objective to shoot for but should not outweigh the critical needs for practicality in the development and use of UCO. Given the choice between the two, practicality should always win. This is specifically codified as a foundational principle for UCO within the CDO charter. I see no issues with the proposed changes at the vocabulary datatype definitions but the proliferation of vocabulary value duplication should not be pursued even if it is at the expense of full OWL DL conformance.
This issue was voted on at the August 9th ontology committee meeting and passed over my strong objections. I do not believe that the ontology members voting in the affirmative fully comprehend the potential impact of this change and I think this will likely come back to bite us at a later date where it will be much more difficult to reverse.
This comment is added as a record of these objections and their rationale.
@sbarnum Thank you for logging your objection.
Slight correction - your comment should have been posted on Issue #406 , not 435.
I agree with this effect on RDF Lists being a significantly unpleasant consequence of OWL 2 DL conformance.
However, the Ontology Committees were warned several times that the engineering convenience of making the shared -members
rdf:List
concepts was a convenience made in spite of a known potential incompatibility with OWL 2 DL. The first warning was explicit, recorded in Proposal 100, and called out in the meeting just before that proposal was voted on. The committee was warned in the Risks of the Issue page of 406 that, having found the explicit citation in the OWL 2 to RDF mapping, that convenience was being rolled back. And, the first commit documented that the unpleasant change was being carried out.
This is an unfortunate interaction of OWL and SHACL. However, be aware also that the "Semi-open vocabulary" design of UCO is, by my experience within the ontology space, possibly a novel feature, and I suspect is certainly a novel implementation as it is now. The most graceful implementation of the goal of semi-open vocabularies might not be lists of strings. The MIME Taxonomy proposal may lead us to an alternative implementation that still allows for user extensibility with gentle warnings about set-membership; allows definitions of semantics for the members; and further, doesn't itself encourage any of our committee members to jettison our underlying standards for the sake of a "foundational principle" that is meeting harsh realities of technology implementation and interoperability of predating standards.
The design document itself is still undergoing review and testing. The lack of workflow time being devoted to it should not be mistaken for acceptance of the document as a whole.
This proposal is ready for a Solutions Approval vote on 2022-08-25. Note that there was a procedural error in processing this proposal, and it was prematurely merged into UCO's develop
. Also, an effect realized on a vocabulary in CASE c/o a new test in this proposal brought to light that CASE had fallen behind on implementing upstream UCO features. The meeting on Thursday will cover updates to the review process implemented to handle both of these matters.
Background
This proposal is an upgrade to UCO CP-90, and is in part a transcription to re-capture original motivations. The CP-90 Confluence page should now be considered superseded by this Github Issue.
The construction of UCO vocabularies does not conform to the OWL 2 mechanism for custom datatype definitions. The non-conformance issue harkens back to the definition of datatypes in RDF Schema. This proposal adds and encodes two requirements for the UCO
vocabulary
namespace, which apply equally to CASE’svocabulary
namespace.For illustration, we will upgrade UCO's
vocabulary:BitnessVocab
to become conformant. (This was selected by merit of having just two members.)Here is the current definition of
BitnessVocab
, omitting therdfs:label
andrdfs:comment
so we may focus on the OWL syntax:Requirements
Requirement 1
UCO must satisfy with OWL 2 syntactic requirements. This entails requiring conformance with RDF syntactic requirements. (These requirements are not distinct to this proposal.) (These requirements are agnostic to serialization language, e.g.
application/rdf+xml
,text/turtle
, et al.)Requirement 2
Remove all statements of the form
vocabulary:SomeVocab rdfs:subClassOf rdfs:Resource .
from the vocabulary namespace.Requirement 2 applicability
This syntax is present in the vocabulary definitions that has confused some tools used in earlier attempts to review the
Datatype
issues. This statement:is entailed by RDF Schema, Sections 2.3 and 2.4, which respectively state:
At least one OWL Profile validation tool is confused by this redundant statement. An error declaration is made by the tool ROBOT and its verb
validate-profile
, that the custom vocabulary declares itself an individual and a class. This violates OWL 1 DL, and is not excepted by OWL 2 DL's Punning.Hence, with no loss of semantics, we propose this requirement to prevent tool confusion.
Requirement 3
In conformance with OWL 2 DL and RDF datatype definitions, UCO's datatypes that are enumerations of string-literals must conform with this definition from RDF 1.1 Concepts Section 5
Requirement 3 applicability
For some of the original XML Schema datatypes, the value space draws from abstract and/or platonic concepts, such as
xsd:boolean
containing the valuestrue
andfalse
, distinct from the lexical values"true"
and"false"
.As spelled in UCO 0.9.0 and earlier,
BitnessVocab
confuses the lexical space and value space, and provides no mapping. The syntax for defining a datatype is given in functional syntax in OWL 2 Syntax, Section 9.4; see especially the examplea:SSN
. Also note that RDF syntax can be toggled "On" with that document's "Show RDF in Examples" button, which shows this demonstration:(OWL 1 made discussion of lexical vs. value
Datatype
s somewhat less confusing to discuss with a conceptowl:DataRange
. However,owl:DataRange
was dropped in the transition to OWL 2. So, we must make do with discussing "Value space"Datatype
s and "Lexical space"Datatype
s.)Two less-obvious syntax components are pertinent to UCO:
rdfs:Datatype
(i.e. the value-spaceDatatype)
is defined as equivalent to anotherrdfs:Datatype
(i.e. the lexical-spaceDatatype
)._:x
, especially the underscore as a node-identifier prefix, is a designation of a blank node. This text pattern holds both in examples in the OWL 2 Syntax document, and in the strict parsing rules in the OWL 2 to RDF mapping.The OWL 2 to RDF mapping defines the required syntax (Section 3.2.4, Table 12, row 4) for the enumeration-based lexical-space
rdfs:Datatype
:UCO's vocabularies are currently incorrect in two manners according to this syntax:
owl:oneOf
is an IRI, not a blank node.Risk / Benefit analysis
Benefits
Risks
owl:oneOf
sequences. Their usage induces a circular definition, but to date this usage has not caused confusion within graph engines. Hence, review of the strings' type annotations is left as out of scope.Competencies demonstrated
Competency 1
A general OWL 2 consumer is interested in seeing all literals that are members of enumerated vocabularies.
Competency Question 1.1
What datatypes are based on fixed sets of literals, and what are their members?
Result 1.1
Run against UCO 0.9.0, these are the results of that query:
Nothing from the
vocabulary
namespace is yet returned.Solution suggestion
owl:oneOf
onrdfs:Datatype
nodes, adding to OWL review suite started in Issue 406.vocabulary
namespace.observable
namespace also definesDatatype
s that are enumerations of literals, e.g.NetworkSocketAddressFamily
. These are already in the correct OWL 2 DL syntax.Coordination
develop
(Note: Implementation was accidentally merged before Solutions Approval vote)develop
(Note: Implementation slated to merge before Solutions Approval vote due to 427 already being merged)develop
(Note: Implementation slated to merge before Solutions Approval vote due to 427 already being merged)