W3C home > Mailing lists > Public > public-rdf-wg@w3.org > August 2011

Re: language-tagged literal datatypes

From: Richard Cyganiak <richard@cyganiak.de>
Date: Mon, 29 Aug 2011 16:42:26 +0100
Cc: public-rdf-wg@w3.org
Message-Id: <2EF41030-B5E5-4F1E-BAC3-4750E6B3CF8B@cyganiak.de>
To: antoine.zimmermann@insa-lyon.fr
On 29 Aug 2011, at 09:09, Antoine Zimmermann wrote:
>> Your summary omits the option that I've been advocating recently:
>> On 26 Aug 2011, at 16:22, Antoine Zimmermann wrote:
>>> B. What if it is a datatype?
>>> If it's a datatype, rdf:LangString must have exactly all the
>>> characteristics that all datatypes have. It must follow the
>>> definition. Now, the definition can either be kept as is (as in RDF
>>> 2004) or modified. B1: If we keep the RDF 2004 definition, I think
>>> we can't really do any better than what the rdf:PlainLiteral spec
>>> is doing. The difference is that we do not need to deal with
>>> untagged plain literals, so the lexical form is quite
>>> straightforward: "foo@en"^^rdf:LangString would be the abstract
>>> syntax of "foo"@en.
>> B1y: We keep the RDF 2004 definition of datatypes. rdf:LangString is
>> a datatype with empty lexical space and empty L2V mapping. The value
>> of a literal is given by the L2V mapping only if its datatype is not
>> rdf:LangString. The value of an rdf:LangString literal is the
>> tuple<lexicalform, langtag>.
> This is inconsistent. You cannot give a formal definition of datatypes, then have an instance of datatypes that does not follow the definition.

In what way does the definition I propose above for rdf:LangString not follow the definition of datatypes in RDF 2004? As far as I can see, it is perfectly consistent.

> If you really want to keep the definition as of 2004, then rdf:LangString must /either/ have a non-empty lexical space and an L2V mapping /or/ it is not a datatype. There is no other possibility.


Received on Monday, 29 August 2011 15:43:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:08 UTC