Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ajnelson-nist opened this issue Feb 13, 2025 · 10 comments · May be fixed by #336
Open

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

ajnelson-nist opened this issue Feb 13, 2025 · 10 comments · May be fixed by #336
Labels
UCR Use Cases and Requirements Vocabularies For issues with the RDF files that the WG maintains

Comments

@ajnelson-nist
Copy link
Contributor

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:

@ajnelson-nist ajnelson-nist added the UCR Use Cases and Requirements label Feb 13, 2025
@tfrancart
Copy link

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
Copy link
Contributor Author

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.

@HolgerKnublauch HolgerKnublauch added the Vocabularies For issues with the RDF files that the WG maintains label Feb 13, 2025
@bergos
Copy link
Contributor

bergos commented Feb 15, 2025

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
Copy link
Contributor

VladimirAlexiev commented Feb 17, 2025

@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
Copy link
Contributor

@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 "[email protected]"^^xsd:string ,"[email protected]"^^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
Copy link
Contributor

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 added a commit that referenced this issue Mar 24, 2025
@ajnelson-nist ajnelson-nist linked a pull request Mar 24, 2025 that will close this issue
2 tasks
@ajnelson-nist
Copy link
Contributor Author

@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 output1 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.

@ajnelson-nist
Copy link
Contributor Author

(Please pardon the closing-opening noise, finger slipped.)

@ajnelson-nist
Copy link
Contributor Author

@bergos : I'm not familiar with the two docs you'd noted. I'm going to enter some possibly-wild speculation - apologies in advance if I'm really far off, and I welcome corrections.

I think the resource in the accompanying PR is best kept at a small impact target: acknowledging as OWL the set of SHACL classes and properties. I mean to have OWL-specific concerns addressable by so-concerned users with a single triple: ex:MyOntologyAndShapes owl:imports <...PR 336's W3C-provided graph...>.. I specifically chose owl:AnnotationProperty to avoid the question of how SHACL concepts would behave as subjects of OWL modeling, as a matter of:

  1. Respecting this working-group's scope, because that's OWL modeling, not SHACL development, and
  2. Avoiding deeper questions of open-world modeling outside of SHACL's closed-world paradigm.

If a project does wish to undergo this exercise, the friction point would be if some interpretation is found for SHACL's rdf:Propertys where it makes sense to devise owl:Restrictions. Such a model, encoded as OWL, would need to include the statement ex:MySHACLOWLModel owl:incompatibleWith <...PR 336's W3C-provided graph...> ..

@ajnelson-nist
Copy link
Contributor Author

PR #336 is open, and its technical contents are being kept synchronized with a separate monitoring repository. I'm NOT planning on inlining the CI into this repository directly, though I don't mind explaining its workflow.1 I'd appreciate feedback on #336 to answer its checklist questions.

The synchronizing mechanism revolves around a SHACL graph that takes shacl12-vocabularies/shacl.ttl and the new-to-#336 shacl-owl.ttl file and cross-checks them with SHACL shapes, only needing SHACL 1.0 syntax.

The issue is, to run in CI on this repository, something would need to run this graph, and do a little pre-processing to concatenate files into a temporary data graph. I'm unaware if W3C lets that kind of CI mechanism be added to working-group documents. It's light enough work that it can run in a separate repository and avoid any technology policy issues. I just have it on cron to run nightly and can file follow-on PRs to vocabulary-adding PRs the morning after their merges.

The review graph is below.

@prefix ex: <http://example.org/sh-shacl-owl-coverage/> .
@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#> .

<http://example.org/sh-shacl-owl-coverage>
	a owl:Ontology ;
	rdfs:comment "A shapes graph to confirm SHACL classes and properties are also cast with OWL types."@en ;
	.

ex:OwlClassIsShaclClassShape
	a sh:NodeShape ;
	sh:class rdfs:Class ;
	sh:targetClass owl:Class ;
	.

ex:OwlPropertyIsShaclPropertyShape
	a sh:NodeShape ;
	sh:class rdf:Property ;
	sh:targetClass owl:AnnotationProperty ;
	.

ex:ShaclClassIsOwlClassShape
	a sh:NodeShape ;
	sh:class owl:Class ;
	sh:targetClass rdfs:Class ;
	.

ex:ShaclPropertyIsOwlPropertyShape
	a sh:NodeShape ;
	sh:class owl:AnnotationProperty ;
	sh:targetClass rdf:Property ;
	.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
UCR Use Cases and Requirements Vocabularies For issues with the RDF files that the WG maintains
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants