Re: shapes-ISSUE-129 (existential constraints): Existential constraints should be consistent [SHACL - Core] from Dimitris Kontokostas on 2016-03-16 (public-data-shapes-wg@w3.org from March 2016)

From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Date: Wed, 16 Mar 2016 09:44:02 +0200
To: Holger Knublauch <holger@topquadrant.com>
Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Message-ID: <CA+u4+a0=xnnOOuYfThaUbfdTJbRB1XoOaxEYvVSJyqWiejzHvw@mail.gmail.com>
On Wed, Mar 16, 2016 at 8:35 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> Could you sketch how the SPARQL would look like for sh:equals,
> sh:notEquals, sh:lessThan? I see no issues with the current definitions,
> but I may be missing something. Do you have a case where sh:equals and
> sh:notEquals are not symmetric? To me, notEquals reports the intersection
> and equals reports violations for all values that are outside of the
> intersection.
>

I would define sh:equals as

SELECT $this ($this AS ?subject) $predicate ?object
WHERE {
 $this $predicate ?object .
 $this $equals ?object2 .
 FILTER (?object != ?object2) .
}

similar to the existing definitions

SELECT $this ($this AS ?subject) $predicate ?object WHERE {

 $this $predicate ?object .
 $this $lessThan ?object2 .
 FILTER (!(?object < ?object2)) .
}

SELECT $this ($this AS ?subject) $predicate ?object WHERE {
 $this $predicate ?object .
 $this $lessThanOrEquals ?object2 .
 FILTER (!(?object <= ?object2)) .
}

SELECT $this ($this AS ?subject) $predicate ?object WHERE {
 $this $predicate ?object .
 $this $notEquals ?object .
}

with the current definition, when a property does not exists, equals
and notEquals are not symmetric since notEquals does not check for
absence.

With the suggested definition we can claim that these properties are
symmetric only when we have a sh:minCount >0 on both properties





>
> Thanks
> Holger
>
>
>
> On 16/03/2016 16:19, Dimitris Kontokostas wrote:
>
> This is for intuitive understanding of the language. sh:hasValue and sh:in
> are similar to sh:class and sh:classIn
> Users would be confused if e.g. sh:class used the subclass hierarchy to
> check class membership and sh:classIn not.
> I would also find it more intuitive if sh:hasValue was applied only on
> existing values but this is only a personal opinion
>
> On Wed, Mar 16, 2016 at 1:41 AM, Holger Knublauch <
> <holger@topquadrant.com>holger@topquadrant.com> wrote:
>
>> I have trouble voting because I am unclear about is why you want to
>> change these things and what the consequences would be. Do you believe this
>> is to improve the intuitive understanding of the core language, or would
>> those changes lead to simplifications elsewhere, e.g. in implementations?
>>
>> And whatever categorization we are trying to come up with is only against
>> the current snapshot of core features (add another one like sh:closed and
>> things may fall apart) and we cannot anticipate the kinds of constraints
>> people will express with the extension mechanism. I think the most natural
>> thing we can do, generally, is to group "universal" constraints and
>> "anything else" (which corresponds to the current design based on
>> sh:NodeValidationFunctions). The "anything else" bucket may have to stay
>> homogeneous because there is an almost infinite amount of scenarios
>> possible.
>>
>> Holger
>>
>>
>>
>> On 15/03/2016 21:03, Dimitris Kontokostas wrote:
>>
>> I made a proposal with a few variations that can help us resolve this
>> issue faster
>>
>> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-129:_Existential_constraints
>>
>> On Tue, Mar 8, 2016 at 11:03 AM, Dimitris Kontokostas <
>> kontokostas@informatik.uni-leipzig.de> wrote:
>>
>>> My take on existential constraints is if the sparql definitions contains
>>> "WHERE { $this $predicate ?object . ... }" or not
>>> if it does it means that the constraint is applied on existing values
>>> and does not require the value to exist.
>>>
>>> Using this definition the list is different
>>> non-existential constraints:
>>> - sh:class, sh:classIn, sh:datatype, sh:datatypeIn, sh:directType
>>> - sh:max/min/In/Exclusive, sh:maxLength, sh:minLength
>>> - sh:nodeKind
>>> - sh:in
>>> - sh:valueShape
>>> - sh:closed
>>> - sh:uniqueLang
>>> - sh:notEquals, sh:lessThan, sh:lessThanOrEquals
>>>
>>>
>>> existential ones:
>>> - sh:minCount, sh:maxCount
>>> - sh:qualified*
>>> - sh:hasValue
>>> - sh:equals (sorry, I didn't catch equals before)
>>>
>>> I didn't mean to include sh:and/or/not as they are different than the
>>> other core constraints
>>>
>>> I suggested to limit them to - sh:minCount, sh:maxCount (and sh:qualified*
>>> of course) but if we don't we should keep them consistent
>>> sh:hasValue should be consistent with sh:in
>>> sh:equals should be consistent with sh:notEquals, sh:lessThan,
>>> sh:lessThanOrEquals
>>>
>>>
>>> On Tue, Mar 8, 2016 at 12:48 AM, Holger Knublauch <
>>> <holger@topquadrant.com>holger@topquadrant.com> wrote:
>>>
>>>> Many constraint types indeed apply to "all values" only:
>>>> - sh:class, sh:classIn, sh:datatype, sh:datatypeIn, sh:directType
>>>> - sh:max/min/In/Exclusive, sh:maxLength, sh:minLength
>>>> - sh:nodeKind
>>>> - sh:in
>>>> - sh:valueShape
>>>>
>>>> These are handled by NodeValidationFunctions in the current draft.
>>>>
>>>> Other constraint types are more heterogeneous, and calling them
>>>> "existential" is IMHO an over-simplification:
>>>> - sh:and, sh:or, sh:not
>>>> - sh:closed
>>>> - sh:equals, sh:notEquals, sh:lessThan, sh:lessThanOrEquals
>>>> - sh:minCount, sh:maxCount
>>>> - sh:qualifiedXY
>>>> - sh:uniqueLang
>>>> - sh:hasValue
>>>>
>>>> Just looking at sh:equals for example, the query is something like
>>>>
>>>>
>>>>         SELECT $this ($this AS ?subject) $predicate ?object
>>>>         WHERE {
>>>>             {
>>>>                 $this $predicate ?object .
>>>>                 FILTER NOT EXISTS {
>>>>                     $this $equals ?object .
>>>>                 }
>>>>             }
>>>>             UNION
>>>>             {
>>>>                 $this $equals ?object .
>>>>                 FILTER NOT EXISTS {
>>>>                     $this $predicate ?object .
>>>>                 }
>>>>             }
>>>>         }
>>>>
>>>> i.e. the system will produce violations if the "other" property has a
>>>> value that isn't present but also vice-versa. It may even fire a violation
>>>> if there is no value at all, but the other property has values.
>>>>
>>>> Coming up with an artificial limitation is likely going to hurt
>>>> extensions that we cannot anticipate yet, so I believe we must treat them
>>>> as "arbitrary" constraint types that may do anything they like.
>>>>
>>>> I also have seen many use cases of sh:hasValue, esp in filterShapes, so
>>>> i would be against dropping that.
>>>>
>>>> Holger
>>>>
>>>>
>>>>
>>>>
>>>> On 7/03/2016 20:49, RDF Data Shapes Working Group Issue Tracker wrote:
>>>>
>>>>> shapes-ISSUE-129 (existential constraints): Existential constraints
>>>>> should be consistent [SHACL - Core]
>>>>>
>>>>> http://www.w3.org/2014/data-shapes/track/issues/129
>>>>>
>>>>> Raised by: Dimitris Kontokostas
>>>>> On product: SHACL - Core
>>>>>
>>>>> The current core spec defines three existential constraints:
>>>>> sh:minCount, sh:maxCount and sh:hasValue.
>>>>> sh:hasValue requires for a value to exist and match the one supplied
>>>>> in the shape definition.
>>>>>
>>>>> This is not consistent with sh:in which is a variation of sh:hasValue
>>>>> and probably not easy for users to understand the different of sh:hasValue
>>>>> and other constraints e.g. sh:minLength, sh:class, etc
>>>>>
>>>>> I suggest we restrict the core existential constraints to sh:minCount
>>>>> and sh:maxCount only. The rest of the constraints will apply only when
>>>>> there is a value.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Dimitris Kontokostas
>>> Department of Computer Science, University of Leipzig & DBpedia
>>> Association
>>> Projects: <http://dbpedia.org>http://dbpedia.org,
>>> <http://rdfunit.aksw.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>
>>> http://aksw.org/Groups/KILT
>>>
>>>
>>
>>
>> --
>> Dimitris Kontokostas
>> Department of Computer Science, University of Leipzig & DBpedia
>> Association
>> Projects: http://dbpedia.org, <http://rdfunit.aksw.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>
>> http://aksw.org/Groups/KILT
>>
>>
>>
>
>
> --
> 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>
> http://aksw.org/Groups/KILT
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://
http://aligned-project.eu
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Wednesday, 16 March 2016 07:44:57 UTC