daniel added a comment.

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.


TASK DETAIL
https://phabricator.wikimedia.org/T190033

EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: WMDE-leszek, daniel
Cc: Lydia_Pintscher, WMDE-leszek, Aklapper, daniel, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to