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

Re: Technical tweaks to the MT, for reviewers.

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Fri, 08 Nov 2002 13:39:20 -0500 (EST)
Message-Id: <20021108.133920.40877001.pfps@research.bell-labs.com>
To: phayes@ai.uwf.edu
Cc: w3c-rdfcore-wg@w3.org, herman.ter.horst@philips.com

From: pat hayes <phayes@ai.uwf.edu>
Subject: Technical tweaks to the MT, for reviewers.
Date: Fri, 8 Nov 2002 11:47:33 -0600

> 1. There is a problem I mentioned earlier with literals like 
> "badnumber"^^xsd:integer . They have to denote something, but they 
> shouldn't denote a literal value (because they, er, don't, right?) 
> The trouble is that until we go ask the datatype, RDF can't tell the 
> difference between one of these and "12345"^^xsd:integer. So in the 
> basic RDF MT, we need to say that typed literals denote something but 
> we don't yet know even if its a literal value, so it has to be in IR, 
> not in LV (as at present).
> So what do we do when we find out that it is bad? The current draft 
> invents an ad-hoc thingie (a triplet) to be the value in this case, 
> but that is not a good solution. Better would be to say that it 
> denotes some unknown but arbitrary thing which, whatever it is, is 
> not a literal value. This adds a slightly odd technical extension to 
> the definition of datatyped interpretation, which will now include a 
> new mapping IBL from datatyped literals to things in IR that are 
> *not* in LV, which are the 'things' that the literal will denote *if* 
> it is badly typed. 

I think that I would prefer the interpretation of bad literals to be
elements of LV that are not in L2V for any datatype.  I think that this is
just a stylistic preference, but there may be consequences in
more-expressive languages (such as OWL, but I can't think of any).  Perhaps
the easiest way to go would be to require bad literals just not to denote
anything in any datatype value space, and leave whether they are in LV


> Pat

Received on Friday, 8 November 2002 13:39:31 UTC

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