- 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