Quoting Matthew Short <sho...@illinois.edu>:
I can definitely say from experience that the users I work with are
often >frustrated by our online catalog. They don't understand why
it is so >complicated to find, for example, a Spanish translation of
Camus' The First Man >or why there are so many different records for
what seems to them to be >essentially the same item. FRBR might
make such things easier. That said, it >is much too early, I think,
to tell if it actually will.
I don't think we need FRBR to accomplish this (although it might
help), just a better use of the data we already have. However, first
we have to define this kind of case as one of the ones we want our
data to address. Then we need to organize our data in a way that we
can derive these kinds of relationships. There's no reason why we
couldn't have:
Camus, Albert
Premier homme
(original text)
(language: French)
(ID:123)
Primo uomo
(language: Italian)
(is translation of --> (ID:123)
First man
(language: English)
(is translation of --> (ID:123)
Primer hombre
(language: Spanish)
(is translation of --> (ID:123)
and have these display such that from any point you get a link to
"other language versions". (That is, anything with: "(is translation
of --> (ID:123)") A direct search for a Spanish translation would be:
((is translation of --> (ID:123)) + (language: Spanish))
Note that this is a "verbal" example of something that would be more
machine-like under the hood.
Why don't we have this now? In part it's because our data is locked up
in records, and the records are stored as units in our databases.
That's not because the people designing those databases are stoopid;
it has a lot to do with how we update our data (full record replace:
MARC doesn't allow any other option, by design) and related issues of
efficiency. It also simply because of our reluctance to give up MARC.
What I have given above is an example of "linked data" -- a way of
organizing information so that it is easier to pull out information
based on relationships. It is what some of us see as the current best
"next data carrier" for library data. It wouldn't have to change the
meaning of our data, but would definitely change its form.
kc
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
