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

Institution: Chicago Architecture Library/Chicago Architecture Digital Library

Collection Name: Libraries in Chicago, Hidden Gems Collection

The Chicago Architecture Library focuses on the architecture of buildings and structures
in the Chicagoland area. The collections include books, architectural drawings, photographs of
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 a small space, that can only house a small portion of our collections at a time, the rest
are in an off-site storage facility. In order to accommodate more patrons, the library has been
focusing on digitizing much of its collections and making more born digital collections available
online. The collection this report looks at is the Libraries in Chicago, Hidden Gems Collection. It
will be located in the Chicago Architectures Digital Library, where we house our digital
collections. The collection consists of digital photographs of interesting and famous libraries in
the Chicagoland Area. 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. This collection is important
because it allows people access to view Chicago library architecture from anywhere and the
photographs often are good mix of close ups on design elements and architectural features as
well as the building as a whole. Chicago is known for its architecture which extends to many
libraries in the area, which were thought up and designed by famous Chicago architects.
The librarys user population is made up of researchers, architects, enthusiasts, and the
general public. We welcome anyone who has an interest in architecture from the novice to the
professional. The metadata schemas that we 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 the records for the collection could be
harvested into other repositories for reuse and discovery. Qualified Dublin Core allows for more
specificity when 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 more sections that can be indexed, which is helpful for the
researchers and architects. The VRA core records allow for records of both the building and the
image of the building, whereas the Dublin Core and Qualified Dublin Core, in order to keep
things simple combine both in one record. VRA Core can allow for extremely specific and
detailed records especially because some of the photographs are of small sections of the whole
building. With VRA core we can add additional views and images of a building to the main
building record. 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 website allows people to create their own tours, using images

1
and the metadata provided to create a map of libraries they want to visit. This is why the field for
address of the building 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 any 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
amount of work 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 detailing challenges and in creating the profile and how well the
metadata schemas mapped to local elements. Katie worked on the fifth and sixth bullet points,
addressing changes we made to the profile as the group completed our records and the issue of
metadata quality. All group members helped to come up with the name of the institution,
collection, and the type of items in the collection.

Sources used in the creation of the Metadata Application Profile

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.

2
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 should
employ three different type of dates: the date when the 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. This worked
well for most of the group, though one building was not in LCNAF and it was decided to use the
librarys website as the source and to create a refid because one did not exist. Another challenge
we had was whether to 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, rights, and relation 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.

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

3
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.
Another issue we ran into was architecture firms change names often, adding or
subtracting names from the firm title, which can make filling in the creator field challenging.
One such challenge appeared because the library website, for the building in an image, listed the
architecture firm as one name, but the LCNAF listed it as another. After some investigation it
was found that both were indeed the same entity, but which name should be placed in the creator
field. In this case, for better indexing it was decided that the LCNAF name should be listed as the
creator in the two Dublin Core records and as the indexed term in the VRA record. It was then
decided that the name the architecture firm used when creating the building could be important
to users so it was used as display name for the agent.

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?

4
 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.
Additionally, while creating the records we decided that for the Dublin Core records to
follow the order of the elements in our MAP. We did this so each record would consistently have
not only the same information but also that information would be displayed in the same order
every time. This makes creating the records easier for us and it would be clearer and more easily
understandable for users if the records order stayed consistent through out all records. That being
said, the group decided to keep the order of the elements in VRA Core the same as in the
template as best practices, but all elements are ordered the same for all VRA Core records.

5
Images:

The Winter Garden at Harold Washington Library

The 9th Floor
Taken by Katie Cheever

6
Front of the Newberry Library
Taken by Selim Layouni on 11-20-2016

7
Front Copper Facade of the Oak Park Public Library, in the Snow
Taken by Amy Pinc on 12-04-2016