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

Re: handling bare literals and PS a Q. about lang tags

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 6 Sep 2002 14:29:24 +0300
To: w3c-rdfcore-wg@w3.org, "ext pat hayes" <phayes@ai.uwf.edu>
Message-ID: <NyFGhwJdvrfx.ZkdbZ3qh@mail.nokia.com>

_____________Original message ____________
Subject:	handling bare literals and PS a Q. about lang tags
Sender:	ext pat hayes <phayes@ai.uwf.edu>
Date:		Fri,  6 Sep 2002 13:39:04 +0300

Patrick's document up to section 6 describes how to handle datatyped 
literals (and does it fine), but I think that its rather strict 
rejection of 'bare' (ie un-datatyped) literals is rather extreme. I 
have a suggestion for how to handle bare literals which is entirely 
compatible (in fact, I think more compatible) with the treatment of 
datatyped literals, and has a few other advantages as well.

In brief, the idea is to treat a bare literal as being a datatyped 
literal with a bnode as its datatype. That is, it means 'some 
datatyping of this literal but we don't know which one right now'. 

	Umm, err, ahem...

	Perhaps you read section C.2 of part 2 of the restructured
	datatyping document or perhaps the previous
	version of the datatyping document (just before
	restructuring) and forgot ;-)

	Both propose precisely what you are proposing.

	I found your re-expression of this approach to match my
	proposal perfectly, and to that end support it

Finally, one alternative is to do all the above but ALSO allow bare 
literals as legal nodes, and require them to follow Dan's preferences 
and denote themselves. 

	I don't see how you would distinguish between 'bare'
	literal nodes and implicitly typed literal nodes in the

	Better to just specify xsd:string or the like either
	explicitly or via a property range.

If the WG feels this is worth bothering with, I could wrote this up 
as a draft in a few days.

	With all due respect, it's already written up, and the WG has 
	been provided with two documents outlining the approach


PS. Catching up on last weeks emails....re. the xml:lang tag, might 
there be some interaction between this and the lexical forms for 


 Eg I gather than in Germany, commas are used for a 
decimal point, so we might for example have
(xsd:real, "10,5") -en .
being invalid but
(xsd:real, "10,5") -gr .
refers to ten and a half.

	Pat, we resolved this issue ages ago. Locale issues
	relating to presentation are not relevant to datatyping.
	It  is a user interface issue. Specific datatypes such as
	xsd:integer and xsd:date define their lexical spaces as
	they like, and mapping to/from local representations
	is up to the applications.

Received on Friday, 6 September 2002 07:32:54 UTC

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