Re: Reopening the discussion on sh:targetShape

Hi Holger!

> The downside of using something like dash:HasValueTarget is that it
doesn't "cover" all possible use cases. Instead of allowing
arbitrary sh:targetShapes we limit this to hasValue patterns.

Indeed, your proposal (is a property & value target) does not satisfy our
requirements (which are for a conjunction of props and disjunction of
values).

I made a proposal that satisfied our requirements (I called it
semanticTarget).

You and others on this list then brainstormed that "it would be nice" to
also support various other shape types (sh:filterShape).
However, sh:filterShape is used with sh:nodes, is based on $this, and is
not at all what we need.

Then I specified using sh:target with a shape. You asked to use a different
prop sh:targetShape which I did.
I wrote a spec that you asked me to change in order to remove examples. I
did.
You pointed that performance may be problematic for some shapes, which I
reflected in a warning.
Then you had second thoughts about those warnings.

Havard implemented sh:targetShape, at least for the case that we need (but
in fact more cases).
We are using it in shapes generated by the Ontotext Platform.
I don't think we're willing to change this any more.

Instead, let's document the cases that work.
I believe that efficient implementations over large data (not in-memory
data) must do special cases for components of interest.
They must know what triple patterns are used by a particular component, so
they can track these patterns efficiently.
SHACL includes "reference implementations" of all components in SPARQL, but
these are not efficient.

> dash:HasValueTarget is a SPARQL-based Target Type
https://w3c.github.io/shacl/shacl-af/#SPARQLTargetType.
> Implementations of SHACL-AF already will do the right thing and will
be able to do so efficiently.

I believe that declaring extensions as SPARQLTargetType
<https://w3c.github.io/shacl/shacl-af/#SPARQLTargetType> is a profitable
idea, IF we can also somehow declare the triple patterns that are involved.
In other words, to "open up" the SPARQL definition so that efficient
implementations can do their own thing.

Cheers!