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

Re: shapes-ISSUE-134 (knowing inverse): does SHACL syntax distinguish inverse property constraints [SHACL Spec]

From: Holger Knublauch <holger@topquadrant.com>
Date: Thu, 7 Apr 2016 15:01:33 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <5705E9AD.2050803@topquadrant.com>
See

http://w3c.github.io/data-shapes/shacl/#shapes-graph-invalid

The 
classes|sh:NodeConstraint|,|sh:PropertyConstraint|and|sh:InversePropertyConstraint|are 
pairwise disjoint

HTH
Holger


On 7/04/2016 14:43, Karen Coyle wrote:
> 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
>>>>>
>>>>
>>>
>>
>>
>>
>
Received on Thursday, 7 April 2016 05:02:07 UTC

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