Jump to content

Research:Developing a wiki-integrated workflow to build a living review on just sustainability transitions

Add links
From Meta, a Wikimedia project coordination wiki
Created
09:22, 15 May 2025 (UTC)
Collaborators
Romain Mekarni, Rémy Gerbet , Arthur Perret, Finn Årup Nielsen, Dariusz Jemielniak, Amélie E. Pereira
Duration:  2025-09 – 2027-03
Grant ID: G-RS-2504-18935

This page documents a planned research project.
Information may be incomplete and change before the project starts.


Upcoming project events:

[edit]

- 1er december (online, french) Wikicafé : De la réponse à un appel à projet de la Fondation Wikimédia à la publication des résultats : retour d'expérience du projet d'utilisation de Wikidata pour faire une revue de littérature par Adélie Ranville https://fr.wikipedia.org/wiki/Projet:Wikifier_la_science/WikiCaf%C3%A9s

Summary

[edit]

This research project focuses on developing a living literature review on just sustainability transitions, addressing the challenges of information overload, knowledge synthesis and dissemination in academic research. We aim to assess the potential of Wikidata for creating an enriched, searchable academic knowledge graph on just sustainability transitions in order to facilitate navigation of existing academic knowledge and synthesis of research findings. To do so, we will conduct a meta-review of existing literature reviews, aiming to synthesize their findings by making the data they include interoperable and compatible with linked open data standards. Utilizing Wikidata, the project will collect and enrich bibliographic data, extract research results, and build a knowledge graph. The final output will include a literature review academic paper linked to this knowledge graph and a technical report about the challenges encountered in our literature review workflow. The project aligns with Wikimedia's strategic goals by contributing to filling content gaps on an important topic and by proposing an innovative way to build and disseminate social sciences results that could improve expert contribution to Wikimedia project and content trustworthiness.

Adressed Wikimedia Foundation Goals :

Methods

[edit]

Our study will rely on a meta-review, that is a review of existing literature reviews. Data presented in literature reviews are usually presented as tables or diagrams, and sometimes provided as supplementary materials in publications. However, these data are not made interoperable and are not used to update prior literature reviews. Our goal will be to synthesize results of previous literature reviews by making their findings compatible with linked open data and open science standards using Wikidata, Wikiversity, Wikipedia and other open-science infrastructures. We will collect and enrich bibliographic data, extract research result data to build a knowledge graph, propose relevant visualization of this graph and write a literature review report linked with our knowledge graph, making scientific writing compatible with the linked open data ideal.

Timeline

[edit]

Our project is organized in 3 work packages each including precise deliverables (D) or event participation (E).

WP1: Conducting a living meta review on just sustainability transition using Wikimedia projects

  • D1.1: An academic Wikidata graph on just sustainability transition supported by academic references and relevant SPARQL queries to navigate the graph.
  • D1.2: An academic paper presenting a meta-literature review of existing reviews on just sustainability transition including our detailed methodology.

WP2: Data engineering and user workflow assessment

  • D2.1: Technical documentation of the method workflow, identifying existing, missing or incomplete tools (ex : Zotero-Wikidata synchronisation)
  • D2.2: Small developments addressing workflow gaps (ex : zotero script, open refine data model, new wikidata properties, Wikidata Schema, export/import between mediawiki and word document…)

WP3: Dissemination and community building

Audience 1: Social science researchers

  • E.1: Academic conference presentation at a social science conference (ex: RC33 International Conference on Social Science Methodology, Knowledge Graphs for Sustainability Workshop – KG4S) to share our new living review workflow.
  • E.2: Wikidata & Wikipedia Editathon on sustainability research

Audience 2: Wikimedia researchers

  • E.3: Presentation within the wikimedia community (ex: Wiki Workshop, Wikimania)
  • D3.1: Updated project page on meta.wiki
  • D3.2: Research grant application targeting open science infrastructure funds (OSCARS Open Calls, The navigation fund, Fond national pour la science ouverte, PEPR eNSEMBLE : « Collaboration Numérique »).

Audience 3: Wikimedia community

  • E.4: Presentation at a french-speaking Wikimedia community event (ex : Wikifranca Wikiconvention Francophone)
Timeline
Task Month
D1.1 : Building wikidata graph (data collection) 1-3
D1.1 : Building wikidata graph (data analysis) 4-7
D1.1 : Building wikidata graph (data viz) 6-9
D1.2 : Writing academic paper 9-12
D2.1 : Writing technical documentation 1, 3, 8, 12
D2.2 : Technical developments 1, 3, 8
D3.1 : Updated Meta.wiki page 3, 4, 9, 12
D3.2 : Grant(s) application writing 2-3
E1-4 : Dissemination events 4, 10

Policy, Ethics and Human Subjects Research

[edit]

The project follows WMFʼs Open Access Policy (https://foundation.wikimedia.org/wiki/Policy:Open_access_policy) and aims to follow open science best practices. No human subjects are involved.

Project outputs

[edit]

Online dissemination:

Link to the present page has been made on

Technical Documentation

[edit]

The documentation below aims to document the technical tools and workflows used to implement our “living review” method using Wikidata and Wikiversity. Our approach is an experiment aimed at answering the following question: can Wikidata – and, more broadly, the Wikimedia projects – be used to produce scientific literature reviews that are continuously updated, more transparent and more easily reusable than traditional reviews? By testing existing tools, we seeks to determine to what extent Wikimedia projects can be integrated into a ‘living review’ workflow that can be used by researchers who are not specialists in semantic web technologies or Wikimedia projects.

This report rely on the analysis of our own trial and errors and seek to identify best tools and practices. We detail below which tools proved most useful for this work, which tools might have been useful had it not been for their technical issues and other bugs, and which tools we found lacking. Given that social scientists may not be familiar with the technical infrastructure of Wikimedia projects, we pay a special attention to issues of user-friendliness. Indeed, technical barriers may be an important issue preventing researchers to adopt Wikimedia projects as tools for research.

The report is structured following four stages of the litterature review process:

  1. Building and enriching an academic corpus
  2. Modelling concepts
  3. Visualizing data
  4. Writing

The four section below describe the various functions needed to realize each step and the existing tools to facilitate them.

1. Building and enriching an academic corpus

[edit]

Database search and publication selection

[edit]

A litterature review usually starts with the search of relevant articles in a database. We searched for article in Web of Science and exported the result in .RIS format. This format allows the import into the reference management software Zotero (which in turn allows to export to Wikidata). We chose to work within Zotero because it allows to link the full text of a publication to its meta-data, and reading the full text was necessary to select and analyze the publications.

Importing publications in Wikidata

[edit]

Wikidata policy regarding academic items

[edit]
Wikidata's content in 2024

Scholarly items (which represent about 1/3rd of Wikidata's content) have been recently separated from the rest of the Wikidata item to avoid technical issues, this is the "Graph Split"). Current Wikidata Notability policy is not opposed to creating more Wikidata items for scholarly sources (https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Notability_policy_reform). However, tools acting like a "bot" and creating items automatically have to go through the bot approval process (Wikidata:Requests for permissions/Bot). For projects involving the creation of above 1000 edits, it is recommended to start a wikiproject and get community feedback. (See discussion : https://www.wikidata.org/wiki/Wikidata_talk:WikiCite#c-ArthurPSmith-20260915161200-Jeanne_Noiraud-20260915122500). In the present project, we focus on tools that facilitate semi-automatic imports of relatively small batch of items and allows for manual checks.

Our exploration of import tools

[edit]

To import the selected publications into Wikidata, we first followed the instructions on the Wikidata:Zotero documentation page : we first ran a script to check if any article was already present in Wikidata. Next, we used another script that checks the ISSN of the publication in Wikidata and add P-Q-pairs in the extra field of Zotero. Then we exported the articles data using the "export to Wikidata QuickStatements" function of Zotero and use the QuickStatements tool to add them to Wikidata.

Next we used the Cita (V1.0.0-beta.17) Zotero add-on to add articles QID in Zotero. At this point we identified that duplicates had been created in Wikidata (possibly because the initial script did not work that well because of the recent Graph Split on Wikidata). We merged duplicates on wikidata using the "Merge" gadget on Wikidata. We checked manually for duplicated statments in those items.

During the project, we discovered various other tools that allow to achieve the same function. The list below shows there are tools available, but they are not always well documented nor easy to find. The Cita extension for Zotero is promising, we first encountered some bugs but our project was an opportunity to open a dialogue with the developpers and start working together to improve current issues (e.g. authentification bug).

The question of whether and how large batch of item creation should be allowed with the tools is an open debate (e.g. Cita does not allow it, and Scholia has a cap at 12 items). QuickStatements can allows hundreds or even thousands of items to be created or modified in a single operation. This is a strength, but also a potential weakness if undesired data are added.

Our recommanded workflow (2026)

We determined whether the interface was user-friendly based on whether or not it required writing code and whether it included a button to trigger the requested action. We automatically excluded tools that were not user-friendly from the comparative analysis below.

  • For batch item creation, use Zotero and Cita: Cita fetches QID for items to avoid creating duplicates > Cita proposes the creation of new item with a directly (with an authentification token) or through Quickstatement
  • For single item creation, use BHL or Scholia: copy the DOI in the tool and run the command in Quickstatement

We have updated Wikidata Help:Source page to link toward BHL and Scholia : https://www.wikidata.org/wiki/Help:Sources#Scientific,_newspaper_or_magazine_article

Tool name Link Functionality Does it work? User friendly? Comments
Zotero https://www.wikidata.org/wiki/Wikidata:Zotero Zotero to Quickstatement (do not check for duplicates, but does not export items having a QID in Zotero "extra" field) Yes Yes To avoid the creation of duplicates, fetch the QID of each publication using Cita : https://www.wikidata.org/wiki/Wikidata:Zotero/Cita
Cita https://www.wikidata.org/wiki/Wikidata:Zotero/Cita Zotero-Wikidata Synchronization Yes Yes Ongoing discussion on batch item creation
Scholia https://scholia.toolforge.org/id-to-quickstatements DOI to Quickstatement (checks for duplicates) Yes Yes Limited to 12 items in a batch
BHL https://bhl2wiki.herokuapp.com/ DOI to Quickstatement (checks for duplicates) Yes Yes
SourceMD https://sourcemd.toolforge.org

https://www.wikidata.org/wiki/Wikidata:SourceMD/instructions

PMID (PubMed ID), DOI (Digital Object Identifier), and PMCID (PubMed Central ID) to quickstatement No Yes Not working
Fatameh https://fatameh.toolforge.org/ Import items to Wikidata about papers with content generated from places like EuropePMC, PubMed and Crossref. No Yes Not working
bib2wikidata https://github.com/mitar/bib2wikidata Import bibliographic data in Citation Style Language (Q824708) format into Wikidata ? No Untested
Papers https://github.com/magnusmanske/papers Rust crate and binary to create and update Wikidata items about scientific publications, and their authors, from third-party sources. ? No Untested
ZotWb https://marketplace.sshopencloud.eu/workflow/P0siWJ Zotero to Wikibase ? No Untested

Existing documentation :

Enriching bibliographic data

[edit]

By metadata enrichment, we mean completing metadata to include additional information about the content of an academic piece. In Wikidata, each type of information is added using a specific property. A property is the edge that links two entities in the Wikidata knowledge graph. We selected three Wikidata properties to describe the content of our selected articles : main subject (P921) to describe what the article is about, study type (P8363) to describe its main methodology/research design and research site (P6153) to describe the geographical scope of the study. We also worked on adding author (P50) and tested adding cites work (P2860) and OpenAlex ID (P10283). The sections below details the tools and procedures we used to complete add these data.

The proposed properties have been added to the following data model : https://www.wikidata.org/wiki/Wikidata:WikiProject_Wikidata_for_research/Data_models/Scholarly_article

Adding study type (P8363) and data analysis method (P13391)
[edit]

We first discussed with the community to clarify the meaning of the study type (P8363) property (https://www.wikidata.org/wiki/Wikidata_talk:WikiProject_Wikidata_for_research/Data_models/Scholarly_article#P8363_and_P13046). We also proposed the creation of data analysis method (P13391) (https://www.wikidata.org/wiki/Wikidata:Property_proposal/Data_analysis_method).

There is currently no tools to add study type (P8363) so the data were added manually. For the references of these statements, we used the property based on heuristic (P887) and the value inferred from Methods description (Q110774886).

Adding main subject (P921)

[edit]

A tool exist to semi-automatize the addition of topics for scientific items (Item Subjector https://www.wikidata.org/wiki/Wikidata:Tools/ItemSubjector), however its use is too technical for people without technical knowledge.

We decided to add the data manually. For the references of these statements, we used the property based on heuristic (P887) and the value inferred from abstract (Q69653744).

Tool name Link Functionality Does it work? User friendly? Comments
Item Subjector [1]https://www.wikidata.org/wiki/Wikidata:Tools/ItemSubjector Helps add main subject (P921) to groups of items in a semi-automatic way ? No Untested

Adding research site (P6153)

[edit]

The property "research site" showed constraints issue as it was created to indicate clinical trial sites but used in practice for the larger purpose of the research site or fieldwork. We started a discussion to solve this : https://www.wikidata.org/wiki/Property_talk:P6153 (Constraints alerts can be ignored in the meantime.)

There is currently no tools to add research site (P6153) so the data were added manually. For the references of these statements, we used the property based on heuristic (P887) and the value inferred from abstract (Q69653744).

Adding author (P50)

[edit]

Author's names are added in Wikidata with the property author name string (P2093). The property author (P50) links more precisely towards the author's QID. Enriching author's data can help doing research on diversity in a specific academic community (ex:https://wikiworkshop.org/2026/paper/wikiworkshop_2026_45_divinwd_insights_from_wikidata_for_measuring_diversity_in_scholarly_publications). The Author Disambiguator tool helped match author's name to authors QID and create new items for authors without QID. The tool helps to minimise errors caused by homonyms among researchers: following a query, it categorises scientific publications into thematic groups. It also automatically searches for ORCID, ResearchGate and VIAF pages.

Tool name Link Functionality Does it work? User friendly? Comments
Author Disambiguator [2]https://author-disambiguator.toolforge.org/

https://www.wikidata.org/wiki/Wikidata:Tools/Author_Disambiguator

Match author's name to authors QID and create new items for authors without QID. Yes (after logging in to your account) Yes If "Too many requests" is displayed, click on the OAuth option
Orcidator https://www.wikidata.org/wiki/Wikidata:ORCIDator Harvest machine readable information from public ORCID profiles into Wikidata No (April 2026) ? Deactivated because of Abuse

Adding cites work (P2860)

[edit]

The property cites work (P2860) allows to link citing and cited items. Adding a full list of cited items require two steps : first creating items for all cited works and then linking citing and cited works. Most tools to link citing and cited work do not allow the batch creation of new cited items. This blockage is in some case voluntary (e.g. for Cita) because the batch creation of cited items could generate the creation of large numbers of items that may not have the notability to be included into Wikidata.

Tools for extracting a list of cited works/references from an academic item

Tool name Link Functionality Does it work? User friendly? Comments
DOI Reference Extractor https://references.mireklzicar.com/ Extract all references for a given DOI number (click "get references" to get cited works) Yes Yes Download in RIS or BibText format to import into Zotero
Cita https://www.wikidata.org/wiki/Wikidata:Zotero/Cita Cita can fetch cited references for each item. No Yes Creation of cited items is disabled.
Open Refine https://openrefine.org/ Harvest citation data from database API Yes No Requires parsing data

See the section "Importing publications in Wikidata" to create items from the list of of extracted cited (Ex: import in Zotero and export in quickstatement or use Cita).

Tools for linking citing and cited works

Tool name Link Functionality Does it work? User friendly? Comments
Cita https://www.wikidata.org/wiki/Wikidata:Zotero/Cita Adds "cites work" statements between items that already exist in Wikidata Yes Yes Does not allow to create new items for all cited items
Wikidata Cites Work(s) Wikidata Cites Work(s) Takes one or more DOIs and creates "cites work" entries for each item. Yes Yes Only links existing items
Open Citation Bot https://www.wikidata.org/wiki/User:OpenCitations_Bot Create missing "cites work" relations as well as new Wikidata items for scholarly publications are created ? No Untested
Citationgraph bot Citationgraph bot Adds "cites work" statements to items ? No Untested
Open Refine https://openrefine.org/ Adds "cites work" statements between items that already exist in Wikidata (for example a list of DOI of cited items) Yes No

Adding OpenAlex ID (P10283)

[edit]
Tool name Link Functionality Does it work? User friendly? Comments
Open Refine https://openrefine.org/ Can harvest identifier from database API and add it to Wikidata. Yes No
Cita https://www.wikidata.org/wiki/Wikidata:Zotero/Cita Cita can "get identifier" from Open Alex Yes No Do not currently allow to add identifier in Wikidata

2. Modelling concepts

[edit]

Modelling bibliographic tables

[edit]

Some review articles contain tables about specific studies. These tables are hard to reuse when they are on a PDF (the table formatting is lost when we try to copy it). However, it is possible to copy a table from the online version of an article and paste it in an excel sheet. For example, the publication The role of energy democracy and energy citizenship for participatory energy transitions: A comprehensive review contains tables with lists of publications. We used the tools above to add these publications into Wikidata, used OpenRefine to enrich the bibliographic data with the content of the tables, and used the publication as reference.

Modelling concepts

[edit]
Visualisation of "instance of" and "subclass of" statements for the item "energy democracy".

Our modelling process for concepts is described in more details on the page : https://en.wikiversity.org/wiki/Just_sustainability_transitions:_a_living_review. We have also listed relevant properties here : https://www.wikidata.org/wiki/Wikidata:WikiProject_Wikidata_for_research/Data_models/Social_science_results.

One of our take away is that modelling can involve logical simplification to make statements more parcimonious. In those cases, visualisation tools such as theWikidata graph builder are usefull to visualize redundancies. The visualisation on the left shows that energy democracy (Q14944319) is an instance of (P31) political concept (Q33104069) and an instance of (P31) concept (Q151885). Which is redundant because political concept (Q33104069) is a subclass of (P279) concept (Q151885).

We made a proposition regarding possible ways to suggest logical simplifications to users : https://www.wikidata.org/wiki/Wikidata:WikiProject_Reasoning/Use_cases#Parcimonious_statement_constraints_based_on_subclass_of_(P279)_and_part_of_(P361)_transitivity

Doing manual edits efficiently

[edit]

Most of our conceptual modelling was made with manual edits. We identified several tools which are usefull to facilitate this process. They can be activated in user settings : https://www.wikidata.org/wiki/Special:Preferences

  • Merge
  • CiteTool
  • Duplicate references
  • Move claim
  • Current Date (to use when using a wikidata item as reference)

3. Data visualisation

[edit]

The Wikidata community has developped various visualisation tools (e.g. https://www.wikidata.org/wiki/Wikidata:Tools/Visualize_data). We decribe below the various tools we have experimented to visualize the data we have added to Wikidata.

Visualizing bibliographic tables with enriched meta-data

[edit]

We tried SPARQL queries to visualise tables of bibliographic items with the data we added (main topic, study type, research site), these requests did not work (possibly because of the Graph split). OpenRefine can be used to build tables with the function "add column from reconciled value" and choosing relevant Wikidata properties, but it it is not the original function of OpenRefine and is not beginner-friendly. Similarly, Python scripts can help generate tables but are not user-friendly for people who do not know how to run them.

Tabernacle seems to be the most user-friendly tool to visualise tables and even add content (ex: translate labels). For now the generated tables are editable by simple click and thus not suitable for purely sharing results since accidental edit can easily occur (we thus requested a "view only" mode : https://codeberg.org/magnusmanske/tabernacle/issues/9). In our case, Tabernacle was usefull to visualize our list of academic articles and do some quality control to check that the content added was correct.

Tool name Link Functionality Does it work? User friendly? Comments
Tabernacle https://tabernacle.toolforge.org Interactive table to visualize and edit Wikidata items Yes Yes
Open Refine https://openrefine.org/ Possibility to "add column from reconciled value" and add columns corresponding to various Wikidata properties. Yes No
Python script https://gist.github.com/fnielsen/70069b61da9f7eb09b721e4d82b63710 From a list od DOI, generate a table for wikipage including QID, publication year, DOI and title. Yes No
Python script https://github.com/Ronnie-V/ReadSubjects Get title and main subject for a given QID ? No

Visualising graphs

[edit]

Another way to visualize data is in the form of graphs. While many tools propose interesting functions, several are bugged or limited to specific properties. Wikidata graph builder seem to be the most user friendly, robust and versatile tool to visualise a graph based on a single property https://angryloki.github.io . The Wikidata Knowledge Explorer also seem to be a robust tool and user friendly tool (https://think.resoneo.com/wikidata-search/) (The negative point is that is was created by a marketing company, encouraging self-promotion on Wikidata in the page "tutorial".)

Tool name Link Functionality Does it work? User friendly? Comments
Wikidata graph builder https://angryloki.github.io/wikidata-graph-builder/ Visualize specific properties starting with a root item Yes Yes Affected by the graph split (academic items do not appear in the results).
Scholia "topic in context" https://scholia.toolforge.org/topic/ Visualize all statements linked to a specific topic Yes (sometimes) Yes Several scholia queries are Affected by the graph split + AI crawling
Wikidata Knowledge Explorer https://think.resoneo.com/wikidata-search/ Visualize all statements for a list of items, possibility to filter to remove properties Yes Yes Created for digital marketing but useful for other things.
Wikidata 3D Explorer https://imadcat.github.io/knowledge-graph-visualizers/wikidata.html Explore items through a 3D graph Yes Yes Interesting to explore graphs dynamically.
Metaphacts https://wikidata.metaphacts.com Explore and visualise a relation between concept. "Pathfinder" function to explore links between entities. No Yes My properties are omitted, data is not up to date, the pathfinder does not work.
Large language models https://query.wikidata.org/ Write SPARQL query from a request formulated in natural language Yes Yes Writing queries with AI still requires an understanding of how the data is structured. Modifying existing queries seems to lead to better results.
SPARQL Query Service https://query.wikidata.org/ Query Wikidata Yes No Affected by the graph split.
Wikipedia Museum https://sophiawliu.github.io/fieldtrip/#/museum-wiki/custom/list?museum=custom Visualize hyperlinks between Wikipedia pages (/!\ not between Wikidata items) Yes Yes This tool can help identify missing links between Wikipedia pages by comparing entities linked in Wikidata with the links across their respective Wikipedia pages.

Visualizing pre-registered queries

[edit]

When one design a relevant SPARQL query, it can be difficult to share results with others or allow queries to be reused. Synia (https://www.wikidata.org/wiki/Wikidata:Synia) is a Wikidata frontend that facilitates the generation of profiles based on Wikidata queries. It generates webpages from SPARQL queries stored on Wikidata pages.

Synia have a few technical issues and we are working on fixing them :

Wikidata page storing queries Synia display page Type of item explored Function
https://www.wikidata.org/wiki/Wikidata:Synia:justsustainabilitytransitions-index https://synia.toolforge.org/#justsustainabilitytransitions
https://www.wikidata.org/wiki/Wikidata:Synia:topic-reference-index https://synia.toolforge.org/#topic/Q14944319/reference Topic Display all references used on the item page + Display causes-effet relationship with number of references
https://www.wikidata.org/wiki/Wikidata:Synia:work https://synia.toolforge.org/#work/Q114306483 Work (academic item) Display authors, co-citation, cited work, citation per year, and statements supported by the work
https://www.wikidata.org/wiki/Wikidata:Synia:topic https://synia.toolforge.org/#topic/Q14944319 Topic

Quality control, maintenance and impact analysis

[edit]

The Wikimedia Projects Dashboard can serve as a quality control tool by tracking edits of contributors of a given project. Several other mechanisms help to minimise errors: a preview of changes before publication, a complete history of contributions, the ability to undo certain changes, detection of duplicates during reconciliation, constraints on properties, possibility to subscribe to change notification and the ability for the community to correct the data. Quality control is not entirely automatic, but it is relatively robust if the tools are used correctly.

An issue we encountered when working on our corpus was the difficulty to keep track of the particular part of the graph we were working on. We linked each academic item we were working on to our research project by adding a statement maintained by WikiProject (P6104) Developing a wiki-integrated workflow to build a living review on just sustainability transitions (Q134545539), but it was still relatively difficult to "filter" the part of the knowledge graph we were working on.

Regarding impact analysis, changes in page views (https://pageviews.wmcloud.org) can be interesting to observe. In our case, we worked on the item "energy democracy" and the number of Wikidata page view has significantly increased since we added rich statements to it : https://pageviews.wmcloud.org/?project=wikidata.org&platform=all-access&agent=spider&redirects=0&start=2025-06&end=2026-05&pages=Q14944319.

Tool name Link Functionality Does it work? User friendly? Comments
Project dashboard https://outreachdashboard.wmflabs.org/explore Track edits during a specific period Yes Yes It could be interesting to be able to track edits around a specific Wikiproject
IneGraality https://www.wikidata.org/wiki/Wikidata:InteGraality Generates a dashboard showing, how well properties are filled for a set items ? No Requires understanding Wikicode and possibly SPARQL
Wikidata Blame https://mormegil-cz.github.io/wikidata-tools/blame/ Visualize the history of a Wikidata item Yes Yes Results display property and item numbers instead of label and are thus difficult to interpret.
Pageview https://pageviews.wmcloud.org Display pageview statistics Yes Yes

4. Writing

[edit]

The idea to use Wikis as a form of scholarly communication is not new in the Wikimedia community (see : https://en.wikiversity.org/wiki/Wikis_in_scholarly_communication). In this section, we investigate the technical challenges involved in doing acadamic writing on Wiki pages. In particular, we explore the issues related to reference management and reference formatting for scholar who use a word processor and Zotero as reference management tool. We investigated the links Zotero, Wikidata and Wikipedia/Wikiversity during Wikimania 2026 Hackathon and proposed prototypes (see https://wikimania.wikimedia.org/wiki/2026:Team_challenges/Team_08E_Europe). In the sections below, we discuss the tools allowing to go from Word/Zotero to Wikitext and the other way around.

Word/Zotero to Wikitext

[edit]

This section discuss how someone who have written a text on Word with references managed with Zotero can publish in Wikitext format. The visual editor currently supports the copy-pasting of text from Word and keeps the formatting. The main difficulty is the management of references, which are lost during simple copy-pasting. Tools can help adding individual references such as the Citoid and ProvIt but it is still time-consuming to format every reference. It took us a lot of time to discover that Zotero natively includes a citation style to format Zotero references into a citation style compatible with (english) Wikipedia.

The template "Cite Q" allows to generate references from an item QID. In this context, Cita is useful to keep track of a reference's QID in Zotero. There is however no citation style to format Zotero references following the "Cite Q" template (we created a prototype for it that could be improved). The existing citation styles only covers english and french and it would be relevant to create more styles for various linguistic versions and add them to the Zotero Style Repository .

In our experimental academic writing on Wikiversity, we also used the Wikidata entity link which replace a word by a link toward a Wikidata entity. While this practice is not recommended in the body of Wikipedia pages, we found it useful to highlight and disambiguate key terms in our academic text.

Tool name Link Functionality Does it work? User friendly? Comments
Visual editor https://en.wikipedia.org/wiki/Wikipedia:VisualEditor Enable edit without wikicode, support copy-pasting from Word. Yes Yes Not always enabled by default, which could be discouraging new contributors.
Citoid https://www.mediawiki.org/wiki/Citoid Generates citation data given a URL, DOI, ISBN, PMID, PMCID or QID Yes Yes Available in the visual editor
ProveIt https://www.mediawiki.org/wiki/ProveIt Helps managing references in Wikicode mode Yes Yes Works only in Wikicode. Not enabled on Wikiversity.
Cite Q Template https://en.wikiversity.org/wiki/Template:Cite_Q Cite scholarly item on a Wikipedia or Wikiversity page using its QID Yes Yes See template page for different language version
Wikipedia citation style https://en.wikipedia.org/wiki/Wikipedia:Citing_sources_with_Zotero#Adding_references_into_Wikipedia_articles_using_your_text_editor Format your references for Wikipedia in a word processor Yes Yes Default template is for english, french version available here.

Additional language support would be interesting.

Wikipedia Cite Q citation style https://github.com/AdelieRanville/Zotero-Wikipedia-CiteQ-Style Format your references for Wikipedia in a word processor using the Cite Q template No (Prototype) Yes Created for the present project. Does not work for Zotero 10.0.3 (the QID is not accepted as custom variable).
Wikidata entity link https://en.wikiversity.org/wiki/Template:Wikidata_entity_link Replace a word by a link toward a Wikidata entity Yes Yes See template page for different language version. Use not recommanded in Wikipedia main text.

Cite Q and Wikipedia

There is currently no consensus regarding the use of the Cite Q template on Wikipedia pages. See existing discussions :

The main argument seem to be that Wikipedia does not impose one "house citation style" and that the Cite Q templates make the citation content opaque for users using the source editor. Cite Q also change how citations are handled in general and deports the maintenance of meta-data into Wikidata, which is a significant change for Wikipedia contributors.

These debates supports the idea of having various citation styles in Zotero that are compatible with Wikipedia styles.

Wikitext to Word+Zotero

[edit]

This section explores how wikitext can be turned into a Word file including references linked to the user's personal Zotero library. The only native export proposed for Wikipedia or Wikiversity pages is a PDF format.

Current possible workflow (2026) :

Given that replace every single references is time-consuming, we created a prototype tool (https://github.com/AdelieRanville/WikiZotRef) that convert wikitext with references into a Word file including references linked to the user's personal Zotero library. The tool require that all the references used in the wikitext are added in the user's Zotero library, then it matches references and generates a word document including Zotero's live citation fields.

Tool name Link Functionality Does it work? User friendly? Comments
Zotero Connector https://www.zotero.org/download/connectors Adding a list of references from Wikitext to Zotero Yes Yes Right click on the connector button > save to Zotero > save to Zotero (DOI)

The function "save to Zotero (COinS)" generate meta-data of lower quality

WikiZotRef https://github.com/AdelieRanville/WikiZotRef Convert wikitext with references into a Word file including references linked to the user's personal Zotero library Yes (prototype) Yes Require an understanding of how metadata works
Pandoc https://pandoc.app/ Convert Wikitext to word Partially Yes References are not managed well, Wikidata entity links disappear
Pandoc ultimate converter https://www.mediawiki.org/wiki/Extension:PandocUltimateConverter Importing documents and webpages into wiki pages and exporting wiki pages to external document formats ? No (beta version)

Recommandations

[edit]

The main obstacle is not Wikidata’s ability to represent scientific knowledge, but the cognitive and technical cost involved in integrating Wikimedia tools into researchers’ day-to-day practices.

Rely on tools used by scholars

[edit]

The key strengths of the tools used here are that they are based on widely used standards (notably the DOI), enabling access to rich metadata. The widespread adoption of these standards amongst research communities promotes reproducibility. Zotero, in particular, is among the top reference management software used in academia (and the top open source one). We believe that a continued integration and compatibility between Zotero and Wikimedia projects is promising (Citoid is a good example).

Train and sensitize researchers

[edit]

Researchers sometime include list of reviewed publications in their litterature review papers or in supplementary material. However we found that the DOI (unique identifier for academic item) was often missing from these tables. This reflects a clear lack of knowledge of the scholarly community regarding data interoperability and linked open data. Sensitizing researchers to these notions seem to be a prerequisite before introducing them to Wikidata and its unique identifiers (Qxxx and Pxxx).

In addition, even the most user-friendly tools require an understanding of several new concepts for resarchers not familiars with Wikimedia projects: the Wikidata data model (items, properties, statements, qualifiers), Q and P identifiers, modelling constraints, as well as the specific functionality of each tool (reconciliation in OpenRefine, QuickStatements syntax, etc.). For a social sciences and humanities researcher with no prior experience, it may take several hours, or even several days, before they can carry out imports independently. The learning curve remain high.

Clarify inclusion policy for academic items

[edit]

A reccuring question in the management of bibliographic data is how much automation is desirable. While automation make the work quicker, it also opens the door for the addition of undesired data (the Orcidator tool was for example deactivated because of abusive use). A related issue may be the need to clarify the notability policy regarding academic items. While academic items can answer criterion 2 as they are "clearly identifiable conceptual or material entity that can be described using serious and publicly available references", adding all academic item to Wikidata would ultimately pose technical problems given the number of item it would represent. Implicitely, importing academic item is considered relevant if it is part of a specific project with a defined goal.

Facilitate user-developpers interactions and improve documentation

[edit]

Several community-run tools appear to be essential to the workflow, but have limited reliability. These tools rely on voluntary community maintenance and do not necessarily benefit from the same guarantees of stability as the central infrastructures of the Wikimedia projects. Some of the main difficulties encountered were the bugs in the open-source tools used. While they appeared to be key obstacle at first, we tried to investigate and engage with the volunteer developers. Solving issues required our team to learn how the tools worked and to develop the ability to "speak the same language" as the developpers (e.g. learn how to report a bug or request a feature).

Sometimes, the main issue were was simply a lack of documentation that made the tool hard to use or understand. Some of the documentation is missing or outdated, which require to dig into the web for existing solutions. There are many resources (Wikidata help pages, OpenRefine documentation, tutorials, videos, Meta pages, community discussions), but they are spread across several websites, sometimes in English only, with varying levels of detail and technical jargon. The present page is an attempt to document various solutions but the poor discoverability of tools could remain an issue and it is often difficult to identify the ‘right’ guide for a specific task.

A possible improvement could be to provide a template for community tools pages including a user-friendly "how to use" section, a "technical documentation" section, and a "maintenance" section describing if the tool is currently maintained, by who, and how to report issues. This last part is mostly absent from existing project pages about tool. Users encountering problems cannot know who they should contact and through which channels (Discussion pages ? Github ? Phabricator ? The developper's email ?). We also discovered that Toolhub (listing Wikimedia-related tool) existed only at the end of this project, so it could be useful to build more links from Wikimedia pages toward this catalogue.

Sensitize companies about how the community works

[edit]

Some of the visualization tools we identified were developped by companies in semantic intelligence (Metaphactory) and digital marketing (Resoneo), probably to be used as demonstrators of the company's skills. These tools have potential to be reused by the community while businesses could have the resources to maintain the tools in the long run. However, firms need to be better acculturated to the Wikimedia community rules and practices, as shown by Resoneo's problematic explanations about "Creating a Wikidata Entry for Yourself". Firms interested in Wikidata could be encouraged to interact more with the community to understand its rules. For example, a digital marketing company could encourage firms to share their data with the Wiki Project Companies rather than explain how to do self-promotion on Wikidata directly.

[edit]

Wikimedia and research

[edit]
  • Science Hub
  • Critical Wikimedia Research Bibliography
  • Systematic review automation (Presentation, Github) : This project is more automated and use a more technical workflow. Compared to our project, this require an existing reliable ontology for the concepts/keywords. In our case, the social science concepts are not well represented nor structured on Wikidata. Automation seem relevant for deductive workflows while we want to support inductive building of knowledge graphs.

Wikimedia and sustainability

[edit]

References

[edit]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Research:Developing_a_wiki-integrated_workflow_to_build_a_living_review_on_just_sustainability_transitions&oldid=31169383"