RE: Change in definition of RDF literals

Hi Martin,

I started three separate times to respond to your message,
but stopped each time because I didn't want to again
open up this terrifyingly complex issue unnecessarily.

After sleeping on it, I decided I would at least try to offer
the following brief comments which I hope will satisfy your
concerns -- at least (hopefully) to the point of being able to 
live with the WG's latest proposal.

> -----Original Message-----
> From: ext Martin Duerst [mailto:duerst@w3.org]
> Sent: 21 May, 2003 16:29
> To: Graham Klyne; Jeremy Carroll
> Cc: w3c-rdfcore-wg@w3.org
> Subject: Re: Change in definition of RDF literals
> 
> 
> 
> Overnight, I was thinking a bit more about the wider issues at hand.
> 
> It appeared to me that there are three different ways to have
> a simple string in RDF:
> 
> <foo xml:lang=''>Hello World!</foo>
> <foo xml:lang='' parseType='Literal'>Hello World!</foo>
> <foo 
> rdf:datatype='http://www.w3.org/2001/XMLSchema#string'>Hello 
> World!</foo>
> 
> All three are plain strings without language, but they are
> represented slightly differently in RDF.

While on the surface, these three forms of expression may appear to be
equivalent, they are not, because in general (not necessarily
the above case) (a) there can be entailments
that hold for XML literals due to canonicalization that do not
hold for plain literals and (b) RDF does not explicitly define
any equality between plain literals, XML literals, and xsd:string
values (even if the specs are sufficiently informative to allow
some application to presume such equalities).

Treating all non-typed literals as XML literals, such that there
would no longer be "plain" literals, will likely result in alot
of confusion and angst by users who will not understand what
XML canonicalization is all about and simply want to use plain
simple string values.

So there is a clear need, IMO, to keep plain literals and
XML literals distinct.

> What the recent decision of the RDF WG has done is that it has
> said that the xml:lang='' in the second variant is unnecessary.

Yes, but...

We have not said that lang tags are not applicable *within*
XML literals. Thus we are not removing the ability to qualify
an XML literal for language using xml:lang, we are simply moving
such qualification into the domain of the literal itself so that
the datatyping model is greatly simplified and far more consistent.

> But this doesn't look like it has addressed the underlying problems.

I'm not really sure what underlying problems you are referring to.
Perhaps you could elaborate if these comments do not prove sufficient
to allow you to live with this latest decision.

I find that one of the benefits of treating XML literals as
a datatype is that it provides a solid foundation for later
supporting XSD complex types as subclasses of rdfs:XMLLiteral.

I also personally feel that, for RDF, xml:lang is not the ideal
mechanism to use for language scoping (prefering a solution based
on reification myself) and so am not myself particularly sympathetic
to the loss of lang tags on XML literals.

And since XML literals *are* different animals than plain literals,
and also since it is quite straightforward to specify an xml:lang
attribute within any XML literal, I don't see that we are losing
anything here (except undue complexity in the whole datatyping
solution).

Is it a perfect solution? Heck no. But no'one in their right mind
expects a perfect solution where RDF datatyping is concerned.

All in all, though, I think the new proposal achieves an optimal
balance between the needs of content producers and tool implementors
(and I hold that opinion as a member of both groups).

Cheers,

Patrick


> Regards,    Martin.
> 
> At 18:50 03/05/19 +0100, Graham Klyne wrote:
> >At 08:38 19/05/03 -0400, Martin Duerst wrote:
> >>I think one way to see it is that the underlying problem is the use
> >>of a datatype of rdf:XMLLiteral for parseType='Literal' is rather
> >>artificial. When I read that for the first time, I thought that it
> >>might be nice to allow XML Schema complex types there, which
> >>would allow validation of the contents, and would bring simple
> >>types and complex types closer together.
> >>The alternative solution is to not treat parseType='Literal' as
> >>a type at all, but as something separate, as a basic literal in
> >>and by itself. One way to go would be to treat all literals as
> >>being XML, with the simple case just having no markup. The
> >>N-triples notation then would maybe just use some elements
> >>of XML syntax, such as &amp; and &lt;. Just an idea.
> >
> >On reflection, I think this last idea is a logical step on from the 
> >decision we reached last Friday, in that it removes the special-case 
> >datatype, which I think is a further useful simplification.  
> I think we 
> >were forced to consider XML literals separately from 
> ordinary literals 
> >when we were trying to accommodate the namespace issues, but having 
> >dropped that idea I think distinguishing XML may be no longer needed.
> >
> >parseType="Literal" then becomes a pure syntactic device to 
> prevent the 
> >enclosed literal from being interpreted as RDF, which to my 
> mind is far 
> >closer to the form of literals that I understood to be 
> presented in the 
> >original RDF M&S.  Non-XML serializations of RDF simply 
> don't have to be 
> >aware of XML literals, which I think is a Good Thing.
> >
> >#g
> >
> >
> >-------------------
> >Graham Klyne
> ><GK@NineByNine.org>
> >PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
> 
>

Received on Thursday, 22 May 2003 04:26:21 UTC