Re: ISSUE-131: Proposal to close

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