Maybe this is a silly remark from me, but does it really matter in what
element (Coverage or Subject) some (redundant?) information may "sit"?
As long as the retrieval software is aware of this, it would do no harm
to the retrievability, I presume?
[log in to unmask] wrote:
>
> ------- Forwarded Message
>
> Return-Path: [log in to unmask]
> Received: from elmer.harvard.edu (elmer.harvard.edu [128.103.151.248]) by
> elmer.Harvard.EDU (8.6.12/8.6.12) with SMTP id QAA18054 for
> <[log in to unmask]>; Thu, 10 Apr 1997 16:57:55 -0400
> Date: Thu, 10 Apr 1997 16:57:55 -0400 (EDT)
> From: "R. Wendler" <[log in to unmask]>
> Reply-To: [log in to unmask]
> To: [log in to unmask]
> Subject: Re: Coverage-Element - working draft for discussion
> In-Reply-To: <[log in to unmask]>
> Message-Id: <[log in to unmask]>
> Mime-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Interesting work, folks! Comments below...
>
> On Wed, 9 Apr 1997 [log in to unmask] wrote:
>
> > a. There is some feeling that Coverage should be used only for what might be
> > termed non-fiction works - for example, a scanned map of Montana - and not for
> > such works as a novel that takes place in Montana. It would be difficult to
> > explain this difference to Webpage users, and I suggest we keep Coverage for
> any
> > sort of spatial or temporal coverage, rather than say, sometimes it's Coverage
> > and sometimes it's Subject or Keyword.
> > Or, to put it another way, that Coverage be used only for certain aspects.
> For
> > example - a ceramic pot; should Coverage - Spatil refer to where the pot were
> > made, or where it were found? I suggest that since it is a repeatable field,
> > one may have a Coverage field for each of these.
> > b. There is a viewpoint that Coverage is a type of Subject or Keyword and
> should
> > be subsumed under that element. This is a topic that catalogers in libraries
> > have been arguing about for years - that is, whether geographic area is a
> > subject or not. It is included in subject headings; but it is dealt with as a
> > separate type of heading from thematic headings. For example, in USMARC,
> > thematic terms (e.g., Geology; Anthrpology; etc.), geographic terms, and
> > chronologic terms are each given different field codes; these are usually $x
> for
> > thematic, $z for geographic, and $y for chronologic headings.
>
> It is true that the distinction between topical and geographical
> subjects in preserved in MARC data. However, at least in the U.S.,
> library system functionality rarely makes use of that distinction.
> While they could easily allow users to make this distinction in
> searching, the vast majority of libraries do not do so. What about
> libraries outside the U.S.? (Or does someone in the U.S. disagree with
> the observation?)
>
> In Canberra a lot of disparate opinions were on view about when
> the subject element should be used vs. when coverage should be used;
> if we can't keep it straight, how do we expect a searcher to?
> The very word "coverage" may contribute to my unease -- a book may
> be said to "cover" the women's suffrage movement, may it not?
> I am (I think...) sympathetic to the subject camp for certain cases:
>
> 1) There is conceptual difference between what a thing *is* and
> what a thing is *about*. For example, data *is* collected during
> a given interval; the data represents (*is*) the climate of North
> Africa. This pot *is* from 16th century China whereas that novel
> is *about* an imaginary pub in Islington. Coverage could be seen
> as an *is* element, so to speak. (Yeah, yeah -- it's not always
> clear, but you understand my point, I hope.) It may be a disservice
> to lump those things together for retrieval.
>
> 2) If I understand correctly, DC was originally conceived to improve
> retrieval of network resources across domains rather than just within
> domains, but it seems unlikely that the wide range of types,
> formats, and intentions of the information in the coverage element
> can be meaningful if the qualifiers cannot be interpreted.
> (Canberra Qualifiers Rule, yes?)
>
> This state of affairs might be fine if we were dealing with textual
> data, where you won't search Timbuktu and mistakenly retrieve the
> Gilded Age, but when the data can be numeric values coded according
> to a wide variety of schemes, the data seems meaningless without
> qualification.
>
> For that reason I'd love to isolate textual *subjects* which have
> geographic or temporal components from the admittedly critically
> important coded data about capture or representation needed for
> sophisticated geo-spatial retrieval. Unlike other fields where,
> when you can't interpret the qualifier, you may continue to process the
> data, many of us may be reduced to simply dropping any coverage field
> whose qualifier is unknown on the assumption that without a specialized
> retrieval environment, it will be noise.
>
> Some geographic and temporal information will be put in the subject
> element no matter how this is decided. Consider Library of Congress
> Subject Heading Strings, which are composed of topical, geographic,
> chronological, and form sub-elements which themselves may be less useful
> if decomposed. If the Dublin Core guidelines instruct the use of
> subject for topics and coverage for temporal/geographic data, you'd see
> things like:
>
> ELEMENT=subject CONTENT=Scholars, Muslim--Mali--Tombouctou--Biography.
> ELEMENT=coverage CONTENT=Tombouctou (Mali)--Biography.
>
> So you'd have to index them together or risk giving people only half the
> story.
>
> (As usual, I'm coming from a metadata-import/use rather than a
> metadata-creation perspective.)
>
> Hi to the Canberrites! Tans faded yet?
>
> Robin Wendler ........................ work (617) 495-3724
> Office for Information Systems ....... fax (617) 495-0491
> Harvard University Library ........... [log in to unmask]
> Cambridge, MA, USA 02138 .............
>
> ------- End of Forwarded Message
--
Frank A. Roos ([log in to unmask])
CWI - Centrum voor Wiskunde en Informatica / Bibliotheek
- Centre for Mathematics and Computer Science / Library
http://www.cwi.nl/cwi/departments/BIBL.html
|