A SHACL OWL "profile" to aid ontologies mixing SHACL and OWL

[ajnelson-nist]

I'm posting this mindful of the scope of the current SHACL working group not including other modeling languages. I am hopeful that this stays within bounds for a modeling language that has already had some concepts used by SHACL, OWL 2, specifically for owl:Ontology, and incidentally owl:imports.

Summary: This is a request to add a graph as a resource in the SHACL suite for the benefit of ontologies that want to use SHACL, AND be conformant to OWL 2 DL (or other profile), and not fall into OWL 2 FULL.

There are ontologies that use a mixture of SHACL and OWL for the two languages' non-overlapping features. There is some roundabout compatibility support for OWL class modeling with SHACL, such as in SHACL 1.0's Section 2.1.3.3 definition of implicit class targets and SHACL Class's positional description that lets owl:Class substitute straightforwardly for rdfs:Class.

However, usage of SHACL in an OWL ontology currently does not satisfy OWL 2 DL rules, without a little extra work left to the implementing ontologists. Syntactically, there is a requirement that can be elided from "skipping ahead" in the OWL specs to OWL 2 Web Ontology Language Mapping to RDF Graphs (Second Edition), that:

• Whenever o is the object in a triple s rdf:type o, o needs to be an instance of owl:Class (or owl:Restriction and other reserved OWL IRIs, but they're beside the point for this issue).
• Whenever p is the predicate in a triple s p o, p must be exactly one of owl:ObjectProperty, owl:DatatypeProperty, or owl:AnnotationProperty.

SHACL and SHACL-SHACL are currently defined primarily with RDFS concepts. Every class and property are rdfs:Class and rdf:Property. The SHACL 1.0 implementation includes the triple sh: a owl:Ontology ., so in a sense, a toe is already dipped into the OWL waters.

The issue is, if an ontology is using SHACL and OWL, the ontology will not be conformant to OWL 2 DL unless it takes the extra step of assigning OWL modeling concepts to every concept in SHACL used in the ontology. E.g., if sh:declares is used, it needs to be defined as an owl:ObjectProperty or owl:AnnotationProperty. I think there is no reason to leave every SHACL-and-OWL adopter the task of adding these statements, especially if there is any pondering they might do on whether every property should be an owl:AnnotationProperty or not.

For the benefit of ontologies mixing OWL and SHACL, can a graph be provided that:

• For each class in SHACL, asserts it is an owl:Class;
• For each property in SHACL, asserts it is an owl:AnnotationProperty.

From my experience with OWL 2 DL conformance testing, I believe this would be sufficient to enable OWL 2 DL conformance testing with SHACL concepts not being an impediment.

If anyone wants to dig into the reasoning for global assignment of owl:AnnotationProperty - again, being mindful of scoping of working group activities - this is to:

• Allow the freedom to let SHACL properties have ranges of literals or non-literal nodes without OWL concerns, and
• Implicitly separate SHACL modeling from OWL modeling involving owl:Restrictions (c/o the reminder that owl:AnnotationPropertys cannot be restricted - see all occurrences of owl:onProperty in the OWL-RDF mapping I cited above, and note "AP" for "Annotation Property" never occurs).

I suggest this graph file be standalone, and not use owl:imports to bring in anything (including the core SHACL spec graph). The new graph should be able to be owl:imports-able by itself.

This graph can be typed up in about 10 minutes with a plain text editor, and I believe would be straightforward to maintain with the evolving SHACL 1.2 and beyond specifications with a mutual coverage checking script. The harder question for the group is the decision to provide this.

Somewhat related issues I can recall offhand:

• Have a dedicated class to type SHACL specifications (instead of owl:Ontology) #169 - A suggestion to use another type instead of owl:Ontology
• Missing Type for shsh: #196 - A note that RDFS entailment can assign the type owl:Ontology to SHACL-SHACL too; however, IIRC (corrections welcome), OWL entailment will terminate reporting inconsistency while properties are not additionally typed per OWL 2 DL specification.

[tfrancart]

I think it would be useful. But if the group agrees to do that, why keeping these assertions in a separate graph ? why not including them in SHACL-SHACL directly ?

[ajnelson-nist]

I think it would be useful. But if the group agrees to do that, why keeping these assertions in a separate graph ? why not including them in SHACL-SHACL directly ?

@tfrancart : I don't want to suggest requiring OWL-&-SHACL users have to import SHACL or SHACL-SHACL. A SHACL user today does not have to import the SHACL graph - they instead just use the SHACL concepts. An OWL-&-SHACL user only needs to know what the structural types are for each of the SHACL concepts, and this is doable with a couple dozen triples.

[bergos]

I think there is an overlap between data modeling and the bounds of subgraphs defined by shapes. For the later use case, constraints for filtering can be optional. The Shape Topologies algorithm, used by the TREE hypermedia specification, skips the filtering for the sake of simplicity.

Maybe it makes sense to broaden the scope of the profile.

@pietercolpaert

[VladimirAlexiev]

@ajnelson-nist At the call today you described this issue in summary as: SHACL talks about RDFS.

• rdfs:Class: mentioned many times, and a rdfs:Class, sh:NodeShape is used as shortcut for sh:targetClass
• rdfs:subClassOf: used to collect sh:targetClass and to check sh:class
• rdf:Property: mentioned many times, but sh:PropertyShape does not depend on it

But OWL uses different constructs.

I think the cleanest way is to require OWL+SHACL ontologies to have dual RDFS+OWL types for their terms.
In fact the following axioms are part of OWL, so this will be automatically satisfied under rdfs:subClassOf reasoning.

owl:Class rdfs:subClassOf rdfs:Class .
owl:DatatypeProperty rdfs:subClassOf rdf:Property .
owl:ObjectProperty rdfs:subClassOf rdf:Property .

[simonstey]

@ajnelson-nist At the call today you described this issue in summary as: SHACL talks about RDFS.

* `rdfs:Class`: mentioned many times, and `a rdfs:Class, sh:NodeShape` is used as shortcut for `sh:targetClass`

* `rdfs:subClassOf`: used to collect `sh:targetClass` and to check `sh:class`

* `rdf:Property`: mentioned many times, but `sh:PropertyShape` does not depend on it

But OWL uses different constructs.

I think the cleanest way is to require OWL+SHACL ontologies to have dual RDFS+OWL types for their terms. In fact the following axioms are part of OWL, so this will be automatically satisfied under rdfs:subClassOf reasoning.

owl:Class rdfs:subClassOf rdfs:Class .
owl:DatatypeProperty rdfs:subClassOf rdf:Property .
owl:ObjectProperty rdfs:subClassOf rdf:Property .

true https://www.w3.org/TR/owl2-rdf-based-semantics/#A_Set_of_Axiomatic_Triples:

owl:Class rdf:type rdfs:Class .
owl:Class rdfs:subClassOf rdfs:Class .

but not all implementations respect that though.. e.g., https://s.zazuko.com/3wib4Wp

@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix testo: <http://ontology.test/> .
@prefix testv: <http://vocabulary.test/> .
@prefix tests: <http://shape.test/> .
@prefix testd: <http://data.test/> .

testo:Party a owl:Class, rdfs:Class, sh:NodeShape ;
	rdfs:label "Party"@en ;
	sh:nodeKind sh:IRI ;
	sh:property [
		sh:path testo:hasContact ;
		sh:nodeKind sh:IRI ;
		sh:class testo:Contact ;
		sh:minCount 1 ;
        sh:maxCount 1 ;
	] .

testo:hasContact a owl:ObjectProperty ;
	rdfs:label "Has Contact"@en .

testo:Contact a owl:Class,sh:NodeShape ;
	rdfs:label "Contact"@en ;
	sh:nodeKind sh:IRI ;
	sh:property [
		sh:path testo:contact ;
		sh:nodeKind sh:Literal ;
		sh:datatype xsd:string ;
		sh:minCount 1 ;
		sh:maxCount 1 ;
	] .

testo:contact a owl:DatatypeProperty ;
	rdfs:label "Contact Code/String"@en .

with

@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix testo: <http://ontology.test/> .
@prefix testv: <http://vocabulary.test/> .
@prefix tests: <http://shape.test/> .
@prefix testd: <http://data.test/> .


## Individuals

testd:e954e11c-8156-42d0-b44a-437598239946 rdf:type testo:Party;
   testo:hasContact testd:c7d80653-05f3-4c96-862a-e2704c4f5d87, testd:39ccc4b1-4426-4bf9-bc54-b0546ab6d951 .

testd:c7d80653-05f3-4c96-862a-e2704c4f5d87  rdf:type testo:Contact.

testd:39ccc4b1-4426-4bf9-bc54-b0546ab6d951  rdf:type testo:Contact ;
  testo:contact "billie@apple.com"^^xsd:string ,"billie2@apple.com"^^xsd:string .

doesn't report violations for testo:Contact as it's only explicitly defined as owl:Class. but I guess that's not our problem but @tpluscode's? ;)

[VladimirAlexiev]

SHACL doesn't require owl:Class rdfs:subClassOf rdfs:Class, so it is not a problem of https://shacl-playground.zazuko.com/.
It is a problem of the user:

• before validating the above, run OWL inference;
• OR use dual typing: testo:Contact a owl:Class, rdfs:Class, sh:NodeShape

[ajnelson-nist]

@VladimirAlexiev and @simonstey : I can't recall where in the OWL docs this is written, but inferencing based on these triples being included in the graph ...

owl:Class rdf:type rdfs:Class .
owl:Class rdfs:subClassOf rdfs:Class .

... does not work within OWL 2 DL. There are expressions needed to define OWL within RDF that OWL disallows in other uses, due to rules OWL made around "reserved" IRIs like owl:Class. A metaclass that subclasses owl:Class, ex:MyMetaClass rdfs:subClassOf owl:Class happens to be disallowed structurally. This was a design decision of OWL, and not intended as a criticism. I remember there's a general phrase like "OWL itself cannot be modeled in OWL; importing the OWL definition graph into an OWL ontology will result in an inconsistent ontology," but the most specific parts of that I can find are "IRIs from the reserved vocabulary other than owl:Thing and owl:Nothing MUST NOT be used to identify classes in an OWL 2 DL ontology" (OWL 2 Syntax, Section 5.1) and "IRIs from the reserved vocabulary MUST NOT be used to identify named individuals in an OWL 2 DL ontology" (Section 5.6.1). In short, owl:Class a owl:Class is true at the gist-of-it level, but formally disallowed.

Hence, a consequence of this modeling restriction is that multi-typing (as @VladimirAlexiev noted a few times in this thread: ex:MyClass a owl:Class, rdfs:Class, sh:NodeShape) is needed for OWL-&-SHACL users. This is why I was noting that sh:ShapeClass wasn't going to be specifically helpful for saving OWL-&-SHACL users redundant-feeling typing triples, over on #212 .

Since @VladimirAlexiev noted ROBOT over on #212 , I'll note its output¹ on an example ontology for the sake of reproducibility w.r.t. this thread and #212 . What I wrote above is my understanding of the meaning behind the below error messages.

Data graph (example.ttl):

@prefix owl: <http://www.w3.org/2002/07/owl#> .
@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#> .

owl:Class a rdfs:Class .
sh:ShapeClass a rdfs:Class ; rdfs:subClassOf owl:Class .

Shell invocation, per documentation at this page:

java -jar robot.jar validate-profile \
  --input example.ttl \
  --profile DL

Output:

OWL 2 DL Profile Report: Ontology and imports closure NOT in profile. The following violations are present:
Use of reserved vocabulary for class IRI: owl:Class [Declaration(Class(owl:Class)) in OntologyID(Anonymous-2)]
Use of reserved vocabulary for class IRI: owl:Class [SubClassOf(<http://www.w3.org/ns/shacl#ShapeClass> owl:Class) in OntologyID(Anonymous-2)]

PROFILE VIOLATION ERROR null violates profile DL
For details see: http://robot.obolibrary.org/validate-profile#profile-violation-error
Use the -vvv option to show the stack trace.
Use the --help option to see usage information.

This working group is not scoped to discuss modeling matters of OWL, so, again, I am trying to be mindful of scope. PR #336 assists current use cases without expanding too much. This is why the file I've uploaded in the accompanying PR is kept separate in import-dependency from other SHACL resources.

Footnotes

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