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

On Wed, Mar 16, 2016 at 9:37 AM, Simon Steyskal <simon.steyskal@wu.ac.at>
wrote:

> Hi!
>
> 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
>>
>
> Just to clarify your understanding of "only applied on existing values" :
>
> ex:example1 a ex:Example ;
>   ex:property 1 .
>
> ex:example2 a ex:Example ;
>   ex:property 2 .
>
> ex:example3 a ex:Example .
>
> ex:ExampleShape a sh:Shape ;
>   sh:scopeClass ex:Example ;
>   sh:property [
>     sh:predicate ex:property ;
>     sh:hasValue 1
>   ] .
>
> if sh:hasValue only applies on existing values, both ex:example1 and
> ex:example3 should be valid, right?
>

yes, just like if we used
sh:class
sh:classIn
sh:datatype
sh:datatypeIn
sh:directType
sh:in
sh:xxxLength
sh:xxxXclusive
sh:nodeKind
sh:pattern
[sh:equals]
sh:lessThan
sh:lessThanOrEquals
sh:notEquals
sh:uniqueLang


> I think it boils down to whether sh:hasValue should (implicitly) assume
> sh:minCount 1 or not.
>

noone asked to drop sh:hasValue, the implicit minCount is the only issue.


>
> simon
>
> (I would definitly vote -1 against dropping sh:hasValue!)
>
> ---
> DDipl.-Ing. Simon Steyskal
> Institute for Information Business, WU Vienna
>
> www: http://www.steyskal.info/  twitter: @simonsteys
>
>
> Am 2016-03-16 07:19, schrieb Dimitris Kontokostas:
>
>> 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
>>
>>> [1]
>>>
>>>
>>> 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 [2]
>>>
>>> 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: [3]http://dbpedia.org [3], http://rdfunit.aksw.org [4],
>> http:// [5]http://aligned-project.eu [6]
>>
>> Homepage: [7]http://aksw.org/DimitrisKontokostas [7]
>>
>> Research Group: AKSW/KILT  [8]http://aksw.org/Groups/KILT [8]
>>
>>  --
>>
>>  Dimitris Kontokostas
>>  Department of Computer Science, University of Leipzig & DBpedia
>> Association
>> Projects: [3]http://dbpedia.org [3], http://rdfunit.aksw.org [4],
>> http:// [5]http://aligned-project.eu [6]
>>
>> Homepage: [7]http://aksw.org/DimitrisKontokostas [7]
>>
>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT [8]
>>
>> --
>>
>>  Dimitris Kontokostas
>>  Department of Computer Science, University of Leipzig & DBpedia
>> Association
>> Projects: http://dbpedia.org [3], http://rdfunit.aksw.org [4],
>> http://http://aligned-project.eu [5]
>>
>> Homepage:http://aksw.org/DimitrisKontokostas [7]
>>
>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT [8]
>>
>>
>>
>> Links:
>> ------
>> [1]
>>
>> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-129:_Existential_constraints
>> [2] http://www.w3.org/2014/data-shapes/track/issues/129
>> [3] http://dbpedia.org
>> [4] http://rdfunit.aksw.org
>> [5] http://aligned-project.eu/
>> [6] http://aligned-project.eu
>> [7] http://aksw.org/DimitrisKontokostas
>> [8] 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