W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > September 2016

Re: on access to the shapes graph in SHACL

From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Date: Mon, 26 Sep 2016 11:06:28 +0300
Message-ID: <CA+u4+a2m9jcCKKUdbmo6bR178Y1rC7m9OaFDz-QYo-cfUSQvSg@mail.gmail.com>
To: Holger Knublauch <holger@topquadrant.com>
Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, "public-rdf-sha." <public-rdf-shapes@w3.org>
I was also never in favour of sh:hasShape, I think it brings many problems
while trying to solve some

Maybe Andy and Ted (as SPARQL engine implementors) are more suited to say
their opinions on the need of sh:hasShape


On Mon, Sep 26, 2016 at 9:57 AM, Holger Knublauch <holger@topquadrant.com>

> The idea is that the SHACL engine would already have the "pointer" to the
> shapes graph, and will reuse that to pre-bind the $shapesGraph variable if
> it needs to. In other words, the parameter would be implicit.
> Holger
> On 26/09/2016 16:49, Peter F. Patel-Schneider wrote:
>> I don't think that this follows unless sh:hasShape can be fully
>> implemented
>> when there is no access to the shapes graph.
>> peter
>> On 09/25/2016 11:38 PM, Holger Knublauch wrote:
>>> I have attached this as a comment to ISSUE-131, which is still open. I
>>> believe
>>> we can delete the shapesGraph argument from sh:hasShape and treat it as
>>> implicitly known to the engine. This should then resolve your concern
>>> here.
>>> Holger
>>> On 24/09/2016 3:12, Peter F. Patel-Schneider wrote:
>>>> Following up one of the recent responses to my comments on Shapes
>>>> Constraint
>>>> Language (SHACL) lead me to look at how access to the shapes graph
>>>> works in
>>>> Shapes Constraint Language (SHACL), W3C Editor's Draft 22 September
>>>> 2016.
>>>> The initial discussion of access to the shapes graph is in Section 1.6:
>>>> "SHACL Full processors MAY pre-bind the variable shapesGraph to provide
>>>> access to the shapes graph. Access to the shapes graph is not a
>>>> requirement
>>>> for supporting the SHACL Core language. The variable shapesGraph can
>>>> also be
>>>> used in user-defined SPARQL constraints and SPARQL-based constraint
>>>> components. However, such constraints may not be interoperable across
>>>> different SHACL Full processors or not applicable to remote RDF
>>>> datasets."
>>>> Given the first "MAY" here, it appears that access to the shapes graph
>>>> is
>>>> neither a requirement for supporting the SHACL Full language.  This puts
>>>> access to the shapes graph in a kind of SHACL Fuller.
>>>> The next discusion is in Section 5.3:
>>>> "$shapesGraph     Can be used to query the shapes graph as in GRAPH
>>>> $shapesGraph { ... }. If the shapes graph is a named graph in the same
>>>> dataset as the data graph then it is the IRI of the shapes graph in the
>>>> dataset. Not all SHACL Full processors need to support this
>>>> variable. Processors that do not support $shapesGraph MUST report a
>>>> failure
>>>> if they encounter a query that references this variable. Use of GRAPH
>>>> $shapesGraph { ... } should be handled with extreme caution. It may
>>>> result
>>>> in constraints that are not interoperable across different SHACL Full
>>>> processors and that may not run on remote RDF datasets."
>>>> Again, access to the shapes graph is in SHACL Fuller.
>>>> The final discussion is in Appendx A:
>>>> "SHACL Full processors must implement the function sh:hasShape, which
>>>> takes
>>>> the following parameters:
>>>> Parameter     Value Type     Summary
>>>> focusNode     rdfs:Resource     The focus node to validate.
>>>> shape         rdfs:Resource     The shape to validate the focus node
>>>> against.
>>>> shapesGraph     rdfs:Resource     The IRI of the current shapes graph."
>>>> An example call of this function is
>>>>     BIND (sh:hasShape(ex:JohnDoe, ex:PersonShape, $shapesGraph) AS
>>>> ?hasShape)
>>>> None of the parameters can be unbound."
>>>> But now it appears that access to the shapes graph is a required part of
>>>> SHACL Full processing, contradicting to the previous discussion.
>>>> Peter F. Patel-Schneider
>>>> Nuance Communications

Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Monday, 26 September 2016 08:07:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:44 UTC