Add sh:ShapeClass

[HolgerKnublauch]

Related to #169 SHACL should become more stand-alone and grow up in a formerly OWL-dominated world.

In the dash namespace we have added

dash:ShapeClass
  a dash:ShapeClass ;
  rdfs:comment "A class that is also a node shape. This class can be used as rdf:type instead of the combination of rdfs:Class and sh:NodeShape." ;
  rdfs:label "Shape class" ;
  rdfs:subClassOf rdfs:Class ;
  rdfs:subClassOf sh:NodeShape ;
.

so that classes using implicit class targets can be written with just one rdf:type instead of two:

ex:Person
    a dash:ShapeClass ;
    sh:property ex:Person-birthDate ;
...

instead of

ex:Person
   a rdfs:Class, sh:NodeShape ;
    sh:property ex:Person-birthDate ;
...

This could be leveraged into the sh: namespace as sh:ShapeClass.

[caribouW3]

Discussion Feb 24th: https://www.w3.org/2025/02/24-data-shapes-minutes.html#d570

[ajnelson-nist]

I am concerned that this proposal induces a requirement of SHACL-specific entailment to expose a non-SHACL modeling class that some systems may require to be hard-coded. If this were also trying to simplify owl:Class designations, then my understanding is this would not work with OWL's parsing algorithm. I think there is an analogous situation for general RDF, so I'll discuss the OWL bit briefly in order to come back to general RDF.

Within OWL, my understanding of the parsing algorithm described in this document is that the parsing process happens with no inferencing. Only hard-coded statements are loaded into the parsing algorithm, whether through the initialization, or through following owl:imports, and there is no point to pause and run an inferencing step.

Let's pretend through just the next code block that sh:ShapeClass also had as part of its definition sh:ShapeClass rdfs:subClassOf owl:Class .. This graph would fail to parse by the OWL algorithm (i.e., the graph is not in the OWL2 DL Profile, but instead in OWL FULL), because ex:person-1 is using an IRI that is not explicitly defined as an owl:Class:

ex:Person
    a dash:ShapeClass ;
    .

ex:person-1
    a ex:Person ;
    .

And now I've talked about OWL long enough to come back to general RDF: I don't know whether RDF parsers also in general have the same strictness of "Something in the object position of s rdf:type o must be designated a class." I imagine there's the general fallback of "Well, at least it'll be an rdfs:Resource," so even s rdf:type [] works. But it's not clear to me whether this would be fine to a parser that is not SHACL-aware:

ex:A
    a sh:ShapeClass ;
    .

ex:B
    a sh:ShapeClass ;
    rdfs:subClassOf ex:A ;
    .

I could see this raising a parse error, similar to "non-Class a part of a subclassing declaration".

I'm concerned that this effort to save a type statement through entailment would cause compatibility issues by imposing a requirement of "You need to speak SHACL to load this" on a single graph that mixes SHACL with RDFS modeling and uses sh:ShapeClass.

Meanwhile, coming back to OWL with one last remark - this proposal as written saves no effort for OWL-and-SHACL users, because it does not include sh:shapeClass rdfs:subClassOf owl:Class. Again from my understanding of the OWL parsing algorithm, I don't think that definitional statement would be of any help. So, OWL-and-SHACL users would still need the second rdf:type statement anyway.

[HolgerKnublauch]

Why should a niche technology such as OWL DL with all its well-known flaws and limitations constrain how other languages like SHACL are designed. The design mistakes that you describe are in the layering of OWL 2 on RDF. It is probably already outside of OWL DL when you use the current pattern, which is

ex:MyClass
    a rdfs:Class, sh:NodeShape .

because it uses rdfs:Class instead of owl:Class. SHACL doesn't say anything about owl:Class, and that's good. Maybe there will be an OWL 2.1 that addresses these problems, but it shouldn't be more than a nice-to-have for us here.

I am aware that individuals can veto the decisions by the group. I have done this in the past too. Therefore, can we try to work on a compromise? What about we include an informal comment that explains that in order to be friendly to OWL, you should do X and Y (which could be "don't use rdfs:Class" and "use owl:Class instead"), so that you can live with the current proposal? Or that the WG publishes a separate document on the relationship between SHACL and languages including OWL, which would then also include the variant of the SHACL definitions that you have suggested in #246 ? In general, wouldn't adding a few triples to #246 also address the sh:ShapeClass compatibility?

[ajnelson-nist]

I've apparently caused a distraction: I only meant to use OWL to illustrate a problem I think would occur outside of OWL. I do believe OWL is outside the scope of this proposal for reasons specific to OWL.

The point I wish to emphasize from my long comment is that sh:ShapeClass seems it would impose a requirement of SHACL entailment on non-SHACL RDFS users. A specific demonstration of this concern would be the following graph raising an error in some RDFS-based parser that is not SHACL aware:

ex:A
    a sh:ShapeClass ;
    .

ex:B
    a sh:ShapeClass ;
    rdfs:subClassOf ex:A ;
    .

I'm also not attempting a veto. I lead my comment with "I am concerned that...", and it's up to the group to decide whether my concern is shared.

[HolgerKnublauch]

Wouldn't RDFS entailment infer that ex:A is also an rdfs:Class because rdfs:domain/range of rdfs:subClassOf is rdfs:Class? likewise, the range of rdf:type is rdfs:Class, so as soon as there are instances of a ShapeClass it would be understood to be an rdfs:Class.

In shapes graph that only declare ex:A s sh:ShapeClass, why would an RDFS processor care what this is, as there are no inferences?

[ajnelson-nist]

Wouldn't RDFS entailment infer that ex:A is also an rdfs:Class because rdfs:domain/range of rdfs:subClassOf is rdfs:Class? likewise, the range of rdf:type is rdfs:Class, so as soon as there are instances of a ShapeClass it would be understood to be an rdfs:Class.

RDFS entailment would pick this up today, yes, as those domain and range statements are in RDF 1.1 Semantics, Section 9.

In shapes graph that only declare ex:A a sh:ShapeClass, why would an RDFS processor care what this is, as there are no inferences?

This is a good point to enumerate the constraints of the use case I'm focused on:

1. An RDFS processor,
2. that uses no inferencing,
3. loading a graph with ex:A a sh:ShapeClass as a data or ontology graph (distinction incidentally under discussion in Where should my ontology go? Data graph versus shapes graph #185 , but not a blocker here),
4. also having in the graph some "Class"-y usage of ex:A, whether x rdf:type ex:A or y rdfs:subClassOf ex:A or p rdfs:domain ex:A,
5. and flags "Undefined" (not-structurally-typed) IRIs, e.g. for typo detection or missing-import warnings.

I don't currently think SHACL-awareness is part of this constraints list. And one thing I'm really unaware of is how much point 5 is a concern to others. I've seen point 5 be a noteworthy data quality control matter.

Explaining the no-inferencing bit: I'm aware that there is a friction with full RDFS entailment and JSON-LD use cases. In short, full RDFS entailment causes an issue with serializing data after entailment, because of entailment rule rdfs4b (in 9.2.1 of the Semantics document). You then get statements like true a rdfs:Resource ., which cannot serialize to JSON-LD because the @id key's paired value must be, or expand to, an IRI. (I can't find the specific part of JSON-LD 1.1 that says this, but this exercise on the Playground flags the issue.)

My concern to the original issue, adding sh:ShapeClass, is that anything that induces an entailment requirement induces some burdens, especially on SHACL-unaware users. Full RDFS entailment causes troubles and needs for mitigations for some users, on parsing, validation, or serialization. (We don't need to discuss OWL entailment here - it turns out to be moot for another OWL-specific reason.) A SHACL-level mitigation might be possible by saying only SOME entailment is needed, like I'd described in #219 , but ultimately I think the potential for trouble outweighs the benefit of consolidating type declarations.

[HolgerKnublauch]

@ajnelson-nist thanks for the details and the discussion. I am really trying to understand the exact problem space here.

From your list of pre-conditions, what exactly do you mean with RDFS processor, if inferencing is OFF. Do you mean just some RDF (triples) processor? What sort of algorithm in particular?

Asking because if an RDF processor only knows about RDFS vocabulary, then it wouldn't even understand owl:Class, owl:Restriction etc. without having the extra rdfs:subClassOf triples from the OWL namespace. This would be the exact same solution to support SHACL and sh:ShapeClass, because the sh: namespace graph contains enough triples to make them understandable. This is not different from any other vocabulary IMHO - in order to make sense of SKOS for example, people should owl:import the SKOS namespace, so that they can learn about the property and class definitions, e.g. that skos:Concept is a class at all.

To me, sh:ShapeClass is more than just syntactic sugar. It is a way for SHACL to "grow up" into a self-contained language where ontologies can model almost everything in the sh: namespace only. The syntactic sugar does remain important too, for example in our home-grown ontologies, more than 95% of node shapes are also classes.

[HolgerKnublauch]

@ajnelson-nist as mentioned in the meeting today, we should try to conclude on this topic here on this ticket. See my comment above, I would appreciate if you could point of exact problems, exact interpretation mistakes that RDF processors would make if they only see sh:ShapeClass without its ontological definition. And if they do, is this even a valid argument: the whole point of ontologies is that people should use them to learn about classes. Even in cases like sh:NodeShape a non-SHACL processor wouldn't really understand that sh:NodeShape is an rdfs:Class without the sh graph.