Page MenuHomePhabricator

Should lemmas of a lexeme, and representations of a form be only allowed to defined one per language/variant code?
Closed, ResolvedPublic

Description

Currently users are only allowed to store a single lemma, or form representation for a given language/language variant code. In other words, I could have a lexeme with lemmas:

  • color, en-us,
  • colour, en-gb

but I couldn't have:

  • color, en
  • colour, en.

In latter case, I would either mean to use different language code for lemma variants, or change the way I model to have color and colour modelled as separate lexemes (with a single lemma variant each). Similar applies to form representations.

When doing the edit on the lexeme page, user is not informed on such limitation. The UI pretends that two lemmas/representations are defined with the same language code (as seen on screenshots below), but after reloading the page, and loading the data from the database user sees than only the latest entry for the language code is actually being stored.

multiple-lemmas.png (565×105 px, 4 KB)

mutliple-representations.png (258×75 px, 2 KB)

The question whether it should be possible to store multiple form representations and/or lemmas has been briefly discussed in the email conversation in 2017 (with the particular focus on form representations). Then @daniel concluded, referring to "lit" and "lighted" being two representations of the hypothetical form:

"lit" and "lighted" indeed have to be separate forms (with the same grammatical features set). The justification is that statements that apply to one may not apply to the other: rhymes-with, first known usage, region or time of use, example quotation, syllabification, pronunciation audio - even different spellings! All these would be different, so "lit" and "lighted" have to be separate forms.

Two representations leading to a different sets of statements, and thus to them being representation of two different forms has seemed a convincing argument for me at first. Then I am having seconds thoughts:

  • should some possible statements be a decisive factor on how to model form representations?
  • are we certain there will always be a statement that make the distinction clear?
  • should the modelling always force users to find the distinction that would either lead to creating a language variant code, or to modelling as separate forms?
  • with lemmas in mind, statements couldn't be used as a tool to distinguish different variants, i.e. different variant codes would be required. Should users be forced to always provide those different variant codes?

Question: Should users be only allowed to provide a single lemma, or single form representation with the given language variant code.

Note: the question how to handle this in the UI might be considered at some later point. As the way the lexeme data is currently stored in the database also assumes there is a single lemma or form representation for a given language code (i.e. they're stored as language => data maps). If this was to be changed, this would mean that the code reading from database would potentially need to handle the data stored in the old format too. If the change of the behaviour, and/or the interal storage format is likely, it might be worth doing it before the WikibaseLexeme is deployed in the production environment, so there is no need to deal with the legacy format.

Accidentally, getentities API uses the same structure for lemmas and form representations as used for internal storage. The current format could be observed there (example taken from https://wikidata-lexeme.wmflabs.org/api.php?action=wbgetentities&ids=L560)

"L560": {
      ...
       "lemmas": {
           "en": {
               "language": "en",
               "value": "colour"
           }
       },
       ...
       "forms": [
           {
                "id": "L560-F1",
                "representations": {
                    "en-gb": {
                        "language": "en-gb",
                         "value": "colour"
                    },
                    "en-us": {
                        "language": "en-us",
                         "value": "color"
                    }
                },
                ...
            }
            ...
       ]
    ...
}

Event Timeline

Decision: change the internal data structure to something that does not make the assumption on the one-per-language code element. See T190057 and T190060 for relevant tasks.
@Lydia_Pintscher: For any user-facing changes (i.e. what behaviour UI should have if having a multiple lemmas per language code was not allowed), it could either be specified in those two tasks respectively, or separate tickets could be open to be fixed later.

WMDE-leszek claimed this task.

My 2c, just for the record:

I disagree with the decision, but I don't think it's particularly bad. It means we (and client libraries) can't re-use code that was written for lemmas (e.g. lemmans and representations can't be represented as a JSON object, but will have to be a list). That's inconvenient.

To address the arguments given in the description:

  • should some possible statements be a decisive factor on how to model form representations?

The need for the ability to apply different statements should be, yes.

  • are we certain there will always be a statement that make the distinction clear?

This is not necessary.

  • should the modelling always force users to find the distinction that would either lead to creating a language variant code, or to modelling as separate forms?
  • with lemmas in mind, statements couldn't be used as a tool to distinguish different variants, i.e. different variant codes would be required. Should users be forced to always provide those different variant codes?

I think this is a useful requirement, yes - though this should not be done by hand. Variant codes such as de-x-wikidata-Q2031873 should be composed using an item selector.

I see how this can be annoying to users, and in some cases difficult. However, I fear that not requiring this may lead to people adding lemmas and representations using very different spelling or even in different scripts all with the same code, giving no indication of which should be used when. We then need ranks for lemmas and representations, which would complicate the model quite a bit.

In any case, please not that this is a modification of the abstract model. The specification needs to be changed to accommodate it, not just the internal data structures.

Thanks @daniel for chiming in! What I care the most now is actually the data structure used for internal storage. It would be inconvenient to have different data structures in the DB if it was decided to allow multiple elements per language code (which I am not sure would not be needed/intended, even if now we can come up with some reasons in favour of not doing so). A list instead of map seems to be simply safer option for me.

Data structure exposed to outside world still could be whatever we want. Be the reason to have a particular structure an intend to allow some code to work without a change (arguable reason if asking me), or to avoid users enter data in unclear way, or any other good reason. External stuff can be changed, on the cost of making breaking change. But doing changing in the storage is more painful, from the developer point of view.

In any case, please not that this is a modification of the abstract model. The specification needs to be changed to accommodate it, not just the internal data structures.

To clarify: you mean here, that lemma/representation would no longer be MultilingualTextValues, or would this lead to more changes in the model?

@WMDE-leszek

External stuff can be changed, on the cost of making breaking change. But doing changing in the storage is more painful, from the developer point of view.

Making breaking changes to the public interface is easier for use than changing internals. Its overall cost is a lot higher. Stability and consistency of public models and interfaces is an extremely valuable asset, since it directly impacts community good will and the ability and willingness for re-using our data. Internal breaking changes only cost developer hours. In the big picture, these are cheap compared to community good-will and 3rd party integration.

From the outside, the internal structures are implementations details which can easily be changed, while changing the public interface means work for everybody.

Anyway: If we keep the guarantee of one-terms-per-language-code in the external interface, then there is no need to allow multipe-terms-per-code internally. In fact, that seems counter-productive. The motivations given for changing the internal model all relate to how people enter data. If they can enter multiple terms per language code, they also have to have a way to get out multiple values per code. We can allow that now, at the cost of consistency with labels and changing the model spec. Allowing it later will be very costly.

To clarify: you mean here, that lemma/representation would no longer be MultilingualTextValues, or would this lead to more changes in the model?

That's the minimum change: you'd have to introduce something like a MultiMultilingualTextValues type or some such. But since the proposed change impacts how data can be used, you may want additional changes, such as ranks for lemmas and representations. Or you may want to ditch language codes completely, and just have a list of strings. If we don't require distinct codes, I fear we'll mostly get the same code for all variants anyway. In that case, a simple list would be preferable.

This discussion raises an important question: who owns the public data model and public interfaces? Who are the domain experts to consult when changing the model?