Re: Simplification of scopes section (see also ISSUE-148)

While the example in 1.3 shows a shape without a scope, (and makes only 
a brief reference to what this means) everywhere that "shape" is defined 
it is defined as having scopes and constraints:

TERMINOLOGY:
"Shape
A shape is a node in a shapes graph that is a SHACL instance of 
sh:Shape. A shape provides a collection of scopes, filters, and 
constraints that specify how a data graph is validated against the 
shape. Shapes can also provide non-validating information, such as 
labels and names."

SECTION 2 INTRODUCTION:
"2. Shapes

Shapes are SHACL instances of sh:Shape and define one or more 
constraints that a set of focus nodes can be validated against. The set 
of focus nodes may be defined explicitly in a shape using scopes and 
filters, or provided by the validation engine as defined in later sections."



On 5/15/16 1:25 PM, Irene Polikoff wrote:
> Is this only about łembedded" shapes or also about any referenced shape? I
> thought the latter.
>
> For example, the section 1.3 example with Issues and Users. UserShape has
> no scope and it is not evaluated against any nodes. However, IssueShape
> has a scope and it says that the objects of reportedBy must confirm to the
> UserShape. As a result, objects of the triples with subjects that are
> validated against the IssueShape and reportedBy predicates get validated
> against the UserShape.
>

It's not just that it has no scope - it is a particular kind of shape, a 
shape-based constraint component, and probably shouldn't be in that 
first example at all. AFAIK, that mechanism functions only for a 
particular set of shapes, ones that are the objects of shape-based CC's. 
That section (4.7) says nothing about scopes. It seems to me that these 
are a particular type of shape and should be defined as such - they are 
shapes that are only to be used in these shape-based constraints. So we 
have a type of shape that I think should be identified on its own by 
something other than its lack of a scope.

kc

>
> Irene
>
>
> On 5/15/16, 1:37 PM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> wrote:
>
>> SHACL has allowed embedded shapes from the beginning.  Initially it
>> allowed
>> the embedding to be recursive, but this is currently not allowed.  One
>> construct that allows recursive shapes is sh:valueShape.  See
>> http://w3c.github.io/data-shapes/shacl/#constraints-shape for constructs
>> that
>> allow for embedded shapes, and
>> http://w3c.github.io/data-shapes/shacl/#ValueShapeConstraintComponent for
>> details on sh:valueShape.
>>
>> It is possible to have something like SHACL that does not do embedding at
>> all.
>> SPIN works this way, I think.  Filters can also be used to get some of
>> the
>> effects of embedding, but I don't think that they are as expressive as
>> embedding.
>>
>> However, there is a difference between filters and embedding in the
>> validation
>> results that would be returned.  Note that the validation results for
>> ex:s1
>> below are for a person who has a dependent without a SSN, not for the
>> dependent.  A non-embedding filter solution would produce validation
>> results
>> for the dependent itself.
>>
>> peter
>>
>>
>>
>> On 05/15/2016 07:42 AM, Karen Coyle wrote:
>>>
>>>
>>> On 5/14/16 1:08 PM, Peter F. Patel-Schneider wrote:
>>>> One problem with having all shapes initiate validation is that
>>>> embedded shapes
>>>> would as well.
>>>>
>>>> So in
>>>>
>>>> ex:s1 rdf:type sh:Shape ;
>>>>     sh:scopeClass ex:Person ;
>>>>     sh:property [ sh:predicate ex:dependent ;
>>>>                   sh:valueShape [ a sh:Shape ;
>>>>                                   sh:property [ sh:predicate ex:SSN ;
>>>>                                                 sh:minCount 1 ] ] ] .
>>>>
>>>> the scope of the embedded shape would be all nodes in the data graph,
>>>> resulting in validation reports for any node that does not have a
>>>> value for
>>>> ex:SSN.
>>>
>>> I thought that filter shapes would be used if further refinement of the
>>> scope
>>> is needed. This appears to be using a shape for that purpose (and I
>>> don't
>>> recall this being mentioned before). Even with a defined scope it isn't
>>> clear
>>> to me what the scope in the embedded shape would act on as its initial
>>> input,
>>> since the spec says that a shapes graph is compared to a data graph,
>>> but the
>>> result of scoping \= a new data graph. ? Anyway, is embedding shapes
>>> allowed?
>>> If so, what are the rules for how that is implemented?
>>>
>>> kc
>>>
>>>>
>>>> If all shapes are to have scopes then there are ways around this
>>>> problem.  One
>>>> would be that shapes are not embedded in other shapes.  Instead there
>>>> would be
>>>> a new kind of SHACL thing that is used when the current effect of
>>>> embedding
>>>> shapes in shapes is desired.
>>>>
>>>> peter
>>>>
>>>>
>>
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Sunday, 15 May 2016 22:05:05 UTC