- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Thu, 19 May 2016 08:59:41 +0300
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a2K+MHqc0VGs242ULkm+baVwWo8NQxRQjsj=_CYKaU07Q@mail.gmail.com>
Karen, This is an issue I raised sometime ago and we have a resolution with the current design https://www.w3.org/2014/data-shapes/track/issues/49 On Thu, May 19, 2016 at 3:26 AM, Holger Knublauch <holger@topquadrant.com> wrote: > 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, http://aligned-project.eu Homepage: http://aksw.org/DimitrisKontokostas Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Thursday, 19 May 2016 06:00:38 UTC