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

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.


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 20:26:14 UTC