- From: Dimitris Kontokostas <jimkont@gmail.com>
- Date: Sat, 24 Sep 2016 16:54:28 +0300
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
- Message-ID: <CA+u4+a1gW=8bHE=OX2FWGwH9d__t7uNzgTx3y1PyLR6YvTZW_Q@mail.gmail.com>
Hi Peter, See my reply on "different levels of SHACL" I think that resolves this issue as well Thanks for your feedback, Dimitris On Friday, September 23, 2016, Peter F. Patel-Schneider < pfpschneider@gmail.com> 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 > > >
Received on Saturday, 24 September 2016 13:55:16 UTC