While this information is currently only sparsely available from the main LLM service providers, this might be about to change under new EU regulation. The EU’s AI Act Article 53(1)(d), released in July 2025 and set to be enforced from 2nd August 2026, requires AI providers to disclose some minimal information regarding the training content that they use. This includes data size, modalities, languages, names of public datasets, and more.

Transparency over training data should foster good practices for model providers, giving the public oversight of and insight into the models, their biases and possible copyright infringements.

The visualisation below shows a few models that have published a GPAI notice, along with their training data sources. You can also display more models, see whether they used data for pre or post-training in some cases, and hover/click on them for more information.

If you can’t see a model on there, it’s probably because its training data sources have not been disclosed.

This static graph viz was compiled using information disclosed by a few model providers, either in a GPAI notice, in a technical article, or a model card (e.g., on Hugging Face).

Starting from models that had disclosed their training datasets, I created a knowledge graph hosted at https://public-ai-data-sources.wikibase.cloud/. Hosting on wikibase.cloud has several advantages: it’s free, it’s public (to the point that anyone can contribute to it after logging in), and it can interoperate with Wikidata. While Wikidata has a project on AI, it doesn’t have the ideal properties for this project yet (trained on, pre-trained on, GPAI notice…), so I decided to create a new wikibase to experiment freely with a dedicated ontology and database.

Please feel free to edit or improve the knowledge graph directly on the wikibase. I’ll keep updating the visualisation regularly. And if you have any other feedback or questions, please contact me at contact-mario-morvan at pm.me.

Open, collaborative curation of knowledge graphs (KGs) has already contributed to making the internet more structured and trustworthy, and shows promise for continuing to do so in the coming decades. I use the term collaborative knowledge graph (CKG) for KGs that are collaboratively curated by a group of people. Below is a review of different examples of CKGs, identifying three main types of collaboration. The aim is to broadly cover the panorama of CKGs, but certainly not of all open KGs.

Why Knowledge Graphs?

Graphs are most suitable to encode and represent interconnections in data, as edges between nodes. Knowledge graphs add a semantic layer to graphs, whereby nodes become typed entities linked through typed relations or statements. This combined relational and semantic structure is particularly well suited for tracing, verifying, querying information. It can foster not only trust, but also interoperability between different KG databases, using shared standards or principles such as linked data.

In a web whose traffic is increasingly mediated by bots, and where information access is to be mediated largely through search engines and LLMs, structuring data becomes even more important and valuable. As LLM training —and to some extent, inference— break the link between original information sources and output statements, human-curated KGs provide deterministically queriable, verifiable, and answerable knowledge. This structured, high-trust data can then be used in other collaborative projects or to improve the reliability of LLMs through training¹ or inference ²³⁴⁵.

Examples of CKGs

We’ll be using these examples throughout:

• Wikidata⁶, the central knowledge graph of encyclopedic knowledge, used across Wikimedia projects and the most studied KG, collaborative at various layers,
• Wikibase ecosystem⁷, the interoperable pool of KGs built on Wikidata’s software, each with its own community and governance,
• DBpedia⁸, structured knowledge extracted from Wikipedia and a founding hub of the Linked Open Data cloud, where collaboration sits in the extraction framework and ontology mappings rather than data entry,
• ORKG⁹¹⁰, a graph of machine-actionable scholarly knowledge,
• schema.org¹¹, a shared vocabulary/ontology for marking up structured data on web pages,
• OBO foundry¹², a federation of interoperable biomedical ontologies coordinated under explicit shared design principles.

A typology of collaboration in KGs

Collaboration can happen at different levels, namely data entry, ontology or algorithmic curation. These are more continuous dimensions to think of collaboration than separate buckets: a KG can have more or less of each type.

Collaborative data entry

A first way to collaborate on knowledge graphs is to let a group of humans create and edit graph data itself. The resulting KGs are sometimes called crowdsourced KGs.

Wikidata allows anyone —logged in or not— to edit the KG by creating or editing items and statements. It currently has about 44,000 active users monthly, a total of 122 million items, and more than 2 billion edits (labels, references, statements…). Each item carries multilingual labels, and is publicly licensed under CC0, explaining why Wikidata has become a reuse hub across many projects.

Beyond Wikidata, there are hundreds of ‘Wikibases’, i.e. other KGs based on the Wikibase software. These projects are generally managed by different communities, with their own rules and objectives. Among prominent Wikibases featuring collaborative data entry, we find: FactGrid (historical research; ~700 users, passed 1M items Oct 2024, CC0, run by the Gotha Research Centre / NFDI4Memory), Rhizome ArtBase (born-digital art), Lingua Libre (audio), the EU Knowledge Graph,⁷ MaRDI (mathematics, ~7M items), and PersonalData.io. The Wikibase Registry is itself a CKG of KGs. Note however, that many Wikibases are expert-curated communities, not open to anyone like Wikidata.

ORKG invites contributions from logged-in users to add or edit various elements of the KG: not only reviews or metadata about individual papers, but crucially, comparisons between papers that get a DOI each. The resulting scholarly KG is thus crowdsourcing contributions mainly from the researcher community rather than the general public. Contributions such as comparisons, visualisations, reviews and lists can be accessed directly on the website, or via the ORKG Ask platform which uses a LLM with vector-search layer to provide natural language access into the graph.

Collaborative Ontologies

An ontology is the schema layer of a KG: the vocabulary of entity types (classes) and relation types (properties), together with the constraints governing how they legitimately combine. Below I outline three ways in which ontologies can be collaboratively defined: schema emerging from data entry, schema as the product itself, and schema embodied in explicit extraction mappings.

Wikidata’s ontology is itself collaboratively maintained. While anyone can create classes (items, with Q-IDs), proposing properties (with P-IDs) requires community discussion and consensus. This process helps keep the ontology consistent, but can also slow schema evolution and requires active community moderation. In practice, only a small fraction of Wikidata users shape its ontology, suggesting that its collaborative aspect happens more at the data entry level.¹³

Other wikibase-like CKGs manage their ontologies differently. For example, FactGrid which tolerates competing ontologies in one pool. A selling point of wikibases is their support for mapping items with Wikidata or other wikibases, enabling interoperability between wikibases when parts of their ontologies map. However, independently-built ontologies don’t easily map onto Wikibase ontologies, limiting the potential for interoperability¹⁴¹⁵.

Other CKG projects aim at producing a schema as their main product, not as a byproduct of their knowledge building practice. That’s the case of OBO foundry, which federates more than one hundred biomedical ontologies under explicit shared principles, and is open to any interested individuals. We could also mention schema.org, a shared vocabulary for web markup, developed through the W3C Schema.org Community Group but launched and still steered by the major search engines (Google, Microsoft, Yahoo, Yandex). Although its curation process is open and collaborative in principle, it remains tied to corporations and governed by a small number of actors.

DBpedia features yet another collaborative way to curate its ontology. Indeed, it is derived from infobox-to-ontology mappings that are collaboratively maintained through the public mapping wiki. This leads us to our last collaborative dimension, making use of algorithms to curate KGs.

Collaborative algorithmic curation

Several KGs involve the use of algorithms, bots and tools to automate tasks and support humans in the data curation process. When there is a collaborative process to govern the use of these algorithms, we will include this as another dimension of collaboration in KG curation.

DBpedia offers a striking example of collaborative algorithmic KG curation. Indeed, its construction relies solely on an extraction framework and mappings wiki, both collaboratively maintained.

On Wikidata, bots currently account for more than half of the edits, sharing the load with humans. They must follow certain requirements and be approved by the community to perform specific tasks. Although integral to the growth and success of Wikidata, this human-bot collaboration has also created some new challenges.¹⁶¹⁷¹⁸ Beyond bot edits, Wikidata also makes use vandalism-detection models such as those underlying ORES¹⁹, making use of ML models trained on data labelled by volunteers to help volunteers flag vandalism.²⁰ There also are prospects for “significantly improving” the accuracy of these systems,²¹ which would sharpen, rather than remove, the question of algorithmic governance on Wikidata.

Final points

Although we outlined three general categories of collaboration, every project has its own focus community and governance structure. Collaboration varies quantitatively and qualitatively in each case, crossing over different modes with a mix that may vary in time.

Even when there exist collaborative processes, data, ontology or algorithmic curation is often reserved to a small group of skilled developers or domain experts, in some cases with strong ties with major big tech companies (e.g., schema.org). This creates biases and results in power asymmetries affecting most CKG projects.²² Improving the accessibility of editing interfaces and processes would already alleviate some of these issues, but this will likely remain a persisting challenge for these and future CKGs.

In the coming years, we can expect to see CKGs being used for new and varied applications such as fact-checking, impact assessment, value alignment; providing a shared, verifiable substrate for an agent-mediated web, or ground for new forms of human and human-machine collaboration.

References

Often, I wonder who else might be thinking about similar questions, problems, projects, possibly from different perspectives. And, more generally: what do other people need or would want to know? I’m grateful for the efforts that have enabled those questions to be answered, but I feel that we currently still fundamentally lack the appropriate means, whatever they are, to give full justice to these questions.

This post is not an attempt to dictate how exactly projects should be collectivised—though it does touch on the how question throughout—but rather to offer some reasons and examples to make a case for the opening, dare I say commoning, of projects.

Project vision

Explicitly or not, a project makes a claim about what it aims to achieve. A project is thus the vehicle for a sociotechnical vision, whether expressed explicitly or not. This vision may relate to a broader sociotechnical imaginary—inspired from it or actively entertaining it.

Without wanting to restrict, formalise or fixate too much what a project’s motives should be, or even how they could be expressed (semantically, informatively, artistically…), the question of its sought objectives and potential impact is essential.

Project evolution

If a project’s objectives are publicly outlined early on, along with ways to evaluate its real-world impact, then its method can be iteratively adapted to fit its objective better, and other people can provide feedback, join the project or develop alternative solutions to it.

Furthermore, it will help the honest evaluation of a project, perhaps alleviating the publication bias towards positive results affecting sciences. Now, the world itself is moving, and so might a project’s objectives and potential impact over time. It thus sounds reasonable to consider that the different components of a project co-evolve together and with the rest of the world dialectically.

Opening research projects

In terms of research, if the overarching objective is indeed to progress common knowledge and not secure personal profit or intellectual property, then surely the research project would benefit from being publicised early on. Would it matter if someone “stole” the idea? In fact, we should also consider what would be an ecology or economy of projects that is collectively managed, which we’ll discuss below. How and at what stage do researchers share their intents?

The suspicion here is that many projects are really shared only when they are well under way, when their final or intermediate products are published. What’s more, they are shared in ways that prevent others from easily contributing to them. Still, there are existing tools and platforms that foster openness throughout the research lifecycle (e.g., https://www.cos.io/tools, https://openreview.net, https://experiment.com/, https://www.researchhub.com), as well as other tools that help maximise accessibility of research outputs (e.g., https://orkg.org/, https://openalex.org/, https://figshare.com/).

A collectively managed ecology of projects

Consider a large pool of project ideas collected from everyone, and a group trying to prioritise between them. It would be ambitious to try and consider all projects in equal measure (what would this even mean?), and pretentious for anyone to claim that their ideas are worth more consideration than any others. What’s more, it would be silly not to consider the similarities and synergies between projects, past, present and future (through their potential impact), when it comes to planning.

It is a complex problem, highly dependent on group decisions and values at the meta-level, and without a single best “method”, unless a trivial metric is optimised for. Also, rather than referring to a mere economy of projects, I prefer to imagine an ecology of projects, recognising their codependencies and links with the real world. However, even before being able to compare and relate projects in a project space, a shared vocabulary or medium needs to be agreed upon to format and structure projects throughout their lifecycles. For examples, if ‘objectives’, ‘impact’, or some other other aspect are deemed important enough to feature as projects’ properties, it would then be sensible to carefully decide on these shared notions, their definitions (e.g. through a glossary), and relations (through an ontology).

This shared vocabulary, data structure, standards and design form the technical meta-layer of governance on open platforms, and play an instrumental role in shaping how projects are to be conducted and opened. Given their importance, a collectively managed ecology of projects may want to inquire and claim some agency in setting these technical rules.

But how verifiable is Wikipedia in practice? How to improve its effective verifiability? This blog post touches on these questions, and makes a case for accrued use of in-source locators in citations.

Problematic citations

Citations can be problematic in various ways, for example if they contain inaccurate or inauthentic metadata, or refer to dubious/unreliable source. On English Wikipedia, there are 95 different inline templates used to flag verifiability issues, often to do with problematic citations: {{failed verification}}, {{citation not found}}, {{irrelevant citation}}, {{verify source}}, {{AI-generated source?}}, {{AI-retrieved source}}…

Even a correctly formatted citation to a reputable source can be misleading, if the citing statement can’t actually be entailed (i.e. derived) from the cited source(s). While building datasets for automatic verification from Wikipedia by annotating claims with respect to their references, these two research papers point to possibly worrying levels of unsupported statements:

• Petroni et al. 2023¹ estimate that “more than 40% of the time, no evidence can be found in the reference to verify a claim”,
• Kamoi et al. 2023² find that 33% of claims (55.8% of subclaims) are fully supported, while 12.3% of claims (25.9% of subclaims) are not supported, and 54.7% of claims (18.2% of subclaims) are only partially supported.

While these studies cannot be extrapolated to the whole of Wikipedia because of how datasets are constructed and claims annotated, they sugggest that entailment rates might be much lower than expected on the collaborative encyclopedia. Problematic citations pose a risk to knowledge integrity, and thus should urge us to seriously consider the problem of effective claim verification on Wikipedia.

Verifying is hard

Verifying citation entailment meets several hurdles in practice. First, it requires access to the source document, which can be restricted by location, time, cost, language, etc. In a 2018 blog post³, Redi et al. estimated that “less than half of the official versions of scholarly publications cited with an identifier in Wikipedia are freely available on the web”.

Assuming that a citation’s source is accessible, the next step and core of the verification process is to peruse the source in order to identify sufficient evidence justifying the claim. This is what annotators did to label the SIDE¹ and WiCE² datasets.

Note that the verification task is ambiguously defined, since it might not be perfectly clear which part of the citing statement (paragraph, sentence, clause…) exactly is meant to be supported by the source. This led several works to decompose the claims in subclaims², or in predicting the citation span ⁴.

Regardless of whether it is done by humans or automatic systems, verifying citations is a difficult task with associated costs.

Ever more citations

On the below Figure, we show the evolution of the number of citations on the English Wikipedia. We did so by randomly sampling 20000 articles from dumps at different dates, and counting the number of “<ref>” tags as well as other citation templates: {{sfn}}, {{sfnp}}, {{r}}.

Compared to the number of articles that has increased by 1.5x, the number of citations increased by 3.1x from Nov 2014 to Jan 2026. On the one hand, having more and more citations in total and per article is a good sign for verifiability of content. On the other hand, it increases the volume of citations to verify. Assuming that we’d want to verify all Wikipedia citations, this would mean more than 70 million of them in 2026, with a number that increases rapidly. Are we able to keep up with it? And beyond the mere volume, are new citations more or less likely to be problematic than old ones, and in what ways?

Though important, we won’t dig much further into these questions right now. Suffice it to highlight that if problematic citations indeed threaten Wikipedia’s knowledge integrity, then this threat is likely to keep growing because of the increasing number of citations, and not least, the increasing use of AI in editing articles.

Where in the source?

To make the job of verifying citations entailment easier, one can specify which part of the source supports the citing statement. This simple trick saves time to the verifier by limiting the text to be compared against. Wikipedia’s guidelines on citing sources encourages this practice especially for lenghty sources:

“When citing lengthy sources, you should identify which part of a source is being cited.”

“A footnote may also contain a relevant quotation from the source. This is especially helpful when the cited text is long or dense. A quotation allows readers to immediately identify the applicable portion of the reference. Quotes are also useful if the source is not easily accessible. However, caution should be exercised, as always, to avoid copyright violations.”

The “references and page numbers” how-to-guide goes on to suggest that:

“It helps to give a page number or page range—or a section, chapter, or other division of the source—because then the reader does not have to carefully review the whole cited source to find the relevant supporting evidence, which promotes efficient source checking.”

These mentions of in-source location can be made directly in unstructured references, or preferably using dedicated parameters in citation templates, such as p or page for a single page, pages or pp for a range of pages. Lesser used parameters include free-format keyword at, keywords related to chapters (chapter, contribution, entry, article, section), quotes (quote, q, quotation, quotepage, qp, quotation-page, quotepages, qpp, quotation-pages, quote-location, quote-loc, quotation-location, quote-at), court cases (panel, pinpoint, opinion), video games (level, scene), video/audio (episode,time,minute). In the below analysis, all these additional parameters are grouped in the ‘other’ category.

On the Figure below, we show the evolution of the use of in-source locators, estimated by parsing the citations in our random samples at different dates.

Looking at the big picture, it is apparent that the use of locating parameters, even when considering the logical ‘OR’ of them in green, increase more slowly than the total number of citations. Looking at the detail for the 5 most represented citation templates (web, news, book, article, or no template), this discrepancy originates largely from the sharp increase in web-based citations (affecting mainly the ‘cite web’ and to a certain extent ‘cite news’ and other templates too), which very scarcely make use of in-source locators. However, other templates such as book, or journal, also see diminishing fraction of citations using in-source locators in general and the page/p in particular.

In the below barplot, we show the shares of different locators per citation template at the beginning of the year, illustrating the intertemplate discrepancies in the use of in-source locators.

It is worth noting that the high proportion of page ranges specified with the ‘cite journal’ template mostly corresponds to the page range corresponding to full articles in their proceedings, providing no useful information to find information within articles themselves.

Recommendations

• encourage the use of page indications for books, articles, and other page-based sources.
• encourage the use of quotations, especially where pages are ambiguous, or sources hard to access (with caution not to violate copyright law).

Wikipedia’s guidelines and the design of its editing mode could be adjusted to support editors.

Furthermore, similarly with the tools deployed to detect the need for citations, the development and deployment of tools to check citations (authencitiy, accuracy, completeness, in-source precision, mutual span, entailment…) could empower editors to detect possible issues and improve existing citations.

Finally, we suggest the possible use of a platform that would indicate the verification status of citations, with annotations from humans or machines.

Method, Code, Caveats

The code used to produce this analysis and visualisations is available at … Should you have questions on the analysis method, please visit the codebase or contact me directly.

Error bars shown on the trend plots correspond to the 95% confidence intervals around the estimated totals. These are based on estimates of the numbers of citations per article in the 20000 random samples.

A few caveats:

• some citations may include quotes directly in the text, and these are not counted in the in-source locators,
• some citations may have incorrectly formatted location indicators that have not been parsed and thus counted in this analysis, We think that these only represent a small fraction of all citations, and do not change in any significant way the argument,

References