- From: <Patrick.Stickler@nokia.com>
- Date: Tue, 27 Jul 2004 14:16:48 +0300
- To: <andy.seaborne@hp.com>, <public-rdf-dawg@w3.org>
> -----Original Message----- > From: ext Seaborne, Andy [mailto:andy.seaborne@hp.com] > Sent: 27 July, 2004 14:05 > To: Stickler Patrick (Nokia-TP-MSW/Tampere); Seaborne, Andy; > public-rdf-dawg@w3.org > Subject: RE: BRQL and typed literals > > > > > > -------- Original Message -------- > > From: Patrick.Stickler@nokia.com <mailto:Patrick.Stickler@nokia.com> > > Date: 27 July 2004 11:59 > > > > > -----Original Message----- > > > From: Stickler Patrick (Nokia-TP-MSW/Tampere) > > > Sent: 27 July, 2004 13:49 > > > To: 'ext Seaborne, Andy'; public-rdf-dawg@w3.org > > > Subject: RE: BRQL and typed literals > > > > > > > > > > > > > 2. Simply adopt the standard N-Triples notation for > typed literals > > > including support for qnames (e.g. "10"^^xsd:integer). > If a given > > > query engine/service supports the datatype in > question, fine, else > > > it issues an error. > > > > > > > Or alternately (and I've covered this in detail before, but > > thought to stress this point) the engine can opt to treat unknown > > datatypes such that, if the typed literal in a query matches > > exactly a typed literal in the knowledge base (both lexical form > > and datatype URI) then it can deem them to be equal and a match, > > otherwise it can treat it as a non-match (even if in fact > > they are equal values (e.g. "010"^^xsd:int and "10"^^xsd.int) > > and even issue a warning that some "real" targets may not have > > been found due to lack of support for the datatype in question. > > > > Thus > > > > DESCRIBE ?x WHERE (?x ex:booga "xyz"^^foo:blargh) > > > > would still be a useful query, even for query engines who have no > > clue what the datatype foo:blargh is, because it can still find > > all triples explicitly matching that typed literal. > > > > Patrick > > Actually, that syntax for literals is already in the strawman > and is in most > RDQL implementations as far as I know. There are shortcuts > for xsd:integer > and xsd:double. Fair enough. I was referring strictly to the BRQL spec, not RDQL, but hence my presumption that support was lurking somewhere there in the shadows... > > As to operations in such values, the WG has accepted it will > identify a > subset of XML schema datatypes and operations. (That's 3.7) > so there is a > common base that can be assumed to be there (implementations > to date have > provided integer comparison, for example) and extensions, > with the suggested > approach by function call (see the strawman doc) or by > evaluating predicates > (c.f. cwm or iTQL). That's fine, if that subset is simply taken as a baseline for minimum required support -- but not fine if it is taken as an absolute such that those datatypes recieve literal representation in the query language yet arbitrary typed literals have no representation in the query language. It's one thing to say "all DAWG implementations must support xsd:integer" but quite another to say "all DAWG implementations must support integers, which are taken to be the same thing as xsd:integer values" etc. The former is fine, the latter is not (if it means not supporting arbitrary typed literals in the query language). Again, IMO, a so-called RDF query language that does not provide for arbitrary typed literals is not an RDF query language. And note, I'm talking about the query language requirements, not implementational requirements for query engines. It's fine to allow implementations to not support arbitrary typed literals and simply barf back an error message. I have no problem with that. But for those implementors who wish to support more than that minimal subset of XML Schema primitive datatypes, they should be able to do so without having to extend the standard query language. > > Much detail to sort out, of course, especially the matters of value > comparisions you mention and the implications on databases. Fair enough. My comments were simply attempting to point out that support of arbitrary typed literals has no explicit treatment in the latest documentation I read, and I am simply encouraging the WG to add it, even if in brief, so that folks who care about such matters get some indication of its anticipated inclusion in the end deliverables. Particularly since support of arbitrary typed literals is not a trivial feature. Cheers, Patrick > > Andy >
Received on Tuesday, 27 July 2004 07:17:16 UTC