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 12:27:53 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <5705C5A9.3080208@topquadrant.com>
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 02:28:27 UTC

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