Extending the OBDA approach - where multiple data sources are exposed to users via a unified conceptual schema based on description logics - to also cover temporal reasoning has been a long standing goal, with many proposals over the last decades. To the best of our knowledge, these have yet to yield results in the form of systems or prototypes. As part of our ongoing work towards practical applicability, we identify here a number of key problems, which we believe have not been addressed suitably by previous works. Among these is the ability to deal with heterogeneous representations of time, the ability to deal with temporal inconsistencies, either due to missing value samples or conflicting values for a given time point and finally we also seek a suitable query language, where we in particular want compositionality the ability to use the output of queries to form new temporal views on the data. We present here our initial ideas on how to meet these challenges.
Ontology-based data access (OBDA) describes the method of enriching relational databases with semantical reasoning tools developed in the area of Description Logics (DLs). Specifically OBDA allows one to create mappings from various data sources to an ontology, and extend the data via concept and role inclusions, and thus create a “virtual knowledge graph” (VKG) over which queries can be answered. This VKG need not be materialised, as the query can be rewritten to incorporate the richer semantics from the ontology, and this rewritten query can then be run on existing commercial RDBMs. At this point, OBDA is increasingly used in practice, with both open-source and proprietary systems available.
While temporal databases have been the focus of research for a long time [
There have been decades of work on temporal data and ontologies, both for the more
fundamental question of understanding the complexity of temporal DLs [
We will highlight in this paper the following challenges that we have identified, and present our initial ideas on how to tackle them.
• Finding ways of dealing with heterogeneous temporal data representations uniformly. • Exploring the possibility of temporal inconsistencies arising both in the input data and as the result of complex queries, and finding solutions that still enable reliable query answering. • Finding a composable temporal query language, with suitable complexity in the form of, ideally, FO rewritability. We note that expressivity of this query language can be extended via a complex ontology language, to be used by experts, in order to allow users to refer to complex temporal events without the need to understand complicated temporal logics.
In the remainder of the paper we will give more insights into these challenges, and present on-going work on how we are planning to meet them.
Related Work. Bridging temporal reasoning and DLs has been an area of focus for many
years [
Here we highlight the key challenges that we still see as unaddressed in the existing literature and which any practical ontology-based system that allows for rich temporal reasoning on real-world temporal databases must meet.
Heterogeneous temporal data representations. One can identify in the literature diferent views at the data level, both point-based (often also called time-series) and interval-based relations. When looking at schemas involving temporal data, it becomes apparent that even the same database will combine time-series and interval-based views. As such, one needs to identify ways to jointly represent both and have ways to safely translate one representation into another. By “safely” we refer to the ability to identify cases of temporal inconsistency, discussed next. Inconsistency and temporal data. In temporal databases, where facts are enriched via validity periods, we define temporal consistency to refer to the fact that we have a consistent assignment of values in the domain to non-temporal attributes for any time-instant that the temporal data is defined over. We believe that the case of temporal inconsistency will occur quite often in practice, and systems will need robust and transparent ways to manage it. Furthermore, we believe that this difers from the case of inconsistency in the non-temporal case. After all, temporal inconsistency only refers to cases where for a given time-point we have too many choices on values for non-temporal attributes (ambiguity) or none at all (gaps in the data). Temporal inconsistency due to ambiguity can be introduced naturally just by allowing general interval-based temporal relations. Managing temporal inconsistency becomes even more crucial when one also considers the third challenge, namely an expressive temporal query language, with the ability to use queries within other queries. With the ability to create new temporal relations (or views) comes the possibility that these new relations themselves could be temporally inconsistent. Thus, dealing with inconsistency becomes a necessity. In addition to inconsistency due to ambiguity, another issue is “gaps” in the temporal data, due to a low temporal resolution, for example. This too will need to be addressed in settings where queries are expected to return useful answers for any time point, regardless of the temporal resolution of any specific data source.
An expressive, composable temporal query language. Just as with standard relational databases and SQL, we would expect temporal query languages to be able to produce new temporal relations, either point-based or interval-based, out of existing temporal data. In addition, we believe it is necessary to be able to express predicates between time-intervals, as detecting complex patterns on time is necessary for the kind of event detection that is of practical interest in industry. An option that we also need to consider in the OBDA setting is the distinction between ontology and query level. As complex and expressive languages on time might be hard for non-expert users to master, one can delegate this task to the ontology engineer via a complex ontology language, which would then introduce new facts to signify temporal events. Users could then make use of the complex temporal machinery without the need to define it themselves.
We present for each of the challenges a proposal or give some further details.
For the data model, our current idea is to extend the relational setting and explicitly support both time-series relations and interval-based relations. We use attr () and pk () to respectively denote the set of all attributes and the primary key attributes of a relation . We use capital letters to identify attributes in the schema and lowercase letters for values inside a tuple. We assume that the type time is realised as time-stamps.
Definition 1 (Time-series Relation). A time-series relation TS is a relation that has the following property: there must exist exactly one attribute ∈ attr (TS) of type time such that ∈ pk (TS).
Definition 2 (Time-interval Relation). A time-interval relation I is a relation that satisfies the following properties: • There are 1, 2 ∈ attr (I) of type time such that 1, 2 ∈ pk (I). We assume w.l.o.g.
that 1, 2 are the first two attributes of I.
• For every tuple (1, 2, 3, . . . , ) ∈ I, we have that 1 ≤ 2.
With these two representations of time, we already get a number of issues that one needs to address in any working implementation of temporal OBDA systems. The first issue is that of clearly defining when one can safely transform one representation of time into the other one. A second issue (or rather feature we want to have) is the ability to define for a data source methods of making the data denser, for example by means of interpolation on numerical data points to extend the temporal relation.
For the problem of dealing with temporal inconsistency due to ambiguity, we only give here a
simple example showing how inconsistency might be introduced even by the ontology language
or at the query level, in addition to the possibility of being already present in the temporal
database itself. For the purpose of this example, we pick the ontology language proposed by
Brandt et al [
Example 1. Let us assume that our schema contains a relation “Project”, which indicates the available budget for our project at a given time interval. We further assume we are given a concrete database with the relation “Project” containing the tuples as shown in Table 1. Furthermore, consider the following rule in DslD: extend (time, budget ) ←
time is rshift 10(time), Project(time, budget ).
This rule would simply extend every existing interval period, while retaining the budget value for that interval. In Table 1, we also show the tuples obtained after applying this rule. We can see that the resulting relation introduces ambiguity in the form of overlaps between time intervals of tuples that have diferent values for the non-temporal attributes.
Outlook. We plan to continue tackling the challenges we sketched out in this short paper, and ideally realise a first prototype implementation once we have a clearer picture of temporal ontology-based data access. The design of a suitable combination of query language and ontology language, while retaining FO reducibility, is in particular a crucial goal. It requires a balance in order to ensure accessibility for non-expert users at the query level, while also maintaining high expressivity overall.
This work was partially supported by the Wallenberg AI, Autonomous Systems and Software Program (WASP) funded by the Knut and Alice Wallenberg Foundation. It was also partially supported by the Austrian Science Fund (FWF) projects P30360 and P30873, by the Vienna Business Agency’s project CoRec, by the Italian Basic Research (PRIN) project HOPE, and by the Province of Bolzano through the project D2G2.