UCO OWL review of RDF List was scoped too broadly

[ajnelson-nist]

Bug description

As part of reviewing UCO's syntax for semi-open vocabularies before UCO 1.0.0 (done in Issue 406), some shapes were written to check the syntax for OWL definitions of custom datatypes. Those shapes recognized some requirements OWL makes on rdf:List, but incorrectly scoped them to apply to all rdf:Lists. This causes some issues with review of certain OWL "A-Box" review (used for representing individuals, i.e. instances of the classes and users of properties from the "T-Box"), as well as SHACL review.

The shapes around rdf:List, rdf:first, and rdf:rest currently in the UCO OWL shapes file need to be revised to be scoped to OWL. This will mean going with a more strict enumeration style, following the rule-matching in the OWL 2 Web Ontology Language Mapping to RDF Graphs (Second Edition).

This Issue houses a bug report and a remediating Change Proposal. It appears complex enough to me to need a Requirements Review vote.

Steps to reproduce

These RDF snippets should not cause UCO's SHACL validation to fail, but currently they do:

@prefix kb: <http://example.org/kb/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
kb:MyOrderedCollection
  a skos:OrderedCollection ;
  skos:memberList ( kb:X kb:Y kb:Z ) .

The above instance-data snippet is drawn from Example 41 in the SKOS reference Section 9.3.

@prefix dash: <http://datashapes.org/dash#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

dash:DateOrDateTime
  a rdf:List ;
  rdf:first [
      sh:datatype xsd:date ;
    ] ;
  rdf:rest (
      [
        sh:datatype xsd:dateTime ;
      ]
    ) ;
  rdfs:comment "An rdf:List that can be used in property constraints as value for sh:or to indicate that all values of a property must be either xsd:date or xsd:dateTime." ;
  rdfs:label "Date or date time" ;
. 

The above SHACL supplementary snippet is drawn from DASH Data Shapes Vocabulary Section 8.1, where the prescribed usage of the shape follows this general form:

@prefix dash: <http://datashapes.org/dash#> .
@prefix ex: <http://example.org/shapes/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

ex:DateOrDateTimeShape
    a sh:NodeShape ;
    sh:property [
        sh:path ex:timeStamp ;
        sh:or dash:DateOrDateTime ;
    ] .

As an aside, a sibling shape snippet, dash:StringOrLangString, could support a goal in the CASE backlog (ONT-6) of supporting language strings without universally requiring language string annotations. (I was informed of this shape in discussion on this pySHACL issue.)

dash:StringOrLangString
  a rdf:List ;
  rdf:first [
      sh:datatype xsd:string ;
    ] ;
  rdf:rest (
      [
        sh:datatype rdf:langString ;
      ]
    ) ;
  rdfs:comment "An rdf:List that can be used in property constraints as value for sh:or to indicate that all values of a property must be either xsd:string or rdf:langString." ;
  rdfs:label "String or langString" ;
.   

Requirements

Requirement 1

UCO's OWL review must not prevent other RDF idioms that are not necessarily within OWL's purview (e.g. instance-data rdf:Lists and SHACL constructs).

Risk / Benefit analysis

Benefits

• Fixes bug impacting applicability past UCO.
• Updates UCO's implemented understanding of OWL 2 DL structural and syntactic nuances.

Risks

• Stub increases: A migration has been proposed to the CDO Technical Steering Committee to export the UCO OWL review shapes into their own repository (described in CDOTSC-34). Some technical-logistical issues have arisen when testing CDO Profiles (profiles described here), delaying that migration. When completed, the new IRIs proposed as part of this Issue will become deactivated stub references.
  • This is believed to be no further operational risk compared to the current state of UCO's OWL (and possibly Collections Ontology) review shapes.
  • One issue that has been recently realized is that stub sh:PropertyShapes will likely need to remain sh:PropertyShapes when reduced to a deactivated stub, in order to continue satisfying any incorporations by the sh:property predicate.
• A non-update on duplication in UCO: One grumble that the UCO Ontology Community collectively had (myself included) was that this OWL review mechanism induced a significant duplication of rdf:Lists used in support of UCO's semi-open vocabulary design pattern. Unfortunately, while the SHACL-specific lists can now be given IRIs and incorporated by IRI reference, the OWL custom-datatype definitions are still affected, so there may be only a few cases where a rdf:List can be de-duplicated in support of semi-open vocabularies.

Competencies demonstrated

UCO's OWL review should not raise any issues for the DASH and SKOS usage patterns described above. The examples are encoded in updated unit tests accompanying this Issue.

Solution suggestion

• Deactivate uco-owl:List-shape; split its functionality into three other shapes.
  • uco-owl:Sequence-shape houses review rules for OWL Sequences, narrower in scope than rdf:Lists.
    • This shape avoids recursive shape references, to avoid infinite recursion issues.
    • This shape guarantees OWL Sequences use blank nodes, and makes no review of non-OWL-"T-Box" rdf:Lists.
    • This shape has no SHACL targeting predicate. Instead, it is adopted by other shapes using sh:node.
  • uco-owl:rdf-first-subjects-shape and uco-owl:rdf-rest-subjects-shape perform structural review that is generalizable to rdf:List - that if either predicate is used on some subject node N, then N has both of the predicates exactly once.
  • uco-owl:List-shape is retained, untargeting and deactivated, to maintain IRI availability as part of backwards compatibility.
• For each of the sequence-valued OWL predicates noted in this document, particularly Section 3.2.4, define a shape targeting objects of the predicate that adopts the sequence node shape using sh:node.

For instance, for owl:oneOf, this new shape is defined:

uco-owl:oneOf-objects-shape
    a sh:NodeShape ;
    sh:node uco-owl:Sequence-shape ;
    sh:targetObjectsOf owl:oneOf ;
    .

This issue leaves the following out of scope, to remain focused on fixing the overly-broad review bug:

• Any further constraints on the list members contextualized to the predicate. (E.g. owl:oneOf should be further constrained based on whether it is being used for an ObjectOneOf or DataOneOf construct. That will come in a future proposal.)
• Any constraints on subjects of the newly-reviewed predicates. (E.g. several require use on blank nodes, e.g. for owl:Restrictions.)

Coordination

• Tracking in Jira ticket OC-301
• [x] Administrative review completed, proposal announced to Ontology Committees (OCs) on 2023-12-04
• [x] Requirements to be discussed in OC meeting, 2023-12-12
• [x] Requirements Review vote occurred, passing, on 2023-12-12
• [x] Requirements development phase completed.
• [x] Solution announced to OCs on 2024-01-12
• [x] Solutions Approval to be discussed in OC meeting, 2024-01-18
• [x] Solutions Approval vote occurred, passing, on 2024-01-18
• [x] Solutions development phase completed.
• [x] Backwards-compatible implementation merged into develop for the next release
• [x] develop state with backwards-compatible implementation merged into develop-2.0.0
• [x] Backwards-incompatible implementation merged into develop-2.0.0 (N/A)
• [x] Milestone linked
• [x] Documentation logged in pending release page
• [x] Prerelease publication: CASE develop branch updated to track UCO's updated develop branch
• [x] Prerelease publication: CASE develop-2.0.0 branch updated to track UCO's updated develop-2.0.0 branch

[ajnelson-nist]

Update: This proposal initially included several shapes using sh:targetObjectsOf on OWL sequence-valued predicates. In this comment on the PR, I concluded that it would be better for issue remediation to use sh:targetSubjectsOf instead, so the PR now implements shapes targeting predicates' subjects.