Dear Tony,
Thanks for cross-posting your message. I think that a significant amount
of confusion remains about the varying roles that metadata can play. This
really doesn't have anything to do with the nature of the information
object, but rather reflects a lack of clarify on the part of the 'metadata
manager' about why a resource is being described, and the functions that
metadata is to support.
The Dublin Core has always been positioned as a tool for enabling *resource
discovery*. This is the first in a series of stages in the research
process, which is conceived as an information use cycle. David Bearman
presented these stages at the Image metadata meeting. [We've got a draft
article in the works that refines this schema further]. The basic premise
is that different kinds of metadata are required at different points in the
process. An extensible architecture, such as that of the Warwick Framework,
is essential for allowing metadata to acrue to an information object over
time, and through use.
The stages in the research process:
1. Information Discovery - finding it
- This is the stage of the process at which the Dublin Core is
directed. It focusses on the location of an object in networked information
space.
2. Information Retrieval - getting it back to your workspace
- Here such issues as technical dependencies, and access
permissions become more critical, as information that is essential to move
an object from one technical environment to another. Howard Besser spoke a
lot about the technical characteristics of an image, for example.
3. Information Use - doing something with it [3 parts]
- This phase is where the user actually does something with the
information resource. Discipline specific schema for knowledge
representation and methodologies for analysis come into play.
A. collation
- Putting a newly retrieved information object into a user
or discipline defined schema that relates it to other known things. This
requires metadata that describes the schema used to create the existing
object, and that allows the user to establish equivalencies between
metadata created in different places. Thesauri, for example, can aid in the
'translation' between controlled vocabularies and preferred scholarly
terinology.
B. analysis
- The interpretation of the meaning of the object - perhaps
drawn from its new context. This will depend on the methodology of the
study, and the discipline of the user. Some tools for analysis, such as
statistical packages, will depend on the availability of metadata that
describes the structure of an information object in detail.
C. Re-presentation
- The creation of new information objects that are based
on, or incorporate, this object. Genres for presentation vary from
discipline to discipline; consider the pre-print, the scholarly article,
and the exhibition as forms of presentations. New information, to be
discovered in a subsequent process is created here.
I'm not sure what the goals of the REACH element set fits are, or how they
fit into this schema. Any thoughts?
jt
At 10:56 AM 3/6/97, Tony Gill wrote:
>A few thoughts on the relationship between the REACH Element Set and the
>Dublin Core....
>
>The scope of the Dublin Core has changed over the course of its
>development, and consequently there are some differences of interpretion
>as to its role in life; I haven't seen any responses from DC people on
>this list yet, so I hope the interpretation I give here isn't too
>inaccurate. I'm cross-posting it to the meta2 list, so hopefully I'll be
>notified if I get any of this wrong!
>
>DC (or the Dublin Core Metadata Element Set) was originally intended as
>a means by which 'document-like objects' on the Internet could be simply
>and easily described as an aid for resource discovery; however, DLO's
>were only ever defined by example. Although from the outset it was
>envisaged that web pages would be the most significant area for
>deployment of DC, it has never been limited solely to this application.
>
>Subsequent workshops have gradually extended the scope of DC; The 2nd
>workshop resulted in the Warwick Framework, a conceptual container
>architecture for diverse metadata 'packets' of varying flavours. The 3rd
>workshop focussed on the use of DC to describe images, and consensus was
>reached that, with a bit of shuffling of the element names and
>definitions (e.g. AUTHOR --> CREATOR), DC could realistically be used
>for images. This led to the extension of the 'Document Like Object'
>concept to include almost any static information object that appeared
>identically to all viewers, i.e. things that don't change according to
>any input parameters or point of view. The 4th workshop, earlier this
>year in Canberra, introduced the notion of optional qualifiers (TYPE,
>SCHEME & LANG), which can be used to refine (but not extend) the scope
>of individual elements, link them to formal schemes and indicate the
>language in which the metadata (as distinct from the data, which has
>it's very own element) is encoded.
>
>What hasn't changed is the role of DC -- it is a tool for encoding
>metadata for resource discovery, and should always be used to describe
>networked digital resources. The REACH Element Set, however, is a common
>set of elements for describing the properties of museum object records.
>
>However, there is a lot of tension here, as Murtha rightly points out;
>if a digital resource contains information about an object, or even a
>surrogate of an object, then much of the metadata needed for effective
>retrieval of the digital resource needs to be 'inherited' from objects
>&/or their surrogates along the way (don't worry, I'm not going to start
>waffling about object-oriented techniques etc. ;-). This is where the
>apples and oranges start to get mixed up.
>
>This is not so much of a problem for bibliographic information, where
>information about the 'work' is usually far more significant for
>retrieval purposes than information about it's physical manifestation.
>
>We also ran into this difficulty recently at the Visual Arts, Museums &
>Cultural Heritage Metadata Workshop, and have produced a draft set of
>optional DC qualifiers that are intended to address the problem of
>distinguising between original objects, surrogate objects and network
>resource objects, and also between digital and analogue objects. These
>recommendations for visual-arts-&-museum-specific DC qualifiers are
>still being reviewed by an Editorial Board, but have been mapped to the
>draft REACH Element Set and will be available on the web from 9 June at
>http://vads.ahds.ac.uk/Metadata4.html. The rest of the report is already
>available, at http://vads.ahds.ac.uk/Metadata1.html. There is also a
>review of pertinent standards at http://vads.ahds.ac.uk/standards.html.
>
>Clearly, although the values stored in the REACH and Dublin Core sets
>may be closely related in the case of networked museum information, the
>two have a fundamentally different role; REACH will be used for storing
>data about museum objects, DC is used for metadata about networked
>resources. Compatibility between the two is still very important though,
>because Dublin Core metadata can then be more effectively used to
>describe REACH data records for networked retrieval.
>
>Murtha Baca wrote:
>
>> [Dublin Core] is intended as an access tool for web pages (at least that's
>> how I understand it as well), but in my humble opinion it also mixes
>> apples and oranges -- the "object," whatever it might be, and the
>> "surrogate," be it digital image, text document, etc.
>
>> Maybe if we all keep thinking about this, it will all become clear in the
>> end...
>
>I hope so!
>
>cheers,
>
>T.
>-- Tony Gill ---------------------- Programme Leader: ADAM & VADS --
> Surrey Institute of Art & Design * Farnham * Surrey * GU9 7DS * UK
> Tel: +44 (0)1252 722441 x2427 * Fax: +44 (0)1252 712925
>-- [log in to unmask] -- http://adam.ac.uk -- http://vads.ahds.ac.uk/ --
--------
J. Trant [log in to unmask]
Partner and Principal Consultant www.archimuse.com
Archives & Museums Informatics
5501 Walnut St., Suite 203 ph. + 1-412-683-9775
Pittsburgh, PA USA 15232-1455 fax + 1-412-683-7366
--------
