| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Currie Collection

Page history last edited by Steve Tatum 11 years, 5 months ago Saved with comment

The Project

 

Leonard J. Currie (1913-1996), a student of Walter Gropius, was an architect and educator. He founded the College of Architecture and Urban Studies at Virginia Tech, in Blacksburg, Virginia, then served as Dean of Architecture at the Chicago Circle Campus of the University of Illinois. He returned to Blacksburg for his retirement. He traveled extensively, documenting architecture and his travels with his camera. 

 

I (Steve Tatum) am scanning a selection of the slides, with the help of architecture students, using the new VRA Adobe custom panel. 

 

Reasons for embedding metadata

 

1. Cataloging in the image itself ensures that the metadata is associated with the correct image.

2. Typing is more enjoyable on the panel than on a spreadsheet.

3. Embedding data is one way to preserve the data, and to keep it with the image.

4. The metadata can be exported to CSV files, which are the main vehicle for uploading metadata to repository and display software. In Virginia Tech's Digital Libraries, CSV files are also the main format for preserving data.

 

Destinations of the images and data

 

The immediate destination is the new implementation of DSpace in the Virginia Tech Digital Libraries and Archives. Permissions from the Currie estate pending, I expect the collection in DSpace to be publicly available online. 

 

Once in DSpace, the images might also be discoverable via Summon, a service from Serials Solutions that indexes any content the library provides in a common database. At Virginia Tech, Summon is a portal for searching almost all of the library's content--books, journals, and media, including materials that aren't in the general catalog.

 

Cataloging for the destinations

 

The destinations affect the choices about metadata and access points. I chose two destinations as the most important--the public display in DSpace and discovery with the library's main collection. The Cushman Phoograph Collection of the University of Indiana, which Eileen Fry directed me to, http://webapp1.dlib.indiana.edu/cushman/index.jsp, is a fine example of an online display that is consistent with my aims for the Currie Collection. 

 

Jana Doyle, who does the quality control for the Virginia Tech general catalog, advised me on some features that would integrate the Currie Collection with other library materials for search purposes. Her suggestions included:

 

1. Separate genre/form headings from subject headings, as the Cushman display does.

2. Use both genre (Architectural photographs) and form headings (Slides).

3. Use geographic subdivisions for at least the broad terms. (I then decided to use them wherever TGM allows for the sake of simplifying the task for everyone doing cataloging.)

4. In addition to using TGM's narrow subject terms, use the broad terms that LCSH uses (TGM uses narrower terms for indexing than LCSH.)

5. In the location field. Use TGN (or GNS) strings for geographic location, starting with the country. But, in accordance with LC, not going below the level of City for Cities. The format didn't matter, but she and I like strings with hyphens, going from broad to narrow. Follow the practice of LC geographic subdivisions, restricting the number of levels shown, except include United States and the names of other countries that aren't allowed in subdivisions: United States--Virginia--Blacksburg.

6. Follow LC's practice of assigning a subject term for names of locations and features within cities (Jana's wording).

7. For names of persons and corporations, use the LC/NAF form if it is found there (Jana's wording).

8. Use MARC identifiers for vocabulary sources and relators (roles).

9. Place quotes around any phrases that include delimiters. Library software often uses delimiters. Only three fields in the VRA panel require quotes around phrases with commas or semicolons, but the quotes are necessary in all fields for export to other systems.

10. Use the description fields to put the images into words. Doing so can aid keyword searches. (If done well, the practice could be good for accessibility, too.)

11. It isn't necessary to map to MARC or to use only LC vocabularies. 

 

By way of further explanation, we consult Getty's AAT for terms and ULAN for names in addition to TGM and LC/NAF.

  • For Work Type we use TGM if there is a suitable term. AAT includes more specialized terms for art and architecture, so we use an AAT term if it is more precise than TGM. For example, for a solar house, we use AAT's Solar houses for instead of TGM's Houses.
  • For Keywords (Image Subject) we always include the TGM terms and also include a narrower AAT term if there is one.
  • ULAN is more carefully vetted than LC/NAF, so we use that for the final authority if we question LC/NAF. Virginia Tech is one of the contributors to NAF, so the library's quality control cataloger can correct errors. She made a correction when we found two entries for the architect Sarah P. Harkness, one of which had wrong birth date.

 

Summon doesn't search subjects, just keywords. It treats subject strings as keyword, so you don't get the precision of a traditional catalog, but at least you have a set of relevant keywords. The adaptations aren't specifically for Summon, though. The adaptations really are aimed at a standard library catalog, where names and codes can hook up to at least some extent with authority records and vocabularies.

 

TGM, LCSH, relators (roles), countries, and geographic areas all have URIs at id.loc.gov. I decided not to include them as identifiers, because our library does not have a way to use them.

 

Approach to cataloging: combining general photography with images that show works

 

Len Currie photographed architecture along with typical travel scenes. The VRA panel is designed mainly for a typical visual resources collection, which is a collection of virtual works. Cataloging concentrates on the work, with the image record serving mostly an administrative purpose, such as recording sources, rights, and so on. The VRA panel reflects this emphasis. The work record is far more developed than the image record.

 

For the Currie project, I wanted an equal emphasis on the image and work. One possibility was to treat all images as works in their own right (which I consider them to be), but that would reduce architecture to a subject of the image. Another possibility was to treat travel slides as works, and to treat architectural slides as images. I wanted to treat all slides consistently, though, and my destinations don't require a work record, as visual resources collections do.

 

I decided to catalog all images fully as images, and to use the work record for works shown in photographs. This is the approach that IPTC takes. IPTC Core can record the information about the image itself, including the subject and the location where the image was taken. The IPTC recently enhanced the Core with an extension, which enables the photographer to provide additional information about frequent subjects in professional photography, such as people, artworks, and models.

 

Before the extension, IPTC had the same problem as Dublin Core. It was easy to confuse information about the image with information about the work. As with VRA Core's Image and Work records, IPTC Core plus the extension clears up ambiguities. If the IPTC design suits the needs of the Currie Collection, why not use it? For one, the IPTC format is specific to commercial photography and its highly automated flow of information. The VRA panel can be more easily adapted to library collections. For another, IPTC Core plus the extension might be confusing for student catalogers to navigate. The VRA panel has some nice features to simplify cataloging, such as a choice of views and the ability to hide unused fields. In addition, the custom fields provide for flexibility.

 

Notes

 

Array fields: Image Creator, Collection, and Keywords

  • The quotes that protect commas do not appear in the extracted file.
  • EMET converts semicolons to commas in these fields (but not in other fields).
  • "Doe, Jane, 1900-1986"; "Doe, John" exports as Doe, Jane, 1900-1986, Doe, John.
  • In order to show the original phrases, I am putting a single quote around them. The single quotes can be converted to double quotes in the spreadsheet after export.
  • If I want to distinguish multiple entries with semicolons instead of commas, I guess I'll have to change commas.
  • Mapping:  
    • dc:creator, dc:publisher, dc:subject
    • dc:publisher is not in IPTC. 

 

FileMind extracts more slowly than EMET but is better in other ways. It preserves semicolons and you can select the fields to export.

 

To control the behavior of delimiters in the array fields (Image Creator, Collection, Keywords), you have to use the file info panel. The Bridge side panes and metadata template (Tools/Create Metadata Template) don't work for that.

 

On two different Macs using CS4, the Bridge behavior was different, but neither worked.

  • One put quotes around everything, preserving all punctuation, even when semicolons were intended to be delimiters.
  • The other Mac removed all quotes and treated all commas and semicolons as delimiters. 

There has got to be an explanation, but the point is that it is hard to control delimiters in Bridge.

 

 

 

 

 

 

 

 

Modifying the use of the panel

 

The panel places the emphasis on works. Instead, I am placing the emphasis on the image. 

 

The fields affected are:

 

View Description used as Image Title. (View Description maps to VRA Core 4 Image Title in the panel's XMP.)

 

Keywords used as Image Subject. (Keywords maps to Dublin Core Subject and IPTC Keywords.)

 

Caption/Description used as Image Description.  (Caption/Description maps to Dublin Core Description and the current IPTC Description.)

 

Custom fields added:

 

Free Text Date e.g., June 11, 2011. The Original Date will be a search date, probably in ISO format YYYY-MM-DD.

 

Location Shown The location shown in the image. It is a string from large to small based on TGN.

 

Box The box number we assign to the box or tray that Len Currie left his slides in. Also records any information Currie wrote on the box or divider.

 

Note Usually a transcription of Len Currie's writing on the mount in cases where we have altered it in the record, such as by expanding abbreviations.

 

Genre/Format Genre and Format headings.

 

 

Exporting to different destinations

 

I do not yet know the mapping that will necessary for the immediate destination, DSpace, nor the amount of control I will have over the public presentation. The cataloging instructions are designed to work well in the panel in its own right, and also to anticipate discovery in the library system. Some of the images will also go into SAHARA.

 

The SAHARA images will be ones that show architecture, so the work fields will be filled to the extent that we have information. Mapping will be straightforward, because the panel is designed for collections such as SAHARA. If I were to put a mix of images--with and without works--into my visual resources database, I would have two choices (that come to mind at the moment). 1. I could treat all the images as works in their own right and map the works they show accordingly. 2. I could decide case by case which slides to catalog as works in their own right which ones to catalog as images. For the latter, the art or architecture would be the works.

 

For now the idea is to export a master CSV file that can be massaged to map to different destinations. From the master, I will map all of the images to DSpace. I might also map a selection of images to directly to SAHARA rather than make a derivative from DSpace. Similarly, should the images ever go do a different destination, I like to work directly from the master again. The reason is that mapping involves distortion and the farther down the line you go, the more distortion you are likely to have.

 

Suggestions for revising the panel to use with general photo collections

 

1. Move the Summary section to be immediately below the image section, so that the summary can be more easily associated with images.

2. Move DC Title to the Summary so that it can be more easily used for the image title. That also brings the key information from IPTC core together, for any one who uses IPTC Core for preliminary cataloging. For example, several programs allow the addition of IPTC core metadata when importing images from a camera.

3. Make the font in DC Title the same size as in other fields.

4. Add a display field for Location Shown to the image record. Suggestions are the IPTC Core location set, for the sake of interoperability with many photo apps, or VRA Core 4 Subject Geographic Location. 

5. Add a field for Genre/Format headings. That could be VRA Core 4 Image Work Type.

 

Location Shown and Genre/Format are the standard fields that general image collections are likely to have in common. Anything else for specific collections can be left to custom fields. These additional fields could be hidden by default, because they are a secondary use of the panel.

 

None of these suggestions interfere with data already entered into the current Beta version of the panel.

 

 

 

 

 

 

Comments (0)

You don't have permission to comment on this page.