Notes on Creating the WebJay API

Am catching up a bit here as I’ve been on holiday and then away travelling over the last few weeks. Lucas Gonze has written up an excellent response to my XTech paper discussing the design decisions and trade-offs he encountered whilst designing the WebJay API.
This was exactly the kind of discussion and sharing I was hoping to trigger. Gonze makes a few other points, notably about problems with web frameworks and client libraries in this posting to rest-discuss.
I should also apologise for not highlighting WebJay’s use of XSPF in my paper. Gonze rightly points out my omission. I found WebJay to be the simplest and most elegant API that I reviewed.
I think I may give it 12 months or so and then take another trawl back through available services and see whether the state of the art has moved on at all.
In his write-up Gonze notes that: I just realized while I was working on this document that there’s no way to get from an XSPF playlist on Webjay to the FOAF profile of the creator; ideas on how to fix that are welcome.
My suggestion is as follows:

  • Provide a FOAF export of the WebJay profile information. There’s enough data already captured (name, email, homepage) to create a minimal profile with enough IFPs to allow it to be easily merged with other data on the web. This will also provide a hook if a user doesn’t have their own profile
  • Give the WebJay FOAF profile more utility by providing links to a users playlist metadata (perhaps via an XSPF-RDF conversion).
  • Revise the WebJay account management form to allow a user to enter a link to another FOAF profile, e.g. one they maintain themselves. This would be rdfs:seeAlso‘d from their WebJay FOAF document
  • Revise the XSPF export to include a hook to the WebJay FOAF description. As XSPF uses namespaces, I’d be inclined to just add FOAF terms directly, e.g. a foaf:Person element and rdfs:seeAlso link to the profile. The alternative is to create a new custom element to link to additional metadata about the user.

I think that covers all the bases: adding additional coherence to the WebJay API by allowing navigation between users and playlists, whilst also allowing navigation from WebJay metadata to other documents on the Web, i.e. a users FOAF profile. As Audioscrobbler also provides a FOAF export of its users metadata, some interesting application possibilities begin to open up, e.g. recommending playlists based on a users listening habits. See the section, “Connecting Social Content Services” in my paper for some relevant further discussion.

One thought on “Notes on Creating the WebJay API

  1. Ton of Posts – to appease the Aggregator God

    So my aggregatopr rules my life = demanding that I feed it everyday with Attention. Attention that I could be selling, if Steve Gillmor had his way. So the only way I know how to appease him (or maybe sh’s a she?) is to spit back a few posts that I’ve …

Comments are closed.