Re: language-tagged literal datatypes

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.

Why?

Best,
Richard

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