Re: invocation conflicting with sh:scope*

* Holger Knublauch <holger@topquadrant.com> [2016-06-23 15:43+1000]
> 
> 
> On 23/06/2016 15:26, Eric Prud'hommeaux wrote:
> >* Holger Knublauch <holger@topquadrant.com> [2016-06-23 09:15+1000]
> >>Hi Eric,
> >>
> >>when a shape is validated as part of a "nested" sh:shape, sh:and, sh:not etc
> >>then its declared scope is ignored. Only its sh:filterShapes will be
> >>considered.
> >Understood, but this isn't about "nested" shapes. Many use cases
> >involve a sort of late binding where the invocation context determines
> >pairings of node/shape for validation. UC4 is explicit about this, but
> >I expect the case where a user interface invokes sh:hasShape directly
> >to be an extremely common case in linked data.
> >
> >We could get more reusability out of the schema by moving sh:scope*
> >into a separate "control graph" (Peter's term), allowing that schema
> >to be applied to other data that doesn't have e.g. a discriminating
> >type arc.
> 
> Yes, users of SHACL have that choice and it could become a best practice in
> certain user groups. That scoping graph would be dynamically merged into the
> shapes graph prior to validation (to drive one particular execution), yet
> kept separately when distributed on the web. The scope triples could also be
> generated dynamically.

I think it would clarify a lot to move the scoping directives into a
separate document. They have wider applicability:

  - outside of validation, e.g. an LDP endpoint could use them for
    finding the start node or nodes in a POSTed graph.

  - in other validation languages, e.g. a couple ShEx engines honor
    various forms of scope properties.

This would reduce the confusion about how the interact with
validation. A validation pipeline would be a sequence of:

  1 select some node/shape pairs by:
    - scopes graph
    - user interface
    - SPARQL query
    - rooted graph protocol

  2 validate them using SHACL rules.


> Holger
> 
> 
> >
> >
> >>This is one of the reasons why the current spec states that node constraints
> >>are validated against each focus node individually, because the set of scope
> >>nodes is relatively orthogonal to the shape's current execution context.
> >>
> >>HTH
> >>Holger
> >>
> >>
> >>On 23/06/2016 8:03, Eric Prud'hommeaux wrote:
> >>>Is a validation engine expected to always honor sh:scope*?
> >>>
> >>>Apart from cardinality constraints on subjects of type arcs, validations boil down to various choreographies to invoke sh:hasShape, which effectively validates a node in a graph against a shape in a schema. There are of course an unenumerable number of ways that one may wish to connect nodes to shapes, user interface, posts to LD containers, routine sweeps of data stores, etc. So if one were to invoke a validation and the schema included some conflicting sh:scopeNode or sh:scopeProperty assertions, which would win?
> >>
> 
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Thursday, 23 June 2016 07:49:07 UTC