The dblp Knowledge Graph and SPARQL Endpoint

The idea of providing access to dblp data as linked open data is not new. In the very first iteration of the linked open data cloud from 2007 (see Figure 1), dblp was already linked as one of the few early data sources [3, 11]. However, these were always independent contributions from the international computer science community and not an original contribution of the dblp team. These earlier contributions were based on snapshots (current at the time) of the public XML dump export and were generally not updated after creation. Given the continuous additions and maintenance by the dblp team, which make dblp a ‘living’ dataset, these conversions were quickly out of sync with the live data. Many of the external live services, in particular SPARQL endpoints, have vanished from the web in the meantime.

The probably earliest RDF conversion of the dblp dataset has been exercised as a benchmark example for the declarative mapping language D2RQ in 2004 [10]. The data was later released together with an accompanying SPARQL endpoint using the D2R Server tool [9].²²2https://web.archive.org/web/*/http://www4.wiwiss.fu-berlin.de/dblp/ (archived) This conversion provided entities for up to 800,000 articles and 400,000 authors and hasn’t been updated since 2007.

At about the same time, further conversions and SPARQL endpoints were the D2R Server in the context of the Faceted DBLP³³3https://web.archive.org/web/*/http://dblp.l3s.de/d2r/ (archived) search engine [17] and the RKBExplorer⁴⁴4https://web.archive.org/web/*/dblp.RKBExplorer.com (archived) [21, 20]. These RDF datasets have been actively used for a long time and are a subject or component of numerous computer science publications. E.g., a simple Internet search using Google Scholar with query "fu-berlin.de/dblp" OR "dblp.l3s.de/d2r" OR "dblp.RKBExplorer.com" finds at least 380 results,⁵⁵5Accessed on 2024-06-12. with citing papers still being published today in 2024.

Other graph datasets used dblp data as a starting point to build improved and extended semantic information. For example, the SwetoDblp ontology and dataset⁶⁶6https://web.archive.org/web/*/http://knoesis.wright.edu/library/ontologies/swetodblp (archived) augmented dblp XML data with relationships to other entities such as publishers and affiliations [2, 1]. The GraphDBLP tool⁷⁷7https://github.com/fabiomercorio/GraphDBLP models the dblp data from 2016 as a graph database and, in doing so, allows for performing graph-based queries and social network analyses [31, 30]. The COLINDA dataset⁸⁸8https://web.archive.org/web/*/http://www.colinda.org/ (archived) provided a linked data collection of 15,000 conference events, augmenting dblp proceedings data with location, start and end times, geodata and further links [39, 38]. More recently, the EVENTSKG knowledge graph⁹⁹9http://w3id.org/EVENTSKG-Dataset/ekg provided a semantic description of publications, submissions, start date, end date, location, and homepage for events of top-prestigious conference series in different computer science communities [18]. Semantically structured metadata on scientific events was later also made accessible via the ConfIDent platform¹⁰¹⁰10https://www.confident-conference.org/ [22, 19].

Independently of dblp and beyond the discipline of computer science, several international efforts have been launched in recent years to provide open scientific knowledge graphs. Wikidata¹¹¹¹11https://www.wikidata.org is the collaborative, omnithematic, and multilingual knowledge graph hosted by the Wikimedia Foundation [40]. Within Wikidata, the WikiCite project¹²¹²12https://www.wikidata.org/wiki/Wikidata:WikiCite aims to create an open, collaborative repository of bibliographic data. OpenCitations¹³¹³13https://opencitations.net maintains and publishes open citation data as linked open data, thereby providing the first truly open alternative to proprietary citation indexes [35]. Initially an outcome of the EU Horizon 2020, the OpenAIRE Graph¹⁴¹⁴14https://graph.openaire.eu was one of the first comprehensive research knowledge graphs [29]. Since then, OpenAIRE has consolidated its organizational structure and the OpenAIRE Graph is now the authoritative source for the European Open Science Cloud (EOSC).¹⁵¹⁵15https://eosc-portal.eu/ OpenAlex¹⁶¹⁶16https://openalex.org/ is a recent open infrastructure service, built on the data of the now abandoned Microsoft Academic Graph¹⁷¹⁷17https://www.microsoft.com/en-us/research/project/microsoft-academic-graph/. OpenAlex is a massive, cross-disciplinary research knowledge graph of publications, authors, venues, institutions, and concepts [36]. Furthermore, the Open Research Knowledge Graph (ORKG) aims to make scientific knowledge fully human- and machine-actionable by describing research contributions in a structured manner, e.g., by connecting research papers, datasets, and used methods [25]. The ORKG aims to build a community of contributors in order to collect, curate, and organize descriptions of scientific contributions in a crowd-sourcing manner.

In this article, we introduce the dblp Knowledge Graph (dblp KG). The dblp KG aims to make all semantic relationships modeled in the dblp computer science bibliography explicit. In contrast to previous approaches, the dblp KG is not merely based on a one-time snapshot of dblp data, but is actively synchronized with the current data. In particular, the dblp KG thus benefits from the continuing curation work of the dblp team.

The dblp KG aims to complement other open knowledge graphs by bringing in dblp’s unique strengths in author disambiguation, semantic enrichment of bibliographies, and its role as a directory of computer science journals and conferences. We demonstrate this by augmenting our dataset with identifiers and citation data from the OpenCitations corpus.

Open and FAIR access to the data is provided via daily updated RDF dumps, persistently archived monthly releases, a new public SPARQL endpoint with a powerful user interface, and a linked open data API. We also make it easy to self-host a replica of our SPARQL endpoint.

The rest of this article is organized as follows. In Section 2, we introduce the ontology of the dblp KG and present statistics about the graph. Section 3 describes the different ways to access the dblp KG and the citation data. Section 4 provides an introduction on how to work with the dblp KG and the added citation data using our SPARQL endpoint, with several example queries, and complemented by a small performance evaluation. Section 5 concludes the article with a short discussion and an outlook.

As there already is a whole range of ontologies that model bibliographic information about scientific works (e.g., see [14, 32, 24]), the dblp ontology is explicitly not intended to replace them. Instead, it is designed to model the way dblp handles and provides bibliographic metadata, including all possible quirks and oddities that may arise from dblp’s unique approach. For example, dblp’s author disambiguation uses certain ‘pseudo-author entities’ (described in more detail in Section 2.1.1 below) to model cases where the true authorship of a work is currently unknown or ambiguous. Also, dblp’s records are incompatible with the more fine-grained FRBR model [34] that is standard in the library community.¹⁸¹⁸18In particular, the dblp data model generally does not distinguish between the FRBR layers Work and Expression and does not address the layers Manifestation or Item at all. Therefore, it was not viable to reuse existing ontologies, as is usually recommended. However, links to related types and predicates from existing ontologies are provided in the dblp RDF schema whenever possible.

In the remainder of this section, entity refers to any resource accessible via an IRI, a literal, or an anonymous node. It is synonymous with the term resource as defined in [12]. Entities in the dblp ontology are assigned certain core and reification types that stem from the dblp internal data model, and relations between entities are modeled using predicates. The types of the dblp ontology and their connections are described below, and a simplified view of the ontology is presented in Figure 3. The full dblp ontology reference documentation can be found at https://dblp.org/rdf/docu/.

This section presents several key statistics of the dblp Knowledge Graph to give an overview of its content and dimension. Table 5 shows the number of entities per type, and Table 6 shows the number of identifiers by schema. The SPARQL queries used to create the statistics can be found online²⁰²⁰20https://github.com/dblp/kg/wiki/Paper-TGDK-2024#statistics-queries, each with a direct link to our SPARQL endpoint that will then execute the corresponding query. The statistics in this paper are based on the dump from September 11th, 2024.

The majority of publication entities are conference proceedings papers (47.43%) and journal articles (39.22%). Informal publications (9.25%), such as preprint publications on arXiv, also form a significant share of publications. The other publication types each form less than 3% of the corpus.

Less than 0.01% of all creator entities are of type dblp:Group because we aim to present individual authorship where possible. Individual authors of type dblp:Person form the vast majority (99.58%) of creator entities. The manually identified dblp:AmbiguousCreator entities only form a small fraction (0.41%).

In contrast to many other research fields, where journals are the predominant medium, conferences play a crucial role in disseminating research in computer science. Many conferences only take place once or twice, while journals tend to be much more long-lived. In addition, conferences are often divided into workshop series which may also form their own entities. All this explains why there are three times as many conference entities (76.18%) as journal entities (21.27%) in the dblp KG. Currently, there are only 6 repository streams in the dblp KG because the support for data publications, which are modeled to be published in repositories, has only recently been added to dblp.

The almost 6 million DOIs are the most often occurring identifier in the dblp KG. In addition to about 170,000 distinct ORCID IRIs manually linked to creators using dblp:orcid in the dblp KG, we also link to more than one million distinct ORCID IRIs on signatures via dblp:signatureOrcid. Other than ORCIDs linked to creator entities, ORCIDs linked to signatures are automatically harvested from metadata and have not been manually verified by the dblp team.

We provide daily updated RDF exports of the dblp KG in RDF/XML, N-Triples, and Turtle formats.²²²²22https://dblp.org/rdf/ These are useful for tools and services that need the latest version of the data. Further, we publish persistent monthly releases of the dblp KG in N-Triples format [15] and recommend using these persistent releases for reproducible experiments and similar purposes. We also provide serializations of the RDF schema of the dblp KG ontology described in Section 2.1. This schema is rarely changed, and all previous versions of the schema are persistently available.

We also provide daily updated dblp RDF exports augmented with citation data²³²³23https://sparql.dblp.org/download/, obtained from the OpenCitations project, which provides open-access citation data for publications across all areas of science [13]. OpenCitations assigns each publication an identifier (called OMID), which is also provided in the dblp KG; see Section 2.1.1. We filter the whole OpenCitations corpus to the subset of citations that are concerned with publications listed in dblp and provide the combined graph. The connection between dblp and OpenCitation entities is done via the predicate dblp:omid (see Section 2.1.1). Please be aware that while the OpenCitations data is updated only infrequently, the dblp KG is updated daily. Thus, the combined dataset is also updated daily.

We provide a public SPARQL endpoint for the combined data described in Section 3.2 under https://sparql.dblp.org/sparql, powered by the QLever SPARQL engine [6] [8].²⁴²⁴24https://github.com/ad-freiburg/qlever The SPARQL endpoint is updated daily, in sync with the daily releases of these datasets. The endpoint conforms with the SPARQL 1.1 Protocol²⁵²⁵25https://www.w3.org/TR/sparql11-protocol/, currently still with minor deviations. These are documented in the dblp KG Wiki²⁶²⁶26https://github.com/dblp/kg/wiki/Known-Issues and will be fixed in the near future. The SPARQL endpoint makes it very easy to build services or tools on top of the dblp KG. Section 4.6 briefly analyzes its performance.

The endpoint also comes with a user interface, available under https://sparql.dblp.org, for the interactive formulation and execution of SPARQL queries. The user interface provides various features to help people that are unfamiliar with the intricacies of the dataset or of the SPARQL query language, most notably context-sensitive suggestions (autocompletion) after each keystroke. This is explained in more detail in Section 4.2, for the example query from Section 4.1. The user interface also features a button, which opens a searchable list of example queries.

The SPARQL endpoint described in the previous section is publicly and freely available. To enable a continuous service, there is a fixed timeout for each query, and at some point, we might also introduce rate limits or quotas. For users with high query volumes or other special requirements, we provide instructions for setting up their own SPARQL endpoint and user interface,²⁷²⁷27https://github.com/dblp/kg/wiki/SPARQL-server-setup with the exact same functionality as described in Section 3.3, using the exact same dataset. This setup requires only a few commands and works with standard hardware; see Section 4.6.

Beyond the examples of the query interface, we also provide links with preformulated SPARQL queries embedded into various pages across the dblp website, as shown in Figure 4. In particular. each author page now features a box with links to related SPARQL queries, such as a query to calculate the most highly cited co-authors of the author described on the page. Similarly, each conference or journal page features a box with links to related SPARQL queries, such as a query to calculate frequent authors for this conference, or conferences with a large overlap regarding authors. These embedded queries are useful in three respects: (1) they provide interesting information that complements the information provided on the respective page, (2) they draw attention to the SPARQL endpoint for users that might otherwise miss this opportunity, and (3) it is an easy and motivating way to learn by example what is in the dblp KG and how to query it.

Finally, we provide an API for individual pieces of RDF data for creators, publications, and streams. This data is guaranteed to always be up-to-date with the current state of the dblp database. The URLs of this API all follow the same structure: a dblp resource IRI, followed by a file extension corresponding to the requested file format as given in Table 7. For example, for the creator resource IRI https://dblp.org/pid/71/4882 there is
https://dblp.org/pid/71/4882.rdf for retrieving RDF/XML,
https://dblp.org/pid/71/4882.nt for retrieving N-Triples,
https://dblp.org/pid/71/4882.ttl for retrieving Turtle,
https://dblp.org/pid/71/4882.html for the dblp HTML website.
Similarly, for publications, there is
https://dblp.org/rec/conf/semweb/AuerBKLCI07.rdf for retrieving RDF/XML,
https://dblp.org/rec/conf/semweb/AuerBKLCI07.nt for retrieving N-Triples,
https://dblp.org/rec/conf/semweb/AuerBKLCI07.ttl for retrieving Turtle
https://dblp.org/rec/conf/semweb/AuerBKLCI07.html for the dblp HTML website,
and for stream entities, there is
https://dblp.org/streams/conf/semweb.rdf for retrieving RDF/XML,
https://dblp.org/streams/conf/semweb.nt for retrieving N-Triples,
https://dblp.org/streams/conf/semweb.ttl for retrieving Turtle,
https://dblp.org/streams/conf/semweb.html for the dblp HTML website.

SPARQL is the standard query language for querying RDF data. The language can be seen as a variant of SQL (the standard query language for relational databases), adapted to the RDF data model. Namely, just like RDF data is a set of triples, the core of a typical SPARQL query is a set of triples, with variables in some places. Following is an example query that asks for the titles of all papers in dblp published until 1940, their authors, and the year of publication:

Run this query  
Conceptually, the result of a SPARQL query is a table. For the query above, that table has three columns (labeled ?title, ?author, and ?year), and one row for each possible assignment to these three variables such that all the corresponding triples in the query body exist and all the additional constraints (in this case, the FILTER condition) are fulfilled. For example, the first five result rows for the query above are as follows:

Note that if a paper has $k$ authors, there are $k$ rows for that paper in the result (as in rows four and five above). If a paper had $k_1$ authors and $k_2$ titles, there would be $k_1\cdot k_2$ result rows for that paper, one for each combination. Such Cartesian products are unexpected for many SPARQL beginners and can lead to very large results, in particular, when making mistakes in the query formulation.

Writing a correct SPARQL query requires knowledge about the SPARQL query language in general as well as about the structure of the concrete knowledge graph. For the example query above, the following skills are required:

1. 1.

   Getting the general syntax right: how to write a SELECT statement, how to write a FILTER expression, how to write an ORDER BY clause.

2. 2.

   Knowing the names of the RDF types and entities needed for the query, here: dblp:title, dblp:authoredBy, and dblp:yearOfPublication.

3. 3.

   Knowing the right PREFIX definitions and where to put them (the first few lines in the query above).

The user interface helps with all of these by offering incremental context-sensitive autocompletion after each keystroke. We recommend to go to https://sparql.dblp.org and try the following instructions live.

By simply typing ‘S’, the UI suggests the whole template for a SELECT clause (needed for most queries). After having typed the first variable ?paper in the body of the SPARQL query, the UI will suggest predicate names, which are searchable by typing a prefix such as ‘ti’ (for title). When selecting a predicate, the corresponding PREFIX statement will be automatically added at the top of the query. After entering the variable ?paper a second time, the UI will suggest only those predicates that would lead to a non-empty result together with the already typed ?paper dblp:title ?title. This narrows down the selection considerably. Continuing this way, the user can type a query from left to right, top to bottom relatively easily with minimal input and minimal knowledge of the syntax and the details of the knowledge graph. The details of this mechanism, along with example queries for other RDF datasets, are described in [7].

The following query returns all papers published at STOC 2018, and for each paper the number of all its authors, the number of its ORCID-certified authors, and the ratio between the two. The results are ordered by that ratio, largest first. The query makes use of the signatures in the dblp KG (see Section 2) as well as of several more advanced SPARQL features.

Run this query  
Here are the top-5 results:
?paper ?num_authors ?num_orcid ?perc https://dblp.org/rec/conf/stoc/Cheraghchi18 1 1 100 https://dblp.org/rec/conf/stoc/Filos-RatsikasG18 2 2 100 https://dblp.org/rec/conf/stoc/BergBKMZ18 5 4 80 https://dblp.org/rec/conf/stoc/ChattopadhyayKL18 4 3 75 https://dblp.org/rec/conf/stoc/ByrkaSS18 3 2 67
Let us break down the main components of this query:

• $\mathrm{■}$

  Each paper has one signature per author, that is, the pattern ?paper dblp:hasSignature ?signature will have one match for each author of each paper.

• $\mathrm{■}$

  A signature might or might not have an ORCID associated with it. The OPTIONAL ensures that no signature will be left out, but if there is no ORCID, the value for ?orcid is undefined.

• $\mathrm{■}$

  The GROUP BY groups the information by paper, that is, there will be one row per paper in the result. As a consequence, any other variable used in the SELECT clause has to be aggregated so that we get one value for each paper: COUNT(?signature) counts the number of authors, COUNT(?orcid) counts the number of ORCIDs that are not undefined, and ?perc is computed as the ratio between the two, expressed as a percentage and rounded to the nearest integer.

• $\mathrm{■}$

  The ORDER BY ensures that the results are ordered by the percentage, highest percentage first. Note that by default, the result of a SPARQL query is unordered (and an endpoint can produce them in an arbirtrary order).

Federated queries request data from more than one SPARQL endpoint. By design, RDF and SPARQL are particularly well suited for such queries because there is no dataset-specific schema (conceptually, every RDF dataset is just a set of triples) and because all identifiers are globally unique (just like IRIs). Connections between datasets are established by reusing identifiers from the other dataset or by having extra triples that relate the identifiers to each other.

For example, the following query returns all SIGIR authors that exist in Wikidata with a link to dblp (via Wikidata’s wdt:P2456 predicate), and the location of their birthplace (which can then be shown on a map).

Run this query  
Let us break down the three main components of this query:

• $\mathrm{■}$

  The first four lines of the query body are a so-called subquery, which is a full SPARQL query enclosed in { ... }. The result of that subquery is a table with one row per dblp author and two columns: the author ID from dblp and the number of papers from that author in dblp.

• $\mathrm{■}$

  The next two lines augment that table by two more columns: the name of the author and the Wikidata IRI of that author. Note that both of these predicates are functional, that is, for each distinct subject there is at most one object.

• $\mathrm{■}$

  The remaining four lines of the query body are a SPARQL query to another SPARQL endpoint, with the URL https://query.wikidata.org/sparql. The result is a table with one row per entity in Wikidata that has a birthplace (these are mostly people) and three columns: the IRI of that person, their birthplace, and the coordinates of that birthplace.²⁹²⁹29We here assume that both of these predicates are functional, which may not always be true. This could be addressed by a slightly more complex query, or by accepting that there will be multiple rows for the same person. If the IRIs for ?person_wd from Wikidata are compatible with the IRIs for ?person_wd from dblp (which they are), the join of the two tables then gives the desired result.

• $\mathrm{■}$

  The reason for the commented out first line of the SERVICE query is as follows. Without that line (or when it’s commented out), the SERVICE query produces a large result, namely a table of all people in Wikidata together with their birthplace and the respective coordinates (3.5 million rows at the time of this writing). Transferring this result to the dblp SPARQL endpoint would be very expensive, and there are two ways to avoid that. One way makes use of the fact that the part of the query before the SERVICE gives only relatively few results, namely one row per author who has published at SIGIR (around one thousand at the time of this writing). The corresponding matches for person_wd can be sent to the Wikidata SPARQL endpoint using a VALUES clause to restrict the result of the SERVICE query.³⁰³⁰30This optimization is even discussed and suggested in the official SPARQL standard, see https://www.w3.org/TR/sparql11-federated-query/#values. QLever indeed automatically performs this optimization for small sub-results, so also for the given query (The exact threshold is configurable). The other way is to comment in the commented out line, which would restrict the result of the SERVICE query to only those persons with a dblp ID (around 71K at the time of this writing). For this particular query, the second way has the disadvantage that the query excludes dblp authors who do have an entry in Wikidata, but where the wdt:P2456 predicate, which links authors to their dblp identifier, is missing (18 authors at the time of this writing). The second way would however be necessary if we wanted to perform the query for all 3.6 million dblp authors (not limited to SIGIR).

It is very natural to query the combined data from the dblp KG (Section 3.1) and the added citation data (Section 3.2). We could have set up a separate endpoint for each of these datasets and then use federated queries as shown in the previous section. However, there is always an overhead associated with federated queries because potentially large amounts of data have to be transferred between endpoints in one of the standard serialization formats. We therefore decided to provide both datasets in a single endpoint, as explained in Section 3.3.

Here is a typical example query to our endpoint that makes use of both datasets. It results in a list of all publications of Donald E. Knuth with at least one citation, ordered by the number of citations (most cited paper first).

Run this query  
This query is easy to understand given the concepts already explained in the previous sections. The second to last pattern of the query connects each publication to its OMID (the identifier used by OpenCitations, see Section 2.1.1). The last pattern produces one match for ?cite for every citation. Grouping by ?publ and using COUNT(?cite) for aggregation gives us the number of citations per publication.

Note that the result will only include publications that have an OMID and at least one citation. For the query above, this is true for only 100 of Donald Knuth’s 184 publications in dblp. To include all publications, the last two patterns could be included in an OPTIONAL { ... }, see Section 4.3.

Our SPARQL endpoint and its user interface described in Section 3.3, as well as the embedded queries described in Section 3.5, are all powered by the QLever SPARQL engine. QLever is free and open-source software (FOSS), provided under a permissive license. QLever’s primary design goal is to be efficient even on very large knowledge graphs (with up to hundreds of billions of triples), on a single machine using (relatively cheap) standard hardware. Compared to other knowledge graphs, the dblp KG is medium-sized (around 400 million triples), even if combined with the OpenCitations data (giving a total of around 1.2 billion triples). But even on a graph of this size, queries can be expensive and an efficient engine is key for a good user experience.