why use rdf:List?

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 *. 
It's related to this:
  ?x ex:prop* ?x
matches EVERY resource in the repo for ANY ex:prop.

AFAIK, order in all (most?) of these constructs is unimportant. 
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 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?
Or if we avoid rdf:List unrolling using my approach, would that help?

Received on Saturday, 24 October 2015 01:01:37 UTC