- From: Holger Knublauch <holger@topquadrant.com>
- Date: Thu, 13 Oct 2016 16:42:45 +1000
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
- Message-ID: <2809285a-c8e8-b6be-e458-587805f7b7d8@topquadrant.com>
On 13/10/2016 16:23, Dimitris Kontokostas wrote: > > > On Thu, Oct 13, 2016 at 8:11 AM, Holger Knublauch > <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote: > > > > On 13/10/2016 15:05, Dimitris Kontokostas wrote: >> >> >> On Thu, Oct 13, 2016 at 4:07 AM, Holger Knublauch >> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote: >> >> I was asked to prepare a possible resolution to close ISSUE-131. >> >> This ticket was raised by Peter in March and a lot of changes >> were made in the meantime. I believe his original questions >> have either been addressed directly or have become redundant >> due to other changes: >> >> - the function no longer uses the team "type" anywhere (we >> now use Node kind in the parameters table) >> - the handling of recursion is left unspecified, as we had >> agreed to do in another resolution. However, we do state that >> a SPARQL error may be returned if infinite recursion is >> encountered. >> - there is (and never was) a need to pass bindings through >> sh:hasShape function >> - the third argument has been (recently) removed, to avoid >> the question of whether the shapes graph can be accessed via >> a URI in a dataset or not. >> >> >> This is actually not correct, sh:hasShape takes 2 arguments, a >> node from the data graph (focus node) and a node from the shapes >> graph (shape) and checks if the focus node validates against the >> shape. > > You may have misread my statement above. All I said is that we > avoid the question of whether the shapes graph is reachable via a > URI or not. This is orthogonal to the question of whether (during > the execution of sh:hasShape) access to the shapes graph is needed > or not. In fact, the situation with regards to ?shapesGraph as a > variable is not affected by any of this, and it remains optional. > Engines can still decide to implement sh:hasShape without > requiring access to the shapes graph. > > > The issue is about sh:hasShape being ill-defined and I comment on this > point > > Maybe I am mistaken but we decided from the very beginning that for > SHACL Full, access to the shapes graph will not be required and this > was the reason that ?shapesGraph became an optional feature. Agreed. > I argue that sh:hasShape needs access to the shapes graph and > implicitly overrides a previous resolution Where does sh:hasShape require access to the shapes graph? > > Other than that, the fact that we removed the ?shapesGraph aargument > from sh:hasShape makes the function much less usable. > It is less usable because now it can only called by the SPARQL/SHACL > engine only and not by users who could provide the shapes graph > externally. > from my pov, If there was some user value in this function it is now > gone completely and turned into an implementation specific function only. I strongly disagree and have use cases to prove that it remains valuable. A built-in constraint component of our library (dash:memberShape) uses sh:hasShape in its body: http://datashapes.org/constraints.html#MemberShapeConstraintComponent It couldn't be implemented without this function. It also couldn't be implemented as part of a standard library if sh:hasShape were made optional. For people using sh:hasShape outside of an executing SHACL engine, the shapes graph can simply be assumed to be the current query graph. This remains to be very useful. > > so my proposal says the same, make sh:shapesGraph optional and to make > it more usefull, put back the ?shapesGraph argument If we put back the ?shapesGraph argument then we re-add problems that Peter has pointed out, for example that there may not be a named URI for that shapes graph to begin with, and that it makes sh:hasShape appear to depend on the shapes graph, which it doesn't. Holger >> It is obvious that access to the shapes graph is required to >> perform the validation. >> Before we had an extra argument to specify externally the shapes >> graph, even if that is now gone it is still needed and provided >> implicitely by the engine. >> >> Since access to the shapes graph is optional my proposal is to >> make sh:hasShape optional as well > > See above, I believe you are mixing two unrelated topics. > > Holger > > >> - the overall terminology has been cleaned up, using defined >> terms such as "failure" with hyperlinks >> >> PROPOSAL: Close ISSUE-131 as addressed, see Holger's email >> (this email). >> >> Holger >> >> >> >> >> >> -- >> Dimitris Kontokostas >> Department of Computer Science, University of Leipzig & DBpedia >> Association >> Projects: http://dbpedia.org, http://rdfunit.aksw.org, >> http://aligned-project.eu >> Homepage: http://aksw.org/DimitrisKontokostas >> <http://aksw.org/DimitrisKontokostas> >> Research Group: AKSW/KILT http://aksw.org/Groups/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://aligned-project.eu > Homepage: http://aksw.org/DimitrisKontokostas > Research Group: AKSW/KILT http://aksw.org/Groups/KILT >
Received on Thursday, 13 October 2016 06:43:17 UTC