W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > July 2016

Re: shapes-ISSUE-174 (Scopenode): Scopenode does not use RDF node definition [SHACL - Core]

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Fri, 15 Jul 2016 11:42:40 -0700
To: Irene Polikoff <irene@topquadrant.com>
Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Message-ID: <0fa7162d-4d1d-b42c-6f95-4b06d96ad595@kcoyle.net>
The question is: how should we define "in scope" and "focus node"? I'm 
thinking that quite possibly "in scope" is not the right term, and we 
should talk about "scoping" or "defining the scope" because "in scope" 
isn't really distinct from "focus node" since both refer to nodes in the 
data graph. The scope step defines a node to be selected in the data 
graph, but since SHACL defines but doesn't *act* there is no data graph 
that can be "in scope" in the SHACL graph regardless of the number of 
iterations of scope and filter that a SHACL instance defines.

So I would say:

(Scope definition for Shape + filter definition) (repeat as needed) = 
focus node in data graph

And the definition of scope, which is:

A scope is a triple or a node in the shapes graph that specifies which 
nodes in a data graph are considered in-scope for a shape. Validating a 
shape in a shapes graph involves validating the in-scope nodes for all 
scopes of the shape.

Would be:

A scope is a *node* in the shapes graph that specifies which nodes in a 
data graph *will be selected as focus nodes*. Validating a *node in the 
data graph* involves validating the *focus nodes in the data graph as 
defined by the scope in the shapes graph*.

I'm not totally happy with that because it doesn't include filters, nor 
does it indicate the possible iterations. Rather than calling scope a 
*node* I would tend to refer to it as a set of instructions that include 
scope definitions and filters, but I don't know how much of the document 
this would change.


On 7/14/16 11:11 AM, Irene Polikoff wrote:
> I think the below is right, but it is not the only way to identify focus
> nodes. A more complete description would be something like:
> 1. Scope step for Shape1-> "in scope" + filter step -> focus node for
> Shape1
> 2. Scope step for Shape2-> "in scope" + filter step -> focus node for
> Shape2
> these are the ³final² focus nodes in that they are definitely in focus,
> but they are not necessary a complete set of focus nodes as step 3 can add
> to them
> Note that I am skipping "Scope step -> "in scope" (+ 0) -> focus node²
> because ³scope step² could also be (+0) - that is, a shape could have not
> only zero filter statements, but also zero scope statements.
> 3. Focus node for Shape1 -> ³sh:shape² step -> additional focus nodes for
> Shape2, where Shape2 is a value of sh:shape in some Shape1 constraint.
> In other words, filter step filters out (removes) some nodes in scope.
> Thus, by applying a filter not all in-scope nodes become focus nodes.
> ³sh:shape² step adds some nodes, so that the nodes that were not
> identified as in scope through the scope statements for a shape can become
> focus nodes.
> Irene
> On 7/14/16, 1:00 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>> So the steps are:
>> Scope step -> "in scope" + filter step -> focus node
>> and this is true even if there is no filter step. I think that's what
>> isn't clear in the document.
>> Scope step -> "in scope" (+ 0) -> focus node

Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
Received on Friday, 15 July 2016 18:43:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:36 UTC