Predicate Proposal - Spotify Artist ID/url

Field Name: Spotify Artist ID/url
Field Type: text
Number of values accepted: single
Description: Spotify ID/url for a musical artist
Format as url: true
Url format: "{:id}"

Examples of proper use:

  • Identify/capture Spotify url for a given artist (individual or group)

Examples of incorrect use:

  • A Spotify url for a specific song or album
  • URLs for any other service

Spotify Artist ID/url value: “06HL4z0CvFAxyc27GXpf02”
which would then generate the url "" which is the Spotify artist url for Taylor Swift.

1 Like

This is probably a non-issue if the field name is Spotify Artist URL, but it may be worth noting in incorrect use that this is specifically for musical artists and not to be used for company or organization podcast series.
Ex. Security Soapbox | Privacy, Security and Everything in Between | Podcast on Spotify
Lookout (company) - Wiki | Golden

Should this predicate specifically be tied to ‘artist’? A more generalized predicate of ‘Spotify ID/URL’ could apply to more entity types such as albums, songs, podcasts, etc. This would help reduce the number of near-synonymous predicates.

Ah that is an interesting question. Good point; it might be useful for it to be more generalized to include company/orgs/other entities that have profiles (mostly for podcasts such as : NPR on Spotify ).

It could be generalized to “Spotify ID” with the following modification:

  • Identify/capture Spotify url for a given individual or group.

I do worry about including creative works though, because it would be hard to find the canonical url for albums and songs. I think it would be advisable to keep this under incorrect use: " * A Spotify url for a specific song or album"

Can you expand on why this is difficult? I would consider /track/{spotify_id} and /album/{spotify_id} to be canonical. If a song gets released as a single and then later is included in an album it does get two unique IDs, but beyond that is there an issue?

For ex I would think this ID stays fixed permenantly: Album:

Yes, I guess for songs I was thinking of the cases where the same song appears on two albums or compilations. Ex. These all have different track IDs:

If we allow more than one URL that may not be an issue, though I could see a few cases where a very popular song appears on many compilation albums.

Probably overthinking this, though; song entities are likely rare compared to artists!

So I personally think creating this one that’s tied to a particular artist makes sense, because each artist will eventually have a Golden topic page, and this predicate would link them together. Importantly, it would be tied to the /artist/{spotify-id} url structure, so users can’t/won’t be able to input data that’s just not valid (an album, a podcast, a particular track, etc.)

In the case of music, I think this makes a lot of sense - to have separate url structures for artists, albums, and specific tracks. There’s a whole bunch of data infrastructure in the music industry, and having Golden predicates that match industry data reality sets everyone up for success. (When it comes to podcasts and/or playlists, perhaps we could have a catch-all “other Spotify” url for these?)

I agree with the idea that this should be an artist specific predicate. I would also be in favor of just calling this Spotify Artist ID. This should make it clear to submitters and validators that the id itself needs to be the value even if we display the id via a formatted url string. When urls themselves are the values, there is more ambiguity and a higher potential for duplicates to be submitted.

1 Like

I think we agree here. I assume that any artist/album/track is of equal importance as an entity (all could/should have pages at some point). As long as all of them get predicates it should be fine.

I pictured a generic Spotify ID functioning like a social URL where each entity would simply have a valid field for Spotify. For instance, we have ‘Facebook URL’, not ‘Facebook Person URL’, ‘Facebook Group URL’ etc.

Using ‘Is A’ should make URL pattern matching possible either way.

I’m happy to say that based on the consensus feedback above, the Spotify Artist ID is now live on!

We will adding this soon as a web3 predicate in Golden, along with the detailed description of the predicate.

Now that this is launched, I’ll be locking the thread and tagging it appropriately.

1 Like