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

Re: language-tagged literal datatypes

From: Richard Cyganiak <richard@cyganiak.de>
Date: Sat, 27 Aug 2011 17:29:08 +0100
Cc: public-rdf-wg@w3.org
Message-Id: <F1C47357-B2DF-451A-B241-6921D2BB4CB7@cyganiak.de>
To: antoine.zimmermann@insa-lyon.fr
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>.

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 Saturday, 27 August 2011 16:31:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:44 GMT