- From: Holger Knublauch <holger@topquadrant.com>
- Date: Thu, 13 Oct 2016 17:58:21 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
- Message-ID: <46be71e9-9efd-a28d-a996-6a0f2c1e7e32@topquadrant.com>
On 13/10/2016 17:45, Dimitris Kontokostas wrote: > > > On Thu, Oct 13, 2016 at 9:42 AM, Holger Knublauch > <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote: > > > > 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 > <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. > > > There are indeed many things that would be useful to be included in > SHACL and I could come up many examples that are useful but not easily > definable. > I don't want to get into an new big endless thread here, I didn't ask > to remove sh:hasShape, only to make it optional. Making a feature optional basically means it cannot be used reliably. We have too many optional features already because there is always someone who will be against something, or has a specific implementation strategy in mind. Instead of adding further optional features, we should go the opposite way. Engines that don't want to support these features simply should not be allowed to claim SHACL Full compliance, but some smaller dialect. > It is not possible to run this in a remote endpoint so your library > will not work anyway in all cases so, saying it is standard doesn't > actually mean interoperability like it should We had the discussion about remote endpoints several times and our conclusion was that SHACL is not required to work on endpoints. SHACL Full implementers need to, for example, implement user-defined SPARQL functions, which also don't exist on endpoints that are not SHACL aware. There are work-arounds for cases where the endpoint is outside of the control of the engine. > > 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. > > > Are we defining a magic property that switches the current graph? how > will this work? It would simply continue to the use same default query graph like the surrounding query. In any case, use of sh:hasShape outside of SHACL engines is not all that important and we don't need to specify it. Holger >> 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 >> <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 07:59:03 UTC