Re: language-tagged literal datatypes

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.
>
> 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.

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/
>>
>


-- 
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 08:09:56 UTC