Re: ISSUE-131: Proposal to close

On Thu, Oct 13, 2016 at 10:58 AM, Holger Knublauch <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>
> 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.
>
>
> 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
>>> 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
>
>
>


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