- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 6 Jul 2016 09:50:16 -0700
- To: james anderson <james@dydra.com>, public-sparql-exists@w3.org
On 07/06/2016 09:40 AM, james anderson wrote: > >> On 2016-07-06, at 18:22, Peter F. Patel-Schneider <pfpschneider@gmail.com >> <mailto:pfpschneider@gmail.com>> wrote: >> >> SHACL, the in-progress result of the W3C Data Shapes Working Group with >> Editors' draft at http://w3c.github.io/data-shapes/shacl/, depends on EXISTS >> in several ways. >> >> The most prominent is that SHACL has basic graph patterns inside EXISTS that >> need to work correctly if a filter variable is mapped to a blank node. For >> example, >> SELECT $this ($this AS ?subject) $predicate (?value AS ?object) >> WHERE { >> $this $predicate ?value . >> FILTER NOT EXISTS { ?value rdf:type/rdfs:subClassOf* $class } . >> } > > this reads as if it corresponds to "problem 3” from the "catalog of problems > with EXISTS”. > is that true? That is correct. >> […] However, SHACL doesn't here >> dictate how EXISTS should work, SHACL just needs EXISTS to work. […] > > is it possible to characterize, as examples, any other cases where a > particular behaviour was expected, but not observed. There are very few examples of SHACL shapes written that directly use user-written SPARQL queries so I don't know of any situations here where expectations were violated. >> The most important in my view, however, is that SHACL centrally uses >> pre-binding, i.e., evaluating SPARQL queries with variables "pre-bound" to >> values. In the above query the variables using $ are all pre-bound. > > to my understanding, as this group has been described by andy seaborne, that > topic is not in its scope. It may not be in scope for this group to come up with a definition of pre-binding. That is, however, not particularly relevant here. The W3C Data Shapes Working Group needs to come up with a definition of pre-binding. The first attempt was modelled off the definition of EXISTS in the SPARQL spec. The current attempt has its own problems. It may be modelled off some definition of prepared queries in some SPARQL implementation. If this group comes up with a fixed definition of EXISTS then my guess is that that definition will end up being used as the basis for pre-binding in SHACL. My hope is that either concurrently or subsequently the definitions of prepared queries and related notions in SPARQL implementations will also be based on the fixed definition of EXISTS. Right now the definitions of prepared queries and related notions in SPARQL implementations are what might be very charitably called insufficient. peter >> Begin forwarded message: >> >> *From: *Andy Seaborne <andy@apache.org <mailto:andy@apache.org>> >> *Subject: **Re: Improving EXISTS* >> *Date: *2016-06-29 17:12:51 CEST >> *To: *public-rdf-tests@w3.org <mailto:public-rdf-tests@w3.org> >> *Resent-From: *public-rdf-tests@w3.org <mailto:public-rdf-tests@w3.org> >> >> On 26/06/16 13:07, james anderson wrote: >>> >>> - request parameters are a de facto requirement, as they were >>> established by sesame and now users expect them. >>> if there is to be an effort to ratify a standard behaviour, that >>> deserves a group of its own, independent of any concern for shapes >>> and/or exists. >> >> Certainly useful and important. >> >> My preference is for a quite tightly focused CG mainly so it knows when it's >> finished and we can see if the approach of using CG's is viable. The biggest >> factor I see is lack of people's time. >> >> There is nothing to preclude another one. Nor of making a proposal to >> public-sparql-dev@w3. There choices for protocol-parametrized queries such >> as it just one set of name/values injected or a table of? > > best regards, from berlin, > > > > > --- > james anderson | james@dydra.com <mailto:james@dydra.com> | http://dydra.com > > > > >
Received on Wednesday, 6 July 2016 16:50:53 UTC