Re: why use rdf:List?

Hi Vladimir,

thanks for the feedback - it is great to have people evaluate the spec 
at this level of detail.

On 10/24/2015 11:01, Vladimir Alexiev wrote:
> sh:AndConstraint and many other constructs use rdf:List, e.g.:
>
>    ex:sh a sh:AndConstraint;
>      sh:shapes (ex:sh1 ex:sh2).
>
> This is implemented by unrolling the list with a property path expression,
> e.g.
>     GRAPH $shapesGraph {
>        $shapes rdf:rest*/rdf:first ?shape
>     }
>
> But Sesame (and maybe some other SPARQL processors) have a problem
> implementing *.

Is this a problem with the current version of Sesame, too? I believe the 
mechanism above is a well-established pattern for list traversal in 
SPARQL, that should work with any SPARQL 1.1 processor.

> It's related to this:
>    ?x ex:prop* ?x
> matches EVERY resource in the repo for ANY ex:prop.

But the variable $shapes already has a value, so it should not traverse 
every triple involving rdf:rest.

>
> AFAIK, order in all (most?) of these constructs is unimportant.

Yes, in terms of semantics that order is unimportant, and we had lengthy 
discussions on this topic within the WG. There is however a (small) 
syntactic advantage of being able to preserve the order as it was 
entered by a user.

> E.g. reading the semantics of AndConstraint it seems full evaluation is
> required (all violations to be returned), no short-cutting.
> RDF is naturally multi-valued, so why can't the constraint be expressed like
> this:
>
>    ex:sh a sh:AndConstraint;
>      sh:shapes ex:sh1, ex:sh2.
>
> And implemented like that:
>
>     GRAPH $shapesGraph {
>        $andShape sh:shapes ?shape
>     }
>
> That's both more economical and more efficient.

I believe the discussion is at this stage unnecessary, because we have 
an open ISSUE-103 to simplify the syntax that (if approved) would change 
the syntax to

ex:sh
     sh:constraint [
         sh:and ( ex:sh1 ex:sh2 )
     ] .

Above, the sh:and would be one property among many others at the same 
node, and I see no efficient alternative to having a list there. We 
could theoretically insert an intermediate blank node, but then the 
syntax gets complicating again.

>
> --
>
> I also have a question:
> Holger wrote that $shapesGraph needs to be passed around, because it's used
> in the rdf:List unrolling.
> I can't quite grok why: in the absence of GRAPH, shouldn't it consult all
> graphs?

The design of SHACL is making no guarantee that the shape definitions 
are visible as part of the default query graph. A SHACL engine takes two 
graphs as arguments: the data graph and the shapes graph. Both might be 
identical, and in many cases they will be, but this is not always the 
case. Therefore, to make sure that the triples from the shape 
definitions are present, we need to switch to the $shapesGraph graph. Is 
this explanation clear enough?

Regards,
Holger

> Or if we avoid rdf:List unrolling using my approach, would that help?
>
>

Received on Saturday, 24 October 2015 03:26:07 UTC