Status: RO
The question of internationalisation came up at the
meeting last week, in connection with the provision of
descriptions in different languages for the items in a
controlled vocabulary.
I mentioned that I had written a note in April to a few
people involved in RDF and DC, and I agreed to forward it to
the DC Data Model list. This became action number 6 in Stu's
list:
>6. Charles will forward a series of limited distribution mail
>concerning DC-I18N to DC-DMWG.
I am also sending a copy to the DC International list, as
the topic is relevant, but please follow up to the DC Data
Model list only.
See http://www.mailbase.ac.uk/lists/dc-datamodel/ for how to join
that list, or mail Misha Wolf ([log in to unmask]).
For the benefit of those who have already seen this mail, I have
not made any changes, so that they don't have to read it again.
I have just removed the references to the weather.
The only reply I received was from Renato Ianella, but I am not
including it here as I don't have his permission.
Renato -- do forward your message if you think it is relevant.
On re-reading the mail below, I think most of what I wrote still
stands, but I would add one thing: I have not used the RDF Alt
construct, because it is not possible to add properties onto a
single Alt list from two different RDF documents (eg two
documents in different languages). You *can* add properties onto
a single node that is not an Alt.
Regards,
Charles [log in to unmask]
=======================================================
Message from 15 April:
The question of the internationalization of Dublin Core
came up a couple of weeks ago when Misha and I were
talking to Eric on the phone. I had some ideas, and
Misha asked me to write them down.
The question is how we construct schemas for DC suitable
for use by people from anywhere in the world. The
single-word label obviously does not change. The full
name of the element, its description, and any other helpful
text needs to be translated. We need to decide how this
should be packaged so that the user gets presented with
the right version, but the versions must still be easy to
maintain.
I am torn between two approaches. With Misha not here,
and no-one to discuss them with, I have decided to present
both of them as a starting point.
I have in mind a situation where a user is using a general-
purpose metadata editor. When I say "general-purpose", I
mean not dedicated to the Dublin Core element set, but
configured by RDF schemas to be able to be used for editing
metadata that uses any vocabulary.
I think there is no objection to defining new RDF property
types for the use of such editors. The main problem here
is knowing what namespace to use, because the name will
typically depend on which consortium defines these property
types. For the moment I will use the namespace "XXX".
I am trying to use "locale" and not "language". These are
easily confused. The codes used are very similar,
eg the RFC 1766 language "en-GB" is often used in places where
the locale is set to "en_GB" (my best reference for use of the
underbar in locales is the POSIX standard ISO/IEC 9945-2:1993,
but I don't have a copy myself).
==========================================================
Approach number 1
In this approach, we bundle together all the definitions for
a particular locale in a single RDF file, say elements_en_US.rdf.
[This is modelled on the way Java properties are handled:
I try never to invent anything myself.
<http://java.sun.com/docs/books/tutorial/i18n/>
It is also how Reggie does it of course, but using directory
names I think.]
So the file elements_fr.rdf may contain:
<RDF:Description RDF:href="http://purl.oclc.org/metadata/dublin_core#Title">
<RDF:instanceOf RDF:href="http://www.w3.org/TR/WD-RDF-Syntax#PropertyType"/>
<RDFS:necessity RDF:href="http://www.w3.org/TR/WD-RDF-Schema#ZeroOrMore"/>
<RDFS:Comment xml:lang="fr">Le nom donné à la ressource par
le créateur ou l'auteur.</RDFS:Comment>
<XXX:name xml:lang="fr">Titre</XXX:name>
</RDF:Description>
etc
The editor would somehow selectively load the correct RDF files
into its memory, so that the entry "Titre" appears on the drop-
down list of possible property types, but not "Title".
And when this property type is selected, the French help text
appears, and not the English.
This selective loading could be done by providing another
file containing this:
<RDF:Description ID="DCSelection">
<XXX:LocaleOption>
<RDF:Description>
<XXX:Locale>fr</XXX:Locale>
<XXX:DefFile>elements_fr.rdf</XXX:DefFile>
</RDF:Description>
</XXX:LocaleOption>
<XXX:LocaleOption>
<RDF:Description>
<XXX:Locale>de</XXX:Locale>
<XXX:DefFile>elements_de.rdf</XXX:DefFile>
</RDF:Description>
</XXX:LocaleOption>
<XXX:LocaleOption>
<RDF:Description>
<XXX:Locale></XXX:Locale>
<XXX:DefFile>elements_en.rdf</XXX:DefFile>
</RDF:Description>
</XXX:LocaleOption>
etc
</RDF:Description>
Note that the last one has a zero-length string for its locale.
The editor would be programmed to look down this list to find
the longest string which prefix-matches the user's current locale.
Thus the English one would be chosen if the user's locale is
not supported yet. Thus "fr_CH" would pick "fr", and "zh_TW"
would pick "" (the English one).
In Java, there is no list of files like this. The resource
loader just manipulates file names, looking successively for
"elements_fr_CH.properties"
"elements_fr.properties"
"elements.properties"
(it's actually a bit more complicated, but you get the idea)
On the other hand, it might be better if the files themselves
contain information about what they are good for, more like a
Java Bean. One would put this at the top of the French file:
<RDF:Description ID="FileInfo">
<XXX:Locale>fr</XXX:Locale>
</RDF:Description>
Once such a file has been introduced to the system (a bit like
registering a Microsoft COM object), selecting one would be
done by standard searching ("find me a file which defines
properties of resources of type "PropertyType" and contains
a resource called "FileInfo" whose "XXX:Locale" is "fr"").
The user would have a Preferences dialog where he or she
could choose between "show all properties" and "show
properties in local language only".
==========================================================
Approach number 2
In this approach, we put the locale selection right down among
the data.
Any file could contain:
<RDF:Description RDF:href="http://purl.oclc.org/metadata/dublin_core#Title">
<RDF:instanceOf RDF:href="http://www.w3.org/TR/WD-RDF-Syntax#PropertyType"/>
<RDFS:necessity RDF:href="http://www.w3.org/TR/WD-RDF-Schema#ZeroOrMore"/>
<RDFS:Comment>
<RDF:Description>
<XXX:Locale>fr</XXX:Locale>
<RDF:Value xml:lang="fr">Le nom donné à la ressource par
le créateur ou l'auteur.</<RDF:Value>
</RDF:Description>
</RDFS:Comment>
<XXX:name>
<RDF:Description>
<XXX:Locale>fr</XXX:Locale>
<RDF:Value xml:lang="fr">Titre</<RDF:Value>
</RDF:Description>
</XXX:name>
<RDFS:Comment>
<RDF:Description>
<XXX:Locale>en</XXX:Locale>
<RDF:Value xml:lang="en">The name given to the resource, usually
by the Creator or Publisher.</<RDF:Value>
</RDF:Description>
</RDFS:Comment>
<XXX:name>
<RDF:Description>
<XXX:Locale>en</XXX:Locale>
<RDF:Value xml:lang="en">Title</<RDF:Value>
</RDF:Description>
</XXX:name>
</RDF:Description>
All this data can then be stored away, with no record kept
of which file each property value came from. On the user
interface, only the properties with the correct locale would
be displayed. The effect to the user would be exactly the
same as Approach 1.
This sidesteps the complication of managing the different
files, but makes the data itself a bit more complicated.
The data is easier to manage, because you don't have to worry
about putting it in separate files. It could be stored in
a database.
There is a temptation to just use the language markup, ie
leave out the "locale" tags, but I think this would be misusing
it. We want to present to the user a package of data specially
prepared for that locale, not just all the strings that happen
to be in the user's preferred language.
Comments?
------------------------------------------------------------------------
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Reuters Ltd.
|
