Boek 5/Blog: Dimitri van Hees - Separation of concerns

< Boek 5

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.