Property talk:P5911
Documentation
paradigm this lexeme belongs to, pattern of forms of the lexeme
| Represents | paradigm (Q1428334), inflection (Q207857), paradigm classification (Q7134150) | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Data type | Item | |||||||||
| Example | no label (L21339) → odd inflection (Q56633433) no label (L20900) → even inflection (Q56633409) no label (L21337) → even inflection (Q56633409) | |||||||||
| See also | has paradigm class (P5913), conjugation class (P5186), noun class (P7165) | |||||||||
| Lists |
| |||||||||
| Proposal discussion | Proposal discussion | |||||||||
| Current uses |
| |||||||||
| Search for values |
List of violations of this constraint: Database reports/Constraint violations/P5911#Value type Q1428334, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P5911#Target required claim P407, SPARQL, SPARQL (by value)
List of violations of this constraint: Database reports/Constraint violations/P5911#Scope, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P5911#Conflicts with P7165, search, SPARQL
Rename to "form pattern"?[edit]
There are entities like Lexeme:L19340 that have a general purpose and special purpose form. We could make an element that describes this format, but this wouldn't be an inflection class.
Should this property be renamed for this, should we merely adjust the constraints, or should we go ahead with Wikidata:Property_proposal/form_pattern_of_lexeme and use that there? --- Jura 12:14, 25 October 2018 (UTC)
- "Format class" means nothing to me, and I wouldn't associate it with inflection. —Rua (mew) 12:56, 26 October 2018 (UTC)
Yes, it describes the addition, but not necessarily the existing values. "form pattern" could work better (I updated the section header accordingly). Obviously the current label could remain an alias. --- Jura 14:06, 26 October 2018 (UTC)
- But nobody calls inflection a "form pattern". —Rua (mew) 10:41, 27 October 2018 (UTC)
- I don't think that matters, but a separate property is probably preferable. --- Jura 11:31, 31 October 2018 (UTC)
- As the other one was closed as not done, I guess we are stuck with this. I added the corresponding alias. --- Jura 17:32, 7 November 2018 (UTC)
- I don't think that matters, but a separate property is probably preferable. --- Jura 11:31, 31 October 2018 (UTC)
requires P407[edit]
Why does it require language of work or name (P407)? Wouldn't the language always be the language of the lexeme itself? --Yurik (talk) 18:13, 9 August 2019 (UTC)
Clarifying Usage Rules[edit]
Hi, there has been a lot of discussion in the ru-wiktionary on how to use this property. Languages may have more than one "morphing classification systems", e.g. there could be a well established rule for declensions studied in schools, and there could be a professional system, used primarily by philologists, e.g. Zaliznyak's сlassification (Q66148413). We plan to create as many as (~100-200) items, one for each classification type according to each systems. Example:
Lexeme paradigm class (P5911) = Zaliznyak noun of type 7c paradigm class (P5911) = 1st declension in Russian (Q66327367)
The biggest concern here is data validation -- the value for P5911 must satisfy:
- the value item must be P31/P279* of inflection class (Q56633378)
Done - the language of the classification system must match the language of the lexeme. This is important because most classification systems are language-centric, so a french word must not be classified according to the Zaliznyak's classification system. I don't think basic constraints can handle that, but we can probably set up a custom rule for this. The current restriction that the item must have language of work or name (P407) could be the basis of that.
- @Yurik: There are cross-linguistic inflection classifications, such as Germanic strong conjugation class 4 (Q56649310). —Rua (mew) 21:21, 20 August 2019 (UTC)
- @Rua: I did say "most" :). Being cross-linguistic doesn't mean classification applies to all the languages, but rather to a well defined limited list - thus allowing validation. In the worst case, having no language defined on classification item simply disables the validation of that rules' applicability. If classification can be used on more than one language, we should add all applicable languages to the classification - thus enabling validation. This moves all the complexity to the meta items, and keep millions (billions?) of the individual words simple. --Yurik (talk) 21:43, 20 August 2019 (UTC)
Removing word stem (P5187) restriction[edit]
One restriction seems excessive -- word stem (P5187) -- in case of Russian, where most words will have at least two classification systems, having a stem attached is redundant and may cause more issues than solve. The word itself has one (or more) stems, and they should not be repeated for every value of P5911. Instead, we think it should not be used at all, and in case of multi-stem words, use integer position.
New rule:
- a lexeme itself should always have a paradigm class (P5911)
- for multi-stem words, use series ordinal (P1545) as a facet for stems. Same stem might appear more than once with different index.
- property paradigm class (P5911) will not allow word stem (P5187) facets, but multi-stem words should use series ordinal (P1545) facet.
--Yurik (talk) 20:00, 14 August 2019 (UTC)
CC: Afaz, Andreasmperu, Arnaugir, Bjankuloski06, Event, Fnielsen, Infovarius, Iniquity, Jura1, KaMan, Njardarlogar, Pintoch, Renamerr, Taravyvan Adijene, Rua, Sobreira, ديفيد عادل وهبة خليل 2 would be great to get your feedback, thanks! --Yurik (talk) 22:59, 19 August 2019 (UTC)
- Since nobody has replied to this in over a year, I've gone ahead and removed it. I agree that it seems excessive. There may be some languages where it's necessary information, but in the languages I'm familiar with, you can start from the lemma. - Nikki (talk) 08:40, 2 December 2020 (UTC)