- From: Irene Polikoff <irene@topquadrant.com>
- Date: Fri, 15 Jul 2016 15:07:09 -0400
- To: <kcoyle@kcoyle.net>
- CC: public-data-shapes-wg <public-data-shapes-wg@w3.org>
I would say Validating a data graph against a shapes graph involves validating the focus nodes in the data graph as defined by the scopes of the shapes in the shapes graph. I would also prefer calling a scope a set of instructions to calling it a node. Irene On 7/15/16, 2:42 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote: >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. > >kc > >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 19:07:46 UTC