- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Mon, 21 Mar 2016 12:39:39 -0700
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: Holger Knublauch <holger@topquadrant.com>, RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
My understanding is that access to the shapes graph during query execution time is only needed at first glance to handle extension constructs like GRAPH $shapesGraph .... It can be convenient to use this construct in extension code so as to permit the investigation of triples in the shapes graph. This can be used, for example, in the implementation of sh:classIn. However, other implementation methods are possible as you can attest to. There are then two questions: 1/ Is there some portion of the core of SHACL where access to the shapes graph is needed at query execution time? The answer to this is no. Our two implementations are partial evidence for this answer. 2/ Are there things that can be done with this access in the SPARQL extension that cannot be done without it? The answer to this is probably yes in some sense but probably no in another. Access to the shapes graph during query execution allows the queries to pick up arbitrary information from the shapes graph, thus the yes answer. However, if there are only a few useful things do be done on the shapes graph then each of them can probably be set up before query execution, thus the no answer. For example, for constructs that have lists as arguments it is convenient to just query the shapes graph to get the elements of the list. However, it is also possible at query preparation time to grab the elements of the list and send them into the query. This can be done in several ways, including via a VALUES construct and via looping control in the query engine. peter On 03/21/2016 12:21 PM, Dimitris Kontokostas wrote: > > > On Mon, Mar 21, 2016 at 7:56 PM, Peter F. Patel-Schneider > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote: > > The spec draft currently says > > The definition of some constraints requires or is simplified through access to > the shapes graph during query execution. SHACL validation engines MAY prebind > the variable $shapesGraph to provide access to the shapes graph. > > > I wrote it that way but I placed the *requires* not for core but for the > SPARQL extension mechanism. > I thought that some complicated sparql user constraint could require access to > the shapes graph. > Isn't this one of the reason we allowed $shapesGraph? to enable some use cases > that cannot be handled otherwise? > > But for me it is fine to change it to "The definition of some constraints is > simplified through access to the shapes graph during query execution..." > > > > This indicates that some constraints require access to the shapes graph during > query execution. > > The resolution of ISSUE-47, at > https://www.w3.org/2016/02/18-shapes-minutes.html#resolution02, indicates that > access to the shapes graph during query execution is an optional feature. The > SHACL spec needs to ensure that all constraints that need access to the shapes > graph are optional. The SHACL spec should go further and be very clear that > access to the shapes graph is indeed optional and all all constraints that > need access to the shapes graph are optional. > > > Right now most of the core constraint definitions use the $shapesGraph variable, > are you suggesting that we change all these definitions or make them optional? > > > > peter > > > On 03/21/2016 04:12 AM, Dimitris Kontokostas wrote: > > Found it, https://www.w3.org/2015/08/27-shapes-minutes.html#resolution03 > > the resolution does not say this but iirc the discussion (which is not 100% > > scribed) was talking about bnodes and how they can be identified with a remote > > call vs in-memory. > > ARQ and Sesame do something clever with bnodes which is not the case for all > > sparql engines but I am not trying to re-open the old issue, only trying to > > close this one using that resolution > > > > I propose we close this issue as: SHACL does not assume that the data graph is > > an RDF dataset as addressed by the current editor's draft > > This of course allows people to use datasets but SHACL doesn't take any > > special care in this case > > > > > > On Mon, Mar 21, 2016 at 12:59 AM, Holger Knublauch <holger@topquadrant.com <mailto:holger@topquadrant.com> > > <mailto:holger@topquadrant.com <mailto:holger@topquadrant.com>>> wrote: > > > > On 18/03/2016 18:38, Dimitris Kontokostas wrote: > >> > >> On Fri, Mar 18, 2016 at 9:41 AM, Peter F. Patel-Schneider > >> <<mailto:pfpschneider@gmail.com > <mailto:pfpschneider@gmail.com>>pfpschneider@gmail.com > <mailto:pfpschneider@gmail.com> > >> <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>> wrote: > >> > >> If it is always possible to construct the dataset, then I don't see > >> a problem > >> either. However, is this always possible? For example, a user who > >> is just > >> trying to validate a graph may not have permissions to create or > >> modify a dataset. > >> > >> > >> iirc there was a resolution on supporting only in-memory validation (not > >> my favorite and cannot find it), e.g. full shacl may not run on remote > >> datasets e.g. sparql endpoints. > >> With this in mind an implementation could just copy the shapes & data > >> graph in memory and perform the validation there > > > > The resolution that we made a while ago was to not require support for the > > SPARQL endpoint protocol. Note that this is different from the question of > > in-memory vs database. It means that implementations can still work > > against databases, e.g. via an API such as ARQ or Sesame (for which all > > major databases provide drivers for), while the SPARQL endpoint protocol > > is too limiting for what SHACL needs to do. > > > > Holger > > > > > > > > > > -- > > Dimitris Kontokostas > > Department of Computer Science, University of Leipzig & DBpedia Association > > Projects: http://dbpedia.org, http://rdfunit.aksw.org, > > http://http://aligned-project.eu <http://aligned-project.eu/> > > Homepage:http://aksw.org/DimitrisKontokostas > > Research Group: AKSW/KILT http://aksw.org/Groups/KILT > > > > > > > -- > Dimitris Kontokostas > Department of Computer Science, University of Leipzig & DBpedia Association > Projects: http://dbpedia.org, http://rdfunit.aksw.org, > http://http://aligned-project.eu <http://aligned-project.eu/> > Homepage:http://aksw.org/DimitrisKontokostas > Research Group: AKSW/KILT http://aksw.org/Groups/KILT >
Received on Monday, 21 March 2016 19:40:09 UTC