W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > July 2001

rdfms-xmllang alternatives

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Mon, 16 Jul 2001 22:28:09 +0100
Message-ID: <3B535C69.1B163015@hplb.hpl.hp.com>
To: rdf core <w3c-rdfcore-wg@w3.org>
I took an action at the last teleconference to write up
alternative ways of resolving this issue.

Option 1: No Change

xml:lang attributes are considered to be 'part of' a literal.

This is an issue that has caused some confusion amongst developers
so we would need to write up a clarification of the specifications
to explain more clearly what is going on.

We would also need to modify n-triple to be able to represent the
languague component of a literal.


This is the simplest resolution.  It makes significant change to
M&S and existing RDF processors which implemented the spec will
be unaffected.  It requires only one triple to represent a
property with a literal value.


Does not represent language as a triple so requires special
purpose processing to support, for example query.

Option 2: Anonymous resource

An xml:lang attribute would trigger the creation of an anonymous
resource with two properties, one to indicate the language and
the other the value of the literal, e.g.

  <foo:bar xml:lang="en">foobar</foo:bar>

becomes (please forgive the shorthand):

  _:a <foo:bar>    _:b .
  _:b <xml:lang>   "en" .
  _:b <rdf:value> "foobar" .


Uses standard triple representation so needs no special handling
for query or model processing.


Properties with a language attribute are represented by a different
triple structure from those without (though those without could
be represented in a similar structure with the xml:lang property

Requires three triples to represent a literal property value
instead of 1.

Is a change to what M&S currently specifies.

Interacts with the interpretation of rdf:ID, e.g.

    <foo:bar rdf:ID="id" xml:lang="en">foobar</foo:bar>

The rdf:ID attribute doesn't seem to identify quite the same
thing it did as specified in M&S.

Option 3: Encode the language in the property

Define a mapping from URI X language <-> URI which given
the URI of a property and a language will generate the URI
of a sub-property which encodes the language attribute, e.g:

    <foo:bar xml:lang="en">foobar</foobar>


  _:a  <foo:bar-en> "foobar" .


This doesn't work.  We don't own the namespaces in which
properties are defined so have no right to go reserving
sections of them.

This solution also relies on the schema concept of subPropertyOf.


Option 4: Language Specific SubProperties

Encode the language attribute in the property, but require the
user to define the language specific sub-properties.



Relies on an RDF Schema concept.

No easy way to query for all properties with an English value.

Option 5: Interpretation Properties

Define a standard modeling technique and set of properties,
so that instead of writing:

    <foo:bar xml:lang="en">cat</foo:bar>
    <foo:bar xml:lang="fr">chat</foo:bar>

the user writes:

    <foo:bar rdf:parseType="Resource">

This option can be combined with option 1, or alternatively the
current processing of xml:lang may be withdrawn and this option
recommended in its place.


less overhead than option 2

does not rely on RDF Schema concepts


can query for all properties with an English value.

no special handling required


This is a change to what is described in M&S.

Option 6 Automatic Interpretation Properties

Interpret xml:lang attributes to generate the structure of option 5.

    <foo:bar xml:lang="en">cat</foo:bar>
    <foo:bar xml:lang="fr">chat</foo:bar>


  _:a <foo:bar> _:b .
  _:b <lang:en> "cat" .
  _:b <lang:fr> "chat" .

We could define this behaviour, however there is no guarantee this
is what the author meant to express, e.g.:

    <hotel:guest xml:lang="en">Aaron</hotel:guest>
    <hotel:guest xml:lang="fr">Pierre</hotel:guest>

Here the author means to express that there are two different guests,
one called Aaron and the other called Pierre.

So ruled out because it does not work.

Option 7  Do nothing for now and Reconsider along with Type's

We are chartered to consider how to use XML Schema data types
in RDF models.  This issue might best be considered at the same

Received on Monday, 16 July 2001 17:30:39 UTC

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