10592 20190318 galley The Map as a Search Box: Using Linked Data to Create a Geographic Discovery System Gabriel Mckee INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2019 40 Gabriel McKee (gm95@nyu.edu) is Librarian for Collections and Services at the Institute for the Study of the Ancient World at New York University. ABSTRACT This article describes a bibliographic mapping project recently undertaken at the Library of the Institute for the Study of the Ancient World (ISAW). The MARC Advisory Committee recently approved an update to MARC that enables the use of dereferenceable Uniform Resource Identifiers (URIs) in MARC subfield $0. The ISAW Library has taken advantage of MARC’s new openness to URIs, using identifiers from the linked data gazetteer Pleiades in MARC records and using this metadata to create maps representing our library’s holdings. By populating our MARC records with URIs from Pleiades, an online, linked open data (LOD) gazetteer of the ancient world, we are able to create maps of the geographic metadata in our library’s catalog. This article describes the background, procedures, and potential future directions for this collection-mapping project. INTRODUCTION Since the concept of the Semantic Web was first articulated in 2001, libraries have faced the challenge of converting their vast stores of metadata into linked data.1 Though BIBFRAME, the planned replacement for the MARC (MAchine-Readable Cataloging) systems that most American libraries have been using since the 1970s, is based on linked-data principles, it is unlikely to be implemented widely for several years. As a result, many libraries have delayed creating linked data within the existing MARC framework. One reason for this delay has been the absence of a clear consensus in the cataloging community about the best method to incorporate Uniform Resource Identifiers (URIs), the key building block of linked data, into MARC records.2 But recent developments have added clarity to how URIs can be used in MARC, clearing a path for projects that draw on URIs in library metadata. This paper describes one such project undertaken by the Library of the Institute for the Study of the Ancient World (ISAW) that draws on URIs from the linked-data gazetteer Pleiades to create maps of items in the library’s collection. A BRIEF HISTORY OF URIS IN MARC Over the last decade, the path to using URIs in MARC records has become more clear. This process began in 2007, when the Deutsche Nationalbibliothek submitted a proposal to expand the use of a particular MARC subfield, $0 (also called “dollar-zero” or “subfield zero”), to contain control numbers for related authority records in Main Entry, Subject Access, and Added Entry fields.3 The proposal, which was approved on July 13, 2007, called for these control numbers to be recorded with a particular syntax: “the MARC organization code (in parentheses) followed immediately by the number, e.g., (CaBVaU)2835210335.”4 This MARC-specific syntax is usable within the MARC environment, but is not actionable for linked-data purposes. A dereferenceable URI—that is, an identifier beginning with “http://” that links directly to an online resource or a descriptive INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2019 41 representation of a person, object, or concept—could be parsed and reconstructed, but only with a significant amount of human intervention and a high likelihood of error.5 In 2010, following a proposal from the British Library, $0 was redefined to allow types of identifiers other than authority record numbers, in particular International Standard Name Identifiers (ISNI), using this same parenthetical-prefix syntax.6 That same year, the RDA/MARC Working Group issued a discussion paper proposing the use of URIs in $0, but no proposal regarding the matter was approved at that time.7 The 2010 redefinition made it possible to place URIs in $0, provided they were preceded by the parenthetical prefix “(uri)”. However, this requirement of an added character string put MARC practice at odds with the typical practices of the Linked Data community. Not only does the addition of a prefix create the need for additional parsing before the URI can be used, the prefix is also redundant, since dereferenceable URIs are self-identifying. In 2015, the Program for Cooperative Cataloging (PCC) charged a task group with examining the challenges and opportunities for the use of URIs within a MARC environment.8 One of this group’s first accomplishments was submitting a proposal to the MARC Advisory Committee to discontinue the requirement of the “(uri)” prefix on URIs.9 Though this change appears minor, it represents a significant step forward in the gradual process of converting MARC metadata to linked data. Linked data applications require dereferenceable URIs. The requirement of either converting an HTTP URI to a number string (as $0 required from 2007-10), or prefixing it with a parenthetical prefix, produced identifiers that did not meet the definition of dereferenceability. As Shieh and Reese explain, the MARC syntax in place prior to this redefinition was at odds with the practices used by Semantic Web services: The use of qualifiers, rather than actionable URIs, requires those interested in utilizing library metadata to become domain experts and become familiar with the wide range of standards and vocabularies utilized within the library metadata space. The qualifiers force human interaction, whereas dereferenceable URIs are more intuitive for machines to process, to query services, to self-describe—a truly automated processing and a wholesome integration of Web services.10 Though it has been possible to use prefixed URIs in MARC for several years, few libraries have done so, in part because of this requirement for human intervention, and in part because of the scarcity of use-cases that justified their use. The removal of the prefix requirement brings MARC’s use of URIs more into line with that of other semantic web services, and will reduce system fragility and enhance forward-compatibility with developing products, projects, and services. Though MARC library catalogs still struggle with external interoperability, the capability of inserting unaltered, dereferenceable URIs into MARC records is potentially transformative.11 Following the approval of the PCC Task Group on URI in MARC’s 2016 proposal makes it easier to work with limited linked data applications directly within MARC, rather than waiting for the implementation of BIBFRAME. By inserting actionable URIs directly into MARC records, libraries can begin developing programs, tools, and projects that draw on these URIs for any number of data outcomes. In the last two years, the ISAW Library has taken advantage of MARC’s new openness to URIs to create one such outcome: a bibliographic mapping project that creates browseable maps of items held by the library. The ISAW Library holds approximately 50,000 volumes in its print collection, MAP AS A SEARCH BOX | MCKEE 42 https://doi.org/10.6017/ital.v38i1.10592 chiefly focusing on archaeology, history, and philology of Asia, Europe, and North Africa from the beginning of agriculture through the dawn of the Medieval period, with a focus on cultural interconnections and interdisciplinary approaches to antiquity. The Institute, founded in 2007, is affiliated with New York University (NYU) and its library holdings are cataloged within Bobcat, the NYU OPAC. By populating our MARC records with URIs from Pleiades, an online, linked open data (LOD) gazetteer of the ancient world, the ISAW Library is able to create maps of the geographic metadata in our library’s catalog. At the moment, this process is indirect and requires periodic human intervention, but we are working on ways of introducing greater automation as well as expanding beyond small sets of data to a larger map encompassing as much of our library’s holdings as it makes sense to represent geographically. MAP-BASED SEARCHING FOR ANCIENT SUBJECTS In the disciplines of history and archaeology, geography is of vital importance. Much of what we know about the past can be tied to particular locations: archaeological sites, ancient structures, and find-spots for caches of papyri and cuneiform tablets provide the spatial context for the cultures about which they inform us. But while geospatial data about antiquity can be extremely precise, the text-based searching that is the user’s primary means of accessing library materials enabled is much less clear. Standards for geographic metadata focus on place names, which open the door for greater ambiguity, as Buckland et al. explain: There is a basic distinction between place, a cultural concept, and space, a physical concept. Cultural discourse tends to be about places rather than spaces and, being cultural and linguistic, place names tend to be multiple, ambiguous, and unstable. Indeed, the places themselves are unstable. Cities expand, absorbing neighboring places, and countries change both names and boundaries.12 Nowhere is this instability of places and their names so clear as in the fields of ancient history and archaeology, which often require awareness of cultural changes in a single location throughout the longue durée. And yet researchers in these fields have had to rely on library search interfaces that rely entirely on toponyms for accessing research materials. Scholars in these disciplines, and many others besides, would be well served by a method of discovering research materials that relies not on keywords or controlled vocabularies, but on geographic location. Library of Congress classification and subject cataloging tend to provide greater granularity for political developments in the modern era, presenting a challenge to students of ancient history. A scholar of the ancient Caucasus, for example, is likely to be interested in materials that are currently classified under the History classes for the historical region of Greater Armenia (DS161- 199), the modern countries of Armenia (DK680), Azerbaijan (DK69X), Georgia (DK67X), Russia (DK5XX), Ukraine (DK508), and Turkey (DS51, DS155-156 and DR401-741); for pre- and proto- historic periods, materials may be classified in GN700-890; and texts in ancient languages of the Caucasus will fall into the PK8000-9000 range. Moreover, an effective catalog search may require familiarity with the romanization schemes for Georgian, Armenian, Russian, and Ukrainian. Materials on the ancient Caucasus fall into a dozen or more call number ranges, and there is no single term within the Library of Congress Subject Headings (LCSH) that connects them—but if their subjects were represented on a map, they would fall within a polygon only a few hundred miles long on each side. This geophysical collocation of materials from across many classes of knowledge can enable unexpected discoveries. As Bidney and Clair point out, “Organizing INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2019 43 information based on location is a powerful idea—it has the capacity to bring together information from diverse communities of practice that a research may never have considered . . . ‘Place’ is interdisciplinary.”13 With this in mind, the ISAW Library has set out to create an alternative method of accessing items in its collection: a browseable, map-based interface for the discovery of library materials. LITERATURE REVIEW Though geographic searching is undoubtedly useful for many different types of content, much of the work in using coordinate data and map-based representations of resources has centered on searching for printed maps and, more recently, geospatial datasets. In an article published in 2007, Buckland et al. issued a challenge to libraries to complement existing text-string toponymic terminology with coordinate data.14 Perhaps unsurprisingly, the most progress in meeting this challenge has been made in the area of cartographic collections. In a 2010 article, Bidney discussed the Library of Congress’s then-new requirement of coordinates in records describing maps, and explores the possibility of using this metadata to create a geographic search interface.15 A 2014 follow-up article by Bidney and Clair expanded this argument to include not just cartographic materials, but all library resources, challenging libraries to develop new interfaces to make use of geospatial data.16 The most advanced geospatial search interfaces have been developed for cartographic and geospatial data. For example, GeoBlacklight (http://geoblacklight.org) offers an excellent map-based interface, but it is intended primarily for cartographic and GIS data specifically, and not library resources more broadly. The mapFAST project described by Bennett et al. in 2011 pursues goals similar to our Pleiades- based discovery system.17 Using FAST (Faceted Application of Subject Terminology) headings, which are already present in many MARC records, this project creates a searchable map via the Google Maps API. Each FAST geographic heading creates a point on the map which, when clicked, brings the user to a precomposed search in the library catalog for the corresponding controlled subject heading. One limitation to the mapFAST model is the absence of geographic coordinates on many of the LC authority records from which FAST headings are derived: at the time that Bennett et al. described the project, coordinates were available for only 62.5 percent of FAST geographic headings; additional coordinates came from the Geonames database (http://www.geonames.org/).18 Moreover, the method of retrieving these coordinates is based on text string matching, which introduces the possibility of errors resulting from the lack of coordination between toponyms in FAST and Geonames. In exploring other mapping projects, we looked most closely at projects with a focus on the ancient world, including Pelagios (http://commons.pelagios.org), its geographic search tool Peripleo,19 and China Historical GIS (CHGIS, http://sites.fas.harvard.edu/~chgis). As described by Simon et al. in 2016, Pelagios offers a shared framework for researchers in classical history to explore geographic connections, and several applications of its data resemble our desired outcome.20 Similarly, Merrick Lex Berman’s work with the API provided by China Historical GIS in connection with library metadata provided important guidelines and points of comparison.21 We also explored mapping projects outside of the context of antiquity, including MapHappy, the Biodiversity Heritage Library’s map of LCSH headings, and the map interface developed for PhillyHistory.org.22 MAP AS A SEARCH BOX | MCKEE 44 https://doi.org/10.6017/ital.v38i1.10592 FIRST STEPS: METADATA To develop a system for mapping the ISAW Library’s collection, we began by working with smaller sets of metadata. Our initial collection map, which served as a proof of concept, represented the titles available in the Ancient World Digital Library (AWDL, http://dlib.nyu.edu/ancientworld), an online e-book reader created by the ISAW Library in collaboration with NYU’s Digital Library Technical Services department. When we initially created this interface, called the AWDL Atlas, AWDL contained a small, manageable set of about one hundred titles. Working in a spreadsheet, we assigned geographic coordinates to each of these titles and mapped them using Google Fusion Tables (https://fusiontables.google.com). Fusion Tables, launched by Google in June 2009, is a cloud-based platform for data management that includes a number of visualization tools, including a mapping feature that builds on the infrastructure of Google Maps.23 The Fusion Tables map created for AWDL shows a pinpoint for each title in the e-book library; when clicked, each pinpoint gives basic bibliographic data about the title and a link to the e-book itself. One problem with this initial map was that it did little to show precision—a pinpoint representing a specific archaeological site in Iraq looks the same on the map as a pinpoint representing the entirety of Central Asia. Nevertheless, the basic functionality of the AWDL Atlas performed as desired, providing a geographic search interface for a concrete set of resources. For our next collection map, we turned our attention to our monthly lists of new titles in our library’s collection. At the end of each month, NYU’s Library Systems team sends our library a MARC-XML report listing all of the items added to our library’s collection that month. For several years now, we have been publishing this data on our library’s website in human-readable HTML form and adding the titles to a library in the open-source citation management platform Zotero, allowing our users multiple pathways to discovering resources within our collection.24 Beginning in August 2016, we began creating monthly maps of these titles, using a variation of the workflow that we devised for the AWDL Atlas. To better represent the different levels of precision that each point represents, we implemented a color-coded range of four levels of precision, from site- specific archaeological publications to materials covering a broad, multi-country range, with a fifth category for cross-cultural materials and other works that can’t be well represented in geographic form. (These items are grouped in the Mediterranean Sea on the monthly new titles maps, but in a full-collection map would most likely be either excluded or represented by multiple points, as appropriate.) The initial New Titles maps took a significant amount of title-by-title work to create. Coordinates and assessments of precision needed to be assigned for each title individually. We quickly began looking for ways to automate the process of geolocation, and soon settled on using data from Pleiades to increase the efficiency of creating each map.25 We set our sights on MARC field 651 (Subject Added Entry-Geographic Name) as the best place in a MARC record to put Pleiades data. As a subject access field, the 651 is structured to contain a searchable text string and can also include a $0 with a URI associated with that text string. However, under current cataloging guidelines, catalogers are not free to use any URI they choose in this field: the Library of Congress maintains a list of authorized sources for subject terms to be used in 651 and other subject-access fields.26 In August 2016, the ISAW Library submitted a proposal to the Library of Congress for Pleiades to be approved as a source of authoritative subject data and added to LC’s list of Subject Heading and Term Source Codes. The proposal was approved the following month, and by early 2017 the LC-assigned code was approved for use in INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2019 45 OCLC records. With this approval in place, we began incorporating Pleiades URIs in MARC records for items held by the ISAW Library. We used the names of Pleiades resources as subject terms in new 651 (Subject Added Entry-Geographic Name) fields, specifying Pleiades as the source of the subject term in subfield $2 and adding the Pleiades URI in a $0: Figure 1. Fields from a MARC record showing an LCNAF geographic heading and the corresponding Pleiades heading, with URI in $0. Figure 1 shows a detail from OCLC record #986242751, which describes a book containing texts from cuneiform tablets discovered at the Hittite capital city Hattusa. This detail shows both the LCNAF and Pleiades geographic headings assigned to this record. (In addition to providing a URI for the site, the Pleiades heading also enhances keyword searches: the 651 field is searchable in the NYU library catalog, thus providing keyword access to one of the city’s ancient names). The second 651 field contains a second indicator 7, indicating that the source of the subject term is specified in $2, where the LC-approved code “pleiades” is specified. This is followed by a $0 containing the URI for the Pleiades place resource describing Hattusa. Our monthly reports of new titles now contain a field for Pleiades URIs. Currently, we are not querying Pleiades directly for coordinates, but rather are using the URI as a vertical-lookup term within a spreadsheet of each month’s new titles, which is checked against a separate data file that matches Pleiades URIs to coordinate pairs.27 For places where no Pleiades heading is available, we have begun using URIs from the Getty Thesaurus of Geographic Names (TGN), MARC-syntax FAST identifiers, and unique LCNAF text strings, using the same vertical-lookup process to retrieve previously researched coordinate pairs for those places. Next, we retrieve coordinates for newly appearing Pleiades locations, research the locations of new non-Pleiades places, and add both to the local database of places used. Lastly, due to Google Fusion Table’s inability to display more than one item on a single coordinate pair, prior to uploading the map data to Fusion Tables we examine it for duplicated coordinate pairs, manually altering them to scatter these points to nearby locations. The overall amount of time spent on cleaning data and preparing each month’s map has decreased from more than a full day’s work in August 2016 to about two hours in January 2018. MAP AS A SEARCH BOX | MCKEE 46 https://doi.org/10.6017/ital.v38i1.10592 Figure 2. A screenshot from the ISAW Library New Titles map for January 2018, showing an item- specific information window (http://isaw.nyu.edu/library/Find/NewTitles-2017-18/2018-jan). CHALLENGES In developing the ISAW Library’s mapping program, we had to overcome several challenges: Early in the project, we needed to address the philosophical differences between how Pleiades and LCNAF think about places and toponyms. The concept of “place” in Pleiades is broad, and contains cities, structures, archaeological sites, kingdoms, provinces, and other types of administrative divisions, roads, geological features, culturally defined regions, and ethnic groups: “the term [‘place’] applies to any locus of human attention, material or intellectual, in a real-world geographic context.”28 In functional terms, a “place” in Pleiades is a top-level resource containing one or more other types of data: • One or more locations, consisting of either a precise point, an approximate rectangular polygon, or a precise polygon formed by multiple points; • One or more names, in one or more ancient or modern languages; • One or more connections to other Place resources, generally denoting a geospatial or political/administrative connection. Locations, names, and connections contain further metadata, including chronological attestations and citations to data sources. No one of these components is a requirement—even locations are optional, as ancient texts contain references to cities and structures whose geospatial location is unknown. INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2019 47 By contrast, Library of Congress rules focus almost exclusively on names—that is, text strings. There are two main categories of geographic names, as described in instruction sheet H690 of the Subject Headings Manual (SHM): Headings for geographic names fall into two categories: (1) names of political jurisdictions, and (2) non-jurisdictional geographic names. Headings in the first category are established according to descriptive cataloging conventions with authority records that reside in the name authority file . . . Headings in the second category are established . . . with authority records that reside in the subject authority file.29 The two categories—essentially definable as political entities and geographic regions—are both of interest to the SHM only as represented by text strings. The purpose of identifying places within the framework of LC’s guidelines is to enable text-based searching and collocation of items based on uniform, human-readable terminology. At the beginning of this project, it was important to acknowledge, explore, and understand this fundamental difference, and to understand the different purposes of an authority file (identifying unique text strings), a linked data gazetteer (assembling and linking many different kinds of geospatial and toponymic data), and our mapping project (identifying coordinate pairs related to specific library resources). In our project, this philosophical gap manifested as a difference between the primary and secondary importance of authorized text strings and URIs: in LCSH and LCNAF, the text string is primary, and the URI secondary (where it is used at all); in Pleiades and many other linked-data sources, URIs are primary and text strings secondary. LCSH and LCNAF text strings are unique, and can be considered as a sort of identifier, but they do not have the machine-readable functionality of a URI. In Pleiades, the machine-readable URI is primary, and can be used to return coordinates, place names, and other human- or machine-readable data. The name of a Pleiades place resource can be construed as a “subject heading,” but these text strings are not necessarily unique, and additional data from the Pleiades resource may be required for disambiguation by a human reader.30 Toponymic terminology—that is, human-readable text strings—are just one type of data that Pleiades contains, alongside geospatial data, temporal tags, and linkages between resources. One example of a recent change in Pleiades data illustrates the fundamental difference in approach between authority control and URI management. Until recently, Pleiades contained two different place resources with the heading “Aegyptus” (https://pleiades.stoa.org/places/766 and https://pleiades.stoa.org/places/981503), both referring to the general region of Egypt. Both of these resources were recently updated, and the title text of both was changed: /places/766 was retitled “Aegyptus (Roman imperial province)” and /places/981503 became “Ancient Egypt (region).” The distinction illustrates the difficulty in assigning names to places over long spans of time: Egypt, as understood by pre-Ptolemaic inhabitants of the Nile region, had a different meaning than the administrative region established after Octavian’s defeat of Marc Antony and Cleopatra—or, for that matter, from the Predynastic kingdoms of Upper and Lower Egypt, the Ottoman Eyalet of Misr, and the modern Republic of Egypt. Prior to this change in Pleiades, both URIs were applied to MARC records for items held by the ISAW Library, under the heading “Aegyptus.” From a linked-data standpoint, there is no real problem here: the URIs still link to resources describing different historical places called “Egypt,” including the coordinate data needed for ISAW’s collection maps. But from the standpoint of authority control, the subject term MAP AS A SEARCH BOX | MCKEE 48 https://doi.org/10.6017/ital.v38i1.10592 “Aegyptus” on these records is now “wrong,” representing a deprecated term, and should be updated. Even here, though, a linked-data model has benefits that a text-string-based model lacks. Even if they contain the same text string heading, the URI means there is no ambiguity between the two headings, and the text strings can be replaced with a batch operation based on the differences in their URIs. Getting away from text-string-based thinking will represent a major philosophical challenge for libraries as we move toward a linked data model for library metadata, but the many benefits of linked data will make that shift worthwhile. Google Fusion Tables represents a future hurdle that the ISAW Library’s mapping project will need to clear. In December 2018, Google announced that the Fusion Tables project would be discontinued, and that all embedded Fusion Tables visualizations will cease functioning on December 3, 2019.31 Fortunately, the ISAW Library has already begun developing an alternative solution that does not rely on the deprecated Fusion Tables application. The core methodology used in developing our maps will remain the same, however. Lastly, the geographic breadth of our collection reveals the limitations of Pleiades as the sole data source for this project. At its inception, Pleiades was focused on the Greco-Roman antiquity, and though it has expanded over time, Central and East Asia—regions of central interest to the ISAW Library—are largely not covered. Because all contributions to Pleiades undergo peer review prior to being published online, Pleiades’ editors are understandably reluctant to commit to expanding their coverage eastward until the editorial team includes experts in these geographic areas. However, though we began this project with Pleiades, there is no barrier to using other sources of geographic data, such as China Historical GIS, the Getty Thesaurus of Geographic Names (TGN, http://www.getty.edu/research/tools/vocabularies/tgn/index.html), GeoNames (http://www.geonames.org/), the World-Historical Gazetteer (http://whgazetteer.org/), or the Library of Congress’s Linked Data Service (http://id.loc.gov/). The same procedures we’ve used with Pleiades can be applied to any reliable data source with consistently formatted data. FUTURE DIRECTIONS We have already begun to move away from the Google Fusion Tables model, and are working to develop our own JavaScript-based map application using Mapbox (https://www.mapbox.com/) and Leaflet (https://leafletjs.com/). When completed, this updated mapping application will actively query a database of Pleiades headings for coordinates, further automating the process of map creation. We are looking into different methods of encoding and representing precision—for example, using points and polygons to represent sites and regions, respectively. The Leaflet map interface will also enable us to show multiple items for single locations, something Fusion Tables is unable to do, and will thus eliminate the need to manually deduplicate coordinate pairs. To expand the number of records that contain Pleiades URIs, we are developing a crosswalk between existing LC geographic headings and Pleiades Place resources. When completed, we will use this crosswalk to batch-update our older records with Pleiades data where appropriate. The crosswalk will contain URIs from both Pleiades and the LC Linked Data Service, and it will be provided to the Pleiades team so that Pleiades resources can incorporate LC metadata as well. We are also exploring further user applications of map-based search. One function we hope to develop is a geographic notification service, allowing users to define polygonal areas of interest on the map. When a new point is added that falls within these polygons, the user will be notified of a INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2019 49 new item of potential interest. Some user training will be required to ensure that users define their areas of interest in such a way that they will receive results that interest them—for example, a user interested in the Roman Empire will likely be interested in titles about the Mediterranean region in general, and may need to draw their bounding box so that it encompasses the open sea as well as sites on land. It will also require thoughtfulness about where users are likely to look for points of interest, especially for empires and other historic entities that do not correspond to modern geopolitical boundaries (for example, the Byzantine Empire or Scythia). Additionally, we hope to begin working with chronological as well as geospatial data, with hopes of being able to add a time slider to the library map. This would enable users to focus on particular periods of history as well as geographic regions—for example, users interested in Bronze Age Anatolia could limit results to that time period, so that they can browse the map without material from the Byzantine Empire “cluttering” their browsing experience.32 The online temporal gazetteer PeriodO (http://perio.do/) provides a rich data source to draw on, including URIs for individual chronological periods and beginning and end dates for each defined temporal term. Following a proposal submitted by the ISAW Library, PeriodO was approved by the Library of Congress as a source of subject terminology in September 2018, and its headings and URIs are now useable in MARC. However, though LCSH headings for geographic places are often quite good, the guidelines for chronological headings and subdivisions are often inadequate for describing ancient historical periods, and thus enacting a chronological slider, though highly desirable, would require a large amount of manual changes and additions to existing metadata. The ISAW Library’s collection mapping project has accomplished its initial goal of providing a geospatial interface for the discovery of materials in our library collection. As we expand our mapping project to incorporate more of our collection, we also hope that our model can prove useful to other institutions looking for practical applications of URIs in MARC, alternative discovery methods to text-based searching, or both. REFERENCES AND NOTES 1 For a summary of this challenging problem, see Brighid M. Gonzales, “Linking Libraries to the Web: Linked Data and the Future of the Bibliographic Record,” Information Technology & Libraries 33, no. 4 (Dec. 2014): 10–22, https://doi.org/10.6017/ital.v33i4.5631. 2 See, for example, Timothy W. Cole et al., “Library MARC Records into Linked Open Data: Challenges and Opportunities,” Journal of Library Metadata 13, no. 2–3 (July 2013): 178, https://doi.org/10.1080/19386389.2013.826074. 3 Deutsche Nationalbibliothek, “MARC Proposal No. 2007-06: Changes for the German and Austrian Conversion to MARC 21,” MARC Standards, May 25, 2007, https://www.loc.gov/marc/marbi/2007/2007-06.html. 4 Ibid. 5 For a detailed discussion of the importance of actionability in unique identifiers, see Jackie Shieh and Terry Reese, “The Importance of Identifiers in the New Web Environment and Using the Uniform Resource Identifier (URI) in Subfield Zero ($0): A Small Step That Is Actually a Big MAP AS A SEARCH BOX | MCKEE 50 https://doi.org/10.6017/ital.v38i1.10592 Step,” Journal of Library Metadata 15, no. 3–4 (Oct. 2, 2015): 220–23, https://doi.org/10.1080/19386389.2015.1099981. 6 British Library, “MARC Proposal No. 2010-06: Encoding the International Standard Name Identifier (ISNI) in the MARC 21 Bibliographic and Authority Formats,” MARC Standards, May 17, 2010, https://www.loc.gov/marc/marbi/2010/2010-06.html. 7 RDA/MARC Working Group, “MARC Discussion Paper No. 2010-DP02: Encoding URIs for Controlled Values in MARC Records,” MARC Standards, Dec. 14, 2009, https://www.loc.gov/marc/marbi/2010/2010-dp02.html. 8 For a summary of this task group’s work to date, see Jackie Shieh, “Reports from the Program for Cooperative Cataloging Task Groups on URIs in MARC & BIBFRAME,” JLIS.It: Italian Journal of Library, Archives and Information Science = Rivista Italiana Di Biblioteconomia, Archivistica e Scienza Dell’informazione 9, no. 1 (2018): 110–19, https://doi.org/10.4403/jlis.it-12429. 9 PCC Task Group on URI in MARC and The British Library, “MARC Discussion Paper No. 2016- DP18: Redefining Subfield $0 to Remove the Use of Parenthetical Prefix ‘(Uri)’ in the MARC 21 Authority, Bibliographic, and Holdings Formats,” MARC Standards, May 27, 2016, https://www.loc.gov/marc/mac/2016/2016-dp18.html; MARC Advisory Committee, “MAC Meeting Minutes” (ALA Annual Meeting, Orlando, FL, 2016), https://www.loc.gov/marc/mac/minutes/an-16.html. For a cumulative description of the scope of this task group’s work, see PCC Task Group on URIs in MARC, “PCC Task Group on URIs in MARC: Year 2 Report to PoCo, October 2017” (Program for Cooperative Cataloging, Oct. 23, 2017), https://www.loc.gov/aba/pcc/documents/PoCo- 2017/PCC_URI_TG_20171015_Report.pdf. 10 Shieh and Reese, “The Importance of Identifiers in the New Web Environment and Using the Uniform Resource Identifier (URI) in Subfield Zero ($0),” 221. 11 Shieh and Reese, “The Importance of Identifiers in the New Web Environment and Using the Uniform Resource Identifier (URI) in Subfield Zero ($0)”; For a discussion of a related problem (finding a place for a URI in MARC authority records), see Ioannis Papadakis, Konstantinos Kyprianos, and Michalis Stefanidakis, “Linked Data URIs and Libraries: The Story so Far,” D-Lib Magazine 21, no. 5/6 (June 2015), https://doi.org/10.1045/may2015-papadakis. 12 Michael Buckland et al., “Geographic Search: Catalogs, Gazetteers, and Maps,” College & Research Libraries 68, no. 5 (Sept. 2007): 376, https://doi.org/10.5860/crl.68.5.376. 13 Marcy Bidney and Kevin Clair, “Harnessing the Geospatial Semantic Web: Toward Place-Based Information Organization and Access,” Cataloging & Classification Quarterly 52, no. 1 (2014): 70, https://doi.org/10.1080/01639374.2013.852038. 14 Buckland et al., “Geographic Search.” 15 Marcy Bidney, “Can Geographic Coordinates in the Catalog Record Be Useful?,” Journal of Map & Geography Libraries 6, no. 2 (July 13, 2010): 140–50, https://doi.org/10.1080/15420353.2010.492304. INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2019 51 16 Bidney and Clair, “Harnessing the Geospatial Semantic Web.” 17 Rick Bennett et al., “MapFAST: A FAST Geographic Authorities Mashup with Google Maps,” Code4Lib Journal, no. 14 (July 25, 2011): 1–9, http://journal.code4lib.org/articles/5645. 18 Bennett et al., 1. 19 Rainer Simon et al., “Peripleo: A Tool for Exploring Heterogeneous Data through the Dimensions of Space and Time,” The Code4Lib Journal, no. 31 (Jan. 28, 2016), http://journal.code4lib.org/articles/11144. 20 Rainer Simon et al., “The Pleiades Gazetteer and the Pelagios Project,” in Placing Names: Enriching and Integrating Gazetteers, ed. Merrick Lex Berman, Ruth Mostern, and Humphrey Southall, The Spatial Humanities (Bloomington: Indiana Univ. Pr., 2016), 97–109. 21 Merrick Lex Berman, “Linked Places in the Context of Library Metadata” (Nov. 10, 2016), https://sites.fas.harvard.edu/~chgis/work/docs/papers/HVD_LibraryLinkedDataGroup_LexB erman_20161110.pdf. 22 Lisa R. Johnston and Kristi L. Jensen, “MapHappy: A User-Centered Interface to Library Map Collections via a Google Maps ‘Mashup,’” Journal of Map & Geography Libraries 5, no. 2 (July 2009): 114–30, https://doi.org/10.1080/15420350903001138; Chris Freel et al., “Geocoding LCSH in the Biodiversity Heritage Library,” The Code4Lib Journal, no. 2 (Mar. 24, 2008), http://journal.code4lib.org/articles/52; Gina L. Nichols, “Merging Special Collections with GIS Technology to Enhance the User Experience,” SLIS Student Research Journal 5, no. 2 (2015): 52–71, http://scholarworks.sjsu.edu/slissrj/vol5/iss2/5/. 23 Hector Gonzalez et al., “Google Fusion Tables: Data Management, Integration and Collaboration in the Cloud,” in Proceedings of the 1st ACM Symposium on Cloud Computing (Indianapolis: ACM, 2010), 175–80, https://doi.org/10.1145/1807128.1807158. 24 The ISAW Library New Titles library is available at http://www.zotero.org/groups/290269. 25 Since our interest was in obtaining coordinate data, we determined that LCNAF and LCSH would not be appropriate to our needs. Although some MARC authority records include coordinate data, it is not present in all geographic headings. Moreover, where coordinate data is available in the authority file, it is not published in the RDF form of the records via the LC Linked Data Service (http://id.loc.gov/). Entries in the Getty Thesaurus of Geographic Names (TGN, http://www.getty.edu/research/tools/vocabularies/tgn/index.html) often include structured coordinate data, and in recent months we have begun using TGN URIs when a Pleiades URI is not available. 26 Library of Congress, Network Development & MARC Standards Office, “Subject Heading and Term Source Codes: Source Codes for Vocabularies, Rules, and Schemes,” Library of Congress, Jan. 9, 2018, https://www.loc.gov/standards/sourcelist/subject.html. 27 It is worth noting that, since the URIs are not currently being queried in the preparation of the map, much of this work could have been accomplished with pre-URI identifiers from MARC MAP AS A SEARCH BOX | MCKEE 52 https://doi.org/10.6017/ital.v38i1.10592 data, or even unique text strings. One benefit of using URIs is ease of access to coordinate data, especially from Pleiades. Pleiades puts coordinates front and center in its display, and even features a one-click feature to copy coordinates to the clipboard. Moreover, the entire Pleiades dataset is available for download, making the retrieval of coordinates automatable locally, reducing keystrokes even without active database querying. The primary benefit of using URIs instead of other forms of unique identifiers, however, is forward-compatibility. This is of immediate importance, since we are developing an updated version of the map that will actively query Pleiades for coordinates. Future benefits of the presence of URIs also include links from Pleiades into the library catalog, based on records in which place URIs appear. If and when the entire catalog shifts to a linked-data model, the benefits of having these URIs present expands exponentially, as this metadata will then be available to all manner of outside sources. 28 Sean Gillies et al., “Conceptual Overview,” Pleiades, Mar. 24, 2017, https://pleiades.stoa.org/help/conceptual-overview. 29 Library of Congress, “Subject Headings Manual (SHM)” (Library of Congress, 2014), H 690, https://www.loc.gov/aba/publications/FreeSHM/freeshm.html. 30 For example, Pleiades contains two Place resources with the identical name “Babylon”: one the Mesopotamian city and capital of the region known as Babylonia (https://pleiades.stoa.org/places/893951); the other the site of the Muslim capital of Egypt, Al-Fusṭāṭ, known in late antiquity as Babylon (https://pleiades.stoa.org/places/893951727082). 31 Google, “Notice: Google Fusion Tables Turndown,” Fusion Tables Help, Dec. 11, 2018, https://support.google.com/fusiontables/answer/9185417. 32 A method of chronological browsing was described in Vivien Petras, Ray R. Larson, and Michael Buckland, “Time Period Directories: A Metadata Infrastructure for Placing Events in Temporal and Geographic Context,” in Digital Libraries, 2006. JCDL’06. Proceedings of the 6th ACM/IEEE- CS Joint Conference on Digital Library (IEEE, 2006), 151–60, https://doi.org/10.1145/1141753.1141782.