Conceptual Friday 6 februari 2015

Versie door Pveverdingen (overleg | bijdragen) op 12 feb 2015 om 23:41
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)

Locatie: Geonovum, Amersfoort
Route: Route naar Geonovum

Aanwezigen[bewerken]

Agenda[bewerken]

Samengevat:

  1. Best practice o.b.v. brandweercase?
  2. Verschillen tussen LD en ESB-scenario
  3. Nieuwe praktijkcases om aan te werken


Zoals in de aankondiging op LinkedIn:

  1. Eerste versie van een best practice uitwerken, gebaseerd op de goedwerkende Linked Data integratie-oplossing die gebruikt wordt bij de brandweer, zodat die oplossing ook door andere sectoren en organisaties gebruikt kan worden
  2. De verschillen tussen het Linked Data en ESB (Enterprise Service Bus) integratiescenario verder uitwerken voor wat betreft de benodigde implementatie-activiteiten en de beheer- en onderhoudsactiviteiten, zodat we de voordelen van een Linked Data integratie-oplossing verder kunnen onderbouwen (niet de starheid van traditionele oplossingen, oftewel meer flexibiliteit, aanzienlijk kleinere wijzigingen en kortere doorlooptijden voor alle activiteiten en daarmee dus ook aanzienlijk lagere kosten voor dergelijke trajecten)
  3. Welke cases kunnen we bedenken die geschikt zijn om verder uit te werken in een PoC (Proof of Concept) of pilot en wie uit ons netwerk weet organisaties die geïnteresseerd zijn om met Linked Data aan de slag te gaan als slimme integratie (en harmonisatie) oplossing, zodat we die kunnen gaan benaderen met een concreet voorstel voor een PoC of pilot


Tijdens de discussies van deze Conceptual Friday hebben we het vooral gehad over agendapunt 1 (ook vanwege de beschikbare tijd).

Best practice o.b.v. brandweercase?[bewerken]

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.

Tussenconclusie[bewerken]

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.

Ideaalplaatje?[bewerken]

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.

Uitdagingen[bewerken]

De volgende uitdagingen zijn deze Conceptual Friday besproken:

  • Closed world versus open world assumption
  • Vendor independency versus vendor lock-in
  • Ontbrekende beveiligingsstandaarden
  • Geen controle op wat de gebruiker doet
  • Geen commit en rollback mechanismen
  • Business argumenten voor besluitvormers


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.

Oplossingsrichtingen[bewerken]

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.

  • Smart agents (zoals die binnen de Internet of Things gebruikt worden)
  • Intelligente Javascript clients die triples kunnen begrijpen en ermee kunnen werken
  • Linked Data Fragments (van Ruben Verborgh e.a.)
  • Hydra (de activiteiten van o.a. Markus Lanthaler)
  • Node.js
  • Linked Data Platform (LDP) working group met o.a. activiteiten voor:
    • Authentication
    • Autorization
  • RDF Data shapes (ook een W3C activiteit)


Vervolgstappen/acties uit deze Conceptual Friday[bewerken]

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

Nuttige links[bewerken]