- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Tue, 15 Mar 2016 13:03:24 +0200
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a0AGjEvkjBDfPxiNeKye0VFS=uOh8N29kGXKjAX4D9PVQ@mail.gmail.com>
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> 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 >>> >>> 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
Received on Tuesday, 15 March 2016 11:04:21 UTC