Print

Print


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 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]

 

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]
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]

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]> 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] http://kcoyle.net

ph: 1-510-540-7596

m: 1-510-435-8234

skype: kcoylenet