Conceptual Friday 23 januari 2015

Categorie:EnterpriseLinkedData
Locatie: Geonovum, Amersfoort
Route: Route naar Geonovum
==Aanwezigen==
* Joep Creusen (NS)
* Pieter van Everdingen (OpenInc)
* Richard Nagelmaeker (Ordina)
* Bart van Leeuwen (Netage)
* Gerald Wildenbeest (Saxion - SAB)
==Agenda==
* Concrete praktijkcase bespreken (de brandweercase)
* Traditionele en Linked Data scenario naast elkaar zetten
* Vervolgstappen afspreken om de case verder uit te werken
==De praktijkcase van de brandweer==
Bart heeft geschetst hoe de Linked Data integratie-oplossing voor de brandweer werkt (zowel in Nederland als in Amerika) en een live demo gegeven van alle stappen in het transportproces om incidentgegevens van de meldingen in het Gemeenschappelijke Meldkamer Systeem (GMS) naar de juiste brandweerkazernes te krijgen via een op Java Message Service (JMS) gebaseerde integratie-oplossing.
==Het belang van goed gedefinieerde brandweertermen==
Het definiëren van een eenduidig brandweer begrippenkader was een belangrijke eerste stap bij het uitwerken van de Linked Data integratie-oplossing voor de brandweer. En de vocabulaire SKOS speelde een belangrijke rol daarbij. Gelukkig zien we binnen de Linked Data community, dat SKOS meer en meer erkend wordt als een van de essentiële onderdelen van Enterprise Linked Data.
==Architectuurschets van de praktijkcase bij de brandweer==
Het volgende overzichtsplaatje laat de stappen in het transportproces zien hoe de incidentgegevens van de meldingen die binnenkomen bij de verschillende meldkamers omgezet worden naar Linked Data en verrijkt worden met andere data, zodat de brandweerkazernes die met deze incidentgegevens aan de slag moeten van de beste informatie zijn voorzien om hun werk snel en goed te kunnen doen bij reddingsoperaties. 
Figuur 1 - Linked Data praktijkcase van de brandweer
De praktijkcase van de brandweer is een op JMS (Java Message Service) gebaseerde integratie-oplossing. Turtle tekstberichten worden via JMS verstuurd en niet via HTTP, omdat dit de betrouwbaarheid van de oplossing verhoogt. ESB’s gebruiken intern vaak ook een messaging structuur (waar JMS een afgeleide van is) voor het transport van berichten tussen zenders en ontvangers van data.
==Toelichting van de stappen in het proces van dit scenario==
Meldingen van incidenten komen binnen bij de meldkamers die deze incidenten opslaan in hun Gemeenschappelijke Meldkamer Systeem (GMS). GMS maakt gebruik van een Oracle database, waarbij elke meldkamer zijn eigen database instantie heeft om de gemelde incidentgegevens op te kunnen slaan. Vervolgens worden deze incidentgegevens gekopieerd naar een replicatie server, waarna ze via een polling mechanisme en met behulp van een complexe SQL Query (4 queries) uit deze server gehaald worden, waarna er Linked Data van gemaakt kan worden.
Tijdens de query wordt de postcode aan de incidenten toegevoegd, zodat dit gebruikt kan worden bij de distributie van de incidentgegevens naar de juiste kazernes. Van de opgehaalde incidentgegevens wordt nu Linked Data gemaakt (een Turtle platte tekst bestand) met behulp van een aantal standaard en zelfgedefinieerde vocabulaires, zoals SEM (Simple Event Model) voor events, SKOS voor definities, OWMS en Dublin Core voor metadata, Vcard voor adressen, W3C WGS84 voor Geo locaties en prov-o voor provenance. Er zijn aanvullend nog 6 data attributen zelf gedefinieerd. 
Vervolgens wordt dit Turtle tekstbestand op de ingaande queue gezet, zodat deze via ESB-achtige functionaliteit getransporteerd kan worden naar de juiste kazernes. Tijdens dit proces wordt de incidentgegevens verder verrijkt met o.a. BAG data en in een Graph store opgeslagen. De incidentgegevens worden verrijkt binnen Message Driven Beans (MDB’s), zodat de experts en de niet-experts de beste informatie tot hun beschikking hebben om de juiste beslissingen te nemen tijdens een reddingsoperatie. 
De laatste stappen in het proces zijn dat de verrijkte incidentgegevens op een uitgaande queue worden gezet om via een distributiemechanisme bij de juiste kazernes terecht te komen, zodat deze de goede acties kunnen ondernemen. Daarbij wordt met een graph compare nog gecheckt of met de juiste versie van de data gewerkt wordt. De queues werken met queue listeners die berichten oppakken om verder te verwerken conform de frequentie die is ingesteld binnen deze componenten van de oplossing.
Voor wat betreft het Linked Data gedeelte van deze oplossing zien we dat URI’s van bijv. de brandweerkazernes nog niet dereferenceable zijn als de incidentgegevens op de eerste queue zijn gezet. De gegevens zijn dan nog niet opgeslagen. Pas als de incidentgegevens zijn opgeslagen in de store kunnen deze gegevens doorzocht worden en kunnen de URI’s gevonden worden om te bepalen naar welke kazernes een incidentbericht gestuurd moet worden (elke kazerne heeft een eigen URI). 
==Wijziging doorvoeren door een data element toe te voegen==
Bart heeft laten zien, dat als je aan de incidentbericht dat naar de brandweerkazernes wordt verstuurd een data element toevoegt er alleen aan de input- en output-kant een kleine wijziging moet worden doorgevoerd (een triple erbij) en er niets aan de processtappen hoeft te worden aangepast en het toegevoegde data element in de output goed wordt getoond en goed kan worden verwerkt door de gebruiker.
==Nederlandse en Amerikaanse versie van de brandweer case==
De technische oplossing die tijdens deze Conceptual Friday gedemo-ed is, is hetzelfde voor de Nederlandse en Amerikaanse versie van dit systeem en kan makkelijk werken met de lokale verschillen (bijv. de verschillende formaten tussen Nederlandse en Amerikaanse postcodes). Hiervoor zijn geen grote wijzigingen nodig. Tijdens de live demo hebben we de client interface van de Amerikaanse versie gezien.
==Een mogelijke volgende stap voor de brandweer case==
Een volgende stap in de verdere uitwerking van deze integratie-oplossing kan zijn om de Queues te vervangen door Topics. Met de huidige Queues-opzet is een one-to-one integratie-oplossing geïmplementeerd (point-to-point), terwijl met Topics een many-to-many integratie-oplossing geïmplementeerd kan worden. De ontvangers van data kunnen zich dan abonneren op een onderwerp, zodat zij de data kunnen ontvangen waarin zij geïnteresseerd zijn. Vraag is dan wel, hoe je met Topics garanteed delivery van berichten kan inregelen zoals je dat bij Queues gewend was.
==Vervolgstappen/acties uit deze Conceptual Friday==
Aan het einde van deze Conceptual Friday zijn de volgende actiepunten afgesproken, waarbij we eerst aan actiepunt 1 gaan werken (verzamelen en bestuderen van impact analyses van ESB-implementaties en dit afzetten tegen de stappen en mogelijke kosten die nodig zijn met een vergelijkbare Linked Data oplossing). De andere actiepunten moeten nog verder besproken worden tijdens de volgende Conceptual Friday.
Verder zijn we binnen de werkgroep van mening, dat we tijdens een Proof of Concept of pilot niet iets moeten gaan bouwen wat zich al bewezen heeft. ESB-functionaliteit bestaat inmiddels al meer dan 10 jaar en is een bekende en goedgedocumenteerde integratie-oplossing. We willen onze tijd binnen deze werkgroep optimaal proberen te benutten door te laten zien hoe een ESB-achtige integratie-oplossing beter, makkelijker en goedkoper met Linked Data gerealiseerd kan worden vanuit een zelf bedachte praktijkcase of vanuit een praktijkcase van een (of meer) sponsorende organisaties. 
Nr	Actie 	Eigenaar 	Status
1 	Een (of meer) impactanalyses bekijken van ESB integratie-oplossingen en deze vertalen naar de activiteiten en kosten die nodig zijn om hetzelfde als Linked Data integratieoplossing te realiseren en te onderhouden 	Richard Nagelmaeker e.a.	onderhanden
2 	De brandweer praktijkcase beschrijven als best practice, zodat andere organisaties in andere bedrijfssectoren deze flexibele en goedkope integratie-oplossing ook kunnen gebruiken binnen hun eigen context 	Bart van Leeuwen e.a. 	nog verder bespreken
3 	De best practice uitbreiden naar een Linked Data integratie-oplossing die meer open is, zodat deze ook over bedrijfsgrenzen heen gebruikt kan worden (met een JMS-based integratieoplossing blijf je binnen bedrijfsgrenzen?)	allemaal 	nog verder bespreken
4 	Beschrijven welke technology stack en ontwikkelomgeving het meest geschikt zijn om deze Linked Data integratie-oplossing te implementeren, waarbij zoveel mogelijk gebruik gemaakt wordt van open source tooling 	allemaal 	nog verder bespreken
==Nuttige links==
Gegeven de brandweercase zijn hieronder een aantal links opgenomen voor de gebruikte technieken en standaarden bij deze case.
* http://www.w3.org/TR/turtle/
* http://www.cs.vu.nl/~laurah/pubs/vanHage2011SEM.pdf (PDF)
* http://www.w3.org/TR/skos-reference/
* http://standaarden.overheid.nl/owms/4.0/doc
* http://www.w3.org/2006/vcard/ns-2006.html
* http://www.w3.org/2003/01/geo/wgs84_pos
* http://www.w3.org/TR/prov-o/
* http://vocab.resc.info