I think it is actually mutually exclusive to maintain backward compatibility, and adhere to standards, if the backward versions are not standards compliant. So I’d prioritize being compliant, avoiding backward incompatibility going forward, and attempt to minimize the cost of migration. If there is sufficient reason to support the existing standard, maybe there is a reason to do that, but maybe it’s more properly SALI’s job.
Modularity makes a lot of sense, as does SKOS for the taxonomic elements, potentially. But I would need to dig into LMSS and other resources further to have an opinion on whether the right place to start is carving part of LMSS out, or of there are more fundamental pieces missing.
I am reminded that the government of Canada last year released it’s first enterprise-wide data standard, and it was for provincial and territorial abbreviations. Thirteen lines of code, give or take. Almost absurd in how small it is. But also exactly the right place to start.
I would actually discount the value of a collaborative editing UI. The point of something like this is that it should get used once it exists. If it’s not used, how easy it was to edit doesn’t matter.
I would focus very hard on what people are or could be using it for, and the standards that will support those uses. Then, you will know what technologies will support those standards, and you can decide how easy it can be made to collaborate using those standards. But if making it easier to use makes it harder to edit, it should be harder to edit.
I am a fan of ontologies (and to a lesser extent, taxonomies), and I think they may have a role to play as a source of truth for standards, but I don’t think that OWL or SKOS files should be the only or primary “product.” As a general rule a CSV file is more useful. To the extent that being more useful is inconsistent with backward compatibility, I would prioritize usefulness, too.
