Track artist, single artist or multiple?

[ZenithDK]

Can a track have multiple artists? It is just listed as a string now, but should it only ever be one artist or are multiple allowed?
For instance: Placido Domingo and the other two guys from the Three Tenors, just to give an example, or should they be listed as "The Three Tenors"?

[canpolat]

I was thinking about this as well. publisher, album artist and composer can also have multiple values (perhaps there are others).

[sampsyo]

Interesting point. If we do allow multi-valued options, it would be good to come up with some principled way of deciding this (rather than choosing per-field). For example, one easy-to-follow policy would be to say that all string-valued fields should instead be lists of string—or that they can be lists of strings, and that "foo" is equivalent to ["foo"] (one string is a shorthand for a single-element list).

What do folks think about applying this as a blanket policy rather than a per-field one?

[canpolat]

What do folks think about applying this as a blanket policy rather than a per-field one?

I agree :)

[andrewrk]

I'd just like to throw in that I always want fields to have the same type. So if there is an artist field, and there can be more than one artist, then it should be ["artist name"] instead of "artist name" even when there is only one artist. Some people think this is more tedious to code against; I think that it actually results in cleaner and less brittle code.

[ZenithDK]

I'm all for the multiple artists (and composer etc) per field.
As for always represnting them as the same type I don't have enough experience to say what is right, but I see your point @andrewrk - I'm in favor.

[sampsyo]

Yes, absolutely—there's a benefit to avoiding code that needs to check the type of the value.

Taking that to the extreme, we could consider making every field a list—which seems like overkill for fields like track where only one value would ever be reasonable. But it would mean that:

• Clients wouldn't need to decide based on the field whether to index the list.
• We wouldn't be stuck with the decision about which fields deserve multiple values and which don't. If we ever dream up a reason for a field that was previously single-valued to become multi-valued, there would be no compatibility headaches.

[andrewrk]

I don't think it makes sense to have track title be a list. What would that mean if there was more than one track title? Someone implementing the aura API might think to themselves "track title is an array even though it's really just one value and that doesn't make sense. Looks like all the fields are like that." then their code only looks at index 0 of the array for all the fields, so they don't realize that artist name is special and truly does have the potential to be more than one.

[Afterster]

I agree with Andrew, it doesn't make sense to have all fields as a list. Some fields are and will never be multiple, it could only result to a leak of understanding.

[sampsyo]

Points well taken about not going overboard with list-valued fields.

If we do choose "string array" (JSON parlance) as the type for some fields, we should (a) think very carefully about which should be which and (b) err on the side of listiness, since this will be hard to go single-to-multiple later, but a single-element list is easy to do.

Examples of fields that should probably be arrays include: artist, albumartist, genre, composer. Anything else come to mind?

I'll make this change now—feedback or direct fixes welcome. 🐟 😃

[sampsyo]

@ZenithDK, does a list-valued artist field resolve your question? Or were you getting at something else with the Three Tenors example (i.e., there are multiple ways to "say" the same artist)?

[ZenithDK]

@sampsyo Yes, it does resolve my question.
The Three Tenors were just a (may poorly chosen) example to get my point across.
I'm actually not even sure what I would put in myself in that case? :-P Maybe all 3 individual artists and then the group name - as this is a sort of special case?

For Mopidy we have the following: https://docs.mopidy.com/en/latest/api/models/#mopidy.models.Track

name (string) – track name
artists (list of Artist) – track artists
album (Album) – track album
composers (string) – track composers
performers (string) – track performers
genre (string) – track genre
track_no (integer) – track number in album
disc_no (integer or None if unknown) – disc number in album
date (string) – track release date (YYYY or YYYY-MM-DD)
length (integer) – track length in milliseconds
bitrate (integer) – bitrate in kbit/s
comment (string) – track comment
musicbrainz_id (string) – MusicBrainz ID
last_modified (integer) – Represents last modification time

I'm actually unsure of why composers and performers are not "list of Artist" also....

[asutherland]

There's also the issue of artist name versus unique artist id. Arguably since the URI schema already keys artists based on a unique id, the unique id should have primacy and the links/include mechanism should be used for the names.

In terms of having multiple track titles, an example of a scenario like that is remixes that have had different names on different releases. But that can get messy quickly. This could probably be handled via optional aliases or other optional extensible data that is pulled down from musicbrainz/etc and the UI just knows how to consume the data from that schema.

[sampsyo]

There's also the issue of artist name versus unique artist id.

That's a good point. Yes, the link should probably be used when the server supports it (it need not). And perhaps the "link" from track to artist (and album to artist) should be plural.

In terms of having multiple track titles, an example of a scenario like that is remixes that have had different names on different releases. But that can get messy quickly.

Yes, I think it's a reasonable "non-goal" to work as a complete music taxonomy database like MusicBrainz—no need to reinvent that wheel.

(Good to see you here again, @asutherland! Mind if I add you as a collaborator on this repo?)

[sampsyo]

Thanks for the list, @ZenithDK! That's very helpful. I'm going to steal "comments" at least for the AURA list. Feel free to add more too.