Treatment of `rdfs:subPropertyOf` like `rdfs:subClassOf`

[ajnelson-nist]

SHACL 1.0 carefully defines support of rdfs:subClassOf in how classes are identified, sought, and reviewed.

However, rdfs:subPropertyOf does not get the same treatment, even though it is possible to have subproperty hierarchies. Searching 1.0's document for "subproperty" returns 0 hits with just the substring "ubp".

This causes SHACL users to need to enable RDFS or OWL entailment as a preprocessing step before their shapes that target with sh:targetSubjectsOf or sh:targetObjectsOf go into effect on properties that are implied through entailment. This can also lead to surprises when turning on entailments suddenly lights up shapes from higher in the subproperty hierarchy.

This example demonstrates what I mean:

@prefix ex: <http://example.org/> .

ex:Class1
	a rdfs:Class ;
	.

ex:Class2
	a rdfs:Class ;
	.

# Property hierarchy is a diamond:
#
#   A
#  / \
# B   C
#  \ /
#   D
#
# So, `ex:a ex:propertyD ex:b .` entails:
#
# `ex:a ex:propertyB ex:b .`
# `ex:a ex:propertyC ex:b .`
# `ex:a ex:propertyA ex:b .`

ex:propertyA
	a rdfs:Property ;
	.

ex:propertyB
	a rdfs:Property ;
	rdfs:subPropertyOf ex:propertyA ;
	.

ex:propertyC
	a rdfs:Property ;
	rdfs:subPropertyOf ex:propertyA ;
	.

ex:propertyD
	a rdfs:Property ;
	rdfs:subPropertyOf
		ex:propertyB ,
		ex:propertyC
		;
	.

ex:propertyB-subjects-shape
	a sh:NodeShape ;
	sh:class ex:Class1 ;
	sh:targetSubjectsOf ex:propertyB ;
	.

ex:propertyC-objects-shape
	a sh:NodeShape ;
	sh:class ex:Class2 ;
	sh:targetObjectsOf ex:propertyC ;
	.

# This triple, with no other supporting data graph, should
# trigger two sh:Violations, due to `ex:a` and `ex:b` not
# having class assignments.
# But with SHACL 1.0, entailment (whether RDFS, OWL, or
# just their rdfs:subPropertyOf expansion rules) is
# necessary.

ex:a
	ex:propertyD ex:b ;
	.

Can SHACL 1.2 include property hierarchy review?

[HolgerKnublauch]

Hi Alex, while rdfs:subClassOf and rdfs:subPropertyOf sound kind-of symmetric in theory, they are practically very very different. With rdfs:subClassOf the impact of algorithms was quite clearly limited to places like sh:class and sh:targetClass. If SHACL engines had to properly support rdfs:subPropertyOf, they would need to do it basically everywhere - in any property constraint, they would also need to walk into subproperties and then combine all values. Even in complex sh:path expressions they would need to do that. It would also become impossible to distinguish directly asserted property values from inferred ones. Edit forms that are based on SHACL would not longer know which triple to assert when sub-properties exist.

Subclassing is also a well-known features from many other mainstream technologies (OO etc) while property hierarchies like rdfs:subPropertyOf are almost unheard of outside of RDFS and OWL. This makes the whole concept harder to understand by newcomers and more difficult to map to other languages.

Users already have the option to activate RDFS inferencing and can consciously do so when they want rdfs:subPropertyOf semantics. I am very much against adding this to the default semantics of SHACL.

[tpluscode]

What about a new type of Property Path? Like [ sh:subPropertyPath rdfs:label ]?

[HolgerKnublauch]

Yes, it could become a node expression if we implement #222 and that would allow users to activate it when needed. Depending on how we define those node expressions, it may not end up in Core though.

[VladimirAlexiev]

• @ajnelson-nist SHACL was very careful to rely only on rdfs:subClassOf reasoning (because it brings modularity), not any other part of RDFS. If you like subPropertyOf reasoning, how about domain/range reasoning?
• @HolgerKnublauch I'm also against adding subPropertyOf reasoning
• @tpluscode Isn't what you propose just the same as [sh:oneOrMorePath rdfs:label] (spelling of the sh prop not checked).
  Reasoners and entailment regimes either have subPropertyOf reasoning or don't: you can't select it per-property.

[tpluscode]

• Isn't what you propose just the same as [sh:oneOrMorePath rdfs:label]

This translates to ?focusNode rdfs:label+ ?o.

I had in mind the equivalent of

?prop rdfs:subPropertyOf rdfs:label .
?focusNode ?prop ?o .

[ajnelson-nist]

• @ajnelson-nist SHACL was very careful to rely only on rdfs:subClassOf reasoning (because it brings modularity), not any other part of RDFS. If you like subPropertyOf reasoning, how about domain/range reasoning?
• @HolgerKnublauch I'm also against adding subPropertyOf reasoning
  [SNIP - discussed already]
  Reasoners and entailment regimes either have subPropertyOf reasoning or don't: you can't select it per-property.

@VladimirAlexiev : I see your point, if intended, on getting into cherry-picking parts of RDFS entailment. If this Issue were accepted and subPropertyOf entailment became baked in, shouldn't domain & range entailment become baked in too.

Going the other way, to me it's a strange middle ground from the perspective of RDF modeling that only one "sub" modeling element became baked in. Why respect rdfs:subClassOf instead of implementing a sh:subShape parallel hierarchy system for sh:NodeShapes? The argument to use the class hierarchy that's already there is a really easy one for me to accept. But why just the one part of RDFS (and coincidentally, OWL) entailment?

A point of the last two paragraphs together: There may be an argument whether SHACL is already on the slippery slope of entailment or not.

I see @HolgerKnublauch 's point that subproperty hierarchies are special to RDF and don't necessarily translate well to other modeling languages. On the other hand, SHACL is an RDF-based language with a ...primary? Principal? use case for reviewing RDF data.

I'm not quite sure I see Holger's issue about forms. For forms, I imagine that's because I don't have a mental muscle built up on building forms. I'm willing to contingently accept experience's conclusion there; we'll see if I find time to tinker and independently confirm. FWIW, this pushback-thread feels tied to #168 .

On the potential confusion around sh:path: I thought briefly there could be some kind of compromise to have the effects for RDFS entailment be just on sh:targetObjectsOf and sh:targetSubjectsOf, but, no, an example helped. Here's an example to make someone's point. Maybe multiple people's. It'll definitely cover one of Holger's.

Suppose my example graph from above also had the below graph.

ex:Class3
	a rdfs:Class, sh:NodeShape ;
	sh:targetClass ex:Class3 ;
	sh:property [
		sh:minCount 1 ;
		sh:path ex:propertyA ;
	] ;
	.

ex:thing-1
	a ex:Class3 ;
	ex:propertyB ex:thing-2 ;
	.

The full graph, with RDFS entailment, passes SHACL validation. Without RDFS entailment, ex:thing-1 doesn't validate in SHACL 1.0. Is this the operational requirement SHACL should maintain? Is this quietly a requirement that any model using rdfs:subPropertyOf will be required to enable RDFS or OWL entailment for SHACL to work?

I think the resolution of this discussion is closely tied with #168 . If there's a "Direct" targeting property, and a "Hierarchy-respecting" targeting property, then maybe there's a solution other than baking in the subproperty hierarchy like subclasses.

[HolgerKnublauch]

@ajnelson-nist we will have to disagree on that but my (strong) personal opinion on the RDF stack is that RDF Schema and in particular OWL were "wrong turns" that, in retrospect, should not have happened. Despite the enthusiasm and good intentions of the RDF Schema and OWL designers, RDF-based graph technology would by now be far more successful if RDF Schema had followed a more mainstream design, with closed world semantics and traditional handling of domains and ranges. And yes, my statement is based on 20+ years of wrestling with customers and users who even in 2025 misunderstand how rdfs:domain and range operate, and still naturally try to apply their OO-style thinking to semantic web technology.

Doing too much inferencing is also killing performance. Subclass inheritance is built into many mainstream languages, subproperty inheritance or domain/range inference are definitely not.

But the situation is what it is, namely that RDF Schema and OWL have been there long before, so there is now a considerable body of ontologies and matching instance data. Some of these ontologies are sophisticated and really do use OWL semantics to the full extent, but the vast majority are simply class and property declarations with simple axioms. It would be a shame to reinvent the basic structure of those simple ontologies which is why SHACL reuses some terms including rdfs:subClassOf and owl:imports. This is an entirely practical consideration and not a bow to appreciate how RDF Schema and OWL have been designed. The good thing is that most instance data can be shared regardless of whether someone has modeled them against an RDF Schema or a SHACL ontology.

To be perfectly honest though, it is my hope that we can move SHACL forward without artificially keeping stillborn technologies alive. Design mistakes from previous semantic web standards should not be propagated further into SHACL.

In any case, those users that require or want RDFS or OWL inferencing can "activate" that through sh:entailment triples. That should suffice IMHO.

[VladimirAlexiev]

I'm not quite sure I see Holger's issue about forms.

SHACL UI generation is a major topic. TQ is still the leading software, but there are others working on it (see "awesome semantic shapes").
On a form to edit objects of class A you need to display all props attached to A (through its applicable NodeShape and PropertyShapes).
If you involve inferred props:

• should it be editable? why not?
• the UI generator needs to include inference to display inferred values
• if it's inferred from several subprops, you need to deduplicate values
• you need truth maintenance:
  • if a value was inferred from a subprop, then the subprop value deleted: you should delete the inferred value
  • if a value was added directly by the user, then also inferred from a subprop, then the subprop value deleted: you should keep the explicit value

It's a nightmare.
In retrospect, I wonder how TQ implements "area = width * height": I'd guess by forbidding direct entry of "area".

Is this quietly a requirement that any model using rdfs:subPropertyOf will be required to enable RDFS or OWL entailment for SHACL to work?

Many ontologies use rdfs:subPropertyOf. Whether it is useful in a particular KG (I mean useful for querying), is a matter of competency questions.
If it is useful, the KG builder should enable subproperty reasoning, independent of any validation.
IMHO it doesn't make sense to validate a KG with some reasoning but consume it without such reasoning.

In other words, reasoning/entailment is an orthogonal issue to validation. Keeping them apart is a good policy (separation of concerns).
SHACL relies on subclass reasoning because it saw it as the easiest and most natural way to implement modularity.
That cannot be used as an argument that SHACL should implement various other kinds of reasoning.

[HolgerKnublauch]

In retrospect, I wonder how TQ implements "area = width * height": I'd guess by forbidding direct entry of "area".

Yes, inferred properties (backed by a sh:values rule) are read-only.