In this work, we aim to address the limitations of current knowledge graph (KG) approaches in representing and reasoning over dynamic information. In particular, we designed a query language called Temporal Query Language (TQL), which extends SPARQL. The article provides a detailed description of the TQL primitives, clarifying the notion of time assumed in the language, and illustrates an intelligent traffic monitoring application.
Query 1 1 shows a KG excerpt related to traffic objects and their properties. In particular, Line 2 and 3 are asserting that there are two entities of type Car, whereas Line 4 and 5 are describing their speeds (the implicit unit of measure adopted is miles per hour).
The instant at which a given information holds can be easily represented in RDF. As an example, we can state that "car 1 has a speed of 22.0 on July 27, 2021 at 14:21". One way of Query 1: Virtualization query example ... tmo:car_1 rdf:type tmo:Car . tmo:car_2 rdf:type tmo:Car . tmo:car_1 tmo:speed 22.0 . tmo:car_2 tmo:speed 25.0 . ... Query 2: Querying information with time SELECT ?car WHERE { tmo:car_1 rdf:type tmo:Car . tmo:car_1 tmo:associatedWith ?x . ?x tmo:hasSpeed ?speed . ?x tmo:time ?time . FILTER(?speed>22.0) FILTER(?time<"2021-06-27T09:00:00" && ?time>"2021-06-27T21:00:00") } representing this information in RDF is to use reification2 , whereas tmo:associatedWith is just an auxiliary predicate and _:x is called a blank node. Blank nodes are auxiliary nodes for connecting different entities in a KG.
tmo:car_1 tmo:associatedWith _:x . _:x tmo:hasSpeed 22.0 . _:x tmo:time "2021-06-27T14:21:00"^^xsd:dateTime Alternatively, we can use RDF-star 3 and represent the same information as following: <<tmo:car_1 tmo:hasSpeed 22.0>> tmo:time "2021-06-27T14:21:00"^^xsd:dateTime
Regardless of the way we represent temporal information, the question is how to effectively query such information and extract salient dynamic properties from it. When treating time like any other property in RDF, we can use standard query language such as SPARQL. For example, Query 2 asks for all cars with speed greater than 20.0 between 9:00AM to 9:00PM on July 27, 2021. This is a usual interpretation of time. Filters like the one shown in Line 9, allow to query for data that satisfy certain restrictions on the associated time point. In other words, the way we can filter time-associated data is to compare the time points using the usual operators like , <, =, ! = etc. But how to conceptualize and generalize events from time points is left to the human. In case of traffic situations, sometimes we are interested in relating information at different time points and beyond the simple semantics of the aforementioned comparison operators. As an example, suppose we want to check if there is a car idling until a police patrol car arrives at the scene. Such query cannot be formalized in SPARQL, as it would require some sort of a while-loop in order to traverse time-indexed KG triples unless certain conditions are satisfied (appearance of a police vehicle in this example). Query languages like SPARQL lack such a capability. Even though some queries about information over time could be expressed in SPARQL, such queries usually end up to be too complex and prone to error. In this work, our goal is to devise a query language to address these issues. We call the language temporal query language (TQL). TQL basically allows us to query about information while constraining them over time. A detailed description will be provided in upcoming sections. For this language, we take certain assumptions about the notion of time in the target knowledge graph, as described below.
The query language we present in this work takes the following assumptions about the target knowledge graph.
The schema or the ontology part of a given KG graph is assumed to be universal. i.e., we do not allow time to be associated with ontological axioms. In other words, the schema is true at all time points i.e., the axioms or knowledge about a particular domain are not time dependent. Further, we want to avoid computational issues like undecidability of query answering [1].
Temporal Data Not all data need to be temporal. But the parts of the data with temporal information need to be associated with some notion of time. In the previous section, we have seen example how a timestamp can be associated to a triple using the usual datatype xsd:dateTime. Nevertheless, this is not a hard requirement in our case. All we need is some way of ordering information. Further, we need this ordering to be linear i.e., give a time point π in this order, there is at most one successor π β² time point of π. A KG π’ thus can be perceived as a union of π’ π , π’ π 1 , β¦ , π’ π π where π’ π represents the schema part of π’ along with the triples which are not associated to some time and hence contain no temporal information, whereas πΊ π π represents the set of triples which are associated with time point π π for 1 β€ π β€ π. Without loss of generality, we associate time to a set of triples onward.
In this work, we apply TQL to improve the analysis of traffic video feeds: the goal is to infer complex behavior from object classes, positions, trajectories recognized by state-of-the-art machine vision systems running on top of stationary cameras. A traffic monitoring ontology has been created, to represent the semantic content or scene of each video frame, and to generate a knowledge graph with the annotated data.
Videos collected from different cameras are analyzed frame by frame. For each frame we get information about the objects and their characteristics in it. We describe this information in a KG using different classes and relationships. Note that each frame is recorded at a particular Query 3: Triples describing an observation about a car in a frame tmo:atomicScene1 tmo:composedOf tmo:position1. tso:TimeStamp "2021-03-03T07:30:44"^^xsd:dateTime; tmo:position1 rdf:type tso:Position; tmo::hasParticipant tmo:car1; tmo::hasProperty ?speedProperty1. ?speedProperty1 rdf:type tso:Speed; tmo:hasValue 20.0.
time point. For our use-case, we consider these time points when dealing with dynamic aspect of the domain. The notion of time will be explained in Section 5. Figure 1 shows a snippet of the traffic monotoring ontology (TMO). We next go through the classes and relations in TMO.
The class AtomicScene is a composition of the class Observation. The elements of Observation represent different types of observations made in a given frame. In our case, the only observations we have are of type Position, which describes a traffic object using some spatial coordinates 4 . However, as an example, if there is a car observed in a frame, triples describing all the relevant information about the car are shown in Query 3. As shown on line 4, Position (Observation) is used to accumulate information about a traffic object (tmo:car1 in this case). What we are describing is that in the given frame we make an observation (of type Position) in which we have a participant (tmo:car1), a property (tmo:Speed) for which we have a value of 20.0. Finally, note that that Line 3 associates a single time point to tmo:atomicScene1. We could actually associate the same time to every triple in Query 3. But since all the triples carry the same time point, we can group them using an instance of AtomicScene.
ComplexScene A complex scene is a composition of atomic scenes. Which atomic scenes constitute a complex scene depends on the pertinent interpretations derived by the use case (see Event) or external constraints. Event Previously we mentioned that complex scenes are composition of atomic scenes. We do not enforce any condition on which atomic scene can be composed into a complex scene. In practice however, we are not interested in random aggregates of atomic scenes. To this end, we use the class Event to represent scenes in a meaningful manner. Events thus can be seen as semantic tags we put on scenes (atomic or complex). Figure 3.1 outlines this idea. As an example, a scene can be interpreted as a congestion in, say, a village, while it can be interpreted as a rush hour in a city. Pictorially, we see in Figure 3.1 the relationship between atomic scenes, complex scenes and events. Different interpretations (events) can be associated to the same complex scene. After presenting an overview of the relevant part of our KG, we next describe the need for a temporal query language. In the next section, we will see why standard querying is not sufficient in use-cases like traffic monitoring where the data is inherently dynamic and thus involves time as an aspect.
In this section, we describe why standard query languages like SPARQL are not sufficient when dealing with data, such as from traffic monitoring domain, which involves dynamic aspects. This will advocate the idea of devising a more expressive query language which we will introduce in Section 5. To this end, we present the following example scenarios. Accelerating car: Suppose we are interested in finding out if π1 βΆ a video (from a traffic camera) contains an accelerating car. For simplicity we imagine that there is only one car (and the same one) in each of the video frames. Suppose there is a video with 20 frames and that these frames are represented as atomic scenes: π΄ 1 , β¦ , π΄ 20 in a KG π’. Let π 1 , β¦ , π 20 be the time point associated with π΄ 1 , β¦ , π΄ 20 respectively in the order π 1 < π 2 < β― < π 19 < π 20 . Note that each atomic scene π΄ π can be represented in π’ in the same fashion as in in Query 3. We, thus, are only interested in the speed property of the position for each of the atomic scenes. The given video is a candidate answer to our query if we observe that the speed of the car is increasing as we go from atomic scene π΄ 1 all the way to π΄ 20 . Retrieving such video from our knoweldge graph can be formalized as a SPARQL query even though it is temporal in nature. All we need to do is to compare the speed corresponding to the position in the atomic scene 5 (frame) at time π π to speed corresponding to the position in the atomic scene at π π+1 where 1 β€ π < 20. That is, we compare ever consecutive pair of scenes for the speed value. Query 4 shows a snippet of such a query. In general, such queries can be very long and non-trivial. As in our example query, we see that we have to get speed for all the 20 atomic scenes.
Note that not all queries dealing with temporal data can be translated into a SPARQL query (or at least to a single SPARQL query). We call the queries that can be translated into some equivalent SPARQL representation, simple temporal queries; we refer to the other queries as complex temporal queries. The next example illustrates the latter type.
Congestion ending in an accident: Suppose we are interested in videos where we encounter traffic congestion ending up in an accident. Let's assume by congestion we mean that the cars are not moving at all for at least 10 time points 6 . Further, we identify an accident if two cars share the same geo-spatial space. In other words, they have overlapping bounding boxes. A video is an answer to this query if (i) there are atomic scenes π π 0 , π π 1 , β¦ π π π with time points π 1 , π 2 , β¦ , π π respectively such that all cars have the same position at least in atomic scenes π π π for 0 β€ π β€ 10, (ii) no two cars have overlapping position in none of the atomic scenes π π π for 0 β€ π β€ 10, and (iii) there is a time point π π with 10 < π β€ π such that there are at least two cars with overlapping positions in the atomic scene π π π . Further, none of the car changes position nor two car's position overlaps in the scenes π π π for 10 < π < π. Note how Condition (i) and (ii) check for a congestion (10 time points) and not happening of an accident. Whereas, Condition (iii) checks for the earliest time point where we encounter an accident. Unlike Condition (i) and (ii), the last condition cannot be translated into a single SPARQL query as we do not know prior how many frames we need to check. This requires some sort of a while-loop which keeps running till the condition is satisfied.
The goal of this work is to answer queries as shown in the above examples. Note that even though the accelerating car example (simple temporal query) can be translated into a SPARQL query, but such queries are large and complex, and thus are prone to error. Next we present a query language which allows expressing simple as well as complex temporal queries.
In this section, we define the formal syntax and semantics for the temporal query language we mentioned in the previous section. We first start with some basic notions.
All the knowledge graphs we consider here are assumed to be OWL based knowledge graphs 7 which roots in Description Logics (DLs) [3]. We now present some preliminary definitions.
A data property assertion triple is a triple of the following form
An object property assertion triple is a triple of the following form
Based on these notions, we next define what we mean by a temporal knowledge graph. Definition 5.2 (Temporal Knowledge Graph). Let π be a non-empty set and < be a strict partial order on π . Further, let π― be a set of triples. Then, a temporal knowledge graph (or TKG in short) based on (π , <) and π― is a knowledge graph if there is a set π of assertional RDF triples with π β π― such that
where π π β π for 1 β€ π β€ π. We represent the knowledge graph by π― (π,<) .
The intuition behind this definition is that the set of all assertional triples in a temporal knowledge graph can be partitioned into subsets π π π based on some order given by <. In practice, we can take π to be a set of xsd:dateTime literals and < is such that π π < π π if π π is before π π for two distinct xsd:dateTime times π π and π π in π . Note that by definition, we do not require π to be a set of xsd:dateTime always. All we need is to have a strict partial order < on π . Hence, π can be set of integers or even strings so far we can establish < amongst its elements 8 . To this end, we define a partial function time βΆ π― β¦ π called the time association function such that for any triple π β π π π we have time(π ) = π π . Definition 5.2 describes our notion of time. In fact, by time we mean just an order as required by < in the definition of the temporal knowledge graphs. We differ with the usual notion of time (or the natural time) represented by xsd:dateTime. Our definition doesn't restrict us to xsd:dateTime only. In fact, (π , <) is the only requirement in our definition i.e., all we need is some way of ordering. At first glance, these requirements seem to be a bit confusing for use-cases in practice. However, a knowledge graph where assertional triples can be grouped based on some order is a temporal knowledge graph according to our definition. We will see later why these requirements suffice when we define temporal operators. From now onward, by time we mean an element from some set on which a strict partial order is defined.
The representation of time can be a part of the temporal knowledge graph itself. To elaborate this, suppose we have a temporal knowledge graph π― (π,<) and π is the subset of all assertional triples in π― with
then the two possible representations of time in a temporal knowledge graph are either associating each triple in π π π is to π π using techniques like reification [4] or grouping all the triples in π π π in a set and the set is associated to π π . Without loss of generality we assume the second representation.
As mentioned in the previous section, we restrict the association of time to class assertions, data property assertions and object property assertions only. This restriction allows us to simplify TQL without compromising its expressivity. Further, we avoid issues with computational decidability, which otherwise would be highly probable when dealing with such languages [5].
Before defining the syntax of TQL, we define some further notions. Here we assume some familiarity with SPARQL query language. We refer the interested reader to [4]. In SPARQL, basic graph patterns (BGPs) are the building blocks of the language. A BGP is an RDF triple where variables are allowed at the position of subject, predicate as well as object. Similar to this, we have the following definitions.
). An assertional basic graph pattern or (ABGP in short) is an assertional RDF triple of one of the following forms:
By definition, every assertional triple is an assertional basic graph pattern (without variables) as well as a standard basic graph pattern. ABGPs simply restricts the occurrence of variables at certain positions compared to the standard ones. Hence, each ABGP can be queried against a knowledge using any SPARQL engine.
). Let πΎ be an ABGP with var(πΎ ) representing the set of all variables occuring in πΎ. Then a solution for πΎ in given a knowledge graph π’ is a partial function π from var(πΎ ) to RDF terms in π’ such that the assertional triple obtained by simultaneously replacing each variable π₯ β var(πΎ ) by π(π₯), can be found in π’ i.e., π(π₯) β π’.
The notion of solutions can be extended to set of AGBPs in an obvious way: for a set of ABGPs Ξ, we say π is a solution for Ξ if and only if π is a solution for each πΎ β Ξ.
Note that as shown in 'accelerating car' example in Section 4, a temporal query checks whether a certain relation holds over time. In other words, we want certain facts to hold when traversing from one time point to another. We call such a requirement as a temporal constraint. Hence, a temporal constraint is a condition that need to be satisfied between sets of ABGPs representing factual information where each set corresponds to a time point. In fact, constraints can be applied to the variables occurring in ABGPs due to the fact that variables can represent different values (RDF terms) in a temporal KG at different time points. Hence, a class ABGP can be constrained at the subject position only whereas data and obejct ABGPs can be constrained at both subject as well as object positions. We will see later how the notion of ABGP solutions can be applied to ABGPs with constrained variable.
In practice, we can have different temporal constraints depending on the required conditions.
Variable constrained under constraint β is a variable which need to satisfy the conditions enforced by π. β(?π₯) represents a variable ?π₯ constrained under β.
Constrained ABGP is an ABGP such that at least one variable is constrained under exactly one constraint. If the variable is constrained under β, we say the ABGP is constrained under β. A constrained ABGP is written as an ABGP except that we write β(π₯) for the constrained variable π₯. For example, the following is a constrained ABGP where ?πππ ππ‘πππ is constrained under rigidity (defined below).
tmo:car_1 tmo:position β(?position).
We define two temporal constraints of interest that we use in this work. To this end, let π― (π,<) be a temporal KG 9 with π― = π’ βͺ π where
and π π β π for 1 β€ π β€ π. Then, Definition 5.5. (Rigidity) The Rigidity constraint is represented by β and requires the values of the variables not to change when moving from one time point to another. Formally, we say rigidity is existentially satisfied for a constrained ABGP π in the temporal knowledge graph π― (π,<) for time π to π β² if and only if there is a solution π for π in π’ βͺ π π and a solution π β² for π in π’ βͺ π π β² such that for each π₯ β var(π ) constrained under rigidity we have that π(π₯) = π β² (π₯). We represent existential rigidity by β πΈ .
We say rigidity is universally satisfied for π in the temporal knowledge graph π― (π,<) for time π to π β² if and only if for every solution π for π in π’ βͺ π π , there is a solution π β² for π in π’ βͺ π π β² such that for each π₯ β var(π ) constrained under rigidity we have that π(π₯) = π β² (π₯). We represent universal rigidity by β π .
Note that rigidity requires both mappings π and π β² to be solutions for π with the additional requirement that the constrained variable (under rigidity) in π is mapped to the same value by both mappings. The intuition behind rigidity constraint is that when moving from time π to π β² , the value for the constrained variable does not change and interprets the triple rigidly for the variables constrained under rigidity. Sometimes we intend to allow for minor changes in the values of variables. We define the so-called likelihood constraint. Note that such a constraint makes sense in case of data property assertional triples as we can enforce likelihood on the values of the data property only. The amount of change for data values can be measured using some threshold function i.e., the satisfaction of likelihood constraint relies on certain threshold. We would like to mention here that the definition of threshold functions as well as threshold values can be defined as per use-case. This adds a great flexibility in controlling change over time.
Definition 5.6 (Likelihood). Let π be a data property ABGPs and let D be the range of the data property in π. In other words, the object position in π is either a variable or a value from D. Further let π₯ β var(π ) be the variable at object position. Let π be a threshold function on D i.e., π βΆ D Γ D β¦ {true, false}. We say likelihood is satisfied for π in π― (π,<) given π for time π to π β² if and only if there is a solution π for π in π’ βͺ π π and a solution π β² for π in π’ βͺ π π β² such that π(π(π₯), π β² (π₯)) = true. In other words, π₯ is mapped to two values, say, π£ 1 and π£ 2 by π and π β² respectively such that π (π£ 1 , π£ 2 ) yields true.
From now onward we assume there is always a given threshold function when we consider constrained ABGP where the variable is constrained under likelihood, unless stated otherwise. Note that the notion of universality and existentiality does not make sense in case of likelihood constrained.
Example of Constrained ABGPs: Consider the following ABGP: π βΆ tmo:car_1 tmo:Speed π(?speed).
Here we suppose that the following threshold function is given for π(?speed)
Let π and π β² be solutions for π in π’ βͺ π π and π’ βͺ π π β² respectively such that π(?speed) = 15 and π β² (?speed) = 18. We thus see that likelihood (with the given threshold function) is satisfied for π in π― (π,<) for π to π β² as both π and π β² are solutions as well as π (18, 17) = true since 18 β 15 = 3 β€ 1.5.
The notion of temporal constraint allows us to enforce certain conditions to be met by solutions when moving over time in a knowledge graph. In other words, temporal constraints are ways to monitor how information in knowledge alters over time. However, temporal operators allow us to traverse over time points. There can be different temporal operators. While temporal constraints enforces conditions that need to be satisfied over time, the temporal operators govern what time points need to be considered when applying these constraints.
Standard temporal logic allows for different temporal operators. We, however, we define two temporal operators namely, N π and U for defining TQL. Definition 5.7 (Syntax of TQL). Let π― (π,<) be a temporal knowledge graph with π― = π’ βͺ π where π = π π 1 βͺ π π 2 βͺ β― βͺ π π π . Let π³ be a set of ABGPs and π³ β be a set of constrained ABGPs. Then, I. any subset of π³ is a temporal query. II. if Ξ β π³, Ξ β π³ βͺ π³ β such that no variable in Ξ is constrained under more than one constraint and Ξ β² is non-empty set with Ξ β² β π³ , then
β’ Ξ N π (Ξ) for π β₯ 1 is a temporal query called N π temporal query.
β’ Ξ.ΞUΞ β² is a temporal query called U query.
β’ ΞN π (Ξ)UΞ β² is a temporal query where π β₯ 1. We call such query as N π U query.
Note how constrained ABGPs are used along with the temporal operators. For simplicity, we restrict to non-recursive occurrences of the temporal operators in temporal queries. Nevertheless, the language can easily be extended to cover more complex queries.
In Definition 5.3, we have mentioned that assertional basic graph patterns (ABGPs) are by very definition basic graph patterns as in SPARQL. Also, in Definition 5.4, we have seen the notion of ABGP solution which again is what we have in standard SPARQL. Note that, similar to SPARQL, a set of ABGPs can be seen as a query. Thus, for a given set of ABGPs Ξ¦ and a knowledge graph π―, a solution for Ξ¦ in π― is simply answer to Ξ¦. Based on this, we next define the notion of TQL query answers. Definition 5.8. Suppose π― (π,<) is a temporal KG with π― = π’ βͺπ where π = π π 1 βͺπ π 2 βͺβ―βͺπ π π and π π β π for 1 β€ π β€ π. Further, Let π³ be a set of ABGPs and π³ β be a set of constrained ABGPs. An answer/solution to π in π― (π,<) is defined as following:
a mapping π from var(π ) to RDF terms is a solution or an answer to π in π― (π,<) if and only if π(π π ) is a match in π― (π,<) for 1 β€ π β€ π. We say π is a solution or an answer for π in π― (π,<) . Note that in this case, we have no constraint nor time to consider as the query is just a set of ABGPs. It, thus can be seen as a SPARQL query.
β’ π = Ξ N π (Ξ) for Ξ β π³, Ξ β π³ βͺ π³ β for π β₯ 1 there are time points π 0 , β¦ π π and mappings π 0 , β¦ , π π such that: π 0 is a solution for Ξ in π’ βͺ π π 0 , π π is a solution for Ξ in π’ βͺ π π π for 0 β€ π β€ π, and the constraints in π β Ξ are satisfied for π in π― (π,<) for π π to π π+1 where 0 β€ π < π.
The solution to π for π is obtained by combining all above π π while replacing in constrained variable π₯ by π₯ (π) i.e., if π₯ is a non-constrained variable in π and π₯ β¦ π π (π₯) is in π π then it is replaced by π₯ (π) β¦ π π (π₯) in π. In simple words, we create copies of the non-constrained variables for each time point.
β’ Ξ.ΞUΞ β² for Ξ β π³, Ξ β π³ βͺ π³ β and a non-emtpy set Ξ β² β π³ there are time points π 0 , π 1 , β¦ and mappings π 0 , π 1 , πππ‘π , and there exists π β₯ 0 such that: π 0 is a solution for Ξ in π’ βͺπ π 0 , π π is a solution for Ξ in π’ βͺπ π π for 0 β€ π < π, each constraint in constrained ABGP π β Ξ is satisfied for π in π― (π,<) for π π to π π+1 for 0 β€ π < π β 1, there is no solution for Ξ β² in π’ βͺ π π π for 0 β€ π < π, and π π is a solution for Ξ β² in π’ βͺ π π π .
β’ ΞN π (Ξ)UΞ β² for Ξ β π³, Ξ β π³ βͺ π³ β and a non-emtpy set Ξ β² β π³ there are time points π 0 , β¦ , π π , π π+1 , β¦ and mappings π 0 , β¦ , π π , π π+1 , β¦ such that: π 0 is a solution for Ξ in π’ βͺ π π 0 , π π is a solution for Ξ in π’ βͺ π π π for 0 β€ π β€ π, the constraints in π β Ξ are satisfied for π in π― (π,<) for π π to π π+1 where 0 β€ π < π, there is a time point π β₯ π such that π π is a solution for Ξ in π’ βͺ π π π for π β€ π < π, the constraints in π β Ξ are satisfied for π in π― (π,<) for π π to π π+1 where π β€ π < π β 1, there is no solution π β² for Ξ β² in π’ βͺ π π π for π β€ π β€ π β 1, and π π is a solution for Ξ β² in π’ βͺ π π π .
Note that the temporal operator N π allows us to iterate over a fix number of time points π and check whether a temporal constraint is satisfied or not. Meanwhile, the temporal operator U checks the validity of a temporal constraint for as long as certain condition is satisfied. In our case, this condition corresponds to the origination of some new facts represented by the set Ξ β² . Let's consider an example of a temporal query from traffic monitoring domain.
We have discussed the benefit of temporal queries in knowledge graphs. We then presented a formal query language for formalizing temporal queries. We called it as Temporal Query Language (TQL). We have precisely defined syntax and semantics of TQL, where we considered different types of temporal queries. We have seen how temporal constraints adds further expressivity to the query language. We have already a first implementation of a query engine for answering temporal queries. A description of the engine, along with a report on experiments and evaluation conducted, is beyond the scope of this paper. In future work, we would like to analyze what other types of temporal queries can be of interest for different use-cases and, in parallel, developing an advanced query editor for TQL.
An Accelerating Car Ending in an Accident Suppose a car encounters an accident if it's bounding box overlaps with that of another car. Then, the query can be formalized as {?scene rdf:type tmo:Scene. β πΈ (?car) rdf:type tmo:Car. ?car tmo:hasSpeed π(?speed).} U {?car tmo:hasPosition ?position. car2 rdf:type tmo:car. ?car2 tmo:hasPosition ?position2. ?position tmo:overlaps ?position2.}
We assume that the threshold function for π(?speed) is as: π (π, π β² ) = true if π β² > π and π (π, π β² ) = true otherwise. Note the likelihood constraint with threshold function π on the variable ?speed makes sure that the value of ?speed increases as we move over time. This way we capture the notion of acceleration for the car. Further, the above query is of the form Ξ.ΞUΞ β² with Ξ = β . Further, β πΈ (?car) constraints the existence of a car over all time points unless there is a time point π where we we find a second car with position of the first car overlapping that of the second one in the knowledge graph π’ βͺ π π .
Incorporating time into RDF has been investigated in prior work [6, 7, 8, 9, 10, 11]. By and large, these studies differ in aspects like treatment of the notion of time and expressivity of the query language. Contributions like [6] extend the idea of TSQL2 [12] in traditional databases to RDF. The treatment of time there is different from the usual notion of time in classical temporal logic like LTL [13]. Nevertheless, works like [11] extends SPARQL with constructs provided in LTL. A thorough comparison of our approach to the state-of-the-art is beyond the scope of this paper. However, the treatment of time in our work exhibits some similarities to the one presented in [6]. What distinguishes TQL is that it considers only one dimension for time, as our definition of temporal KG is based on a linear order (T, <) unlike N-dimensional time π― = π― 1 Γ π― 2 Γ β― Γ π― π in [6, 7], where the focus is ontology versioning. When it comes to our query language, our work is somewhat similar to SPARQL-LTL presented in [11]. However, the focus in [11] when it comes to the notion of time is more on versioning of RDF data. Hence, the defined semantics consider different named graphs where each graph represents one version of the data. As pointed out by the authors, it is not a limitation per se. We believe this is comparable to our definition of temporal knowledge graph (Definition 5.2), where without loss of generality, we assume a set of triples to be associated with a time point.
Besides all similarities to the existing approaches, the notion of temporal constraint, to the best of our knowledge, adds new expressivity to SPARQL extended with the temporal operators. Even though such constraints are translated into SPARQL checks, the succinctness they add to the query language is of great advantage, as it helps to reduce complex queries to simpler and more compact ones (as shown in the examples in the traffic monitoring domain).