Just a reminder that we don't all have to use the same elements in
order to play in this space. Some bibliographic data can be as
minimal as a normal academic citation, and other data can be as
complex as that turned out by large research libraries. Yet these
can play together well if they use the Semantic Web technologies
(which I assume are solidly behind the BIBFRAME design). So there is
little need to argue about what our "one true record" will be, but
we should be listening to a wide variety of communities about their
needs and how we can connect bibliographic data from different
sources, each of whom has their own point of view.
Carrying forward the complexity of MARC may be of interest to some
but it shouldn't be a requirement for everyone. I would also feel
better about that complexity if it weren't such a Rube Goldberg mess
of 40 years of modifications, some of which were shoe-horned in
awkwardly. A few posts back someone (sorry -- names escape me more
often than not) said that we should be carrying forward the intended
*meaning* of the bibliographic data. I salute you, whoever said
On 1/18/13 6:55 AM, Barbara Tillett
[log in to unmask]"
type="cite">If back on track is back to the questions about what
identifying characteristics are important for users to find,
identify, select, or obtain information, we have decades, in fact
centuries, of research and use information that has led us to the
identifying elements in cataloging codes, such as RDA: Resource
Description and Access.
RDA built on research and international consensus in the
library community (not just the experience of catalogers, but
also reference/public service staff helping users every day) -
which includes public and academic and all kinds of libraries
and library-related service providers, as well as archivists and
curators from museums.
The basic, essential elements are identified in RDA as "core"
elements and other identifying characteristics are included for
all types of resources - to be used or added as appropriate to
fulfill a user task (find. identify, select, obtain, etc.).
Identifying information can be added at any time - by the
creator of the resource, by the publisher, by catalogers over
time, by others able to do so, etc. This becomes even more
do-able in the Internet, where experts could augment
descriptions and provide relationships (links).
Let's please not dumb down the possible elements for the sake
of a very simple element set - that was done with Dublin Core,
which has proven helpful for limited applications but has limits
when more granularity/detail is needed. Let's learn from that
and enable the future framework to meet the needs of all users.
Our future framework really must accommodate details that
will be important for humans. Plus we need to do it in a way
that machines can easily manipulate so humans can understand and
see connections/relationships and confirm/distinguish among
similar things in order to do what they wish with information.
If we can accommodate details, then we can simplify our display
and uses of that data - condensed into a shorter/brief view of
data or mapped to broader categories of data; but if we only
provide a few elements, we can't go from generalities to details
when that is needed.
Dr. Barbara B. Tillett
Chair, Joint Steering Committee for Development of RDA
On Jan 17, 2013, at 10:25 PM, Tennant,Roy wrote:
Re: [BIBFRAME] Input screens
Here I was about
to call for closure on the “Input screens” thread,
before it truly went down the electronic discussion
But then comes this post by Kathleen Goldfarb,
which, I believe, gets us back on track. That is,
what are the aspects of a work we really must record
to make it findable and relatable to other works in
ways that actual users want their systems to work?
That must be at the very center of our discussions,
and not merely an afterthought after debating the
relative merits of a 245 $h. Or whatever.
Please let us simply acknowledge that appropriate
input/editing methods will be created to deal with
the New World and get back to discussing what truly
matters — the data being recorded, and how.
On 1/17/13 1/17/13 • 6:03 PM, "Goldfarb, Kathie"
<[log in to unmask]>
Yes, some of those
differences are meaningless, but some are
important, at least to some people for some
reasons. Difference between $x and $v? If your
system can do it, some people may want to find
books OF poetry, rather than those ABOUT poetry.
If your system can at least identify that
information, or even better yet, allow you to
search or filter by that info, it can be a big
help for patrons. A lot of this depends on the
ILS or Discovery system you are using.
Do we need to know the diameter of a CD-ROM?
Probably not, since most of them are the same,
and even the few smaller ones out there can be
played on a standard player. It is a holdover
from a time when phonograph records came in
different sizes and that was importatant to
Is it important to know the height of a book?
Ususally no, but when we cannot find a book on
the shelf, that height might help find it. Is
it worth putting the height in every book? I
don’t know. If we decide not to do so, it’s not
going to bother me. We have a lot of older
records in our catalog without height. I don’t
even think of trying to find it an update the
Do some patrons want to know whether that name
they are looking at is an author, illustrator,
subject of a book? We are forgetting those that
do have specific wants and needs. Any kind of a
new coding system has to allow for methods of
letting people know what they found, so they can
decide if it is what they want. Maybe we need
to be asking researchers what they need in order
to identify the materials they need.
Technical Services Librarian
College of the Mainland
Texas City, TX 77539
409 933 8202
P Please consider whether it
is necessary to print this email.
Bibliographic Framework Transition Initiative
Forum [mailto:[log in to unmask]]
On Behalf Of Simon Spero
Sent: Thursday, January 17, 2013 7:26 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Input screens
On Thu, Jan 17, 2013 at 6:20 PM, Kevin M Randall
<[log in to unmask]>
Yes, certainly, as long as the language of input
is MARC, then absolutely anyone who does
inputting needs to be able to understand that
language. My point is that we haven't created
everyday-use tools that do the MARC translation
in the background so people can do cataloging
work without knowing MARC. My point is that
we're requiring people to learn a language that
they really shouldn't have to learn.
Programmers should know it; managers should
know it; but lower level cataloging assistants
shouldn't have to know it.
Why should even managers have to know the
difference between 650 $x and $v (answer: they
shouldn't because $v is an abomination).
Rarer tags have higher error rates (the rarest are
almost always miskeying ; do statistical analysis
of tag frequencies and co-occurrences, and you'll
spot all sorts of mistakes (e.g. hitting a key
twice, pushing the last digit of the tag into the
For that matter, if the only study every conducted
on the, er, subject, found only about a 50%
success rate for *technical services*
professionals in generating paraphrases of
pre-combined subject heading strings, with
reference and general adults scoring worse, do
they have a meaning (and in what language game)?
If collapsing two fields changes neither recall
not precision when searching, does it make a
If splitting a field changes recall or precision,
which is it not split?
Why must we know the diameter of a cd-rom?
Is this ruler really necessary?
[log in to unmask] http://kcoyle.net