- 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