Print

Print


Thanks Thomas,

It really is an American phenomenon, IMHO regarding this.  It's probably due to the long standing history/tradition of MARC starting here with 1967 MARC Pilot Project and the early adoption by the university libraries in Ohio when they created OCLC.  (Which stood for Ohio College Library Center originally)

So the history baggage is going to be enormous, but not insurmountableówith good hand holding and proper input from the Catalogers, we could end up with data that is enormously rich and easily exposed.


Jeffrey Trimble
Associate Director &
Head of Information Services
William F.  Maag Library
Youngstown State University
330.941.2483 (Office)
[log in to unmask]
http://www.maag.ysu.edu
http://digital.maag.ysu.edu
"For he is the Kwisatz Haderach..."


From: <Meehan>, Thomas <[log in to unmask]<mailto:[log in to unmask]>>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]<mailto:[log in to unmask]>>
Date: Tuesday, January 15, 2013 12:02 PM
To: "[log in to unmask]<mailto:[log in to unmask]>" <[log in to unmask]<mailto:[log in to unmask]>>
Subject: Re: [BIBFRAME] Inviting community engagement on building a bibliographic roadmap

I donít think the technical problem of creating an interface will be too difficult, or of at least moving away from a MARC-based one. I created this (very) simple mock-up input form<http://www.aurochs.org/zz/marc_input/marc_input.html> out of 99% server-side Javascript (and not a lot of that) to try the idea of not inputting MARC (or ISBD) directly. The fact that it outputs MARC (rather than something else) on the right is besides the point, which is that the cataloguer shouldnít necessarily have to grapple with the nuts and bolts of the way the data is stored when inputting data. Building an elegant and engaging interface is of course another matter.

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.

Thanks,

Tom

---

Thomas Meehan
Head of Current Cataloguing
Library Services
University College London
Gower Street
London WC1E 6BT

[log in to unmask]<mailto:[log in to unmask]>

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Jeffrey Allen Trimble
Sent: 15 January 2013 16:22
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [BIBFRAME] Inviting community engagement on building a bibliographic roadmap

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.)




Jeffrey Trimble
Associate Director &
Head of Information Services
William F.  Maag Library
Youngstown State University
330.941.2483 (Office)
[log in to unmask]<mailto:[log in to unmask]>
http://www.maag.ysu.edu
http://digital.maag.ysu.edu
"For he is the Kwisatz Haderach..."





On 1/15/13 10:51 AM, "Karen Coyle" <[log in to unmask]<mailto:[log in to unmask]>> wrote:

Bernard,

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 [1]. 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
communities

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
by developers.

kc



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.



Very briefly:
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
MARC's omnipresence.

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?)


B.Eversberg

--
Karen Coyle
[log in to unmask]<mailto:[log in to unmask]>http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet