Re: ISSUE-131: Proposal to close

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.
I argue that sh:hasShape needs access to the shapes graph and implicitly
overrides a previous resolution

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.

so my proposal says the same, make sh:shapesGraph optional and to make it
more usefull, put back the ?shapesGraph argument


> 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