Re: on access to the shapes graph in SHACL

Similar to access to $shapesGraph, sh:hasShape was a result of long 
discussions and essentially a compromise between two architectures - one 
with SPARQL end points only and another with local datasets. We ended up 
making both features optional. I would find it very unfortunate if we 
have to re-open all these discussions yet again, esp given that we are 
trying to reach CR status at some stage. Likewise we could re-open the 
existence of sh:entailment which is a similar compromise feature that 
not everyone will want to implement, and many other topics. It is not 
possible now to take out one piece of the puzzle without risking other 
features that were built under the assumption of their presence.

Holger


On 26/09/2016 18:06, Dimitris Kontokostas wrote:
> I was also never in favour of sh:hasShape, I think it brings many 
> problems while trying to solve some
> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0076.html
>
> Maybe Andy and Ted (as SPARQL engine implementors) are more suited to 
> say their opinions on the need of sh:hasShape
>
> Dimitris
>
> On Mon, Sep 26, 2016 at 9:57 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>     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, 
> http://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>