W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2004

Re: Encoding arbitrary literals in RDF/XML

From: Arjohn Kampman <arjohn.kampman@aduna.biz>
Date: Thu, 23 Sep 2004 12:08:58 +0200
Message-ID: <4152A0BA.4090700@aduna.biz>
To: Patrick.Stickler@nokia.com
Cc: www-rdf-interest@w3.org

Patrick.Stickler@nokia.com wrote:
> If you mean saying something like
>    ex:someThing ex:someProperty "..."^^xsd:base64Binary .
> where "..." is the base 64 encoded lexical form, then I 
> don't consider that a hack at all, but a valid and proper
> use of typed literals. After all, rdf:XMLLiteral is only
> one possible datatype that can be used to express a typed
> literal value.

Well, I'm afraid this is not what I meant. Sesame is a generic
RDF toolkit for storing whatever RDF data is thrown at it. Currently,
you can upload data to it in RDF/XML, Turtle and N-Triples format and
then query and export this data, possibly in another format. The
question I have is: what should we do if someone uploads
N-Triples/Turtle-data containing literals like "...\u0000..." and then
wants to export this in RDF/XML format?

One option would be to throw some "SerializationException" when trying
to export such data in RDF/XML. Another option would be to disallow the
"non-XML" characters altogether, even when encoded in Turtle or
N-Triples. Third option would be to transparently encode and decode
incompatible strings in e.g. base64. Note that the last option does not
mean replacing the literal with another one that has datatype
xsd:base64Binary. That would be unacceptable as it would change the
semantics of the RDF graph.

DanC already suggested on the rdfig irc to send an e-mail to
rdf-comments, requesting a clarification of the RDF specs concerning
this issue. But I guess it doesn't hurt discussing it here first.


Aduna BV - http://aduna.biz/
Prinses Julianaplein 14-b, 3817 CS Amersfoort, The Netherlands
tel. +31-(0)33-4659987  fax. +31-(0)33-4659987
Received on Thursday, 23 September 2004 10:09:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:53 UTC