Repository navigation
Wikidata
The DBnary documentation mentions Wikidata, and it's worth discussing Wikidata here as well because of its similarities. For example, readers of this repository may wonder whether they should look into extracting data from Wikidata in addition to or instead of from DBnary / Wiktionary.
Wikidata is a project of the Wikimedia Foundation (the organization that sponsors Wikipedia and Wiktionary). Like DBnary, Wikidata is a graph database with lexical information that can be queried using SPARQL. Wikidata is not an interface to Wiktionary, but it's possible that a Wiktionary page pulls data from Wikidata.
At this point, we recommend readers read the Wikidata documentation for lexicographical data, as we will not give a complete overview here and instead only repeat some points for emphasis. Some recommended links are:
- Project page (for lexicographical data in Wikidata)
- Documentation
- Support for Wiktionary and the page it links to at https://www.wikidata.org/wiki/User:Rua/Wikidata_for_Wiktionarians.
- Wiktionary FAQ - has a couple motivating examples
Lexemes can be entered in a large number of language. Wikidata lexemes have an identifier that starts with 'L' followed by a numeric id. A lexeme is for a single language and part of speech, so searching for 'arm' among lexemes returns the English noun (L3259), the English verb (L5507), the German adjective (L343483), etc. Wikidata also stores items, which are usually concepts. There is concept Q43471 which has English label 'arm', Spanish label 'brazo', etc.
The ids for senses and forms of the lexeme are derived by adding '-Sn' and '-Fn' to the lexeme id where 'n' is a number. Note that this 'n' is permanent. If 'L123-S1' and 'L123-S2' are created, and then 'L123-S1' is deleted, the id for 'L123-S2' does not change. This seems beneficial over Wiktionary where senses usually don't have a permanent id. Hence, senses are identified in each DBnary version by their sequence, but this sequence number can change if the position in the sequence changes.
Having things other than glosses or a text description of the sense as identifiers can be beneficial because minor changes can be made to the text descriptions without breaking references to the sense. For example, we have evaluated translation completion of a few thousand specific senses. Since we were interested in translation completion, we identified these senses in their English Wiktionary using the gloss text
of the translation table entry. To re-run the completion analysis on a subsequent month, we must deal with the fact that the gloss text may have changed. And in fact, a surprising number of these texts do change monthly (TBD: share stats). A Wiktionary senseid template exists that users can use to tag a sense, and this sense id can be used in the translation table entries, but in practice this is rare (in the English Wiktionary).
Translations can be added to each sense (linking to senses of lexemes of other languages) using the translation property (P5972). However, an equally common, if not more common, way of representing a translation is when two different senses link to the same item using the item for this sense property (P5137). Synonyms (senses of other lexemes) can be added to each sense, and the same is true for other 'nym' relations. In Wiktionary, synonyms are usually underspecified. That is, a synonym might link from a lexical entry or sense to a page. Perhaps the link to the correct lexical entry can be reasonably inferred (e.g., by considering part of speech), but linking to senses is usually not trivial, unless the lexical entry has only one sense.
Wikidata has usage examples. However, it does not italicize, bold, or otherwise mark the lexeme in the example. DBnary also removes such markers from its examples, but the markers are in the source Wiktionaries (at least for the Wiktionaries we are familiar with). (TBD: does it also have author-written usage examples or only citations? TBD: does it have a property for the translation of the usage example?)
Only CC0 data may be uploaded to Wikidata. This facilitates re-use of Wikidata data, but it limits what, if anything, can be extracted from the Wiktionaries and inserted into Wikidata since the Wiktionaries have CC-BY-SA licenses.
There is no functionality that we are aware of like the Wiktionary:Thesaurus project in the English-language Wiktionary.
For the most part, Wikidata has less lexical data than the Wiktionaries. For most languages, a lot less. See here for some counts. Although most languages have only a fraction of the senses in Wikidata as in DBnary (Wiktionary), a small number of languages (Danish, Portuguese, Norwegian) have more senses in Wikidata. For some of the languages where the relative proportion is low, the absolute number of senses is high. For example, using a somewhat arbitrary cut-off of 20,000 senses and limiting to the 28 Wiktionaries extracted to DBnary, there are 9 languages where the Wikidata count is more that the cut-off and 22 where the DBnary count is more than the cut-off. When including other languages (those where the Wiktionary is not extracted to DBnary), two more in Wikidata exceed the 20k cut-off: Aragonese and Basque.
The dump files from Wikidata can be downloaded, just like those from Wikipedia and Wiktionary. Fortunately, the lexeme data is separate, as the lexeme dump file size (in September 2026) ranges between 0.5 and 1.5 G, depending on the format. This is for lexemes in all languages. For comparison, the English-language Wiktionary for the same month is 1.9 G. It looks like this download contains (as one might expect) not just lexemes, but broader lexicographical data (i.e., lexemes, senses, and forms).
It's good that the lexicographical data is offered as a separate download than the rest of Wikidata, as the all-Wikidata downloads are much larger (103G - 254 G). However, the lexicographical data download (LDD) will not have many properties and items that are predicates or objects in statements about lex. items. So translations of senses will be in the LDD if the translation is captured using the 'translated to' property but they won't be in the LDD if the translation is captured using the 'item for this sense' property. Similarly, the language of the lexeme will only be available as its resource id (Qxxxxx) in the LDD, etc.
Wikimedia Foundation employees have indicated various aspects of the growth rate of Wikidata are not sustainable. See Sarabadani's proposal and the mass-editing policy proposal by Pintscher, et al. This raises questions to us about its future, especially since as noted above the relative lexical data content is pretty low currently compared to Wiktionary. Authors should also keep this in mind if they are presented with the argument that size considerations in Wiktionary are irrelevant because Wiktionary is not paper because it's also true that 'Wikidata is not paper' but Wikidata is encountering very real resource constraints.
As for what items are most represented in Wikidata, Aisha Khatun's User Page has a list of the top 50 subgraphs (presumably in 2021) and slightly more updated numbers are in the manuscript of Fahl, et al.. The subgraph analysis shows that citations are the largest subgraph, and one remediation already performed in May 2025 was to split the previously single Wikidata query graph database into two databases: citations and non-citations.
Official use of Wikidata in the English-language Wiktionary is prohibited, with a few exceptions. The only use we're aware of is Wikidata concept ids (and not lexeme ids) are used as the sense id in translation table entries for countries and planets. See here for details. We're not sure what the policies are in other Wiktionaries and whether other Wiktionaries use Wikidata.
Wikidata use in a Wiktionary can take several forms. One form would be in the Wiktionary page actively extracts data from Wikidata when the page is loaded. Another way the data might be used is that data from Wikidata might be copied into the wikitext of a page in Wiktionary. Use in the first way would be easy to quantify and detect, while use in the second way would not.