Several query federation engines have been proposed for accessing public Linked Open Data sources. However, in many domains, resources are sensitive and access to these resources is tightly controlled by stakeholders; consequently, privacy is a major concern when federating queries over such datasets. In this paper, we present SAFE, a SPARQL query federation engine that enables decentralised, policy-aware access to clinical information represented as RDF data cubes. We validate the performance of the system with experiments over real-world datasets provided by three clinical organisations as well as legacy Linked Datasets. In our evaluation, we show that SAFE enables granular graph-level access control over distributed clinical RDF data cubes and efficiently reduces the query execution time when compared with general-purpose SPARQL query federation engine.
Inspired by the publication of hundreds of Linked Datasets on the Web, researchers have
been investigating federated querying techniques to enable access to this decentralised
content. Query federation aims to offer clients a single-point-of-access through which
distributed data sources can be queried in unison. In the context of Linked Data, various
optimised query federation engines have been proposed that can federate multiple
SPARQL interfaces [
However, in the context of the Healthcare and Life Sciences (HCLS) domain – where data-integration is often vital – real-world datasets contain sensitive information: strict ownership is granted to individuals working in hospitals, research labs, clinical trial organisers, etc. Therefore, the legal and ethical concerns on (i) preserving the anonymity of patients (or clinical subjects); and (ii) respecting data ownership through access control; are key challenges faced by the data analytics community working within the HCLS domain. Our focus in this paper is on point (ii), i.e., proposing a policy-based access control mechanism for user-restricted resources residing at different locations.
The key challenges for federated querying are efficient source selection (i.e., determining which sources are (ir)relevant) and query planning (i.e., determining an efficient query execution strategy). Query-federation engines often apply source selection at the level of endpoints, whereas in a controlled environment, a user may only have access to certain information within an endpoint. Adding an access control layer to existing SPARQL query federation engines thus adds unique challenges: (i) source selection should be granular enough to enable effective access control, and (ii) it should be policyaware to avoid wasteful requests to unauthorised resources. Therefore, in this paper we present SAFE, a SPARQL query federation engine that supports policy-based access to sensitive statistical data. SAFE is motivated by the needs of three clinical organisations in the context of an EU project who wish to enable controlled federation over statistical clinical data – such as data from clinical trials – owned and hosted by multiple clinical sites, represented in the form of data cubes: multi-dimensional arrays of numeric data.
SAFE extends upon the FedX engine [
The rest of the paper is structured as follows: Section 2 discusses our motivational scenario where data from different clinical locations need to be queried and aggregated. Section 3 discusses related work. Section 4 presents the three main components of SAFE query processing. Section 5 presents evaluation of SAFE against internal and external data sets and Section 6 concludes our work. 2
Our work is motivated by the needs of three clinical organisations: University Hospital Lausanne (CHUV)1, Cyprus Institute of Neurology and Genetics (CING)2, and ZEINCRO3. These organisations wish to develop a platform for analysing clinical data across multiple clinical sites, which would allow for increasing the total number of patients that are included in each analysis, thus increasing the statistical power of conclusions related to biomarkers, effectiveness and/or side-effects of drugs or combinations of drugs, correlations between patient groups, etc. The ultimate goal is to enable the collaborative identification of new drugs and treatments while reducing the high costs associated with clinical trials.
Use of Linked Data: With these goals in mind, the three clinical organisations mentioned are partners in the Linked2Safety EU project4. The two main goals of the Linked2Safety project are (i) the discovery of eligible patient data—also known as subject selection 1 http://www.chuv.ch/ 2 http://www.cing.ac.cy/ 3 http:/www.zeincro.com/ 4 http://www.linked2safety-project.eu/
CHUV – S1 CING – S2 Diabetes BMI_Abnormal Hypertension HIV Cases Diabetes Smoking Gender Cases 0 0 0 0 30 0 0 0 (F) 90 1 0 1 0 60 1 0 1 (M) 120
ZEINCRO – S3 CHUV – S4
Fig. 1: Example (2D) data cubes published by CHUV, CING and ZEINCRO criteria—that can be recruited for clinical trials from multiple clinical sites; and (ii) enabling multi-centre epidemiological studies enabling better understanding of relationships between pathological processes, risk factors, adverse events, and between genotype and phenotype. Although Linked Data technologies can help enable multi-site interoperability and integration, the community largely focuses on datasets that can be made open to the public. In contrast, clinical data is often of an extremely sensitive nature and there is often strict legislation in place protecting the privacy of patients. Legal and ethical implications of patient privacy: According to EU Data Protection Directive 95/46/EC5, clinical studies that involve patient-specific information must adhere to data-access restrictions that preserve patient anonymity. More specifically, a data access mechanism must ensure that patient identity cannot be discovered by any direct or indirect means using the dataset. Similar legislation exists in other jurisdictions. To avoid sharing of individual patient records, the Linked2Safety consortium has developed a data mining approach for transforming original clinical data into statistical summaries that may aggregate (or indeed redact) multiple dimensions of raw data.
The result is a set of anonymised data cubes whose dimensions correspond to
insensitive clinical parameters without personal information [
Although the data considered are aggregated and do not contain personal information
about patients, deanonymisation may still be possible [
In order to employ stricter data access restrictions on the anonymised multi-dimensional RDF data cubes, we then require an access-control–based query-federation approach that enforces and optimises for restricted user access over these RDF data cubes. To further illustrate and motivate, we now walk though an example. 5 http://www.dataprotection.ie/docs/EU-Directive-95-46-EC/89.htm 1 PREFIX qb: <http://purl.org/linked-data/cube#> 2 PREFIX sehr: <http://hcls.deri.ie/l2s/sehr/1.0/> 3 SELECT ?diabetes ?bmi ?hypertension ?cases 4 WHERE { ?dataset a qb:DataSet. 5 ?observation qb:dataSet ?dataset; 6 a qb:Observation; sehr:Diabetes ?diabetes ; 7 sehr:BMI_Abnormal ?bmi ; 8 sehr:Hypertension ?hypertension ; sehr:Cases ?cases . }
Figure 1 shows four sample data cubes published by three different clinical sites. Each observation represents the total number of patients exhibiting a particular adverse event. For example, the CHUV-S1 observations describe the total number of patients (in the Cases column) that exhibit a particular combination of three adverse events: Diabetes, (Abnormal) BMI Abnormal (Body Mass Index) and/or Hypertension. The value 0 or 1 indicates if the condition is present or not. For example, the second row in CHUV-S1 shows that there are 26 cases presenting with both Diabetes and Hypertension but without BMI Abnormal.
Once the data are published by clinical sites, they should be accessible to clinical researchers. Figure 2 shows a sample SPARQL query specifying subject-selection criteria, asking for the counts of cases that involve some combination of diabetes, abnormal BMI, and hypertension. An answer returned by the query, i.e., number of cases, will play a major role in deciding the resources (i.e., number of subjects, location, etc. ) required for conducting a clinical trial. However, answering such a query requires integrating RDF data cubes with three dimensions – Diabetes, Hypertension, BMI Abnormal – and the respective counts originating from multiple clinical sites.
Referring back to Figure 1, only three of the datasets (CHUV-S1, CING-S2 and ZEINCRO-S3) contain all required dimensions. An answer returned by the query (Figure 2) should list counts (i.e., cases) from these three RDF data cubes. However, assuming that the policy restrictions are applied to the user (say James), who wants to execute the query and has access to CHUV-S1 and CING-S2 RDF data cubes only. Therefore, the query federation engine should retrieve results only from CHUV-S1 and CING-S2 and should not consider ZEINCRO-S3 for querying.
Hence, one of the key requirements in the context of the Linked2Safety project is to
support federation of queries over clinical data distributed at multiple clinical sites by
taking into account the data access policies (Figure 3 (c): shows a data access policy)
assigned to the users (Figure 3 (a): shows a user profile for James) executing those
queries. Since RDF data cubes are self-contained entities associated with additional
provenance information (e.g., creator, location, etc.; see Figure 3 (b)), they are modelled
using named graphs [
In order to publish clinical data cubes as RDF (Figure 1) and describe user profiles along with their access rights (Figure 3) used within query federation process, the Linked2Safety consortium has developed two vocabularies: (i) Semantic EHR Model (prefix “sehr”) describes the clinical terminologies used by the three clinical partners; and (ii) Access Policy Model (prefix “lmds”) describes the user profiles (their activity, @prefix lmds: <http://www.linked2safety.eu/lmds#>. @prefix acl: <http://www.w3.org/ns/auth/acl#>. @prefix sehr: <http://hcls.deri.ie/l2s/sehr/1.0/> :James lmds:hasRole lmds:ClinicalResearcher . :James lmds:hasLocation “Greece”. :James lmds:hasWorkingArea sehr:Oncology. :James lmds:hasOrganization lmds:UCY . :James lmds:hasExpertise sehr:Epidemiologist.
(a) User Profile :CHUV-S1 a lmds:NamedGraph . :CHUV-S1 lmds:hasGraphURI "http://linked2safety.eu/CHUV/graph/6" . :CHUV-S1 lmds:hasSparqlEndpoint "http://10.196.2.116:3030/query" . : CING-S2 a lmds:NamedGraph (b) Data Cubes Sources :AP1 a lmds:AccessPolicy . :AP1 lmds:grantsAccess acl:Read_l2s . :AP1 lmds:appliesToNamedGraph : CHUV-S1, :CING-S2 . :AP1 lmds:hasUserProfile :James .
(c) Access Policy
location, organisation, position and role) and their respective access rights (e.g., read,
write). Considering space limitations, further details of these two vocabularies are out of
scope for this paper; we instead refer the readers to dedicated papers on the Semantic
EHR Model [
Various approaches have been proposed to query RDF data in a decentralised manner. Here, we focus on approaches that look at federating multiple SPARQL endpoints. Likewise, a number of works have looked at access control over Linked Data. We now briefly discuss both categories of work in the following.
SPARQL Query Federation: Many query federation engines have been proposed for
SPARQL (e.g., [
Table 1 gives an overview of existing SPARQL query federation engines with respect to source selection type, physical join operators, use of caching and explicit support for updates. We also remark on whether code is available for the system.
In this setting, our work builds upon an existing federated engine – FedX – with
support for an access-control layer over statistical data represented as RDF data cubes.
ADERIS [
SAFE is designed specifically to query statistical RDF data cubes in a distributed setting, where access control is coupled with source selection and both operate on the same level of granularity: named graphs. Access control – deny or allow access – is based on user profiles and their access rights. 4
SAFE’s architecture is summarised in Figure 4, which shows its three main components: (i) Source Selection: performs multilevel source selection based on the capabilities of data sources; (ii) Policy Aware Query Planning: filters the selected data sources based on access rights defined for each user; and (iii) Query Execution: performs the execution of sub-queries against the selected sources and merges the results returned. In the following, we describe these components in detail. 4.1
SAFE performs a tree-based two-level source selection as shown in Figure 5. At Level 1,
like other query federation engines [
Data Summaries: We assume a set of datasets D where each dataset D 2 D is a RDF dataset: D := f(u1; G1); : : : (un; Gn)g, where each (ui; Gi) is a named graph with (unique) URI ui. In our case, named graphs refer to individual RDF data cubes as we do not consider a default graph. We denote all graph names by names(D) and a graph in the dataset by D(u) := G. We denote by preds(G) := fp j 9s; o : (s; p; o) 2 Gg the set of all distinct predicates in G and by preds(D) := S(u;G)2D preds(G) the set of all distinct predicates in D. For each dataset D 2 D, SAFE stores the following as a data summary: (i) the endpoint URL (lmds:endpointUrl), where each endpoint indexes a dataset D; (ii) the set of all graph names in a dataset D: names(D) where each graph contains a RDF data cube (lmds:cube/lmds:graph); and (iii) for each graph G 2 D, the set of all predicates in G: preds(G) (lmds:cubeProperties).
We (informally) denote the set of all data summaries for D as S and the data summary for a particular source as S (D). A snippet of a data summary generated for the sample RDF data cubes published by three clinical sites (CHUV, CING, ZEINCRO) of Figure 1 is shown in Figure 6, where CHUV contains two RDF data cubes (CHUV-S1, CHUV-S4), CING contains one RDF data cube (CING-s2), and ZEINCRO also contains only one RDF data cube (ZEINCRO-s3). Before explaining the algorithm in the next section, PREFIX acl: <http://www.w3.org/ns/auth/acl#> PREFIX lmds: <http://www.linked2safety.eu/lmds#> ASK WHERE { ?accessPolicy a lmds:AccessPolicy . ?accessPolicy lmds:appliesToNamedGraph ?namedGraph . ?namedGraph lmds:hasGraph :CHUV_S1 . ?accessPolicy lmds:grantsAccess acl:Read_l2s .
?accessPolicy lmds:hasRequesterProfile :James . } we wish to make a formal description of the sets that are calculated on-the-fly by the algorithm as part of the data summary: 1. The set of all predicates in a dataset D : preds(D). This is the set-union of all preds(Gi) for each Gi 2 D; e.g., preds(CHUV) = fsehr:Diabetes, sehr:BMI Abnormal, sehr:Hypertension, sehr:Smoking, sehr:Gender, sehr:Cases g (ref. Figure 1, Figure 6). 2. The set of unique predicates in a dataset D: upreds(D) := fp 2 preds(D) j @D0 2 D : D 6= D0 ^ p 2 preds(D0)g; e.g., upreds(CHUV) = fsehr:Smoking; sehr:Genderg (ref. Figure 1, Figure 6). 3. The set of unique properties in a graph with name u: upreds(u; D) := fp 2 preds(D(u)) j @u0 : u0 6= u ^ p 2 preds(D(u)0)g (overloading upreds(:; :) for use with graphs also); e.g., upreds(:CHUV-s1; CHUV) = fsehr:BMI Abnormal; sehr:Hypertensiong and upreds(:CHUV-s4; CHUV) = fsehr:Smoking; sehr:Genderg (ref. Figure 1, Figure 6). 4. The set of graph names in D with unique properties: unames(D) := fu 2 names(D) j upreds(u; D) 6= ;g. For example, unames(CHUV) = f:CHUV-s1; :CHUV-s4g. 4.2
Once the relevant sources are identified for a SPARQL query, the next step is to further
filter these sources by authenticating the user that is making the request. Policy-Aware
Query Planning is the process of identifying capable sources: relevant sources that the
user has access rights for. Access policies on each source are defined in the access
policy model [
Relevant named graphs that return false will be filtered. Endpoints with capable
named graphs are then queried using standard federation techniques. For this, we use
the FedX query engine [
Algorithm 1: Access policy-based triple pattern-wise source and named graph selection
Data: D = fD1; : : : ; Dng, BGP = fbgp1; : : : ; bgpmg, S, P , user /* sources, BGPs of a SPARQL query, SAFE summaries of sources, Access
Policies, User 5 /* if jUGj > 1, no source can match the join else if !bound(p) then /* triple-pattern-wise source selection using ASK queries for each D 2 D do if ASK(D; t) = true then
R R [ (ftg names(D) fDg) ; /* select all graphs */ /* do policy-based graph filtering for each cgi 2 R do /* for each capable graph */ if ASK(D; cgi; P; user) = false then /* Authorise user against graph of a source using access policies */
RemoveGraph(cgi, R) ; /* remove unauthorised graph */ R
R [ fRg if UG = ; then
R R [ (ftg else if jUGj = 1 then
R R [ (ftg
UG fDg) ;
/* nothing unique so add all */ names(D) fDg) ; /* one unique cube */ 28 return R ;
/* return relevant sources and graphs for triple patterns */ 4.3
SAFE’s access policy-based triple-pattern-wise source selection is shown in Algorithm 1. The algorithm is designed to exploit specific properties of RDF data cubes, particularly the locality of joins: assuming RDF data cubes are not split over sources, certain types of joins can only be answered locally. In particular, we define a subject–subject join (s–s join), where two triple patterns share (only) a subject variable, and a subject–object join (s–o join), where the join variable appears in the subject position of one triple pattern and the object of the other. For example, in Figure 2, triple patterns 1–2 (lines 4–5) form an s–o join and triple patterns 2–7 (lines 5–8) form an s–s join. As per the example, such joins would have to be answerable by one source/data cube; thus (reasonably) assuming that RDF data cubes are not split across sources, we can exploit this locality with a join-aware strategy that reduces sources considered relevant while ensuring complete results. For example, in Figure 2, though many sources will match the first triple pattern, they will not be considered relevant unless they are relevant for later triple patterns also.
The algorithm takes the set of all available datasets D, their data summaries S, the access policy P , user info, and a SPARQL query containing a set of basic graph patterns6 BGP as input (source selection only refers to BGPs, which may be extracted from features such as UNION or OPTIONAL, etc.). The algorithm returns the set of relevant sources and corresponding named graphs for individual triple patterns as output. We process the individual triple patterns of each BGP separately (lines 1–2 of Algorithm 1). Given a triple pattern t 2 bgp 2 BGP with bound predicate p, for each dataset D 2 D, we collect the dataset-unique properties U , all unique properties A, and all dataset properties E from data summaries (lines 3–10 of Algorithm 1). A dataset D is relevant for triple pattern t if its predicate is a set member of E and either t forms a star (s–s) or path join (p–o) with any other triple pattern (in the same query) having a predicate in U or t does not form both star and path join with set difference A=U (line 11 of Algorithm 1). Once a relevant source is selected, the next step is to identify the set of relevant graphs within that relevant dataset (lines 12–19 of Algorithm 1). If triple pattern t belongs to a unique graph ug in selected data source D then only uq is selected as relevant graph (lines 13–15 of Algorithm 1). If there is no unique graph in D then all graphs in D are selected as relevant (lines 16–19 of Algorithm 1). If a predicate is not bound in t, we fall back to a standard strategy and make use of SPARQL ASK queries for source selection, i.e., we send a SPARQL ASK request to each of the endpoints (lines 20–23 of Algorithm 1). Once relevant graphs within relevant data sources are selected, the final step is to further prune the select capable graphs using policy-based filtering (lines 24–26 of Algorithm 1). A capable graph cg is removed if the user does not have access (according to policies P ) for cg.
As per our running example, consider the triple pattern tp := "?observation sehr:Diabetes ?diabetes" of the query given in Figure 2. Since the predicate is bound in tp, the condition given at line 6 of Algorithm 1 holds. For the CHUV dataset, U = fsehr:Smoking; sehr:Genderg, A = fsehr:Smoking; sehr:Gender; sehr:HIVg, and E = fsehr:Diabetes; sehr:BMI Abnormal; sehr:Cases; sehr:Smoking; sehr:Hypertension; sehr:Genderg (line 8–10), and A n U = fsehr:HIVg. The predicate sehr:Diabetes 2 E and tp does not not form a star join (s–s) or path join (s–o) with A n U in the query. Therefore, the condition given at line 11 of Algorithm 1 holds and the data source CHUV will be selected as relevant for T P . The next step is to select named graphs within the CHUV data source. For both named graphs (CHUV-s1, CHUV-s4) the condition given at line 14 is true, therefore both named graph are selected as relevant. For both CING and ZEINCRO the condition given at line 11 also hold; therefore they are also selected. Assuming James as the user who has requested the data, the response of ASK queries (i.e., true or false) will authorise the user against each capable named graph (line 25). In this example, James’ access will be denied for the named graph ZEINCRO-s3 and granted for the two other named graphs as specified in Figure 7(b). Hence ZEINCRO-s3 will be removed from the set of capable graphs and only CHUV will be queried to get the desired results. 6 http://www.w3.org/TR/sparql11-query/#BasicGraphPatterns This section presents evaluation comparing SAFE against FedX to validate the extensions we have proposed. The experimental setup (e.g., datasets, queries and metrics) for evaluation are as follows: Datasets: We use two groups of datasets exploring two different use cases.
The first group of datasets (INTERNAL) are collected from the three clinical partners involved in our primary use case as described in Section 2. These datasets contain aggregated clinical data represented as RDF data cubes and are privately owned/restricted.
The second group of datasets (EXTERNAL) are collected from legacy Linked Data containing sociopolitical and economical statistics (in the form of RDF data cubes) from the World Bank, IMF (International Monitoring Fund), Eurostat and Transparency International. The World Bank data contains a comprehensive set of information about countries around the globe, such as observations on development indicators, financial statements, climate change, research projects, etc. The IMF data provides a range of time series data on lending, exchange rates and other economic and financial indicators. The Eurostat data provides statistical indicators that enable comparison between countries and regions across Europe. The Transparency International data includes a Corruption Perceptions Index (CPI), which ranks countries and territories based on how corrupt their public sector is perceived to be.
Table 2 gives an overview of the experimental datasets (i.size refers to index size and i.time refers to time taken for index generation). Each dataset was loaded into a different SPARQL endpoint (using Jena Fuseki) on separate physical machines.
Queries: A total of 12 queries are designed to evaluate and compare the query
federation performance of SAFE against FedX. These queries are of varying complexity and
have varying type of characteristics. For space reasons, the full list of queries is made
available at http://linked2safety.hcls.deri.org:8080/SAFE-Demo/
queries.html. In Table 3, we summarise the characteristics of these queries
(following similar dimensions to the Berlin SPARQL benchmark [
Metrics: For each query type we measured (i) the number of sources selected; (ii) the average source selection time; (iii) the average query execution time; and (iv) the number of ASK requests issued to sources. The performance of SAFE and FedX was compared based on these metrics. All experiments are carried out on a local network, so that network cost remains negligible. Machines used for experiments have a 2.60 GHz Core i5 processor, 8 GB of RAM and 500 GB hard disk running a 64-bit Windows 7 OS. The results produced by FedX and SAFE are the same for all queries. Triple pattern-wise sources selected: Table 4 shows the total number of triple patternwise (TP) sources selected by SAFE and FedX for all the queries. The last column in Table 4 shows the average number of TP sources selected by each approach. FedX performs optimal source selection at the triple-pattern-level using ASK queries for each triple pattern to find out precisely which sources can answer an individual triple pattern. By using join-aware source selection designed for RDF data cubes, SAFE manages to filter further potential sources that do not contribute to the end results, thus (as we will see) reducing response times.
Number of SPARQL ASK requests: Table 5 shows the total number of SPARQL ASK requests used to perform source selection for each query. FedX is an index-free approach and performs runtime SPARQL ASK requests during source selection for each triple pattern in query. Conversely, SAFE uses data summaries for source selection, reverting to SPARQL ASK requests only when there is an unbound predicate in a triple pattern. None of our evaluation queries have an unbound predicate; hence there are no SPARQL ASK requests for SAFE. Though flexible in the generic case, index-free approaches can incur a large cost in terms of SPARQL ASK requests used for source selection, which can in turn increase overall query execution time.
Source selection time: Figure 8 compares the source selection time of SAFE and FedX for all queries, where the y-axis is presented in log-scale. The rightmost pair of bars compares the average source selection time over all queries. As expected, the source selection time for SAFE is much lower than that of FedX. This is primarily attributable to SAFE’s use of a domain-specific index for source-selection, which avoids incurring heavy traffic for ASK queries. The index can typically be pre-loaded into memory before query execution, which means that the source selection time for the presented use case(s) will be minimal.
Query execution time: For each query, the average query execution time was calculated for both approaches by running each query ten times. Figure 9 compares the overall query execution time of SAFE and FedX for all queries. Again, the y-axis is logscale and the rightmost pair of bars compares the average query execution times. The results shows that SAFE has significantly outperformed FedX in all queries in the context of the presented use cases. In fact, we see that FedX times-out in the case of three queries (in our experiments, we set queries to timeout after 25 minutes).
There are a number of factors that can influence the overall query execution time of a query federation engine, such as join type, join order selection, block and buffer size, etc. However, given that SAFE is based on the FedX architecture, we can attribute 1 the observed runtime improvements to three main factors: (i) source selection time is reduced (as we have seen in the previous sets of results); (ii) fewer sources are queried meaning less time spent waiting for responses; and (iii) triple patterns are more selective in SAFE, where, for example, our join-awareness makes it unlikely that all rdf:type triple patterns will need to be retrieved/queried for all sources but rather only from sources where such a triple pattern joins with a more selective one. Taken together, these three main observations explain the time saving observed for our presented use cases. 6
In this paper, we have presented SAFE: a query federation engine that enables policybased access to sensitive statistical datasets represented as RDF data cubes. The work is motivated in particular by the needs of three clinical organisations who wish to develop a platform for collaboratively analysing clinical data that spans multiple clinical sites, thus improving the statistical power of conclusions that can be drawn (versus one source alone). Clinical data – even in aggregated form – is of a highly sensitive nature, and thus query federation engines must take access policies into account.
SAFE is developed as an extension on top of the FedX federation engine to support two main features: (i) optimisations tailored for federating queries over RDF data cubes; and (ii) source selection on the level of named graphs that allows for integration with an existing access control layer. We evaluated these extensions based on our internal data sets (private data owned by clinical organisations) as well as external data sets (public data available from the LOD cloud) in order to measure the efficiency of SAFE against FedX. Our evaluation results show that, for our use-case(s), SAFE outperforms FedX in terms of fast source selection and query execution time. The source-code (AGPL License) and a demo for SAFE can be found at http://linked2safety.hcls. deri.org:8080/SAFE-Demo/.
ACKNOWLEDGMENTS: This publication has emanated from research supported in part by the research grant from Science Foundation Ireland (SFI) under Grant Number SFI/12/RC/2289, EU FP7 project Linked2Safety (contract number 288328), EU FP7 project GeoKnow (contract number 318159) and by the Millennium Nucleus Center for Semantic Web Research under Grant NC120004.