- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 19 May 2016 19:05:32 -0700
- To: public-data-shapes-wg@w3.org
Great, thanks Holger. That's what I wanted to confirm. None of the examples showed this so I wasn't sure. kc On 5/19/16 3:43 PM, Holger Knublauch wrote: > Karen, I see nothing invalid in your example. Are you referring to the > value of sh:valueShape being a bnode? Yes, this is perfectly fine, just > like such bnodes can show up in sh:or and sh:not. > > Holger > > > On 20/05/2016 3:56, Karen Coyle wrote: >> Thanks, Simon. Looking at the code in your message in January, I am >> wondering if this, below, a variant using a bnode, is valid SHACL - >> >> ex:IssueShape a sh:Shape; >> sh:scopeClass ex:Issue ; >> sh:property [ >> sh:predicate ex:submitter ; >> sh:valueShape [ >> a sh:Shape >> sh:scopeClass ex:Person ; >> sh:property [ >> sh:predicate ex:username ; >> sh:minCount 1 ; >> sh:maxCount 1 ; >> ] >> ] >> >> The examples all show nodes with IRIs. If a bnode is also valid, then >> we should add a short example showing that. If not, then the document >> should explain that. >> >> kc >> >> On 5/19/16 7:37 AM, Dimitris Kontokostas wrote: >>> 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 >>> <mailto: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> >>> <mailto: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 <mailto:kcoyle@kcoyle.net> http://kcoyle.net >>> m: 1-510-435-8234 >>> skype: kcoylenet/+1-510-984-3600 <tel:%2B1-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 >>> >> > > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Friday, 20 May 2016 02:05:58 UTC