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

Yes, the discussion of shapes and focus nodes is confusing in places.

peter

On 05/15/2016 03:04 PM, Karen Coyle wrote:
> 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
>>>>>
>>>>>
>>>
>>
>>
>>
>

Received on Sunday, 15 May 2016 22:52:26 UTC