Re: shapes-ISSUE-129 (existential constraints): Existential constraints should be consistent [SHACL - Core]

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>
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>
> 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:// <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
>
>
>


-- 
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