- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Wed, 6 Apr 2016 21:43:35 -0700
- To: public-data-shapes-wg@w3.org
Thanks, Holger. But can you say exactly which classes will be defined as disjoint from each other? I'm still finding this rather vague. Or maybe it's in the issue somewhere? kc On 4/6/16 7:27 PM, Holger Knublauch wrote: > Karen, > > I don't think you need to be concerned. This is merely about corner > cases such as > > ex:MyShape > a sh:Shape ; > sh:property ex:c ; > sh:inverseProperty ex:c . > > ex:c a sh:PropertyConstraint ; > sh:predicate .... > > i.e. a constraint node is shared as both sh:property and > sh:inverseProperty. I don't think anybody would practically do this, but > we need to exclude that possibility to help the engine decide which > SPARQL to run. > > It does not make the use of, say, sh:minCount and sh:class disjoint with > each other. > > HTH > Holger > > > On 7/04/2016 12:22, Karen Coyle wrote: >> All WHAT disjoint? All constraints? That not only makes me nervous >> about unintended consequences, but in addition since we've rejected >> inferencing, I'm not sure what it does. If nothing else, pairwise >> disjoint rules on every possible combination of constraints could be >> burdensome if your software is expected to enforce that. And I'd like >> a run-through of the constraints to make sure this doesn't trip us up >> somewhere down the line. In general, my preference is to avoid >> declaring disjoint classes or properties except when absolutely >> necessary. >> >> Could you give an example of the case that brought this up, and see if >> it generalizes to other constraint classes? >> >> kc >> >> On 4/6/16 12:57 AM, Holger Knublauch wrote: >>> Yeah, why not. I just made them all disjoint. This is a rather >>> theoretical corner case anyway, so being conservative here will make our >>> lives easier: >>> >>> The >>> classes|sh:NodeConstraint|,|sh:PropertyConstraint|and|sh:InversePropertyConstraint|are >>> >>> pairwise disjoint, i.e. it is illegal to have shape definitions that use >>> nodes that are instances of two or more of these classes - either >>> explicitly stated via|rdf:type|or implicitly via theirdefault value >>> type. >>> >>> Thanks, >>> Holger >>> >>> >>> On 6/04/2016 17:42, Dimitris Kontokostas wrote: >>>> >>>> On Wed, Apr 6, 2016 at 10:08 AM, Holger Knublauch >>>> <<mailto:holger@topquadrant.com>holger@topquadrant.com> wrote: >>>> >>>> On 11/03/2016 15:57, Holger Knublauch wrote: >>>>> Ok, we can leave this ticket open here as a reminder that this >>>>> needs to be clarified. Like the other unwritten details about >>>>> sh:property vs sh:inverseProperty vs sh:constraint, this will be >>>>> cleaned up once we have resolved the general metamodel discussion. >>>> >>>> I believe this ISSUE-134 can be closed now: Section 2.3 now >>>> includes a paragraph: >>>> >>>> The >>>> classes|sh:PropertyConstraint|and|sh:InversePropertyConstraint|are >>>> disjoint, i.e. it is illegal to have shape definitions that use >>>> nodes that are instances of both classes - either explicitly >>>> stated via|rdf:type|or implicitly via theirdefault value type. >>>> >>>> >>>> Can we say that all constraint types are pairwise disjoint? >>>> we can get in similar cases when someone uses sh:NodeConstraint >>>> and sh:InversePropertyConstraint >>>> this means that constraint IRIs can be reused but only with same >>>> constraint types >>>> Dimitris >>>> >>>> >>>> >>>> -- >>>> Dimitris Kontokostas >>>> Department of Computer Science, University of Leipzig & DBpedia >>>> Association >>>> Projects: <http://dbpedia.org>http://dbpedia.org, >>>> http://rdfunit.aksw.org, >>>> http://<http://aligned-project.eu/>http://aligned-project.eu >>>> Homepage:<http://aksw.org/DimitrisKontokostas>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 Thursday, 7 April 2016 04:43:13 UTC