I think it is a cultural problem though as itís unclear why this hasnít been done already in ILSs. From a cataloguerís standpoint, MARC fields are how the data is entered.
Head of Current Cataloguing
University College London
London WC1E 6BT
I've been listening in for some time and this posting gave me pause for thought.
"but I'm not sure that the US library world is on board."
I think that one of the issues I'M attempting to grappling with is not the underlaying structure of the data (I.E. MARC21, marcxml, rdf, etc.) it is the going to be the interface that the professionals use to create the data and maintain the data.
The historical hangup is going to be the fact that Catalogers have been using input screens that represent the MARC record (more or less raw, without the Directory data) and over the decades the editors have become sophisticated enough for the user to gain help to the coding.
What will be needed to get catalogers to "buy in" to the shift to a new structure, is an editor which the data can be created, manipulated and maintained without know how to use xml coding (or other "<coding>") knowledge.
A reminder that MARC was supposed to be "under the hood" and not for the end userócataloger. No one developed the interface any further and it has become the "defacto" editor.
This is where you will have major pushback from the Librarians that are in technical services more than anything else. Of course, our ILS vendors need to step up to the plate and show us some next-generation models for the creation/maintenance/manipulation with input from the users who create the data.
I believe that this will be the *major* hurdle to overcome. Once I see an input screen that is as efficient and easy to use as the MARC record is, than I don't care how it lies underneath. I'll be willing to bet librarians will want to add more data than ever before and tie all things together in neat packages (read: FRBR, RDA, etc.)
Associate Director &
Head of Information Services
William F. Maag Library
Youngstown State University
"For he is the Kwisatz Haderach..."
On 1/15/13 10:51 AM, "Karen Coyle" <[log in to unmask]> wrote:
I think it's important to think of bibliographic data with a broader
scope than libraries, much less Bibframe. Bibliographic data is one of
the more common types of data that is used widely in a variety of
contexts. There are efforts around bib data that come out of publishing,
out of "ad hoc" academic efforts, in retail, etc. If we don't think
about this bigger world, libraries will end up once again in a silo that
is of use only to libraries.
Note that W3C already sponsored an effort to encourage libraries to
think of their data in the Web context . I'm not sure that it has had
that effect (yet). But we really should not create a new bibliographic
framework without thinking about:
- how other communities might use the data libraries create
- how libraries might use the data that other communities create
- how library data can interact usefully with data created by other
It is my impression that the Zepheira vision tries to address these
issues, but I'm not sure that the US library world is on board. Some
non-US library communities, including the German, British and Swedish,
seem to be heading more in that direction, as is Europeana.
I agree that we need ways for people to create data and manipulate data
so that we can all experiment with these concepts. It needs to become
more "real" in order for folks to grasp it. We also need more education
in this area, and there is a group at Univ. of Washington who are
requesting grants to develop training materials that can be used widely,
including databases that can be searched and software that can be used
On 1/15/13 5:42 AM, Bernhard Eversberg wrote:
Am 15.01.2013 13:36, schrieb Todd Carpenter:
... The end result of
this work will be a report that will identify exchange points where
standards development is needed, and document suggested areas where
functionality testing should be performed. It should help pinpoint
at a high level the development priorities and coordination points
needed over the next 24-36 months.
Most helpful might be the development of a prototype for metadata
entry and editing. For right now, those who will actually have to do
the jobs (formerly called "catalogers", and who cannot in a short or
medium term all be replaced by latter-day staff having been brought up
on all the new technologies) are most of them thoroughly perplexed
and in the dark about what they will be expected to learn and do.
In my minority (?) view, the brave new world will have a chance
only if there will be a demonstrably more efficient and elegant
way of entering and editing data, surpassing the familiar MARC
data entry screen and carrying the potential of becoming as
widespread and universal as the latter because knowledge transfer
from one application to any other is one of the biggest benefits from
At the same time, only an easily learnable and swiftly operable
data interface will be able to convince "other communities" to
jump the BIBFRAME bandwagon.
(Is there any formal involvement with Zepheira?)