W3C home > Mailing lists > Public > public-rdf-text@w3.org > April to June 2009

history lesson RE: A summary of the proposal for resolving the issues with rdf:text --> Could you please check it one more time?

From: Jeremy Carroll <jeremy@topquadrant.com>
Date: Wed, 20 May 2009 11:14:13 -0700
To: "'Pat Hayes'" <phayes@ihmc.us>, "'Boris Motik'" <boris.motik@comlab.ox.ac.uk>
Cc: "'Eric Prud'hommeaux'" <eric@w3.org>, "'Andy Seaborne'" <andy.seaborne@hp.com>, "'Alan Ruttenberg'" <alanruttenberg@gmail.com>, <public-rdf-text@w3.org>, "'Semantic Web'" <semantic-web@w3.org>, "'Sandro Hawke'" <sandro@w3.org>, "'Axel Polleres'" <axel.polleres@deri.org>
Message-ID: <000501c9d976$c9548e60$5bfdab20$@com>
> It makes it more elegant, yes, but is there really a PROBLEM here that
> needs to be solved? That is, what actual issues for users or
> implementations are posed by the presence of two literal forms? Or is
> this discomfort simply a matter of theoretician's feelings of
> inelegance or clumsiness? Because if the latter (as I strongly
> suspect), this is not a sufficient reason to attempt to retroactively
> undermine the existing RDF standard, and to deliberately create what I
> believe will be troublesome and awkward problems for an entire
> generation of implementations, and certainly for a majority of
> existing ones. Creating problems like this is exactly what W3C WGs
> should NOT be doing, especially at a critical point in the deployment
> of SWeb technology. Google just quietly announced their cautious
> support for RDFA. It is not exactly a great idea for two W3C WGs to be
> at that very moment deliberately attempting to undermine one of the
> basic aspects of the RDF design. Elegance, is, frankly, not of central
> importance right now.

I haven't been following this thread, so forgive me if I am off-beam here, but trying to be helpful.

When this peculiar design
 (lexForm) or (lexForm,lang) or (lexForm,datatype)
Was being developed, there were some in RDF Core (e.g. me) who preferred

My initial text was something like: 
A literal in an RDF graph contains three components called:

    * The lexical form being a Unicode [UNICODE] string in Normal Form C [NFC].
    * The language identifier as defined by [RFC-3066], normalized to lowercase.
    * The datatype URI being an RDF URI reference.

The lexical form is present in all RDF literals; the language identifier and the datatype URI may be absent from an RDF literal.

A plain literal is one in which the datatype URI is absent.

A typed literal is one in which the datatype URI is present.

This was rejected by the WG, who preferred text like:
A literal in an RDF graph contains one or two named components.

All literals have a lexical form being a Unicode [UNICODE] string, which SHOULD be in Normal Form C [NFC].

Plain literals have a lexical form and optionally a language tag as defined by [RFC-3066], normalized to lowercase.

Typed literals have a lexical form and a datatype URI being an RDF URI reference.

The RDF Core WG was in the main not theoreticians, but more engineers.
They preferred a less elegant but clearer formulation. 

The actual issue was

This is linked from the third point in:

Looking back at the relevant minutes I see we picked option 4 from
I think the msg title "ugly parade" is telling. We knew that we are making a bad choice, but all the choices are bad. And unless you appreciate that all the choices are bad, you haven't understood the problem - and once you have, you see that the current inelegance is just one of a range of not good choices, and there isn't much reason to switch from one not-so-good choice to another not-so-good choice.

In terms of the actual issue being presented this special text datatype, I see it as a plausible name for some implementation detail, but I don't much like it getting out onto the wire: that seems to be trying to redesign something that is probably best left alone.

Received on Wednesday, 20 May 2009 18:15:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:43 UTC