Closed ProxPxD closed 8 months ago
Three proposals:
morphemes:
elems: ...
features: ...
morphology:
morphemes: ...
features: ...
morphemes:
...
features: ...
graphemes:
elems: ...
features: ...
graphemics:
graphemes: ...
features: ...
graphemes:
...
features: ...
I - always stable II - always stable and more verbose III - error prone, someone may want define feature as their morpheme identificator, but the most comfortable if someone I and II - it seems unnecessary to have one more depth just for a possibility of defining features there that may never be used
maybe let's allow to do:
morphemes:
...
or
morphemes:
elems:
features:
The validator will the detect whether elems
and feature
are under morphemes
and both ways will work and will be less error-prone
Decision: do the I and potentially extend for the III one later and maybe with a flag
How to structure the grapheme schema? The current idea in toki pona is SCRIPT:
This means that graphemes contain the scripts as first level depth and graphemes as second and not as in morphemes where morpheme is a first level depth.
In morphemes the features are defined as key-value pairs in each morpheme, while graphmes have been defined in toki pona's
feature.yaml
. This is not right.both morphemes and graphemes should have the same interface, so the graphemes can be defined separately with the script defined as their feature an morphemes could be defined in elems lists undes a specific feature. In case of morphemes that feature can be for example
clitics
,prepositions
, etc.Maybe a hierarchy should be extended like: morphology:
Something similar is already mirrored in the deutsch/graphemes.yaml but with a keyword
list
instead ofmorphemes/graphemes
It is related to whether rules should be on the same level as morphemes and graphemes, or should be under them to specific unit. Maybe both ways should be possible so the users used whichever approach is better for them