This paper presents a new Linked Open Data brokering service model HIPLA for using and maintaining historical place gazetteers and maps based on distributed SPARQL endpoints. The model introduces several novelties: First, the service facilitates collaborative maintenance of geo-ontologies and maps in real time as a side e ect of annotating contents in legacy cataloging systems. The idea is to support a collaborative ecosystem of curators that creates and maintains data about historical places and maps in a sustainable way. Second, in order to foster understanding of historical places, the places can be provided on both modern and historical maps, and with additional contextual Linked Data attached. Third, since data about historical places is typically maintained by di erent authorities and in di erent countries, the service can be used and extended in a federated fashion, by including new distributed SPARQL endpoints (or other web services with a suitable API) into the system. To test and demonstrate the model, we created the rst prototype implementation Hipla. of the HIPLA model. Hipla. is based on four Finnish datasets in SPARQL endpoints totaling some 840,000 geocoded places on 450 historical maps from two atlas series aligned on modern maps, and on the Getty Thesaurus of Geographic Names (TGN) SPARQL endpoint in the US. As a rst application, a part of the Hipla. data service has been applied in creating a 5 million triple semantic portal of historical Second World War data with tens of thousands of end users.
foreign geographic names, sanctioned by the United States Board on Geographic Names (US BGN). GeoNames2 in an international initiative whose database contains over eight million place names harvested from tens of local databases, and there is also an interactive Web 2.0 interface for the developer community for adding new missing places.
Dealing with historical geographical places and gazetteers3 [
This paper presents a new Linked (Open) Data (LOD) broker service model
for historical places and maps, called HIPLA, addressing these challenges. The
service model is based on a set of distributed SPARQL endpoints. HIPLA is
2 http://geonames.org
3 A gazetteer is a geographical dictionary or directory used in conjunction with a map
or an atlas.
essentially a federated ontology service [
We present the HIPLA model using its prototype implementation Hipla.
for illustrating the more general underlying ideas. Hipla. is a Rich Internet
Application (RIA) service on top of distributed SPARQL endpoints. As an
application use case, the Hipla. data service has been applied in creating a
semantic portal for Second World War Data [
In the following, we rst describe the HIPLA model and the Hipla. implementation of it. After this, the cataloging process using evolving shared ontologies is in focus, followed by a discussion of Linked Data services, and an application case of a war history portal. In conclusion, related works are discussed and contributions of the paper are related to them, regarding the research challenges 1{4 above. 2
The end users of HIPLA are 1) collaborative geo-ontology developers, 2) catalogers of historical content, 3) information searchers, and 4) application developers. For group 1 HIPLA facilitates a sustainable model for aggregating historical place names in shared data repositories as time goes by. For groups 2 and 3 HIPLA provides a combination of historical and contemporary maps, linked contextual data, and semantic federated search to nd and understand historical places. User group 4 can utilize distributed SPARQL endpoints, URI resolving services, and an autocompletion text search widget
Fig. 1 depicts the components of the HIPLA service model. In the left lower corner are the public SPARQL endpoints (PSE) hosting the historical place gazetteers connected to the service, such as TGN, DBpedia, or national land survey gazetteers. Above it is a legacy cataloging or annotating system where references to historical places need to be made. This system queries the HIPLA service in the upper right corner using, e.g., an autocompletion widget. HIPLA is a brokering service that federates the query to the PSEs and aggregates the results. In addition, HIPLA has an internal repository of Suggested New Places, and may also federate the query to private SPARQL endpoints, such as a con dential place registry of a museum. In addition, HIPLA is connected to a Map geo-rectifying service, providing historical maps on top of contemporary maps for HIPLA's end-user interface. 3
In this section we show how the HIPLA system is used in practice, by presenting its prototype implementation Hipla. , publicly online at http://hipla.fi. Fig. 2 depicts the HIPLA user interface, providing the end user with the following functionalities:
Searching places For nding, disambiguating, and examining historical places, there is an autocompletion search input eld (a). By using the checkboxes above (b) the user can select which datasets (e.g., TGN, Suggested New Places) are included in the search results. The results are grouped based on their dataset, and they can be examined as follows: 1. Hovering the cursor over the search results shows where the places are: the corresponding marker bounces on the map. 2. A click on a search result label or on the corresponding map marker opens the info window of the place, showing its context (c). 3. A click on the menu button on a result row (a) shows the place data in a Linked Data browser for investigating the data in detail.
Multiple dataset browsing If the user does not know the name of the place, but she has some idea where the place is located, she can pan and zoom the map view to the area. After this it's possible to use \View all places on current map view" button next to (b) on the left. This way places from di erent datasets connected to HIPLA are rendered on the map, and the user can check if the place exists already in some of the datasets. Places from di erent datasets are dataset-wise color-coded, which makes it possible to compare places in di erent gazetteers.
View on historical maps The "Maps" (b) tab provides a list of old maps that intersect the current map view. The map images are fetched from HIPLA's Map Warper georectifying service4 and their metadata is queried with SPARQL from the map RDF graph of the HIPLA service. Each map has a checkbox for rendering the map on the main map view, a thumbnail image, information about map series, scale and type, and a link to view the map in Map Warper. All map series are visible by default, but with the map series button it is possible to lter maps series-wise. Once one or more historical maps have been selected with the checkboxes for viewing, the opacity of the historical maps can be adjusted with the slider that is located on the top right corner of the map. If the user pans or zooms the main map view, clicking on the "Refresh map list" button updates the map list.
View contextual data When the user selects a place, the resource can be
browsed using the Linked Data browser SAHA5 to see its detailed structure.
Furthermore, contextual data (c) is provided connecting the place to other
relevant data sources using an infobox. This functionality was rst piloted with the
spatial datasets of the WarSampo portal [
Suggesting new place names If the place at hand does not exist in any of the datasets connected to HIPLA, the user can submit a place suggestion
by clicking the "Add a new place" button and lling the place details form. Coordinates for the new place suggestion can be selected from the Google map view, and it is possible to use historical map sheets for setting the coordinates. Finally the user must select the target dataset for the place suggestion. After the "Save changes" button is clicked, the new place suggestion is available for all the users of the service.
Our rst application case in developing HIPLA has been on modeling, storing, and searching Finnish place names in multiple SPARQL endpoints, and on displaying them on historical and contemporary maps at the same time. The datasets used in Hipla. are stored in separate RDF graphs, which makes it possible to o er dynamic selection of data sources for the user interface or external data consumers. Table 1 presents the datasets currently connected to HIPLA. village, house, etc. 34,938
New datasets can be added to the Hipla. service by providing their conguration to the system. The required information includes 1) the SPARQL endpoint URL, 2) a SPARQL query for the autocompletion search, and 3) a HTML template for rendering a SPARQL result in the autocompleted result list. In addition, another SPARQL query and a HTML template can be supplied for providing contextual data for the user when a place is selected.
The system was implemented using the Linked Data Finland platform6 [
and autocomplete search functionality using typeahead.js.9 Embedded Google Maps view is used to visualize historical places. HIPLA's Map Warper is an instance of the open source Map Warper tool10 of the New York Public Library for georectifying old maps on modern ones. 4
When annotating data using an ontology service, it is a challenge to decide what to do when a new concept is needed in a shared ontology. The cataloger needs to make a reference to a concept not present in the shared ontology, say create a new place instance. The traditional approach to maintaining a Knowledge Organization System (KOS) is to contact the committee in charge of maintaining the KOS with a suggestion of a new concept to be added to the system. However, the cataloger cannot wait for the committees decision for days, weeks, or months. Therefore, a shared mechanism is needed for populating the ontology with the following features: First, it should be possible for the cataloger to create a new concept in real time or she is not able to make the annotation at hand, or has to make a less accurate annotation using only the existing concepts. Second, the new concept should be shared in real time with other users. Otherwise they may end up in creating duplicates of the same concept. Third, there should be a mechanism for the maintaining committee of the KOS to edit, approve, or reject the proposed concepts afterwards, in case errors or duplicates arise.
We generalize our previously proposed ontology maintenance process [
The ontology evolves by crowdsourcing the DUs as follows: 1. A DU searches for an annotation concept C (using, e.g., autocompletion search). The VCs and SCs are grouped into their own categories in the result listing. In this way the DU knows whether the concept is already accepted or was only suggested by someone. Both VCs and SC concepts can be used for annotation. 2. If C is found and acceptable the DU can use it and the annotation is done.
10 https://github.com/timwaters/mapwarper 3. Otherwise, she can create a new concept C with mandatory metadata, including a persistent identi er (IRI), labels for human identi cation, and additional properties, such as (sub)classes, coordinates, etc., depending on the data model of the KOS. Also, the ontologies the concept should be added into are chosen in this step. 4. C is added into the SC, and is immediately available to all users. In particular, the DU is able to use C in her annotation at hand immediately. 5. The OCs validate new concepts in the SC every now and then. 6. If the new concept C is valid, the OC copies it from the SC into a VC. The OC typically mints a new URI to the concept so that it conforms to the URI policy of the ontology the concept is added into. At this point, it is possible to add and edit metadata of the concept. As the IRI of the suggested concept may have already been used by the community, it should not be removed. Instead, the OC creates a new mapping entry in the CM. A mapping entry is a triple (suggestedIRI, mapping, validatedIRI) where suggestedIRI is the suggested concept, validatedIRI is a concept in a VC, and mapping is a predicate indicating the relation between the suggested and validated concept. Typically owl:sameAs is used as the mapping predicate. 7. If the concept is not accepted, OC either marks it with an unaccepted status or adds a new mapping entry in the CM linking the suggested concept to an existing validated concept that should be used instead.
The idea of the CM is to give a fallback service to users who have used suggested concepts. Using the concept mappings the data already annotated with SC by a user in her database can be mapped to the validated concepts of the VCs later on. 5
The Hipla. data services include the publication of the suggested place names and the metadata of historical maps as Linked Data in a SPARQL endpoint, resolving URIs of the brokered data sources for end users, and an autocompletion widget for integrating the data into legacy systems.
URI Resolving of Linked Data The place names suggested by the users are published in a SPARQL endpoint hosted in the Linked Data Finland platform. The URIs of the data resources are resolved to RDF presentation for machines and HTML pages for humans. The distributed gazetteers used in the Hipla. as data sources are published in the Linked Data publication platforms ran by the original data owners, and used in Hipla. through their SPARQL endpoints. As Hipla. is a brokering service, the URI resolving of Linked Data of the places in the gazetteers is handled by the data owners.
Hipla. prototype implementation provides a URI resolving service for displaying information related to a place on a map view. The URL template for resolving a place URI is http://hipla.fi/?uri=URI, where URI is the identier of a place. The resolving mechanism can be used for displaying an HTML presentation of a place for an end user for any place that is known to the Hipla. service, i.e., can be found in a SPARQL endpoint con gured as a data source for the service.
Publishing Historical Maps We use three classes to model historical maps: 1) atlas, 2) map series, and 3) map. An atlas is a collection of maps, which may contain one or more map series. A map series is a map published over several sheets. Therefore the map sheets belonging to the same series have the same scale and cartographic speci cations. The map class represents the actual map sheets. It is also possible to store an individual map sheet without using the atlas or map series class. The map series and map classes are described with common properties, e.g. scale, map type and time of issue.
The metadata of the maps including a map identi er is stored in the RDF graph of the HIPLA Service, and the Map Warper tool provides the actual map images for application use based on the map identi er.
Integration into Legacy Applications The idea is that Cultural Heritage
organizations can connect their legacy cataloging systems to HIPLA using an
API in the same vein as in ONKI [
This section presents an application of the Hipla. prototype in the WarSampo Portal,11 a system for publishing collections of heterogeneous, distributed data about the Second World War on the Semantic Web. The WarSampo Portal allows both historians and laymen to study war history and destinies of their family members in war from di erent interlinked perspectives. 11 Available and in use at http://sotasampo.
In this case, the Hipla. was populated with four data sources in SPARQL endpoints: 1) National Archives of Finland's map application data of 612 wartime municipalities, 2) the Finnish Spatio-Temporal Ontology describing the regions of the Finnish municipalities in di erent times,12 3) a dataset of geocoded Karelian map names (35,000 map names with coordinates and place types), and 4) the current Finnish Geographic Names Registry (PNR) (800,000 places). In addition, some 450 historical map sheets from two atlases were recti ed on modern maps.
Most datasets used in WarSampo contain references to historical places. Hipla. provides the application with a brokering service of historical places for 1) interlinking the WarSampo datasets and for 2) visualizing the contents of di erent datasets on historical and contemporary maps. Since WarSampo uses the Hipla. URIs in its datasets, the resolving mechanism of rendering URIs as end-user HTML pages can be utilized easily. When there is a need in WarSampo to show the user information about a place with a URI, this can be done easily by just creating the link http://hipla.fi/?uri=URI. For example, the place \Porkkala" can be found in the PNR dataset13 of the Linked Data Finland data service with the local name P 10070203. Its URI
can be rendered in Hipla. by the URI:
as the HTML page depicted in Fig. 3, showing the location and related data of Porkkala. This page has similar functionalities as the Hipla. service described earlier. For example, Porkkala can be viewed on historical maps by using the map tab, and related photographs, events, and magazine articles can be viewed by following the links. 7
This paper presented HIPLA, an ontology library service [
In below, we summarize how the HIPLA model and Hipla. system address the research challenges 1{4 set in Section 1, and in contrast with the related works above.
1. Contextualizing Historical Place Names. Gazetteers typically
provide information based on one underlying register without external context.
HIPLA advocates the idea of enriching historical place data by contextual data
based on using Linked Data, as illustrated in the WarSampo application case
based on Hipla. . It seems that this possibility is not much used in current
gazetteers even if they were based on LD that would facilitate this. Hipla. data
service supports URI dereferencing and traditional Linked Data browsing [
2. Need for Historical Maps. In HIPLA, historical maps can be used for providing a historical context for places. There are several online systems for historical maps available. For example, OldMapsOnline23 is a search engine for nding historical maps covering a given contemporary area. In contrast to Hipla. , this service comes without a historical gazetteer, and the maps are not recti ed.
HIPLA includes a map service for aligning and viewing georecti ed historical maps, as in the New York Public Library's Chronology of Place gazetteer.24 Major tools for rectifying maps include the open source tool Map Warper, employed in Hipla. , and the commercial Georeferencer.25 These systems focus on maps and are not data service gazetteers. HIPLA also publishes the metadata of the historical maps as Linked (Open) Data. The dynamic and transparent selection of the data sources makes it possible to understand the origins of the data.
3. Maintaining Evolving Historical Gazetteers. A novelty of the HIPLA model lies in the idea of crowdsourcing the creation of the ontologies by soliciting contributions from the catalogers of Cultural Heritage content, as a side e ect of their daily work. This idea is di erent from systems like Pleiades or GeoNames that crowdsource volunteers' work in gazetteer development. We envision that sustainable gazetteer maintenance should involve not only gazetteer developers but also their users.
4. Managing Distributed Historical Gazetteers. HIPLA is a
brokering service that not only aggregates the data for humans but also for machines
(legacy cataloging systems) using the SPARQL endpoint APIs of the
participating data services. The service itself hosts a triple store of shared suggested new
places and map metadata. The proposed brokering solution bears resemblance
to idea of \normalized ontology repositories" [
Acknowledgements Hanna Hyvonen recti ed Hipla. maps and Eetu Makela contributed in creating gazetteers. Our work was supported by the Finnish Cultural Foundation and the Wikidata Project of Wikimedia Finland. 23 http://www.oldmapsonline.org 24 http://nypl.gazetteer.us 25 http://www.georeferencer.com