- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sat, 24 Oct 2015 13:25:29 +1000
- To: public-data-shapes-wg@w3.org
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