Re: sh:sourceShape points to blank PropertyShape

I believe the current behaviour makes sense and would be too hard to change without breaking implementations anyway. In general I would recommend using URIs for property shapes, and we use blank node only in demo scenarios. URIs not only simplify the problem here but also allow other graphs to reuse or deactivate them.

Keep in mind that property shapes may have their own target declaration and therefore be executed without any surrounding node shape.

There is also an implicit assumption that for most applications, the blank node runtime object can be used to access the original node in the shapes graph. This seems to be also the case in your environment because you can use SPARQL to post-process the results. Given this, I don’t exactly understand what problem you are seeing with the current design.

The situation is different for more complicating expressions that use nested shapes. For example if one component of a sh:and constraint would fail, the violation is reported for the shape owning the sh:and. However, sh:details could be provided by the engine to point at the specific sub-shape.

Holger


> On 19 Feb 2022, at 9:37 am, Vladimir Alexiev <vladimir.alexiev@ontotext.com> wrote:
> 
> In our case we don't share prop shapes between node shapes.
> And the metadata is always at the node shapes .
> It helps to have named prop shapes, to understand what's happening eg in the Playground . But fir or case we'r have to get to the node shape
> 
> On Fri, Feb 18, 2022, 23:31 Mark van Berkel <mark@schemaapp.com <mailto:mark@schemaapp.com>> wrote:
> Hi,
> 
> We wanted to do something similar, and ended up switching to use named nodes to facilitate this. Named nodes might provided for reuse opportunities as well. 
> 
> Regards
> Mark
> 
> On Fri., Feb. 18, 2022, 10:03 Vladimir Alexiev, <vladimir.alexiev@ontotext.com <mailto:vladimir.alexiev@ontotext.com>> wrote:
> Hi! We have a bunch of rules (NodeShapes) with a lot of metadata in them.
> We want ValidationResults to point to those shapes, so we can display the metadata along with the node and value to blame.
> Our rules are often implemented as a single sh:property, and sometimes with sh:and, sh:or, sh:node.
> 
> We find with both TQ SHACL and RDF4J SHACL that sh:sourceShape is set to the PropertyShape, which in our case is a blank node.
> For example:
> 
> <sh1> a sh:NodeShape;
>   sh:target...
>   sh:property [sh:path ...; ...]. <<< set to this blank-node PropertyShape
> 
> <sh2> a sh:NodeShape;
>   sh:target...
>   sh:not [sh:property [sh:path ...; ...]]. <<< set to the NodeShape
> 
> Paradoxically, results from the more complicated shape sh2 ends up pointing to the right node, whereas the simpler shape sh1 points to a blank node.
> 
> What we do is post-process the validation results to redirect sh:sourceShape to the right node, eg:
> 
> delete {?x sh:sourceShape ?propShape}
> insert {?x sh:sourceShape ?nodeShape}
> where {
>   ?x sh:sourceShape ?propShape
>   filter(isBlank(?propShape))
>   filter exists {?propShape sh:path []}
>   ?propShape ^sh:property ?nodeShape
> }
> 
> However, shouldn't the spec lay down some rules that sh:sourceShape is redirected "upwards" from blank-node PropertyShape?
> 
> --
> Vladimir Alexiev, PhD, PMP
> Chief Data Architect
> Sirma AI, trading as Ontotext: https://www.ontotext.com <https://www.ontotext.com/>, LinkedIn, Twitter, Rate GraphDB
> Email: vladimir.alexiev@ontotext.com <mailto:vladimir.alexiev@ontotext.com>, skype:valexiev1
> Mobile: +359 888 568 132, SMS: 359888568132@sms.mtel.net <mailto:359888568132@sms.mtel.net>
> Calendar: https://www.google.com/calendar/embed?src=vladimir.alexiev@ontotext.com <https://www.google.com/calendar/embed?src=vladimir.alexiev@ontotext.com>
> Publications and CV: https://github.com/VladimirAlexiev/my <https://github.com/VladimirAlexiev/my>