Most scientific publications name the institutions their authors were affiliated with at the time of writing. The information is recorded alongside the author names, and it often sits in the metadata that dblp processes.
We are happy to announce that this information is now properly represented in our data: research institutions have become proper entities in the dblp computer science bibliography. The affiliations that connect people and publications to those institutions are now recorded as data as well. In practice, this means five new things:
- you can filter publication lists by affiliation,
- institutions have their own landing pages on dblp.org,
- you can search for institutions just like you search for authors or venues,
- institutions and affiliations are part of the dblp Knowledge Graph,
- and they are therefore also available in our SPARQL query service.
This work is a main outcome of SmartER Affiliations, a joint project of Schloss Dagstuhl, GESIS – Leibniz Institute for the Social Sciences, and the Institute of Databases and Information Systems at Ulm University, funded by the German Research Foundation (DFG).
Below, we introduce the new features, explain how the data fits together, and give some numbers on coverage.
Institutions and affiliations
An institution is an entity. It has an identity of its own, recorded under a dblp identifier that starts with inst/, together with its names, acronyms, external identifiers, and other data. This data is found on the institution’s landing page (cf. the screenshot further down below), just as with other entities in dblp. Institutions exist independently of whether anyone is currently affiliated with them. dblp currently knows more than 10,000 institutions in 195 countries.
An affiliation is a link between entities. It says that some entity in dblp is connected to an institution. The relationship itself is the thing being recorded, and it carries its own metadata, such as the time span it covers and whether it is a person’s current or a former affiliation.
In dblp, that link comes in two variants:
Person-based affiliations connect a person to an institution. These are recorded manually by dblp curators, which makes them deliberate and reviewed, but also far fewer than the automatically retrieved ones: about 256,000 affiliation statements for some 195,000 people (of about 4,2 million persons total). The large majority describe a person’s current institution, and around 24,000 are marked as former affiliations. On author pages, they still appear as the free-text notes you may know from before, but in dblp’s data they are now links to institution entities.
Signature-based affiliations connect a signature to an institution. A signature is the link between a publication and one of its authors, the concrete act of that person authoring that paper. Signature-based affiliations therefore express something much more specific: “in this paper, this author gave this institution as their affiliation.” These affiliations are retrieved automatically at scale, mainly by extracting and matching affiliation statements from publication metadata. About 60% of all signatures in dblp currently carry at least one signature-based affiliation.
Filtering publications by affiliation
The most immediately visible change is that publication lists can now be filtered by affiliation. On the pages where this applies, you will find affiliations as a new facet next to the filters you already use, and it can be freely combined with them.
New filter facet: “refine by affiliation”
This filter operates on signature-based affiliations, and what it matches depends on where you are. On an author page, refine by affiliation offers that person’s own affiliations and filters by those alone, so you get the papers this author wrote while at that institution. Everywhere else, in search results and on tables of contents, refine by institution matches a publication if any of its authors gave that institution on that publication.
Either way, the result is a subset of the papers in this view that are known to have been written at the institution. Obviously, someone who has just moved there does not bring their earlier publications along with them.
What any of these filters can return is limited above all by whether affiliation data exists at signature level, and very often it does not. So you get the publications for which we currently have an affiliation statement that we were able to match with sufficient confidence, rather than everything an institution has published. The data is knowingly incomplete, and we treat it as work in progress that will keep improving. More on the limits of the data below.
Institution landing pages
Every institution in dblp now has its own page. It collects what dblp knows about the institution and what the institution links to:
- the preferred name, plus alternative names, translations, and acronyms we know about,
- basic descriptive information, such as the institution’s location(s) and related institutions,
- a visit menu with links to the institution’s own web presence, its Wikipedia article, and authority control records,
- an export institution menu offering XML and three RDF serializations, along with the dblp key of the institution, for example
inst/11/687, - an ask others menu that hands the institution over to external search services,
- and the people affiliated with the institution, including those who earned their PhD there. This listing does not distinguish current from former affiliations.
Wherever possible, the page contains links to the institution’s data records in other projects and services. The underlying institution data is kept in sync with ROR, so that changes there find their way into dblp as well.
Institutions are also browsable by country, in the same way you browse the rest of dblp.
Institution landing page – here: Schloss Dagstuhl
Searching for institutions
Institutions have also been added to dblp’s search. You can look them up by their preferred name, by an alternative name, or by an acronym, and follow the result straight to the institution’s landing page.
Searching for an institution – here: combined search
Where the data comes from
Two different kinds of data come together here: the affiliation statements of the publications, and the institutions they are matched against.
The affiliation statements (i.e., where each author was based when working on the paper) mostly come from the data we receive from the publishers. A further source is OpenAlex.
Our main source for institution data is the Research Organization Registry (ROR). ROR is an open, community-maintained registry of research organizations, released under CC0. It provides persistent identifiers, name variants and acronyms, location information, and links to other identifier systems. Building on ROR means that institutions in dblp are identified in a way that can be joined with data from anyone else who uses ROR IDs — which by now is a large part of the scholarly metadata landscape.
That said, we do not simply mirror ROR. We continue to curate institutions ourselves, because our requirements do not always match those of a general-purpose registry. Computer science has its own history of institutional mergers, renamings, and re-organisations. Some organisations that matter for our data are not (or not yet) in ROR. And matching thousands of messy affiliation strings to a registry inevitably produces cases that need a human decision. Where ROR and dblp differ, the dblp record reflects a curatorial choice we made on purpose. About four in five of our institutions carry a ROR ID; the rest are ones we maintain on our own.
No faculties, no departments, no institutes
dblp does not model faculties, departments, institutes, or research groups as entities of their own. Generally speaking, the university is the lowest level of granularity we model. An affiliation statement naming a specific chair at a specific institute of a specific faculty of a university becomes an affiliation with that university, although the full text of the statement is kept.
This loses information that some users would like to have. However, sub-institutional units are unstable. They are founded, merged, renamed, and dissolved far more often than their parent organizations, and reconstructing that history retroactively for decades of publications is not realistic. They are also inconsistently reported: the same group may appear as a chair, an institute, a department, or nothing at all, depending on the publisher’s template and the author’s mood. And they are largely absent from the external registries we rely on for identifiers. So we draw the line at the level we can keep consistent across the whole database.
Not every institution is a university, of course. Companies, non-university research institutes, government labs and hospitals are modeled in the same way, and the same rule applies to them: we record the organization, not its individual divisions or labs.
There are a few exceptions where an organization that is formally a part of a larger body is nevertheless modeled as its own institution; typically when it is a distinct legal or research entity with its own identity in ROR. As a rule of thumb, though, we model whole organizations rather than their parts.
Institutions in the dblp Knowledge Graph and SPARQL
As announced in our post on the SPARQL query service, extending the dblp Knowledge Graph with institution entities and affiliation links was one of our declared next steps. Institutions and person-based affiliations are now part of the dblp KG, are included in our RDF dumps (starting October 2026), and are queryable at https://sparql.dblp.org. Signature-based affiliations will follow.
Institutions are modeled as dblp:Institution, carrying their names, their ROR ID in dblp:ror, and their location. Person-based affiliations connect an author to an institution through dblp:affiliatedWith, with the details of a single affiliation, such as the time span it covers, reachable through dblp:hasAffiliation. The full set of new classes and properties is documented in the dblp RDF schema.
Because affiliations are links rather than attributes, the interesting queries are the ones that traverse them. For example, you can list the institutions with the most affiliated people in dblp:
PREFIX dblp: <https://dblp.org/rdf/schema#>
SELECT ?name (COUNT(DISTINCT ?pers) AS ?people) WHERE {
?pers dblp:affiliatedWith ?inst .
?inst dblp:primaryInstitutionName ?name .
}
GROUP BY ?name
ORDER BY DESC(?people)
LIMIT 20(Run this query on sparql.dblp.org)
Institutions also carry their ROR ID in dblp:ror and a link to Wikidata in dblp:wikidata, so the data can be combined with any other source that uses those identifiers. Wikidata, for instance, knows when an institution was founded, which is something dblp does not record. The query below takes the 500 institutions with the most affiliated people in dblp and sorts them by their founding date:
PREFIX dblp: <https://dblp.org/rdf/schema#>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT ?name (year(xsd:dateTime(?inception)) as ?inceptionYear) WHERE {
{
SELECT ?wikiq ?name (COUNT(DISTINCT ?pers) AS ?people) WHERE {
?inst a dblp:Institution ;
dblp:primaryInstitutionName ?name ;
dblp:wikidata ?wikiq .
?pers dblp:affiliatedWith ?inst .
}
GROUP BY ?wikiq ?name
ORDER BY DESC(?people)
LIMIT 500
}
SERVICE <https://qlever.dev/api/wikidata> {
?wikiq wdt:P571 ?inception .
}
}
ORDER BY ?inception(Run this query on sparql.dblp.org)
As we noted when the query service was launched, federated queries can be slow, and the number of results exchanged between the two endpoints needs to be kept in check. That is what the inner query with its limit is for.
Limits of the data
Coverage is uneven. About 60% of all signatures in dblp currently carry an affiliation, 18.2 million out of 30.3 million. For most of what we index, coverage is good. The largest publishers account for roughly two thirds of all signatures, and for those, coverage is typically above 70%. What pulls the average down is a small number of clearly identifiable gaps. By far the largest is arXiv: its publications account for 2.6 million signatures in dblp, and fewer than 2,000 of them currently carry an affiliation. We are actively working on closing that gap. A few smaller gaps exist elsewhere, mostly where affiliations are not part of the metadata we receive. Coverage also peaks for publications from the mid-2010s and declines for recent years, mostly because the affiliation data for recent publications has not been processed yet.
Automatic extraction makes mistakes. Signature-based affiliations are machine-generated. Names are ambiguous, institutions get renamed, “Cambridge” is not one place, and multi-affiliation authors are common. We invest a lot of effort into matching and into feeding curator corrections back into the pipeline, but errors remain.
Please do not build rankings out of this. The count of publications per institution in dblp says at least as much about the coverage of affiliations in dblp as it does about the institutions themselves. dblp’s scope is computer science, its indexing decisions are editorial, and affiliation coverage is a moving target. The data works well for exploration, discovery, and disambiguation but it makes a poor basis for evaluating institutions, and we would ask you not to present it that way.
Affiliations are historical, i.e., a signature-based affiliation records what a paper said at the time it was published. It is not a statement about where someone works today, and an author who moves does not take their earlier publications with them. Person-based affiliations work differently. They can carry a time span, and they distinguish a person’s current affiliation from former ones. They are also manually curated, and therefore far fewer in number.
Corrections and feedback
Wrong affiliations and wrong institutions can be corrected like any other data error in dblp.
If you notice a systematic problem — an institution that has been split into duplicates, a merger we have not caught up with, a matching error that affects a whole venue — telling us about the pattern is much more valuable than reporting individual cases. You can always reach the dblp team at dblp(at)dagstuhl.de. For questions and discussion about the knowledge graph and the SPARQL service, our GitHub Discussions forum is the better place.
Outlook
There are some things left to do, for example bringing signature-based affiliations into the knowledge graph. We will also use the new affiliation data in our own curation work, above all for author disambiguation.
We are very interested in how you end up using this data: both because it helps us set priorities, and because affiliation data has a way of revealing use cases nobody anticipated.
Acknowledgement
The work described in this post has been carried out as part of the project SmartER Affiliations: Enhancing Open Repositories through Harvesting and Extracting Affiliation Data as First-class Citizen, a cooperation of Schloss Dagstuhl – Leibniz Center for Informatics, GESIS – Leibniz Institute for the Social Sciences (Brigitte Mathiak and Asif Suryani), and the Institute of Databases and Information Systems at Ulm University (Ansgar Scherp and Florian Hauss). The project is funded by a grant of the German Research Foundation (DFG) within the funding program “e-Research Technologies” (grant project number 515537520).
We would also like to thank the ROR community for maintaining an open registry of research organizations, without which this feature would have looked very different, and much worse.