Bernhard Eversberg wrote:
> But that depends a whole lot on the system and the way it is optimized.
> To envision a system that replaces only certain parts of records isn't
> necessarily easier. Record sharing and exchange has to be based on
> units of some sort, and what if not complete records?
>
That could be fine, so long as the complete records represent no more
and no less than a FRBR entity instance. Our records now have unclear
boundaries when it comes to the FRBR model---or any other model. They
contain a bit of this entity, a bit of that entity, one attribute from
another entity. This is a problem.
But I think there are technical methods for sharing just parts of FRBR
entity instances too, that could be very useful and shouldn't be written
off without consideration.
Jonathan
>> 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.
>>
> Had these been covered by the rules (AACR), we'd probably be better off
> with them now. RDA might learn from that and specify things that ought
> to be coded from the start, like what used to be GMD.
>
>> 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, ...
> without much concern for coding and format actually, but the latest
> draft for chapter 3/4 has tables to show where current MARC21 places
> things the proposed rules prescribe.
>
>> 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.
>>
>
> But doesn't Google work from a much less coherent base of given
> material, the designers of which still mostly don't care at all about
> structuring their stuff, let alone metadata, despite DC having been
> around for 10 years? (And G. disregards it anyway, as you know.)
>
> The big issue is probably not the rules at all but the fact that any
> cataloging rules will always produce only a small amount of data per
> document whereas search engines work from full document content.
> So, to improve end user results, more meat will have to be put on
> the RDA skeleton anyway. ToC, abstracts, reviews, ...
>
> Reliability in known-item searching and FRBR collocation, OTOH, cannot
> be had without a good code of rules along time-proven ideas. It is only
> discovery searching that can profit from extra verbiage. But what is
> the relative importance of discovery searching vs. the other functions?
> Discussions here seem to indicate that discovery searching is the only
> thing worth talking about, but it may be it is because everybody takes
> the other functions for granted. (Google can't do them - so who needs
> them?)
>
> B.Eversberg
>
--
Jonathan Rochkind
Sr. Programmer/Analyst
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
Received on Mon Apr 30 2007 - 07:47:09 EDT