1) The question that came up for me recently is how we model the grammatical context for senses. For instance, "to ask" can mean requesting information, or requesting action, depending on whether we use "ask somebody about" or "ask somebody to". Similarly, "to shit" has entirely different meanings when used reflexively ("I shit myself").

but I don't even know what that field should contain, exactly.

scripts) of the same lexeme. In English we have "color" vs "colour", in German we have "stop" vs "stopp" and "Maße" vs "Masse". In Serbian, we have a Roman and Cyrillic rendering for every word. We can treat these as separate Lexemes, but that would mean duplicating all information about them. We could have a single Lemma, and represent the others as alternative Forms, or using statements on the Lexeme. But that raises the question which spelling or script should be the "main" one, and used in the lemma. I would prefer to have multi-variant lemmas. They would work like the multi-lingual labels we have now on items, but restricted to the variants of a single language. For display, we would apply a similar language fallback mechanism we now apply when showing labels.

What do you think?

There are many many words with multiple spellings, but not many words

wrote:

Hi all! Sorry for the delay. To keep the conversation in one place, I will reply to David, Denny, and Philipp in one mail. It's going to be a bit long, sorry... Am 11.11.2016 um 23:17 schrieb David Cuenca Tudela: ("Gxxx", object" qualifier reflexive I see no need for a separate entity type, this could be done with a regular Item. If we want this to work nicely for display, though, the software would need to know about some "magic" properties and their meaning. Since Wikidata provides a stable global vocabulary, it would not be terrible to hard-code this. But still, it's special case code... This is pretty similar to Lemon's "Syntactic Frame" that Philipp pointed out, see below. as for corruption...). You can always use a statement for this kind of information, just as we do now on Wikidata with properties for the surname or official name. The question is how often the flexibility of a statement is really needed. If it's not too often, it would be ok to require both (the lemma and the statement) to be entered separately, as we do now for official name, birth name, etc. Another question is which (multi-term lemma or secondary lemma-in-a-statement) is easier to handle by a 3rd party consumer. More about that later. special kind something like Yes, this would be very convenient. But it would also mix levels of content (editorial vs. sourced) that are now nicely separated. I'm very tempted, but I'm not sure it's worth it. Am 12.11.2016 um 00:08 schrieb Denny Vrandečić: yourself". Yes, the boundary to a phrase is not clear cut. But if we need the full power of modeling as a phrase, we can always do that by creating a separate Lexeme for the phrase. The question is if that should be the preferred or even the only way to model the "syntactic frame". It's typical for a dictionary to have a list of meanings structured like this: to ask to ask so. sth. to ask so. for sth. to ask so. about sth. to ask so. after sb. to ask so. out ... It would be nice if we had an easy way to create such an overview. If each line is modeled as a separate Lexeme, we need to decide how these Lexemes should be connected to allow such an overview. I feel these "frames" should be attached to senses. Making all of them separate Lexemes will drive granularity up, making things hard to follow and maintain. exactly. It could be a reference to an Item. Perhaps that item defines a specific pattern, like "$verb someone" or "$verb someone something" or "$verb oneself". That pattern (defined by a statement on the item) can then be used to render the concrete pattern for each word sense. the Possible, but then it's unclear which parts of the grammar are required to generate a specific meaning. You'd need some kind of markup in the example, which I would like to avoid. the machine-readable, Getting rid of bots that keep duplicate data in sync was one of the reasons we created Wikidata, and one of it's major selling points. Bots have a lot of uses, but copying data around isn't really a good one. Also, how do you sync deletions? Reverts? The semantics is not trivial. True. But that's not how other dictionaries work: https://dict.leo.org/ende/index_de.html#/search=color http://www.merriam-webster.com/dictionary/colour http://www.dictionary.com/browse/color?s=t Oxford even redirects: https://en.oxforddictionaries.com/definition/color Only dict.cc makes the distinction: https://www.dict.cc/?s=colour vs https://www.dict.cc/?s=color We are collecting a LOT of information about each Lexeme. Duplicating it for all spelling variants is going to be a HUGE pain. And it's not rare, either. I estimate that we'll be storing like 20% duplicates (assuming one in five words has two spellings, on average, across all languages). That also means 20% duplicate notifications in your feed, 20% more pages to watch. I don't like it... think it keep Just show all variants, unless told otherwise. In the order given. There are many many words with multiple spellings, but not many words with more than two, and few with more than three [citation needed]. We have the problem of distinguishing these cases for all the modeling variants. Well, with statements you *could* use SomeValue, but I highly doubt that people will do that. True. When the full power of a Statement or Lemma is needed, just create one. I'm just saying that in the vast majority of cases, that's overkill, and a pain to manage, so that should not be the default way. version? I currently prefer to just always show all spellings, in the order given. For people who strongly prefer one version over the other, filtering/sorting can be applied by a gadget, or server side formatting code. Consumers that only want to show a single lemma can just show the first. Sure, people will need to figure out primacy. But they would have to do this also if you go with Statements (which spelling will be the one single lemma?) and separate Lexemes (either show all, or pick the "main" one somehow). different the data but for I think for a 3rd party consumer that does care about variants, it's a LOT simpler to deal with multiple lemmas than to deal with Statements with special properties, getting the ranks right, etc. And for those who don't care about variants, joining list elements or just showing the first element is simple enough. Also: a Wikibase client will need code for dealing with TermLists anyway, since it needs to handle multi-lingual item labels. My broader point is: by keeping the (ontology level) meta-model simple, we would make the actual (instance level) model more complicated. I prefer a more complex meta-mode, which allows for a simpler instance model. The instance model is what the community has to deal with, and it's what we'll have gigabytes of. beginning. That is true. But if we miss a crucial aspect, people will build workarounds. And cleaning those up is a lot of work - and sometimes impossible. This is what is locking us into the ancient wiki syntax. People *will* capture 99.9% - the question is just how much energy that costs them, and how re-usable the result is. Agreed. But how exactly? For instance, take the two Wiktionary pages on "color" and "colour". Would they benefit more from two separate Lexemes (similar to how things are on Wiktionary), or from a single Lexeme, to automatically keep the pages in sync? The model determines how our data is going to be used. We cannot rely on the presentation layer to work out kinks in the model. And more importantly, we can't make fundamental changes to the model later, as that would break millions of pages. about Slow iteration is nice as long as you don't produce artifact you need to stay compatible with. I have become extremely wary of lock-in - Wikitext is the worst lock-in I have ever seen. Some aspects of how we implemented the Wikibase model for Wikidata also have proven to be really hard to iterate on. Iterating the model itself is even harder, since it is bound to break all clients in a fundamental way. We just got very annoyed comments just for making two fields in the Wikibase model optional. Switching from single-lemma to multi-lemma would be a major breaking change, with lots of energy burned on backwards compatibility. The opposite switch would be much simpler (because it adds guarantees, instead of removing them). I would prefer to keep the user generated *data* as straight forward as possible. That's more important to me than a simple meta-model. The complexity of the instance data determines the maintenance burden. Am 20.11.2016 um 21:06 schrieb Philipp Cimiano: https://www.w3.org/community/ontolex/wiki/Final_Model_ Specification#Syntactic_Frames Ah, thank you! I think we could model this in a similar way, by referencing an Item that represents a (type of) frame from the Sense. Whether this should be a special field or just a Statement I'm still undecided on. Is it correct that in the Lemon model, it's not *required* to define a syntactic frame for a sense? Is there something like a default frame? [...] but two Indeed, sorry for being imprecise. And yes, if we have a multi-variant lemma, we should also have multi-variant Forms. Our lemma corresponds to the canonical form in Lemon, if I understand correctly. I agree. I think Denny is concerned with putting that burden on the application. Proper language fallback isn't trivial, and the application may be a light weight JS library... But I think for the naive case, it's fine to simply show all representations. Thank you all for your input! -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V. -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V. _______________________________________________ Wikidata-tech mailing list Wikidata-tech(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

I am not a friend of multi-variant lemmas. I would prefer to either have separate Lexemes or alternative Forms.

There is one thing that worries me about the multi-lemma approach, and that are mentions of a discussion about ordering. If possible, I would suggest not to have ordering in every single Lexeme or even Form, but rather to use the following solution: If I understand it correctly, we won't let every Lexeme have every arbitrary language anyway, right? Instead we will, for each language that has variants have somewhere in the configurations an explicit list of these variants, i.e. say, for English it will be US, British, etc., for Portuguese Brazilian and Portuguese, etc.

Given that, we can in that very same place also define their ordering and their fallbacks.

The upside is that it seems that this very same solution could also be used for languages with different scripts, like Serbian, Kazakh, and Uzbek (although it would not cover the problems with Chinese, but that wasn't solved previously either - so the situation is strictly better). (It doesn't really solve all problems - there is a reason why ISO treats language variants and scripts independently - but it improves on the vast majority of the problematic cases).

So, given that we drop any local ordering in the UI and API, I think that staying close to Lemon and choosing a TermList seems currently like the most promising approach to me, and I changed my mind.

My previous reservations still hold, and it will lead to some more complexity in the implementation not only of Wikidata but also of tools built on top of it,