Re: resend: Fwd: I18N Comments]

At 11:58 17/07/03 +0100, Brian McBride wrote:
>On Tue, 2003-07-15 at 16:48, Graham Klyne wrote:
>
>[...]
>
> >
> > My impression is that no showstopper has been identified, but the current
> > approach will be quite painful for some.
>
>Have we identified whom?

Since you ask, application developers, I guess (more than tool developers).

If I were writing an RDF application that dealt extensively with properties 
containing human readable text (e.g. properties like rdfs:comment or 
foaf:name, which I think might include applications like your meeting 
assistant), which might also reasonably contain some kind of additional 
markup (HTML tags, Ruby?), then I think that I would find having two 
different ways of handling language tags would be a real pain;  it would 
create alternative code-paths where there should really be just 
one.  Having to add things like the suggested <span> elements to convey 
language information would, I think greatly complicate some of those paths 
to the extent that some developers might be tempted to skip handling those 
forms of data that might be needed for effective I18N.

...

I started in this debate feeling quite neutral, but the more I think about 
it the more I find that I dislike the special treatment of XML in RDF.

All of the actual RDF applications I've contemplated use literals in one of 
two ways:
(a) as human-readable text, and
(b) as simple data values with their own formatting rules and other properties.

In the past, I never really considered there to be an important role for 
XML *within* RDF literals, and have been happy enough to let others drive 
that aspect of the design in ways they thought useful.  But the proposition 
that XML in RDF literals is provided to extend the range of human-readable 
text is one that I find compelling, particularly in the face of I18N, and 
one that doesn't really sit comfortably with the current design (for 
reasons like those noted above, and in Pat's earlier message [1]).

I think our datatyping design does gives us a very clear and direct way to 
avoid this problem of "how shall we treat XML - as text with markup or as a 
formal data representation language?", as I noted previously [2]:

[[
Finally, I observe that dropping XML literals from the RDF specification 
does not preclude the later introduction of XML literals as currently 
defined -- they are simply another datatype.  The difference would be that 
said datatype is not automatically signalled by the presence of 
parseType="Literal".
]]

The treatment of any XML as anything other than text-with-possible-markup 
can be indicated, as with any other form of literal text, by the 
application of a datatype.

...

I also find myself revisiting the question:  what is the purpose of 
language tagging in RDF?  I think we agreed some time ago (can't find 
record) that the purpose of a language tag was not for presentation, but 
for recording additional information about the content.  To the extent that 
human readable text is opaque to automated systems (cf. social meaning 
debate), I'm wondering why it's so important at all.  Ho hum.

#g
--

[1] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jul/0067.html

[2] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jul/0155.html


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

Received on Thursday, 17 July 2003 09:30:33 UTC