Mark,
Right, we have FRBR as a conceptual model. It's not a model for a
bibliographic record, however. (And in fact, RDA, the way it is
currently going, is NOT following even following FRBR as a model, which
is a bit of a shame.)
I said nothing about changing the theoretical foundations of cataloging.
I can go back and read Cutter and I have to say that what the man said
over 100 years ago still makes a lot of sense. It's the melding of
cataloging and technology that we need to work on. It's easy to forget
that the card catalog was a technology, and that cataloging practice was
developed to create the entries in that "system."
I really don't see how anyone can advocate for separating the act of
cataloging from the technology that will implement it into a user
service. I WANT catalogers to be actively creating the catalog as they
create the data. Which basically means that I want them to be deeply
involved in the catalog as a user service. I don't know exactly why they
aren't -- in my earlier note I recounted the history, but that shouldn't
be an excuse for why we haven't improved the situation. Jonathan
Rochkind recently said in a post:
"As I've said before, I firmly believe that the disciplines
of cataloging, metadata, and systems design are converging into
something that must be treated as one unified discipline, not segmented. "
My only amendment would be to say that cataloging, metadata and systems
design have already converged, but they are acting as antagonists
instead of working together. I simply find it to be too limiting to be
told that I have to work with the current library data "as is" and that
I cannot work with the cataloging community to create better data to
support better catalogs. In the end, aren't better catalogs what we ALL
want?
kc
Andrews, Mark J. wrote:
> I've got a copy of Barbara Tillett's "What is FRBR? A Conceptual Model
> for the Bibliographic Universe" next to me. My quick take on FRBR and
> applications of this model to authority records is that the LAST thing
> we need in LibraryLand is to spend the next 100 years changing the
> theoretical foundations of cataloging. There's already literature out
> of OCLC describing algorithms to derive FRBR-based displays from large
> bibliographic data sets - not perfectly, but perhaps adequately.
>
> Put me in "The Online Library Catalog: Paradise Lost and Paradise
> Regained," by Karen Markey, camp. We need search tools in libraries
> like those already in use in other contexts. We otherwise run the risk
> of building the perfect tool to assist us in doing a job that no one
> needs.
>
> Mark Andrews
>
> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Karen Coyle
> Sent: Friday, April 27, 2007 9:57 AM
> To: NGC4LIB_at_listserv.nd.edu
> Subject: Re: [NGC4LIB] What library patrons really want.
>
> Jonathan Rochkind wrote:
>
>> The problem needs to be attacked from all angles at once, with all of
>>
> us
>
>> cooperating. It is not sufficient to blame MARC for being bad, or to
>> blame systems for not taking full advantage of MARC. We've got to do
>>
> it
>
>> all together. As I've said before, I firmly believe that the
>>
> disciplines
>
>> of cataloging, metadata, and systems design are converging into
>> something that must be treated as one unified discipline, not
>>
> segmented.
>
> Absolutely. I look to our recent history to understand why we have this
> vast division between cataloging and systems development. (I think we've
> been down this path before, here on NGC4LIB, so some of this may be a
> repetition.) In the card catalog days, cataloging and the development of
> the catalog were one and the same: cataloging created the catalog card
> entry. We took that entry and made it machine-readable (in the 1960's)
> in order to produce the cards more efficiently. The development of the
> OPAC, however, did not come from the catalog department, and it wasn't
> directly informed by cataloging. At that point, cataloging and the
> creation of the catalog diverged.
>
> Having been on the ground in 1980 when we first developed the MELVYL
> catalog at UC, we basically saw our task as taking the data we had (MARC
> records that had been produced as a side product of the libraries' use
> of OCLC to print cards) and making it searchable. There was no concept
> that perhaps the data should need to change. We really were creating the
> online "card catalog" to some extent. There never was the possibility of
> going back to the catalog department and asking for different data. That
> would have been unthinkable. We were a kind of clean-up crew, recyclers
> of the libraries' canonical data. It was fun to find new ways to make
> use of that data and we often felt very clever, but we were unmistakably
> the last step in a process over which we had no influence.
>
> I have never seen a good analysis of the systems problems that one faces
> when working with MARC records. One of my bugaboos is the "unit record"
> model, which, among other things, requires that the entire record be
> replaced when any changes are made. This is incredibly inefficient from
> a systems point of view, and I know that our system was basically in
> constant churn, re-indexing incoming updates at a furious pace. Yes,
> there were things to do to mitigate that, but still it needs re-design.
> Then there are the problems of redundancy within and between records,
> and of inconsistency (when the same data is entered differently in
> different fields). Because there was no concept of the value of the
> fixed data elements, these were applied in a rather haphazard fashion
> among participating libraries, rendering them virtually useless for data
> processing.
>
> When I look at the RDA process, I see us going down this same road: the
> cataloging rules will be determined without any concern about the end
> system use, and then systems developers are expected to come along and
> make something out of this data that didn't get any systems design
> concepts built into it. In the IT world, this is the classic nightmare
> of the IT department getting specs written by the marketing department
> that basically describe their current hard-copy practices.
>
> OK, enough complaining. I'm going to start setting down some of the
> requirements for a new data record. I think there has been a beginning
> on futurelib, but we really need to put forth the systems needs in a
> clear, coherent fashion.
>
> kc
>
> --
> -----------------------------------
> Karen Coyle / Digital Library Consultant
> kcoyle@kcoyle.net http://www.kcoyle.net
> ph.: 510-540-7596
> fx.: 510-848-3913
> mo.: 510-435-8234
> ------------------------------------
>
>
>
--
-----------------------------------
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 Fri Apr 27 2007 - 11:46:10 EDT