Re: invocation conflicting with sh:scope*

* 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.


> 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 05:26:37 UTC