- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Mon, 21 Mar 2016 22:33:28 +0200
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: Holger Knublauch <holger@topquadrant.com>, RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a3DJyLH=ReFbrsYjXH5NgW7mWT1AUoUc1pjKRXrrBgmrg@mail.gmail.com>
I was always a proponent of not requiring access to the shapes graph. I agree with (1), personally I could also live without (2) but I see that it has some use cases and the WG voted on using it. I tried to add some more details and warnings on the use of $shapesGraph here https://github.com/w3c/data-shapes/commit/460f6aeb3e7bb4cf4f35a63cc5ef17ae8415e776 On Mon, Mar 21, 2016 at 9:39 PM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > 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 > > > > -- Dimitris Kontokostas Department of Computer Science, University of Leipzig & DBpedia Association Projects: http://dbpedia.org, http://rdfunit.aksw.org, http:// http://aligned-project.eu Homepage:http://aksw.org/DimitrisKontokostas Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Monday, 21 March 2016 20:34:24 UTC