W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2002

RE: RDF concepts

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Fri, 25 Oct 2002 13:41:51 +0200
To: "Patrick Stickler" <patrick.stickler@nokia.com>, <w3c-rdfcore-wg@w3.org>

> Please begin vigorous backpeddaling ;-)
>   ... I suggest the WG should prefer an
> acceptable alternative

Having achieved the near miracle of getting Brian and Patrick to agree on
something ...

I won't backpedal before today's telecon but thought I should sketch the

0) rewording to satisfy Patrick's "the lexical form is not a pair"
I stuck the lexical form is a pair in very late in the day, to try and get
section 2.4.4 to flow more smoothly. See below.

1) (only very slight change)
  Explicitly prohibit datatypes other than the two predefined types from
using the language identifier in the map. This could be accompanied by (0).

2) back to 'majority' view
  This is like (1) except that the two predefined datatypes are instead
expanded as two alternative types of literal. The language IDs are present
and ignored.

3) back to (nearly) 'minority' view
   In the datatyped literals there is no language identifier.
(This seems to be Brian's preference)

lexical form explanation:

The text I had problems with was:
The datatypes used in RDF have either:

+ A lexical space consisiting of a set of strings (for example any datatypes
from XML Schema).

+ A lexical space consisiting of a set of pairs: each being a string with a
language tag (for example the two predefined types).
and some of the other text in 2.4.4.

This is where the pair (string + lang) originated from.

 I could change this to be either a set of stings (first bullet) or a set of
literals (second bullet) [a literal being a triple: including the (constant)
datatypeURI]. That way I could drop the pair/pair way of expressing a


I note that the chair is weighting concerns about potential feedback we
might receive more highly than the actual feedback we have already received.

Received on Friday, 25 October 2002 07:41:59 UTC

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