| 
  • 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
 

Virginia Landscape XMP Panels

Page history last edited by GregReser 14 years, 1 month ago

A custom XMP panel for the Virginia Speedway Database

Steve Tatum, Virginia Tech

 

 

The Project

Ed Brooks, who works with maps and GIS materials in Virginia Tech's Newman Library, has been a NASCAR fan since childhood. Brian Katen, currently Chair of the Department of Landscape Architecture in the College of Architecture and Urban Studies, has been a frequent patron over the years. Brian travels through Virginia collecting oral accounts, news articles, and any other materials he can find about speedways. Some speedways are no longer in use, while others still are. When someone tells him, for example, that there used to be a speedway twenty miles over in that direction, Brian comes to the library to look through aerial photos of the region to find signs of the old speedway. Through his personal interest, beyond the call of his responsibilities, Ed offered to create a database in Luna Insight of Brian's speedway materials. Ultimately, there will be news clippings (scanned as TIFFs), photographs, aerial photo, sound recordings, video, and PDFs. Parts of the collection that are cleared for copyright will be public. Other materials will be reserved for Brian's classes.

 

This summer, Ed hired one of my student assistants, Marie Williams, to catalog the materials and help put them in Luna. The three of us have worked together, and consulted with others, to design a metadata schema. In the space of about two days, Kimberli Weeks of Virginia Tech's Digital Libraries told me about RDF and how it could be used to combine schema.

 

Objectives

1. We wanted the database to be able to communicate with databases in the Virginia Tech Digital Libraries and Archives, which uses mainly Dublin Core, but also other schema with RDF. We do not know whether that will ever be possible or necessary, but trends are in that direction, so we wanted to lay the groundwork.

2. We wanted a our cataloging methods to be independent of any one system for display.

3. We wanted a schema that we can use for other GIS and local history projects that are likely to come Ed's way, such as one on cemeteries.

4. We wanted to embed the metadata in the archived digital files as a preservation measure.

 

More background


Implementation of schema

 

Dublin Core:

We selected Dublin Core because it is central to much of the work in Virginia Tech libraries. By itself, it could handle all of the information we needed to search and present in a record.The point of using Dublin Core was to allow a critical portion of the schema to map directly to a lot of other cultural collections in libraries and historical societies. We follow the Dublin Core Elements standard strictly, according to our understanding, including the one-to-one rule. We consistently use DC to catalog a text document or a documentary photograph.
 
DC and DC Terms
Since the Dublin Core data would be shared with Virginia Tech Digital Libraries and Archives, it was mandatory that we mimic their use of the DC Terms schema.  The native metadata mapping in Photoshop CS products does not include DC Terms, only DC, therefore the data that is entered using the VA Landscape custom panel will live as a separate data set in the XMP file.  We will have two distinct, unsynchronized sets of Dublin Core data: DC and DC Terms.  While this might seem to present a problem, it actually serves an important purpose: it segregates user data from curator data.  The faculty contributor enters information in the Photoshop "Description" panel which is written to DC.  By writing the cataloging data to DC Terms, we preserve the primary source material and distinguish it for easy export later.  The description provided by the contributor serves as a starting point for the cataloger who parses it out to the appropriate DC Terms elements.
 
namespace: http://purl.org/dc/terms/

prefix: dcterms 

  

SKOS

Chosen because Dublin Core does not have a note field. We wanted a notes field for the resources, so followed Virginia Tech Digital Libraries and Archives practice of using the SKOS note field.

 

namespace: http://www.w3.org/2008/05/skos#note/

prefix: skos

  

CDWA

Chosen because it has elements that closely match Virginia Tech's existing cataloger information elements.

 

namespace: http://www.getty.edu/CDWA/

prefix: cdwa

  

VRA Core 4

Chosen because it allow us to expand on the work (a speedway, for example), which is the subject of the document or photograph. Also, cataloging both the document and the work is consistent with the philosophy behind the research, which is to catalog a virtual collection of speedways and also a virtual collection of the documentation of them (the researcher often does not have the original documents).  Dublin Core allows us to provide limited information about the speedways in the coverage and subject fields.  The problem was that we wanted to focus on the speedways, not the documentation about them. The documents are significant and interesting, but the database is about the speedways. We wanted to emphasize them more, provide a little more information about them, and search date ranges.

 

Work / image record? Since the Core 4 data would only describe the original work, such as a speedway itself, we only allowed for a single set of VRA elements.  Image metadata was stored in the Exif and Photoshop schema. 

Sub-element and attributes?  Since the main function of the VRA data is to provide ready reference about the speedways for people looking at the documents, we decided that structured sub-elements and attributes were not necessary.  To allow for the clarification of complex information, we included note elements for Title, Agent, Date, and Location.
 

namespace: http://www.vraweb.org/vracore/4.0/

prefix: vra

 
  Dublin Core Terms
CDWA SKOS VRA
Core 4.0
Resource (original photos, clippings)

X

 X

X

 

Site shown in the resource (speedway, fairgrounds)



X

 

See the full element mapping and definitions

 


XMP Panels

 

CS2 / CS3 panels (click for full size version)


 

VirginiaLandscapeResource1.txt


 

VirginiaLandscapeResource2.txt


 

VirginiaLandscapeSite.txt

 

 

 

 

 

 

 

 

 

 

 

 

CS4 Panel (click for full size version)

 

CS4 Files: VALandscape.zip

Bridge sidebar panel: VAlandscape.xml

Readme.txt

 

 


Sample Image and Data

 

Go to: Virginia Landscape Record CS3

          Virginia Landscape Record CS4


Problems encountered

 

Unable to preserve commas

XMP allows you to enter multiple values in an element and have each one written on a separate line.  This is known as either alternate, sequential or bag structured data.  According to the Adobe documentation, the command “preserve commas” will allow only a semicolon to act as the separator making it possible to use a comma in a string of text.  However, we discovered that this does not work in the Photoshop panels. 

 

For example, we wanted to create a bag structured list of terms that contain commas, e.g., Hurt, Robert; Christensen, Lars Lindberg

The XMP should look like this:

<dc:contributor>

<rdf:Bag>

<rdf:li>Hurt, Robert</rdf:li>

<rdf:li>Christensen, Lars Lindberg</rdf:li>

</rdf:Bag>

</dc:contributor>

 

The problem is that when the XMP panel closes, the commas are changed to semicolons and each term is written as a separate entry in the bag.  Like this:

<dc:contributor>

<rdf:Bag>

<rdf:li>Hurt</rdf:li>

<rdf:li>Robert</rdf:li>

<rdf:li>Christensen</rdf:li>

<rdf:li>Lars Lindberg</rdf:li>

</rdf:Bag>

</dc:contributor>

 

This means that users can’t use a comma in any field that allows multiple entries.  It turns out that this is a PS CS3 coding choice for bag/seq delimiters - to be either a comma or semi (though it always displays as a semi).

 

Since many fields will have commas a normal punctuation, such as location, LCSH subjects, sources, etc., we decided to make all elements text strings with semicolons as the delimiter between terms - no sequences of terms on separate lines.  This was the simplest because VT are going to copy and paste between the CS panels and spreadsheets, which already use semicolons as delimiters.  Also, the VT Digital Libraries and Archives use semicolons as delimiters.  We didn't see any harm in having semicolons in fields even after they have been converted to RDF/XMP.  That's better than having commas break up fields in the wrong places. The VT digital libraries do not expect perfection in interoperability as long as you can search the data, see the data, and tell what it means. They really like controlled vocabularies with LCSH being the common denominator. The vocabulary and the RDF are probably enough for them.

 


 

 

Go to:

Virginia Landscape CS3 Panels

Virginia Landscape CS3 Example

Virginia Landscape CS4 Panel

Virginia Landscape CS4 Example

Virginia Landscape - Element Map

Virginia Landscape Record CS3

Virginia Landscape XMP Panels

Virginia Landscape XMP Record

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Comments (0)

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