- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 13 Oct 2016 09:12:41 -0700
- To: public-data-shapes-wg@w3.org
Support for extension languages other than SPARQL has already been resolved twice: https://www.w3.org/2015/06/11-shapes-minutes.html#resolution03 RESOLUTION: Close ISSUE-60: Shall SHACL support other extension languages beside SPARQL (like JavaScript)? saying yes, even though we may not define any such extension at this point, the design should allow it. https://www.w3.org/2015/05/20-shapes-minutes.html#resolution04 RESOLUTION: Close Issue-45, stating that SHACL shall include SPARQL as an extension language, without making it a required feature for compliance (possibly via profiles) and without implying that SHACL must be implemented in SPARQL kc On 10/13/16 1:41 AM, 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 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 > > > > > 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 > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Thursday, 13 October 2016 16:13:13 UTC