This was one of the reasons we moved from the old “instrument tree” to having instruments-as-entities, which means that a given instrument can be a “child” of multiple “parents” if/as needed.
I agree. But a tree is better than a simple list and can work very well for filters and browsers to aid in UI presentation of instruments. A casual search turned up many efforts to expand upon the antiquated H-S classification system; to turn it into a full fledge ontology that can represent all the complex relationships that a tree cannot. But there doesn’t seem to be consensus. Until some proposed ontology emerges as the standard; it seems that H-S will still be the go to classification system for instruments. It is old; but unfortunately nothing has emerged to dislodge it from it’s perch.
I very much don’t like the H-S structure for our purposes. At least not in how its hierarchy is expressed. I do think that it would be useful to have a mapping from our Instrument representation and H-S; at least at the leaf nodes.
Returning back to the original question. From my perspective I think the proposal in STYLE-609 should be adopted. And I haven’t seen anything mentioned that suggests that the idea should not happen. Just that there are difficult issues to overcome. It seems to me that what the Instrument ontology should be is far from being settled. And I think that if we ignore the UI while developing that ontology; we risk creating an obtuse ontology that is difficult to use; with the result that we get bad data, or no data. We need to make the task of entering data easier, not harder. And if we have an inherently more complex data structure; the burden will be on the UI to aid the user in overcoming that complexity.
So back to adoption of STYLE-609; my vote is to go forward with it; but that the first step in moving forward is to settle the Instrument Ontology design and how that design will be integrated with the UI.
I think this is an important point.
I am also for implementing the STYLE-609 as well (and have been, for years)
as for implementation of UI, this might even tie in with the issues mentioned in Instruments with disambiguation comments with how we implement an UI that is easy to find the right instrument/voice/whathaveyou
I was hoping to discuss this further with developers during this year’s MetaBrainz summit, but the summit has been cancelled. In any case, we have two clear conclusions:
- This is generally wanted.
- We need to make sure the UI doesn’t make things harder to use.
With this in mind, I’ll try to get hold of the devs and see what their UI ideas are