W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > September 2001

Re: 2001-09-07#5 - literal problem

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Thu, 13 Sep 2001 17:16:42 +0100
Message-Id: <>
To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Cc: <w3c-rdfcore-wg@w3.org>
At 02:39 PM 9/13/01 +0100, Jeremy Carroll wrote:
>Questions for WG for tomorrow:
>+ Does the WG agree that a Literal is a <Unicode String,RFC 3066> pair?

A thought:  why not a <Unicode string,URI> pair?  RFC 3066 tags could be 
embedded in URI space using (say) 
This would provide a mapping for xml:lang attributes, but would also leave 
a possible route forward for qualifying a literal with (say) XML schema 
datatype URIs.

>+ Does the WG agree that Literal equality should be defined?

I'm not sure about this.  If the model theory needs this idea, then 
yes.  The mapping
   XL : qLiteral -> LV
suggests to me that some concept of equality is required by the MT 
(otherwise the idea of a fixed interpretation doesn't make sense to 
me).  Other than that, it's not clear to me that a notion of equality 
defined by RDF will necessarily be useful to all RDF applications.

For this purpose, I think your notion of equality is about right:
When comparing two RDF Literals, their Unicode strings must be
equal for the RDF Literals to compare as equal. If both Literals
have language tags, these tags must be equal for the Literals to
be considered equal. If two Literals are found equal but only
one has a language tag, the Literals should not*** be considered

The equality of Unicode strings is specified by W3C I18N WG;
see [fixme:url]. Language tag equality is defined by RFC3066
and is case insensitive.

>+ Does the WG agree that the new specs should descibe a specific Unicode
>string to be delivered by rdf:parseType="Literal"?

I must confess I'm not very clear what this means.


Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
Received on Thursday, 13 September 2001 12:39:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:04 UTC