W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2004

RE: BRQL and typed literals

From: <Patrick.Stickler@nokia.com>
Date: Tue, 27 Jul 2004 14:16:48 +0300
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B02A2E9C2@trebe006.europe.nokia.com>
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.



> 	Andy
Received on Tuesday, 27 July 2004 07:17:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:44 UTC