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


This is an issue I raised sometime ago and we have a resolution with the
current design

On Thu, May 19, 2016 at 3:26 AM, Holger Knublauch <>

> 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.
> Holger
> 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

Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Research Group: AKSW/KILT

Received on Thursday, 19 May 2016 06:00:38 UTC