O ntolex- L emon in W ikidata and other W ikibase instances (2025)

Abstract: This paper provides insight into how the core elements of the Ontolex-Lemon model are inte- grated in the Wikibase Ontology, the data model fundamental to any instance of the Wikibase software, including Wikidata lexemes, which today is probably the largest Ontolex-Lemon use case, a dataset collaboratively built by the community of Wikidata users. We describe how lexical entries are modeled on a Wikibase, including the linguistic description of lexemes, the linking of lexical entries, lexical senses and lexical forms across resources, and links across the domain of lexemes and the ontological part of a Wikibase knowledge graph. Our aim is to present Wikibase as a solution for storing and collaboratively editing lexical data follow- ing Semantic Web standards, and to identify relevant research questions to be addressed in future work.

## introduction wikibase, foot_0 a set of extensions to mediawiki foot_1 , is a software solution for storing, collaboratively editing and exhibiting structured data on the web, in the shape of a knowledge graph. the software is used, first and foremost, by wikidata (vrandečić and krötzsch, 2014; erxleben et al., 2014). @xcite many other instances of the software have emerged since the software packages (and hosting solutions) are freely available. @xcite the types of entities described in a wikibase include items, which represent all kinds of real-world objects and ontological concepts, and lexemes, describing words. as it will be explained in section 2.1, in a wikibase, lexemes are described following the core of the ontolex-lemon model (mccrae et al., 2017), and so they are on wikidata, which is today probably the largest open and collaboratively editable ontolex-lemon use case. by may 2025, wikidata described 1.42 million lexical entries in 1,379 different languages, which compared to earlier figures (nielsen, 2020) means an exponential growth. german, russian, danish, estonian, english and malayalam are, in this order, the languages with the most described lexemes. the potential uses of the linguistic descriptions contained in this growing resource, which we present in more detail in section 2.2, are manifold. section 2.3 is devoted to wikibase as a linking hub for descriptions of lexical entries, senses and forms across different resources; cross-resource links are encoded as external id properties. @xcite external identifiers do not only constitute hyperlinks for a user to jump between the resources presented in different web portals, but also enable sparql federation, @xcite that is, a wikibase's content may be integrated also with the lexical and ontological content of any other wikibase, including wikidata, or an rdf database of other kind. @xcite in this regard, it is important to point out how rdf is used on a wikibase, which will be explained in section 2.4. related to this, an important and distinguishing feature of wikibase is its multi-layer integration of lexical and ontological entities inside the same database, which will be discussed in detail in section 2.5. while the lexemes collection on wikidata is open for continued enrichment, some use cases may require a separate wikibase instance, in a first phase of a contribution project, or even for a whole project lifetime: a language may be already described on wikidata, so that any addition would involve lexeme, sense and form disambiguation and deduplication tasks, which when working on an own instance could be left to the final phase of a project. also, a dataset to be curated may be regarded too noisy (e. g. in a legacy dictionary digitisation project), or too esoteric (e. g. when dealing with dialectal or historical language data) to be included in wikidata without previously ensuring relevance and quality. in addition, to work on an own wikibase instance means freedom in data modeling and community management. licensing might also be an issue, since wikidata content is obligatorily licensed according to cc0. exploring these potentials, we briefly discuss the wikibase ecosystem for lexeme descriptions in section 2.6. in the closing section 3, we provide an outlook for open research questions to be worked on, focusing on the relation between the fine-grained modeling proposals made by the ontolex community, on the one hand, and the conventions emerging in the community working on wikidata lexemes, on the other. ## outlook to further research in this paper, we have been revisiting the model for lexical entries on wikibase, and in wikidata lexemes, the largest collection of lexical data on a wikibase today, and which is also, probably, the largest ontolex use case. it can be stated that, by reusing ontolex-lemon, the wikibase software enables the community to perform steps towards the vision of a linked lexical data cloud (declerck, 2018). since the first publications of the lemon model (mccrae et al., 2012), which had been available by the time of defining the wikibase ontology, the ontolex community has been publishing modeling proposals as modules, regarding, among other aspects, the description of morphology, etymology, and corpus attestations. @xcite in the same timespan and in parallel, there has been emerging a tradition of modeling lexemes on wikidata. one research question seems obvious in this context: where and how do both models differ, where do they come together? where can they benefit from each other? what advantages and disadvantages have the two strategies, compared to each other: a top-down model with strict recommendations, aiming at interoperable lexical datasets also at a more fine-grained level (ontolex), and a model that limits obligatory interoperability to the core, leaving decisions regarding fine-grained descriptions up to the user (wikibase), aiming at higher levels of interoperability through on-the-fly grassroot community discussions (wikidata)? this can shed lights on questions about whether the lemon core has proven its functionality, if the obligatory core should be extended, or if even some of the minimum requirements might turn out problematic for certain use cases. comparing both universes may lead to useful insight: can the wikidata lexemes collection provide data-driven evidence for modeling decisions that can be regarded universal, beyond the ontolex-lemon core? and, in the other direction: can collaborators or automatic tools informed in ontolex-lemon modeling proposals help grassroot communities to improve consistency, quality assessment and interoperability? a continued dialogue between the ontolex and the wikidata lexemes communities, and those around other instances of the wikibase software, will help to address these questions in detail.