Re: RDF *already* supports literal subjects - a thought experiment

On Jul 9, 2010, at 12:54 PM, Graham Klyne wrote:

> 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 ( 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=" 
> ",10
> to denote the same as "10"^^< 
> XMLSchema#integer>, or the
> integer 10.
> ...

Hi Graham

> 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  
> 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?

No, but it would be a semantic extension to RDF, so the folk who have  
invested so much into implementing RDF as of 2004 will not support it.  
So if this is standardized, their engines will not work properly  
without changing some code. So they will not be happy, for the same  
reasons they are not happy with the current suggestion.  LIke most  
such suggestions along these lines, it will produce problems of its  
own, the most obvious being that we would then have two syntactically  
distinct but semantically equivalent ways to write every literal in  
the places where literals are permitted, requiring engines to check  
for all these different forms all the time (in fact, to check *every*  
URI in any RDF just in case it is a hidden literal.)  In the case of  
plain literals, we would actually have four such ways to write them  
instead of the two we have now.

Although its ingenious, I think this is laying land-mines for future  


> ...
> 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

IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile

Received on Friday, 9 July 2010 20:00:53 UTC