RDF *already* supports literal subjects - a thought experiment

It has already been suggested that data: URIs provide a way to implement
subjects-as-literals in RDF.  I thought it might be worth fleshing this out a
little to see where it leads...

...

A data: URI (http://tools.ietf.org/html/rfc2397) has the following general form:

   data:[<mediatype>][;base64],<data>

For representing literals (which are, after all, sequences of characters), we
can probably disregard the [;base64] option.

To distinguish data: as literals, I would suggest introducing a new MIME type, say:

   application/rdf-literal [;datatype=uri] [;language=<lang-code>]

where datatype= indicates a typed literal, and language may be present for
non-typed literals.

(%-escaping would be applied as necessary for the data: URI to conform to URI 
syntax.  I won't worry with the details in this message.)

Thus, we can have:

   data:application/rdf-literal,Hello%20world

intended to denote the same thing in RDF as the plain literal "Hello world", or:

   data:application/rdf-literal;language=fr,Bonjour%20monde

to denote the same as "Bonjour monde"@fr (using Turtle notation here for the
literal), or:

data:aplication/rdf-literal;datatype="http://www.w3.org/2001/XMLSchema#integer",10

to denote the same as "10"^^<http://www.w3.org/2001/XMLSchema#integer>, or the
integer 10.

...

So far, all this should lead to intended-literals in subject position that can
be read by any existing RDF/XML consuming application.

What I'm less sure about is fixing the semantics:  as it stands, the RDF
semantics is expressed in terms of allowing arbitrary interpretations --
mappings to things in the domain of discourse -- for all URI nodes in a graph.
Would it be unreasonable or problematic to say that, for this particular form of
URI, the  denotation is fixed by the same general rules that govern the
denotation of literals?

...

A side effect of this approach might be that if a web server were to dereference
a URI to a value returned with MIME type application/rdf-literal, then for
overall consistency that would constrain the semantics of the URI used to
access such a resource (subject to the usual caveats about not everything
in the web being a truth).

...

I think an approach like this maybe could avoid the objections vis-a-vis 
deployment economics to allowing literal subjects, and leave a path clear for 
some future development (e.g. N3 based) that allows literals more directly.

#g

Received on Friday, 9 July 2010 17:56:10 UTC