Re: language-tagged literal datatypes

I agree with Andy. The key points about a datatyped literal are that it (1) display the datatype IRI and (2) this datatype provides an unambiguous way to determine the syntactic correctness of the literal and if it is correct, a way to compute its value. All the rest of the machinery is simply there to serve this purpose. Cleaving to the current mathematical/semantic rules is good to avoid unnecessary disruption, but they should not be considered inviolate. In this spirit, I now think Richard's 2b option to be the best way to proceed, and we will just swallow the oddity of rdf:LangString not having a conventional L2V mapping. In all other respects, this retains exactly what we all need and desire. It is the simplest and least disruptive option. 

Pat


On Aug 29, 2011, at 8:57 AM, Andy Seaborne wrote:

> 
> 
> On 29/08/11 09:09, Antoine Zimmermann wrote:
>> Richard,
>> 
>> Le 27/08/2011 18:29, Richard Cyganiak a écrit :
>>> Hi Antoine,
>>> 
>>> 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.
> 
> str("foo"@en) is already "foo"
> 
>>> 
>>> 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.
>> It's like saying that prime numbers are numbers that are only dividable
>> by 1 and by themselves and that 9 is a prime number dividable by 1, 3
>> and 9. It cannot be, it's broken.
>> 
>> 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.
> 
> owl:Real is a existing counterexample to the 2004 defn.  "The owl:real datatype does not directly provide any lexical forms."
> 
> The "non-empty lexical space" restriction seems to be artificial. Empty, and some other way to form values, works just as well albeit with specific rules for each datatype.
> 
> 	Andy

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 29 August 2011 14:11:56 UTC