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

Not all shapes need to have a scope IMHO. It's the same situation as in 
ontology development. Not every class that is published in an ontology 
is used by everyone, and thus does not need to have instances. Sometimes 
shapes will be defined in one file so that they can be extended with a 
scope in another file, for one specific application.

I don't see a problem with our current design, and sh:scopeProperty 
being sometimes a bit redundant. As I said elsewhere, there are cases 
where sh:scopeProperty and sh:predicate are in fact different. I would 
not favor introducing a new concept for nested shapes.


On 19/05/2016 2:22, Karen Coyle wrote:
> On 5/15/16 10:37 AM, Peter F. Patel-Schneider wrote:
>> 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.
> +1. I can't think of a good name for these, but it seems to me that we 
> have:
> SHACL "file" (data set, whatever) - a set of shapes and constraints
> shape - defines a scope, optional filters, and related constraints
> constraint - the node that defines a set constraints that will be 
> applied to the focus node
> [X] - a set of constraints
> [X] can be a blank node, as it is in many shapes, or it may have an 
> IRI, which is what was formerly illustrated in Example 1. (This 
> assumes that the only difference between them is IRI-v-bNode.)
> The "embedded" vs. "referenced" doesn't make sense in an RDF context, 
> to my mind. It has instead to do with whether the constraints are 
> local-only (bnode) or shareable (IRI).
> kc
> p.s. This doesn't take into account Holger's latest proposal to place 
> shapes sub constraints, but I don't think that makes a difference here

Received on Thursday, 19 May 2016 00:26:39 UTC