Re: invocation conflicting with sh:scope*

For me it is also fine to say that it is considered a good/best practice to
keep scopes and shapes separated but I would prefer not to require it.
Otherwise we would have to change a lot in the spec for things that are
quite stable now e.g. validation will require 3 graphs, data, shapes &
scopes

We already suggest owl:imports in the spec as a way to merge different
shapes graphs and this could be an option to keep shapes and scopes separate

On Thu, Jun 23, 2016 at 5:22 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:

> I'm fine with creating a separation between scoping and constraint
> definitions, although I think that SHACL should provide both or else it
> cannot be a full, programmable solution to the RDF validation problem. By
> separating them, a different solution to either function could be
> substituted in the future.
>
> kc
>
>
> On 6/22/16 10:26 PM, 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.
>>
>>
>> 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?
>>>>
>>>
>>>
>>>
>>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>
>


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