- From: Holger Knublauch <holger@topquadrant.com>
- Date: Mon, 3 Aug 2015 09:00:38 +1000
- To: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
- Message-ID: <55BEA116.9060405@topquadrant.com>
On 7/31/2015 23:01, Dimitris Kontokostas wrote: > > > On Fri, Jul 31, 2015 at 1:29 AM, Holger Knublauch > <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote: > > On 7/30/2015 23:46, Dimitris Kontokostas wrote: >> >> >> On Fri, Jul 24, 2015 at 6:51 AM, Holger Knublauch >> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote: >> >> As resolved in the call today, SHACL now supports >> >> - sh:maxExclusive >> - sh:maxInclusive >> - sh:minExclusive >> - sh:minInclusive >> (hopefully not including too many copy and paste errors) >> >> - sh:maxLength >> - sh:minLength >> - sh:pattern >> >> I have implemented the latter three so that they work with >> any datatype and even IRIs. >> >> >> Errors are reported on blank node values, because they cannot >> be turned into strings. Errors are also reported if the <, > >> comparisons fail. >> >> >> I have some minor concerns on this as it might not be consistent >> with other cases where a comparison fails and a user would expect >> an error report as well. > > Do you have a specific example for the latter? SPARQL usually > "silently" fails on function evaluation errors, i.e. it returns no > matches in such SELECT queries. Would your preference be that we > do the same and not return an error when a > comparison failed, > i.e. returned unbound? > > > I do not have a strong preference on this, I suggest that if we go > with your approach we should make a note that this is not the expected > SPARQL behavior Ok that's fine. I hope this paragraph clarifies it: https://github.com/w3c/data-shapes/commit/005604e8aa0b6c6843bd1525dbe260a4ed30d7ab Holger
Received on Sunday, 2 August 2015 23:01:16 UTC