Several people have pointed out that elements named with numbers instead
of English words could be difficult to use. And it has been pointed out,
by analogy to the English words in HTML and in programming languages,
that "Pascal doesn't use English. Pascal uses keywords. The keywords
just happen to look like English words."
I am convinced that we will be well-served with default element names
that happen to be English words. And I think those twelve canonical
words should be carefully chosen to reflect the elements' scopes as
broadly and as obviously as possible.
However, I do not think that these twelve words will ultimately prove
satisfactory; in fact, they could get in the way. If I am going to
distribute a metadata template to photographers, it would be more elegant
if the Creator element were labeled "photographer" as opposed to "author
(role=photographer)". Likewise, for a German template, an element labeled
"Autor" would be more straightforward than "author (role=Autor)".
Perhaps a compromise is possible:
That each element have two canonical names: an English word
("author", "title"...) and a number. The user can choose.
Perhaps one could allow the number to be followed by a colon, and anything
after the colon could be interpreted as a qualifier. For example:
name="dc.Title" content="The Big Technical Report"
or name="dc.2:Titolo" content="Il Grande Rapporto Tecnico"
name="dc.Author" content="Mathew Brady" role="photographer"
or name="dc.1:Photographer" content="Mathew Brady"
Tom
P.S. I see a danger: what if someone tries "dc.Fotografo" (Italian for
photographer, without an element number)? But if we will rely on public
registers to control the qualifiers, perhaps we could do the same even
with element names.
P.S.S. Terry Allen <[log in to unmask]> writes:
>I think numbers is a neat idea if you need a fig leaf for Angelic
>names. It shifts the question of whether translated element names
>correspond to the originals to whether all the various names match
>up. Instead of having to ask, "Does AMOUR equal LOVE?" you get to
>ask "Do AMOUR and LOVE equal 2?"
>
>But you have to define the semantics of 2 in some human language
>("the score of zero in tennis"), so it is really only a fig leaf.
>Better, perhaps, to be alive to cross-cultural variation in what
>metadata elements might mean when defining them.
Assuming Terry meant English names, not Angelic (pure and lovely?), this
gets to the heart of why I don't think we should rely on one English
word to stand for the essence of an element. If that word were just a
might-as-well-be-arbitrary string that happens to look like English, as
a keyword in HTML or Pascal, we wouldn't care so much which word that
happened to be. But we do care what an element is called (according
to our native languages, disciplines, and preferences), so I'd like to
have the option of calling an element by the name most appropriate to
my application. At any rate, the elements should be defined less by
single words (like AMOUR and LOVE), or even by legalistic definitions,
than by ranges of examples that fall within their scopes.
_______________________________________________________________________________
Thomas Baker [log in to unmask]
GMD -- Forschungszentrum Informationstechnik GmbH Tel. +49-2241-14-2171
Schloss Birlinghoven Fax. +49-2241-14-2071
53754 Sankt Augustin, Germany Secr. +49-2241-14-2911
GMD - German National Research Center for Information Technology
ERCIM - European Research Consortium for Informatics and Mathematics
|