And one of these would/will be “soprano vocals”. I don’t see the issue here. 
You would type “vocals” or “lead vocals”.
1 Like
[quote=“Freso, post:6, topic:105524”]
And one of these would/will be “soprano vocals”. I don’t see the issue here.[/quote]
The issue is that I’m looking for vocals in a list of instruments.
Why? How did I know to type that?
2 Likes
I would image that it would get renamed to something like “instruments and vocals” or “instruments/vocals”.
How do you know to type “guitar” if someone is credited with “guitar”?
1 Like
I wonder how it’d interact with any (hypothetical, future) attempt to add roles to opera works, and linking those with a performer on a release? I guess it’d probably not matter, as it’d just go unused for instruments…
The issue: we would make a very common case harder. I.e. a usability regression.
… iff the future UI will work as we imagine. It all depends on the details. I guess one could come up with a dialog that is more streamlined. One off-the-cuff suggestion is to have both „add instrument“ and „add vocal“ buttons in the same dialog.
What I like about the suggested change is that it makes the case of mixed vocal/instrument performers easier – like the archetypical guitar-plus-vocal. No need to add the artist twice!
1 Like
That would also be served by any relationship that has an instrument/vocal attribute including both UI parts. I’m not sure that moving vocals into the instrument ui would improve usability.
1 Like
I think all this UI discussion is beside the point. It is essential to decide how to best represent things at the database level; what the editing UI or a tagger make from this is secondary.
4 Likes
Right now, that only works for relationships that use them as attributes. We can’t, for example, have a relationship that says “this artist predominantly performs soprano vocals”, while we could do that with electric guitar. Similarly, we could relate a violin and piano work to “instrumentation: violin and piano”, but not a voice and piano one. Just UI changes don’t solve that issue, which is basically that vocals and instruments are currently completely different levels of data, despite being basically equivalent in use.
3 Likes
I strongly disagree here. The discussion here clearly stated that it will affect the UI and is not merely a data structure change not visible to the user. If it is only a change in data and the UI stays the same there is no need to discuss this.
But as I understood it so far it is planned to merge the instrument and vocal trees and this will change the UI. I see having just a single “instruments” select list which also contains the vocals as confusing and a loss in usability. I am sure we can find ways to make up for this somehow with some UI changes, but these need to be part of this discussion.
4 Likes
I’ll grant you that better representation at the database level is primary, and the editor UI or use of data is secondary. But usability regressions also matter. Therefore, it might be that a desirable database change must not proceed until an complementary UI change is also designed and ready to proceed.
5 Likes
I think for this to work the taxonomy represented by the Instruments table would need to be a hierarchical one. So at the top there would be a “Vocal” or “Voice” category; with subcategories for the typical “Soprano”, “Alto”, “Tenor”, and “Bass”; with further subdivisions below that. Then UI’s could employ the hierarchy to use filters to present to the users a subset of the available instruments if that aids in usability. I would also argue that a hierarchical taxonomy is more than a mere accommodation of UI needs; but represents better data modeling of instruments since there is an explicit “type of” relationship between Instrument types that can be used to find “similar” instruments.
1 Like
I think merging vocals and instruments could be useful, since we already have “instruments” that are the body of the player, and there are edge cases that could be classified as a either an instrument or a vocal (such as beatboxing). Then again, if we go with @dukeja’s suggestion, we’ll still have that problem (though it’s still a good suggestion).
Not really a useful comment of mine, I know, just some random thoughts. 
This may be taking the conversation a bit too far afield, but I thought some involved in this conversation would appreciate this. The ICOM International Committee for Museums and Collections of Musical Instruments has adapted an old and widely supported classification system called the Hornbostel-Sachs classification system to classify the various instruments they keep in their collections. The thing is, that classification system doesn’t necessarily lend itself to improved UI experiences. The UI experience, as well as the way in which instruments are referenced in music compositions, recordings, or releases; isn’t from the perspective of a museum curator.
But it’s interesting to look at. Perhaps the coding system could be used to remove ambiguity.
I think Musicbrainz, taking a leaf from Wikipedia’s book, already traces its „Instrument Tree“ in part to Hornbostel-Sachs.
In our context, I think H-S is too academic to be very helpful. At least I always forget what an ideophone is…
It’s also quite old, is it updated to developments of the last 40 years? C.f. the recent discussion of sequencing/programming/…
@dukeja’s link is an update of that classification. But I have only read a little bit, because it’s a long document.
Personally I think that a “tree” is a bit too limiting for classification. For example, instruments can be both chordophones and electrophones. That’s hard to visualise in a tree.
1 Like
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.
1 Like
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.
6 Likes
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
1 Like
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 
9 Likes