Input gezocht: wat moet de 3VOOR12 API bevatten?
Saturday, November 3, 2007 at 9:20AM Eerst even uitleggen voor de minder technisch onderlegden onder ons.
Wat is een API ? API staat voor Application Programming Interface. Volgens Wikipedia:
Een Application Programming Interface (API) is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel (meestal in de vorm van bibliotheken).
Oftewel: een API beschrijft hoe de informatie van een programma of internetservice is gerangschikt en wat je daar mee kunt / mag. Zo kan informatie van verschillende sites aan elkaar geknoopt worden en ontstaan creatieve toepassingen. Bijvoorbeeld: doordat Flickr en Google Maps met API's werken kan Flickrvision ontstaan. Doordat Twitter een API heeft kan Twitterposter ontstaan. Door informatie vrij te geven, kunnen andere creatievelingen voortbouwen op je inhoud. Dat is leuk en spannend en zorgt doorgaans voor meer bezoek naar sites.
De site van 3VOOR12 is technisch zo gebouwd dat anderen op de inhoud kunnen voortborduren. Elke denkbare informatie is uit 3VOOR12 tevoorschijn te toveren zodat die aan andere inhoud geknoopt kan worden. Wil je een feed met de tag 'Hilversum' zodat je het altijd de onmiddelijk weet als er weer een bericht, concert of band van dat trefwoord voorzien is? Het kan. Wil je een feed met de zoekopdracht 'Pinkpop' zodat elke paar uur de site weer doorgeploegd wordt op zoek naar inhoud met het woord Pinkpop? Het kan. Wil je informatie over de activiteit van je vrienden? Het kan. Zeker nu de afdeling Doe Mee (waar je je eigen voorkeuren opslaat, ziet wat je vrienden doen en goed vinden, etcetera) recent sterk is geupgrade, biedt dit veel mogelijkheden. Je wordt er gekoppeld aan muzikale buren (met vergelijkbare smaken), je ziet het als er nieuws rondom je favoriete artiesten is, je ziet het in een oogopslag als je vrienden een nieuwe blogpost hebben geplaatst, etcetera.
O.K. dat gezegd hebbende. 3VOOR12 is een grote site met veel inhoud. Alles aanbieden heeft geen zin. Selecteren is goed. Vandaar de vraag aan de wat meer technisch onderlegden: als we aan een API gaan werken, wat moet die dan bevatten? Wat is interessante informatie om meer mee te doen? Wat mag in ieder geval niet ontbreken? Vertel het in de comments, we houden er rekening mee!
En de minder technische mensen: als je weet dat internet op allerlei manieren aan elkaar geknoopt kan worden, wat zouden jullie waardevol vinden? Een applicatie die als je naar een concert luister automatisch bijbehorende foto's bij Flickr opzoekt? Een applicatie die inhoud van jouw woonplaats koppelt aan een concertagenda van Upcoming? Ook dat helpt ons nadenken over de inhoud van de API. Shoot!
Reader Comments (22)
En oh ja, natuurlijk is Open Social waar het deze week over gaat: het initiatief van Google om met zijn allen dezelfde taal te spreken. Heel goed! Maar nu gaat het mij primair over de vraag welke informatie uit 3VOOR12 waardevol is voor anderen om te hebben, om iets mee te kunnen.
Koppeling tussen 3voo12 en Last.fm lijkt me super voor event info.
Dat vrienden stuk van 3VOOR12 begint inderdaad heel goed te worden. So Social! Daar wil ik meer mee. Info van mijn vrienden koppelen aan uitgaan of Twitter! En oh ja, ook op de mobiel wil ik mijn vrienden en hun posts en favorieten als startpunt.
Omdat ik niet tot de 312-doelgroep behoor (want van de klassieke muziek) snap ik ook niet veel van de site - maar bij het eerste beeld dat opkwam (London Calling) moest ik ineens denken aan bbc's topofthepops met die aardige informatieve pop-ups op het tv-scherm, waarin via faits-divers achtergond-info werd gegeven over het desbetreffende optreden/filmpje - terwijl ik dit schrijf, speelt op mijn computer operamuzie; een ticker met teksten die meeloppt zou ik dan best prettig vinden; klik op een database-trefwoord "november" en een separaat scherm met het gedicht "november"van Bloem opent, je speler met een onderliggende song met dat woord? enz - ik hou er wel van verrast te worden met iets nieuws - wie van de 312-generatie kent Bloem? voila, vrije associatie al typend... bonne chance
Wellicht is het even interessant om te vermelden dat de API gebruikt kan worden voor grofweg drie doeleinden:
1. Om via externe sites/applicaties informatie (data) in 3voor12 te plaatsen
(denk aan een Mobypicture die zo of foto's doorplaatst naar diverse platformen)
2. Externe applicaties/sites kunnen via de API informatie uit 3voor12 te halen en op eigen site of andere medium gebruiken (denk bijvoorbeeld aan de embed mogelijkheden van video van Youtube op andere platformen)
3. Mashup mogelijkheden via API. Dit zijn koppelingen van twee of meerdere databases op een nieuw platform.
(denk bijvoorbeeld aan Twittervision. Hier wordt Twitter door een ontwikkelaar gekoppeld aan Google Maps, zodat je kan zien wie wat waar op de wereld aan het Twitteren is)
Belangrijk bij ontwikkeling van een API is het definieren van de unieke onderdelen van de (toekomstige) database.
Bij Youtube is dat de gebruikers, (flash)video en de bij flash bijbehorende embed mogelijkheden.
Bij Flickr zijn dat de gebruikers, foto's in combinatie met de attributen (bv. geodata).
Bij Twitter de gebruikers, de vrienden/volgers, de tweets en de locatie.
Wat zijn dat bij 3voor12?
Ik ga er zelf ook naar de mogelijkheden kijken...
Een API is een interface op je database. Hoe meer toegang je geeft tot je database door de hoeveelheid verschillende verzoeken die mensen kunnen doen hoe waardevoller je API in principe is. Volgens mij ontsluit de beste API dus je complete database, behalve persoonsgegevens van je gebruikers en andere gevoelige informatie. Eventueel kun je voor de hand liggende of populaire verzoeken (alles over artiest x, alle recensies over plek x) uitlichten.
Het mooie van een API is dat mensen met een andere kijk soms manieren ontdekken hoe je informatie ook gebruikt kan worden, verborgen waarde. In de database zelf moet je denk ik in het geval van 3voor12 goed aangeven welk item onder welke copyrights valt. De bouwer van de applicatie moet zich dan zelf aan de regels houden door deze informatie niet te laten zien. Je hebt als eigenaar altijd nog controle over welke websites wel of geen verzoeken op je database kunnen doen.
Bedenkt iemand toch iets heel erg leuks voor de data die het 3voor12 domein niet af mag dan kun je hem of haar altijd aanbieden de applicatie te hosten. Een goede discussieplek voor ontwikkelaars die gebruik maken van je API leert je denk ik het meest over wat ontbreekt in een API.
Wat wel belangrijk is om je af te vragen of je alleen informatie op laat halen via je API of dat je mensen ook de mogelijkheid geeft informatie toe te voegen aan de database. Bijvoorbeeld iemand maakt een applicatie waarin je op een artikel kunt reageren. Wil je dan dat deze reactie ook op je eigen site onder het artikel komt.
Hoe vrij maak je de ingang naar je database? De database is één van je meest waardevolle bezittingen, wat je niet wilt is dat hier vervuiling in komt.
Zet hele mmbase cloud open. Laat de mensen het zelf uitzoeken (wat Wlbert zegt). Makkelijk want dan hoef je niet te kiezen als VPRO 8-) Maar andere kant, wat is je social object? Dat vraagt Mathijs zich ook af.
hmm dus wat als je zou moeten kiezen? Eigenlijk vraag je welke bron maakt de beste mashup...
Ok, als je moet kiezen begin je met de muziek van nu. De concerten, djsets en de luisterpaal. Inclusief de sociale interactie eromheen. Jullie sociale object is de muziek, de muziek die bijna daar is of de muziek die net geweest is. Maak dat portable. Elke video, set en nummer is oproepbaar en embedable, inc ratings en feedback. Dat je bij wijze van spreken je eigen nummer kan maken met samples die je uit de api haalt. Want alle muziek kan op de seconde gecued worden.
Samengevat: zet je hele database open en als je niet met de volle 100% wil beginnen: start met de muziek
hmmm: kan je niet een mooie RDF laag boven op de bestande base maken? Ben je direct op weg naar het semantische web zonder dat je te veel zorgen hoeft te maken met je 'historisch ontwikkelde' base die vast erg compelx is geworden in de loop der jaren
Het is de vraag wat je er mogelijk mee wil maken. Als je het mogelijk wil maken dat men een '3Voor12' player in een website kan maken, zijn er relatief weinig calls nodig. Je moet dan van een artiest een reeks urls (audio, video, foto, html) op kunnen vragen met media, zodat een lokaal spelertje deze kan gaan afspelen.
Dat lijkt mij wel aardig, dan kan ik mijn aigen 'Gotan Project' playertje op mijn site zetten. Viral!
Advies voor wat betreft techniek: Wij hebben nu een (te) ingewikkelde API gebouwd voor Sitestat die met SOAP werkt. Dat is onhandig omdat je deze niet makkelijk kan testen. Het mooie van de Twitter API is dat je alles met 'curl' vanaf de command line kan uitproberen, dat maakt het ontwikkelen van een API toepassing kinderspel. Wij zijn onze API nu ook aan het ombouwen zodat dit mogelijk gaat worden; SOAP is echt te moeilijk.
Michiel
Volgens mij is het mooie van een API juist dat je niet weet wat je mogelijk maakt. Je zet een doos legostenen neer en ziet wel wat mensen er van kunnen maken.
Je hebt als leverancier controle over de verschillende mogelijkheden door de hoeveelheid stenen die je beschikbaar stelt. Het ligt voor de hand om met de informatie te beginnen die het mogelijk maakt om zoiets als een speler, kaart of agenda te maken, maar echt spannend wordt het pas als iemand iets maakt waar je zelf nooit aan hebt gedacht.
Wat ik zou willen zien?
* makkelijke call om events, eventinformatie weer te geven
* makkelijke call om artiest, artiestinformatie weer te geven
* makkelijke call om muziekstream, informatie weer te geven (realtime ticker met playlist bijv)
Liefst in een zo makkelijk mogelijk format (veel api's werken met simpele url-calls, zie bijv de 37signals api of de last.fm structuur), zodat iedereen ermee kan werken en alles zo basic mogelijk is: de ontwikkelaars doen de rest.
@Wilbert: Eens, het wordt pas leuk als je publiek er echt mee aan de haal gaat en er dingen mee doet die je zelf nog niet had verzonnen. Maar als je begint met een API moet je wel bepalen wat de legostenen zijn, en dat bedoelde ik met mijn voorbeeld.
Volgens mij moet je ook niet te bang zijn om met een kleine hoeveelheid functionaliteit te beginnen. Als je kijkt in de documentatie van de Flickr API kan je zien dat deze API net zo organisch gegroeid is als de dienst. Hele functiegroepen zijn er bij gekomen, zoals geotagging. Prima!
Ik ben het ook eens met de insteek van Maarten: Wat zijn je social objects. Aan de hand van die objects ('artiesten', 'playlists', 'streamURL') kan je een aantal methodes bedenken die dan redelijk voor de hand liggen. Dat kan je ook zien aan de Twitter API. Je hebt public timeline, je eigen timeline, je friends, je status updates.. en dan een aantal calls om daar de elementaire dingen mee te doen ('maak nieuw', 'geef lijst', 'geef details van bepaalde'). Je legostenen.
Michiel
Input van Don Crowley:
Hi Erwin, Dennis Howlett heeft in de afgelopen 2 weken een post gemaakt over de Seesmic API. Hun API is niet af, maar hun plannen zijn geweldig vind ik zelf. Seesmic willen hun applicatie helemaal open stellen... je kunt alles tegen aan gooien en alles eruit krijgen. Ik kan me voorstellen dat de VPRO copyright issues hebben met zo'n systeem maar dit als basis is erg cool. Wat ik ook leuk vind is sommige aspecten van kyte.tv. Je kunt commentaar leveren op een kyte.tv post (die meestal video is) als chat, video of audio.
IMHO zou ik probeeren alles in de VPRO API te zetten en daarna aan de rechten werken. Je kunt de article van Dennis vinden op http://blogs.zdnet.com/Howlett/wp-mobile.php?p=194
Dennis zit ook op Twitter en op Seesmic. Als je op Seesmic wil hou Loic in de gaten... en laat mij of Erno Hannink het ook weten. Loic geeft af en toe uitnodigingen uit via Twitter. Wij kunnen dat nog niet. Success en bedankt voor de vraag.
Irregular Enterprise mobile edition
http://blogs.zdnet.com/Howlett...
Loic LeMeur’s Seesmic has the ingredients to be a hit - inside the enterprise. Mike Arrington and Ben Metcalfe have rendered their respective cautious verdicts and it would be remiss of me to sound overexcited. ...
@allen Bedankt voor jullie input! Zeer waardevol!
Ik begrijp de reactie 'doe me alles maar dan zie ik wel wat ik er mee doe'. Maar vrijwel elke API kent beperkingen. En als we nu dingen gefaseerd gaan uitrollen, dan helpt het om van mensen te weten wat ze in ieder geval zouden willen / kunnen. De API bepaalt niet wat mensen er mee gaan doen, maar wat de startbouwstenen zijn. Maar jullie info helpt daar zeer bij!
Erwin,
Je zou ook echt buiten de doos kunnen denken en het mogelijk maken om sessie-files tussen artiesten open te stellen.
Een social network voor muzikanten. En zoals jezelf ook zegt: het proces is interessanter aan het worden dan het product.
Mechanical Turk voor muziek, met als voorbeeld HIT: doe mij een strakke beat onder dit leuke deuntje dat ik verzonnen heb.
Ik zou zeker gebruiker worden en als ik Adobe was zou ik Audition er wel mee willen integreren.
Ben benieuwd...
Via Twitter komt van Jan Willem Eshuis binnen:
"Een api met goede selectie mogelijkheden op namen, tijd (datum) , media ed zou top zijn voor 3voor12."
Robert Gaal meldt (ook via Twitter ;-) ):
Paar tips die ik even snel kan geven: kijk goed naar de Flickr API, gebruik OAUTH, doe het RESTful
Zoals je hier zelf ook al eens bedacht: wat je beluistert op de luisterpaal et al doorsluizen naar de last.fm-scrobbler.
[...] Checklist [...]
[...] Checklist [...]
@all Dank voor alle input!
Oeps, ik dacht dat ik allang gereageerd had.....Hier dan nog mijn commentaar (nog net voordat je weg bent bij de vpro ;-) )
Een aantal dingen zijn hier ook al eerder genoemd, maar zijn wel erg belangrijk.
Technische uitgangspunten: maak een REST API, biedt meerdere output mogelijkheden aan (atom, json, xml, rss, etc), maak gebruik van OAuth en eventueel Open Social.
Koppelingen met externe systemen: MusicBrainz en Last.fm.
Voor wat er in de API zou moeten komen kan je onderscheid maken tussen een read en een write API.
Met de read API kan je basis informatie uit 3VOOR12 halen. De basis informatie moeten de 'social objects' van 3VOOR12 zijn, dus:
* artiesten
* events (complex object, want bestaat uit meerdere andere objecten)
* nieuws
* tracks/sessies/programma's/etc
De write API bevat het 'doe mee' deel van 3vOOR12, dus daarmee moet het mogelijk zijn om op artiesten, tracks, concerten, etc te stemmen, beoordelingen te schijven, etc.
Voor gebruik van 3vOOR12 data in bestaande sociale netwerken (hyves, facebook, etc) is het ook belangrijk om de profiel informatie op te kunnen halen, dus wie zijn iemands vrienden op 3VOOR12, wat is de favoriete muziekstijl, etc.
Wat denk ik heel belangrijk is: begin klein en simpel (en probeer 't ook zo simpel mogelijk te houden). Beperkingen in de API zijn niet erg, beperkingen zijn vaak goed voor de innovatie!
[...] Soms met leuke nieuwe initiatieven, maar helaas nog al te vaak met bedroevend resultaat. En dat is niet eens verbazingwekkend, want in essentie bevat het crossmediale denkpatroon dezelfde klassieke push-valkuil als vroeger. Het is daarmee in mijn ogen niets anders dan een hype-woord dat absoluut geen recht doet aan de belangrijke onderliggende ontwikkelingen, die de laatste jaren hebben plaatsgevonden. Een soort tweede Seconde Life… [...]