- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Wed, 16 Mar 2016 11:51:28 +0200
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a2W2fm0qrhOJofU0drDjs=m34U+6kp185_MPgqreWt1bg@mail.gmail.com>
On Wed, Mar 16, 2016 at 10:54 AM, Holger Knublauch <holger@topquadrant.com> wrote: > On 16/03/2016 17:44, Dimitris Kontokostas wrote: > > > > On Wed, Mar 16, 2016 at 8:35 AM, Holger Knublauch < > <holger@topquadrant.com>holger@topquadrant.com> wrote: > >> 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. >> > > I would define sh:equals as > > SELECT $this ($this AS ?subject) $predicate ?object > WHERE { > $this $predicate ?object . > $this $equals ?object2 . > FILTER (?object != ?object2) . > } > > > But this would iterate over all combinations, i.e. even for two identical > sets of 2 values, it would produce violations. In other words, both > properties could only ever have one value. > Good point! so I would adjust the current definition to SELECT $this ($this AS ?subject) $predicate ?object WHERE { { $this $predicate ?object . $this $equals [] . FILTER NOT EXISTS { $this $equals ?object . } } UNION { $this $predicate [] . $this $equals ?object . FILTER NOT EXISTS { $this $predicate ?object . } } } added " $this $equals [] ." & " $this $predicate [] . " to make sure the quality is verified only when both properties exist > I regard these as set-operators. > > sh:equals: both sets must be equal > sh:notEquals: both sets must not be equal, i.e. there are nodes outside of > either set > sh:lessThan: all values of set1 must be < all values of set2 > I agree > sh:hasValue: the set must include a given value > sh:in should be also added i this category then > > > Holger > > -- 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 09:52:24 UTC