This is an umbrella ticket, aiming to clarify several several tickets created ad-hoc, and give a overview of the their combined aims.

In MusicBrainz, there are 'primary' ids (i.e. mbids), which have a one-to-one relationship with all core entities.

There are then 'secondary' ids, which represent ids (largely) from outside musicbrainz, and can a many-to-many (though sometimes implemented as a one-to-many at present) relationship with core entities. Three of these ids, puid, isrc and discid, are what could be considered as fully functional. If 'A' or 'a' represents a core entity (e.g. recording), and 'B' or 'b' represents a secondary id (e.g. isrc), the puid, isrc and discid all provide the following functionality:

1) The ability to store 0 or more B ids for any core entity A.

2) Direct lookup via the website:
http://musicbrainz.org/b/1234 returns a page with a list of associated A entities.

3) Direct lookup via the web service:
http://musicbrainz.org/ws/2/b/1234 returns <b id="1234"><a-list><a id="..." /><a id="..." />...</a-list></b>

4) List of b ids for a core entity via the website:
http://musicbrainz.org/a/id returns a page for entity A with a list of its B ids

5) List of b ids for a core entity via the web service:
http://musicbrainz.org/ws/2/a/id returns <a id="id">...<b-list><b id="..." /><b id="..." /></b-list></a>

6) Submit b ids for a core entity via the web service:
http://musicbrainz.org/ws/2/a POST <a-list><a id="..."><b-list><b id="1234" /><b id="5678" /></b-list></a></a-list>

There are additional core entities that implement some of the above: iswcs, barcodes and asins.

iswcs and barcodes have a one-to-many relationship with works and releases respectively. Both are diplayed on the entities page on the website. Both are returned via the webservice, but in the form of <a id="...">...<b>1234</b>...</a> rather than the above <a>...<b-list><b id="1234"</b></b-list></a>. It is possible do peform a lookup via an iswc, but the returns xml of the form <a-list><a id="...">...</a><a id="...">...</a>...</a-list> rather than the above <b id="1234"><a-list><a id="...">...</a><a id="...">...</a>...</a-list></b>.

asins have a many-to-many relationship with releases, and are displayed as such via the website, but are only shown as a having a one-to-many relationship via the webservice (taking the first asin for each release), and are again shown in the form <release id="...">...<asin>ABCD1234</asin>...</release>.

It is suggested that asins, barcodes and iswcs are promoted to behave as discids, isrcs and puids.

It wouldn't be necessary to switch the relationships to being many-to-many internally, nor fully implement all of the above for all entities. However, it is strongly recommended that the functionality that is currently implemented be made to confirm with the above behaviour, with future functionality implemented likewise, giving a consistent interface for clients, and scope for implementing additional functionality from the above without further changes to any APIs.

In general, maintaining backwards compatibility isn't a major problem. For most situations, <a id="...">...<b>1234</b>...</a> would just become <a id="...">...<b>1234</b><b-list><b id="1234" /></b-list>...</a>. The only awkward problem is iswc lookups via the webservice, which currently returns a work-list as the top-level element rather than an iswc element containing a work-list.