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.

Advantages:

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.

Disadvantages:

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.

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

becomes (please forgive the shorthand):

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

Advantages:

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

Disadvantages

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

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.

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

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:

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

becomes:

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

Disadvantages

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.

ITS JUST HORRIBLE!


Option 4: Language Specific SubProperties
=========================================

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

  <rdf:Description>
    <rdf:bar-en>foobar</rdf:bar-en>
  </rdf:Description>

Disadvantages:

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:

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

the user writes:

  <rdf:Description>
    <foo:bar rdf:parseType="Resource">
      <lang:en>cat</lang:en>
      <lang:fr>chat</lang:fr>
    </foo:bar>
  </rdf:Description>

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.

Advantages

less overhead than option 2

does not rely on RDF Schema concepts

straightforward

can query for all properties with an English value.

no special handling required

Disadvantages

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.

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

becomes:

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

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

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


Brian
Received on Monday, 16 July 2001 17:30:39 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:38:11 EDT