RE: Encoding arbitrary literals in RDF/XML

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.

You could further say e.g.

   ex:someProperty rdfs:range xsd:base64Binary .

which would allow one to infer that all objects in statements
employing that predicate denote members of the value space of
xsd:base64Binary, which is a good way to inform applications
regarding the nature of base 64 encoded values.

Granted, the values will have to be base 64 encoded when
serialized in the RDF/XML -- rather than output as human
readable Unicode strings in the RDF/XML, but whether that
is a serious issue I guess depends on whether you are using
the RDF/XML for machine-to-machine interchange, or whether
humans are manually touching/consuming the RDF/XML. In the
latter case, it could be a bit inconvenient.



-----Original Message-----
From: on behalf of ext Arjohn Kampman
Sent:	Wed 2004-09-22 17:30
Subject:	Encoding arbitrary literals in RDF/XML

Dear all,

We're currently discussing a literal serialization issue on the
Sesame/ forum[1]. Reason for this discussion is that XML does
not support the full range of Unicode characters. More specifically,
the issue concerns the null character (hex value 0x0). From what I've
learned about Unicode in the past days, I understand that this is a
perfectly legal Unicode character, but the XML specs do not allow you to
include it in an XML document. Support for these kinds of exotic
characters has been increased in XML 1.1, but it still doesn't include
the full range.

A workaround that I have been thinking about is to encode such literals
in hex or base64 and to include an attribute in the surrounding element
that indicates this. This sounds like a bit of a hack, though, and I'm
not sure whether this is completely standards compliant. Therefore, I
would highly appreciate any feedback or suggestions on how to solve this




Aduna BV -
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 08:38:54 UTC