Re: Reopening the discussion on sh:targetShape

On 7/07/2020 17:28, Vladimir Alexiev wrote:

> Initially I specified exactly the cases that we need (semanticTarget).
>
> Then you and others suggested we generalize to filterShape (which 
> however is not applicable) so we arrived at targetShape.
>
> We've implemented targetShape for the cases that are useful to us. It 
> has undeniably useful applications
> - iterative checking
> - checking of shapes by triple pattern (hasValuesIn and the like)
The same applies to the solution based on SPARQL targets. Note that 
SPARQL targets can be executed both as SELECT and ASK queries (as 
outlined in the last paragraph in the SHACL-AF spec 
https://w3c.github.io/shacl/shacl-af/#SPARQLTarget). This means it can 
also be used for iterative checking. And of course direct triple pattern 
look-up. With a well-defined URI such as dash:HasValueTarget you can 
also just hard-code that case to avoid any SPARQL. This requires no 
changes to any spec.
>
> This is a useful interface to generalized targets. It's more useful 
> than SPARQL targets, which are opaque and cannot be tracked 
> efficiently unless the sparql is parsed.
>
> I've documented the performance considerations (user beware). Its up 
> to the user to use it wisely.
>
> Irene, I don't think it's constructive to challenge a useful 
> implemented feature, especially after people on this list led me to 
> generalize it. Sorry, I don't buy your argument that your reopening 
> this question is somehow better that that logician's objections.
I am not happy that I had to retract my earlier recommendation either 
and sorry if you end up having wasted time on the PR. Things go through 
iterations and implementations, so the PR has at least informed our 
discussion well. Feel free to look through the history of the original 
shapes WG to see how many times things have been changed over and over 
again, only to be eventually dropped (like sh:filterShape which was in 
the drafts for several months). Compromises all over the place.
>
> If you can't accept it in the shacl-af spec then let's move it to the 
> dash spec, if Holger can assure us he'll accept it. Nobody wants yet 
> another "ontoshapes" namespace/spec...

This would have similar implications for me, as I would still need to 
support it in TopBraid.

HasValueTarget solves the main use cases that I see. Maybe it boils down 
to the question which other use cases you *really* require here, and 
which were rather nice-to-haves that emerged once we thought about 
generalizing the approach?

Holger