- From: Arthur Ryman <arthur.ryman@gmail.com>
- Date: Thu, 29 Oct 2015 16:25:16 -0400
- To: Vladimir Alexiev <vladimir.alexiev@ontotext.com>
- Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Vladimir,
I agree. rdf:List is overkill when the order of the members is not
significant. Using a multi-valued property is much simpler.
-- Arthur
On Fri, Oct 23, 2015 at 9:01 PM, Vladimir Alexiev
<vladimir.alexiev@ontotext.com> 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 *.
> 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 Thursday, 29 October 2015 20:25:44 UTC