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: Holger Knublauch <holger@topquadrant.com>
Date: Wed, 16 Mar 2016 16:35:38 +1000
To: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Message-ID: <56E8FEBA.60506@topquadrant.com>
Whatever we do with sh:hasValue we need to keep in mind that its 
specific term is already used by OWL. If we change the semantics, then 
we should rename that property to avoid confusion. I agree it's not nice 
to have an implicit sh:minCount>0 here, yet it is convenient and compact 
for its common use case in filters.

Could you sketch how the SPARQL would look like for sh:equals, 
sh:notEquals, sh:lessThan? I see no issues with the current definitions, 
but I may be missing something. Do you have a case where sh:equals and 
sh:notEquals are not symmetric? To me, notEquals reports the 
intersection and equals reports violations for all values that are 
outside of the intersection.

Thanks
Holger


On 16/03/2016 16:19, Dimitris Kontokostas wrote:
> 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 <mailto: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
>>
>>     On Tue, Mar 8, 2016 at 11:03 AM, Dimitris Kontokostas
>>     <kontokostas@informatik.uni-leipzig.de
>>     <mailto: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 <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
>>         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
>>
>
>
>
>
> -- 
> 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
>
Received on Wednesday, 16 March 2016 06:36:13 UTC

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