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

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

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Mon, 17 Sep 2001 13:00:08 +0100
Message-ID: <3BA5E5C8.3A279B6@hplb.hpl.hp.com>
To: w3c-rdfcore-wg@w3.org

> Jeremy Carroll wrote:
> > There was agreement with the treatment of equality proposed.

Brian McBride wrote:
> Jeremy, please can you explain why we need f*.  Why not just f?

Out of context that could be misinterpreted :-).

The argument, which is not bullet-proof, goes like this.

For general purpose applications our analysis suggests f, this is hence
our recommendation.

However, we do not wish to tie the hands of application developers who
have specific linguistic needs. Thus the f* can be read as true by an
application developer who may have a strong default to some given

e.g. a small company developing tools specifically for the US Hispanic
market may have a default language tag value of "es-US" (I think that's
the right one). Then any RDF input which doesn't say it isn't is then
interpreted as "es-US". 

e.g. in the same scenario, the software tool might need to have a small
footprint database and when an RDF file is loaded irrelevant triples are
immediately discarded. These are distinguished by not having language
tag "es-US". This does seem to give real advantage for f* in this

I don't find this argument convincing; but conversely I am not
sufficiently persuaded that it is the wrong way to go to want to
prohibit it. 
In many ways my argument that we are talking about the syntactic
equivalence of terms rather than a language processing model rather goes
against this; & the use of xml:lang="es-US" on the rdf:RDF tag addresses
the default language issue.

A further point, is that in M&S xml:lang processing is optional. f* is
hence justified by backward compatibility. The * in f* is the difference
between SHOULD and MUST.

Bill, do you have anything to add here?

Received on Monday, 17 September 2001 07:55:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:51 UTC