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

> 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
(lexForm,[lang],[datatype])

My initial text was something like: 
http://www.w3.org/TR/2003/WD-rdf-concepts-20030123/#section-Graph-Literal
[[
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:
http://www.w3.org/TR/rdf-concepts/#section-Graph-Literal
[[
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
http://www.w3.org/2001/sw/RDFCore/20030123-issues/#danc-02


etc.
This is linked from the third point in:
http://www.w3.org/TR/2003/WD-rdf-concepts-20030905/#section-substantive-Revisions

Looking back at the relevant minutes I see we picked option 4 from
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003May/0096.html
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.

Jeremy

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