Re: What library patrons really want.

From: Karen Coyle <kcoyle_at_nyob>
Date: Mon, 30 Apr 2007 12:53:52 -0700
To: NGC4LIB_at_listserv.nd.edu
Andrews, Mark J. wrote:
> Are you thinking of some process analogous to the transport formats for
> authority, bibliographic and holdings records?  To my knowledge there
> are no commercial systems available or in use that can ingest or export
> records that strictly correspond to the FRBR entity relationship model.
>
That's right. And there's no record format that corresponds to the FRBR
model. All of this has to be developed if we are to move into a
bibliographic world based on FRBR. It's going to take work, no question
about it.
> Is it desirable that library systems, whether commercial or community,
> proprietary or open-source, use the FRBR entity-relationship model as
> internal storage format and/or a transport format?
In no way should we define the internal storage format of systems. The
library world has done a great job of making clear that MARC is a
transport format only. But I think we are going to have to be clear
about what we mean by "format." Are ISO 2709 and MARCXML different
formats? Or are MARC21 and UNIMARC different formats? In other words, do
we include the semantics of the data elements in the term "format" or
not? I ask this because participation in certain services will require
adherence to a set of data elements. If you are part of an active Z39.50
environment, you probably need to conform to a certain set of indexes
and be able to return a display record with certain data elements.
Internal to your system, of course, there are many ways that you can do
this, and that shouldn't make any difference to anyone using or
communicating with your system.

In our current world we talk about the MARC "format" and mean a host of
things:
  - ISO 2907
  - the particular selections within ISO 2907 that we use (2 indicators,
1 subfield code)
  - the content of the MARC21 record (245=title) (the semantics of the
data elements)
  - the rules for encoding the MARC21 data elements, as found in the LoC
documentation (e.g. how to fill in fixed fields and indicator values)

We have a "glomming" problem ;-). In AACR/2, we glom together
information about the work, the expression, the manifestation, and even
the item. In MARC21 we glom together the record structure, the encoding
of AACR/2, and the addition of data elements that are only part of
MARC21. Among other things, this leads to an imprecision in our way of
thinking about and talking about these key standards, and I think we end
up going round and round in our discussions at times because we are
talking about different things. The value of FRBR is that it gives us
more precise concepts than we've had to work with before.


>  Is there some need
> for a three-way cross-walk between:
>
>    * the internal storage format of ILS and other library systems
>
>    * the MARC21/Z39.2 content and transport model for bibliographic,
> holdings and authority records
>
>    * and the FRBR/FRAR entity relationship model
>
> Thinking in traditional ILS terms, there is still no clean, defined way
> to move transaction records, summary and detailed system statistics,
> user/patron records, overdues/fines/bills, serial control and pattern
> records, and acquisitions and fund accounting records.
>
Yep, because there are no standards in those areas. Which is one of the
reasons why it is so very hard for libraries to move from one system to
another. Serials control should be getting better, with both MARC
holdings and the ERM systems. I would NOT volunteer to be on the
standards committee that tries to tackle fund accounting!

kc
> Mark Andrews
>
>
>

--
-----------------------------------
Karen Coyle / Digital Library Consultant
kcoyle@kcoyle.net http://www.kcoyle.net
ph.: 510-540-7596
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
Received on Mon Apr 30 2007 - 13:51:04 EDT