Curious…
If an artist’s website was to provide an API, what services would the API have that would be of interest? UPDATE: as some pointed out, this would also apply to groups of artists, but its easier to start granular and work to conglomerate than go the other way.
Gut response – a univeral, open artist’s API is a lot bigger deal than any individual artist’s API. But if there were an API standard or toolkit that anyone could access – then a lot of neat things open up…mashups like maps of concert tours or photos of places mentioned in lyrics or 100 other things.
I agree with Lee.
There’s too many artists for any one api to be useful.
The only type of person who would find a solo act’s API useful would be a fan, who by their very nature, wouldn’t know what to do with an api. A few would, much like a young Ethan with REM, but the vast majority wouldn’t.
agreed. but starting granular is an easier manner of thinking. What applies to an artist as singular can easily apply to artists (plural), with some added API calls to deal with the aggregate (ie, artists by genre, by year, etc).
Considering we use Drupal its not that hard to imagine an API that abstracts all artists on our label. From there, a standard, from there… you see where I’m going.
A few suggestions:
- Basic bio information (structured & time-tagged so you could do timelines).
- Calendar with structured & tagged data (i.e. tags that distinguish between ‘concert’ vs. ‘signing’ vs. ‘new album release’ — etc).
- Song meta-data (including deep structured data, like lists of musicians, where recorded, on what type of instruments, etc)
- Multi-lingual versions of songs and/or lyrics.
- Song mood and/or tempo data
- Album meta-data (dates, places, artwork, recording locations)
- Link to artistic influences. Build a FOAF web that spans generations
- Reverse links to cover versions of songs, tribute bands, etc.
- Song lyrics with deep tags (i.e. cross-referenced locations, people, or anything else the artist wants fans to know)
- Contact data (for bookings, etc)
- Favorites (i.e. blogs the artist reads, etc)
- Merchandise URL
- Album download URL
- Alternate format download URL (i.e. ringtones)
- All location data geo-tagged
- DRM/re-use rules (if any) published as a web-service so sites would know what they legally can do if they republish the content or media and pass along the rules downstream.
- Fan-site links in structured form (i.e. with URLs, description, geo-tag, image, etc. + meta-data.)
- Fan-site events republished (including dates/geo-tag locations) for when people do Meetups or special pre-event gatherings.
- Other sites where the artist hangs out (i.e Personal blog, Facebook, Twitter, etc).
- Video links (live, recorded, music video) + mirrors. Also embed code for each one.
- Podcast/audio clip links + mirrors
- Official images, searchable by date and/or location
- Poll API – allowing remote sites to host polls with the data coming back to the artist’s own site
- Widget URL (returns JS/HTML/raw URL embed code for custom widgets)
- Structured list of where else the artist has appeared, for example, web/magazine interviews, movie appearances, etc.
- Most of this information should also be available via RSS/Atom so sites that want to subscribe can get updated data.
- If you want to be *really* cutting edge, maybe an XMPP feed so artists could directly talk to fans in their own personal chat-space.
For all these web-services, you could also support affiliates (a la Amazon). Help build an ecosystem around the artist.
For Calendar data, I’d also offer it as iCal to let people directly subscribe to events in their favorite PIM.
If it was me, I’d publish a lot of this data in XHTML+RDFa (i.e. tagged HTML), or you can go nuts and do an XML micro-grammar, but that often locks you into a specific, strict structure.
The advantage of RDFa is that it lets you publish a normal web-site (i.e. with Drupal) but have individual fields be tagged so an RDFa parser could extract the data.
The other advantage is that you can send the data as RSS content. A combo RSS/RDFa parser would get the body and take out the bits it needs. All you need to do is publish the catalog of tags and what they mean.
A disadvantage is that consumers of the web-service would have to write RDFa parsers, but you could put out a separate API that does the parsing for them and returns the raw data in XML or JSON for those who want it that way.
Just my $0.02. Hope you do it.
awesome suggestions. for XMPP, you are thinking a pubsub service that would do notifications, a la how Twitter’s test XMPP implementation works?
Re: XMPP a la Twitter. Kinda sorta.
You can take it one step further and make the XMPP payload carry the structured data. Sort of a web-service push. To take advantage of that, though, you’d need custom clients that could parse and understand the data formats — none of which currently exist out in the open.
I’d do regular pull web-service first, though. XMPP client libraries are still not as prevalent as plain HTTP. A couple years from now, though, who knows — we could be getting live artist updates pushed up to our iPhones — with built-in maps, music, calendars, etc. while we chat with other fans and arrange where to meet before concerts for drinks.
P.S. Jayzus. Didn’t realize my ‘few’ suggestions would format to such a long comment. Sorry about that.
All the above ideas are great, but personally, I think without a doubt the only API absolutely needed is show data.
Nearly every web service imaginable that attempts to aggregate show data has to do so either by hand, or some nasty method of pulling data from individual sites that are not very friendly. I myself have been trying to build such a site.
I think concert performance would go through the roof if people just had more access to it without having to work hard for it. Give us an API with concert data.
Make it easy for me, the Consumer, to connect with the Artist via:
Last FM ( http://www.audioscrobbler.net/data/webservices)
Amazon’s Unbox
Individual band member’s mobile phones ( Twitter )
FireEagle while they are on tour ( http://fireeagle.yahoo.net/ )
My Google Calendar ( write/update show times )
Two click ticket purchase ( PayPal or Google cart )