Hello,
well, my actual point was that actions should be machine-
understandable strings, which natural language terms are not.
Language tagging vor property values in general is a different
problem, but anyway:
I think there is a rather general solution in the way XML (or RDF)
handles this, i.e. every element/node and every subelement/literal
may have an xml:lang tag. The tag does not change the semantics of
the element/property though: <dc:title xml:lang="en">... and
<dc:tilte xml:lang="de">... both specify "the" title, with no
preference of one *form* over the other.
In practice, I have the impression that all this language tagging is
rarely used, people just don't seem to care about multilingual
documents. Also note that language tagging is really nasty when it
comes to changing values: I may be able to change the English and
German title, but I am at a loss when it comes to the Hindi and
Cantonese one. In this case the result is not only a language
problem, but a semantic mismatch problem too: some properties have
the "current" tilte and some still retain the "old" one.
Now if you still want to go for it, IMHO the cleanest solution would
be the addition of a separate member in property, separate from
metatype, actual value, and MIME type.
In most cases this one will be just a NULL pointer, i.e. no value,
but for a tagged property it contains the language code (RFC 3066, en-
us, cn, de, like that). This is close to (2), with all its advantages
and disadvantages.
I would not mash this in with the MIME type however, as it is really
something entirely different. Same for the metatype (1), the language
does not really change the type, only qualifies it. Finally, (3) does
not tag/qualify properties with equivalent meaning, but expresses
*translations* of properties. While this is interesting, it is not
what we want.
Regards,
Karsten Otto (kao)
Am 26.04.2006 um 02:34 schrieb Reed Hedges:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Karsten Otto wrote:
The point here is that the action *must not* be a simple string.
While
an English speaking human may understand the string "open",
someone who
only speaks Chinese will not understand it. Same with your average
agent, who does not speak *any* language at all :-)
You actually bring up a very interesting problem that I would
*love* to
find a general solution for, before there's too much existing users of
VOS -- supporting multiple translations in human-oriented metadata.
This would probably be part of the MetaData vobject properties, but
couldf also be used anywhere there is text for humans to read.
I have three ideas on it:
1. Have seperate properties, with the language indicated in the
property
name. E.g. misc:title.en-us, misc:title.de, misc:title.cn. If your
language isn't present, you would use the first one in the list. You
could always also omit the language, and just say misc:title; some
metadata strings would not really benefit much from translation in
some
cases.
2. Have seperate properties with the same name, but indicate the
language in the property datatype. The definition of a property
datatype leaves room for this in that MIME types can have
"parameters".
E.g. misc:title with data type "text/plain(lang=en/US)", misc:title
with
data type "text/html(lang=de).
The disadvantage of (2) is you have to iterate over the properties
before you find your language. Peter is proposing including the
datatype in with the property vobject type; if you could do a site
search query on vobject types, you could search for your language.
(But
that forces you to do a search query which is not required for a
site to
support; you'd have to fall back on iterating all properties if search
is not supported.)
3. Another idea is to allow a metadata property to have children with
translations. I kind of like this. It lets you know what the original
or native property value is (the parent property's value), and you can
craft search queries not to descend it if you don't care about
translations. You would probably then just name all the child
translation properties after their language ("en", "de", etc.), and
you
would probably add a type to the parent property to indicate that
it has
child translations. You could even represent a whole tree of
translations, if, for example, the original value is in Russian,
and you
then make a French translation, then someone uses that to make a
derivative English translation.
The disadvantage of (3) is that it adds complexity to the data
structure, especially if you represent the whole family tree of
translations. Not sure if there are any actual problems with this yet
though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFETsAkFK83gN8ItOQRAuVuAJ43BcjxBjK86QuGQ3/atHTl41wlbQCeJow1
on4bcrVRkCHkwscz9B1+KlQ=
=Z1Gt
-----END PGP SIGNATURE-----
_______________________________________________
vos-d mailing list
[email protected]
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
_______________________________________________
vos-d mailing list
[email protected]
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
