- From: Holger Knublauch <holger@topquadrant.com>
- Date: Wed, 16 Mar 2016 09:41:22 +1000
- To: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <56E89DA2.8000507@topquadrant.com>
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 <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 Tuesday, 15 March 2016 23:42:01 UTC