Robert Forkel

So the idea would be that the cocepticon or grammaticon reference is **the** information that lets us understand automatically what a parameter represents - and in the absence of these,...

Well, we have [this recommendation for coding paradigm data](https://github.com/cldf/cldf/tree/master/modules/StructureDataset#multi-dimensional-features) - which is based on a convention @d97hah proposed. So `A`, `S` and `O` would be just additional parameters. Of course,...

Ok, I think I see where this is going :) The data model of `clld` apps knows **two** types of parameters: - The "normal" ones, used to model Features in...

Yes, with the "unit" idea, we could more cleanly separate the ways of looking at lexical data: - Rows in `FormTable` would then be word forms that - if linked...

@XachaB just a quick reply regarding data vs. analysis: I guess if there were a CLDF principle here, then maybe that "your analysis might become other people's data" - so...

Regarding completeness, I think I agree with @LinguList in that whether this is possible at all, is questionable. I'd rather say a paradigm is a set of grammaticon concepts that...

I think the idea of the CLDF spec here is that `Form` should indeed be something that can be meaningfully segmented, i.e. a single string composed of graphemes in some...

Yes, that would work. Alternatively one could model something like "Allomorphsets" similar to cognate sets, and put a foreign key to the Allomorphsets table into FormTable. The latter method would...

Voilà! So you can also call the Allomorph table `morphemes.csv`.

I'd also like that option from a conceptual standpoint: The link from FormTable to MorphemeTable marks the thing in Form as allomorph. With this setup, it may even be possible...