Re: language-tagged literal datatypes

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

>
> Then, you end up with the cases that I mentioned in my mail.
>
>
> --AZ
>
>
>>
>> I see this as better than B1 because it doesn't introduce lexical
>> forms and then forbids their use, like rdf:PlainLiteral does.
>>
>> I see this as better than either of the B2 options because it
>> minimizes the deviation from RDF 2004 and doesn't disagree with XSD.
>>
>> Best, Richard
>>
>>
>>> B2: If we change the definition of datatypes, I can see two ways:
>>> *B2x: do as Pat suggested, that is, allow the lexical space to
>>> contain tuples; then everything else follows the standard
>>> definitions (DATATYPE("foo"@en) is as per the normal rule, the
>>> semantics is as per the normal semantics of typed literals, etc)
>>> *B2y: include in the definition of datatypes an exception, that is,
>>> say "A datatype is either: (i) a combination of 3 parts: lexical
>>> space, value space and L2V; or (ii) rdf:LangString. Then you have
>>> to define the semantics of rdf:LangString literals differently from
>>> other types, since there is no L2V. DATATYPE("foo"@en) would follow
>>> the normal rule.
>>>
>>> Whichever path we choose, we could also introduce language-specific
>>> datatypes.
>>>
>>> Personally, I have no problem with B1, it's straightforward, has
>>> the advantages of rdf:PlainLiteral without the awkward "@" for
>>> non-lang-tagged strings (since it does not deal with
>>> non-lang-tagged strings at all) and it has a better name. Then I
>>> prefer B2x over B2y, but could live with either solutions.
>>>
>>>
>>> Hope this helps, -- Antoine Zimmermann Researcher at: Laboratoire
>>> d'InfoRmatique en Image et Systèmes d'information Database Group 7
>>> Avenue Jean Capelle 69621 Villeurbanne Cedex France Tel: +33(0)4 72
>>> 43 61 74 - Fax: +33(0)4 72 43 87 13 Lecturer at: Institut National
>>> des Sciences Appliquées de Lyon 20 Avenue Albert Einstein 69621
>>> Villeurbanne Cedex France antoine.zimmermann@insa-lyon.fr
>>> http://zimmer.aprilfoolsreview.com/
>>>
>>
>
>

Received on Monday, 29 August 2011 13:57:45 UTC