- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Thu, 19 May 2016 17:37:45 +0300
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a1uaJnkUCTC0TdQ_3F8L-9ZUa2b9BZv0oAj4D6P7rpavA@mail.gmail.com>
IIRC, This is the proposal we voted for https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Dec/0044.html and there were some followup questions e.g. the following that was tagged by mistake under a different issue https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jan/0015.html here it is clarified that scoping and filters are ignored when the shapes are referenced from another shape On Thu, May 19, 2016 at 4:59 PM, Karen Coyle <kcoyle@kcoyle.net> wrote: > Thanks. Can you describe or point me to the resolution? - kc > > On 5/18/16 10:59 PM, Dimitris Kontokostas wrote: > >> 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 <mailto: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 >> >> > -- > Karen Coyle > kcoyle@kcoyle.net http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet/+1-510-984-3600 > > -- 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 14:38:41 UTC