Right now, the webservice gives you only a list of strings, which for some relation types could look like:

'attributes': [ 'additional', 'lead vocals', 'minor', 'alto saxophone', 'background vocals', 'trumpet' ]

(Admittedly a horribly bad made-up example, but you get the idea)

There's no way for a consumer of the webservice to know that 'additional' and 'minor' are boolean indicators, while 'lead vocals' and 'background vocals' are vocal types and 'alto saxophone' and 'trumpet' are instruments! This makes actually using the data a horrible pain.

(Technically, if you have a local list of all possible vocal types and instruments, you can attempt to match them to your list... but that's horrible.)

I would propose changing the json webservice to use the following representation:

'attributes': {
  'additional': true,
  'vocals': ['lead vocals', 'background vocals'],
  'minor': false,
  'instruments': ['alto saxophone', 'trumpet']
}

Note that although all my examples are in JSON, this issue affects the XML webservice, too. I'm not really sure what the representation should look like there. And in either case, changing this would require careful consideration for backward compat (particularly with the XML).