Wikidata:Property proposal/ song ID

From Wikidata
Jump to navigation Jump to search song ID[edit]

Originally proposed at Wikidata:Property proposal/Authority control

Descriptionidentifier for a composition, track or single on the music site
Data typeExternal identifier
Domainaudio track (Q7302866), single (Q134556), musical composition (Q207628)
Allowed values[1-9][0-9]*
Example 1Make You Feel My Love (Q56085788)38570
Example 2I Took a Pill in Ibiza (Q21198255)95033 (original), 95500 (Seeb remix) (only one item exists for both recordings as well as the composition and the single releases at present, so both identifiers should be temporarily attached to the existing item until the necessary items are created)
Example 3Eastside (Q55975144)115274
Number of IDs in source46,558 as of 6 August 2019
Expected completenessalways incomplete (Q21873886)
Formatter URL$1
See artist ID (P7109), chart ID (P7138)

Motivation[edit] (Q9580090) is listed as a reliable music charts archive for multiple countries by w:en:Wikipedia:Record charts/Sourcing guide; its data set begins in March 2003 and is still updated.

Acharts uses sequential integers as identifiers for songs/singles and albums; as far as I can tell, the two sets of identifiers do not overlap. (The highest ID for both sets is approximately 125,000 at time of writing, and according to the home page there is a combined total of approximately 109,088 albums and songs/singles.) To my knowledge, there is no formatter URL which would work for both sets.

The Acharts data is occasionally messy for songs/singles, because it seems to use simple title matching to some degree. As a result, a number of entities may refer explicitly to singles instead of tracks, and some singles may be duplicated (e.g. Tonight and Tonight / Miss You Nights by Westlife (Q151241) have separate IDs due to being released differently in different countries, despite all releases containing both "Tonight" and "Miss You Nights"). In addition, different charts may have changed their charting rules at different times, so one song ID may represent both a single release (i.e. MusicBrainz release group ID (P436)) and a track (i.e. MusicBrainz recording ID (P4404)). This is further complicated somewhat because Wikidata uses two mutually exclusive systems for organizing songs, with about 1,000 following the MusicBrainz convention and most others having one item to represent several different MusicBrainz entities. I would suggest the following system:

  • For Wikidata items using the older system of one item per single plus one item for every cover version and B-side, all applicable IDs should be added to the main single item unless an appropriate cover item exists.
  • For Wikidata items using the newer system of one item for every composition, track, single (release group) and format (release), the most appropriate track item(s) should take precedence unless the title clearly refers to a single, in which case the identifier should be added to the item for the single (release group).
  • If an item is converted from the older system to the newer system, then the value(s) for this property should be manually checked if a song title contains a slash, parentheses or words like "remix" or "version", or if the relevant English Wikipedia article (if any) contains more than one chart data table. Otherwise, the value should be moved to the most appropriate track item(s).

Jc86035 (talk) 10:33, 6 August 2019 (UTC)


  • @Moebeus: Does this proposal make sense, or is there a good way to reduce the complexity of this? Would it be better to add these IDs to the composition items, or to always add these to the single items if they exist? Jc86035 (talk) 10:33, 6 August 2019 (UTC)
    @Jc86035: The proposal absolutely makes sense, but this is a tricky subject that hasn't really been solved on WD in any meaningful way. As a concept a "single" or "album" as it relates to record charts is quite different than a single/album as it's defined in Musicbrainz or Discogs. When gold records or similar sales certifications are awarded, there is in many cases no distinction made between a song and a remix of the same song - all variants are grouped together for the purpose of calculating the highest sales figure. It's "fruit salad" when you want "apples" and "oranges" and severely messes with the work that's gone into having greater separation/detail levels. Airplay- and composite charts further complicate matters and our current models simply aren't sophisticated enough to handle it. Moebeus (talk) 19:13, 6 August 2019 (UTC)
    @Moebeus: On the other hand, we might not actually know if tracks were combined, especially in cases where a song might receive several different releases/remixes (or where an award or a certification isn't specific enough). Putting the data on the composition item (for data relating to tracks) or on the release group item (for data relating to singles and albums) and using qualifiers to specify the artist, the credited track(s) and the other possible matching track(s) might also work. (We would probably then be assuming that all singles charts including airplay, downloads or streaming would use tracks as entities, with the rest using single releases, although this wouldn't work for the proposed property without figuring out the inclusion criteria for all 20 of the singles charts.)
    I suppose ontologically there are only three logical paths – increase the complexity of the system, decrease the complexity, or keep the system the same. If we were to include that information thoroughly only the former two options would work (without substantial data duplication), and decreasing the complexity would mean going back to the old system. Jc86035 (talk) 06:34, 7 August 2019 (UTC)
  • Symbol support vote.svg Support David (talk) 06:31, 7 August 2019 (UTC)
  • Symbol support vote.svg Support Moebeus (talk) 15:53, 7 August 2019 (UTC)
  • Symbol support vote.svg Support --Trade (talk) 21:53, 10 August 2019 (UTC)

@ديفيد عادل وهبة خليل 2, Moebeus, Jc86035, Trade: ✓ Done: song ID (P7166). − Pintoch (talk) 19:42, 13 August 2019 (UTC)