- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Wed, 16 Mar 2016 10:16:14 +0200
- To: Simon Steyskal <simon.steyskal@wu.ac.at>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a3rSc+Bo3Te9QnJ=8P+RgRmxHT4GuMX=u-nMKdSCRo3QA@mail.gmail.com>
On Wed, Mar 16, 2016 at 9:37 AM, Simon Steyskal <simon.steyskal@wu.ac.at> wrote: > 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? > yes, just like if we used sh:class sh:classIn sh:datatype sh:datatypeIn sh:directType sh:in sh:xxxLength sh:xxxXclusive sh:nodeKind sh:pattern [sh:equals] sh:lessThan sh:lessThanOrEquals sh:notEquals sh:uniqueLang > I think it boils down to whether sh:hasValue should (implicitly) assume > sh:minCount 1 or not. > noone asked to drop sh:hasValue, the implicit minCount is the only issue. > > 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 >> > > -- 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
Received on Wednesday, 16 March 2016 08:17:11 UTC