W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2002

Re: xml:lang [was Re: Outstanding Issues ]

From: Dave Beckett <dave.beckett@bristol.ac.uk>
Date: Wed, 13 Feb 2002 11:08:10 +0000
To: Patrick Stickler <patrick.stickler@nokia.com>
cc: RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <8839.1013598490@tatooine.ilrt.bris.ac.uk>
>>>Patrick Stickler said:
> Because the above is not the case. No RDF parser I've used thus far
> uses anything but a string representation for a literal, nor gives any
> regard to xml:lang attributes. None of the examples I have ever
> seen either in the rec or elsewhere has ever used a representation
> other than a simple string for a literal. All of the datatyping and MT
> discussions concerning literals strongly suggests the common view
> that literals have simple string representation.

Jeremy's Java ARP parser does:

    "xml:lang is fully supported, both in RDF/XML and any document
    embedding RDF/XML."
    -- http://www.hpl.hp.co.uk/people/jjc/arp/

and so does the Java RDFFilter as Ron noted.

I intend my C parser Raptor to do so also, but I've been
concentrating on the core aspects of the code (passing the test cases).

> Now, that may simply mean that the M&S is right and everyone has
> been completely ignoring it. Shame on us and a hundred lashes with
> a wet towel. But if literals were structured objects,
> I would expect to see implementations reflecting that (your's may
> be the first and only).

There are implementations that use this:

  Jena - Java (Brian, Jeremy, HP Labs et al)

    public java.lang.String getLanguage()
       If a language is defined for this literal return it
    -- http://www.hpl.hp.com/semweb/javadoc/com/hp/hpl/mesa/rdf/jena/common/LiteralImpl.html#getLanguage()

  Redland - C/Perl/Python/Java/... (me)
    librdf_node_get_literal_value_language - Get the XML language of the node
    -- http://www.redland.opensource.ac.uk/docs/api/node.html

but there are, of course, implementations that use just strings for
literals.  Both of these were and are legitimate choices from the M&S

I liked what the Mozilla project/Netscape 6.x said:

    As with resources, the function that maps a literal to a string
    value is one-to-one. Hence, it is possible to identify each
    literal using its string value. The RDF Model and Syntax
    Specification explicitly states that the mapping from literal to
    string value need not be one-to-one; we've chosen to make the
    mapping one-to-one to allow for efficient comparison of
    literals. Informally, a literal is a primitive value that has no
    "first-class identity"; for example, a string, a date, or a

  -- http://www.mozilla.org/rdf/back-end-architecture.html

and in the code they uses literal strings, dates, integers and blobs

> That said, our options appear to be that either we
> a) change to a structured representation for literals everywhere, or
> b) generate triples in some fashion to capture the language context
>    in the graph, or
> c) say that xml:lang only lives in the XML space, for RDF parsers,
>    but not in the RDF space, in the graph, for RDF applications.
> Thus whether or not you would need to change your code (or everyone
> else would ;-) depends on whether the M&S is kept as stated
> or changed on this point.

Changing my code isn't something I have a problem with.

The problem is explaining why we are changing the model to the many
people who have used xml:lang.

I think all RDF Schemas I've seen use it, and all RDF Tutorials, most
all articles about RDF mention it.  If we now change this, the people
who read M&S and used it (and read RECommendation), deserve a good

> My assertion that the M&S got it "wrong" is the expression of an
> implicit common consensus based on what I see as pervasive practice
> and perception that literals have simple string representation in
> the graph. If there is evidence otherwise then I'm quite happy to
> stand corrected (and take my wet towel lashings like a man ;-)

I think I've shown that there is evidence of practice as literals !=
simple string, however yucky that is :(

Received on Wednesday, 13 February 2002 06:08:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:10 UTC