In the last years several web services emerged that manage and make accessible place gazetteers for the archaeologies and historical sciences. By using semantic technologies these gazetteers act as linked data hubs connecting multiple datasets of varying thematic focus and of different structural properties. Just as important as the geo-spatial properties of research objects are their temporal classifications. In this talk we describe a time gazetteer web service that assumes a role similar to that of place gazetteers but for temporal concepts and cultural periods.

1. CoDArchLab
Cologne Digital Archaeology Laboratory
i3mainz
Institut für Raumbezogene
Informations- und Messtechnik
Hochschule Mainz
iDAI.chronOntology
Wolfgang Schmidle, Nathalie Kallas, Sebastian Cuy (DAI)
Florian Thiery (i3mainz)
Digital Classicist Seminar Berlin, 10.01.2017

2. Time gazetteers
Arachne
• no term definitions at all (on purpose)
• no dating information, can be added for individual items
• will move to chronOntology
Portraitbüste:Augustus
https://arachne.dainst.org/entity/1075871

3. Time gazetteers
Getty AAT
• very large, "Styles and Periods" facet has more than 5000 terms
• LOD
• descriptions but no real definitions
• spatial information only in free text
• inconsistent use of period types
• simple hierarchy
Augustan
http://www.getty.edu/vow/AATFullDisplay?find=&logic=AND&note=&subjectid=300020543

4. Time gazetteers
PeriodO http://perio.do/
• LOD, used in ARIADNE project
• regions and timespans as part of the definition
• Periods as objects of discourse

5. Time gazetteers
FORTH thesaurus
• demonstrator for an "ideal" time gazetteer
• periods as concepts
• definitions/types and relations
• only 8 terms from one source
• bounding boxes (Spacetime volumes)
• will be ingested by ChronOntology
http://www.ics.forth.gr/isl/publications/paperlink/CIDOCpaper1_Doerr.pdf
http://cidoc-crm.org/docs/period/xsl_output.html

6. iDAI.welt

7. ChronOntology
counterpart to iDAI.gazetteer (http://gazetteer.dainst.org/)
• part of iDAI.welt, guaranteed availability after end of project
• temporal norm data for the DAI
• LOD: stable URIs
• robust system for large amounts of data
• accept data of differing quality and completeness
• project partners can enter their data
• batch imports and user interface
• minimal goal: "get IDs for your temporal norm data"
funded by German Research Foundation (DFG), 2015 to 2017

8. ChronOntology

9. Implementation
Frontend and widgets:
http://chronontology.dainst.org
• based on AngularJS
• beta version!
• Search
• Visualization of single datasets
• browse space and time
• on GitHub

10. Implementation
Backend
http://chronontology.dainst.org/data/period/rjqJUoIToI7L
• LOD hub, REST API
• Java
• JSON as data format
• elasticsearch
• on GitHub

11. Goals
• take care of time-specific challenges, e.g. definitions
• ingest data from electronic sources and secondary literature
• accommodate conflicting definitions and opinions
• easy to use for minimal datasets
• linking with other (time) gazetteers

12. Design principles
attempt CIDOC CRM compatibility where possible:
• compatible with CIDOC CRM and extensions (periods as concepts)
• use E4 Period as basis (sets of coherent phenomena or cultural
manifestations occurring in time and space)
—> but e.g. Murad II
• add properties only if there is evidence in the data

13. Design principles
P1: A dataset describing a temporal term is not identified by its name, but
a unique ID.
This is a well-known general principle, just as a John Smith cannot be identified by his
name alone. Using a unique ID allows creating different datasets for different usages of
the same term, and one dataset can have more than one name associated with it.

14. Design principles
P2: A temporal term can not defined by dating information.
The definition and any dating information based on this definition should not be
confounded. Only the definition determines whether we are talking about the same
thing or not (co-reference), and only when a term has a definition or at least a type
such as “political” or “material culture” one can meaningfully associate dating
information with it.
Similarly to a dictionary entry, a temporal term can have more than one meaning, each
potentially leading to different datings.
A temporal term may not even have any known explicit dating information, for
instance when it is only part of a relative chronology. Likewise, a temporal term can be
defined without knowing anything about its spatial extent.
• However, we strongly encourage adding explicit temporal and spatial information
wherever it is missing
• Add information by reasoning (see gazetteer)

15. Design principles
P3: Each defined temporal term is actually a spacetime volume (STV)
I.e. the area in space and time where it happened, regardless of what we actually know
about this STV. Any explicit spatial and temporal information given about the term
approximates this STV.
Follows from using E4 Period.

16. 4500 BCE
3700 BCE
2900 BCE
2100 BCE
1300 BCE
500 BCE
W
orldw
ide
N
earEast
C
entralAsia
EastAsia
South
Asia
SoutheastAsia
Europa
Sub-saharian
Africa
IA BA SA
The Bronze Age is a time period characterized by the use of bronze.

17. Design principles
P4: Mark whether a period is ongoing or not.
This information will have consequences for reasoning over the data, for example for
establishing bounding boxes for the period.
Different extents may be due to looking at it at different points in time.

18. Design principles
P5: A link to the time gazetteer may contain additional information.
Especially time information.The details need to be worked out.
In any case, if one simply links to a dataset in the time gazetteer without specifying any
additional information, the semantics of the connection defaults to the usual “is part of
or equal to” interpretation of a gazetteer link.

19. Design principles
P6: The data model should be robust enough to accommodate data with
varying degrees of data quality and completeness.
Temporal term data that was not designed for this time gazetteer should fit
nonetheless.All typical statements about temporal terms should fit in.
The data to be imported should be modeled semantically in a form that may contain
imprecise statements, but explicitly wrong statements should be avoided.
The data model should support a workflow for making the data more precise.
Minimal set of information, first ingest without too much preparatory work

20. Data model
about the dataset:
• ID
• names in different languages, preferred names
• provenance, external ID
• types, including „all meanings“
• same term with different types: political, material culture > pottery
• definition: „standard definitions“ from name and type (real defs. rarely available)
• we would prefer explicit definitions (only for core?)
• description
• tags, notes
• created, modified, version
• dating information
• ongoing

21. Data model
Relations between datasets: Sense, place, time, matching, other
• by definition:
• hasSense / isSenseOf
• follows / isFollowedBy
• isPartOf / hasPart
• matching: „sameAs“, „same as or finer than“ (more will come as needed)
• lists

22. Senses
• hasSense / isSenseOf
all meanings, political, etc.
• must be easy to use! no barrier to entry
• matching of similar senses: e.g. style vs. material culture
• complementary to e.g. PeriodO: some ChronOntology data may be
added to PeriodO (as new statements), especially "all meanings"

23. Connection to the iDAI.gazetteer
Gazetteer: split between Gazetteer and chronOntology
connection types: spatiallyPartOfRegion, hasCoreArea, isNamedAfter
„core area“, „ca.“: problematic, but this is what is in the ingested data
unify data models?

24. Time
• follows / isFollowedBy
• isPartOf / hasPart
• Allen relations (at the moment only inferred)
internal:
• hasTimespan: timeOriginal, begin At,AtPrecision, End etc., source
• can be repeated
Role of marker events
Aegean Bronze Age: Use case FORTH thesaurus, different dating systems

25. Matching
Data refinement: the better the data, the better the matching
Use case: DAI thesauri
Hochmittelalter (um 900 bis 1250)
Arabische Münzen
Barbarische Nachprägungen

26. The data so far
Getty AAT periods facet (the biggest chunk)
Arachne
geological epochs (several sources)
Secondary literature: Bronze age in the Levant
"chronontology core": still a little experimental

27. Ingestion workflow
• should be doable in reasonable time, faster than the Getty AAT data
• only model explicitly what is given in the source
• add explicit definition (or at least type) from free text notes
• add explicit explicit temporal and spatial information if possible
• Statements should be at least not wrong („equal to or restricted to
sense“)
• can be made more precise at any time (different dataset)
• tested with different levels of pre-processing for different parts of the
AAT

28. Ingestion workflow
• Core terms / ingested terms
• matching data: "sameAs"
http://chronontology.dainst.org/search?q=hadrianic

29. Ingestion workflow
Minimal information: similar to PeriodO ?
• Type?
• place?
• time? (becomes one opinion in the dataset)
• add provenance
Arachne: just the terms, "all meanings"

30. Challenges
Distinguish between e.g.“Neolithic, limited in a strictly geographic sense
to the Levant” and “Neolithic in the Levant” as the latter may explicitly or
implicitly have a different definition.
Data sources inconsistent or unclear: „European Bronze Age coexists with
Bronze Age (three-age system)“
List nodes
different opinions about whether one can apply “Augustan” to the ancient
Greek city of Aphrodisias (now Turkey)
• a matter of precise definition

31. Reasoning
pairs of properties
inheriting the region (not yet implemented)
isPartOf (by definition) => is temporally part of

32. Visualisation
Mapping of actual term usage

33. Visualisation
Mapping of actual term usage

34. Visualisation
Gazetteer-based search

35. Use case
Augustan: meanings of a term, Roman art by Greek artists

36. Use case
Viking Buddha: interplay of systems, formulate research questions

37. Named entities?
extend system to accommodate non-modern terms
(P5: A link to the time gazetteer may contain additional information)

38. Next steps
prepare for hands-on session in March 2017: system should be ready to
ingest data on the spot
neutral URL
Implementation: reach 1.0 version, including data editor
extend the data model as needed
documentation: best practices, type thesaurus, property hierarchies