Group 5: Amy Pinc, Katie Cheever, Selim Layouni Pereyra

Institution: Chicago Architecture Library

Collection Name: Libraries in Chicago, Hidden Gems Collection

In the first section of the body of the report, describe your institution and digital collection, the
user population for the collection, and the metadata schemes you will use to catalog the
collection. Give some background on the collection and why it is important.

The Chicago Architecture Library focuses on the architecture of buildings and structures in the
Chicagoland area. The collections include books, architectural drawings, photographs, exterior
and interior designs, and scale models. The library collects anything related to architecture
including items for both important buildings and individual residences. The actual library is in a
small space, that can only house a small portion of our collections at a time, the rest is in a
off-site storage facility. In order to accommodate more patrons the Library has been focusing on
digitizing much of its collections. The collection this report looks at is the Hidden Libraries of
Chicago collection. While the collection features many famous libraries in Chicago and the
surrounding area, this collection focuses on hidden design and architectural features that are
often missed in large scale building photographs and drawings. The librarys users population is
made up researchers, architects, enthusiasts, and the general public. The metadata schemas that
the Digital Initiatives department and Metadata Librarian decided on are Dublin Core, Qualified
Dublin Core, and VRA Core. These schemas were chosen to be both simple enough for basic
searchers and information and to be detailed enough to be useful to researchers and architects.
Using Dublin Core as a metadata standard was decided because then the records for the
collection could be harvested into other repositories for reuse and discovery. Qualified Dublin
Core allows for more specificity indexing than Dublin Core but is still easy to comprehend and
does not cause information overload for users who mainly are interested in the images. VRA
Core 4.0 was decided upon because it can better express and describe certain aspects of the
physical buildings and the photographs and it has a more sections that can be indexed for
searching for the researchers and architects. VRA Core can allow for extremely specific and
detailed records especially because some of the photographs are of small sections of the whole
building. VRA Core will be the metadata used to display information about an image on the
website, although there is an option for people to look at the qualified dublin core record for a
simpler record. The repository allows people to create their own tours, using images and the
metadata provided to create a map of places they want to visit. That is why field for address is
important in the metadata record, because it allows users to easily find the building if they
choose to create a tour.

How did your group divide the work?

The group decided to work on the Metadata Application profile together during the class time
allotted for the project. This was beneficial because the members of the group could bounce
ideas off one another and workout out an issues with the profile together when those issues
arose. The group decided to split up the different sections of the group report. Amy worked on
numbers one and two of the group report and the first two bullet points for number three. This
was decided because the first section and the first two bullet points of the third section were
relatively simple and straightforward. Selim worked on the third and fourth bullet points for
number three. Katie worked on the fifth and sixth bullet points. All group members helped to
come up with the name of the institution, collection, and the type of items in the collection.

Did you use any outside sources to create your metadata application profile? If so,
please cite.

We did use some outside materials when creating the metadata application profile including the
Dublin Core and VRA Core Websites, Dr. Snows example Metadata Application Profile, and
Steven J. Millers metadata mapping chart.
Sources Consulted:

Miller, Steven J. "Dublin Core, MODS, and VRA Element Mappings - ALA Store." Web.
Retrieved December 02,2016. Originally From Metadata for Digital Collections: A
How-to-Do-It Manual by Steven J.
Snow, Karen. Famous Trees of the United States - Metadata Application Profile (MAP.)

VRA Core 4.0 Element Description: Retrieved December 02, 2016.

https://www.loc.gov/.../vracore/VRA_Core4_Element_Description.pdf

Dublin Core Metadata Element Set, Version 1.1. Retrieved December 02, 2016, from
http://dublincore.org/documents/dces/

What were some of the challenges your group faced while creating the application
profile and metadata for the collection?

When we started creating our records, we soon realized that some of our local element names
had to be modified, deleted, or added according to particular cases. Likewise, the way we
originally mapped the elements from one metadata scheme to another suffered some alterations.
As a group, we decided to use VRA Core, since it was the metadata scheme that better fit our
goal, which is to describe works of art (in our case, architectural work). However, using VRA
Core was a real challenge in the sense that it demanded a level of granularity and specificity that
was not required when creating our Dublin Core records because this metadata schema is more
generic and flexible.
When we created our first Metadata Application Profile (MAP) we focused more on the image or
resource description rather than describing what those images were depicting. Because of this,
we initially did not contemplate the need to include the architect/creator value nor the date the
building was constructed. After correcting this issue on our MAP, we also realize that we better
should employ three different type of dates: the date when architectural work was built, the date
when the picture was taken, and date when the picture was added to our collection.
Another problem that arose when we were creating the VRA Core record was what kind of
values we should input for the attributes id, refid, and source in the element work. After
thinking about this, and even consulting the instructor, we decided to use as a source the
Library of Congress Name Authority File, and its unique identifier as the refid. Another
challenge we had was whether assign an identifier for the work, as well as an identifier for the
photograph in our collection. After consulting with our instructor, we decided to use both types
of identifiers, using Library of Congress Name Authority File as the unique identifier for the
physical place. We also initially considered our institution as a value for the contributor field
in Dublin Core, but it was decided that including this value would not properly apply, since our
institution was more suitable for the publisher, and rights fields.
As stated earlier, thanks to the granularity of VRA Core, new local elements had to be added in
order to reflect accurately all the information available in our records. The local element
Building Materials was added to conform to the VRA Core element MaterialSet. The local
element Building Materials was mapped to both Dublin Core records as Subject. Similarly,
we decided not to map the Cultural Context (American) element from VRA Core into Dublin
Core Coverage element because it would be redundant. Further uncertainties arose when
deciding whether to include the VRA Technique element. After expressing our opinions, we
decided that it would be better not to include this element at all because it was too common.

How well did each metadata scheme map to your local elements? Was there any
loss of information?

We found that most of the information gathered in order to create our records and populate our
MAP local elements were satisfactorily used. The process to map our local elements to both
Dublin Core records was relatively smooth and uncomplicated, thanks in great part to the
flexibility that Dublin Core allows. However, VRA Core did present some challenges that
needed careful consideration in order to map it correctly to our local elements. Some values that
appeared in our VRA Core record made us modify and add local elements while other values
were deemed not important enough to be included in our MAP, such as the Technique
element. In other cases, we input information that good practice demanded in The VRA Core,
like bibliographic information in the VRA Description Source sub-element, but that
information was not required or applicable to our Dublin Core records. The Cultural Context
Set was another VRA element that overlapped with the spatial refinement in the Dublin Core
coverage element. In all three cases, the work creators were Americans and that condition was
reflected in the aforementioned element. Finally, due to difficulties in obtaining information
about the physical places dimension, we decided to only input measurements values related to
our images.

Did you need to change your application profile once you began creating records
for the photographs? If so, give a few examples of what you changed and why.

We did need to change our application profile once we began creating records. One of our group
members got their records done early and so we were able to change some things before the
other two members got far into creating their records. After wed gotten all our records done we
made more changes to the application profile after discussing some things we had issues with.
Digital Format is one of the areas we changed. In both Dublin Cores we have it mapping to
format and originally we had it in Work Type for VRA Core, but we realized that this was the
wrong area for it and changed it to measurements (image) indicating that we would use that for
just the measurements in the image record. Many of the changes we did were for clarity in the
VRA Core records where the information was going to go. We added Building Technique into
our Local Element, because VRA Core has a technique element and we wanted to use it. So we
made that a Note in the Dublin Core schemes. However, we realized that the building technique
for every building is the same, construction (assembling), and realized it wasnt important
information to include in the record and no one had remembered to put it in their Dublin Core
records. So we removed the local element and its subsequent elements in the different schemes
all together.

How did your group address issues of metadata quality?

We found out the struggles of mapping our local elements to Dublin Core and to VRA Core.
Since VRA Core is such a richer metadata scheme many of the elements dont map easily to
Dublin Core nor even to our local elements. We wanted to make sure everything mapped like it
was supposed to and that we had quality metadata. As we found out that we had to make some
decisions on what to keep and what not to keep. Like mentioned in the last section, we decided
not to use the technique element from VRA Core because it didnt easily map to Dublin Core
and wasnt important information. We wanted to be complete and consistent as possible when
using VRA Core, but realized that some of the information in the elements of VRA Core werent
important for the type of database that our items were being added to. Since our digital library is
part of an architectural library, we made sure that we had information in our elements that helped
architectural minded people. Information like the architectural school/type of the building that
was photographed and the architect were information we knew our users would search for.

Images:

The Winter Garden at Harold Washington Library

The 9th Floor
Taken by Katie Cheever
Front of the Newberry Library
Taken by Selim Layouni on 11-20-2016
Front Copper Facade of the Oak Park Public Library, in the Snow
Taken by Amy Pinc on 12-04-2016