De introductie van de Google Maps API in 2005 wordt gezien als het begin van het Mashup en API tijdperk. Nu 6 jaar later, zijn APIs ‘serious business’ geworden en zijn ze niet meer weg te denken. Maar APIs kunnen voor een bedrijf ook erg kostbaar zijn. Anderen profiteren van de diensten die een bedrijf aanbiedt, in veel gevallen zonder daar iets voor te hoeven betalen. Langzamerhand worden er steeds meer betaalde APIs aangeboden, vaak met een beperkte, gratis variant (gelimiteerd of met reclame).

Eerder dit jaar schrapte Google al een hele serie APIs en maakte van de gratis Translate API een volledig betaalde variant. En nu is het dus de beurt aan de Google Maps API.

Er was overigens altijd al een betaalde variant van de Google Maps API, de Google Maps API Premier. Deze is bedoeld voor bedrijven die support willen, geen advertenties, meer geocoding of de kaarten intern willen gebruiken.

Google legt in de FAQ uit, welke limieten er geïntroduceerd worden. De API blijft gratis tot 25.000 ‘Map loads’ per dag voor de normale kaarten en tot 2.500 ‘Map loads’ per dag voor aangepaste kaarten. Daarboven moet er vanaf begin 2012 betaald worden. Voor de normale kaarten zal dit $4 per 1000 ‘Map loads’ worden en voor de aangepaste kaarten $4 of $8 per 1000 ‘Map loads’. Dit geldt zowel voor de JavaScript APIs als voor de Static Maps API. Opvallend is dat de oude JavaScript API (V2) ook nog ondersteund wordt, maar dat hiervoor $10 per 1000 ‘Map loads’ betaald moet worden.

Er wordt in de FAQ ook precies uitgelegd wat een ‘Map load‘ inhoudt. Het gaat hierom het laden van de Maps JavaScript door een website of applicatie of het genereren van een kaart afbeelding m.b.v. de Static API.

De limieten zijn overigens niet hard. Als een website over de limiet heen gaat, wordt niet direct de de kaart uitgeschakeld, maar bij herhaaldelijk overschrijden van de limiet, kan er een waarschuwing worden getoond op de kaart en zal iemand van Google contact opnemen.

Is het nu erg dat er voor de Maps API betaald moet gaan worden? De eerste reacties zijn overwegend positief. Natuurlijk is het jammer als je als ontwikkelaar moet gaan betalen voor iets dat voorheen gratis was, maar beter een betaalde versie dan helemaal geen Maps API meer.

Of dit nu zal betekent dat veel ontwikkelaars overgaan stappen op alternatieven, zoals bijv OpenStreetMap, zal de tijd moeten leren.

Overigens gelden de bovenstaande beperkingen alleen voor commerciële websites. Nonprofit websites kunnen zelfs nog in aanmerking komen voor opheffing van bepaalde limieten (bijv het uitschakelen van advertenties). Informatie hierover is te vinden op de Google Earth Outreach website.

Het aantal organisaties dat een API aanbiedt is de afgelopen jaren enorm toegenomen. Op de website Programmableweb.com staan op dit moment 3891 API’s geregistreerd. In dit overzicht overzicht staan een kleine 40 Nederlandse API’s (overzicht is niet volledig, aanvullingen zijn welkom!).

Wat zijn op dit moment de trends in de (wondere) wereld van de API’s? Hieronder een overzicht:

json-only

Veel API’s bieden meerdere output formaten aan, meestal XML en JSON. Ontwikkelaars zijn gek op JSON. JSON is lekker simpel, niet te veel overhead, etc. Dit is de reden waarom veel API’s tegenwoordig JSON-only zijn. Vooral veel nieuwe API’s bieden alleen nog JSON aan als output formaat. Op Programmable Web is 20% van de nieuwe API’s (in 2011) al JSON-only. Maar ook steeds meer bestaande API’s stappen over op JSON-only.

Meta API’s

Als je een applicatie of mashup ontwikkelt, waarbij je alle informatie wilt gebruiken die over een bepaalde (geografische) locatie te vinden is, moet je meerdere API’s raadplegen, bijvoorbeeld Wikipedia voor de algemene informatie, Foursquare voor de checkins en tips, Twitter voor de tweets over de locatie, etc.

Het koppelen van de verschillende informatie bronnen kan soms complex zijn. De naam van de locatie is misschien net iets anders in Wikipedia dan in Foursquare en er bestaat al helemaal geen unieke id.

Meta API’s proberen een einde te maken aan dit probleem, door een overkoepelende API aan te bieden, of door een vertaalslag aan te bieden voor de id’s van de verschillende API’s. Een goed voorbeeld hiervan is de Uberblic Doppleganger API.

Realtime/Push API’s

Om een API te raadplegen moet meestal een verzoek naar een server gestuurd worden, waarna de resultaten binnengehaald kunnen worden. In deze tijd van realtime updates is dat vaak niet meer genoeg. Daarom worden er steeds meer push of ook wel realtime API’s aangeboden. Bij een push API worden nieuwe resultaten automatisch naar een applicatie gestuurd.

Bekend voorbeeld van deze push API is de streaming API van Twitter. Hierbij kan je als ontwikkelaar aangeven welke woorden of gebruikers je wilt volgen en komen de nieuwe tweets als een continue stroom van informatie naar je toe.

Ander recent voorbeeld: gisteren lanceerde Foursquare twee realtime API’s als beta. Een ontwikkelaar kan hier notificaties ontvangen als een gebruiker ergens incheckt of als er iemand op een bepaalde locatie incheckt.

Dit zijn drie trends die, volgens mij, op dit moment belangrijk zijn, heb ik nog iets gemist?

Er is in een week tijd al erg veel over dit apparaat gezegd en geschreven, de iPhoneclub heeft een mooi overzicht.

Flash

Er is veel kritiek, met name op het ontbreken van de camera (of zit deze er toch in?) en het ontbreken van Flash support. Zelfs de CTO van Adobe bemoeit zich met deze discussie.

Ik denk zelf dat ‘t ontbreken van Flash geen groot probleem is. Flash wordt over het algemeen gebruikt voor video en interactieve, ‘multimediale’ toepassingen. Steeds meer videosites zijn aan het experimenten met HTML5 video. Dit is nog niet ideaal en er is nog een lange weg te gaan voordat HTML5 video Flash helemaal kan vervangen, maar op de iPhone werkt dit tot nu toe prima, dus waarom op de iPad niet?

Daarnaast zijn er volgens mij weinig interactieve toepassingen die echt Flash nodig hebben, de meeste kunnen m.b.v. HTML5, JavaScript en CSS3 prima ontwikkeld worden.

HTML5, JavaScript en CSS3

Natuurlijk zitten er nog wel nadelen aan het gebruik van deze drie technieken. HTML5 en CSS3 zijn nog niet ‘af’. De specificaties hiervan zijn nog volop in ontwikkeling en er kunnen dus nog wijzigingen plaats vinden.

Een ander nadeel is dat nog niet alle browers deze technieken volledig ondersteunen, met name Internet Explorer loopt op dit gebied achter op de andere moderne browsers. Maar ook Microsoft is sinds enige tijd betrokken bij de ontwikkeling van HTML5, dus er is hoop.

Laatste nadeel is dat HTML5, JavaScript en CSS een andere soort ontwikkelaar vereisen dan Flash. De meeste Flash ontwikkelaars zijn gewend om met de grafische Flashontwikkelomgeving te werken. Voor HTML5, JavaScript en CSS zijn deze er bij mijn weten nog niet. Tenminste niet met hetzelfde gemak als Flash. Maar ik heb zo’n gevoel dat deze tools niet lang op zich laten wachten en het zou best kunnen dat Adobe daar een belangrijke rol in gaat spelen.

Met name door de goede ondersteuning van HTML5, JavaScript en CSS3 in de mobile Safari (Webkit) lijkt de iPad me een interessant nieuw apparaat om voor te ontwikkelen.

ePub

Ik zit zelf alleen nog met een vraag. Hoe staat het met de ondersteuning van ebook standaard ePub? Apple heeft aangekondigd dat de iPad ePub ondersteund, maar er zijn nog geen details bekend.

Er is op dit moment nog geen audio of video mogelijkheid in de ePub standaard, maar er zijn wel manieren om toch audio en video op te nemen in een ePub document. Er zijn tot nu toe alleen weinig devices die dit ondersteunen.

Het zou toch mooi zijn als boeken, maar met name magazines en kranten gebruik zouden kunnen maken van audio en video zonder dat er voor iedere publicatie een aparte App ontwikkeld moet worden.

Proof of Concepts

Alhoewel deze Apps misschien in eerste instantie wel nodig zijn om te bepalen wat voor unieke mogelijkheden het apparaat biedt voor tijdschriften en kranten. Want als maar een klein stukje van deze twee ‘proof of concepts’ mogelijk worden gemaakt met de iPad, dan komen er mooie tijden aan voor tijdschriften en kranten die met hun tijd mee willen gaan.

Mag+ from Bonnier on Vimeo.

De meeste berichten gaan met name in op de concurrentie die Google in de ogen van veel mensen nu aangaat met Windows van Microsoft. Dit zal ongetwijfeld zo zijn, alhoewel ik niet verwacht dat veel Windows gebruikers direct zullen overstappen op Chrome OS. En daar zijn velen ‘t over eens.
Het schijnt trouwens dat CEO Eric Schmidt al 6 jaar bezig is om Sergey Brin en Larry Page ervan te weerhouden een OS te ontwikkelen. Schmidt vond dat Google nog niet klaar was voor de OS concurrentie strijd, nu dus blijkbaar wel

Voor mij als techneut is het veel interessanter om te kijken hoe dit OS opgebouwd zal zijn en ik denk dat daar al meer over bekend is dan je in eerste instantie zou zeggen.

Google Chrome OS doet denken aan de Netwerk Computer of Thin Client, die verschillende partijen in het verleden al op de markt hebben proberen te brengen. Oa Oracle en Sun hebben in ‘t verleden (rond 1996) systemen op de markt gebracht waarbij de computer beperkte capaciteiten heeft en de applicaties op de server draaien. Chrome OS is in eerste instantie bedoeld voor NetBooks waarbij de capaciteit ook minder is dan een volledige laptop/deskop computer.

Ook browser ontwikkelaar Netscape heeft in het verleden de browser al gepresenteerd als het nieuwe OS. Helaas is hiervan weinig meer terug te vinden. Ik kan me nog hele mooie whitepapers over dit onderwerp herinneren.

Negen maanden geleden heeft Google de Chrome browser geïntroduceerd. Sindsdien zijn er een aantal ontwikkelingen geweest die volgens mij allemaal een relatie met het Chrome OS (kunnen) hebben.

HTML5

Google zet zwaar in op HTML5. Deze nieuwe HTML specificatie is nog niet afgerond, maar wordt nu al ondersteund door verschillende browser fabrikanten waaronder dus door Google met Chrome. Google heeft ook al verschillende applicaties ontwikkeld die gebruik maken van HTML5 features, zoals de mobiele versies van Gmail en Calendar.

Tijdens Google I/O, de developers conferentie van Google bleek dat Google aan nog veel meer HTML5 projecten werkt, zoals bijv een Flash vrije Youtube.

Voordelen van HTML5 zijn oa offline mogelijkheden, lokale opslag, video en audio zonder plugin afspelen, etc. Deze mogelijkheden zijn goed te gebruiken in een Operating System.

JavaScript

De Chrome browser maakt gebruikt van de opensource Webkit Browser Engine, behalve voor de JavaScript parsing. Daarvoor heeft Google de V8 JavaScript Engine ontwikkeld. Deze JavaScript Engine is erg snel en dat is natuurlijk onmisbaar als je volledige applicaties ontwikkeld die gebruik maken van deze programmeertaal.

Native Client SDK

Een van de belangrijkste vragen die gesteld zijn na de bekendmaking van Google Chrome OS is of het OS ook native applicaties gaat ondersteunen. De kans is natuurlijk klein dat er bijvoorbeeld Windows programma’s op gedraaid kunnen worden. Maar afgelopen december heeft Google de Native Client gelanceerd. Dit is een research project waarbij onderzocht wordt hoe native x86 code binnen webapps gebruikt kan worden, met behoud van browser neutraliteit.

Deze technologie kan bijvoorbeeld gebruikt worden om vanuit de browser de hardware direct aan te spreken. Voordeel hiervan is dat er snelheidswinst in allerlei berekeningen behaald kan worden. Ook voor de ontwikkeling van games kan het belangrijk zijn om de hardware direct aan te spreken.

O3D

Een andere vraag is hoe zit het met graphics? Natuurlijk heeft HTML5 canvas en SVG ondersteuning, maar dat maakt geen gebruik van specifieke grafische kaarten. Ook hier heeft Google al ‘iets op de plank’ liggen, nl O3D. Dit is een API om interactieve 3D applicaties in de browser te ontwikkelen.

Wave

Google Wave is een nieuwe manier van communiceren en samenwerken op het internet. Hoe dit precies in het Chrome OS verhaal past, weet ik niet, maar ik denk wel dat we dit terug gaan zien in het OS. Google Wave is ook nog niet officieel gereleased, maar er is al wel een uitgebreide API.

Ik ben zelf erg benieuwd hoe applicaties voor het OS ontwikkeld gaan worden. Maakt Google alleen gebruik van de bovenstaande technieken, waardoor de applicaties inderdaad ook op andere browser gebruikt kunnen worden, zoals ze zelf zeggen. Of komt er toch ook een soort native SDK waarmee op een soort Palm WebOS achtige manier applicaties ontwikkeld zullen worden?
De tijd zal het leren, want Google gaat het OS later dit jaar beschikbaar maken als opensource en dan in de 2e helft van 2010 zal het beschikbaar komen voor consumenten.

Maar een ding is duidelijk, voor webdevelopers zoals ik, zijn het interessante tijden

Update: Ik ben benieuwd naar jullie reactie en ideeën hierover. Wat denken jullie? Kunnen jullie je een beetje vinden in m’n gedachtengang? Of sla ik de plank volledig mis?

Overigens is dit niet nieuw, in 2007 schreef ik al een artikel over de bronnen waar Google haar informatie voor Google Maps vandaan haalt. Dat er nu ophef over ontstaan is, wordt veroorzaakt doordat er ‘privé-informatie’ van BN’ers naar buiten is gekomen. Steeds meer zzp’ers zijn verplicht om zich in te schrijven in het Handelsregister, dus ook bekende zzp’ers.

De ophef heeft geleid tot kamervragen. Vorige week werd bekend dat de ondernemer/zzp’er meer zeggenschap krijgt over de gegevens die opgenomen zijn in het Handelsregister.

Meer zeggenschap is natuurlijk altijd goed, maar voor veel ondernemers is het gevonden worden op Google Maps erg belangrijk. Google gebruikt de informatie van Google Maps tegenwoordig ook in de ‘normale’ zoekopdrachten. Zodra er een plaatsnaam in de zoekopdracht voorkomt, wordt ook de lokale informatie uit Google Maps gebruikt.

Een onbekende mogelijkheid van Google Maps is het Lokale Bedrijvencentrum. Met dit bedrijvencentrum kan je de informatie, zoals deze op Google Maps verschijnt, wijzigen en zelfs uitbreiden (extra omschrijving, werkterrein, url, etc). Ook hier schreef ik al eerder over, maar deze informatie is verouderd. Ik zal binnenkort een vernieuwde versie van dit artikel publiceren.

Mocht je in de tussentijd geïnteresseerd zijn om de informatie zoals deze in Google Maps over je bedrijf vermeld staat, aan te passen, dan biedt Google uitgebreide help informatie.

Kom je er niet uit of wil je je er niet in verdiepen, neem dan contact met mij op (of via @gvenk).

Staatssecretaris Frank Heemskerk heeft de dag voor Prinsjesdag 2007 een actieplan naar de Tweede Kamer gestuurd. Dit actieplan, “Nederland open in verbinding”, bevat een groot aantal actiepunten voor het gebruik van Open Source Software en Open Standaarden binnen de (semi-) publieke sector.
De nadruk van de actiepunten ligt op het gebruik van Open Standaarden, deze worden verplicht gesteld, mits niet een van de uitzonderingscriteria geldt (zie de pdf blz 10 voor deze criteria).
Over Open Source Software wordt er in het document gezegd dat er een implementatie strategie ontwikkeld moet zijn voor de aanbesteding en inkoop en het gebruik, het moet een ‘eerlijke’ kans krijgen.
Het document gaat uit van het zogenaamde ‘pas toe of leg uit strategie’. Als er afgeweken wordt van het gebruik van Open Source Software en Open Standaarden moet dat uitgelegd worden.

Ik ben een groot voorstander van het gebruik van Open Standaarden en Open Source door overheden en andere organisaties in de publieke sector, dus ik juich zo’n actieplan van harte toe. Maar wat mij tegenvalt in het actieplan is dat er met geen woord gerept wordt over het beschikbaar stellen van publieke data op een open manier.

Publieke data

De (semi-)overheid produceert en verzamelt veel data. Een (groot) deel van deze data is interessant voor het publiek. Denk hier bij bijvoorbeeld aan geografische data (straten, publieke gebouwen, etc), maar ook informatie van de onderwijs inspectie over scholen, politie statistieken, vul zelf maar aan.

Op dit moment wordt er verschillend met deze data omgegaan. Sommige data wordt verkocht aan commerciële partijen (dit geldt bijvoorbeeld voor de geogratische data). Andere data is doorzoekbaar via een website, maar de informatie kan niet zo maar verder gebruikt worden (bijvoorbeeld de rapporten van de onderwijs inspectie). En zo langzamerhand verschijnt er ook data die ontsloten wordt via een webservice, zodat je daarmee nieuwe Mashups kunt ontwikkelen (bijvoorbeeld de Nieuwe Kaart van Nederland).

Waarom beschikbaar stellen?

Waarom zou de overheid deze data vrij beschikbaar moeten maken? Want doordat ze nu deze data soms verkopen aan commerciële partijen krijgen ze er geld voor en dat is weer voordelig voor ons als belasting betalers.

Maar toch denk ik (en gelukkig velen met mij) dat het goed is als deze data vrij beschikbaar komt. De burgers, consumenten organisaties en journalisten zouden op deze manier meer inzicht krijgen in het politieke proces. Waar gaat het geld naar toe, wat wordt er allemaal gedaan, maar ook waar kan je terecht met je vragen en opmerkingen over specifieke onderwerpen.

Verder zal de toegankelijkheid en doorzoekbaarheid van overheidsdata toenemen als de data beschikbaar komt. Zoekmachines zullen deze data (beter) kunnen indexeren, maar er kunnen ook specifieke zoekmachines of indexen ontwikkeld worden voor de publieke data.

En, wat ik zelf ook erg interessant vind, alle data kan gecombineerd worden in Mashups, zodat er weer nieuwe informatie bronnen ontstaan. Toepassingen waar de overheid zelf niets aan heeft en dus nu nooit zal ontwikkelen, kunnen door anderen ontwikkeld worden. Data kan worden verrijkt, gevisualiseerd, etc. Er zullen nieuwe startups ontstaan die hiermee aan de slag gaan en dat is weer goed voor de economie.

Voorop lopen door vrije data

Afgelopen woensdag was er een debat in de Tweede Kamer over het eerder genoemde actieplan. Voorafgaand aan dit debat heeft OpenStreetMap Nederland een rapport gepubliceerd Voorop lopen door vrije data. Het rapport stelt dat het vrijgeven van overheidsdata de doelstellingen van het actieplan ‘Nederland in open verbinding’ bevorderd:

• Open standaarden bevorderen de interoperabiliteit. Vrije data kan dit een extra impuls geven. Vrije data is niet alleen in principe uitwisselbaar, vrije data kan samengevoegd worden tot een enkele dataset.
• Open standaarden en open source verminderen van de afhankelijkheid van leveranciers. Vrije data kan hieraan een extra bijdrage leveren op het vlak van de inhoud. Tevens kan de beschikbaarheid van vrije data de hoeveelheid leveranciers van software vergroten, zoals hierboven aangetoond.
• Open source bevordert een gelijk speelveld op de software­markt en bevordert voorts de innovatie en de economie. Waar de beschikbaarheid van data een voorwaarde is voor de ontwikkeling van software, bevordert vrije data een gelijk speelveld, de innovatie en de economie.

Debat

Het was de bedoeling dat dit artikel voor het debat van woensdag online zou komen, maar doordat mijn internetverbinding het niet deed is dat niet gelukt. Ik zou nog schrijven dat ik me afvroeg of het rapport van OpenStreetMap wel veel aandacht zou krijgen, aangezien er vooraf voornamelijk aandacht was voor de discussie over ODF en OOXML en de rol van Microsoft in het geheel..

De Tweede Kamer is akkoord gegaan met het plan, maar ik heb tot nu toe geen verslag kunnen vinden, dus ik weet niet of er ook gesproken is over vrije data. Van alles wat ik er tot nu toe over gelezen heb, krijg ik de indruk dat dit niet het geval is. Een gemiste kans dus, tijd voor een vervolg actieplan!

Vandaag licht Techcrunch een tipje van de sluier op, Google lanceert morgen OpenSocial.

OpenSocial (link werkt vanaf donderdag) is geen nieuw sociaal netwerk, maar het is een set van APIs waarmee applicaties ontwikkeld kunnen worden, die met alle sociale networken kunnen samen werken, zolang deze de OpenSocial APIs ondersteunen.

Wat?

Wat is OpenSocial nu precies? Volgens Techcrunch bestaat het uit 3 verschillende APIs, waarmee de belangrijkste onderdelen van een sociaal netwerk ontsloten worden:

• Profiel informatie (user data)
• Vrienden informatie (social graph)
• Activiteiten (wat gebeurt er binnen het netwerk)

Het is geen universele API die alles van een sociaal netwerk probeert af te handelen. De nadruk ligt op de gemeenschappelijke, generieke data. Voor de specialistische informatie kan een sociaal netwerk een eigen API aanbieden.

In tegenstelling tot Facebook, maakt OpenSocial geen gebruik van een eigen markup taal, maar gewoon van Javascript en HTML. Dit is voor ontwikkelaars erg goed nieuws, er hoeft geen nieuwe taal geleerd te worden en overal waar Javascript en HTML werkt, kunnen applicaties, gebaseerd op de OpenSocial API aangeboden worden.

OpenSocial legt Hosts (=deelnemende sociale netwerken) geen verplichtingen op, ze kunnen hun eigen regels bepalen waaronder ze de API willen aanbieden. Dus geen ingewikkelde TOS, geen verplichting om gebruik te maken van Google diensten (behalve de API zelf natuurlijk), geen Ads, etc. Ik hoop wel dat er in de API vastgelegd is dat de gebruiker altijd de regie houdt wat er met zijn/haar informatie gebeurt.

Het is op dit moment nog onbekend of OpenSocial ook gebruik zal maken van bestaande open standaarden als OpenID en OAuth, maar ik kan me bijna niet voorstellen dat ze hier aan voorbij zullen gaan.

Voor wie?

OpenSocial is interessant voor meerdere partijen. Als eerste natuurlijk de sociale netwerken zelf. Zij hoeven voor de standaard informatie geen eigen API meer te bedenken, maar kunnen de OpenSocial API implementeren. Ze kunnen zich dus richten op een API voor hun specifieke informatie (als ze daarvoor een API willen aanbieden), dat wat hen onderscheidend maakt van andere netwerken.
Daarnaast kunnen zij diensten aanbieden waardoor gebruikers toegang krijgen tot hun eigen informatie binnen andere sociale netwerken.

Voor bedrijven die applicaties voor sociale netwerken ontwikkelen, houdt de aankondiging in dat ze minder kosten hoeven te maken om meerdere netwerken te kunnen ondersteunen. Verder kunnen ze, als een gebruiker daar toestemming voor geeft, de beschikking krijgen over gebruikersdata uit de verschillende netwerken.

Een ontwikkelaar hoeft niet voor ieder sociaal netwerk een nieuwe API te leren, of zelfs een nieuwe taal, zoals dat op dit moment voor Facebook het geval is.

En de gebruiker? Wat schiet de gebruiker hiermee op? Met de OpenSocial API zou het mogelijk kunnen worden om vrienden uit te wisselen tussen de verschillende netwerk sites. Dus niet iedere keer iedereen weer opnieuw toevoegen, maar gewoon importeren. Ook andere informatie uitwisselen (profiel) wordt hiermee eenvoudiger. Daarnaast zullen er ook overkoepelende sites komen, waarbij een gebruiker z’n sociale netwerken beter kan managen.

Verder verwacht ik veel toepassingen en combinaties tussen netwerken die we nu nog niet kunnen bedenken. Er komt een interessante tijd aan

Deelnemende partijen

Er is al een interessante lijst van deelnemers:

Hosts are the participating social networks, and include Orkut, Salesforce, LinkedIn, Ning, Hi5, Plaxo, Friendster, Viadeo and Oracle.

Developers include Flixster, iLike, RockYou and Slide.

Waarom Oracle bij de sociale netwerken genoemd wordt is mij onbekend.

Interessant detail over de deelnemende developers is dat er een aantal partijen bij staan die (ook) Facebook applicaties ontwikkelen.

Nederland

Ik ben erg benieuwd of Nederlandse netwerken ook inspringen op OpenSocial. Van Hyves is al een tijdje bekend dat ze met een API bezig zijn. Het zou natuurlijk fantastisch zijn, als ze deze API gaan ondersteunen.

Update: Zojuist maakt Yme Bosma bekend dat Hyves ook OpenSocial gaat. Dat is erg goed nieuws! Binnenkort volgt meer informatie.

Welke netwerken zijn er nog meer in Nederland waarvoor deze APIs interessant zouden kunnen zijn? Ekudos, 3VOOR12 (toch ook steeds meer een sociaal netwerk)….wie vult aan?

Strijd

Na de bekendmaking dat Microsoft investeert in Facebook, heeft Google hiermee de strijd op het sociale netwerken toneel op scherp gezet. Veel gehoorde klacht over Facebook is dat ze niet open genoeg zijn, Google biedt netwerken nu de mogelijkheid om helemaal open te gaan, maar geen van de deelnemende netwerken zijn groot genoeg om de strijd aan te gaan met Facebook. Of zouden ze door OpenSocial samen sterker en groter kunnen zijn als Facebook?

En wat gaat Yahoo doen? En Microsoft? En Myspace? De tijd zal het leren, maar dat het een interessante tijd gaat worden, staat vast

Update: informatie over Hyves toegevoegd.

Analyse

Als je als gebruiker foto’s op Flickr plaatst heb je een aantal mogelijkheden om jezelf te beschermen tegen ongeautoriseerd gebruik van je foto’s.

Je kan kiezen uit verschillende licentie vormen voor de foto’s, uiteenlopend van All Rights Reserved tot Creative Commons Naamsvermelding. Hiermee geef je aan wat anderen met je foto’s mogen doen.

Daarnaast heb je een aantal configuratie mogelijkheden, zoals wie je foto’s mogen downloaden, printen, bloggen, etc. Belangrijke optie is de “Hide your photos from public searches” optie. Hiermee geef je aan of jouw foto’s in de resultaten mogen verschijnen van zoekopdrachten via de API.

Wat is het probleem waarover de discussie nu gevoerd wordt? Een Flickr gebruiker heeft zijn foto’s als “All Rights Reserved” staan en de “Hide your photos from public searches” optie aan staan. Toch kwam hij foto’s van zichzelf tegen op een andere site dan Flickr, namelijk op elsewhere.adactio.com. Deze site beeldt de foto’s af van Jeremy Keith en zijn contacten bij Flickr. Als je op een contact klikt, zie je ook de foto’s van diens contacten, etc.

De site maakt gebruik van de mogelijkheid om m.b.v. de Flickr API rechtstreeks de foto’s van een gebruiker op te kunnen halen. Deze mogelijkheid werkt voor iedere gebruiker, ook al zijn diens foto’s ARR en beschermd tegen zoeken via de API. Overigens worden de foto’s op elsewhere.adactio.com afgebeeld onder vermelding van de eigenaar van de foto’s.

Austen Haines, die de discussie op Flickr gestart is, heeft een aantal bezwaren tegen het gebruik van zijn foto’s. De eerste is dat er geen toestemming gevraagd is voor het gebruik van zijn foto’s en de tweede is als er geen toestemming is, dan zou er nog sprake kunnen zijn van Fair Use, maar de foto’s worden niet alleen in thumbnail formaat afgebeeld.

Wie is de schuldige?

Een belangrijke vraag in de hele discussie is: wie is de schuldige? Is dat Flickr voor het feit dat ARR foto’s toch in de API verschijnen? Of is dat de ontwikkelaar van de mashup omdat deze geen toestemming heeft gevraagd aan de eigenaren van de foto’s?

In veel reacties in deze discussie wordt de verantwoordelijkheid bij de ontwikkelaar gelegd. Hij had eerst toestemming moeten vragen voordat hij foto’s gebruikte. Jeremy geeft aan dat er veel meer applicaties zijn, waarbij je zonder dat je hoeft in te loggen foto’s van een specifieke Flickr gebruiker kan opvragen. Daarnaast laat de mashup de foto’s zien, met vermelding van de eigenaar en worden er geen foto’s opgeslagen.

Er is ook nog een tweede discussie ontstaan, waarbij de verantwoordelijkheid meer bij Flickr gelegd wordt. Flickr zou niet moeten toestaan dat zo maar alle foto’s via de API opgevraagd kunnen worden. Bij ARR foto’s zouden bijvoorbeeld alleen thumbnails opgevraagd moeten kunnen worden. Voor grotere afbeeldingen zou de eigenaar van de foto’s moeten inloggen, zodat diensten als Moo nog wel mogelijk blijven, maar dan alleen voor de eigenaar van de ARR foto’s.

Austen Haines zou al minder problemen met elsewhere.adactio.com als deze alleen maar gebruik zou maken van thumbnails, omdat dat eventueel onder ‘Fair Use’ zou vallen.

Er zijn mensen in de hele discussie die aangeven dat het gevolg van foto’s op Flickr plaatsen (of überhaupt foto’s op internet plaatsen) nu eenmaal is dat mensen met je foto’s aan de haal kunnen gaan. Natuurlijk is dat waar, maar daarom hoef je er nog niet mee akkoord te gaan. Je hebt bij Flickr de mogelijkheid om foto’s ARR aan te bieden en dan moet dat ook geaccepteerd worden.

Aan de andere kant, Flickr biedt de mogelijkheid aan om rechtstreeks foto’s op te vragen van een gebruiker, moet je dan als Mashup developer deze gebruiker ook nog om toestemming gaan vragen?

Er zijn ook mensen die, zolang hun naam bij de foto’s staat, het prima vinden om op deze manier extra aandacht te krijgen. Deze mensen zouden eigenlijk geen gebruik moeten maken van de ARR optie, maar zouden de “Naamsvermelding-Niet-commercieel-Geen Afgeleide werken” licentie moeten gebruiken. Deze licentie staat het alleen toe dat je de foto mag gebruiken, zolang je de bron vermeldt. Je mag de foto’s niet commercieel gebruiken en je mag ze ook niet bewerken.

Ik ben wel benieuwd naar jullie meningen. Is het de verantwoordelijkheid van Flickr of van de Mashup developer om te checken of een foto wel of niet gebruikt mag worden? En zou jij het een probleem vinden als je foto’s op een site als elsewhere.adactio.com zouden verschijnen?

Oplossing

Flickr is volgens een reactie van Paul Hammond aan het nadenken over een oplossing. Ze vinden het nog niet zo eenvoudig aangezien er veel applicaties en Mashups zijn die gebruik maken van de Flickr API. Ze willen voorkomen dat deze applicaties niet meer werken door een aanpassing in de API.

Ik denk dat Flickr de gebruikers een extra optie moet gaan geven waarmee ze of hun foto’s helemaal kunnen uit sluiten van ongeauthoriseerd gebruik via de API of toestemming kunnen geven om thumbnails te gebruiken.

Daarnaast zou de standaard licentie de Naamsvermelding-Niet-commercieel-Geen Afgeleide werken moeten worden. Gebruikers die dit absoluut niet willen kunnen dit wijzigen, maar ik denk dat veel mensen er helemaal geen probleem mee hebben om foto’s onder deze licentie aan te bieden. Hierdoor kunnen Mashups toch gebruik blijven maken van de mooie bron die Flickr natuurlijk is.

Een aanpassing van de API is overigens geen garantie dat je foto’s niet alsnog ergens opduiken door bijvoorbeeld rss feeds of rechtstreeks linken naar een afbeelding.

Toekomst

In een reactie op de hele discussie heeft Jeremy nog een post geschreven met als titel Lock up your data. Hij schrijft hierin oa:

As sites like Flickr and Last.fm move from a user base of early adopters into the mainstream, this issue becomes more important. What isn’t clear is how the moral responsibility should be distributed. Should Flickr provide clearer rules for API use? Should Google index less? Should the people publishing photos take more care in choosing when to mark photos as public and when to mark photos as private? Should developers (like myself) be more cautious in what we allow our applications to do with the API?

Ik hoop dat we hier met z’n allen in alle redelijkheid een goede oplossing voor kunnen verzinnen. Het is absoluut niet wenselijk dat je als gebruiker of als Mashup ontwikkelaar te maken krijgt met allerlei ingewikkelde voorwaarden of overeenkomsten, voordat je je informatie ergens mag plaatsen of voordat je de informatie via een API mag gebruiken.

Ik hoop dat steeds meer mensen gaan inzien dat er met delen en gebruiken hele mooie toepassingen kunnen ontstaan, die waardevol zijn voor de ontwikkeling van onze cultuur.

Er zijn meer mogelijkheden dan gevaren!

Toch mis ik nog een aantal dingen. Je kan de video van Uitzendinggemist niet op je eigen site gebruiken, dus geen artikel schrijven over een bepaalde uitzending en deze direct bij het artikel plaatsen. Je kan niet eenvoudig linken naar een specifiek stukje in een uitzending. En als laatste, er is maar 1 RSS feed voor heel Uitzendinggemist. Het moet eenvoudig zijn om ook RSS feeds toe te voegen voor de verschillende onderdelen van de site (zender, genre, omroep of zelfs specifiek programma).

Ik kan wel een aantal redenen bedenken waarom je video van Uitzendinggemist niet mag ‘herbruiken’ (rechten, in eigen hand willen houden, hogere eisen aan de technische infrastructuur, etc), maar in het huidige Web-2.0 tijdperk kan dat eigenlijk niet meer. Inhoud moet herbruikt kunnen worden, zeker eigen materiaal van de Publieke Omroep. Een publieke organisatie wil met haar uitzendingen oa nieuws brengen, een bijdrage leveren aan politieke discussies, maar ook bijdragen aan de cultuur van Nederland. Hoe kan een organisatie dit nu beter doen, dan toe te staan dat deze uitzendingen ook op andere sites geplaatst mogen worden? Hierdoor wordt het bereik groter en worden er eventueel meer kanten belicht dan op de tv vaak mogelijk is.

Als de Publieke Omroep een mooie embedded player zou ontwikkelen, zouden de video’s herkenbaar blijven als materiaal van de Publieke Omroep.

Youtube

De meest bekende manier om video’s te delen en te herbruiken op andere websites is natuurlijk Youtube. Bij iedere video op Youtube staat een stukje html waarmee je de betreffende video op je eigen site kan plaatsen. Helaas is het nog niet mogelijk om een specifiek stuk uit een Youtube-video op je site te plaatsen, zoals wel mogelijk is met Google Video. Maar ik verwacht dat dit binnen afzienbare tijd ook mogelijk wordt voor Youtube videos’.

Er zijn een aantal Publieke Omroep kanalen op Youtube. Helaas is er nergens een compleet overzicht te zien, dus ik weet niet of ik nog kanalen gemist heb. Op Google Video staan wel een aantal officiële Nederlandse Youtube kanalen uitgelicht onder het kopje ‘Video Speciaal’.

De Publieke Omroep kanalen zijn:

• Uitzendinggemist
• VPRO
• 3fm

Het Uitzendinggemist kanaal bevat helaas alleen teasers van wat er op Uitzendinggemist.nl staat of komt te staan. Zo nu en dan staat er een keer een iets langer item op, maar het biedt geen interessante inhoud.

De VPRO heeft niet 1 kanaal, maar meerdere:

• Algemeen VPRO
• 3VOOR12
• Holland Doc
• Geschiedenis TV
• Villa Life
• VPRO international

De kanalen van de VPRO bevatten zowel teasers als complete uitzendingen, of materiaal dat alleen voor internet bedoeld is. Ook het 3fm kanaal bevat meer dan alleen teasers.

Videotalent

Videotalent van de NCRV is een platform waar videomakers hun video’s kunnen uploaden. Deze video’s kunnen vervolgens in uitzendingen van de NCRV gebruikt worden. Er worden dus geen complete programma’s van de NCRV aangeboden.

De video’s van Videotalent kunnen eenvoudig op je eigen site geplaatst worden, iedere video heeft een knop ‘plaats op eigen site’.

NOS

Tijdens de Tour de France afgelopen zomer kon je via de NOS een videostream op je eigen site plaatsen. De video was nog wat klein, maar het geeft wel aan hoe er op dit moment binnen de NOS nagedacht wordt over het hergebruik van hun content op andere sites.

Een 2e initiatief waar (nog) niet zoveel ruchtbaarheid aan gegeven is, is de mogelijkheid om de NOS content in je eigen site te embedden. De lijst met mogelijkheden staat een beetje verstopt op de Feeds pagina.

Uit betrouwbare bron heb ik vernomen dat deze mogelijkheden binnenkort uitgebreid worden met oa losse onderwerpen van het NOS Journaal.

PCzapper

PCzapper.tv is een video portal waar ook de Uitzendinggemist uitzendingen van de Publieke Omroep tussen staan. PCzapper biedt bij iedere video ook een
‘embed’ mogelijkheid, om de video op je eigen site te plaatsen. PCzapper plaatst hiervoor de Uitzendinggemist video speler in een frame, waardoor een deel van de speler wegvalt en de video prominent in beeld blijft.

Het kan handig zijn om op deze manier een video te embedden, maar een erg mooie oplossing is het niet. De Publieke Omroep zou er beter aan doen, om dit zelf mogelijk te maken.

Toekomst

Voor de toekomst hoop ik dat de Publieke Omroep zelf meer video (en ook andere inhoud) zo gaat aanbieden dat deze makkelijk te hergebruiken is. Natuurlijk zou het mooi zijn als commerciële omroepen hier ook meer mee gaan doen, maar ik zou dit vooral als een publieke taak van de publieke omroepen willen zien.

Er zijn een aantal mogelijkheden waarop de Publieke Omroep het hergebruik van video zou kunnen ondersteunen en stimuleren:

• Embedden – Bij video een stukje html code plaatsen waarmee deze video op een eigen site geplaatst kan worden. Lekker simpel en doeltreffend om het gebruik van de video te stimuleren.
• API – Een API rond Uitzendinggemist waarmee organisaties en mensen kunnen voortborduren op de content van de Publieke Omroep door Mashups te creëren. Dit is een complexere oplossing dan de embed mogelijkhed, maar hiermee kunnen wel ‘rijkere’ applicaties onstaan.
• Creative Commons licentie – Uitzendingen waarvan een omroep alle rechten heeft (dus ook van de gebruikte audio, afbeeldingen, etc) zouden onder een Creative Commons licentie aangeboden kunnen worden. Hierdoor kunnen deze video’s geremixed worden en als basis dienen voor nieuwe content.

Ik hoop dat alle 3 de mogelijkheden in de nabije toekomst aangeboden worden. Het hoeft niet zo te zijn dat altijd alle 3 de mogelijkheden beschikbaar zijn, want ivm rechten kan dat soms lastig zijn, maar dat er iets moet en gaat gebeuren op dit gebied, daar ben ik van overtuigd.

Extra: Linken naar onderdeel Uitzendinggemist afleveringen

Als extra nog een voorbeeld hoe je kan linken naar een specifiek onderdeel uit een Uitzendinggemist aflevering. Je moet hiervoor de link naar de uitzendingen aanpassen.

Een link naar een aflevering op Uitzendinggemist ziet er als volgt uit:
http://player.omroep.nl/?aflID=5411687

Door er een start en een end achter te plaatsen, wordt alleen dat stuk video afgespeeld. De url komt er dan als volgt uit te zien:
http://player.omroep.nl/?aflID=5411715&start=00:01:05&end=00:04:30
Update 1: Het blijkt dat de bovenstaande link niet werkt op MacOSX. Of dit aan de Mac versie van de Windows Media plugin ligt of aan de implementatie van de player weet ik niet.

Update 2: ik had het bovenstaande stukje net gepubliceerd, toen ik een artikel op Publiek Centraal las met de titel:‘Uitzending Gemist wil ook ‘longtail’ gebruiken. Hierin een interview met Egon Verharen over de status van uitzendinggemist. Hij heeft het ook over de Long Tail en hergebruik van video:

De kern (= de Social Objects) van een huizensite is duidelijk, dat zijn de huizen. Helaas zijn de huizensites een beetje vergeten voor wie en aan wie ze de huizen verkopen: mensen!

Dit artikel beschrijft een aantal mogelijkheden waardoor de huizensites de mensen (zowel kopers als verkopers) beter van dienst kunnen zijn. Daarnaast zullen ze door het ontwikkelen en inzetten van deze mogelijkheden het ‘2.0-tijdperk‘ betreden en beter voorbereid zijn op de toekomst.

RSS

Van alle mogelijkheden is dit de meest eenvoudige om te implementeren. Zet de resultaten van een zoekopdracht om naar een RSS feed en geef mensen de mogelijkheid om zich hierop de abonneren. Dit is een goede uitbreiding van het bestaande aanbod van email en inloggen op een site om geattendeerd te worden op nieuwe woningen die aan jouw zoekvoorwaarden voldoen.

Naast nieuwe woningen is het ook interessant om je te kunnen abonneren op een RSS feed van één bepaalde woning, zodat je geattendeerd wordt op wijzigen in de informatie van deze woningen (bijv prijsverlagingen). Als je informatie van meerdere woningen wilt monitoren moet dat natuurlijk gecombineerd kunnen worden tot 1 RSS feed.

Widgets voor kopers

Een logisch vervolg op het aanbieden van RSS feeds zijn Widgets. Widgets voor iGoogle, Netvibes, Mobiele telefoon. MacOSX, etc.

De RSS feeds kan je natuurlijk zelf toevoegen aan je persoonlijke homepage, maar het is interessanter als de huizensites zelf mooie en bruikbare widgets zouden aanbieden. Een widget die in een lijst nieuwe woningen laat zien die aan jouw zoekvoorwaarden voldoen is niet zo interessant. Interessanter is om direct in de widget alvast wat meer informatie te kunnen zien over de nieuwe woningen. bijvoorbeeld een foto, video of de locatie tonen op een kaart.

Widgets voor verkopers

Makelaars en huizensites proberen huizen te verkopen in opdracht van hun klant, de verkoper. Als ik mijn huis zou verkopen heb ik er belang bij dat mijn huis op zoveel mogelijk plaatsen wordt gepromoot. Een widget zou hier een mooi hulpmiddel voor zijn. Dit gaat dan om een widget ter promotie van jouw woning die je op je eigen site, weblog, hyves, etc kan plaatsen.

SMS

Er zijn verschillende makelaars die aan het experimenteren zijn met informatie opvragen over een woning via SMS. In deze gevallen staat er een telefoonnummer en een code op een ‘te koop’-bordje. Ik vraag me af hoe interessant het is om informatie over een woning te ontvangen via SMS. SMS is toch vrij beperkt qua informatie. Interessanter zou het zijn als je de mogelijkheid heb om een SMS-je te sturen met je emailadres en dat je dan vervolgens informatie (of een link naar de informatie) in je mailbox ontvangt.

Een melding dat er nieuwe woningen toegevoegd zijn die aan jouw zoekresultaten voldoen is ook interessant om via SMS te ontvangen. Hierdoor weet je dat je zo snel mogelijk op de website moet kijken of de toegevoegde woningen voor jou interessant zijn.

Een melding dat de prijs van een woning waarin jij geïnteresseerd bent, is gewijzigd, is ook uitermate interessant. Hierbij wil je natuurlijk niet alleen de melding ontvangen maar ook direct de nieuwe prijs.

Mobiel

Anders dan SMS is mobiel internet al weer een stuk interessanter om direct informatie van een huis op te vragen als je een ‘te koop’-bordje ziet. Hier zijn een aantal mogelijkheden voor:

• Code – Vul de code van het ‘te koop’-bordje in op de site de ook genoemd wordt op bord en je wordt direct doorgestuurd naar de betreffende pagina.
• Permalink – Een directe url naar de webpagina van het betreffende huis.
• Shotcode – Foto maken van een code op het bord en een applicatie op je mobiele telefoon stuurt je direct door naar de juiste pagina.
• Location Based Services – Zoek naar alle huizen die te koop staan in de omgeving waar jij je bevindt.

Andere mogelijkheden die misschien op een wat langere termijn beschikbaar komen zijn:

• RFID – RFID tag kan verwerkt worden in een ‘te koop’ bord. Als er meer mobiele telefoons komen met een RFID lezer, kan deze de tag herkennen en je doorsturen naar de pagina over de betreffende woning.
• Foto herkenning – Maak een foto van de woning die te koop staat en een applicatie op je mobiel zoekt de informatie op die bij de betreffende woning hoort.

Het kan lastig zijn om de RFID en Shotcode methoden te gebruiken als het ‘te koop’-bordje nogal op een afstand staat, zoals bij een appartementen complex. De toekomst zal moeten leren of hier ook adequate oplossing voor bedacht worden. In ieder geval kunnen de bovenstaande technieken gecombineerd worden.

Voorwaarde voor het gebruik van deze methoden is wel dat de huizensites goed geschikt zijn voor mobiel gebruik. Dat lijkt op dit moment nog niet het geval te zijn.

Mapplets

Sinds een aantal maanden biedt Google de mogelijkheid om zogenaamde ‘Mapplets‘ te ontwikkelen. Een Mapplet is een laag welke de gebruiker zelf kan aan zetten op maps.google.nl.

Waarom is dit nu zo’n interessante mogelijkheid voor huizensites? Een gebruiker kan de huizenlaag combineren met andere Mapplets die bijvoorbeeld informatie afbeelden over de buurt waarin de huizen staan (scholen, uitgaansgelegenheden, parkeerplaatsen, openbaar vervoer, etc).

Een huizensite kan deze informatie ook op z’n eigen site plaatsen (wat zeker goed is om te doen), maar het is onmogelijk om alle informatie aan te bieden. Met name informatie die maar voor een bepaalde kleine groep potentiële kopers interessant is (vergelijkbaar met het Long Tail effect).

Er wordt op dit moment nog niet veel informatie aangeboden als Mapplet, maar ik verwacht dat dat in de toekomst zal toenemen.

Buurtinformatie

Voor een koper is het erg interessant om te weten in wat voor een soort buurt een woning staat. Op dit moment bieden een aantal sites statische informatie aan over de buurt. Het gaat dan met name om hoeveel procent ouderen en gezinnen er wonen, wat het gemiddelde inkomen is, etc. Deze informatie komt uit officiële statische bronnen.

In het huidige tijdperk van User Generated Content kan deze informatie aangevuld worden met informatie van mensen uit de buurt. Ervaringen over hoe het wonen in de buurt is.

Natuurlijk kleven hier ook gevaren aan. Voor een verkopende partij zal het niet leuk zijn als er met name slechte ervaringen over een buurt staan. Maar ik ben van mening dat je het beste maar zo eerlijk mogelijk kunt zijn. Nu kan een potentiele koper ook bij de buren gaan vragen wat hun ervaringen zijn met de buurt.

Adverteren

Met de mogelijkheden die Google Adwords en Google Maps bieden kan je veel gerichter adverteren met woningen dan op dit moment gebeurt. Als je nu zoekt in Google op “3 kamer appartement amsterdam de pijp” krijg je een aantal advertenties te zien die over appartementen in Amsterdam gaan.

Als een site hun huizen bestand koppelt aan Adwords, zoals Toading dat bijvoorbeeld doet voor KLM vluchtgegevens, kan er direct een advertentie verschijnen voor een woning die voldoet aan de zoekopdracht.

Uitwisselings API

Als de huizensites nu een API ontwikkelen waarmee ze informatie over huizen onderling kunnen uitwisselen, zodat ze niet langer elkaars sites hoeven te gaan spideren, dan houden ze tijd en geld over om zich klaar te gaan maken voor de toekomst. De kansen liggen voor het op grijpen.