Ontwerp en implementatie als Mash-Up

Transcriptie

1 Ontwerp en implementatie als Mash-Up Groep 5 Maarten Decat 1e Master Ingenieurswetenschappen: Computerwetenschappen Optie Gedistribueerde systemen maarten.decat@student.kuleuven.be Benjamin Slegers 1e Master Ingenieurswetenschappen: Computerwetenschappen Optie Gedistribueerde systemen benjamin.slegers@student.kuleuven.be Thomas De l Arbre 3e Bachelor Informatica Minor Verbreding thomas.delarbre@student.kuleuven.be Wouter Theetaert 1e Master Ingenieurswetenschappen: Computerwetenschappen Optie Gedistribueerde systemen wouter.theetaert@student.kuleuven.be ABSTRACT Bij dit derde luik van de cursus was het de bedoeling om mashups te integreren in de muziekapplicatie. Er werd teruggegrepen naar het oorspronkelijk idee: het aanbieden van een platform waar jonge bandjes zichzelf kunnen voorstellen (en waar ze kunnen gevonden worden door organisatoren van concerten). Het spreekt voor zich dat de applicatie bijgeschaafd diende te worden in vergelijking met de Flex-implementatie. Hiertoe werd een nieuw storyboard ontworpen. De grootste wijziging situeert zich in het feit dat de groepjes niet langer zelf de data aanbrengen die gebruikt wordt om hun groepspagina op te vullen, maar dat die data op externe locaties wordt gehaald en wordt verwerkt tot een dynamisch geheel. Zowel bij het implementeren van de zoekfunctie (Google Maps) als bij het uitwerken van de groepspagina s (YouTube, Flickr, Seeqpod) werd gebruik gemaakt van mash-ups. In tegenstelling tot het Flex-gedeelte van de opdracht lag de klemtoon deze keer minder op de grafische kant, maar meer op de functionaliteit. Het resultaat (de uiteindelijke applicatie) kan online bekeken worden [1]. Er staat ook een link naar de applicatie op de wiki. 1. O TWERP Bij het uitwerken van deze opdracht werd in de eerste plaats teruggegrepen naar het oorspronkelijk idee dat ontstaan was na de brainstorm uit de eerste sessie. Het was dan de bedoeling een platform aan te bieden met een duale werking: enerzijds konden jonge, onbekende bandjes er zichzelf op een multimediale manier voorstellen (video, geluid, tekst, foto,...) en anderzijds konden organisatoren van optredens op zoek gaan naar geschikte groepen om hun line-up te vervolledigen. Dit idee werd ook succesvol gerealiseerd in Adobe Flex. Al snel werd duidelijk dat dit ontwerp aangepast diende te worden om een nuttige implementatie met mash-ups mogelijk te maken. Er moest zelfs geschoven worden met het kernidee: jonge bandjes brachten oorspronkelijk zelf hun materiaal aan (video's die ze zelf konden uploaden, eigen foto's, eigen muziek) terwijl het bij het gebruik van mash-ups de bedoeling is om materiaal vanop andere plaatsen te verzamelen en te presenteren. Er werd dus eerst en vooral gezocht naar een toepassing van mash-ups. Een voor de hand liggend idee is het aanbieden van een site met groepspagina's, waarbij de inhoud van de groepspagina een mash-up is van verschillende sites. Het nadeel van dit idee is dat het helemaal niet origineel is (er bestaan al een hoop websites die een dergelijke functionaliteit aanbieden) waardoor het project geen toegevoegde waarde zou hebben. Het leek ons echter belangrijk het doelpubliek van ons oorspronkelijk ontwerp niet uit het oog te verliezen: onbekende bandjes. Wanneer een site met groepspagina's van onbekende groepjes wordt gemaakt, biedt het project wel een meerwaarde. Het is bovendien mogelijk om ook voor de zoekfunctie (uit het tweede aspect van onze Flex-applicatie) een mash-up te gebruiken: Google Maps. Deze piste voldoet aan alle voorwaarden: ze ligt in de lijn van het oorspronkelijk project, ze maakt gebruik van mash-ups en ze biedt een meerwaarde aangezien iets dergelijks nog niet bestaat. Het probleem bij het werken met onbekende bandjes is het ontbreken van informatie. Het leek ons in eerste instantie erg moeilijk om op een gestructureerde manier dezelfde informatie van verschillende groepjes te vinden en te verwerken. Voor bekende groepen zijn heel wat API's beschikbaar, zoals die van MusicBrainz. Locatie, groepsleden, playlists en dergelijke meer liggen slechts een muisklik verwijderd. Zoals eerder aangehaald was het echter niet de bedoeling om een mash-up te maken voor groepspagina's van bekende groepen (dit bestaat al) maar wel van onbekende groepen. Zij zijn echter niet te vinden in MusicBrainz, noch in enige andere API. Gelukkig kwamen we op onze zoektocht naar alternatieven bij Poppunt [2] terecht. Deze site biedt exact wat we nodig hebben: een overzicht van honderden onbekende bandjes in België, op een gestructureerde manier voorgesteld en met alle info die voor onze implementatie nodig is: de naam en de locatie van de bandjes. Om de info van Poppunt te gebruiken werd een screen scraper geschreven. Deze applicatie, die geschreven is in Java en waarover meer info kan gevonden worden in paragraaf 3.1, haalt de nodige gegevens van de website van Poppunt op (concreet: een lijst van de beschikbare groepjes en hun locatie) en stopt deze in een lokale database. Hierop kunnen op een zeer eenvoudige manier queries worden uitgevoerd.

2 De vraag kan gesteld worden waarom de informatie van Poppunt eenmalig in een lokale database wordt gestopt. Een alternatief is om bij elke zoekopdracht de site van Poppunt te gaan screen scrapen. Er is bewust voor gekozen om dit niet te doen. Vooreerst is de info van de site van Poppunt vrij statisch: de info die in onze toepassing gebruikt wordt (de naam van een groepje en de locatie ervan) zal niet snel wijzigen. Daarnaast zou het telkens binnenhalen van meer dan 3000 namen de applicatie nodeloos vertragen. Het is de bedoeling de gegevens in de lokale database op regelmatige basis te gaan updaten door op regelmatige tijdstippen een scrape uit te voeren. Voor de toepassing die wij voor ogen hadden moet dit zeker volstaan. Nu de gegevens beschikbaar zijn, kan de echte mash-up beginnen. Het globale project kan opgesplitst worden in twee grote delen: enerzijds de zoekfunctie voor het opzoeken van de groepjes, anderzijds de groepspagina's die een multimediale mash-up van de groepjes aanbieden (video, muziek, foto). Voor de zoekfunctie werd gebruik gemaakt van Google Maps. Wanneer de gebruiker een zoekopdracht start wordt een kaart van België getoond, met daarop een merkteken (een marker in de terminologie van Google Maps) per gemeente waar één of meerdere groepjes beschikbaar zijn. Bij het klikken op een dergelijk merkteken komt een tekstballon te voorschijn met daarin de beschikbare genres binnen de gemeente, en het aantal groepen binnen dat genre. Wanneer een gemeente effectief wordt aangeklikt, krijgt de gebruiker een overzicht van alle beschikbare groepjes in die gemeente (gerangschikt per genre). Het aanklikken van een groepsnaam voert de gebruiker naar de bijhorende groepspagina. Het globale idee van de groepspagina is ongewijzigd gebleven in vergelijking met wat uit de brainstorm is voortgevloeid en geïmplementeerd werd in Flex. Een groepspagina is nog steeds een platform waar een onbekend groepje zich op een multimediale manier kan voorstellen. Het grote verschil met de Fleximplementatie is dat de groepjes de data nu niet meer zelf aanbrengen, maar dat deze met behulp van mash-ups vanop verschillende locaties wordt opgehaald. De groepspagina bestaat uit een mash-up van drie componenten. Met de bandnaam als zoekterm wordt op YouTube gezocht en het eerste filmpje uit de resultatenlijst wordt op de groepspagina afgespeeld. Er is eveneens een overzicht van de gerelateerde filmpjes, zodat de gebruiker eventueel andere video's van dezelfde groep kan bekijken. Daarnaast wordt ook een zoekopdracht op Flickr uitgevoerd. De eerste vier foto's die hieraan voldoen worden eveneens op de groepspagina gepresenteerd. Een derde en laatste component is Seeqpod. Dit is de muziekcomponent: aan de hand van de groepsnaam wordt gezocht naar MP3-files die daarna worden afgespeeld. Meer info over de concrete implementatie van deze componenten kan gevonden worden in paragraaf STORYBOARD Voor de uitwerking van de opdracht met behulp van mash-ups werd een nieuw storyboard uitgewerkt. De lay-out is zeer analoog aan die van het Flex-project (met uitzondering van het coverfloweffect natuurlijk, dat eigen was aan de Flex-implementatie). Na dat eerste project werd immers beslist om minder tijd te verliezen aan het grafische, de design-kant van de komende projecten. Er zijn natuurlijk lichte wijzigingen aangebracht in het storyboard, maar de rode draad is gelijk gebleven. Verderop in dit verslag staan de verschillende stappen in het storyboard beschreven, samen met een kleine figuur. De figuren kunnen op ware grootte gevonden worden als bijlage bij dit verslag, alsook op de wiki [3]. Op elke pagina van het storyboard zijn vier verschillende deelvensters te zien. Twee ervan blijven hetzelfde over de hele applicatie: het bovenste venster (met daarin het logo van de website en de gebruikers-gerelateerde menu-items zoals Profiel, Berichten, Favorieten, ) en het onderste venster (met daarin de verschillende zoekmogelijkheden). Het tweede venster (de titel van de pagina) en het derde venster (de eigenlijke pagina-inhoud) veranderen wel. Wanneer de gebruiker op de website terechtkomt, krijgt hij/zij een welkomstboodschap te zien en een overzicht van het laatste nieuws op BandStart (figuur 1). Het is ook mogelijk om de gebruiker enkele persoonlijke zaken mee te delen (laatste inlogbeurt, aantal nieuwe berichten, ). Figuur 1: Welkomstpagina Als de gebruiker ervoor kiest om te zoeken volgens locatie (hij/zij klikt op de knop Locatie in het onderste deelvenster) komt hij/zij op de pagina zoals getekend in figuur 2. De kaart van België verschijnt, met markers op de steden waarvan er groepjes in de database zitten. Figuur 2: Zoeken op Locatie Het is de bedoeling dat de gebruiker op de stad van zijn/haar keuze klikt. Wanneer dit gebeurd is, verschijnt een lijst van de verschillende genres waarvan er groepjes vertegenwoordigd zijn in die stad. Per genre staat eveneens aangegeven hoeveel groepjes er bekend zijn. Dit alles kan gezien worden op figuur 3.

3 Figuur 3: Resultaat van het zoeken op locatie Als het aanbod de gebruiker bevalt, kan hij/zij op de naam van de stad klikken (helemaal bovenaan in de lijst). Er verschijnt een lijst van alle genres die binnen de stad vertegenwoordigd zijn, met daaronder een opsomming van de verschillende groepjes binnen dat genre. Het geheel ziet eruit zoals aangegeven op figuur 4. Figuur 4: Overzicht per stad Wanneer de gebruiker tenslotte op een bandnaam heeft geklikt, komt hij/zij terecht op de groepspagina van de gekozen band (figuur 5). De gebruiker ziet een filmpje van de betreffende groep (YouTube), kan muziek beluisteren (Seeqpod) en enkele foto s bewonderen (Flickr). Figuur 5: Groepspagina 3. IMPLEME TATIE 3.1 Screenscrapen Het vinden van gegevens over jonge, onbekendere Vlaamse bandjes was niet gemakkelijk. De voor de hand liggende gegevensbronnen (vb. de bekende API's, zoals Musicbrainz ([4], [5])) geven heel nuttige en bruikbare informatie over bekendere groepen, maar geven nauwelijks tot geen informatie over onbekende bands. Daarom was het onmogelijk om op een dynamische manier data te vinden, en werd er gekozen voor de klassiekere statische methode, nl. screenscrapen. De site van Poppunt [2] bleek een heel handige site om te scrapen, om verschillende redenen. Ten eerste geeft deze site een relatief volledig overzicht van onbekende Vlaamse groepjes (meer dan 3000 zijn er in de database van Poppunt opgenomen). Ten tweede is deze site ook makkelijk te scrapen, omdat alle info over navigatie en zoeken in de URL wordt opgeslagen. Het is mogelijk de URL op een zodanige manier aan te passen dat alle groepjes op één pagina worden weergegeven. Een extra pluspunt is ook dat de database van Poppunt alle locaties van de bandjes bevat, nodig om de overzichtskaart op te bouwen. Omdat voor dit project niet meer nodig was, is de scraper volledig opgebouwd rond deze site. De navigatie via de URL's binnen Poppunt was zo overzichtelijk, dat in theorie het dynamisch uitlezen van data ook had kunnen gebeuren. Er is echter voor gekozen om dit niet te doen, omdat de applicatie voor het overzichtskaartje altijd een overzicht van alle bands nodig heeft (naam en locatie). Dit elke keer dynamisch scrapen zou een zeer trage applicatie opleveren. Bovendien werd in de URL van specifieke band-pagina's gebruik gemaakt van een ID dat niet logisch te achterhalen was, dus was er in elk geval ook een (statisch) overzicht nodig dat de bandnaam aan de band-id koppelt. Als de informatie op de site van Poppunt dikwijls zou veranderen, en ook interessanter zou zijn voor de mash-up, was het gedeeltelijk dynamisch uitlezen wel nuttig geweest. Dan zouden bijvoorbeeld ID en locatie van de band statisch opgezocht en opgeslagen kunnen worden, maar andere, vluchtigere data had dan dynamisch opgehaald kunnen worden. De scraper is volledig geschreven in Java. Er had eventueel een bestaande scraper gebruikt kunnen worden, maar de site van Poppunt was zo eenvoudig om te scrapen dat dat een beetje overbodig was. De data die de scraper vond werd vervolgens opgeslagen in een MySQL-database. Conclusie: De screen scraper is misschien niet de modernste manier om data te zoeken voor een mash-up, maar in het geval van dit project zonder twijfel wel de eenvoudigste en de efficiëntste manier. 3.2 Google Maps Google Maps is een handige API van Google [6] die toelaat vanop elke website de Google tools te gebruiken. De API is volledig te gebruiken in Javascript en blinkt uit in gebruiksgemak. De code blijft compact en eenvoudig leesbaar en levert in korte tijd zeer bruikbare resultaten op. De API Reference [7] is overzichtelijk en levert snel de antwoorden op de meeste vragen omtrent het gebruik van de aangeboden klassen. In combinatie met de vele voorbeelden die op de website van Google Maps en de rest van het net te vinden zijn, leverde het de keuze voor deze API in ons geval weinig problemen op. De beschikbare klassen zijn grosso modo in te delen in twee grote stukken. Enerzijds bevat de API klassen en methodes om gemakkelijk adressen om te zetten naar coördinaten en omgekeerd (wat Google "geocoding" en "reverse geocoding" noemt). Anderzijds is het mogelijk om in enkele regels de typische Google Maps kaartjes toe te voegen aan een website. Aan dit kaartje kunnen markers en info windows toegevoegd worden. Een marker is een aanduiding van een bepaalde plaats op de kaart (gedefinieerd door zijn coördinaten) zonder verdere info. Een info

4 window is een tekstballonnetje dat eveneens toegekend wordt aan een bepaalde plaats op de kaart waarin ook enkele eenvoudige regels HTML weergegeven kunnen worden. Ons doel met Google Maps is het weergeven van alle plekken in België waar groepjes gevonden kunnen worden. Op die manier moet het gemakkelijk zijn om naar groepjes te zoeken in een bepaalde omgeving. In ons geval wordt elke gemeente of stad waar bands aanwezig zijn, weergegeven door een marker. Met een eenvoudige klik op deze marker wordt een info window getoond met daarin bondige informatie omtrent hoeveel groepjes in welke genres er daar aanwezig zijn. In de info window staat eveneens een link naar een pagina waarop al deze groepjes iets gedetaileerder weergegeven kunnen worden. Bij standaard gebruik van het kaartje worden alle bands op alle plekken getoond. Uiteraard kan er eerst gezocht worden op één of ander zoekcriterium (bvb. genre of taal) waarbij het aantal weergegeven groepjes kleiner wordt. Er kan ook gemakkelijk gezocht worden op locatie, waarbij enkel de groepjes daar in de buurt getoond worden op het kaartje. Met Google Maps zijn weinig tot geen problemen ondervonden. De Google Maps API wordt aangesproken m.b.v. Javascript, wat voor moeilijkheden zorgde voor het gebruik van de data. In ons geval kwam de dummy data nog steeds uit een MySQL database. We verbinden hier niet mee vanuit Javascript om verschillende redenen. Enerzijds kan gesteld worden dat het niet slim is private data (bvb. het paswoord van de database) te laten downloaden naar de client zijde (wat steeds gebeurt bij javascript code). Anderzijds is het eenvoudiger en efficiënter de data op te halen naar de server aangezien die meestal in rechtstreeks contact staat met de database, als die al niet op dezelfde machine draait. Om die redenen hebben we voor een soort hybride oplossing tussen Javascript en PHP gekozen: Er wordt verbonden met de database vanuit PHP-scripts op de server. Daarin wordt meteen ook de data verwerkt en wordt Javascript-code geprint. Meer specifiek worden hierbij addmarker() Javascript-statements geprint om per locatie een marker toe te voegen aan het kaartje met de juiste informatie erbij. Voor de gebruiker lijkt de Javascriptcode die alle markers toevoegt statische HTML, maar aan de serverkant wordt deze code wel degelijk dynamisch opgebouwd. Het grootste punt van belang is echter het verwerken van de gebruikte data zelf. Een eerste aandachtspunt is de granulariteit van de data. Per locatie wordt een marker toegevoegd aan het kaartje. Langs de ene kant is een kleine granulariteit van deze locaties gewenst zodat de gebruiker nog een gedetailleerd overzicht van alle groepjes kan krijgen. Anderzijds mogen ook niet te veel markers toegevoegd worden om het overzicht te bewaren. Een goede afweging is omtrent dit probleem zeer belangrijk. Een ander aandachtspunt is de korte weergave van de groepjes in elke gemeente. De gebruikte manier is het weergeven van alle genres op die locatie met daarbij het aantal groepjes in dat genre op die locatie. Op die manier komen we echter terecht bij het algemene probleem van het indelen van de genres. De mogelijke genres beperken tot een vaste lijst, levert mooie resultaten bij de korte weergave van een locatie maar geeft weinig vrijheid aan de bandjes om hun genre te omschrijven. De bandjes zelf hun genre volledig laten ingeven als vrije tekst zorgt echter voor een immens aantal genres waarin maar zeer weinig groepjes zullen spelen. Dit levert een zeer uitgebreide korte inhoud bij een locatie en is niet bruikbaar in ons geval. Een uitgebreide hiërarchie van genres zou de perfecte oplossing zijn. Op die manier kan elk groepje zijn specifiek genre vastleggen en kunnen al deze subgenres toch tot enkele overzichtelijke hoofdgenres gegroepeerd worden. Als besluit kunnen we stellen dat de ervaringen met de Google Maps API positief waren. De API is eenvoudig in gebruik en levert mooie resultaten. Als men niet meer dan een eenvoudig, mooi en overzichtelijk kaartje met wat extra info wil toevoegen aan een website, is deze API zeker de juiste keuze! De moeilijkheden in ons geval kwamen vooral van de data zelf. Hoeveel markers moeten precies weergegeven worden op een kaartje? Hoe gaan we de genres overzichtelijk weergeven? Dat zijn de voornaamste vragen die moeten opgelost worden in de definitieve versie van onze applicatie. 3.3 YouTube Voor het aanspreken van YouTube is een vrij grote API beschikbaar onder Google Code [8]. Deze valt uiteen in twee grote delen: enerzijds kan je beschikbare data opvragen, anderzijds kan je nieuwe filmpjes toevoegen. Voor dit project is enkel de eerste functionaliteit van belang. In de API is documentatie en voorbeeldcode aanwezig voor het aanspreken van YouTube via Java,.NET, PHP, Python en Javascript. Waarschijnlijk verloopt het gebruik in elke taal even vlot en efficiënt; in ons project is het YouTube-gedeelte uitgewerkt in Javascript. Java en.net vielen uit de boot (het project diende te runnen op een beschikbare server), de stap naar Python leek ons te groot. De keuze tussen PHP en Javascript is louter een kwestie van voorkeur, beide talen waren een mogelijkheid. Omdat voor de Javascript-implementatie geen authentication key diende aangevraagd te worden en omdat geen server nodig is bij het ontwikkelen werd voor deze taal gekozen. Bij het implementeren van de YouTube-mashup werd vertrokken van een bestaand Javascript [9]. Bij het voorbeeld diende de gebruiker een zoekterm in een tekstvak in te geven, waarna de vijf eerste resultaten na het zoeken bij YouTube werden getoond. Na het klikken op het gewenste resultaat speelde het filmpje af. Er werd eveneens plaats voorzien voor het weergeven van gerelateerde filmpjes en filmpjes van dezelfde gebruiker. De code die in ons project is gebruikt is een aangepaste versie van deze implementatie. De gebruiker dient niet manueel een groepsnaam in te vullen, deze wordt automatisch meegegeven bij het openen van de betreffende groepspagina. Bovendien krijgt de gebruiker niet vijf maar slechts een resultaat te zien (het eerste resultaat dat YouTube teruggeeft) en dient hij niet meer te klikken om het filmpje te starten (het start automatisch). Tijdens deze implementatie kon ondervonden worden dat het vaak moeilijker is om bestaande code te wijzigen dan om zelf van nul te beginnen schrijven. Javascript liet ook niet echt debugging toe: ofwel werkte het, ofwel werkte het niet. Uiteindelijk heeft de volharding wel resultaat opgeleverd: de huidige applicatie doet wat ze moet doen. De zoekparameter wordt meegeleverd bij het laden van de pagina, en het overeenkomstige eerste zoekresultaat van YouTube wordt op de groepspagina weergegeven en afgespeeld. 3.4 Seeqpod De web services van SeeqPod kunnen voor verschillende doeleinden gebruikt worden, die allemaal min of meer met zoekfuncties te maken hebben. Wat voor dit project vooral nuttig

5 is, is de zoekfunctie die voor een gegeven artiest en nummer MP3's daarvan zoekt. Wat SeeqPod extra interessant maakt is de eenvoudige manier om de web service aan te spreken, nl. door een bepaalde URL in te geven. SeeqPod voert dan een zoekopdracht uit, en geeft op diezelfde URL een XML-bestand dat de resultaten van de zoekopdracht bevat. Bovendien zoekt SeeqPod op het web naar deze liedjes, en bvb. niet in een eigen database. Het leek voor dit project met onbekende groepjes dan ook een interessantere manier om MP3-bestanden te vinden. Uiteindelijk viel de werking van SeeqPod toch tegen. Het belangrijkste probleem om SeeqPod te gebruiken, is het feit dat een zoekopdracht zowel de naam van de artiest als een nummer nodig heeft. In de database waarvan de mash-up gebruik maakt, worden geen nummers opgeslagen. Veel locaties die SeeqPod vond, waren niet meer geldig (of zijn misschien nooit geldig geweest). SeeqPod bleek uiteindelijk toch geen antwoord te bieden op het probleem van de onbekende groepjes. Alleen van de bekendste artiesten werden liedjes gevonden, van de artiesten waar wij mee werkten vond SeeqPod helemaal geen liedjes. Als er extra tijd was geweest, had dit laatste probleem wel nog opgelost kunnen worden. M.b.v. last.fm kan er gezocht worden naar liedjes die lijken op een gegeven liedje, en dan konden deze liedjes gebruikt worden om naar te zoeken. Samenvattend kan dus gesteld worden dat Seeqpod veelbelovend was voor het gebruik in deze applicatie, maar iet of wat teleur bleek te stellen. 3.5 Flickr Een laatste multimediaal aspect van de voorstelling van de bandjes is het gebruik van foto s. Het lag voor de hand hiervoor de Flickr-diensten te gebruiken, daar Flickr de bekendste aanbieder van beeldmateriaal is en er bovendien een uitgebreide API ter beschikking wordt gesteld. De API kan aangesproken worden vanuit verschillende talen. Een eerste poging gebeurde in Java, omdat de syntax van die taal geen probleem meer vormt en er dus op de API zelf kon geconcentreerd worden. De uiteindelijke applicatie moest echter een webapplicatie worden. In die context was Java niet zo n goed idee, dus werd overgeschakeld op PHP. Het bleek uiteindelijk erg eenvoudig om de Flickr API op deze manier aan te spreken. Het is mogelijk zeer veel metadata op te vragen die bij een bepaalde Flickr-foto hoort. De eigenaar van de afbeelding, het aantal keer dat deze bekeken is, : alles lag binnen handbereik. Voor onze applicatie bleken veel van deze mogelijkheden overbodig. Op basis van een gegeven zoekterm (de bandnaam) wordt op Flickr gezocht naar afbeeldingen. De eerste vier resultaten die worden teruggegeven worden op de pagina van een groep weergegeven. Deze methode werkt vlot en goed, ware het niet dat Flickr met hetzelfde probleem worstelt als Seeqpod en YouTube: er is erg weinig data beschikbaar over onbekende groepjes, waardoor men soms tot vreemde resultaten komt 4. RESULTAAT Het resultaat van de mash-up is tegelijk positief en negatief. Technisch gezien werkt alles: het aanspreken van Google Maps, YouTube, Flickr en Seeqpod is gelukt, er is geen enkele feature die in het storyboard stond maar niet kon geïmplementeerd worden. Bovendien zou het niet zo'n grote moeite zijn om extra elementen in de mash-up op te nemen. Op dit moment zit er bijvoorbeeld geen component in uit de sociale sector (Facebook, LinkedIn, Netlog,...) omdat de implementatietijd ontbrak en deze functies niet prioritair waren. Het mag echter geen probleem vormen om bijvoorbeeld op basis van de groepsnaam een link naar een profiel te leggen. Aan de andere kant moet gesteld worden dat het resultaat van dit project het slachtoffer is geworden van zijn eigen uitgangspunt: het werken met onbekende groepjes. De gegevens van die groepjes werden op een centraal punt gevonden (de site van Poppunt) maar als je met die gegevens grote websites als YouTube en Flickr gaat aanspreken, krijg je vreemde resultaten. Het probleem is dat dergelijke groepjes te weinig naambekendheid hebben om het eerste zoekresultaat in YouTube of Flickr te worden - als ze al tussen de zoekresultaten voorkomen. Onbekende groepjes hebben daarenboven vaak namen waarin een bestaand woord voorkomt; het spreekt voor zich dat men dan vaak zoekresultaten krijgt die niet tot het groepje maar wel tot dat woord gerelateerd zijn. Aangezien bij YouTube het eerste filmpje en bij Flickr de eerste twee foto's worden weergegeven, krijg je zelden het filmpje of de foto's die bij het betreffende bandje horen te zien. Een oplossing voor dit probleem is niet zo eenvoudig. Als een persoon een zoekopdracht ingeeft in YouTube, kan hij/zij tussen de resultaten zelf het gewenste item selecteren. Een computer kan dit natuurlijk niet. Het is zeer moeilijk om de zoekresultaten op de een of andere manier te gaan filteren om zo tot het gewenste resultaat te komen. Een mogelijkheid die zou kunnen overwogen worden is het zoeken met zoveel mogelijk zoektermen (ipv enkel op de groepsnaam te zoeken) zodat het zoeken gerichter is en de kans op een juist resultaat groter. Op deze manier kan voorkomen worden dat er filmpjes worden weergegeven die niets met de band in kwestie te maken hebben. Wanneer er geen resultaat wordt gevonden, kan het aantal zoektermen verminderd worden. Dit alles implementeren is echter niet zo eenvoudig, en wegens tijdsgebrek is dit dan ook niet aanwezig in de oplossing. Met het oorspronkelijke idee in het achterhoofd (het aanbieden van een platform waar jonge bandjes zichzelf kunnen presenteren) is het eventueel mogelijk om aan de bandjes te vragen een video op YouTube up te loaden met de juiste naam (= de bandnaam), of foto's op Flickr te zetten. Dit vergroot de kans dat de resultaten van de mash-up op onze site verbeteren. Op die manier wordt de grens tussen een mash-up en het zelf hosten en aanbieden van de multimedia natuurlijk een stuk kleiner. 5. CO CLUSIE 5.1 Mash-up Het idee van een mash-up is een typisch gevolg van de huidige webcultuur: alles moet gedeeld en herbruikt worden. Dit heeft duidelijk voordelen, maar dit project heeft toch ook duidelijk de limieten van mash-ups aangetoond.

6 Wat zeer goed werkt, is het aanspreken van de bekende, degelijke API's (zoals die van GoogleMaps, YouTube,...) en deze integreren in de mash-up. Dit leidt tot een snel, eenvoudig en direct ook relatief mooi resultaat. Het nadeel is dat de ontwikkelaars heel afhankelijk zijn van de API's die ze gebruiken. Er worden wel veel API's aangeboden, maar niet altijd alles wat nodig is voor een applicatie. Daar komt nog bij dat heel wat API's, los van de bekende API's, nauwelijks of niet onderhouden worden, en dus mindere resultaten geven (vb. SeeqPod). Een mash-up is dus een handige manier om een applicatie te maken, als er gewerkt kan worden met algemene gegevens. Voor applicaties die snel gemaakt moeten worden en die er toch erg mooi moeten uitzien kan een mash-up zeker de efficiëntste oplossing zijn. Er moet dan wel rekening gehouden worden met de functionaliteit van de aparte componenten, er mogen m.a.w. geen wonderen worden verwacht qua extra functionaliteit. Het samenbrengen van de afzonderlijke componenten is een voordeel in die zin dat ze coherent kunnen gebruikt worden en op die manier eventueel een meerwaarde brengen. In projecten zoals het onze, waarbij de data niet zo algemeen verspreid is en waarbij er met onbekende onderwerpen gewerkt moet worden, is een mashup zeker moeilijker dan bvb. een RIA gemaakt in Flex. Een mashup zou wel een snellere oplossing geven, maar niet de beste, zoals dit project bewezen heeft. 5.2 Teamwork Met de werkpunten van het eerste project in het achterhoofd, is er aan dit project met een heel andere ingesteldheid begonnen. I.p.v. direct allemaal moeilijke elementen van de applicatie beginnen te maken, is er beslist om eerst een werkende mash-up te ontwikkelen, hoe eenvoudig ook. Pas als er een werkend resultaat was, kon er dan eventueel aan uitbreidingen gewerkt worden, afhankelijk van de overgebleven tijd. Uiteindelijk is er wel een beetje van deze strategie afgeweken, omdat anders de taakverdeling onmogelijk werd, maar het heeft wel tot een werkend resultaat geleid. Het enige wat achteraf anders aangepakt had kunnen worden, was de herwerking van het ontwerp. Met wat we nu bijgeleerd hebben over mash-ups, hadden we beter een ander uitgangspunt kunnen nemen dan onbekende Vlaamse bands. Er was immers geen enkele API die goed overweg kon met zo'n onbekende data. 6. REFERE TIES [1] De applicatie: BandStart (Mash-up implementatie) [2] Poppunt [3] Storyboard Mash-up Groep 5 op Wiki _-_Sessie_7 [4] MusicBrainz [5] MusicBrainz API [6] Google API [7] Google API Reference ence.html [8] YouTube API (Google Code) [9] Javascript-implementatie voor het aanspreken van YouTube API r.html [10] Tijdsbesteding Groep 5 op Wiki teding_groep5 APPE DIX A. APPE DIX: TIJDSBESTEDI G De volledige en gedetailleerde tijdsbesteding voor groep 5 kan gevonden worden op de wiki-pagina van de groep (doorklikken via Tijdsbesteding [10]. De tijdsbesteding zoals hieronder in de tabel aangegeven geldt enkel voor het derde deel van de cursus, de mash-upimplementatie. Iedereen is elke sessie aanwezig geweest, de kleine verschillen die opduiken zijn te wijten aan het later aankomen of vroeger vertrekken. Grosso modo kan gesteld worden dat iedereen evenveel binnen de sessies heeft gewerkt. Thomas en Benjamin hebben zich in het begin bezig gehouden met het zoeken naar bronnen die info bevatten over onbekende bandjes. Benjamin heeft zich daarna bezig gehouden met het implementeren van de screen scraper en heeft een helpende hand geboden bij de YouTube- en Seeqpod-integratie. Thomas heeft ervoor gezorgd dat foto s van Flickr konden worden gehaald. Maarten en Wouter hadden als eerste taak het zoeken naar geschikte API s. Maarten stortte zich vol overgave op Google Maps en implementeerde dit dan ook met succes. Hij hielp later ook bij het Seeqpod-gedeelte. Wouter heeft de YouTube-API onder handen genomen en zich daarna bezig gehouden met het ontwerp en de lay-out van de website. Aan het verslag heeft iedereen zijn steentje bijgedragen, waarbij dat van Wouter het zwaarste woog. aam Binnen sessie Buiten sessie Maarten 14.5u 9u Thomas 13u 9.5u Benjamin 14.5u 10.5u Wouter 15u 11.5u