Closed LinguList closed 7 years ago
Maybe, it is possible, to keep the current machinery for CLTS as some kind of an explorer code to make it easy to expand the data, while setting up explicit collections of metadata in which we spell out the feature bundles and link to the four base types? This would then make the lookup in clts just require to use the meta-data, but if it fails, new sounds could be generated for lexibank, and then evaluated and added to the base list of sounds, similar to the way we do it in concepticon?
I have this first proposal, by which:
In this sense, I think, apart from the JSON-metadata specifications on the different values and types of the metadata, we are good.
We can now use a feature-bundle to distinguish one sound uniquely (we should be able to do that). The definition of a sound, however, the feature bundle, is in four columns: three base columns plus the columns with key:value-pairs. This is useful, but if we want to add meta-data, I am wondering, where to add it:
I'd prefer 1, but if we take the Sound().name as the identifier, it is a bit dangerous that we generate it in a first place, yet if we don't generate it, we may mess up the order when adding new sounds. Currently, the way to create a name is by setting up an order of features in an array, but we may well add new features in the future, and we may even change the order, if people complain.
In any case: we need to set up an example for metadata, and metadata will exist along the following lines (judging from what is there in the literature):