We introduce the Gize framework for querying historical RDF data. Gize builds upon two main pillars: a lightweight approach to keep historical data, and an extension of SPARQL called SPARQ{LTL, which incorporates temporal logic primitives to enable a rich class of queries. One striking point of Gize is that its features can be readily made available in existing query processors.
Introduction
Querying historical data is of utmost importance in many contexts, from city
monitoring, where one needs to track di erent aspects (e.g., pollution,
population) to generic exploratory research, where one is interested in posing queries
like \Retrieve players that are now managing some club they played for" or
\Retrieve the annotation of a gene since the discovery of a particular interaction".
The classical approach for querying RDF data (e.g., via SPARQL endpoints)
only considers the latest version. In fact, querying of historical RDF data poses
some challenges. The rst concerns the representation and storing of historical
data. Some approaches (e.g., [
To cope with these issues we present the Gize4 framework. Gize is built
around two main components. The rst is a lightweight approach to store RDF
data, where each version of the data is stored in a separate named graph. The
second component is a powerful extension of SPARQL called SPARQ{LTL. This
language inherits a variety of temporal operators from Linear Temporal Logics
(LTL) [
4Gize (
) is the Ethiopian word for time.
Related Work. Approaches like the DBpedia Wayback Machine [
The Gize Framework Representing Historical RDF Data. The tenet of Gize is to enable querying of historical RDF data on existing processors. To represent versions, Gize leverages the notion of RDF quad. 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 I (IRIs) and L (literals) are countably in nite sets. The forth element of the quad represents that named graph to which the triple belongs.
June 2012 <http://gize.org/v1> March 2014 <http://gize.org/v2> September 2014 <http://gize.org/v3> Jddubbnpp:eUoE:dd2FrbAb0ep_p:g1EIdotiau6b:lroypoc_np:ConeaaaaeltniscoN_ahnCaraehml__aefmPo<orpdatibhonbddandptlbbs_ehoppttliep:ooiapc::mun:nraa/rmm/eeengtdibdpzdb:bGeppi:a:.AUmnEopdFrarA...eo_galEo_/_uPrPvoiar_l4z2oz0>i1n2i dJbupoly:rd2deb0bgpdpdb1io:Ipbto:6a:pUncly:ECao_FnleaAasNc_taiahoErnmuear_eol_Ppfeordaaobnntbp_daCoeld<h_l:biatnehmpaatopmmi:otenndspahbm:ippe/dob:/dpndb:gAabpipnm:G:deLzriuaeecmaa...._p_PaoAiornrllootog_nP/ealvziz5in>i dbdpbdopb::pUr:EIdteauFbglAyppdi__:dnbEAoaaupnntritotaoooepn:lneacNial_ooanf_o_amCoCcethbohaanmlt_epteiodaanmbdshpdiopdi:tbicdopubonrp:rodnbe:apnnm:UtaeEmFeAdd_bbEppu:M...r:doAa_ent2tld0ee1roet6_ia_oDq_nauParmilriflyioainng dbpod:bdprb:epItagodliyb:_opcnn:oaAaatniolctnoNhanal_imofoe_oCtbodadnblbt_peptoeoa::mnnaammee ddbbpp:M:Aanttder...oe_aD_Parirmloian dbddpbbopdp:bo:Irtp:a:elcGyg_oiniaaaomctinohpnaiaellr_Nofoa_omVtbeeanl_tudterbaapmo:dnbapmoe:ndabdpbm:peM:Aa...tntedore_aD_aPrmirlioan DBpedia Update Statistics about People dbp:UEFA_European_Chadmbppioon:shcipurrent dbp:UEFA_Euro_2016 dbp:UEFA_European_Championsdhbippo:currendtbp:UEFA_Euro_2016
Fig. 1. An exceprt of evolving data from DBpedia.
Fig. 1 shows the evolution of some data taken from DBpedia. Each of the 5 versions considered is represented by a named graph. From this small data sample one may notice that Italy has changed 3 coaches from July 2012 (C. Prandelli) to July 2016 (G. Ventura). Interestingly, the latest coach (G. Ventura) will start on July 18th. One may also notice that some players like A. Pirlo were part of the team along the whole period, while some other like G. Pazzini or M. Darmiani were left out or added, respectively. The gure also shows (bottom right corner) update statistics about People in DBpedia. Each percentage is computed wrt the previous version. The availability of historical data allows to pose queries like \Find all players that played with the highest number of coaches" or \Find players that played since C. Prandelli was the coach". Most of existing approaches either are not able to express such kind of queries or have to resort to ad-hoc processing infrastructures.
The SPARQ{LTL Language. The syntax of SPARQ{LTL is shown below while Table 1 provides a description of the temporal operators. Let q be a SPARQ{LTL query, H = fh1; h2; : : : ; hmg be the set of versions, and hc be the current (not necessarily the latest) version of the data.
QP ::= QP1 : QP2 j fQP1g UNION fQP2g j fQP1g MINUS fQP2g j QP1 OPTIONAL fQP2g j j GRAPH I [ VQP1 j QP1 FILTER fRg j t = (I [ V) (I [ V) (I [ L [ V) j j XfQPg j WfQPg j FfQPg j GfQPg j fQP1g U fQP2g j j YfQPg j ZfQPg j PfQPg j HfQPg j fQP1g S fQP2g Operator SPARQ{LTL Syntax Meaning X q NEXT Evaluate q on version hc+1 F q EVENTUALLY Evaluate q on all versions hc; ::::hm G q ALWAYS The evaluation of q must be the same on all versions hc; ::::hm q1 U q2 UNTIL If S2 is the solution of q2 in a version, hk 2 fhc; ::::hmg then there exists a solution S1 of q1 on hc such that
S1 is compatible with S2 in all versions fhc; ::::hkg Y q PREVIOUS Evaluate q on version hc 1 P q PAST Evaluate q on all versions h1; ::::hc H q ALWAYSPAST The evaluation of q must be the same on all versions h1; ::::hc q1 S q2 SINCE If S2 is the solution of q2 in a version, hk 2 fh1; ::::hcg then there exists a solution S1 of q1 on fhk; ::::hcg such that
S1 is compatible with S2 in all versions fhk; ::::hcg
Example 2. Find the name of the coach of the Italian national football team after the sacking of Cesare Prandelli. SELECT ?n WHERE { PAST { dbp:INFT dbpo:coach dbp:CP.
NEXT { dbp:INFT dbpo:coach ?n.
FILTER (?n != dbp:CP ) } } }
Translation into SPARQL SELECT ?n WHERE { {GRAPH <http://gize.org/v5> { dbp:INFT dbpo:coach dbp:CP.
GRAPH <http://gize.org//v6> {dbp:INFT dbpo:coach ?n. FILTER (?n != dbp:CP )}
} } UNION ...... UNION {GRAPH <http://gize.org//v1> { dbp:INFT dbpo:coach dbp:CP.
GRAPH <http://gize.org//v2> {dbp:INFT dbpo:coach ?n. FILTER (?n != dbp:CP ) } } }}
In the previous query, dbp:CP is a shorthand for dbp:Cesare_Prandelli. As before, the translation of PAST makes usage of UNION queries over each versions vi; then, for each vi, NEXT checks in version vi+1 (via a FILTER) that the coach changed. 3
Conclusions
We have outlined Gize, which enables to set-up an infrastructure for
querying historical RDF data on existing SPARQL processors. Gize adopts a simple
approach to store di erent versions of the data and a powerful temporal
extension of SPARQL called SPARQ{LTL. As a future work, we are considering
approaches like RDF HDT [