Date:Wed, 1 Feb 2006 13:29:07 -0600
Reply-To:[log in to unmask]Sender:Metadata Object Description Schema List <[log in to unmask]>
From:"Timothy W. Cole" <[log in to unmask]>
Organization:University of Illinois at UC
Subject:Re: Question: Source of title
Comments:To: Metadata Object Description Schema List <[log in to unmask]>
In-Reply-To:<[log in to unmask]>
Content-Type:text/plain; charset="us-ascii"
Bill-
Certainly would agree with need to reassess cataloging practices on an
ongoing basis, especially as we look at born digital content and related
issues of descriptive granularity -- and other issues surrounding the "what"
of what we're trying to describe. You may also be right about trends in
metadata towards sparseness, though I have some concerns about that.
(Another rationale in favor of this trend is ready availability of
full-content objects, which many have argued obviates need for many
traditional descriptive cataloging fields.)
As a possible low-level OAI-related counter-example of a service that would
want to know about things like source of title, consider a service that was
trying to FRBR-ize or otherwise trying to relate objects described by
metadata records harvested from disparate repositories. We've already seen
in OAI harvesting many examples of World War I and II posters that have been
digitized and described by multiple institutions. In one very specific case,
two institutions have digitized different instances of the same poster
manifestation. One institution was targeting use of the poster to K-12
community. The other institution was targeting use of the poster for
scholars studying the nature of war posters in a much more academic vein.
Not surprisingly they each described the poster very differently. Assuming
an automated or semi-automated OAI-based service trying to identify from the
metadata whether the two objects were related, knowing whether the title
value given in each metadata record was made up by the cataloger (or not)
could make a real difference in comparison process and ultimately whether
the service recognizes the two posters as related or not. Of course as I
recall neither poster instance is described in MODS yet, so the specific
question on the list is moot for this particular example, but you get the
idea of what might happen. Knowing source of key metadata fields like title
could be very relevant for services that are looking at harvested metadata
trying to identify relationships between objects.
So I think we're in agreement that need for source of title can be
significant (or not) depending on use model / user expectations. As you say
conversion of legacy metadata and priorities for born-digital descriptive
cataloging is a fertile area for more thought. It depends a great deal on
how we expect metadata to be used. Though OAI tends to be associated with
certain kinds of metadata use, that association is not especially a
limitation of the Protocol itself, more a matter of how OAI-PMH has been
used to date.
Be interesting to see what happens.
Thanks,
Tim Cole
University of Illinois at UC
> -----Original Message-----
> From: Metadata Object Description Schema List
> [mailto:[log in to unmask]] On Behalf Of Bill Landis
> Sent: Wednesday, February 01, 2006 12:36 PM
> To: [log in to unmask]
> Subject: Re: [MODS] Question: Source of title
>
> Thanks for weighing in, Tim. Good to have my notion of the
> possibilities for OAI metadata sharing, blinkered a bit by my
> current engagements with it, expanded by a clear vision of
> potential futures for it.
>
> To get back to notes about sources of supplied titles,
> though, I think they represent a good opportunity for this
> community to explore a bit more why and when they do matter.
> I'd argue that the bibliographic assumptions behind the whole
> notion of bracketing supplied titles, or making specific
> notes about sources for such titles, is perhaps a legacy of a
> world of primarily formalized production of information
> resources. It also seems to me a legacy of having the luxury
> of dealing with most descriptive tasks on a 1:1 basis between
> descriptive record and object being described.
>
> As we start dealing with the challenge of appraising,
> capturing, describing, and preserving born-digital
> information resources, probably at a level of aggregation
> much higher than anything that corresponds to an "item" that
> we're used to in terms of our library- and museum-based
> notions of cataloging, I think there's a real need for some
> profession-wide explorations of the assumptions we bring to
> this juncture. If metadata are (and I'm not sure of this,
> just have some vague hunches about it) trending towards
> increasing sparseness and less focus on a more traditional
> notion of "item", what kinds of metadata would we really need
> to build services that end users want/need/care about? I
> don't really know what kinds of assessment activities have
> gone on in the OAI-PMH world, but it seems somewhat
> challenging to make practical recommendations about mapping
> metadata out of legacy systems for sharing without some real
> sense of 1) what metadata are really useful for driving
> automated services (e.g., how useful are metadata fields that
> are more prose-oriented and less controlled or proscribed by
> clear content guidelines?), and 2) what kinds of information
> is really useful to end users of the serviced metadata?
>
> Anyway, thanks for something interesting to think about on a
> rainy Oakland morning! I hope there are some creative venues
> at future conferences to explore some of our legacy
> assumptions about "cataloging," and how we and end users
> envision metadata functioning in aggregated systems designed
> to provide specific services for specific audiences.
>
> Cheers!
>
> Bill
>
> -----Original Message-----
> From: Metadata Object Description Schema List
> [mailto:[log in to unmask]]On Behalf Of Timothy W. Cole
> Sent: Wednesday, February 01, 2006 7:52 AM
> To: [log in to unmask]
> Subject: Re: [MODS] Question: Source of title
>
>
> While the use assumptions Bill articulates may be inherent in
> Aquifer plans for OAI-PMH (though I'm not even sure that's
> true), it is not inherent in OAI-PMH itself.
>
> We can anticipate (and are already beginning to see)
> OAI-based services that are designed to do more significant
> work with harvested metadata before or even instead of
> redirecting end-users back to original source full-content
> repositories. Analytical services over harvested metadata and
> potentially full content, services that look to de-dup or
> uncover and exploit new relationships between objects, other
> services that may do extensive work with harvested metadata
> and/or associated full-content before or instead of pointing
> end-users back to original source repository can all
> (potentially at least) be implemented using OAI-PMH. Such
> more sophisticated OAI-based services may have reason to want
> to know explicitly the source of title values in harvested
> metadata records -- it may matter to some OAI-based services,
> if not now, then at some point in the future. I don't think
> generic consideration of OAI-PMH sheds light on this question.
>
> So, while I agree with Jenn and Bill that the assumptions
> embedded in the Aquifer Metadata Working Group's current
> draft recommendation should be recognized as having limited
> scope, I would not put any assumption about whether source of
> title matters off on OAI-PMH. OAI-PMH does not make
> assumptions at this level about metadata transported using
> the Protocol.
> ("The nature of a resource, whether it is physical or
> digital, or whether it is stored in the repository or is a
> constituent of another database, is outside the scope of the
> OAI-PMH") This is how people got started thinking of OAI-PMH
> as synonymous with DC.
>
> This point is a bit orthogonal to main thrust of this thread,
> but I didn't want to let Bill's earlier assertion pass
> without comment.
>
> Tim Cole
> University of Illinois at UC
