- From: Simon Steyskal <simon.steyskal@wu.ac.at>
- Date: Wed, 16 Mar 2016 08:37:20 +0100
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
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? I think it boils down to whether sh:hasValue should (implicitly) assume sh:minCount 1 or not. 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
Received on Wednesday, 16 March 2016 07:37:51 UTC