W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2016

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

From: Iovka Boneva <iovka.boneva@univ-lille1.fr>
Date: Tue, 15 Mar 2016 15:02:48 +0100
Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Message-ID: <56E81608.1020608@univ-lille1.fr>
Are the minCount and maxCount constraints really existential ? The 
maxCount constraint has a "universal" aspect, as it requires that there 
do not exist nodes satisfying the property beyond the maxCount allowed 
ones.
I think that the minCount and maxCount constraint are counting 
constraints and should be considered apart.

While trying to formalize SHACL, I identified 5 kinds of constraints, 
and the sh:hasValue constraint that enters in none of the five categories.

- universal constraints

sh:class
sh:classIn
sh:datatype
sh:datatypeIn
sh:directType
sh:in
sh:xxxLength
sh:xxxXclusive
sh:nodeKind
sh:pattern

- counting constraints

sh:xxxCount
sh:qualifiedXxxCount

- complex constraints on the value

sh:valueShape
sh:qualifiedValueShape

- "second order constraints" : these require to quantify on the set of 
values, and inspect all the elements of a set; this is not a first-order 
quantification (unlike the universal constraints), and is not captured 
by counting (counting is a kind of simple extension of first-order 
quantification)

sh:equals
sh:lessThan
sh:lessaThanOrEquals
sh:notEquals
sh:uniqueLang

- unclassified

sh:hasValue

The sh:hasValue constraint is different from the others. It also 
requires second order quantification, but different from the previous 
ones. Moreover, I was wondering whether it can be expressed as a 
qualified cardinality (qualified min count >= 1).

As Dimitris, I tend to think that having one constraint that is 
different from all others can be confusing for users.

Iovka



Le 08/03/2016 10:03, Dimitris Kontokostas a écrit :
> 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 <mailto: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 <http://aligned-project.eu/>
> Homepage:http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>


-- 
Iovka Boneva
Associate professor (MdC) Université de Lille
http://www.cristal.univ-lille.fr/~boneva/
+33 6 95 75 70 25
Received on Tuesday, 15 March 2016 14:03:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:30 UTC