=Paper=
{{Paper
|id=Vol-1608/paper-06
|storemode=property
|title=Linked Data brokering service for historical places and maps
|pdfUrl=https://ceur-ws.org/Vol-1608/paper-06.pdf
|volume=Vol-1608
|authors=Eero Hyvönen,Esko Ikkala,Jouni Tuominen
|dblpUrl=https://dblp.org/rec/conf/esws/HyvonenIT16
}}
==Linked Data brokering service for historical places and maps==
https://ceur-ws.org/Vol-1608/paper-06.pdf
Linked Data brokering service for
historical places and maps
Eero Hyvönen, Esko Ikkala, and Jouni Tuominen
Semantic Computing Research Group (SeCo), Aalto University, Finland
http://seco.cs.aalto.fi/, firstname.lastname@aalto.fi
Abstract. This paper presents a new Linked Open Data brokering ser-
vice model HIPLA for using and maintaining historical place gazetteers
and maps based on distributed SPARQL endpoints. The model intro-
duces several novelties: First, the service facilitates collaborative main-
tenance of geo-ontologies and maps in real time as a side effect of an-
notating 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 typ-
ically maintained by different authorities and in different countries, the
service can be used and extended in a federated fashion, by including
new distributed SPARQL endpoints (or other web services with a suit-
able API) into the system. To test and demonstrate the model, we created
the first prototype implementation Hipla.fi of the HIPLA model. Hipla.fi
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 first application, a
part of the Hipla.fi 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.
1 Challenges of Managing Historical Place Gazetteers
Linked Data publishing principles [4] and geospatial place ontologies [1] are
becoming popular in georeferencing [5], i.e., in relating information to geographic
locations in information sciences. Ontologies define classes and individuals for
representing geographic regions, their properties, and mutual topological and
other relationships. Interoperability of dataset contents in terms of geographical
places can be fostered by sharing place resource URIs in different applications,
preferably already when cataloging and annotating data.
There are lots of databases and repositories available for contemporary places
provided by national land survey organizations and international consortia. For
example, GEOnet Names Server1 is the official repository of standard spellings of
1
http://geonames.nga.mil/gns/html/
40 A. Adamou, E. Daga and L. Isaksen (eds.)
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 [12] adds a tem-
poral dimension and the notion of change to Geographic Information Systems
(GIS). Many, if not most, historical places, such as Carthago or Czechoslovakia,
do not exist anymore on modern maps or have at least changed substantially
over the time. A place name may refer to different versions of the places depend-
ing on the time [9]. For example, Germany in 1943, 1968, and today covers quite
different regions, and the question of what Germany actually was in the 18th
and 19th century may be vague. As a result, creating and managing historical
place ontologies has several special challenges when compared to contemporary
gazetteers, including the following:
1. Contextualizing Historical Place Names. Understanding a historical
place requires more contextual data than a contemporary one. Not only are
the names ambiguous, but even ”same” places can have different properties
in different times (e.g., ”Germany” above).
2. Need for Historical Maps. Historical places cannot necessarily be found
on modern maps, but only on old historical maps from a matching time
period that provides an essential context for the places.
3. Maintaining Evolving Historical Gazetteers. Historical places cannot
be listed comprehensively, but new place names are encountered constantly
in cataloging, and as time goes and the world evolves. Dynamic and fast
mechanisms for ontology updates and sharing them are needed. The situ-
ation is more dynamic in historical than in modern gazetteers that can be
completed more easily at a fixed point in time.
4. Managing Distributed Historical Gazetteers. Data about historical
places are often distributed across different contemporary countries, whose
data is managed by national institutions. Data from several organizational
data silos are usually needed to cover larger areas (say the Roman Empire),
and on the other hand, these organizations often maintain overlapping reg-
istries of the same places. More cross-organizational collaboration is needed
when dealing with historical gazetteers than with contemporary ones. Since
there are several strong independent gazetteer authorities in the field, one
has to deal with different identifiers, data models, and distributed data stores
that evolve independently in different locations.
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.
1st Workshop on Humanities in the Semantic Web (WHiSe 2016) 41
essentially a federated ontology service [2, 14] for historical places where the
historical context of places can be presented to the end user for disambiguat-
ing place names and understanding them in context and on historical maps.
A novelty of HIPLA is its collaborative real-time mechanism for updating and
maintaining evolving ontologies of historical places, based on providing the com-
munity with yet another SPARQL endpoint of suggested new place resources.
This data source can be updated in real time for sharing new resources within
the community, and be finally integrated into the underlying main ontologies.
Our ultimate goal is to integrate the HIPLA service model into legacy cataloging
workflows, which facilitates a sustainable model for aggregating historical place
names in shared data repositories as time goes by.
We present the HIPLA model using its prototype implementation Hipla.fi
for illustrating the more general underlying ideas. Hipla.fi is a Rich Internet
Application (RIA) service on top of distributed SPARQL endpoints. As an ap-
plication use case, the Hipla.fi data service has been applied in creating a se-
mantic portal for Second World War Data [10] dealing with places in pre-war
and contemporary Finland, many of which do not exist on after-war maps, since
they were destroyed or renamed after annexed to the Soviet Union in the Paris
Peace Treaties in 1947. The paper extends our earlier papers [8, 11] by making a
clear distinction between the general brokering model HIPLA and its realization
Hipla.fi that is also applied in an in-use semantic portal application.
In the following, we first describe the HIPLA model and the Hipla.fi imple-
mentation of it. After this, the cataloging process using evolving shared ontolo-
gies is in focus, followed by a discussion of Linked Data services, and an applica-
tion 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 HIPLA Service Model
The end users of HIPLA are 1) collaborative geo-ontology developers, 2) cat-
alogers of historical content, 3) information searchers, and 4) application de-
velopers. 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 find 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
42 A. Adamou, E. Daga and L. Isaksen (eds.)
Fig. 1. HIPLA system architecture.
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 confi-
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 Prototype Implementation: Hipla.fi
In this section we show how the HIPLA system is used in practice, by present-
ing its prototype implementation Hipla.fi, publicly online at http://hipla.fi.
Fig. 2 depicts the HIPLA user interface, providing the end user with the following
functionalities:
Searching places For finding, disambiguating, and examining historical
places, there is an autocompletion search input field (a). By using the check-
boxes 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
1st Workshop on Humanities in the Semantic Web (WHiSe 2016) 43
Fig. 2. Hipla.fi user interface.
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 different
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 different datasets are
dataset-wise color-coded, which makes it possible to compare places in different
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 filter
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 rele-
vant data sources using an infobox. This functionality was first piloted with the
spatial datasets of the WarSampo portal [10], providing, e.g., 160,000 historical
photos related to the places during the Second World War and a timeline of
historical events.
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
4
http://mapwarper.onki.fi
5
http://seco.cs.aalto.fi/services/saha/
44 A. Adamou, E. Daga and L. Isaksen (eds.)
by clicking the ”Add a new place” button and filling 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 first application case in developing HIPLA has been on modeling, stor-
ing, 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.fi are stored in separate RDF graphs, which makes it pos-
sible to offer dynamic selection of data sources for the user interface or external
data consumers. Table 1 presents the datasets currently connected to HIPLA.
Table 1. Datasets connected to Hipla.fi.
Dataset Original source Place type Size
Finnish Municipalities National Archives of municipality 612
1939–1944 Finland
Karelian map names in Fin- Jyrki Tiittanen village, house, etc. 34,938
land and Russia / National Land Sur-
vey of Finland
Finnish Spatio-Temporal SeCo research group municipality 1261
Ontology
Finnish Geographic Names National Land Sur- 61 place types 797,668
Registry vey of Finland
The Getty Thesaurus of J. Paul Getty Trust 1800 place types 2,156,896
Geographic Names
Historical Senate atlas National Archives of map 404
(ca. 1900) in 1:21 000 Finland
Karelian maps (1928–1951) National Land Sur- map 47
in 1:100 000 vey of Finland
New datasets can be added to the Hipla.fi service by providing their con-
figuration 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 [7],
based on Fuseki7 with a Varnish Cache8 front end for serving the Linked Data.
The end-user interface of HIPLA is a lightweight HTML5 single page map ap-
plication, which provides access to multiple data sources with SPARQL queries
6
http://www.ldf.fi
7
http://jena.apache.org/documentation/serving data/
8
https://www.varnish-cache.org
1st Workshop on Humanities in the Semantic Web (WHiSe 2016) 45
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 Cataloging with Evolving Shared Ontologies
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 [8] by
supporting simultaneous usage of multiple ontologies, managed independently by
different organizations. The process involves three groups of people: 1) Ontol-
ogy Committees (OC) responsible for maintaining and validating the ontologies,
2) Developer Users (DU) using the system with the right to add new concept
suggestions in the system, 3) Ordinary Users (OU) with the right of using the
system as it is. The ontology infrastructure is divided into three parts: 1) Vali-
dated Concepts (VC) constitute the official knowledge graphs of the ontologies
that have been validated and approved by the OCs. 2) Suggested Concepts (SC)
constitute a graph that includes concepts proposed by the DUs, but that have
not been validated by the OCs yet. 3) Concept Mappings (CM) is a graph of
mappings between suggestions and accepted concepts in the VC graphs.
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.
9
http://twitter.github.io/typeahead.js/
10
https://github.com/timwaters/mapwarper
46 A. Adamou, E. Daga and L. Isaksen (eds.)
3. Otherwise, she can create a new concept C with mandatory metadata, in-
cluding a persistent identifier (IRI), labels for human identification, and ad-
ditional 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 partic-
ular, 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 Linked Data Services
The Hipla.fi 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.fi as
data sources are published in the Linked Data publication platforms ran by the
original data owners, and used in Hipla.fi through their SPARQL endpoints. As
Hipla.fi is a brokering service, the URI resolving of Linked Data of the places in
the gazetteers is handled by the data owners.
Hipla.fi prototype implementation provides a URI resolving service for dis-
playing information related to a place on a map view. The URL template for
1st Workshop on Humanities in the Semantic Web (WHiSe 2016) 47
resolving a place URI is http://hipla.fi/?uri=URI, where URI is the identi-
fier 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.fi
service, i.e., can be found in a SPARQL endpoint configured 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 specifications. 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 identifier 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 identifier.
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 [13], harmonizing the content created by
the community. As a starting point, we have isolated the text search user in-
terface component used in the Hipla.fi prototype into a stand-alone JavaScript
widget. The widget can be integrated into a web-based cataloging system, en-
riching text fields with autocompletion functionalities. The URI and label of the
place selected with the widget are communicated to the cataloging system via
a JavaScript callback function along with information about the source dataset,
e.g., its name and SPARQL endpoint URL. The idea is that the widget can
be configured to suit different use cases, e.g., by adding organization’s private
repository of places as a data source, or by customizing what kind of contex-
tual information about a place is displayed in the autocompletion search result
listing (e.g., accompanied with a compact info window containing a map that
shows the location of the place). We consider the autocompletion widget to be
generic enough to be applied not only to historical place ontologies, but to any
kind of reference ontologies (e.g., person databases and classification schemes).
6 Application Case: Semantic Portal for World War II
This section presents an application of the Hipla.fi 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 different interlinked perspectives.
11
Available and in use at http://sotasampo.fi
48 A. Adamou, E. Daga and L. Isaksen (eds.)
In this case, the Hipla.fi 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 different times,12 3) a dataset of geocoded Kare-
lian map names (35,000 map names with coordinates and place types), and 4)
the current Finnish Geographic Names Registry (PNR) (800,000 places). In ad-
dition, some 450 historical map sheets from two atlases were rectified on modern
maps.
Most datasets used in WarSampo contain references to historical places.
Hipla.fi provides the application with a brokering service of historical places
for 1) interlinking the WarSampo datasets and for 2) visualizing the contents of
different datasets on historical and contemporary maps. Since WarSampo uses
the Hipla.fi 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
http://ldf.fi/pnr/P_10070203
can be rendered in Hipla.fi by the URI:
http://hipla.fi/?uri=http://ldf.fi/pnr/P_10070203
as the HTML page depicted in Fig. 3, showing the location and related data
of Porkkala. This page has similar functionalities as the Hipla.fi 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 Related Work and Discussion
This paper presented HIPLA, an ontology library service [2] model for brokering
historical places from distributed LD gazetteers on historical and contemporary
maps, and its prototype implementation Hipla.fi. There are several gazetteers
of historical places on the web, such as The Historical Gazetteer of England’s
Place-names,14 Gazetteer for Scotland,15 the Danish service DigDag16 for find-
ing historical administrative areas with polygons on maps, the Dutch services
Gemeentegeschiedenis.nl17 and Histopo.nl,18 and the Alexandria Digital Library
12
http://seco.cs.aalto.fi/ontologies/sapo/
13
Described at http://www.ldf.fi/dataset/pnr
14
http://www.placenames.org.uk
15
http://www.scottish-places.info
16
http://www.digdag.dk
17
http://www.gemeentegeschiedenis.nl
18
http://histopo.nl
1st Workshop on Humanities in the Semantic Web (WHiSe 2016) 49
Fig. 3. A Linked Data Finland URI rendered for the end user as HTML in Hipla.fi.
Gazetteer [6]. Thesauri of historical places, published as Linked Data, include
the Getty TGN of some 1.5 million records and Pleiades19 [3] for ancient places.
Pelagios projects20 develop APIs and GUIs for multiple historical gazetteers,
such as Pleiades. DBpedia21 contains masses of LD of historical and contempo-
rary places while GeoNames focuses on modern places. VIAF22 brokers mutually
aligned authority files, including historical place names, from various national
libraries around the world in LD form, and from some additional open data
sources, such as DBpedia and Wikidata.
In below, we summarize how the HIPLA model and Hipla.fi 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 pro-
vide 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.fi. It seems that this possibility is not much used in current
gazetteers even if they were based on LD that would facilitate this. Hipla.fi data
service supports URI dereferencing and traditional Linked Data browsing [4],
providing also a kind of context for familiarizing oneself with the underlying
data. This LD publishing idea of resolving external place URIs as data in differ-
ent formats or as ready-to-use HTML pages for the end user to browse is used in
19
http://pleiades.stoa.org
20
http://commons.pelagios.org
21
http://www.dbpedia.org
22
http://viaf.org
50 A. Adamou, E. Daga and L. Isaksen (eds.)
LD-based gazetteers in different ways and to different degrees. Hipla.fi provides
a complete LOD service for its own LD repositories.
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 finding historical maps covering a given contemporary area. In contrast to
Hipla.fi, this service comes without a historical gazetteer, and the maps are not
rectified.
HIPLA includes a map service for aligning and viewing georectified historical
maps, as in the New York Public Library’s Chronology of Place gazetteer.24 Ma-
jor tools for rectifying maps include the open source tool Map Warper, employed
in Hipla.fi, 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 effect of
their daily work. This idea is different 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 broker-
ing service that not only aggregates the data for humans but also for machines
(legacy cataloging systems) using the SPARQL endpoint APIs of the participat-
ing 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” [15] where distributed ontology
services are normalized using shared SKOS-based APIs and are combined into
a larger service. In HIPLA, SPARQL is used for normalization and the domain
is historical gazetteers. This idea is also related to the VIAF model where au-
thority files from different sources are mapped to each other using owl:sameAs,
and are given unifying URIs in a new namespace. In our case, such mappings
and URIs are not created or maintained. The choice of what URIs to use is left
to the end user.
Acknowledgements Hanna Hyvönen rectified Hipla.fi maps and Eetu Mäkelä
contributed in creating gazetteers. Our work was supported by the Finnish Cul-
tural Foundation and the Wikidata Project of Wikimedia Finland.
23
http://www.oldmapsonline.org
24
http://nypl.gazetteer.us
25
http://www.georeferencer.com
1st Workshop on Humanities in the Semantic Web (WHiSe 2016) 51
References
1. Ashish, N., Sheth, A. (eds.): Geospatial Semantics and Semantic Web: Foundations,
Algorithms, and Applications. Springer–Verlag (2011)
2. d’Aquin, M., Noy, N.F.: Where to publish and find ontologies? A survey of ontology
libraries. Web Semantics: Science, Services and Agents on the World Wide Web
11, 96–111 (2012)
3. Elliott, T., Gillies, S.: Digital geography and classics. Digital Humanities Quarterly
3(1) (2009), http://www.digitalhumanities.org/dhq/vol/3/1/000031.html
4. Heath, T., Bizer, C.: Linked Data: Evolving the Web into a Global Data Space
(1st edition). Synthesis Lectures on the Semantic Web: Theory and Technology,
Morgan & Claypool (2011), http://linkeddatabook.com/editions/1.0/
5. Hill, L.: Georeferencing: The Geographic Associations of Information. MIT Press
(2009)
6. Hill, L., Frew, J., Zheng, Q.: Geographic names: The implementation
of a gazetteer in a georeferenced digital library. D-Lib 5(1) (1999),
http://www.dlib.org/dlib/january99/hill/01hill.html
7. Hyvönen, E., Tuominen, J., Alonen, M., Mäkelä, E.: Linked Data Finland: A 7-star
model and platform for publishing and re-using linked datasets. In: The Semantic
Web: ESWC 2014 Satellite Events, Revised Selected Papers. pp. 226–230. Springer–
Verlag (2014)
8. Hyvönen, E., Tuominen, J., Ikkala, E., Mäkelä, E.: Ontology services based on
crowdsourcing: Case National Gazetteer of Historical Places. In: Proc. of the
ISWC 2015 Posters & Demonstrations Track. CEUR-WS Proceedings (2015),
http://www.ceur-ws.org/Vol-1486, vol 1486
9. Hyvönen, E., Tuominen, J., Kauppinen, T., Väätäinen, J.: Representing and uti-
lizing changing historical places as an ontology time series. In: Ashish and Sheth
[1], pp. 1–25
10. Hyvönen, E., Heino, E., Leskinen, P., Ikkala, E., Koho, M., Tamper, M., Tuominen,
J., Mäkelä, E.: WarSampo data service and semantic portal for publishing linked
open data about the Second World War history. In: Proc. of ESWC 2016. Springer–
Verlag (2016)
11. Ikkala, E., Tuominen, J., Hyvönen, E.: Contextualizing historical places in a
gazetteer by using historical maps and linked data. In: Proc. of Digital Humanities
2016, short papers (2016)
12. Southall, H., Mostern, R., Berman, M.L.: On historical gazetteers. International
Journal of Humanities and Arts Computing 5(2), 127–145 (2011)
13. Tuominen, J., Frosterus, M., Viljanen, K., Hyvönen, E.: ONKI SKOS server for
publishing and utilizing SKOS vocabularies and ontologies as services. In: Proc. of
the 6th European Semantic Web Conference (ESWC 2009). pp. 768–780. Springer–
Verlag (2009)
14. Viljanen, K., Tuominen, J., Känsälä, T., Hyvönen, E.: Distributed semantic content
creation and publication for cultural heritage legacy systems. In: Proc. of the 2008
IEEE International Conference on Distibuted Human-Machine Systems. pp. 335–
340. IEEE Press (2008)
15. Viljanen, K., Tuominen, J., Mäkelä, E., Hyvönen, E.: Normalized access to on-
tology repositories. In: Proc. of the Sixth International Conference on Semantic
Computing (IEEE ICSC 2012). pp. 109–116. IEEE Press (2012)