JSON webservice relationships returned

picard
Tags: #<Tag:0x00007f30951ffde8>

#1

One improvement in Picard 2.0 is that it uses the JSON version of the webservice (although it is a pain changing a plugin to work with JSON rather than XmlNode). As well as being a more logical format, it does return slightly more data (see Difficulties with work artist aliases). Now it will return aliases for recording.relations.work.relations.artist - at least when artist is “type: composer”.

However, if the type is “type: arranger” it seems to return an empty list of aliases, even if they exist in the MB database - see track 6 of this: https://musicbrainz.org/ws/2/release/e6bf7d96-2628-3db5-add5-287f4cd2c1ea?inc=release-groups+media+recordings+artist-credits+artists+aliases+labels+isrcs+collections+artist-rels+release-rels+url-rels+recording-rels+work-rels+recording-level-rels+work-level-rels&fmt=json
Levon Atovmian has aliases but they are not listed in the JSON

On the other hand, this one - https://musicbrainz.org/ws/2/release/0aadac63-79e4-4374-8757-a36f887a8121?inc=artists+artist-credits+artist-rels+recordings+recording-level-rels+work-rels+work-level-rels+release-groups+labels+aliases&fmt=json does have aliases for Rimsky-Korsakov as orchestrator on track 4.

Any ideas why this should be?

EDIT: It seems fairly random, since in track 4 of the last release mentioned above, Glazunov is also listed as an orchestrator, with an empty alias list although he has aliases in the MB database.


Difficulties with work artist aliases
#2

It looks like a consistency bug to me. Historically, aliases were not included in results. Query parameter inc=aliases initially returned aliases for the main target, and then for every related entity. The issue might be related to the depth of the entity (artist Levon Atovmian) in the result tree, rather than to the relationship type.

Can you please check this is the same issue as MBS-6576? If not create a separate issue.