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

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>
> 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://rdfunit.aksw.org, http://
> http://aligned-project.eu
> Homepage: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