Re: ISSUE-131: Proposal to close

On Thu, Oct 13, 2016 at 9:42 AM, Holger Knublauch <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>
> wrote:
>
>>
>>
>> On 13/10/2016 15:05, Dimitris Kontokostas wrote:
>>
>>
>>
>> On Thu, Oct 13, 2016 at 4:07 AM, Holger Knublauch <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.
>

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.
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


> 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?

> 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
>> 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://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://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT