- From: Holger Knublauch <holger@topquadrant.com>
- Date: Thu, 13 Oct 2016 19:38:03 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
- Message-ID: <1ebfb69f-f76f-38dd-7ac5-1b3385cd6d0f@topquadrant.com>
On 13/10/2016 18:41, Dimitris Kontokostas wrote: > > > On Thu, Oct 13, 2016 at 10:58 AM, Holger Knublauch > <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote: > > > > 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. > > > > In that case, SHACL Full can only be implemented by SPARQL Engines and > there is no way for a library like e.g. RDFUnit to reuse the > implementation of sh:hasShape of another engine and run constraints. I cannot follow this train of thought. sh:hasShape is only relevant if a SPARQL-based constraint or constraint component uses it somewhere in a SPARQL query. The interface of the sh:hasShape function is standard, so "my" implementation would have the same contract as "your" implementation. In the absolute worst case, your implementation can detect queries that use sh:hasShape, and then make sure they are executed under the control of your own engine and not sent to a remote endpoint. > > I guess this limits the maximum number of SHACL Full implementations > to like 4-5? > I definitely do not like this but can accept it if the WG wants to go > this way RDFUnit was designed before SHACL was even started. While I believe we should aim at lowering the implementation burden, I don't think you can expect SHACL to be limited due to design limitations of a particular implementation. That would be short-sighted. Instead of trying to influent the standard, I would much rather spend time understanding why this issue is so problematic to you, because (like recursion) this is a topic that you raise and re-raise. Feel free to send me technical details if you think this topic may get out of hand for the mailing list. But from my native point of view, a function such as sh:hasShape is comparably easy to add to a SPARQL engine such as Jena. Holger > > 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 >> <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 09:38:39 UTC