De eerste PLDN-bijeenkomst die ik eind 2012 bezocht, bezorgde mij een lichte cultuurshock. Ik was gewend om buiten kantoortijden in hippe anti-kraakkantoortjes met pragmatische mede-nerds, ongeschoren UX designers en online marketeers van flitsende startups over mobile app development, Internet of Things, NoSQL databases en de nieuwste Facebook en Twitter API’s te praten. Maar hier spraken keurige mensen tijdens een uitgebreide koffietafel over semantiek, URI-strategieën, Tim Berners-Lee, SOAP, XML, W3C standaarden, RDF, triple stores, SPARQL, informatiemodellen en tal van andere onderwerpen waar ‘wij’ het nooit over hadden.
Ondanks de compleet andere setting intrigeerde het onderwerp Linked Data mij. Want wat zou semantiek kunnen betekenen voor chatbots? Wat zou het kunnen bevragen van meerdere gelinkte databronnen kunnen betekenen voor online marketing? En wat te denken van het volgen van links om meer informatie in applicaties te kunnen tonen?
Ik werd ‘trekker’ van het onderwerp ‘Linked Data voor developers’. Die case leidde tot de ‘missing link’ tussen beide werelden. Na de derde ster van het beroemde vijfsterrenmodel haakten de eerder genoemde flitsende startups massaal af. “SPARQL? Dat kennen we niet. Is er niet gewoon een REST API, zoals bij Facebook en Twitter?”. Met de lancering van JSON-LD werd het onderwerp met een knipoog naar het vijfsterrenmodel afgesloten door een zesde ster toe te voegen: API’s.
In de wereld der API’s speelt ‘separation of concerns’ een grote rol. Dit wil zeggen dat ieder onderdeel van een systeem precies dát doet waar het goed in is. Op deze manier kan alle benodigde expertise gefocust worden op een specifiek onderdeel. Neem Stripe. Deze payment provider levert via een API de financiële expertise die menig ontwikkelaar niet heeft en ook niet wil hebben. Fraudedetectie? Validatie van creditcards? De implementerende partij weet er niks vanaf en hoeft dat ook niet. Stuur een creditcardnummer en een bedrag naar de Stripe API en zij regelen de rest.
Separation of concerns geldt ook voor mensen met verschillende disciplines. Linked Data is geen totaaloplossing. Het is een concept dat bestaat uit meerdere facetten die je ook los van elkaar zou moeten kunnen gebruiken. Mensen die zich ontfermen over semantische vraagstukken als ‘betekent het verlengen van een wegdeel nu een nieuw wegdeel of een aangepaste eigenschap?’, zijn gebaat bij kennis over filosofie, terwijl het optimaliseren van triple store performance een andere tak van sport is.
Nu de API in de Linked Data-community geaccepteerd is, vind ik het tijd om over dit onderwerp na te gaan denken. Wat mij betreft beginnen we bij ‘visualisaties’. Die moeten gemaakt worden door mensen met verstand van ‘visualisaties’ en niet door mensen met verstand van SPARQL. Mensen die mooie en bruikbare visualisaties kunnen maken zijn opgeleid om mooie en bruikbare visualisaties te maken en niet om Linked Data te begrijpen. Het zal eindgebruikers een biet wezen uit welke database de data komt, zolang de visualisatie maar goed is.
Zolang dit niet gebeurt, is het het allemaal ‘net-niet’. De leukste Linked Data-cases blijken in de praktijk geen Linked Data, maar lenen slechts het concept. Dat is niet erg. Hybride oplossingen, waarbij het beste uit alle werelden gehaald wordt, hebben de toekomst. Laten we ons daar op focussen, zodat iedereen kan doen waar hij/zij het beste in is. Dan volgen de flitsende startups vanzelf.
Dimitri van Hees
Dimitri van Hees (@dvh) is dataspecialist, medeoprichter van Apiwise en in zijn vrije tijd API-driven bierbrouwer bij brouwerij De Brouwtoren.
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). Vaak vormen API's de scheiding tussen verschillende lagen van abstractie, zodat applicaties op een hoog niveau van abstractie kunnen werken en het minder abstracte werk uitbesteden aan andere programma's. Hierdoor hoeft bijvoorbeeld een tekenprogramma niet te weten hoe het de printer moet aansturen, maar roept het daarvoor een gespecialiseerd stuk software aan in een bibliotheek, via een afdruk-API.
Resource Description Framework (RDF) is een standaardmodel voor gegevensuitwisseling op het web. RDF heeft functies die het samenvoegen van gegevens vergemakkelijken, zelfs als de onderliggende schema's verschillen, en het ondersteunt specifiek de evolutie van schema's in de loop van de tijd zonder dat alle gegevensgebruikers moeten worden gewijzigd.
De activiteiten van Platform Linked Data Nederland (PLDN) worden mede mogelijk gemaakt dankzij het Kadaster, TNO, Big Data Value Center (BDVC), ECP, Forum Standaardisatie, Kennisnet, SLO, Waternet, Taxonic, MarkLogic, Triply, Franz Inc., SemmTech, Rijksdienst voor het Cultureel Erfgoed (RCE), Beeld en Geluid, EuroSDR, de KVK en ArchiXL
Wilt u op de hoogte gehouden worden van nieuws en ontwikkelingen binnen PLDN?
Schrijf u dan in voor de nieuwsbrief