W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > April 2003

Issue jsr-118 (global datatyping)

From: Graham Klyne <gk@ninebynine.org>
Date: Wed, 02 Apr 2003 16:25:39 +0100
Message-Id: <>
To: w3c-rdfcore-wg@w3.org

Er, how did this issue end up being assigned to concepts?

Anyway, here's a proposed resolution for discussion:

Rejected, or maybe postponed.

We have much sympathy with this request.  But the working group spent much 
time exploring options to allow global datatyping of the kind requested 
here, and were unable to find a solution that allowed this and also 
preserved other strongly-desired features of RDF.  It might be possible to 
devise an alternative syntax-based approach to global datatyping, but I 
think even that would not fully capture the goals of CC/PP here, to express 
capability profile feature types in a schema separately from on-the-wire 

The current version of CC/PP formally treats all attributes as textual 
values (i.e. plain literals in RDFcore parlance).  The global datatyping 
could be achieved for CC/PP applications by continuing to formally treat 
all CC/PP attributes as textual values and:
(a) using range constraints to limit the allowed lexical values, and
(b) building the lexical-to-value mapping into the semantics of the CC/PP 
attribute properties.

(a) would require some URIs to be designated to denote classes for the 
lexical space of the datatypes used.  Currently, CC/PP uses its own URIs 
for datatypes, so this would be easily accommodated.  In practical terms, I 
see no changes to current CC/PP applications required by this change:  what 
is described above is a formal device to make CC/PP as currently defined be 
consistent with the current semantic framework.

The downside of this approach is that it is a non-standard approach to 
using literals to indicate datatype values, and it may add some complexity 
if and when future developments of CC/PP require to express comparisons 
between CC/PP attribute values and datatype values from other RDF descriptions.

Note to WG:  the suggested CC/PP approach is basically a strategy for 
implementing CC/PP under the old datatyping proposal 'S', ignoring the new 
datatyping facilities.


Graham Klyne
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
Received on Wednesday, 2 April 2003 11:49:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:54:04 UTC