Property Shapes without paths

[tpluscode]

Pleas consider this shape, as mentioned in issue zazuko/rdf-validate-shacl#140

@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .
@prefix ex: <http://example.com/> .

ex:PersonAddressShape
    a sh:NodeShape ;
    sh:targetClass schema:Person ;
    sh:property ex:age .

ex:minCount    a sh:PropertyShape ;
        sh:minCount 1 .

ex:age    a sh:PropertyShape ;
        sh:path schema:age ;
        sh:and ( ex:minCount ) .

It seems logical to be able to reuse parts of property shapes like this but this is invalid SHACL, because ex:minCount does not have a sh:path

On the other hand TopBraid's SHACL implementation does support this construct as one would expect.

Should the definition of property shape be relaxed?

[VladimirAlexiev]

@tpluscode and @matthiaspalmer (who was poster of the original issue)

• Isn't and supposed to have at least 2 arguments?
• Seems to me you are using and as a marker to say "... and now incorporate all features of the following, by reference"?
• So it's not just about "relax the definition of property shape" but also about imparting some completely new semantics?
• And what would be the semantics if the piece you want to reuse defines its own sh:path?

ex:minCount    a sh:PropertyShape ;
  sh:path ex:foo;
  sh:minCount 1 

[matthiaspalmer]

@VladimirAlexiev my toughts per point below.

@tpluscode and @matthiaspalmer (who was poster of the original issue)

• Isn't and supposed to have at least 2 arguments?

Don't think so, the range of sh:and is a SHACL List, there is nothing in section 4.6.2 that says it must have 2 arguments.

• Seems to me you are using and as a marker to say "... and now incorporate all features of the following, by reference"?

Yes, exactly, this is what I would like to achieve. i.e. a way of using and would allow you to "extend" property Shapes.

• So it's not just about "relax the definition of property shape" but also about imparting some completely new semantics?

I do not see that this is new semantics, I think this is how sh:and should work. Or am I missing something?

• And what would be the semantics if the piece you want to reuse defines its own sh:path?

ex:minCount    a sh:PropertyShape ;
  sh:path ex:foo;
  sh:minCount 1 

That would a shape expression that is not possible to satisfy, unless ex:foo is a subproperty of ex:age and you validate with entailment enabled.

But "impossible shapes" is not unique to this situation. Just consider a shape with minCount 2 and maxCount 1.

[tpluscode]

Thanks @matthiaspalmer, I never got a reply I was satisfied with but I like your argument about "impossible shapes". You can achieve unsatisfiable shapes in various ways.

Seems to me you are using and as a marker to say "... and now incorporate all features of the following, by reference"?

I'd say that is exactly what and is meant for. Maybe more often used in Node Shapes.

Isn't and supposed to have at least 2 arguments?

The >2 element rule applies to sequence paths. Maybe that's what you thought of @VladimirAlexiev

And what would be the semantics if the piece you want to reuse defines its own sh:path?

Alternatively to what @matthiaspalmer said, the path could be ignored and the constraints incorporated into the parent Property Shape? 🤔

[VladimirAlexiev]

• @tpluscode and @matthiaspalmer I never thought of Unary conjunction. I guess it's needed for logical completeness (even zeroary conjunction, its value is True).
• But how about this requirement "Each member of such list must be a well-formed shape". A PropertyShape without path is not well formed. You want to reuse not property shapes, but only aspects of them
• "I'd say that is exactly what and is meant for. Maybe more often used in Node Shapes": the key difference is that the conjuncts are self-contained shapes, whereas here you propose conjuncts that are partial shapes
• @matthiaspalmer the "new semantics" consists in the need to define how partial shapes are combined and only then evaluated. The spec says "conformance checking of v against any of the members of $and", it doesn't say "members of $and combined in some new way with aspects of the invoking shape".

If you want to reuse aspects of property shapes, I think the right way is to look into Constraint Components?

[tpluscode]

@HolgerKnublauch, could you comment on this scenario being seeming supported by the TB implementation?

[HolgerKnublauch]

The spec states that the behaviour of SHACL engines against malformed shapes graphs is undefined. So if my code does allow these incomplete property shapes without sh:path through then this is officially allowed.

For SHACL 1.2 we could strengthen those cases though and say that a sh:PropertyShape without a sh:path should throw a failure and stop validation.

[VladimirAlexiev]

A PropertyShape without path is not well formed.

Here's the evidence: https://www.w3.org/TR/shacl/#property-shapes

A property shape is a shape in the shapes graph that is the subject of a triple that has sh:path as its predicate.
sh:PropertyShape have one value for the property sh:path.

Property Shapes without sh:path will not even be recognized as such.

[HolgerKnublauch]

@tpluscode can this be closed?

[tpluscode]

Maybe. Are we actioning this in SHACL 1.2 or keep the undefined behaviour when an engine sees a Property Shape without path?

[HolgerKnublauch]

Given the lack of editorial contributions here I am not expecting the WG to do much more on this topic. We are currently raising tickets quicker than they are processed, so I think we need to be realistic and not delay the "more interesting" work on inferencing too much.

[HolgerKnublauch]

Closing for now as explained. Please reopen if you disagree.