=Paper=
{{Paper
|id=Vol-2230/paper_04
|storemode=property
|title=Spatio-Temporal Reasoning in CIDOC CRM: An Hybrid Ontology with GeoSPARQL and OWL-Time
|pdfUrl=https://ceur-ws.org/Vol-2230/paper_04.pdf
|volume=Vol-2230
|authors=Gilles-Antoine Nys,Muriel Van Ruymbeke ,Roland Billen
}}
==Spatio-Temporal Reasoning in CIDOC CRM: An Hybrid Ontology with GeoSPARQL and OWL-Time==
https://ceur-ws.org/Vol-2230/paper_04.pdf
Spatio-Temporal Reasoning in CIDOC CRM: An
Hybrid Ontology with GeoSPARQL and
OWL-Time
Gilles-Antoine Nys
Geomatics Unit, ULiège, Quartier Agora B5a 4020 Liège, Belgium
ganys@uliege.be
Muriel Van Ruymbeke
Geomatics Unit, ULiège, Quartier Agora B5a 4020 Liège, Belgium
mvanruymbeke@uliege.be
Roland Billen
Geomatics Unit, ULiège, Quartier Agora B5a 4020 Liège, Belgium
rbillen@uliege.be
Abstract
Semantic description of cultural heritage information is already widely structured through CIDOC
CRM and its different extensions. This shared understanding of cultural heritage information
has already proved its usefulness. Until now, despite its spatial and temporal data management
proposition, lack standardization limited the possibilities in terms of reasoning and workabil-
ity. This paper proposes to increase the potentiality offered by the current scheme by including
GeoSPARQL and OWL-Time in the framework. The result, as hybrid ontology, allows concur-
rent spatial and temporal handling. These are used to provide a near-full data management for
complex spatio-temporal reasoning and querying through SPARQL queries. Example queries
depicting the strength of the approach and allowing knowledge discovery in huge archaeological
datasets illustrate its benefits.
2012 ACM Subject Classification Information systems → Ontologies
Keywords and phrases CIDOC CRM, cultural heritage, spatio-temporal reasoning, hybrid on-
tologies
Digital Object Identifier 10.4230/LIPIcs.COARCH.2018.
1 Introduction
Since several years, CIDOC CRM [14] and its extensions are regularly used to model
archaeological data. We recently presented an extension proposal to allow cultural heritage
knowledge semantic modelling, taking care of data imperfection [25]. In this paper, we
describe the way we link semantic content with spatial and temporal data using standardized
formalization. Indeed, CIDOC CRM and compatible extensions offers several possibilities
to store temporal and spatial information. These propositions lack standardization, and
© Gilles-Antoine Nys, Muriel Van Ruymbeke and Roland Billen;
2nd Workshop On Computing Techniques For Spatio-Temporal Data in Archaeology And Cultural Heritage.
Editors: A. Belussi, R. Billen, P. Hallot, S. Migliorini
37
Spatio-Temporal Reasoning in CIDOC CRM
properties are not yet workable in computation algorithms. Consequently, there is no
possibility to implement spatio-temporal queries.
To encounter this issue, we seized the opportunity given by an extension of CIDOC CRM:
CRMgeo [13]. This module, providing links with GeoSPARQL [18] vocabulary for representing
geospatial data, handles spatial content. About time, we opted for OWL-Time vocabulary [8]
because of the non existence of management of temporal data in GeoSPARQL (see section
3.2).
Our paper will be organized as following: after a short presentation of the ontological
context, we describe the way we articulate spatial and temporal classes and properties in
the terminology of our formal ontology (Terminological box - TBox). After that we explain
how we made the spatial and temporal properties workable combining GeoSPARQL and
OWL-Time in an hybrid ontology. We will go on with the description of the instantiation
of the assertion set (Assertional box – ABox). Finally, we finish by illustrating all these
considerations giving three examples of complex queries run on our knowledge base structured
around the proposed formal ontology.
2 Ontologies background
Thinking process about definition and description of the concepts used in cultural heritage
domain began in the early nineties. Museum professionals took charge of these problematic
under the aegis of ICOM-CIDOC (International Council of Museums – International Com-
mittee on Documentation). At that moment, the main goal was to create a common and
interoperable framework for IT developments dedicated to museum activities.
A first version of the CIDOC Conceptual Reference Model was published in 1998 [9]. In
2006, it became an official standard (ISO 21127:2006). After that, the revised ISO standard
(ISO 21127:2014) provided an update and is available since 2014. The current version [14]
was published in early 2018.
Over the years, CIDOC CRM was deeply transformed and improved. It was adapted
to match with Semantic Web standards and it was expanded to span the entire field of
cultural heritage documentation. This includes archaeology, architecture, intangible heritage
and so on (examples taken of [6], [23], [15], [16], [17]). Moreover, compatible models and
collaborations have fleshed it out in specific aspects. It is notably the case: CRMsci for
Scientific Observation Model [11], CRMinf for Argumentation Model [23], CRMarchaeo for
Excavation Model [10], CRMba for Archaelogical Buildings [20], CRMgeo for Spatio-temporal
Model [13] and FRBRoo for Functional Requirements for Bibliographic Records [5].
Recently, we proposed an extension dedicated to store fuzzy, incomplete, incoherent and
imprecise data: EPA (Expansion Proposal A) [25]. This proposal relies on principle of
separation between phenomenal and descriptive worlds defined in CRMgeo. In this approach,
spatial and temporal data is considered as information given about real chronology and
localization of phenomenal objects. After having tested and validated our extension with
semantic content, we turned to testing it with geometrical and chronological content.
From a computer science point of view, terminological box (TBox) [3] structures the con-
ceptualization in a specific domain within a graph structure and controlled vocabularies.
CIDOC CRM creators proposed therefore several possibilities to store spatial and temporal
38
G.-A. Nys, M. Van Ruymbeke and R. Billen
information related to cultural heritage objects [17]. The illustration of facts, TBox-compliant
statements, populates the graph: it is the assertional box (ABox). TBox concepts and ABox
facts statements constitute a knowledge base (see Figure 1).
Figure 1 Generic structure of a Knowledge Base
3 Terminological box - TBox
CIDOC CRM provides a TBox which defines cultural heritage concepts and describes their
relationships. Besides CIDOC spatial classes (E53 Place, E44 Dimension, E47 Spatial
coordinates and E94 Space Primitive), the model offers properties which fulfil most common
topological spatial relations (Dimensionally Extended nine-Intersection Model (DE-9IM) [12]
[7], Region Connection Calculus (RCC8) [19]). Some temporal classes are also provided
(E49 Time Appellation, E50 Date, E52 Timespan). Temporal properties, range from P114 to
120, and their inverses overlay Allen’s intervals [1] [2] are also part of the proposition. In
addition, properties from P173 to P185 allow dealing with relations between time intervals
with fuzzy boundaries. Finally, CIDOC defines class E92 SpaceTime Volume that designates
four dimensional points sets and has temporal (CIDOC:P160 ) and spatial (CIDOC:P161 )
projections.
Besides this, the CRMgeo extension provides spatial and temporal classes and properties
dedicated to formulate declarative information. It also provides links with GeoSPARQL [18].
Indeed, these links with the OGC GeoSPARQL standard are necessary " . . . to make use of
the conceptualization and formal definitions that have been developed in the Geoinformation
community . . . " [13]. The same remark could be held true in regard to time information.
However, CIDOC CRM provides no link to widely used standard like, for instance, OGC
OWL-Time [8]. It is important to note that CRMgeo provides no link neither with temporal
ontology.
Regarding the use of data types and data properties specifically developed for temporal
information, CIDOC CRM offers the possibility to implement individuals type of E50 Date.
Data types, as xsd:gYear, that has a more frequent use in cultural domain, are not yet
supported. Currently, in CIDOC-CRM, date types need to register (and thus, to know) the
day, the month and the year. Those precisions are rarely present in archaeological data. On
another hand, data properties targeting these data types come from CIDOC CRM:E52 Time
Span. This statement affects the domain of classes that need to be strictly subclasses of
E52 entities. At least, for spatial data types, geo:gmlLiteral and geo:wktLiteral cannot be
39
C OA R C H 2 0 1 8
Spatio-Temporal Reasoning in CIDOC CRM
specifically recognized in CIDOC CRM [17] and CRMgeo therefore encourages the use of
GeoSPARQL to this end.
To take advantage of data implemented into the knowledge base, and to be able to run
queries or to infer relations, it is necessary, as explained in the spatial representation section
3.1, to have implemented rules and/or reasoning axioms. Such rules do not exist in early
stages of CIDOC CRM or in its spatial extension CRMgeo [17]. To formalize these rules,
we transcribe logical and topological statements in Semantic Web Rule Language (SWRL).
Description logic results ensue then from the asserted rules. For this reason, we choose to use
GeoSPARQL and OWL-Time besides CIDOC CRM respectively for storing geometrical and
temporal information and to take advantage of their standardized formalization. Following
sections explain the different pros and cons to take into account in SWRL.
Commonly, working with GeoSPARQL supposes to structure spatial assertion of geometries
as: geo:Feature geo:hasgeom geo:Geometry [18]. Some may consider time as a graduated line
but GeoSPARQL imposes to formalise geometries in WKT or GML, in which graduation
are not supported. OWL-Time provides approximately the same schema with property
owl:Thing time:hastime time:TemporalEntity, which ". . . supports the association of temporal
information with any temporal entity, such as an activity or event, or other entity. . . and
provides a standard way to attach time information to things, which may be used directly in
applications if suitable, or specialized if needed" [8]. This OWL-Time property coming from
any domain allows easily linking. A contrario, it is not the case with GeoSPARQL where
geo:hasGeometry relation must have a geo:Feature or one of its subclasses as subject. As we
do not have "feature" in such, we added another way to link our data with their geometry:
geo:Geometry are defined as topclass of SP5 Geometric Place Expression. Accordingly, SP5
Place Expression can be geo:Point, geo:Polygon . . . These entities are linked to correspondent
instances of class SP6 Declarative Place, the "features", with the existing property Q10 defines
place. These considerations are depicted in Figure 2 where EPA (Expansion Proposal A) is
an extension dedicated to store fuzzy, incomplete, incoherent and imprecise data [25].
On another hand, instead of using time:hasTime property between SP10 Declarative Time
Span and SP14 Time Expression, we used the existing and already implemented property
Q14 defines time. We also created an equivalence between SP14 Time Expression and
time:TemporalEntity. This equivalence allowed us to make SP14 Time Expression instances
also instances of time:Instant or time:Interval. Actually owl:sameAs relation is mandatory
between the considered individuals.
These two mappings bring here the notion of hybrid approach: different top-level ontologies
are used to define common semantic concepts. Because of the hierarchy and owl:equivalentTo
relations, this approach is different from multiples ontologies, where ontologies are used in
a common application but without any merging. Ontologies associations are strong and
semantic content is widely consolidated.
3.1 Spatial representation
Spatiality is an aspect of the data that is difficult to represent and store. Geospatial topology
studies the spatial relationships between connecting or adjacent features (points, polylines
and polygons). These features and their compositions are so called geometries within the
context of databases. In order to handle spatial representation of the real world, two solutions
are proposed: SOWL and GeoSPARQL.
40
G.-A. Nys, M. Van Ruymbeke and R. Billen
Figure 2 Semantic Expression context
A first example is the approach proposed by SOWL [4], where spatial relations are especially
defined using a compass, a cone-based direction representation, and RCC8 relations between
entities [19]. Composition tables of these relations can then be translated into rules for
reasoning in ontologies.
Composition tables are simple configuration that defines elements as made of elements of
the same type. Composition is the result of higher-level rules. For instance, if an Object A
contains an Object B and the Object B equals a third Object C, therefore, Object A contains
Object C. The composition of all the relations combinations and their results are stored in a
table: the composition table. These permit the discovery of knowledge based on asserted
relations. This way, relations between concepts can be set but they are not set on objects
or their representations but between relations themselves: those entities which are linked
are only concepts related to the real objects and do not refer to any proper coordinate or
location.
Although topological relations between geometries are indeed well defined and documented
in GeoSPARQL (DE-9IM [12] , RCC8 . . . ), these are passive. By "passive", we consider here
the fact that these relations are not workable by algebraic or logical operations. The semantic
content of relations, mostly data type properties, is not workable within the ontology: it is
not possible to simply add, multiply, operate . . . their values. Just as it is not possible in
SOWL. They need to be processed by other external tools to permit arithmetic, logical or,
in a greater dimension, topological computations.
To handle this, frameworks provide plugins, such as GraphDB Java1 , that implement built-in
functions for topological and spatial computations in SPARQL queries and spatial indexes.
These functions are approved by the OGC Naming Authority and accordingly widely used.
1
Official documentation : http://graphdb.ontotext.com/documentation/standard/
41
C OA R C H 2 0 1 8
Spatio-Temporal Reasoning in CIDOC CRM
Thanks to these algorithms, it is possible to compute geometries in a effective way. Topological
computations constitute big challenges in databases because of their time-consuming and
complexity requirements.
Indexing data following Lucene Apache Spatial2 indexation methods and extracting them
from the graph database, 2D Euclidean/Cartesian geometries can thus be processed through
distance and other spatial related math calculations. Lucene only managed WKT-serialised
data, which is supported by GeoSPARQL, and improve performances on shapes search.
As many Triple Stores, GraphDB provides both the predicate-object-subject (POS) index
and the predicate-subject-object (PSO) index for triples management. Therefore, because
of the use of connectors to these external operations, topological reasoning is achievable.
Disadvantages of the method: it needs a complete framework: SPARQL Endpoint, connectors
and functions, such as GraphDB provides them. Moreover, the processed elements need to
be expressed in a common and well-described spatial reference system to guarantee results
consistency.
Figure 3 9-Intersection Model
In our study, the choice is made to use second solution GeoSPARQL, defining all data following
the Well-Know Text standard (WKT), one of the two standards currently supported by
GeoSPARQL. The spatial reference system is set as Belgian Lambert 72. Those data are
simply defining the concepts and no topological relations are stored in the database. An
example of spatial SPARQL query is provided and explained in the section 5 using the
DE-9IM built-in functions, see Figure 3.
3.2 Temporal representation
As it is explained for spatial reasoning, complex reasoning often need external tools to operate
data: logical reasoner, built-ins functions ... In our study, spatial information is handled
with external plugins. A contrario, temporal queries are set up with Semantic Web Rule
Language (SWRL). This methodology is a bit different of the previous one because rules
2
Official website : https://lucene.apache.org/
42
G.-A. Nys, M. Van Ruymbeke and R. Billen
are formalised within the ontology file but still need a reasoner to be expressive. Pellet [22]
is chosen because of its support of SWRL built-in functions. So that, after reasoning, the
inferred model consolidates the triples based on the rules. The database can then be updated
and avoid further computations or complex queries.
As a reminder, two solutions are proposed in the context of temporal representation: OWL-
Time, OGC standard, and SOWL, which introduces SWRL inferred temporal relationships
between entities based on OWL-Time definitions.
Defined in OWL-Time, Allen’s relationships (see Figure 4) can be used as conditions part in
SWRL rules bodies and heads. Differently from the temporal data management of SOWL
proposition [4], no composition table is used to build relations on previously asserted relations.
In our study, Allen’s relationships are results of reasoning and logical computations on dates.
Moreover, this proposition makes the links between different temporal entities: intervals
(time span between two dates) and instants (a single date). This permit links between
different classes and levels in the taxonomy.
Because of this bottom-up approach, the knowledge discovery is considered as wider. One can
so discover complex knowledge, for instance relations between intervals from their constituting
dates. The former SOWL proposition, which is a top-down approach, decompose the asserted
definitions. In a knowledge discovery point of view, it is much better to discover knowledge
from data that could be automatically generated than decompose a complex human-made
dataset. Possibilities are now open.
Figure 4 Allen’s temporal relationships
About the level of granularity considered in this study, the simplest constituting elements
of time is the year. These are so called Instant and refer to the time:Instant. At least two
time:Instant constitute an interval (time:Interval). Just like spatial geometries, temporal
entities are not workable but needs to be decomposed. Each temporal entity is defined by
datatype properties. These properties store year, month, time stamp . . . About the time
granularity, only the inXSDgYear relation, which provides the Gregorian year format of the
concept, processed to prove the concept. Because of this constructing relation, SWRL rules
43
C OA R C H 2 0 1 8
Spatio-Temporal Reasoning in CIDOC CRM
are divided in two main sets: top rules, which are based on instants, and Allen’s relations
based rules, which are based on the top rules.
Top rules are structured around time:Instant and a basic inequality between two of them.
Time is nothing more than an ordered one-dimension vector of values, which are separated
in equal intervals. Therefore, it is possible to determine if one of the value is greater or less
than another one. This rule simply expresses this statement and defines the time:before
relation as a result of two instants when the former is less than the later.
Listing 1 Transcription of before relation rule
inXSDgYear(?xInstant, ?xXSD) ^ inXSDgYear(?yInstant, ?yXSD) ^ swrlb:
lessThan(?xXSD, ?yXSD) -> before(?xInstant, ?yInstant)
The inverse rule, time:after, is already defined in the initial ontology OWL-Time. A second
rule, which expresses equality between two instants, results in an owl:sameAs relation. This
relation defines that, indeed, both the individuals are two names for a same concept.
Allen’s relations based rules are structured on top rules and their results. OWL-Time provides
passive semantic definitions. All basic relations and their corollary are written and tested
in the scope of this research. However only one relation is depicted and explained in this
paper:
Semantic definition of time:intervalBefore relation from OWL-Time :
I Theorem 1. If a proper interval T1 is intervalBefore another proper interval T2, then the
end of T1 is before the beginning of T2.
Listing 2 Transcription of intervalBefore corollary rule
ProperInterval(?T1) ^ ProperInterval(?T2) ^ hasEnd(?T1, ? T1End) ^
hasBeginning(?T2, ?T2Begin) ^ before(?T1End, ?T2Begin) ->
intervalBefore(?T1, ?T2)
It is important here to pay attention to the fact that time:before and time:intervalBefore
are two different relations with their proper domains and ranges. The former expresses
association between two time:Instant and the second two time:ProperInterval, a hierarchy
subclass of time:Interval.
One relation is set to link both time:Instant and time:Interval: time:inside. It specifies that
an instant is strictly included in an interval. The equality with one of the interval limits
results in the previous owl:sameAs definition.
Listing 3 Transcription of inside relation rule
time:Interval(?i) ^ time:hasBeginning(?i, ?iB) ^ time:hasEnd(?i, ?iE) ^
time:Instant(?m) ^ time:after(?m, ?iB) ^ time:before(?m, ?iE) -> time:
inside(?i, ?m)
Important advantage of this methodology is that all the rules are computed only one time. It is
not an incremental process that involves many steps or complex configuration. The influence
of each relation, class or individual is therefore taken into count in all sub-computations.
Possible drawback is the computation time needed to achieve a result. An example of
temporal SPARQL query is provided and explained in section 5 using the Allen’s built-in
relations.
44
G.-A. Nys, M. Van Ruymbeke and R. Billen
4 Assertional box
As explained above, geometries instantiation is rather simple: instances of geo:Geometry
are subclasses of CRMgeo:SP5 Geometric Place Expression. Those are then defined by a
data type property geo:asWKT that stores the geometry as a geo:WKTLiteral (see Figure
5).
Figure 5 Semantic Expression context
To instantiate temporal data, thanks to the equivalence between CRMgeo:SP14 Time Ex-
pression and time:TemporalEntity, instances of CRMgeo:SP14 Time Expression are also
time:Instant or time:Interval (see Figure 5). Since we first had to choose the adequate granu-
larity, where we opted for "year", our instantiated instants are Gregorian years. Commonly,
intervals are constituted by a beginning (an instant time:hasBeginning) and an end (another
instant time:hasEnd), but it is also possible to make them begin with a time:DateTimeInterval
(a day, a month, a year, . . . ). Nota bene, this is the way that PeriodO [21] collection has
chosen to implement its intervals’ starts and ends.
As explained in OWL-Time ontology, seven properties and their inverse provide alternative
ways to describe the temporal relation between two intervals. To store an instant, we choose
time:inXSDgYear which was the simplest way to allow our temporal reasoning rules to
operate.
5 Architecture and spatio-temporal queries
Previous sections was dedicated to theoretical and structural needs to store and/or compute
spatial and temporal data in CIDOC. Proposition on theoretical and assertional boxes
45
C OA R C H 2 0 1 8
Spatio-Temporal Reasoning in CIDOC CRM
were defined. This section illustrates possibilities now offered by our architecture especially
through complex SPARQL queries.
Figure 6 System architecture
The knowledge base is a common GraphDB system architecture (see Figure 6). Temporal
reasoning is performed using the integrated reasoner of GraphDB and total materialization
assumption (inferences are computed after every modification to the Knowledge Base).
GraphDB provides a SPARQL Endpoint with support of GeoSPARQL for querying.
For instance, topological reasoning is also possible to determine which elements are defined
by a geo:Geometry, a WKT point, which is contained within a study zone, that is also defined
by a geo:Geometry, a WKT multipolygon. For example:
Listing 4 Which other objects are in Wallonia?
PREFIX geosparql:
PREFIX geof:
PREFIX CRMGeo:
select ?DeclarativePlace where {
:Wallonia_geometry CRMGeo:Q10_defines_place :Wallonia .
:Wallonia_geometry geosparql:asWKT ?WalWKT .
?Geometry CRMGeo:Q10_defines_place ?DeclarativePlace .
?Geometry geosparql:asWKT ?GeomWKT .
FILTER(geof:sfContains(?WalWKT, ?GeomWKT)) .
}
Temporal queries are possible over date time but also on date intervals. The different types
of relations (instant/instant, instant/interval and interval/interval) may lead to knowledge
discovery. Here is an example of temporal query:
Listing 5 What are the intervals that end after 750 and do not have a known beginning date?
PREFIX time:
PREFIX xsd:
SELECT * WHERE {
46
G.-A. Nys, M. Van Ruymbeke and R. Billen
?interval time:hasEnd ?end .
?end time:inXSDgYear ?xsdE .
FILTER(?xsdE > "0750"^^xsd:gYear) .
FILTER ( !EXISTS{ ?interval time:hasBeginning ?beginning })
}
These two query examples can be merged into a complex spatio-temporal query. The different
aspects, semantic, temporal and spatial, of the query are split here to keep consistency in
the reading.
Listing 6 What are the semantic expression that speaks about an entity that existed after 1500
in Wallonia?
PREFIX MVR:
PREFIX geosparql:
PREFIX geof:
PREFIX CRM:
PREFIX CRMGeo:
PREFIX time:
SELECT ?SemanticExpression ?DeclarativePlace WHERE {
?TimeExpression CRM:P67_refers_to ?SemanticExpression .
?Geometry CRM:P67_refers_to ?SemanticExpression .
?TimeExpression time:hasEnd ?end .
?end time:inXSDgYear ?xsdE .
FILTER(?xsdE > "1500"^^xsd:gYear) .
:Wallonia_geometry CRMGeo:Q10_defines_place :Wallonia .q<
:Wallonia_geometry geosparql:asWKT ?WalWKT .
?Geometry CRMGeo:Q10_defines_place ?DeclarativePlace .
?Geometry geosparql:asWKT ?GeomWKT .
FILTER(geof:sfContains(?WalWKT, ?GeomWKT)) .
}
The computation query needed at most 0.2 seconds on a GraphDB triples store (Free Version),
which implements 26000 triples and is hosted on HDD. SSD will be much less computational
time.
Such queries also make the comparison possible between different semantic expressions. One
of the extensions of this paper will automatise the identification of conflicting declarations.
Declarations made from heterogeneous sources may lead to inconsistency in the knowledge
base and therefore, errors explanations will help to find antagonist discourse [24]. Are people
speaking of the same historical elements? Do people have the same conception of a real-world
entity?
47
C OA R C H 2 0 1 8
Spatio-Temporal Reasoning in CIDOC CRM
6 Conclusion and future work
Cultural heritage information is a field of study since several years. CIDOC CRM defines many
extensions to structure information for scientific observation, argumentation, excavation...
While spatio-temporal reasoning is at the centre of archaeologists’ lifework, its workability
in information management, in an automatic way, is not yet supported. GeoSPARQL and
OWL-Time fill an important gap. Applications of such a tool can be depicted in all areas
of their profession: museums, libraries, archives ... The proposed hybrid ontology allows
supporting their efforts and therefore facilitates them.
Knowledge discovery limits are pushed a little further. Archaeological data management is
simplified. Machine learning algorithms now have a well-defined structure to build semantic
applications that involve spatio-temporal reasoning. Linking such engine with a graph
database as DBPedia or Wikidata opens a new horizon.
Future work will, on the basis of the suggested mapping, build consistency analysis and
errors detection from heterogeneous sources: concurrent declarative discourse, antagonistic
interpretative sequence...
Acknowledgements. The authors would like to thank the anonymous reviewers for their
valuable comments and suggestions to improve the quality of the paper.
References
1 J. F. Allen. Towards a general theory of action and time. Artificial Intelligence, 23(2):123–
154, July 1984. doi:10.1016/0004-3702(84)90008-0.
2 J. F. Allen. Time and time again: The many ways to represent time. International Journal
of Intelligent Systems, 6(4):341–355, July 1991. doi:10.1002/int.4550060403.
3 Franz Baader, Diego Calvanese, Deborah L. McGuinness, Daniele Nardi, and Peter F. Patel-
Schneider. The Description Logic Handbook: Theory, Implementation and Applications.
Cambridge University Press, New York, NY, USA, 2nd edition, 2010.
4 S. Batsakis and E. G. M. Petrakis. SOWL: A Framework for Handling Spatio-temporal
Information in OWL 2.0. In Rule-Based Reasoning, Programming, and Applications, Lec-
ture Notes in Computer Science, pages 242–249. Springer, Berlin, Heidelberg, July 2011.
doi:10.1007/978-3-642-22546-8_19.
5 C. Bekiari, M. Doerr, P. Le Boeuf, and P. Riva. FRBR object - oriented definition and
mapping from FRBRer, FRAD and FRSAD Current version (version 3). Technical report,
September 2017.
6 C. Binding, K. May, and D. Tudhope. Semantic Interoperability in Archaeological Data-
sets: Data Mapping and Extraction Via the CIDOC CRM. In B. Christensen-Dalsgaard,
D. Castelli, Bolette Ammitzbøll J., and J. Lippincott, editors, Research and Advanced
Technology for Digital Libraries, volume 5173, pages 280–290. Springer Berlin Heidelberg,
Berlin, Heidelberg, 2008. doi:10.1007/978-3-540-87599-4_30.
7 E. Clementini, P. Di Felice, and P. van Oosterom. A small set of formal topological rela-
tionships suitable for end-user interaction. Advances in Spatial databases LNCS 692, pages
277–295, 1993.
48
G.-A. Nys, M. Van Ruymbeke and R. Billen
8 S. Cox and C. Little. Time Ontology in OWL. Technical report, October 2017.
9 N. Croft, I. Dionissadou, M. Doerr, and P. Reed. CIDOC - Conceptual Reference Model -
Information Groups. Technical Report version 1, September 1998.
10 M. Doerr, A. Felicetti, S. Hermon, G. Hiebel, A. Kritsotaki, A. Masur, K. May, P. Ronzino,
W. Schmidle, M. Theodoridou, D. Tsiafaki, and E. Christaki. Definition of the CRMarchaeo.
An extension of CIDOC CRM to support the archaeological process. version 1.4.5 April
2018. Technical report, April 2018.
11 M. Doerr, A. Kritsotaki, Y. Rousakis, G. Hiebel, and M. Theodoridou. CRMsci: Scientific
observation model. Definition of the CRMsci. An extension of CIDOC-CRM to support
scientific observation. proposal for approval by CIDOC CRM-SIG. Version 1.2.5 September
2017. Technical report, May 2018.
12 M. Egenhofer and R. Franzosa. Point-set topological spatial relations. International Journal
of Geographical Information Systems, 5(2):161–174, 1991.
13 G. Hiebel, M. Doerr, Ø. Eide, and M. Theodoridou. CRMgeo: a Spatiotemporal Model.
An Extension of CIDOC-CRM to link the CIDOC CRM to GeoSPARQL through a Spati-
otemporal Refinement. Proposal for approval by CIDOC CRM-SIG Version 1.2. September
2015. Technical report, September 2015.
14 P. Le Boeuf, M. Doerr, C. E. Ore, and St. Stead. Definition of the CIDOC Conceptual
Reference Model. Produced by the ICOM/CIDOC Documentation Standards Group, Con-
tinued by the CIDOC CRM Special Interest Group. Version 6.2.3 Mai 2018. Technical
report, May 2018.
15 E. Le Goff, O. Marlet, X. Rodier, S. Curet, and P. Husi. Interoperability of the ArSol
(Archives du Sol) Database based on the CIDOC-CRM Ontology. In Proceedings of the 42nd
Annual Conference on Computer Applications and Quantitative Methods in Archaeology
CAA 2014 - 21st Century Archaeology, pages 179 – 186, Paris, 2015. Giligny F., Djindjian
F., Costa L., Moscati P., Robert S.
16 O. Marlet, S. Curet, X. Rodier, and B. Bouchou-Markhoff. Using CIDOC CRM for Dy-
namically Querying ArSol, a Relational Database, from the Semantic Web. In Proceedings
of the 43rd annual conference on computer applications and quantitative methods in archae-
ology. CAA2015 - Keep the Revolution going, pages 241 – 249, Sienne, 2016. S. Campana,
R. Scopigno, G. Carpentiero, M. Cirillo.
17 S. Migliorini and P. Grossi. Towards the Extraction of Semantics from Incomplete Ar-
chaeological Records. In Proceedings of Workshops and Posters at the 13th International
Conference on Spatial Information Theory (COSIT 2017), Lecture Notes in Geoinforma-
tion and Cartography, pages 349–358. Springer, Cham, September 2017. doi:10.1007/
978-3-319-63946-8_52.
18 M. Perry and J. Herring. GeoSPARQL - A Geographic Query Language for RDF Data |
OGC, September 2012.
19 D. A. Randell, Z. Cui, and A. G. Cohn. A spatial logic based on regions and connection.
Proc. 3rd Int. Conf. on Knowledge Representation and Reasoning, page 165–176, 1992.
20 P. Ronzino, F. Niccolucci, A. Felicetti, and M. Doerr. Definition of the CRMba. An ex-
tension of CIDOC CRM to support buildings archaeology documentation. Proposal for
approval by CIDOC CRM-SIG, Version 1.4, April 2016. Technical report, 2016.
49
C OA R C H 2 0 1 8
Spatio-Temporal Reasoning in CIDOC CRM
21 Ryan Shaw, Adam Rabinowitz, Patrick Golden, and Eric Kansa. A sharing-oriented design
strategy for networked knowledge organization systems. International Journal on Digital
Libraries, 17(1):49–61, March 2016. doi:10.1007/s00799-015-0164-0.
22 E. Sirin, B. Parsia, B. C. Grau, A. Kalyanpur, and Y. Katz. Pellet: A practical OWL-DL
reasoner. Web Semantics: Science, Services and Agents on the World Wide Web, 5(2):51–
53, June 2007. doi:10.1016/j.websem.2007.03.004.
23 S. Stead, D. Oldman, and J. W. Cloud. Exploring Time ans Space in the Annotation of
Museum Catalogues: The Sloane Virtual Exhibition Experience. In Proceedings of the 42nd
Annual Conference on Computer Applications and Quantitative Methods in Archaeology
CAA 2014 - 21st Century Archaeology, pages 221 – 225, Paris, 2015. Giligny F., Djindjian
F., Costa L., Moscati P., Robert S.
24 Mehdi Teymourlouie, Ahmad Zaeri, Mohammadali Nematbakhsh, Matthias Thimm, and
Steffen Staab. Detecting hidden errors in an ontology using contextual knowledge. Expert
Systems with Applications, 95:312–323, April 2018. doi:10.1016/j.eswa.2017.11.034.
25 M. Van Ruymbeke, P. Hallot, G.-A. Nys, and R. Billen. Implementation of multiple inter-
pretation data model concepts in CIDOC CRM and compatible models. Virtual Archaeology
Review. doi:10.4995/var.2018.8884.
50