Quoting "Diane I. Hillmann" <dih1_at_CORNELL.EDU>:
> Ed,
>
> Thanks for the plug! Those who are concerned about how we're going to
> haul our legacy data with us as we move on from MARC should take a look
> at what the eXtensible Catalog Project is doing (some screencasts here:
> http://www.screencast.com/users/eXtensibleCatalog -- I particularly
> recommend #1 & #3). They've taken much of the work we did for NSDL and
> put it to good use in their metadata management system and their
> services.
The difference I see, though, between XC and some of the discussion
here is that XC is about *use* of data not *creation* of data. In
other words, XC is about taking metadata and transforming it. I still
can't quite figure out the level of detail that is retained after the
transformations, but all of the verbs are things like "harvest" and
"transform", meaning that metadata has to already exist.
Where I think we have some difficult decisions to make is around data
creation. MARC has over 500 different variable data elements and a
hundred or so more fixed elements.
(http://futurelib.pbworks.com/Data+and+Studies).
RDA has over 300 elements and more than that as relationships (and we
know that RDA elements have been underspecified in terms of detail
compared to MARC). (http://metadataregistry.org/rdabrowse.htm) If you
have highly detailed metadata, you can always reduce it to less detail
if that's all you need for an application. However, if you don't
create the metadata at a particular level of detail, you will probably
not be able to recover greater detail algorithmically.
The analysis that hasn't been done on library cataloging is: "what
elements and coding are necessary for the desired system
functionality?" We don't know what level of detail is useful, much
less cost-effective. The cataloging rules (AACR2, RDA) address some
functionality (e.g. designing headings for an alphabetical view), but
ignore most of it (e.g. how to provide searchable values for dates;
how to code serials numbering for check-in services). I'm fine with
the system functionality analysis being a second step in the process,
but it has to be a step, and it has to be part of the same process
that produces cataloging rules, for two reasons: 1) the rules may have
to make some compromises in order to have the desired system
functionality 2) the same catalogers who will be creating the AACR2 or
RDA cataloging data are the ones who are creating the data that will
be used by systems, whether added on to the cataloging rules or
included with them.
I don't think we can go forward unless this step takes place, yet, as
I've said before, we don't seem to have any organization or entity
whose task this is. JSC isn't taking it on (and doesn't have the
skills to); LC took it on for AACR/MARC, but seems unable to play that
role today; the "publishers" of RDA are just that: publishers, not
systems folks.
kc
>
> Diane
>
> On 4/20/10 10:33 AM, Ed Summers wrote:
>> In case you haven't seen it already, I meant to add that Hillman,
>> Dushay and Phipps have a good paper on the operational need we have to
>> move beyond the Record in our metadata:
>>
>> Improving Metadata Quality: Augmentation and Recombination
>> http://ecommons.library.cornell.edu/handle/1813/7897
>>
>> Digital libraries have, in the main, adopted the traditional library
>> notion of the metadata 'record' as the basic unit of management and
>> exchange. Although this simplifies the harvest and re-exposure of
>> metadata, it limits the ability of metadata aggregators to improve the
>> quality of metadata and to share specifics of those improvements with
>> others. The National Science Digital Library (NSDL) is exploring
>> options for augmenting harvested metadata and re-exposing the
>> augmented metadata to downstream users with detailed information on
>> how it was created and by whom. The key to this augmentation process
>> involves changing the basic metadata unit from 'record' to
>> 'statement.'
>>
>> //Ed
>>
>>
--
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
begin_of_the_skype_highlighting 1-510-435-8234 end_of_the_skype_highlighting
skype: kcoylenet
Received on Tue Apr 20 2010 - 15:48:22 EDT