A footnote to Mary Larsgaard's message. The ADL architecture is designed
to handle multiple metadata formats - whatever the "collection" is using
is okay as long as it is documented so that mappings can be made to the
ADL full metadata report, the access report, and to the "search buckets"
that provide high-level search capability across all collections. But no
matter how parent/child records may be represented in the collection
metadata (the maintenance part of the system), we decided for ease of
handling in the system, that we would create full child records for
internal handling if necessary (the operational part of the system). We
are still discussing treatment of "derived" objects, but are leaning
toward the 1:1 solution with links between related objects in the
metadata - as is being adopted by DC. We need to assure that a user
whose query finds a paper map for an area of interest also knows that a
scanned version of that map is also available or vice versa.
One observation: care needs to be taken in formatting titles for derived
objects. The title "scanned image," for example, for the title of an
image of an object does not stand alone. Processing rules can be
established to concatenate titles from related metadata but this is more
complicated to implement than just making stand-alone titles in the
first place.
- Linda Hill
Alexandria Digital Library
-------- Original Message --------
Subject: 1:1 - past experience
Date: Fri, 06 Nov 1998 13:38:23 -0800
From: Mary Larsgaard <[log in to unmask]>
To: [log in to unmask]
CC: [log in to unmask]
The following gives a (mercifully brief) history of
how the Alexandria Digital Library has, over a period
of 4 years, dealt with what we call parent/child (or
multilevel description) metadata.
a. October 1994-spring1995:
Under the pressure of getting a prototype ready for
a National Science Foundation site visit, I decided
to experiment (translation: ignore several AACR
cataloging rules) and cataloged both the hardcopy item -
in this case, an aerial photograph - and the scan of
the item in the same record, and then prayed that nobody
noticed how this made for a confused record as
far as physical description was concerned. Meanwhile,
what I really wanted to do was ...
b. Spring 1995-late 1997
Inherit metadata from parent to child, at the time the
child record was called up. That is:
- one catalogs the parent (e.g., air photo flight as a whole)
- then one catalogs each child, and in each child puts
ONLY the information that is unique to the child, PLUS
a linking field to the control number of the parent.
This failed for both human-perception and systems reasons:
- having the DB software do a join of the child and the
parent was unbelievably time-consuming for a good
many reasons, ranging all the way from the hierarchically
very complex metadata schema to other software reasons
far beyond my ability to comprehend;
- even if we could have done that, it nearly drove us 'round
the bend trying to figure out how the record should look
to the user - should one have all the unique child info first, and
then all the parent info? or vice versa? and decided both
were confusing in some way;
- what we ended up with was that the child record displayed
with a button at the bottom of the screen, "Parent Metadata".
Problem was that the vast majority of the time the child record
was so sparse as to be meaningless to anyone except a
map librarian. Even more importantly, probably only another
cataloger understands the concept of parent/child (or even
should have to).
c. 1998
We went (back, if you prefer to put it that way) to the standard-
cataloging technique of including all the information (all parent info;
all unique child info) that is relevant to a child (e.g., one air photo
of a flight) in one record. As long as one is taking advantage of
db software that allows one to input the parent-level info ONCE
and then just copy it over into each child record, and then add
to each child record the info unique to the child, that works.
Incidentally, it does NOT work always - or, for at any rate
for geospatial data - to say that child info
overrides parent info (e.g., child title always overrides parent
title).
The above is from the point of view of the cataloger of the project
(me); Linda Hill, a researcher for ADL, may well have another
viewpoint to present.
Mary Larsgaard
University of California, Santa Barbara
>X-Sender: [log in to unmask]
>Date: Thu, 5 Nov 1998 20:29:24 -0500
>To: meta2 < >
>From: "J. Trant" <[log in to unmask]>
>Subject: Re: [long] Re: Subject: Qualifying dc:Subject (really 1:1)
>Sender: [log in to unmask]
>
>I'd like to ask for futher clarification of why 1:1 "doesn't work"...
>
>In my experience with AMICO data, and (or at least this is what I heard
>John Perkins say) in the CIMI Testbed, 1:1 was essential for maintaining
>clarity and integrity in metadata records. We've found in assembling the
>first AMICO dataset that implied meaning, no matter how clear within an
>insitution gets lost as soon as data moves into an inter-institutional
>environment. Explicit metadata is the only way to make things unambiguous.
>
>The way I see it, 1:1 is just a case of describing the 'object in hand'.
>And since there isn't a way of linking repeating elements in DC, it is also
>the only way to ensure that records make logical sense.
>
>There was talk at DC 6 about "embedding" metadata from one record within
>another. I'm struggling to understand this, because I can't see how it
>differs from 1:1, and would like to speak with an example.
>
>I'm using the Mummy that John borrowed at the DC6 meeting -- that image can
>be found at http://www.amico.net/docs/dataspec.final3.shtml I'm running
>fast and loose without any qualifiers, and as a result have had to force
>the Art Institute of Chicago into being a Publisher. ... "I want my DCQ"
>
>
>
>ID: AIC_.1910.238
>Creator: Egyptian, Possibly from Thebes
>Title: Mummy Case of Paankhenamun
>Date: Third Intermediate Period Dynasty 22 (c. 945 - 715 BC)
>Type: Physical Object
>Type: Sarcophagus
>Format: cartonnage mummy case with mummy inside
> h. 67 in (170 cm) w. 17 in (43 cm) d (12 1/2 in) (31.7 cm)
> Cartonnage (gum, linen and papyrus), gold leaf, pigment
>Publisher: The Art Institute of Chicago, Chicago, Illinois
>[ALTERNATELY Relation: IsOwnedBy]
>Relation:
> HasFormat AIC_.E22827.TIF
>
>
> ID: AIC_.E22827.TIF
> Creator: The Art Institute of Chicago
> Title: front view
> Date: 1998
> Type: image
> Type: reproduction
> Format: TIFF
> Format: RGB
> Format: 331 x 768 pixels
> Format: 745 K
> Format: uncompressed
> Relation: IsFormatOf AIC_.1910.238
> Publisher: The Art Museum Image Consortium
> Rights: Copyright The Art Institute of Chicago, 1998
>
>
>I've got two DC records here, each describing a thing {the digital image or
>the original sarcophagus). I could (and we have) continued to create other
>DC records for other versions of images (thumbnails, partial screen views,
>etc.), or other images, like details of the top of the head, or x-rays, or
>CAT Scans.
>
>We can reassemble these records in ways that look a lot like MARC records
>with "nested" 856 <?> fields (as in the AVIADOR project at Columbia) by
>displaying the fields in the DC image record "under" the title of the
>original object. But I can't merge the records without losing the logical
>distinction about what is the TIF file, and what is the sarcophagus. Right?
>
>Thanks.
>
>jennifer
>
>(if you want to see the full AMICO record for the Sarcophagus, it's at
>http://www.amico.net/library/3.shtml)
>
>
>__________
>J. Trant [log in to unmask]
>Partner & Principal Consultant phone: +1 412 422 8530
>Archives & Museum Informatics fax: +1 412 422 8594
>2008 Murray Ave, Suite D http://www.archimuse.com
>Pittsburgh, PA 15217
>__________
>
|
