data elements to be collected

After a site visit and consultation with the curator, I have determined that for quick cataloging the following basic data elements are necessary:

• accession number, if any
• transcription of label text
• box number
• date
• condition
• brief description
• donor or source, if known

The curator states that the collection is basically undocumented and that with present resources only the most basic information can be recorded (B. Veksler, personal communication, May 16, 2002). I devised a basic data entry interface to meet the need for quick cataloging.

The museum director, however, states that the emphasis during the next year will be on detailed documentation of approximately 500 museum objects. These will be thoroughly described, then photographed, as part of a project funded by the Luce Foundation, with the intent of integrating the Drexel Digital Museum into the Open Archives (K. Martin, personal communication, May 23, 2002). I began to devise a more complete data entry interface for detailed cataloging.

At minimum, for more thorough cataloging the basic elements above are necessary, plus data elements representing each of the unqualified Dublin Core elements, for Open Archives compliance. These might include

• object name (DC.Title)
• creator of object (DC.Creator)
• thesaurus terms for object (DC.Subject)
• physical description of object (DC.Description)
• transcription of label text (DC.Description)
• publisher of image of object (auto-fill data element) (DC.Publisher)
• project name or funding source (DC.Contributor)
• creation date of object (DC.Date)
• object format (costume, costume accessory, textile, etc.) (DC.Format)
• accession number, if any (DC.Identifier)
  
• box number (DC.Identifier)
  
• provenance (DC.Source)
• language of record (auto-fill data element) (DC.Language)
• file name of image of object (DC.Relation)
  
• style or period of object (DC.Coverage)
• copyright information (auto-fill data element) (DC.Rights)

For exhaustive cataloging, a data element would be collected for each of the over 150 data fields identified in the metadata crosswalk.

interface requirements

The data entry interface will

• be attractive
  
• be easy to use
  
• require little training or instructional material
  
• accommodate both first-time and experienced users
  
• provide online support, including thesauri, authority files, crosswalks, and definitions of data elements
  
• accommodate the cataloging workflow and not require the user to change processes to accommodate data entry
  
• be divided into manageable and sensible "chunks"
  
• allow entry of all required data elements
  
• allow entry of both controlled and uncontrolled vocabulary
  
• not require entry of data in the same order that the data will be displayed in the public interface
  
• support full or partial cataloging of objects
  
• allow printing of catalog record at any point in the data entry process
  
• allow display of catalog record in public display format at any point in the data entry process
  
• include printable cataloging worksheets and checklists
  
• be expandable as new data elements are required
  
• require minimal use of mouse
  
• require entry of userid and password for access

back-end software

While design of the cataloging software and database is beyond the scope of my project, several features are implicit in the design. For instance, the software should

• match any text entered against the thesauri and authority files and flag uncontrolled vocabulary for review by curators
  
• record date, time, and userid of changes to catalog records
  
• provide auto-fill of data fields which are the same in every record; for instance, owner: Drexel University
  
• allow subsequent editing of auto-filled data fields if necessary

outline of data entry workflow

The order in which the interface asks the cataloger for data elements should match the cataloger's natural workflow. The outline below is based on my guesses of what that flow would be. Ultimately, however, the interface must be tested and re-tested against actual cataloging practice.

The work is broken up into sensible chunks or groups of 10 to 20 elements in order to make the interface less intimidating, to break the work into easy units, and to encourage frequent proofreading and saving of data.

GROUP 1
accession information
current storage location
transcription of text

GROUP 2
object type
classification

GROUP 3
measurements
parts and components

GROUP 4
materials and techniques
conservation and condition

GROUP 5
physical description

GROUP 6
creator
creation dates
style or period

GROUP 7
provenance
related documentation

GROUP 8
imaging information

GROUP 9
copyright and rights information
AMICO-specific elements

GROUP 10
deaccession information

Auto-fill data would include current owner information, most imaging information, cataloging dates and times, and cataloger userids.

action required

next page: theoretical discussion

back to project home page

Donny Smith
May 2002
[email protected] or [email protected]