InflectionType

[chiarcos]

current definitions:

• Class morph:InflectionType represents a single slot for a single grammatical category for all its possible values (e.g. all the cases)
  • Book analogy: a column from a paradigm table without allomorphy/alternative variants for just a single morpheme
  • property morph:inflectionType assigns an inflectional pattern of a form as belonging to a morphological pattern of a lexical entry

this definition does not work for the current diagram, if one inflection type represents the position for all cases, we cannot associate the form for, say, dative with the rule for dative via inflection type (thanks to Matteo for pointing that out).

Comparing alternatives

current model

1. Form -inflectionType-> InflectionType

2. Paradigm <-paradigm- InflectionType

3. InflectionType -inflectionRule-> InflectionRule

4. InflectionType -next-> InflectionType

alternative 0: keep current model, one inflection type per paradigm and rule

• pro: backward-compatible
• con: unneccessarily verbose: what is the difference to inflection rule then?
• con: still contradicts current definition

alternative 1: detach InflectionType

1. Form -inflectionRule-> InflectionRule
2. Paradigm <-paradigm- InflectionRule
3. InflectionRule -inflectionType-> InflectionType
4. InflectionType -next-> InflectionType

• pro: we basically keep all the information we have, incl. finite state modelling and agglutination
• con: inflection type won’t be used for fusional languages and probably fall out of use
• con: terminologically, the finite state use case is still a bit of a stretch, a better name?

note: paradigms should be allomorphy-free, then (this is at odds with traditional usage of “paradigm”. in inflection tables, it normally includes allopmporphic variants.

alternative 2: replace InflectionType by GrammaticalMeaning

1. Form -inflectionRule-> InflectionRule
2. Paradigm <-paradigm- InflectionRule
3. InflectionRule -grammaticalMeaning-> GrammaticalMeaning
4. GrammaticalMeaning -next-> GrammaticalMeaning

• pro: we basically keep all the information we have, incl. finite state modelling and agglutination
• pro: we eliminate one class and we address a feature request by Penny
• pro: slot information can be plausibly a part of grammatical meaning (or, better, structure)
• con: no explicit data structures for slots, researchers would need to “discover” that from comments => rename next to nextSlot?
• con: for FST, this is very opaque, a better name? => we could introduce a designated subclass “FiniteState” of GrammaticalMeaning !?

alternative 3: merge InflectionType with InflectionRule

1. Form -inflectionRule-> InflectionRule
2. Paradigm <-paradigm- InflectionRule
3. InflectionRule -grammaticalMeaning-> GrammaticalMeaning
4. InflectionRule -next-> InflectionRule

• pro: we keep all the information we have, incl. finite state modelling and agglutination
• pro: we eliminate one class and address a feature request
• pro: “rule” is more relatable to what a finite state does than “inflection type” (which sounds static)
• con: no explicit data structures for slots, researchers would need to “discover” that from comments
• con: in agglutinating languages, the sequence is not over replacement rules, but classes of morphemes, so we lack a formal data structure for slots
• con: for FST, this conflates states and replacements, normally one state can have different replacements (“rules”)

[chiarcos]

my favorite would be alternative 2, with the following modifications:

• rename GrammaticalMeaning to FeatureBundle (a “slot” is described as a bundle of features, so that makes sense, and finite states are informally associated with some kind of function, but typically not a specific grammatical meaning, esp. for morphophonological processes)
• introduce a subclass FiniteState of FeatureBundle (we would informally capture the finite state itself as a feature, and the bundle would consist of exactly one such feature)

[pennyl67]

For fusional languages, alternatives 1 - 3 have no difference, as they all "drop" InflectionType. (See examples added at the minutes to be discussed next time: https://docs.google.com/document/d/1ckwhltPxJKxFpEOwTanOHHHIM0HvYm_Q38B191e1dpY/edit#heading=h.28k0zvfnaaec).

Note that for the current model, we have added grammatical meaning (be it a single feature or a set of features) as a property on inflection rule (this is not depicted in the diagram, see issue https://github.com/ontolex/morph/issues/11).

The current model is less economical compared to the other alternatives; so, alternative 2 sounds ok, but let's see also how this can be used for agglutinative languages.

Regarding renaming "GrammaticalMeaning" to "FeatureBundle", +1.

[chiarcos]

current diagram implements alternative 1

[chiarcos]

• closed with https://github.com/ontolex/morph/blob/master/doc/wrapup/minutes-2025-06-04.md, note the renaming of inflectionType to inflectionSlot and of paradigm to inflectionClass.