We demo an online system that tracks the availability of over four-hundred public SPARQL endpoints and makes up-to-date results available to the public. Our demo currently focuses on how often an endpoint is online/o ine, but we plan to extend the system to collect metrics about available meta-data descriptions, SPARQL features supported, and performance for generic queries.
In previous work [2], we presented an analysis of the landscape of public SPARQL endpoints and asked the question: are these endpoints ready for action?4 Taking the full list of 427 public endpoints from the CKAN/DataHub catalogue (as available at the time of writing), for each endpoints, we conducted a number of experiments to gauge the following four main aspects: Our results showed that about half of the endpoints listed on CKAN/DataHub are now o ine, that only a few endpoints make meta-data descriptions available about their content (VoID) or features supported (SPARQL 1.1 Service Descriptions) in easy-to- nd locations, that there was mixed adoption This work was supported by Fujitsu (Ireland) Ltd. & by Science Foundation Ireland under Grant No. SFI/08/CE/I1380 (Lion-2). Carlos Buil-Aranda was supported by CONICYT/FONDECYT project No. 3130617. 4 This work is accepted for the Experiments track of ISWC 2013 [2]. This demo paper rather focuses on our tool for making results available to the community. of SPARQL and (recently standardised) SPARQL 1.1 features, that the performance of di erent endpoints over HTTP for generic queries could vary by orders of magnitude, and that less than one third of the endpoints had an average availability in the interval 99{100% (i.e., at least two-nines availability). We concluded that the usability of di erent public endpoints varies greatly.
We thus propose a system that tracks and collects metrics about public endpoints over time. Currently, our service tracks the hourly availability of endpoints, and we plan to extend it to collect weekly metrics about the available meta-data, supported features and performance of these endpoints, as well as other metrics that the community may wish to suggest.
In Section 2, we rst discuss our current \SPARQL Endpoint Status" system, available online at http://labs.mondeca.com/sparqlEndpointsStatus/. Thereafter, in Section 3, we discuss our proposed extensions. 2
Monitoring Availability The system automatically collects and updates a list of public SPARQL endpoints from the CKAN/DataHub catalogue. These endpoints are queried on an hourly basis using two alternative SPARQL queries: ASK WHERE{ ?s ?p ?o . }
SELECT ?s WHERE{ ?s ?p ?o . } LIMIT 1
The ASK query on the left is issued rst. If this query fails (from previous experience, we note that some endpoints do not support ASK [2, x 3]), we try the SELECT query on the right. Both queries are selected at they should be as cheap as possible for the endpoint to run: our goal is simply to check whether or not the endpoint is available for answering queries. If the endpoint returns a valid SPARQL response for either query, we then say that the endpoint is available at that timepoint. We also record the time taken for the query to execute.
At the time of writing, we have collected more than two million hourly pings across hundreds of endpoints over a period of more than two years. Detailed analysis of these availability results is available in [2, x 5].
User Interface We provide a user interface to browse and visualise the hourly results. The user interface supports two primary views.
The rst view, exempli ed in Figure 1, provides a full list of all the
monitored endpoints, their availability in the past 24 hours (ratio of successful hourly
queries in that period), and their availability in the past seven days. A
green/yellow/red/gray icon indicates, resp., that the endpoint is operating
normally/available but had problems in the past 24 hours/not available currently/not available
once in the past 24 hours. As per the icons listed on the right of the screenshot,
each endpoint is also associated with (
The second view provides details for a given endpoint. Figure 2 shows an example screenshot for the DBpedia endpoint. The graph on the left shows the response times for the last 24 hourly pings to that endpoint. The graph on the right plots the 24 hour availability for each of the last seven days. RDF Meta-data Results of the hourly pings are exported as RDF. Figure 3 presents an example description. We reuse existing vocabularies as much as possible (VoID, dcterms, etc.) to describe each dataset, their related SPARQL endpoint, title and identi er, etc. To capture availability information, we designed a new vocabulary (no existing one handled this feature). The \endpoint status" vocabulary5 (ends) allows the description of a status observation with the information of date, description (we are here reusing dcterms vocabulary), status availability and response time. All RDF data are then published in a SPARQL Endpoint available at: http://labs.mondeca.com/endpoint/ends. 5 http://labs.mondeca.com/vocab/endpointStatus/
Our system currently captures endpoint availability and query latency. In line
with the discussion of Section 1 and the methods of our experimental paper [2],
we wish to extend our system to track more metrics about public endpoints.
These would include: (
Acknowledgements: This paper was supported by Fujitsu (Ireland) Limited, and funded in part by Science Foundation Ireland under Grant No. SFI/08/CE/I1380 (Lion-2). Carlos Buil-Aranda was supported by the CONICYT/FONDECYT project No. 3130617.