The core is a "converter" file similar to a dictionary with lists as keys:
B : ɸ, β, f, p͡f, p͜f, ƀ
E : ɛ, æ, ɜ, ɐ, ʌ, e, ᴇ, ə, ɘ, ɤ, è, é, ē, ě, ê, ɚ
D : θ, ð, ŧ, þ, đ
G : x, ɣ, χ
...
This is then converted into a dictionary in which all list-items are a key and the original key is a value. This is for maintenance reasons, as it is much easier to handle such a structure than, say, a csv-file in which all sound-class-symbols are repeated. This format could be stored in JSON, but JSON is difficult to handle, as the specification replaces unicode symbols with the \u003 construct. Maybe the INIT structure is best, as one could define a key with a list of items. Internally, the list can be converted to json or any other format to make it quicker to load it, but there should be a backend for quick editing of the files.
Here's the current description of the basic structure.
The core is a "converter" file similar to a dictionary with lists as keys:
This is then converted into a dictionary in which all list-items are a key and the original key is a value. This is for maintenance reasons, as it is much easier to handle such a structure than, say, a csv-file in which all sound-class-symbols are repeated. This format could be stored in JSON, but JSON is difficult to handle, as the specification replaces unicode symbols with the
\u003construct. Maybe the INIT structure is best, as one could define a key with a list of items. Internally, the list can be converted to json or any other format to make it quicker to load it, but there should be a backend for quick editing of the files.