|Sister projects' integration proposals|
- Previous proposals and discussions are at /Previous.
There have been numerous proposals for how to best support Wiktionary in Wikidata. This proposal ties together most of the previous discussions and results. It would be appreciated to keep discussions in one place, or at least link to them from here. --Denny (talk) 12:01, 2 August 2013 (UTC)
|The following is a draft of a proposed inclusion of Wiktionary.
There are some doubts about this structure of inclusion. Please look at the discussion page.
Unfortunately, the terminology around dictionaries and lexical resources is easily confusing. Therefore we provide a terminology that should be used strictly and consistently throughout the proposal. In order to make it obvious, we will use the technical terms throughout in italics, like this.
- A lexeme, also known as word or lexical entry, is what is described on one page in the lexical part of Wikidata. A lexeme consists of a lemma, a lexical category, a language, a set of forms, a set of senses, and a set of statements.
- The lemma is the canonical form or dictionary form of the lexeme, e.g. for verbs this is usually the infinitive form, for a noun the nominative singular, etc.
- The lexical category, also known as the part of speech or word class, defines the lexeme to be either a noun, or a verb, or an adjective, etc. The set of possible values is open and taken from the Wikidata items.
- The language of a lexeme is taken from Wikidata items, and thus an open set.
- A form is a specific, fully conjugated or inflexed form of the lexeme. A form consists of a representation, a set of lexical properties, and a set of statements. A form always belongs to one (and exactly one) lexeme.
- A representation is the actual string value realizing a given form, e.g. the string value "wrote" for the past tense of the lexeme for "write". All representations are indexed for search.
- A lexical property describes the form, e.g. tense or number for verbs, case for nouns, etc. This is an open set and points to Wikidata items.
- A sense is described by a gloss and has a set of statements. A sense always belongs to one (and exactly one) lexeme (and lexemes belong to one language only). Senses are not independent of lexemes.
- A gloss is a short description (translatable in all languages of the Wikidata UI) of one sense of the given lexeme.
The terms Wikidata item, property, string value, qualifier, statement, and claim are taken from the Wikidata glossary and have the same meaning here.
- Transliterations in other scripts can be either handled by two separate lexemes or by a single lexeme with a statement on each form with the transliteration property pointing to a string value, with a qualifier describing the script. If the latter, transliterations will be indexed for search too.
- Orthographic variants can be either done as two separate lexemes or by a single lexeme with statements on the appropriate level and qualifiers explaining the variant. If the latter, the variants will also be indexed for search.
- Translations can be either done from sense to sense, or by a sense referencing a common Wikidata item. If done the latter, the translations will be automatically displayed and kept up to date. This is only possible when the translation is symmetric and transitive, which is often not the case - but frequently enough to merit a specific implementation.
- (lexeme) W123 (won't be displayed)
- (lemma) apple
- (lexical category) noun (i.e. Q1084)
- (language) English (i.e. Q1860)
- (form) F272 (won't be displayed)
- (representation) apples
- (lexical property) plural (i.e. Q146786)
- (statement) rhymes with -> paddles (F404)
- (sense) S2011 (won't be displayed)
- (gloss) (en) tree of the species Malus
- (gloss) (de) Baum der Spezies Malus
- (sense) S1989 (won't be displayed)
- (gloss) (en) fruit of the apple tree
- (gloss) (de) Frucht des Apfelbaumes
- (translation) (de) Apfel (i.e. W9000)
- (statement) hyperonym -> fruit (i.e. S239)
Note that this is a single entry, i.e. forms and senses do not have their own pages but are part of the lexeme they depend on.
Editing in Wikidata
Wikidata users are not required to be multilingual, and they can view any item or lexeme in their preferred UI language and also edit it there. This is mostly in the same vein that edits are done in Wikidata already. A bit more challenging will be to make the senses work, as they potentially require quite a number of translations. Here improvements in language fallback and work on the multilingual text datatype will provide additional help.
There will not be a site of its own for Wiktionary data, but it will be saved in Wikidata proper.
Usage in Wiktionary
Wikipedia and Wikidata have basically a 1-to-1 mapping of articles in a Wikipedia to items in Wikidata. This is not the case for this proposal for Wiktionary: Wiktionary pages contain all lexemes that have the same representation or lemma across languages and lexical categories. On the other hand, specific forms might have their own Wiktionary page, but there is no lexeme in Wikidata for it.
Therefore language links for the actual words in Wiktionary should not be moved to Wikidata and provided from there. This is especially true since most of these links can be done trivially by merely linking to the page with the same name on the other Wiktionary.
On the other hand, there are a number of pages that can be linked through Wikidata, especially outside the main namespace, like the Wiktionary equivalent to the village pump etc. This can not be provided by such an extension.
In order to resolve these issues, two functionalities have to be developed:
- an extension that creates language links automatically for Wiktionary. Only after this is deployed to Wiktionary, Wikidata Phase 1 functionality should be switched on (in order to avoid any motivation to create items for all current Wiktionary main namespace pages)
- extend Wikidata with the functionality to provide arbitrary access to any Wikidata item from any page on the client. Currently, access to data is restricted to only the connected item.
Using the data (Phase 2)
Once a Wiktionary is connected as a client to Wikidata, it is possible to access and display any data from Wikidata on any Wiktionary article. Note that this is explicitly a possibility: any Wiktionary project can decide from word to word or language to language whether and how they want to use any or all of the data in Wikidata.
Especially for other than their primary languages in smaller Wiktionaries it is expected that they might decide to basically just visualize the data from Wiktionary in a more appropriate way. Wikidata will not for a long time achieve to be as visually coherent and concise as a page like Wiktionary can be. For larger communities especially regarding their primary language it is rather expected to use the from Wiktionary to check part of the entries that they already have, and create automatic reports listing errors. This way a layer of quality assurance is being provided by Wikidata for the Wiktionaries that is harder to breach than merely containing the entries in isolation.
Also it is not expected that everything represented in Wiktionary can be added to Wikidata. Complex etymologies, usage notes, discussions might elude Wikidata for a long while, if not forever.
Wiktionary remains Wikimedia's prime mode of disseminating lexical knowledge in the languages it is available in, just as the Wikipedia's obviously remain their primate over the respective Wikidata items. Wikidata is a supporting project, which offers a few novel modes of help to the Wiktionary projects, which they can use if they so wish.
Possible further plans
Whereas the first implementation pass should not spend too much time on bringing the UI for forms into a too compact version. Once we have some data and see some usage patterns, this can be done by for creating tabular views per language and lexical category. Also an automatic creation of the forms based on morphological classes of the lexeme could be attempted then. Both extensions should wait for sufficent data to flow in in order to make the appropriate technical decisions.
Technical implementation details
Lexemes, forms, and senses are entities, but forms and senses are not being described in their own wikipages but as part of their containing lexeme. They are connected with the lexeme through a claim of has form or has sense. A lemma is (a required claim with a string value on the lexeme) or (the monolingual label). They have no description that can be set by the user, but it is automatically generated out of the lexical category and language. The lexical category and language are both properties that are used in claims on the lexeme, but they are required to be set to a concrete value. Lexical properties are also claims on the forms. The gloss is (a claim with a multilingual text value) or (a multi-lingual description) of a sense. The representation is a (required claim with a string value) or (the monolingual label) of the form. There can be only one lemma, lexical category, language per lexeme. There can be only one representation per form. There can be only one gloss per sense. Maybe there should be similar restrictions for transliterations and sense references (as per notes).
Seriously, too many. The proposal is heavily influenced by discussions with Duesentrieb, Micru, Francis Tyers, Lavour, Markus Krötzsch, Eloquence, EncycloPetey, 23PowerZ, User:-sche, and many others. It is also is based on previous work as done for OmegaWiki (thanks to GerardM and Kipcool) in the Wiktionaries, WordNet, etc., as analyzed by a number of researchers. Finally, the end result is heavily inspired by the Lemon model, and thanks to the researchers involved for their time to answer us questions. In short, this work is not my achievement in any way, I am merely editing and trying to bring it together in a concise form. And now that it is in a wiki, feel free to discuss and modify it. --Denny (talk) 12:01, 2 August 2013 (UTC)