The hideous ugly I'm most frightened of is the kind of thing that happens when I
talk to my potential-sister-in-law who's studying Information Management at the
University of Canberra.
I made the mistake once of asking about taxonomies in classification (like - how
does LOC work, compared to Dewey).
Three hours later, after hearing about floating categories and
somebodyorother-shelving rules, I was totally lost. Apparently one of the
earliest cataloging schemes depended on the physical size of the book, and the
colour of its cover. While that cataloging scheme might be relevant to a library
where shelf space is at a premium (pack all the same sized books on the same
sized shelf), I doubt it has much relevance to the cataloging schemes that we'll
be applying to digital works.
While taxonomies inherited from existing schemes might be of value (eg:
Geographical terms are tacked onto the end of a classification to indicate a
specific region of importance for the content), I'd like to be able to throw out
all the AACR books (or the two CDs, as the case may be) and stick to something
really simple.
At this stage, it seems to me to be a simple thing to ignore all the
specialisations and special cases inherent in the AACR rules. While this may be
going against centuries of tradition, it will make the interoperability goal a
lot easier. Fields from similar systems such as MARC can be "mechanically"
translated into the DC "bucket" that nearest matches the MARC semantics. Some
stuff from the MARC entries won't necessarily translate into DC at all - you'll
have to find the optimum fit in the Admin Core or some additional database. For
example, author affiliations can either be represented by DC.Contributor
relationships, or by an external database indicating entity affiliations as a
function of time.
Once the resource has been discovered, you can resort to the catalog for more
information about it. The extra information you want will be different depending
on the type of resource you're after, and I'd leave it up to the discovery
program creators to find a way of either linking off to other systems, or
incorporating results from those systems in their search results.
To my way of thinking, allocating DC metadata for a resource is more about how
little you can get away with, and still have your resource being discovered, and
less about how to cram all the "relevant" information about a resource into the
minimal structure of the DC metadata fields.
A query such as "Show me all the works created by Joshua Smith, between 1800 and
1880" can be answered entirely based on DC metadata.
A query such as "What percentage of Windows NT vs. other OS benchmarks that were
favourable to Windows NT, were sponsored by Microsoft" would probably rely on
external resources. Unless it was acceptable for Mindcraft to list Microsoft as
the sole sponsor at the time of publication - in which case you could get some
results from that query using DC metadata, and find the answer by reading the
results to see which ones are "favourable".
A query such as "Which organisations was the author of Das Kapital associated
with at the time of that document's publication?" would rely on external systems,
in order to divine the affiliations between the author and the organisations.
Such a system could also show affiliations shortly before and after the required
date, to give the researcher an indication of how significant the author's
affiliations were on the content (or vice-versa). If the affiliation information
was only stored in the DC metadata, all you would ever find is who the author was
affiliated with at the time of publication.
You could never ask questions like "Which publications have been shortly followed
by rejection of the author from known organisations?"
I'll stop here before I start making sense
Alex
Bernhard Eversberg wrote:
> Alex Satrapa writes:
>
> > IMHO, we should be
> > approaching DC from the POV of the researcher, not the cataloguer.
> >
> The earliest catalogers, those who set the guidelines for what a catalog
> is supposed to do, WERE researchers, not catalogers.
> And even today, we try to anticipate, in cataloging, what researchers
> may want to be able to discover. That's the rationale behind our
> rules - or so I like to believe.
>
> I am not saying everybody who produces metadata should attend a cataloging
> crash course first. I *am* saying the rules we are using have a lot of built
> in experience derived from feedback we got over the decades
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|