Webservices versus Linked Data

Voer hier de niet op te maken tekst inWebservices versus Linked Data: data uitwisselen versus data koppelen (ik had een langere tekst maar wist niet dat LinkedIn max 4000 tekens ondersteunt dus her en der heb ik wat ingekort ;-))
Gister heb ik de sessie van de pilot bezocht. Omdat we pas sinds kort zijn ingestapt was ik daar vooral uit nieuwsgierigheid. Wat ik zag was een groep enthousiaste mensen die bevlogen zijn met LOD. Als nieuwkomer kreeg ik dan ook de indruk dat je rustig over een succesvolle pilot kan praten en aan de hand van het programma kijk ik uit naar het eindcongres. Wat mij echter nog steeds niet helemaal duidelijk is, is de doelstelling...
Als ik kijk naar het doel van de Kadaster Toolbox dan is dat om de community aan de slag te laten gaan met het ontwikkelen van apps in de breedste zin des woords. Dit past bij de doelstelling om de economie een boost te geven door bedrijven en particulieren geld te laten verdienen met deze apps en zelf minder apps te hoeven ontwikkelen. 
Dit heeft op zich weinig met LOD te maken. Het zal developers weinig uitmaken hoe data verzameld wordt, als het maar gebeurt. Of dit met SPARQL gebeurt of door 10 stagiaires dagelijks wordt overgetypt doet er niet toe. De meerwaarde van het koppelen van data is dat er veel meer mogelijkheden zijn voor de eindgebruiker. Maar ook hiervoor geldt dat het de developer niets uitmaakt hoe dit gekoppeld wordt, als het maar gebeurt.
Bekijken we het vanuit de doelstelling dat er een manier gevonden moet worden om data te koppelen dan is LOD voldoende om dit te behalen. Ik ben er van overtuigd dat LOD dé manier is om data te koppelen en zeker de toekomst heeft. Maar met alleen data linkbaar maken ben je er mijns inziens nog niet. Sterker nog: daar heeft de community momenteel vrij weinig aan.
Met de opkomst van betaalbare hardware (Raspberry, Arduino, etc.) en mobile devices zijn we in een revolutie beland waarbij iedereen devices web-based kan laten communiceren met elkaar en met het web. Veel van deze ontwikkelingen zijn te danken aan de community waardoor je door het downloaden van een library heel simpel je huiskamertemperatuur via internet kan volgen. Bijna al deze code is geschreven volgens dé huidige standaard om gegevens uit te wisselen: een RESTful JSON Webservice.
SOAP is uit, REST is in. XML is uit, JSON is in. Waarom? Omdat XML een heleboel metadata teruggeeft waardoor de payload hoger wordt en dat is weer nadelig voor dataverbruik en performance op mobiele devices en microcontrollers. Daarnaast is XML lastiger te parsen wat een drempel is voor developers in tegenstelling tot eenvoudige JSON.
Of het maken van een dergelijke API (waarin tevens de benodigde logica, performance, statistieken en eventuele betalingen of autorisatie wordt afgehandeld) onderdeel is van deze pilot weet ik niet, wat ik wel weet is dat LOD géén vervanger is van een webservice. Als we willen dat de community met data aan de slag gaat zullen deze twee dingen naast elkaar moeten bestaan. Als we verwachten dat de door de community opgebouwde standaarden vervangen worden door LOD ben ik bang dat dit de huidige ontwikkelingen juist af zal remmen.
Ik heb 2 schetsen bijgevoegd van PostcodeAPI. 1 is de huidige situatie, waarin wij zelf niet-linked data van BAG (adressen) en het CBS (gemeente/provincienamen) bij elkaar zoeken en koppelen. 2 is mijn gewenste situatie waarbij wij via LOD adressen aan gemeentenamen kunnen koppelen voor de Postcode API en aan andere data voor een andere API. Maar de 'onderkant' blijft bestaan en dat is waar developers tegen willen praten.
LOD is in mijn ogen het koppelen van data, voor het uitwisselen van data heb je anno 2013 nog steeds een webservice nodig. Dat is namelijk waar de markt om vraagt. En dat is weer belangrijk voor de beslissing om te investeren in het ontwikkelen van een API of LOD. Als het budget niet toelaat om in beiden te investeren adviseer ik een API, daar is immers meer vraag naar. In de praktijk blijkt dat vaak het geval.
Ik vind LOD machtig interessant en geloof dat het complementair is aan webservices en vice versa, maar LOD != webservice. Voorlopig nog niet. Wellicht is dat toch iets om over na te denken voor het eindcongres.