1

Group 3: Nicole Conti, Ly Nguyen, Jazmyn Taylor, Jeffrey Thivel

Name of Imaginary Institution: Catalogic Cultural Center
Name of Imaginary Digital Collection: Famous Fountains of Chicagoland Digital Collection

Background
Catalogic Cultural Center is a community-based institution that welcomes all people of
Chicagoland. The cultural center offers services to tourists and residents alike to educate, entertain, and
celebrate Chicago’s rich heritage. As a part of the cultural center, we offer our digital archives for
research and enjoyment. We are currently featuring the Famous Fountains of Chicagoland Digital
Collection, which consists of photographs of public fountains installed across the city for beautification,
historic commemorations, and tourist attractions. Included are fountains both retired and still in use,
spanning more than 100 years of Chicago’s 178-year history. Chicago is a city of water. Fountains are a
wonderful way to showcase and celebrate Chicago’s connection with water while offering an attractive
and peaceful place to relax and enjoy the day. From large landmark fountains like Buckingham Fountain
to dainty little fountains tucked away in the corner of a park, people are attracted to and enjoy Chicago’s
many fountains. The Catalogic Cultural Center wishes to preserve these historic landmarks around
Chicago by sharing this collection with the public so that sightseers can learn about Chicago’s wonderful
architectural history.

For our schema, we implemented simple Dublin Core, qualified Dublin Core, and MODS. The
group chose MODS over VRA Core because everyone in the group felt more comfortable working with
MODS as our third scheme.

Group Work
To discuss our group dynamic, we didn’t divide the group work by delegating responsibilities,
rather each member volunteered to do each portion of the project. Our main method of communication
ended up being Google Docs and we were able to makes comments and suggestions to guide our
decisions for the rest of the project. We settled on the theme of fountains around Chicago because Jeff
happened to be reading a book Chicago’s Fabulous Fountains by Greg Borzo and he suggested that we
use fountains for our theme. He also suggested the collection name, “Famous Fountains of Chicago,”
which we later agreed to change to Famous Fountains of Chicagoland Digital Collection to be more
precise. Ly suggested that the institution be called “Catalogic,” and Nicole mentioned that the institution
might be a cultural center, so the Catalogic Cultural Center came to be our institution. Jazmyn came up
with a working description and background for the collection.

As we moved into section 3 of the project, creating the MAP, Jeff did a lot of the foundation work
by creating a table in the Google Doc with the local element names and started the crosswalk across the
three schema. We decided that exporting the MAP to Excel would be easier to read and would provide
more room for the table. Jazmyn volunteered to export the guidelines table to Excel and Ly later
translated a crosswalk table to Excel as well. Closer to the end of the project, both Excel tables were put
into a single Excel spreadsheet as separate tables so the MAP document was easier to submit. The
process of creating our XML documents for each schema was lengthy, but we were able to set timelines
to review each other’s documents. The review process was iterative, so changes were made if another
group member caught something in someone’s record or if a change to the MAP was decided. This
review process was very helpful in pooling all of our strengths because many modifications to the MAP
happened as a result of peer-reviewing each other’s’ records. Each member of the group made
necessary changes to the MAP during these discussions. Once it came time to write our group report,
each member contributed their thoughts on the questions posed in the assignment sheet and this was
later edited into the final group report to ensure that the paper would be coherent and transition well as a
whole.
 2

Metadata Application Profile

For the creation of our metadata application profile (MAP), we started by using Table 2.3
“Customized Local versus Standard Dublin Core Elements” from the Metadata for Digital Collections
textbook as our template (Miller, 2011, p. 41). We also used “Famous Trees of the United States -
Metadata Application Profile (MAP)” from Exercise 2 (Snow, n.d.). Materials from Exercises 1 and 3 from
the coursework, and Table 2.10, “The Dublin Core Metadata Element Set” and Table 2.14 “Dublin Core
Qualifiers” from the Miller textbook helped with mapping the simple and qualified Dublin Core portions of
our MAP (2011, p. 50, 54). For MODS, Table 7.2 “Side-by-Side Comparison of Qualified Dublin Core and
MODS Records” and Table 7.3 “Simple and Dublin Core Mapping to MODS Version 3” were also helpful
in creating our crosswalk (Miller, 2011, p. 205, 210). For outside sources, we consulted the Dublin Core
Qualifiers Refinements & Vocabulary/Encoding Schemes Table (“DCMI Type Vocabulary DCMI Metadata
Terms”) to help us with the crosswalk from simple DC to qualified DC in the second table of our MAP. We
also referred to the Dublin Core Metadata Initiative (DCMI, 2018) and the Metadata Object Description
Schema (MODS, 2016) websites, for help with mapping local elements to DC and MODS. We felt that
having two separate MAP tables, one for the guidelines and one for the crosswalk for the three schemas
was easier to read, which is why we chose to create two different tables instead of packing all of this
information into one large Excel table.

Challenges
To begin with, we had to determine what our local elements were going to be. As we began filling
in values, we realized that some additions and changes would be needed to be make sure our metadata
would be specific to our theme of fountains. Deciding the order in which to put our elements was a
challenge because we wanted to group elements logically, based on the fountain and the digital photo,
and this would also reflect the order in which the metadata appeared in the schemas. We found it helpful
to make what we called “Image Files,” which are tables that had the local element name in one column
and the element value in the other. This allowed us to really focus on these two fields of data and be
precise when entering metadata in our records.

One of our main challenges was determining how to match elements in MODS to metadata that
described our fountains of choice, rather than the digital photograph of the fountain. At first, we were
using elements such as <physicalDescription> or <dateCreated> to record metadata that was relevant to
the fountain, but later realized we had to change our crosswalk elements for MODS to show that this
metadata was for a related resource, rather than the image itself with the use of a <relatedItem>
container for fountain-specific metadata. While we had a lot of ongoing discussion about the crosswalk
table of our MAP, specifically elements relating to MODS, after we had already decided on our local
elements, the table for the guidelines did not change much. Modelling our XML documents after previous
class assignments proved to be difficult because we were often asked to create documents based on an
analog item and a digitized item, while in this project, we were asked to only catalog a digital photograph.
Because we used records that had metadata for two resources as a template, we had to remind
ourselves that our metadata was mainly describing the digital image so that we could construct accurate
records. Remembering this important aspect also helped us maintain the one-to-one principle, so we
were not mixing metadata about multiple resources in one record.

Overall, we found MODS to be more demanding and detailed compared to DC while offering
more descriptive options and designations. We discussed and ultimately did change elements and values
for our local names and the various schema. Resolving issues like which MODS elements, sub-elements,
and attributes to use to describe these data values were discussed for days. Challenges and discussions
involving issues such as obligation requirements, removal of elements, naming of digital files, addition of
sub-elements, expanded use of repeatable elements, using Image vs. StillImage for the type of resource,
the <note> or <description> or <subject> dilemma to describe local element “Type of Fountain”,
<physicalDescription>, <physicalLocation>, and last, but not leaset, <relatedItem> were all challenging
 3

issues in developing our MAP, crosswalk, and records. These topics were discussed many times until we
all felt comfortable with the results. An odd challenge arose when Jeff was uploading his MODS XML doc
to Canvas. For some reason the complete record was not uploading, so Jeff copied his XML docs to
Word and they uploaded without any issues. Curiously, and much to Jeff’s relief, Ly was able to download
Jeff’s MODS XML file and it appeared normal in Oxygen.

Metadata Schema Mapping

Once we settled on our local elements, mapping to simple and Qualified Dublin Core was easily
accomplished. Some small changes were made, for example changes in the order in which elements
were listed or small changes in names of local elements to more accurately reflect the data they
represented. We didn’t lose any information from simple DC to qualified DC, though to achieve this we did
have to find creative, yet still accurate ways to modify our local elements. When moving to MODS we
actually gained more information. MODS is more detailed and allows for greater expansion in the level of
the metadata through sub-elements and attributes. For example, we had to decide how we wanted to
record the digital repository for our images in MODS where we didn’t have to in Dublin Core. Ultimately,
we decided to record it in the <relatedItem> element. We also had some discussion of how to properly
document the dimensions and building materials of our physical fountains. Though our records focused
on our born-digital images, we still wanted to include information about the physical fountain without
sacrificing the focus of our records or creating outright incorrect records for the project. This required us to
make changes to the application profile, but ultimately,
we came to a solution on how to reflect this information in the record by recording
<physicalDescription> information within <relatedItem>.

While simple and qualified DC were easier to work with, MODS did allow us to record a lot more
information about the fountain and our digital photograph. For example, in MODS, we were able to add a
description about the fountain creators and sponsors to give more background information on the
fountain. While we used the tag <relatedItem> to separate metadata having to do only with the fountain
from the metadata about the digital image in MODS, there was not a distinct way to separate the different
metadata in simple DC or qualified DC. In our case, there are multiple <dc:date> and <dc:creator>
elements in the records for simple DC and qualified DC which gave values for the creation date and
creators of the fountain, as well as the date created and creators of the digital photograph.

MAP Changes
We found that for crosswalking to MODS, we needed to add more detailed information to our
MAP. We added descriptions for the Designer/ Builder and Funding/ Sponsor local elements to provide
more background information. We discussed whether to remove the vocabulary/encoding scheme column
from our crosswalk table since we already included it in our MAP guidelines table. We decided to keep it
in because it made it easier when translating from schema to schema to know the recommended
encoding for each element. In order to reduce confusion over local element names, we decided to change
Description/Note element to just Description because we already had a Notes element. For the “Type of
Fountain” local element, we initially had it as <description> under MODS because we were thinking of
using AAT and TGM vocabulary. However, disappointingly, the only term applicable to our local element
was “Fountains” in those particular thesauri. We were thinking more in terms of a “category” of fountain
and hoping for something a little more descriptive like “Iconic fountain” or “Landmark fountain”. At one
point even <genre> was proposed. We discussed adding both <description> and <subject> elements for
the “Type of Fountain” local element because it is possible to have more than one element that can apply
in a crosswalk from local element to MODS. After discussion, we felt that <subject> was a better choice
for this element because, after all, fountains was our subject of photography. The benefit for using the
<subject> element under MODS, controlled vocabularies from AAT, TGM, and LCSH is still allowed,
unlike using <description>.

For the Fountain Dimensions/Measurement and Fountain Construction/Materials of the fountains,

we discussed and went back and forth on whether to use <physicalDescription>, <note> or <description>
 4

as MODS elements. We were trying to decide if this data was describing the subject of our photos, the
physical fountain, or the digital image itself. We asked ourselves, if this data is not about the digital image
itself, should it be contained under a <relatedItem> wrapper? We decided on using <relatedItem>
<physicalDescription> for these elements relating to the fountain dimensions and construction materials.
We also added a “Digital File Size” local element to support administrative metadata, in the case that the
digital files needed to be preserved or modified in any way. Information about the original image file would
be useful in this respect.

As we worked through our records entering our data into the schemas and checking each other’s’
XML documents, we finalized our MAP and crosswalk tables. Since we each had a different fountain,
data for each of our records was slightly different. Some of us had information about our fountain that
others did not. Because of this, our files were not always the same despite the fact that we all followed
the same MAP. This shows how each cataloger is unique and may have different preferences based on
the data they have access to.

Metadata Quality
Our group ensured that we didn’t lose data from schema to schema, particularly from DC to
MODS. Although mapping from DC to MODS is an example of mapping from a simpler schema to a
“richer” one, which is relatively easier than the opposite, we still had to make changes as we worked.
While creating our records, we referred regularly to the crosswalk table, citing differences that we found in
each other’s records (we went through many drafts of each record) and then discussed how we should
amend the crosswalk to better capture information that didn’t transfer between schema, such as
alternative names for fountains, or information on the builders and sponsors, etc. For us, finding a “home”
for information about our digital image required us to look closer at the meanings and proper uses of
MODS Top Elements: <relatedItem> and <physicalDescription> in MODS.

One of the ways we ensured shareability with our records was recording as much information as
we thought was necessary without providing too much minutiae. For our geographical subject elements,
we opted to include metadata for continent and country, even though our specific collection only depicted
fountains in Chicago, Illinois. If our metadata was harvested and institutions in other countries or cities
were to use our metadata, it would be easier to understand what location the photographs took place in.
With regards to indexing certain data value fields, we tried to figure out what information our end users,
primarily tourists and residents of Chicagoland, would want to locate most. Miller suggests suppressing
technical and administrative metadata from user view to eliminate unhelpful information (2011, p. 247). In
our case, some elements we decided against indexing included fountain dimensions, digital file size, and
digital ID, which most users would not need to know. In a large way, creating the MAP was a great way to
document our local practices because it allows other institutions to see our guidelines and preferable
mappings to other widely-used schema, like Dublin Core and MODS (Miller, 2011, p. 47).

Conclusion
In conclusion, this project gave us the chance to understand how much work goes into
collaborating with a team that is actively cataloging a digital collection and the need to ensure consistency
and quality for each record. It helped all of us build remote communication skills, as all of the work was
done online. Although this may be a different experience from other group projects we’ve had in other
classes, we found that being able to share and edit documents in real time helped immensely with the
project coming together smoothly. We all had different schedules and other finals to contend with, but
working remotely with other group members did not take away from the project. We were able to
capitalize on each of our individual strengths and communication skills to produce a group effort that each
of us was proud of.
 5

References

DCMI (2018.) Dublin Core Metadata Initiative. Retrieved from http://dublincore.org/.

DCMI. (2012). DCMI Metadata Terms. Retrieved from http://dublincore.org/documents/2012/06/14/dcmi-

terms/.

DCMI. (2012). DCMI Type Vocabulary DCMI Metadata Terms. Retrieved from
http://dublincore.org/documents/dcmi-type-vocabulary/#H7.

Miller, S.J. (2011). Metadata for Digital Collections: A How-To-Do-It Manual. New York: Neal-Schuman.

Snow, K. (n.d.) Famous Trees of the United States - Metadata Application Profile (MAP). Retrieved from
https://dominicanu.instructure.com/courses/853560/files.

Metadata Object Description Schema (MODS). (2016). MODS Elements and Attributes.
Retrieved from http://www.loc.gov/standards/mods/userguide/generalapp.html.
 6

Ly’s fountain:

The title of the fountain is “Fountain in The Crystal Gardens at Navy Pier.” It was designed by the firm
WET Design and is owned by Phil Stefani Signature Restaurants.

Nicole’s Fountain:

Buckingham Fountain (also known as the Clarence Buckingham Memorial Fountain) was created in 1927
and is located in Grant Park. Designed by Edward Bennett, Marcel Loyau and Jacques Lambert, the
fountain was donated by Kate Buckingham in honor of her brother, Clarence Buckingham.
 7

Jeff’s Fountain:

The Fountain of the Great Lakes is a neoclassical sculpture designed by Lorado Taft and built in 1913. It
is an allegorical representation of the Great Lakes and is located in the South Garden at the Art Institute
in Chicago.
 8

Jazmyn’s Fountain:

The Drexel Fountain was created in 1881 as a

memorial for Francis M. Drexel, a banker who
donated land he owned to the city to create
what is now Drexel Boulevard. The fountain
was commissioned by his two sons, and built
by Henry Manger.