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

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?
I think it boils down to whether sh:hasValue should (implicitly) assume 
sh:minCount 1 or not.

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

Received on Wednesday, 16 March 2016 07:37:51 UTC