W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > May 2016

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

From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Date: Thu, 19 May 2016 08:59:41 +0300
Message-ID: <CA+u4+a2K+MHqc0VGs242ULkm+baVwWo8NQxRQjsj=_CYKaU07Q@mail.gmail.com>
To: Holger Knublauch <holger@topquadrant.com>
Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>

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 <holger@topquadrant.com>

> 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
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Thursday, 19 May 2016 06:00:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:33 UTC