We research the problem of querying RDF archives. In this setting novel data management challenges emerge in terms of support for time-traversing structured queries. We formalize an extension of SPARQL, called SPARQ-LTL, which incorporates primitives inspired by linear temporal logic. We give formal semantics for SPARQ-LTL and devise query rewriting strategies from SPARQLTL into SPARQL. The usage of SPARQ-LTL allows to gain conciseness and readability when expressing complex temporal queries. We implemented our approach and evaluated query running time and query succinctness.
Research in the field of archiving policies of Linked Open Data (LOD) opens up new
opportunities for the traceability of Semantic Web data over time [
Querying historical data is important in many contexts, from analytic tasks where one needs to understand how knowledge has evolved and updated (e.g., pollution levels in a city), to generic exploratory research, where one is interested in posing queries like “Retrieve the annotations of a gene since the discovery of a particular interaction” or “Find players that are now managing some club they played for”. Typically one can use plain SPARQL to express such queries. However, besides hindering the readability of a query this approach is tedious and error-prone (e.g., one needs to be consistent with variable names). Therefore, a number of proposals came up with extensions of SPARQL both in terms of language primitives and indexing techniques (see Related Work). Despite the plethora of approaches for querying temporal RDF data, we believe that, especially for the case of RDF archives, having a simple approach that neither require to setup complex processing infrastructures nor to learn complex temporal languages can be useful. Therefore, the tenet of this paper is to study how to facilitate querying historical RDF data on existing SPARQL processors.
We formalize a powerful extension of SPARQL called SPARQ–LTL, which allows
to use a variety of temporal operators inspired by Linear Temporal Logics (LTL) [
SPARQ–LTL by Example. We now provide some examples of SPARQ–LTL queries. Example 1. Select footballers who played at least twice for the same club. SELECT ?person WHERE {
EVENTUALLY{ ?person :occupation :football_player . ?person :member_of_team ?club .
NEXT { EVENTUALLY {
?person :member_of_team ?club .
}} } }
The SPARQ–LTL query expressing the example makes usage of the EVENTUALLY and NEXT temporal operators. EVENTUALLY checks that eventually (along the whole time line) one has to be a football player, playing for some club (a binding of the variable ?club). After identifying the timepoint (data version) where the first part of the query has a solution, the usage of NEXT, by moving at the next point in the timeline, checks again the same condition. As an example, M. Hughes played for Manchester United both in 1980-86 and 1988-95. Note that the management of timepoints is completely transparent to the user. We now give another example of SPARQ–LTL along with its translation into SPARQL. We assume each historical data version (e.g., DBpedia dump) to be stored in a separate named graph.
Example 2. Find the name of the coach of the Italian national football team after the sacking of Cesare Prandelli.
SPARQ–LTL SELECT ?n WHERE { PAST { dbp:Italy dbpo:coach dbp:Cesare_Prandelli.
NEXT { dbp:Italy dbpo:coach ?n.
FILTER (?n!=dbp:Cesare_Prandelli) } } }
Translation into SPARQL SELECT ?n WHERE { {GRAPH <http://data/v5> { dbp:Italy dbpo:coach dbp:Cesare_Prandelli.
GRAPH <http://data/v6> { dbp:Italy dbpo:coach ?n.
FILTER(?n != dbp:Cesare_Prandelli)} } } UNION ...... UNION{ GRAPH <http://data//v1> { dbp:Italy dbpo:coach dbp:Cesare_Prandelli.
GRAPH <http://data/v2> { dbp:Italy dbpo:coach ?n.
FILTER(?n != dbp:Cesare_Prandelli) } } }}
The previous SPARQ–LTL query makes usage of PAST to find when (in which version) C. Prandelli was the coach. Then, via the nested NEXT operator executes the innermost part of the query looking for the Italian football team coach in the subsequent version. Assuming to have 6 versions of the data it can be noted that PAST makes usage of UNION queries over each of the 6 versions vi, with i 2 f1; :::; 6g, (since the starting version is the current one, i.e., v6); then, for each vi, NEXT checks in version vi+1 (via a FILTER) that the coach changed — actually, note that the evaluation of PAST can transparently start from the version v5 since version v6 does not have a NEXT version. The advantage of using SPARQ–LTL can be noted both in terms of succinctness (the SPARQ–LTL query has 140 characters while the complete translation 600) and readability. We formalize the translation in Section 3.3.
Contributions and Outline. We make the following main contributions: (i) a formalization of SPARQ–LTL, a temporal extensions of SPARQL that offers a concise and readable syntax for temporal queries; (ii) a formal semantics; (iii) a translation from SPARQ–LTL into SPARQL; (iv) an experimental evaluation along with an analysis of the succinctness of SPARQ–LTL queries. 2
This section provides some background about the machineries used in this paper. 2.1
An RDF triple4 is a tuple of the form hs; p; oi2I I I[L, where I (IRIs) and L (literals) are countably infinite sets. An RDF graph G is a set of triples. To query RDF data, a standard query language, called SPARQL, has been defined. The semantics of a SPARQL query is defined in terms of solution mappings. A (solution) mapping is a partial function : V ! I [ L. Two mappings, say 1 and 2, are compatible (resp., not compatible), denoted by 1 = 2 (resp., 1 6= 2), if 1(?v) = 2(?v) holds (resp., does not hold) for all variables ?v 2 dom( 1) \ dom( 2) . If 1 = 2 then 1 [ 2 denotes the mapping obtained by extending 1 according to 2 on all variables in dom( 2)ndom( 1). This allows for defining the join, union, difference, and left outer join operations between two sets of mappings M1, and M2 as shown below: M1 1 M2 = f 1 [ 2 j 1 2 M1; 2 2 M2 and 1 = 2g M1 [ M2 = f j 2 M1 or The SPARQL semantics uses a function JQKG that evaluates a query Q on a graph G and gives a multiset (bag) of mappings in the general case.
2.2
Linear temporal logic (LTL) is an extension of modal logic to formally specify systems
and reason over them; here, modalities are temporal operators relating events happening
at different time instants over a linearly ordered timeline. Classically, LTL formulas
are interpreted over infinite sequences of states. The LTLf variant [
PLTLf formulas are built over a set V of atomic propositional variables by using the Boolean connectives ^; _; : plus the future temporal operators X (NEXT), F (EVENTUALLY), G (ALWAYS), U (UNTIL), and the past temporal operators Y (PREVIOUS), P (PAST), H (ALWAYSPAST), S (SINCE). The meaning of the temporal operators is summarized in Table 1.
X q q has to hold in the next state F q q has to hold in some future state
G q q has to hold in the current and all future states q1 U q2 q1 has to hold in all states in the future until there is a state in which q2 holds Y q q has to hold in the previous state P q q has to hold in some past state
H q q has to hold in all past states
q1 S q2 q1 has to hold starting from the state in the past where q2 holds
Our main goal in this paper is to devise a temporal extension of SPARQL with particular
emphasis on an easy (and intuitive) usage of temporal operators and their combinations.
Our second goal is to enable querying RDF archives on existing SPARQL processors.
In what follows we provide an overview about archiving policies for historical RDF
data [
Independent Versions. The first approach works by keeping independent versions of the data. In the case of RDF this could be implemented by assuming that each data version (e.g., DBpedia dumps) is stored in a separate named graph. Consider the data taken from DBpedia reported in Fig. 1. A query ran on March 2014 and asking for the coach of the Italian football team would have returned Cesare Prandelli. The same query ran on September 2014 would have returned Antonio Conte. Query infrastructures allowing to query the latest version of the data, miss the flow of updates. As an example it would not be possible to ask queries like “Find players since C. Prandelli was the coach”. A simple way to represent historical RDF data using versioning is via RDF quads. An RDF quad (for simplicity, we omit bnodes) is a tuple of the form hs; p; o; ci 2 I I (I[L) I, where the fourth element of the quad represents the named graph to which the triple belongs5. Hence, quads that differ for the fourth element only (e.g., white (uncolored) triples in Fig. 1), represent the fact that a triple is present in different versions.
dbp:Luca_Antonelli dbp:Italy_national_football_team dbpo:name .. dbpo:regionalName dbpo:name dbp:Giam.paolo_Pazzini
dbp:UEFA_European_Championship July 2016 <http://gize.org/version5> dbpdbop::cGoiaamchpiero_Ventura dbpo:nadbmpe:A..ndrea_Pirlo dbp:Italy_national_football_team .
dbpo:regionalName dbpo:name dbp:Matteo_Darmian March 2014 <http://gize.org/version2> September 2014 <http://gize.org/version3> dbp:Cesare_Prandelli dbp:Andrea_Pirlo dbp:Antonio_Conte dbp:Andrea_Pirlo dbpo:coach dbpo:name dbpo:coach dbpo:name ..
dbp:Italy_national_football_team . dbpo:regionalName dbpo:name dbp:Matteo_Darmian dbp:UEFA_European_Championship dbp:UEFA_Euro_2016_qualifying
dbpo:current update addition deletion
DBpedia Update Statistics about People dbp:UEFA_European_Championship dbp:UEFA_Euro_2016 dbpo:current
Tracking the changes. This approach is based on the computation (and storing) of updates or differences (deltas) between versions. It requires additional computational costs for delta propagation which may affect version-focused retrieving operations. Timestamps. In this case each RDF triple is annotated with its temporal validity. From a practical point of view, there are two main approaches: (i) compression techniques e.g. using selfindexes or delta compression in B+Trees (e.g., [17]); (ii) annotate triples (with time information) only when they are added or deleted.
In this paper we consider the independent versions model to describe our SPARQ– LTL language. Nevertheless, SPARQ–LTL can be also used (with minor changes) with the other archiving models (see Section 6). 3
We are now ready to introduce SPARQ–LTL, a general language that offers a concise syntax for the writing of temporal queries. We first discuss SPARQ–LTL syntax, then its formal semantics6 and finally the translation of SPARQ–LTL queries into SPARQL. 3.1
Let V be a set of variables. The syntax of SPARQ–LTL query patterns (QP) is shown in Fig. 2. The language extends SPARQL with constructs inspired by the temporal operators of Linear Temporal Logic (LTL) as described in Table 1. In SPARQ–LTL the 5For instance, the date in which a version is created 6For the sake of readability we focus on set semantics. complete name of the temporal constructs can be used, e.g. one can write ALWAYS instead of G or ALWAYSPAST instead of H.
QP ::= SPARQL operators t = (I [ V) (I [ V) (I [ L [ V) j QP1 AND QP2 j fQP1g UNION fQP2g j fQP1g MINUS fQP2g j QP1 OPT fQP2g j QP FILTER fRg j GRAPH I [ V fQPg j
XfQPg j FfQPg j GfQPg j fQP1g U fQP2g j YfQPg j PfQPg j HfQPg j fQP1g S fQP2g The formal semantics of SPARQ–LTL is shown in Table 2; rules in the top part define the semantics of (standard) SPARQL operators (we focus on set semantics for sake of exposition), while the semantics of the temporal constructs is defined in the bottom part.
JtKGi = f j dom( ) = var(t) and (t) 2 Gig
Jq1 AND q2KGi = f j 2 Jq1KGi 1 Jq2KGi g Jq1 UNION q2KGi = f j 2 Jq1KGi [ Jq2KGi g Jq1 MINUS q2KGi = f j 2 Jq1KGi n Jq2KGi g
Jq1 OPT q2KGi = f j 2 Jq1KGi ./ Jq2KGi g Jq FILTER fRgKGi = f j 2 JqKGi and eval( ; R)=trueg
J GRAPH u fqgK = f j 2 JqKGu g J GRAPH ?v fqgK = SGj f j 0 2 JqKGj and = 0 [ f?v ! Gjgg
JJXF qqKKGGii == JSqiKGji<+n1JqKGj J q1 JUGqq2KKGGii == fSi :j<n2fJq1KG1i 12 JjqK2Gi2+1Jq12K:G::j1anJdqKG1n2g Jq1KGk ; 8i
JJPY qqKKGGii == JSq0KGji 1iJqKGj J q1 JSHqq2KKGGii == fS0 : j 2ifJq1K1Gi 12 Jjq.K2G2i 1Jq12K:G::j 1anJdqKG102g Jq1KGk ; 8j < k
The evaluation function J K requires a graph Gi (encoding a version of the data) for
all rules but those (last two in the top part) that actually allow to evaluate the query
on a specific graph. By default the evaluation starts from the current version. The
result of a query is a set of mappings that are retrieved by looking into a particular (set
of) data version(s) as dictated by the temporal constructs. To define the semantics of
temporal operators in SPARQ–LTL we took inspiration from the semantics of LTL [
SPARQ–LTL allows to express complex temporal queries in a concise way by incorporating constructs inspired by LTL allowing to capture a variety of temporal aspects both involving the past and the future. The second goal of this paper is to make SPARQ– LTL available into existing SPARQL processors. To fulfill this goal we now discuss a translation procedure from SPARQ–LTL queries into SPARQL queries.
The translation of SPARQ–LTL is outlined in Table 3. The (recursive) translation function (q; i), given a SPARQ–LTL query q and a graph version i produces a SPARQL query by translating the temporal operators via a (set of) pattern(s) evaluated on named graphs (via the SPARQL GRAPH operator) maintaining data versions. The SPARQL query is generated by applying recursively the translation function to the sub-queries. We give an additional example by considering data versions (stored in separate named graphs) where dbp:INFT is a shorthand for dbp:Italy_national_ football_team.
Example 3. Select players who are playing in the Italian national football team under the current coach and that have played under at least one different coach in the past.
SPARQ–LTL
Translation into SPARQL
The SPARQL query on the right is automatically generated and can be evaluated on existing processors. Note that the translation requires to look into all previous versions. (t = hs; p; oi; i) = t (q1 AND q2; i) = (q1; i) AND (q2; i) (q1 UNION q2; i) = (q1; i) UNION (q2; i) (q1 MINUS q2; i) = (q1; i) MINUS (q2; i) (q1 OPT q2; i) = (q1; i) OPT (q2; i) (q FILTER fRg; i) = (q; i) FILTER (R) ( GRAPH v fqg; i) = f GRAPH v f (q; v)gg ( GRAPH ?vfqg; i)= f GRAPH h0if (q; 0)g BIND(0 AS ?v)g UNION . . . UNION
f GRAPH hn-1if (q; n-1)g BIND(n-1 AS ?v)g (Xfqg; i) = GRAPH hi+1if (q; i + 1)g (Ffqg; i) = f GRAPH hiif (q; i)gg UNION f GRAPH hi+1if (q; i+1)gg UNION . . .
UNION f GRAPH hn-1i f (q; n-1) gg (Gfqg; i) = GRAPH hiif (q; i)g GRAPH hi+1if (q; i+1)g . . . GRAPH hn-1if (q; n-1)g (fq1gUfq2g; i) = f GRAPH hiif (q2; i)gg UNION f GRAPH hi+1if (q2; i+1)g GRAPH hiif (q1; i)gg UNION . . . UNION f GRAPH hn-1if (q2; n-1)g GRAPH hiif (q1; i)g : : :
GRAPH hn-2if (q1; n-2)gg (Yfqg; i) = GRAPH hi-1if (q; i-1)g (Pfqg; i) = f GRAPH hiif (q; i)gg UNION f GRAPH hi-1if (q; i-1)gg UNION . . . UNION f GRAPH h0if (q; 0)gg (Hfqg; i) = GRAPH hiif (q; i)g GRAPH hi-1if (q; i-1)g . . . GRAPH h0if (q; 0)g (fq1gSfq2g; i) = f GRAPH hiif (q2; i)gg UNION f GRAPH hi-1if (q2; i-1)g GRAPH hiif (q1; i)gg UNION . . . UNION f GRAPH h0if (q2; 0)g GRAPH h1if (q1; 1)g : : :
GRAPH hiif (q1; i)gg
In databases, there exists a vast body of literature on temporal relational databases for developing temporal data models and query languages (cf. the survey [30]). The most prominent query language for temporal databases is TSQL2 [33]. TSQL2 is not a part of the standard SQL, however, the latest standard (SQL:2011) supports the valid (viz. application time) and transaction time models [35].
In the Semantic Web, the introduction of time into RDF has been studied almost one decade ago [22]. Gutierrez et al. [22] studied fundamental problems of temporal RDF graphs such as entailment and outlined a query language allowing to express queries making usage of intervals. Along these lines several other extensions of SPARQL such as -SPARQL [34], T-SPARQL [18], tRDF [32] and RDF-TX [17] have been proposed.
-SPARQL extends SPARQL query patterns with two variables ?s and ?e to bind the
start time and end time of temporal RDF triples and express temporal queries. The
evaluation is done by rewriting -SPARQL queries into standard SPARQL queries.
TSPARQL leverages a multi-temporal RDF model where each RDF triple is annotated
with a temporal element that represents a set of temporal intervals. T-SPARQL is based
on TSQL2 (temporal SQL). The tRDF system builds upon the Gutierrez et al. [22]
temporal RDF model. tRDF queries are evaluated using an index (viz. tGrin) based on a
strategy that clusters RDF triples using a graphical-temporal distance. RDF-TX [17]
offers both a temporal extension of SPARQL and an indexing system based on the
compressed multiversion B+ tree approach from relational databases. SPARQL-ST is a
query language for spatiotemporal RDF data [31]. It extends SPARQL with spatial and
temporal variables. The temporal variables appear in the fourth position of valid time
temporal triple patterns (i.e., when temporal triples are represented by quads); and thus,
these variables can be mapped into time intervals upon query evaluation. Additionally,
SPARQL-ST proposed a new filter operator called TEMPORAL FILTER which
supports temporal constraints based on Allen’s interval relations [
7Strabon is a spatiotemporal RDF store http://www.strabon.di.uoa.gr
In the experimental evaluation we measured: (i) query running time when translating a SPARQ–LTL query; (ii) query succinctness.
Datasets. We used both local and remote datasets. We considered data (person data and infoboxes) from the latest 7 versions of DBpedia8 and loaded each version in a separate named-graph by using Blazegraph9 as SPARQL processor. All the experiments have been performed on an Intel i5 machine with 8GBs RAM. Results reported are the average of 10 runs. Table 4 reports the size (in millions of triples) of the (local) data loaded in each version along with the percentage of updated (Upds), added (Adds) and removed (Dels) triples between versions.
Running Time. We used a set of 10 SPARQ–LTL queries including from one to four temporal constructs. In the first experiment, we measured the query time after translating the queries. Running times are reported in Table 5. As it can be observed the running time for all queries is in the order of tens of seconds.
Q1 11 Q6 12 Q2 23 Q7 23 Q3 11 Q8 32 Q4 14 Q9 33 Q5 41 Q10 31
We noted that the query time grows almost exponentially with the number of temporal constructs involved. Indeed, each temporal construct requires a certain number of UNION queries. The cost in terms of time to load all the version was of about 3h (on a 8http://downloads.dbpedia.org 9https://www.blazegraph.com 4000 3000 2000 1000 0 SPARQ-LTL SPARQL laptop), with a total storage space for all the versions of about 50 GBs. To give a sense of the amount of redundancy introduced by this approach, we noticed that the 40% of triples are left untouched along all the versions. Overall, this approach has the advantage of providing an immediate way for querying historical RDF data. The cost that one has to pay consists in loading different data versions plus data redundancy. The level of redundancy that can be afforded depends on the dataset; for datasets of small/medium size like DBpedia this may be bearable.
Query Succinctness. We measured the length, in terms of number of characters, of the SPARQ–LTL queries considered along with their translations. Fig. 3 shows the result of this analysis. It is worth to point out that: (i) SPARQ–LTL queries not only are shorter but also more readable; (ii) the user deals with a lower number of variables.
Q1
Q2
Q3
Q4
Q5
Q6
Q7
Q8
Q9 Q10
We now give a hint of how SPARQ–LTL can be used with other archiving models. In particular we focus on timestamps and leave as a future work a complete treatment of this topic. Timestamps allow to establish the time (or the version) at which a certain event is true. In this setting, a temporal RDF graph is a graph where triples hs; p; oi in the graph have a fourth element that represents validity [v1; v2], i.e., (hs; p; oi; [v1; v2]). As mentioned in Section 2.3, for triples that do not change at all across versions the validity can be omitted. The syntax of a graph in this setting is usually given by reifying temporal facts into non-temporal facts [21]. We represent a temporal triple (hs; p; oi; [v1; v2]) in RDF as shown in Fig. 4.
The advantage of this approach over the independent versions model is that data are stored in one graph, although requiring an effort to generate and keep up to date the validity of triples. In terms of storage space, this approach requires at most (only for triples that change) four triples instead of one.
s p _:x. _:x p o. _:x :validFrom v1.
_:x :validThrough v2.
The independent versions model can be cast into the timestamp model as follows: (i) start with the oldest data version (v1) and represent each triple as hs; p; oi; (ii) for each version vi, i > 1, if hs; p; oi (resp., (hs; p; oi; [vj ; ])) was in vi 1 and is not in vi add (hs; p; oi; [v1; vi 1]) (resp., (hs; p; oi; [vj ; vi 1])); (iii) if hs; p; oi was not in vi 1 but is in vi add (hs; p; oi; [vi; ]).
In this setting, the evaluation function used to define the semantics of SPARQ–LTL will not make usage of different (named) graphs (see Table 2) but will make usage of a single graph and leverage the validity information of triples. As an example, the operator EVENTUALLY whose semantics according to the independent versions is JF qKGi =
[ i j<n
JqKGj JF qKvGi =
[ vj:vj vi
JqKvGj with the timestamps is interpreted as: assuming that timestamps are expressed as integer values and vi is the version from which F q is evaluated. Similarly, the translation of SPARQ–LTL into SPARQL now takes into account validity information that will be taken into account by using RDF predicates as those in Fig. 4. We give a hint via the following example, which also underlines the conciseness of SPARQ–LTL.
Example 4. Select all footballers that always played with the same football team.
SELECT ?person WHERE { { ?person :occupation ?x1.
?x1 :occupation :football_player.
ES?VEpELeNErTCsUToAnL?Lp:Yeo{rcscounpaWtHiEoRnE:{football_player. {OOPP?TTpIIeOOrNNsAAoLLn{{??:xxm11em::bvveaarll_iioddfTF_hrtroeomaumg?ht?1x?.t2}2..} ALWAYS{?person :member_of_team ?club.} ?x2 :member_of_team ?club. } } OOPPTTIIOONNAALL{{??xx22 ::vvaalliiddTFhrroomug?ht3?.t}4.}OPTIONAL FILTER(((!BOUND(?t1)&&!BOUND(?t3)) || (?t3=?t1)) && (!BOUND(?t4))) }}} 7
We described a novel formal language for querying historical RDF data called SPARQ–
LTL. We presented a formal semantics along with translations that makes SPARQ–
LTL queries usable in existing SPARQL processors. In this work, we focused on RDF
archives with data stored in separate named graphs. As mentioned in Section 6 we
are currently working on an extension of the language where archival RDF data are
represented via timestamps. As a future work, we will explore the possibility to add
other temporal features to the language and perform a more comprehensive
experimental evaluation and comparison with related proposals also using benchmarks like
BEAR [
History of RDF Knowledge Bases. In EDBT, pages 269–280, 2016. 18. F. Grandi. T-SPARQL: A TSQL2-like Temporal Query Language for RDF. In ADBIS (Local
Proceedings), pages 21–30. Citeseer, 2010. 19. M. Gueffaz, S. Rampacek, and C. Nicolle. Mapping sparql query to temporal logic query based on n smv model checker to query semantic graphs. International Journal of Digital Information and Wireless Communications (IJDIWC), 1(2):366–380, 2012. 20. M. Gueffaz, S. Rampacek, and C. Nicolle. Temporal logic to query semantic graphs using the model checking method. Journal of Software, 7(7):1462–1472, 2012. 21. C. Gutierrez, C. Hurtado, and A. Vaisman. Temporal rdf. In The Semantic Web: Research and Applications, pages 93–107. Springer, 2005. 22. C. Gutierrez, C. A. Hurtado, and A. Vaisman. Introducing time into rdf. Knowledge and
Data Engineering, IEEE Transactions on, 19(2):207–218, 2007. 23. U. Khurana and A. Deshpande. Efficient snapshot retrieval over historical graph data. In Data Engineering (ICDE), 2013 IEEE 29th International Conference on, pages 997–1008.
IEEE, 2013. 24. M. Koubarakis and K. Kyzirakos. Modeling and querying metadata in the semantic sensor web: The model stRDF and the query language stSPARQL. In The semantic web: research and applications, pages 425–439. Springer, 2010. 25. F. Laroussinie, N. Markey, and P. Schnoebelen. Temporal logic with forgettable past. In Logic in Computer Science, 2002. Proceedings. 17th Annual IEEE Symposium on, pages 383–392. IEEE, 2002. 26. R. Mateescu, S. Meriot, and S. Rampacek. Extending SPARQL with Temporal Logic. Report, 2009. 27. B. McBride and M. Butler. Representing and querying historical information in rdf with application to e-discovery. HP Laboratories Technical Report, HPL-2009-261, 2009. 28. V. Milea, F. Frasincar, and U. Kaymak. towl: a temporal web ontology language. IEEE
Transactions on Systems, Man, and Cybernetics, Part B (Cybernetics), 42(1):268–281, 2012. 29. B. Motik. Representing and querying validity time in rdf and owl: A logic-based approach.
Web Semantics: Science, Services and Agents on the World Wide Web, 12:3–21, 2012. 30. G. O¨ zsoyog˘ lu and R. T. Snodgrass. Temporal and real-time databases: A survey. Knowledge and Data Engineering, IEEE Transactions on, 7(4):513–532, 1995. 31. M. Perry, P. Jain, and A. P. Sheth. Sparql-st: Extending sparql to support spatiotemporal queries. In Geospatial semantics and the semantic web, pages 61–86. Springer, 2011. 32. A. Pugliese, O. Udrea, and V. Subrahmanian. Scaling RDF with time. In Proc. of the 17th international conference on World Wide Web, pages 605–614, 2008. 33. R. T. Snodgrass. The TSQL2 temporal query language, volume 330. Springer Science &
Business Media, 2012. 34. J. Tappolet and A. Bernstein. Applied temporal RDF: Efficient temporal querying of RDF data with SPARQL. In European Semantic Web Conference, pages 308–322. Springer, 2009. 35. F. Zemke. What’s new in SQL:2011. ACM SIGMOD Record, 41(1):67–73, 2012.