Locatie: Geonovum, Amersfoort
Route: Route naar Geonovum
Samengevat:
Zoals in de aankondiging op LinkedIn:
Tijdens de discussies van deze Conceptual Friday hebben we het vooral gehad over agendapunt 1 (ook vanwege de beschikbare tijd).
Het eerste idée dat we hadden toen we de brandweercase bespraken tijdens de vorige Conceptual Friday was, dat we die oplossing direct zouden kunnen vertalen naar een meer generieke en meer open best practice voor een Linked Data integratie oplossing.
Na aanvullende discussies tijdens deze Conceptual Friday zijn we tot de conclusie gekomen dat we dat beter niet kunnen doen, omdat in de oplossing van de brandweercase componenten zitten die voor een zuivere Linked Data oplossing niet nodig zijn.
In de praktijk kun je met deze componenten, zoals Enterprise Service Bus (ESB) achtige functionaliteit, geconfronteerd worden en toch een goed werkende Linked Data integratie oplossing maken. Maar vaak zijn er hele andere redenen om voor dit soort componenten te kiezen, zoals ontkoppeling en guaranteed delivery, dan de redenen die je gebruikt om meer voor een Linked Data scenario te kiezen, zoals de data begrijpbaar maken voor mens en machine door context, betekenis en metadata aan de data mee te geven, de grotere flexibiliteit, en dus ook de makkelijkere uitbreidbaarheid en aanpasbaarheid van datasets (triples toevoegen), kortere doorlooptijden bij wijzigingen en de veel lagere kosten.
Dat maakt dat we opgedane inzichten en lessons learned uit de goed werkende brandweercase prima kunnen gebruiken om een generieke oplossing te maken en te beschrijven, maar dat dat geen 1-op-1 mapping zal zijn vanuit de datatransport processtappen in die oplossing en de bouwstenen die we in de architectuur van die oplossing tegenkomen.
Het ideaalplaatje voor een Enterprise Linked Data integratie-oplossing bestaat derhalve niet, omdat dit afhankelijk is van een groot aantal factoren die binnen enterprise context een rol spelen (zie volgende sectie). Wel kunnen we proberen een Linked Data referentie architectuur plaatje te maken (of te vinden), dat zo generiek en zo open mogelijk is, waarbij niet of zo min mogelijk gebruik gemaakt wordt van proprietary oplossingen (dus vendor lock-in proberen te vermijden).
In de volgende sectie op deze pagina zullen we een aantal uitdagingen benoemen die de keuzes binnen Enterprise Linked Data integratie oplossingsscenario sterk kunnen beinvloeden.
De volgende uitdagingen zijn deze Conceptual Friday besproken:
Elke uitdaging zal nu kort toegelicht worden.
In de praktijk zien we dat veel bedrijven nog helemaal niet open willen zijn. Er zijn een aantal positieve uitzonderingen te benoemen, zoals Amazon, Mercedes en NXP die er bewust voor kiezen om met Linked Data te werken vanwege de grote voordelen die Linked Data heeft t.o.v. meer traditionele oplossingen.
Maar ook in een gesloten omgeving kan het gebruik van Linked Data van grote toegevoegde waarde zijn en dat willen we ook met de activiteiten van deze werkgroep aantonen. Het feit dat een omgeving gesloten is, kan wel van invloed zijn op de mogelijk andere keuzes die je dan maakt binnen een integratie-oplossingsscenario.
Ook kan het zijn dat je binnen bedrijfsomgevingen gedwongen wordt om met bepaalde proprietary componenten te werken. Dat is een gegeven waar een generieke architectuur mee om moet kunnen gaan. Dat kan dus betekenen dat er meer hybride integratie-oplossingsscenario’s moeten worden uitgewerkt.
Ook zien we dat op het gebied van Linked Data een aantal beveiligingsstandaards voor authenticatie en authorisatie nog niet bestaan. De Linked Data Platform (LDP) working group gaat dit onderwerp wel oppakken, maar het is nog niet bekend wanneer we hier de eerste bruikbare resultaten van kunnen verwachten. Mogelijk zijn er echter alternatieven te bedenken vanuit de meer traditionele integratie-oplossingen, zoals SAML, die ook goed kunnen werken in combinatie met Linked Data. Dat moet nog verder uitgezocht worden. Door het ontbreken van beveiligingsstandaarden kan het dus voorkomen dat er in de huidige oplossingen geen/weinig controle is op wat een gebruiker doet en dat een gebruiker te veel kan doen als hij snapt hoe het werkt. Echter we zullen zien, dat de benodigde standaarden hiervoor zullen worden uitgewerkt.
Er zijn ook uitdagingen voor wat betreft het uitvoeren van transacties met Linked Data. De gebruikte technologie bij Linked Data, zoals SPARQL, kent geen committ en rollback mechanismen en de transacties bij REST API’s zijn stateless, zodat je niet terug kunt gaan naar een valide vorige toestand. Ook transacties met Linked Data zijn dus onderwerp van nader onderzoek. Ook dit is een onderwerp dat binnen de Linked Data Platform (LDP) working group wordt opgepakt. En daar waar we reeds werkende best practices tegenkomen, zullen we die betrekken binnen de activiteiten van deze werkgroep.
De algemene beleving van de betrokken Linked Data experts is dat Linked Data oplossingen een factor 10 of zelf nog meer goedkoper kunnen zijn dan vergelijkbare traditionele oplossingen. Dit is een zeer goed argument om in Linked Data meer tijd en energie te steken om dit verder te onderbouwen met een aantal goede praktijkcases en dit dan ook in business taal te kunnen communiceren aan de betrokken stakeholders en besluitvormers. Ook hier is nog werk te doen om Linked Data breder geaccepteerd te krijgen.
Zoals gezegd zijn er in de praktijk een groot aantal voorbeelden hoe Linked Data wordt toegepast binnen een bedrijfscontext. Deze oplossingen zijn goed bruikbaar in de praktijk, maar we zien dat we op een aantal punten nog wat verbeteringen zouden willen zien. Een aantal initiatieven zijn al bezig met de verbeteringen die voor onze werkgroep interessant kunnen zijn.
De conclusie uit deze Conceptual Friday is dat we eerst een visiedocument willen opstellen, waarin we de tot nu toe opgedane inzichten willen vertalen naar hoe een Enterprise Linked Data integratie-oplossing zo generiek en zo open mogelijk beschreven kan worden, zodat je per onderdeel van een mogelijk oplossings-scenario kan bepalen waarvoor je ergens voor kiest en waarom.
Nr | Actie | Eigenaar | Status |
---|---|---|---|
1 | Visiedocument opstellen wat we willen presenteren op de bijeenkomst op 2 april bij Waternet | Pieter van Everdingen, Bart van Leeuwen, e.a. | nog inplannen |
2 | Minimaal 1 praktijkcase definieren, waarmee we de visie kunnen toetsen | Richard Nagelmaeker e.a. | nog verder bespreken |
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.
Linked Data Fragments is a conceptual framework that provides a uniform view on all possible interfaces to RDF, by observing that each interface partitions a dataset into its own specific kind of fragments. A Linked Data Fragment (LDF) is characterized by a specific selector (subject URI, SPARQL query, …), metadata (variable names, counts, …), and controls (links or URIs to other fragments).
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