Access to hundreds of knowledge bases has been made available on the Web through SPARQL endpoints. Unfortunately, few endpoints publish descriptions of their content. It is thus unclear how agents can learn about the content of a given endpoint. This research investigates the feasibility of a system that gathers information about public endpoints by querying directly about their own content. It would thus be feasible to build a centralised catalogue describing the content indexed by individual endpoints by issuing them SPARQL 1.1 queries; this catalogue could be searched and queried by agents looking for endpoints with content they are interested in. However, the coverage of the catalogue is bounded by the limitations of public endpoints themselves: some may not support SPARQL 1.1, some may return partial responses, some may throw exceptions for expensive aggregate queries, etc. The goal is twofold: 1) using VoID as a bar, to empirically investigate the extent to which endpoints can describe their own content, and 2) to build and analyse the capabilities of an online catalogue.
TopIntroduction
Linked Data aims at making data available on the Web in an interoperable format so that agents can discover, access, combine and consume content from different sources with higher levels of automation than would otherwise be possible (Heath & Bizer, 2011) . The envisaged result is a “Web of Data”: a Web of structured data with rich semantic links where agents can query in a unified manner – across sources – using standard languages and protocols. Over the past few years, hundreds of knowledge bases with billions of facts have been published according to the Semantic Web standards (using RDF as a data model and RDFS and OWL to provide explicit semantics) following the Linked Data principles.
As a convenience for consumer agents, Linked Data publishers often provide a SPARQL endpoint for querying their local content (Jentzsch, Cyganiak, & Bizer, 2011) . SPARQL is a declarative query language for RDF in which graph pattern matching, disjunctive unions, optional clauses, dataset construction, solution modifiers, etc., can be used to query RDF knowledge bases; the recent SPARQL 1.1 release adds features such as aggregates, property paths, sub-queries, federation, and so on (Harris, Seaborne, & Prud’hommeaux, 2013). Hundreds of public endpoints have been published in the past few years for knowledge bases of various sizes and topics (Buil-Aranda, Hogan, Umbrich, & Vandenbussche, 2013; Jentzsch et al., 2011). Using these endpoints, clients can receive direct answers to complex queries using a single request to the server.
However, it is still unclear how clients (be they human users or software agents) should find endpoints relevant for their needs in the first place (Buil-Aranda et al., 2013; Paulheim & Hertling, 2013). A client may have a variety of needs when looking for an endpoint, where they may, for example, seek endpoints with data:
- 1.
About a given resource, e.g., michael jackson;
- 2.
About instances of a particular type of class, e.g., proteins;
- 3.
About a certain type of relationship between resources, e.g., directs-movie;
- 4.
About certain types of values associated with resources, e.g., rating;
- 5.
About resources within a given context or with specific values, for example, crimes with location u.k. in year 1967 or rat genes and disease strains;
- 6.
A combination of one or more of the above.
Likewise a client may vary in how they are best able to specify these needs: some clients may only have keywords; others may know the specific IRI(s) of the resource, class or property they are interested in; some may be able to specify concrete queries or sub-queries that they wish to answer.
It can be argued that a service offering agents the ability to find relevant public endpoints on the Web would serve as an important part of the SPARQL querying infrastructure, enabling ad-hoc discovery of datasets over the Web. However, realising such a service over the current SPARQL infrastructure on the Web is challenging. Looking at the literature (in particular, works on the related problem of federated querying (Acosta, Vidal, Lampo, Castillo, & Ruckhaus, 2011; Harth et al., 2010; Hasnain et al., 2014, 2017a; Quilitz & Leser, 2008; Schwarte, Haase, Hose, Schenkel, & Schmidt, 2011), authors can find two high-level approaches that have been investigated thus far:
- •
Runtime Queries: The first option is to take an agent's request and query the endpoints directly at runtime to determine if they have relevant metadata or not (Schwarte et al., 2011). For example, if the agent were interested in instances of mo:MusicalWork,1 one could issue a list of endpoints the following query: