Pilot Linked Open Data by Geonovum

Pilot Linked Open Data Nederland

Colofon Dit boek is een gecombineerde heruitgave van deel 1 (Het Managementoverzicht) en deel 2 (De Verdieping) van Pilot Linked Open Data, een verzameling van artikelen waaraan gewerkt is in de Pilot Linked Open Data (2012-2013).

Founding fathers De founding fathers van PiLOD zijn:

Deze uitgave is mogelijk gemaakt door: â&#x20AC;&#x192;

www.den.nl www.pilod.nl Editors Erwin Folmer, Marcel Reuvers, Wilko Quak (allen editors deel 1 en 2), Paul Brandt (review deel 1) Communicatie Yvonne Verdonk Opmaak remwerk, Amersfoort Drukwerk Klomp Bizzprint, Amersfoort Oplage 800 Contact Erwin Folmer (PiLOD): e.folmer@geonovum.nl Ralph Stuyver (DEN): ralph.stuyver@den.nl ISBN 978-90-5986-446-7

Inhoud Deel 1 - Het Managementoverzicht Voorwoord 5 Introductie Pilot Linked Open Data

Data, Data, Data: Big, Linked & Open

Linked Open Data in Nederland: een snelgroeiend gewas in vruchtbare bodem Artikelen Deel 2 De samenvattingen

33 41

Deel 2 - De Verdieping A

The Essentials: Een algemene introductie in Linked Open Data

Linked Open Data â&#x20AC;&#x201C; The Essentials

De Toepassingen: Mogelijke toepassingen op basis van Linked Open Data

5 Sterren toepassingen: niet zo logisch als het lijkt

Huiskluis: basis voor nieuwe diensten

Branden blussen met Linked Open Data

103

Linked Data & semantiek: we begrijpen elkaar steeds beter

105

Casus OnderwijsBegrippenKader: de basis onder Educational Linkedscape

116

De erfgoedthesaurus in de kennisketen van het cultureel erfgoed

135

OpenInc: waarde creĂŤren met Open Data

146

Open Data in electronics industry

153

How to: Gericht op toepassers van Linked Open Data

Walking the extra byte: A lifecycle model for linked open data

157

How to publish Open Data on the Web

174

How to use LODRefine?

182

Semantiek en Linked Data

192

How to: Linking resources from two datasets

201

How to use AllegroGraph to work with Linked Open Data

BigData4Apps: Van Linked (Open Big) Data naar Contextualized Little Data

218

Linked Open Data en Linked Enterprise Data: vervagende grenzen in de â&#x20AC;&#x2DC;extended enterpriseâ&#x20AC;&#x2122;

224

Technical Considerations: Verdieping van inhoudelijke uitdagingen rond Linked Open Data

Aanzet tot een nationale URI-Strategie voor Linked Data van de Nederlandse overheid

240

The suitability of formats for Linked Open Data

253

Accessing data with HTTP, URIs and links

264

Een nieuwe wereld, een nieuwe informatiearchitectuur

273

Het contextdilemma hanteren met Linked Data

284

Ontwerp van consistente domein-ontologie hergebruik van bestaande sectorafspraken

291

INSPIRE and Linked Data

304

From Geo-Data to Linked Data: Automated Transformation from GML to RDF

Mapping Statistical Linked Data: A Tutorial on Combining Linked Open Data and Tabular Data in R

324

D10

Pragmatism versus formalism: the relation between Linked Open Data, semantics and ontologies

337

211

311

Interviews Samenwerking cruciaal voor Linked Open Data

345

Tijd is rijp voor Linked Open Data

347

Slimmer (her)gebruiken met linked data

350

Linken van data is complex maar leerzaam proces

353

Alfabetische lijst van auteurs

356

Voorwoord Dit boek in uw hand is een heruitgave van het gelijknamige boek gepubliceerd en uitgereikt op het slotcongres van de Pilot Linked Open Data in juni 2013. Deze pilot is inmiddels gecontinueerd in ‘PiLOD’ (Platform implementatie Linked Open Data), waarin vele organisaties waaronder DEN participeren.

Het initiatief voor deze herdruk komt vanuit het project Ergoed & Locatie van DEN. Dit project intensiveert de samenwerking en standaardisatie op het gebied van ‘digitaal erfgoed met een geografische component’. Het project vormt een netwerk met betrouwbare kennispartners, zoals de Rijksdienst voor het Cultureel Erfgoed, stichting Bibliotheek.nl en Waag Society. Linked (Open) Data is in onze visie voor het erfgoedveld bijzonder belangrijk de komende periode. Naast het bestaande internet-of-

PiLOD

Digitaal Erfgoed Nederland bevordert en bewaakt de kwaliteit van digitalisering en digitale dienstverlening door de erfgoedsector (archieven, musea, erfgoedbibliotheken, audiovisuele, archeologische en bouwhistorische instellingen). DEN investeert in kennisontwikkeling op het gebied van open ICTstandaarden en andere kwaliteitsprincipes voor duurzame digitalisering en interoperabiliteit. www.den.nl

PiLOD staat voor “Platform implementatie Linked Open Data (PiLOD)”. Het platform vormt het hart van een levendige LOD community die kennis en ervaring rond het maken, beheren en toepassen van Linked Open Data deelt. Door de (technisch) inhoudelijke kennis in te zetten in bestaande toepassingscases levert het platform een innovatieve bijdrage aan toepassingen met Linked Open Data in Nederland. www.pilod.nl

documents zal er een internet-ofdata ontstaan. Instellingen voor cultureel erfgoed kunnen daarmee veel voordelen behalen. Zo zal de semantische interoperabiliteit en duurzame beschikbaarstelling door middel van LOD-technieken ongetwijfeld leiden tot een nieuw en uitgebreider gebruik van de digitale erfgoedcollecties en onverwachte mogelijkheden voor dienstverlening. Dit is voor DEN Erfgoed & Locatie dan ook de reden om in PiLOD te participeren en deze heruitgave mede mogelijk te maken. De hoeveelheid kennis, contacten en technieken die aanwezig zijn bij PiLOD helpt DEN om de LOD kennis naar het cultureel erfgoedveld over te brengen en innovatie daarvan te stimuleren.

PiLOD is een unieke open samenwerking in Nederland op het gebied van Linked Open Data, waarin u ook van harte welkom bent om in mee te participeren! De bijdrages in deze uitgave vormen slechts een klein overzicht van alle kennis en kunde die in de PiLOD-community aanwezig is, maar blijven een mooi startpunt om meer kennis te vergaren over LOD. Waar in de oorspronkelijke uitgave er sprake was van twee delen, zijn deze nu gecombineerd. We wensen u veel leesplezier met deze heruitgave.

Erwin Folmer Trekker PiLOD (Geonovum/TNO)

Ralph Stuyver Projectmanager Erfgoed & Locatie (DEN)

Pilot Linked Open Data Nederland Deel 1 - Het Managementoverzicht

Voorwoord Dit boek is een resultaat van de Pilot Linked Open Data Nederland. Ik heb deze pilot mogen leiden en dat was een groot genot. Enerzijds omdat het onderwerp Linked Open Data uitermate boeiend is en een enorme potentie heeft. Maar bovenal door de grote groep enthousiastelingen die gewoon aan de slag gingen en de pilot tot een succes hebben gemaakt. Het grootste succes is misschien wel het opbouwen van het netwerk (de community), de nieuwe contacten die zijn opgedaan, en de enorme hoeveelheid kennisuitwisseling die heeft plaatsgevonden. Dit boek is, ondanks de enorme rijkheid aan kennis, slechts een kleine neerslag van de kennisuitwisseling die heeft plaatsgevonden, en hopelijk blijft plaatsvinden. Ondanks dat de pilot een echte community activiteit is geweest, wil ik toch een paar personen bedanken. Ik begin met Marcel Reuvers, de aanstichter; zonder hem was deze pilot er niet geweest! Uiteraard alle stuurgroepleden, en de ‘founding’ organisaties. Daarnaast alle trekkers die hard gewerkt hebben aan deelonderwerpen: Paul Geurts, Paul Francissen, Wilko Quak en

Arjen Santema. De organisaties die de ruimtes beschikbaar hebben gesteld (Belastingdienst, Brandweer Amsterdam-Amstelland, Gemeente Nijmegen, Geonovum, Kadaster, Rijksdienst voor het Cultureel Erfgoed, TNO), en alle presentatoren tijdens de bijeenkomsten, met daarbij een bijzonder woord van dank aan Frank van Harmelen voor het inspireren en ook beschikbaar stellen van VUonderzoekers. Christophe Guéret dank voor het delen van je enorme hoeveelheid kennis en kunde, en het geven van cursussen, wat ook geldt voor Paul Hermans en Lieke Verhelst. En dan nog eenieder die demonstrators gebouwd heeft, data heeft omgezet, servers in de lucht heeft gebracht, met daarbij een bijzonder compliment aan Marcel van Mackelenbergh voor zijn enthousiasme en inbreng. En tot slot dank aan alle deelnemers in de pilot. Alle namen staan achterin dit boek. Ik hoop dat dit project, het prachtige onderwerp Linked Open Data, èn de energie in de community, jullie verder inspireert en energie geeft om verder door te pakken en te blijven innoveren!

Erwin Folmer (Geonovum) Projectleider Pilot Linked Open Data Nederland

Introductie Pilot Linked Open Data

Introductie Pilot Linked Open Data Auteur

Erwin Folmer (Geonovum) Dit hoofdstuk beschrijft de Pilot Linked Open Data, vanaf de oorsprong, naar de uitvoering, de resultaten en het leven na de pilot. De oorsprong van de pilot Een grote groep partijen onderschrijft in 2012 het belang om onderzoek te doen naar de mogelijkheden om aan elkaar gerelateerde informatie uit verschillende overheidsregistraties uniform te ontsluiten op het web als open, dus vrij beschikbare, data. Het oorspronkelijke doel van de Pilot Linked Open Data (LOD) was om met een integrale aanpak, startend met data preparatie, het linken van data, tot aan de toepassing ervan, aan het werk te gaan en om al doende op basis van praktijkervaring inzicht te krijgen in de mogelijkheden en wensen. De verkregen inzichten kunnen vervolgens leiden tot algemene afspraken en afgesproken standaarden voor ontsluiting van open data op het web.

Open Data kent vele facetten. De scope van de Pilot lag echter op het linken van Open Data dat veelal gezien wordt als de vervolgstap nĂĄ het beschikbaar stellen van Open Data. Buiten de scope van deze pilot vielen de facetten rondom de juridische kant van Open Data. Het plan voor de Pilot is geĂŻnitieerd door de observatie dat op meerdere plaatsen Open Data gepubliceerd wordt maar dat er een gemis is aan een gemeenschappelijk referentiekader voor de ontsluiting ervan. Dit gemis is voelbaar aan de technische kant van standaarden, met als direct gevolg dat vanuit de overheid verschillende formaten worden gebruikt. Dit limiteert het gemeenschappelijk gebruik van Open Data. De Open Data van de overheid worden als afzonderlijke siloâ&#x20AC;&#x2122;s ontsloten en links tussen overheidsverzamelingen en verzamelingen op het web kunnen niet worden gelegd, terwijl deze wel aanwezig zijn. Daarnaast leidt het ontbreken van dit gemeenschappelijke referentiekader tot drempelvrees voor overheden om tot publicatie van Open Data te komen.

Het concept Linked Data biedt veel potentie en stond daarmee centraal in de pilot. Daarbij zijn drie gezichtspunten gekozen in de pilot. Allereerst de kant van toepassingen, want daar draait het natuurlijk allemaal om. Wat zijn potentiële toepassingen die het nut van Linked Data inzichtelijk kunnen maken? Ten tweede, om die toepassingen mogelijk te maken is er een ‘aanbod’ nodig aan Linked Open Data. Het derde gezichtspunt betreft ‘techniek’. Om te komen tot toepassingen en aanbod van Linked Open Data is het noodzakelijk dat er ‘technische’ kennis wordt opgedaan en gedeeld; niet vanuit de premisse dat één gedeelde technische oplossing een noodzakelijke voorwaarde is, maar juist om de ontkoppeling van Linked Open Data met techniek te stimuleren.

De uitvoering van de pilot De uitvoering van de pilot lag nadrukkelijk bij de deelnemende partijen uit zowel de wetenschappelijke, publieke als private sector. Het was een pilot die voor iedereen was opengesteld voor deelname. Een bijzondere vermelding verdienen de partijen: Geonovum, Kadaster, Ministerie van Infrastructuur en Milieu, Forum Standaardisatie, KING, GeoBusiness Nederland, Interprovinciaal Overleg, Programma Stelsel van Basisregistraties, Gemeente

Amersfoort en de Gemeente Nijmegen. Deze partijen vormden de stuurgroep en zorgden voor de financiën, beslissingen, en data en waren daarmee de katalysator van het proces. De andere deelnemers van de Pilot Linked Open Data deden kosteloos mee en stelden uren van zichzelf of van de organisatie ter beschikking. Gedurende de pilot konden deelnemers aanhaken. Elke deelname was welkom, waarbij sommige deelnemers betrokkenheid toonden door aan een activiteit deel te nemen en te produceren, en anderen zich vooral tot doel stelden om inzicht te verkrijgen in Linked Open Data, dan wel om juist als kennispartner te fungeren. In september 2012 was het project uit de startblokken gevlogen met een inspirerende bijeenkomst te Amersfoort. Meer dan 100 aanwezigen hebben zich in verschillende groepjes verdeeld om verder te werken aan de drie genoemde gezichtspunten. Dat betekende het startschot van een levendige community voor dit onderwerp. Deze community is vaak bij elkaar gekomen, zoals tijdens de zestal plenaire bijeenkomsten (ook gehouden bij de deelnemers: Belastingdienst, TNO, Gemeente Nijmegen, Kadaster, Brandweer Amsterdam-Amstelland), tijdens de vele onderwerp-specifieke bijeenkomsten, maar tevens bij de

Conceptual Fridays @ Geonovum. Daarnaast waren de leden ook actief op LinkedIn (LOD Nederland). We mochten daarbij ook rekenen op de steun van Vrije Universiteit die op basis van vouchers drie onderzoekers beschikbaar stelde. De resultaten van de pilot zijn ook internationaal uitgedragen: onder andere bij Google London tijdens de Open Data on the Web workshop van het W3C, en op het European Data Forum te Dublin.

Wat heeft de pilot opgeleverd? Vanuit het gezichtspunt van de toepassingen is snel een keuze gemaakt voor twee specifieke toepassingen: ‘Monumenten’ en ‘Huiskluis’. De groep rond Monumenten, onder aanvoering van de Gemeente Nijmegen, hield zich niet alleen bezig met de ontwikkeling van een demo app op basis van data omtrent monumenten, maar ook met het delen van ervaringen rond de kloof tussen het aanbod van Linked Open Data en de mogelijkheid tot het gebruik ervan in nuttige apps. De tweede toepassing betrof de ‘Huiskluis’; een toepassing die eenvoudig uit te leggen is als een centrale plek om informatie over een huis te presenteren. Zou het niet prettig zijn als je in één oogopslag alle gegevens van je huis kan inzien? Op basis van Linked Data kan je eindeloos informatie blijven toevoegen aan de huiskluis. Vanuit het gezichtspunt van het

aanbod is door een groep gewerkt om datasets als Linked Open Data beschikbaar te stellen voor de demo toepassingen. Daarnaast is er gewerkt aan een architectuur voor het aanbieden van Linked Open Data. Tot slot de technische groep: deze heeft zich beziggehouden met een verscheidenheid aan technische uitdagingen hoe datasets ontsloten en toegepast kunnen worden. Veel van deze resultaten zijn ook terecht gekomen in het boek over deze pilot. In hoofdstuk 5 van dit eerste deel kunt u de samenvattingen hiervan lezen, terwijl in deel 2 (of via Internet) de volledige tekstbijdrages beschikbaar zijn. En dat sluit dan ook aan bij misschien wel het belangrijkste resultaat van de Pilot Linked Open Data: de kennisuitwisseling. De energie die vloeide tijdens, en gedurende deze productie voortvloeit uit, deze kennisuitwisseling was en is een fantastisch resultaat. Dat begon al met de inspirerende sprekers tijdens de bijeenkomsten. Gedenkwaardig waren de cursussen die gegeven werden door de experts tijdens de bijeenkomst bij de Belastingdienst.

Vanuit de pilot zijn interviews afgenomen, en deze zijn gepubliceerd in nieuwsbrieven over de pilot. Ook deze zijn opgenomen in deel 2: Interview 1 Joop Vanderheiden en Bart Broex van de Rijksdienst voor het Cultureel Erfgoed Interview 2 Frank van Harmelen van de Vrije Universiteit

Interview 3 Hayo Schreijer van het Kennis- en exploitatiecentrum voor OfficiĂŤle Overheids Publicaties (KOOP) Interview 4 Willem Melder van het Nederlands Instituut voor Beeld en Geluid

De resultaten uit de pilot zijn aangevuld met bijdrages van buiten de pilot. Samen vormen ze een inhoudelijk rijk en inspirerend boekwerk op het gebied van Linked Open Data: het eerste in zijn soort in Nederland. We zien het dan ook als een mooi sluitstuk om dit werk uit te delen op de laatste kennisdelingsactiviteit van deze pilot: het slotevenement op 3 juli bij de Rijksdienst voor het Cultureel Erfgoed in Amersfoort.

Is er leven na de pilot? Jazeker. Deze pilot was een startschot en dat betekent dat er nog vele stappen gezet moeten worden voordat Linked Open Data breed toegepast gaat worden. Maar het was wel een noodzakelijk startschot. Nu is het tijd dat er doorgepakt wordt, want de potentie van Linked Open Data is glashelder. De community is deze uitdaging aangegaan, en pakt het nu verder op. Dus u hoort nog van ons!â&#x20AC;&#x192;

Data, Data, Data: Big, Linked & Open

Data, Data, Data: Big, Linked & Open Auteurs

Erwin Folmer (Geonovum) Dennis Krukkert (TNO) Silja Eckartz (TNO) De gehele business en IT-wereld praat op dit moment over Big Data, een trend die medio 2013 Cloud Computing is gepasseerd (op basis van Google Trends). Ook beleidsmakers houden zich actief bezig met Big Data. Neelie Kroes, vice-president van de Europese Commissie, spreekt over de ‘Big Data Revolution’ en de verandering naar een ‘Data-driven Economy’, waarbij data als de nieuwe olie worden beschouwd die tientallen miljarden euro’s waard zijn. [1] Deze Big Data Revolutie wordt ook uitmuntend beschreven in het boek ‘De Big Data Revolutie’, waarin big data wordt beschreven als bron van economische waarde en innovatie: ‘Gegevens kunnen op een slimme manier worden hergebruikt en zo uitgroeien tot een rijke bron van innovaties en nieuwe diensten’. Een aspect daarbij is de gigantische toename van data en

de noodzakelijke machines, maar de echte revolutie zit in de gegevens zelf en de gebruikswijze. [2] De bedrijvigheid en innovatieve aspecten worden breed gedragen, en in een overheidscontext vaak ook gerelateerd aan Open Data in het publieke domein. Zoals Kroes het heeft over ‘Unlocking this gold mine’ en ‘Opening up public data means opening up business opportunities’. Maar ondanks de stevige uitspraken van Kroes is Europa geen koploper. In mei 2013 heeft Obama een nieuwe wet voor Open Data ondertekend: ‘And today I’m announcing that we’re making even more government data available, and we’re making it easier for people to find and to use. And that’s going to help launch more start-ups. It’s going to help launch more businesses… It’s going to help more entrepreneurs come up with products and services that we haven’t even imagined yet. This kind of innovation and ingenuity has the potential to transform the way we do almost everything.’ Daarbij gaat Obama verder dan alleen het open publiceren: een open licentie, machine readable, en in een open formaat. Daarnaast zal de data gecombineerd

en gerelateerd moeten worden voor toepassingen. [3] Ook het OECD heeft een rapport [4] gepubliceerd over Big Data, of eigenlijk de economische mogelijkheden van de nieuwe data society. Daarin wordt een vijftal toepassingen of trends beschreven: ll Data-driven R&D: verbetering in onderzoek door data toepassing ll Data(-intensive) products: het ontwikkelen van nieuwe producten/diensten waarin data het product is (of component) ll Data-driven processes: optimaliseren van productieprocessen ll Data-driven marketing: meer gerichte advertenties en gepersonaliseerde aanbevelingen ll Data-driven organisation: ontwikkelen van nieuwe benaderingen voor het management in organisaties Maar is dit nu Big Data? De terminologie in ICT is al jaren een hot issue; termen en trends met spannende afkortingen zoals een SOA, volgen elkaar in rap tempo op. Zoals gezegd in 2013 is Big Data booming. Linked Open Data is een term die al een lange geschiedenis heeft en al jaren relatief stabiel is, maar het is sterk gerelateerd aan de trend Big Data, en uiteraard ook aan Open Data.

In het kort samengevat gaat Big Data over de slimme toepassing van data in alle soorten en maten die tot op heden nog niet mogelijk waren. Eigenlijk is de term ‘big’ dus misleidend. We hadden het beter gewoon ‘Data, Data, Data’ kunnen noemen zoals in de Roadmap ICT; dat dekt beter de lading. [5] Regelmatig worden ook andere termen geïntroduceerd om de lading beter te dekken. Zoals Small Data [6], Long Data [7] of Smart Data [8], en voor specifieke toepassingsdomeinen zoals Linked Enterprise Data. Maar het gaat om data, data, data.

De viewpoints op ‘Data, Data, Data’ Er zijn vele ‘viewpoints’ mogelijk op ‘data’, maar de drie belangrijkste zijn toch wel Big, Open en Linked; deze overlappen elkaar ook. Op de volgende pagina’s worden de viewpoints nader beschreven. De drie viewpoints hebben overlap, en waar ze elkaar overlappen wordt het vaak interessant. Vaak gaan initiatieven van Linked Data over vrij beschikbare (open) data, en spelen issues gerelateerd aan het Big viewpoint ook een rol.

19 19

Linked Data Big Data

Open Data

Big Data De benaming ‘Big’ Data view mag enigszins verwarrend overkomen, want in de vorige paragraaf lieten we zien dat de hype Big Data, niet heel specifiek over ‘Big’ gaat. Echter binnen de ruime hype term (die wij liever data, data, data noemen) is er zeker wel een onderwerp dat specifiek over ‘Big’ gaat. Meestal worden dan de drie V’s (volume, velocity, en variety) gebruikt om aan te tonen dat het ‘Big’ is, ook al zijn er geen eisen aan bijvoorbeeld het Volume gedefinieerd voordat we over ‘Big’ zouden moeten praten. Maar als je aan een informaticus vraagt wat Big Data is dan komt hij met een krapper, technischer antwoord: Big data bestaat uit datasets die te groot zijn om met reguliere databasemanagementsystemen te onderhouden. Denk hier bijvoorbeeld aan sensor data of data streams.

Hier wordt ook de term NoSQL voor gebruikt om uit te drukken dat het om ongestructureerde data in schemaloze databases gaat. Voor een informaticus spelen dan ook data mining en data analytics een heel belangrijke rol voor big data. Verschillende open source softwaremodellen ondersteunen data-intensieve gedistribueerde applicaties. Een voorbeeld is MapReduce, een raamwerk voor het verwerken van problemen over enorme datasets met behulp van een groot aantal computers (nodes), ook cluster of grid genoemd. Een populaire vrije implementatie is Apache Hadoop. Hierbij gaat het ook over process hosting: waar worden de data-analyseprocessen uitgevoerd (bijvoorbeeld Amazon EC2)? En waar staat de data (cloud computing, distributed hosting (bijvoorbeeld Amazon S3)?

20 20

Big Data

Open Data ‘Open’ Data zijn datasets die met een open licentie beschikbaar worden gesteld zodat toegang en hergebruik zonder beperkingen mogelijk is. De voorwaarden waaronder de data beschikbaar zijn, worden beschreven in licenties en gebruiksvoorwaarden. Het idee van open data is om de beperkingen in hergebruik tot een minimum te limiteren. Hierdoor wordt het delen en hergebruik van data bevordert. Vaak wordt data van de overheid op deze manier gedeeld om transparantie te vergroten en economische activiteit te bevorderen. Verder geeft open data derde partijen de kans om met data te innoveren. Veelal wordt ook onder open data verstaan dat data (indien relevant) ‘machine readable’ moet zijn en in een open formaat beschikbaar moet worden gesteld. In principe kunnen tekstdocumenten ook geprint worden, gescand worden en in jpg als open data beschikbaar worden gesteld. Het doel van open data, hergebruik, wordt dan wel lastig. Hetzelfde geldt voor data die beschikbaar worden gesteld

Open Data in een gesloten formaat dat alleen met dure software is in te lezen; ook dat belemmert het hergebruik. Vandaar: open licentie, machine readable, en open formaat. Tot slot wordt regelmatig vergeten dat onderhoud, kwaliteit en governance op de open data ook belangrijke aspecten zijn. Datasets kunnen snel verouderen, dus alleen eenmalig op Internet zetten is niet voldoende. Wat is de kwaliteit, en wie bepaalt welke correcties wanneer doorgevoerd gaan worden?

21 21

Linked Data

Linked Data ‘Linked’ Data is een essentieel onderdeel van het Semantische Web. Door Tim Berners-Lee in 2006 al beschreven als een component van ‘Web 3.0’, een trend waarbij Internettoepassingen goed op elkaar afgestemd en soms zelf geïntegreerd kunnen worden. De ontwikkeling van het Internet wordt dan als volgt beschreven: van het web van documenten (Web 1.0) via Web 2.0 waar het Internet als interactief communicatiemedium beschouwd wordt en gebruikers informatie kunnen uploaden naar Web 3.0: het web van Linked Data, waar Internettoepassingen en data bijvoorbeeld via webservices aan elkaar gelinkt kunnen worden. Deze slimme toepassingen kunnen dan de links volgen tussen datasets. Dit is de basis van het semantic web. Linked Data, Semantic Web, Web 3.0 worden weleens als synoniemen gebruikt, alhoewel specifiek Linked Data gebruikt wordt als term voor een methode voor het publiceren van data in een structuur zodat het linkbaar wordt en daarmee bruikbaar.

Linked Open Data Linked Open Data is een praktische manier om een bijdrage te leveren aan het Semantische Web. Semantisch wil zoveel zeggen als ‘de betekenis lerend’. Het semantisch web zou je grofweg kunnen definiëren als een web van verbanden. Verbanden gelegd tussen informatie op het internet, waardoor nieuwe inzichten kunnen ontstaan. Informatie gepubliceerd als Linked Open Data stimuleert het hergebruik van je data, omdat je zelf zoveel mogelijk verwijzingen aanbrengt naar kennisbronnen elders en omdat anderen gemakkelijk naar jouw informatie kunnen verwijzen.

Als je in een willekeurige webbrowser naar ‘s Gravenhage zoekt, vind je geen resultaten waarin ‘Den Haag’ voorkomt, terwijl beide woorden naar dezelfde stad verwijzen. Dat komt doordat webdocumenten met elkaar verlinkt zijn, maar de inhoud zelf niet. Een zoekmachine kan zo alleen maar op woorden zoeken. Linked Data biedt een oplossing voor dit probleem door woorden als concepten uniek te maken en te beschrijven in één of liefst meerdere subject – predicaat – objectrelaties. Een stad wordt daarmee een concept en kan meerdere attributen krijgen, waarvan elk attribuut ook weer een eigen concept is. Zowel subject, als predicaat en object zijn dus op zichzelf weer unieke concepten. Elk concept wint aan betekenis naarmate er meer beschrijvingen aan gelinkt worden. Op deze manier wordt de inhoud

23 23

van webdocumenten betekenisvol en worden zoekresultaten nauwkeuriger. Uiteindelijk bereik je zo taalonafhankelijkheid omdat het dus niet meer uitmaakt of je naar ‘The Hague’ of ‘Den Haag’ zoekt. Zoals gezegd staat ‘Linked Data’ voor het idee dat informatie (resources) op het web aan elkaar gelinkt wordt zodat je informatie maar één keer hoeft te beschrijven, en er vervolgens vanuit verschillende bronnen naar kunt verwijzen. Open data gaat over het ontsluiten van data op een zodanige manier dat eenieder die data kan gebruiken zonder vast te zitten aan licenties die het gebruiksrecht beperken. Als we beide combineren dan komen we op Linked Open Data, oftewel: data die via het web op een open manier aangeboden wordt, en die onderling verbonden is.

Het belang van Linked Data Om nauwkeurig te kunnen zoeken in de enorme hoeveelheid informatie op het web is zoeken op basis van betekenis onontkoombaar. Het semantisch web is een verzamelnaam voor technieken die computers in staat stellen de betekenis van de informatie op het web te begrijpen zónder menselijke tussenkomst. Een complicerende factor hierbij is dat de betekenis van mensen, dingen, gebeurtenissen etc. niet constant is, maar kan variëren. Zo heeft de koningin van Nederland een wisselende betekenis die o.a. afhankelijk is van de tijd: in 2010 verwijst het begrip naar Beatrix, maar in 1970 was het Juliana, en in 2013 naar Willem-Alexander. Menselijke informatieverwerkers zijn gewend om contextuele factoren, zoals tijd, mee te nemen bij het toekennen

van betekenis. Voor machines geldt dit niet. Om computers toch in staat te stellen de juiste betekenis toe te kennen, is het aanbieden van relevante context van groot belang. Linked Data is een techniek om machine-leesbare context te genereren. We sluiten deze paragraaf af met een quote uit het OECD-rapport: ‘The linking and use of data across sectors drive innovation, socioeconomic development and growth.’ [4]

Linked Open Data concepten Om data op een betekenisvolle manier aan elkaar te linken wordt gebruik gemaakt van ‘semantic web’ technologie. Dit is een verzamelnaam voor verschillende standaarden en technologieën die gebruikt kunnen worden om te komen tot een web van ‘Linked Open Data’ die op een betekenisvolle manier gebruikt (en door computers geïnterpreteerd) kan worden.

De basis voor het semantic web is RDF (Resource Description Framework). Een resource kan van alles zijn: een persoon (bijvoorbeeld Erwin, een auteur van dit hoofdstuk), een organisatie (Geonovum, een werkgever van Erwin), een boek (bijvoorbeeld dit boek), een artikel, etc. Elke resource heeft een unieke URI in de vorm van een URL. Op de locatie van deze URL wordt een representatie van de resource aangeboden. Het linken van data gaat via zogenaamde ‘triples’. Een triple is een getypeerde relatie tussen twee resources, en bestaat uit een subject, een predicate en een object. Hiermee kun je bijvoorbeeld uitdrukken Erwin (subject) werkt voor (predicate) Geonovum (object). Erwin en Geonovum zijn beide resources waarnaar verwezen wordt middels een URI. Van het boek Pilot Linked Open Data kan ook een resource gemaakt worden. Het is nu heel eenvoudig om aan te geven wie de auteur van dit boek is door een triple toe te voegen: Pilot Linked Open Data (subject) is geschreven door (predicate) Erwin (object). Omdat elke keer verwezen wordt naar dezelfde resource hoeft deze maar één keer beschreven te worden.

Het hergebruik van data wordt pas echt waardevol door niet alleen data te linken, maar door ook betekenis toe te voegen aan de link. Oftewel: door expliciet vast te leggen wat de relatie (de ‘predicate’) ‘werkt voor’ betekent. Ook hiervoor wordt de hetzelfde mechanisme gebruikt: de relatie wordt beschreven in RDF-formaat, en ontsloten via een URI. In aanvulling op RDF kan RDFS gebruikt worden. Met behulp van RDFS kunnen ‘klassen’ van resources aangemaakt worden, en tevens beperkingen gelegd worden op de verschillende relaties die mogelijk zijn tussen instanties van deze klassen. Hiermee zou je bijvoorbeeld vast kunnen leggen dat de relatie (lees: predicate) ‘is getrouwd met’ alleen gelegd kan worden tussen twee resources van het type ‘persoon’. Gelukkig hoeven we het wiel niet opnieuw uit te vinden. Er zijn al veel standaard definities beschikbaar van resource- en relatietypes. Deze zijn vastgelegd in zogenaamde ontologieën. Een ontologie is, eenvoudig gesteld, een neerslag van concepten en hun onderlinge verbanden die door een groep betrokkenen gezien wordt als representatie van hun gedeelde werkelijkheid. Afhankelijk van de toepassing kan een ontologie daarmee de vorm krijgen van bijvoorbeeld een definitielijst, een

RDF-graph, een UML-model, een taxonomie, een zuiver logisch model en vele andere. Voorbeelden van veelgebruikte ontologieën zijn SKOS (Simple Knowledge Organization System) voor het opstellen van vocabulaires en thesauri, en FOAF (Friend-of-a-friend). SKOS bevat zaken als ‘broader’, ‘narrower’ en ‘alternative label’. FOAF bevat zaken als ‘Person’ en ‘email’. RDF beschrijft het algemene principe achter triples, en schrijft bijvoorbeeld het gebruik van URI’s voor. Het technische formaat (de syntax) waarin triples worden vastgelegd en uitgewisseld wordt echter vrijgelaten. Hiervoor zijn verschillende technische formaten beschikbaar zoals RDF/ XML, Turtle, N3 en JSON. Met elk van deze formaten kunnen triples vastgelegd worden. De formaten verschillen enerzijds in syntax, en anderzijds in een aantal toevoegingen bovenop RDF. Triples kunnen ook opgeslagen worden in een database, ook wel ‘triple store’ genoemd. Om een triple store te bevragen is een speciale taal ontwikkeld (analoog aan SQL voor relationele database): SPARQL (SPARQL Protocol and RDF Query Language).

De vier principes van Linked Open Data 26

Linked Data moet aan vier principes (vrij naar Tim Berners Lee) voldoen [11]. Deze principes zijn:

Principe 1

Principe 2

Gebruik URI’s om dingen te identificeren.

Gebruik HTTP-URI’s zodat er naar deze dingen kan worden verwezen en dat ze kunnen worden opgezocht door zowel mensen als machines.

Principe 3

Principe 4

Leg de informatie over het concept vast in een ‘triple’ (subject-predicaatobjectrelatie), leg die triple vast en maak het beschikbaar op basis van standaarden zoals RDF en SPARQL.

Neem links naar andere, gerelateerde, opendataconcepten op in de beschrijving om het ontdekken van gerelateerde informatie op het web te verbeteren.

Een URI betekent in feite het toekennen van een unieke string om data-objecten uniek identificeerbaar te maken. Door middel van HTTPURI’s wordt er verwezen naar een

unieke plek op het internet waardoor informatie over het object vindbaar wordt. Linked Open Data zijn datasets in RDF-formaat, met URI’s en met links tussen de datasets.

De weg naar Linked Open Data: het vijfsterrenmodel Organisaties zullen vaak niet direct met Linked Open Data beginnen. Vaak worden er verschillende stappen gezet voordat men kan spreken over Linked Open Data. De eerste stappen betreffen veelal puur het open maken van Data. Dit heeft Tim Berners-Lee verwerkt in het vijfsterrenmodel van Linked Open Data [12]. De vijf sterren in dit model zijn hieronder beschreven.

27 27

De eerste drie sterren betreffen open data, en pas bij de laatste twee sterren spreken we van Linked Open Data. In 2013 maken leiders zoals Kroes en Obama duidelijk een beleid gericht op drie sterren, terwijl in het verleden ĂŠĂŠn ster veelal voldoende was. Als die lijn zich doorzet, zitten we binnen een paar jaar op vijf sterren (overheids)data!

De informatie is beschikbaar op het internet, in welk formaat dan ook. De informatie is online beschikbaar in een gestructureerd formaat, dat geschikt is voor automatisch hergebruik (zoals Excel in plaats van een plaatje van een tabel). De informatie is online beschikbaar in een open bestandsformaat (zoals CSV in plaats van Excel). Al het bovenstaande, en bovendien wordt gebruikgemaakt van de open standaarden Resource Description Framework (RDF) en SPARQL, zodat anderen makkelijk naar de dataobjecten kunnen verwijzen. Al het bovenstaande, en bovendien wordt er naar data van anderen verwezen voor meer context van de data.

Referenties [1] Statements Kroes: http://bit.ly/19bpC0q

[5] Roadmap ICT: http://bit.ly/ShQGEd

[2] Boek Big Data: Viktor Mayer-Schönberger & Kenneth Cukier (2013), De Big Data Revolutie, Hoe de data-explosie al onze vragen gaat beantwoorden, Maven Publishing.

[6] Small Data: http://bit.ly/17Q3Z88

[7] Long Data: http://bit.ly/Wd9FCK

[3] Statements Obama: http://bit.ly/197zCG2 [8] Smart Data: http://bit.ly/ZUgNoV http://1.usa.gov/15NKxby

[4] OECD rapport: OECD (2013), ‘Exploring DataDriven Innovation as a New Source of Growth: Mapping the Policy Issues Raised by ‘Big Data’’, OECD Digital Economy Papers, No. 222, OECD Publishing. http://bit.ly/14DIB2E

[9] Boek Linked Data: Tom Heath & Christian Bizer (2011), Linked Data, Evolving the Web into a Global Data Space, Morgan & Claypool Publishers. http://bit.ly/13Qsz2W

[10] Boek Linked Open Data: Florian Bauer & Martin KaltenbĂśck (Semantic Web Company) Linked Open Data: The Essentials - A Quick Start Guide for Decision Makers. De eerste drie hoofdstukken uit dit boek zijn opgenomen in deel 2. Het volledige boek is beschikbaar als PDF op http://bit.ly/AC4EIZ [11] Vier principes van Linked Open Data: http://bit.ly/FQVNV

[12] Het vijfsterrenmodel: http:// www.5stardata.info â&#x20AC;&#x192;

Linked Open Data in Nederland: een snelgroeiend gewas in vruchtbare bodem

Linked Open Data in Nederland: een snelgroeiend gewas in vruchtbare bodem Auteur

Frank van Harmelen (Netwerk Instituut, Vrije Universiteit Amsterdam) Deze bundel is in zekere zin een mijlpaal. Er zijn al talloze internationale publicaties verschenen over Linked Open Data maar er is geen enkele die zo uitgebreid verschillende aspecten van Linked Open Data behandelt, variĂŤrend van technische principes en praktische toepassingen tot maatschappelijke en zelfs filosofische beschouwingen.

In deze korte beschouwing geef ik een kort synthetisch overzicht van de inhoud van deel 2 van dit boek. Dat overzicht leidt tot een aantal conclusies over de stand van Linked Open Data in Nederland, en die conclusies zijn voornamelijk optimistisch van aard. Tot slot probeer ik naar de korte termijn toekomst te kijken, om te bepalen welke volgende stappen nu het meest nodig zijn.

Observaties over dit boek Diversiteit in Toepassingen Het eerste dat elke lezer zal opvallen, is de grote diversiteit in de toepassingen van Linked Open Data die in dit boek besproken worden. Geurts, Brentjens en Van Aart maken informatie beschikbaar over talloze monumenten voor de gemeente Nijmegen, Francissen en Van Echtelt ontsluiten kadastrale gegevens, van Leeuwen schrijft uit eigen ervaring met zijn co-auteurs Pattje en Folmer over het nut van open data voor hulpverleningsdiensten als de brandweer, en Salters illustreert haar

betoog met behulp van bestuurlijke informatie. Het brede scala aan toepassingen wordt voortgezet door het consortium van Hamers, Van der Arend, Verhoeff, Nijstad en Van Vuuren die onderwijskundige kennis openbaar maken met Linked Open Data, met de bijdrage van Walker en Nelissen betreft productdata voor NXP, en sluit af met Vanderheiden, Hendriks en Verbeij die laten zien hoe het Nederlands cultureel erfgoed baat heeft bij het publiceren van een gemeenschappelijk vocabulaire dat vervolgens gekoppeld wordt aan diverse bronnen. Dit alles beslaat een zeer brede waaier aan informatie uit de publieke, semi-publieke sector en private sector, en laat goed zien hoe breed de impact van Linked Open Data kan zijn.

Diversiteit van samenwerkende partijen Naast de diversiteit in toepassingen is ook opvallend hoe heterogeen de teams zijn die voor deze toepassingen samenwerken. Een gemeenteambtenaar werkt samen met een hightech startup, een brandweerman werkt samen met een adviesorganisatie, onderwijskundigen en erfgoeddeskundigen werken samen met een ICT-consultant. Andere bijdragen in deze bundel komen van technologieleveranciers, van universitair onderzoekers, van het Kadaster, van medewerkers bij de landelijke overheid etc. Zo’n diversiteit van achtergronden laat zien dat Linked Open Data zich bevindt in een heel rijk ‘ecosysteem’ van partijen. En zo’n rijk ecosysteem is zeer gunstig voor de snelle absorptie van nieuwe technologie in de praktijk.

Overzicht van essentiële basistechnologieën Naast een mooie bloemlezing van Linked Open Data toepassingen, is deze bundel ook een zeer nuttig overzicht van allerlei essentiële basistechnologieën. In de delen C en D komen vrijwel alle essentiële elementen van Linked Open Data aan bod: het publiceren van legacy data (Hermans), de W3C-principes (Guéret), het ontwerpen van semantische modellen (Verhelst, en elders Stap), het aanbrengen van links tussen datasets (Guéret), het gebruik van triple-stores (Aasman en Stap), een strategie voor URI-ontwerp (Van den Brink, Overbeek en Brentjens), de keuze tussen verschillende dataformaten (Brentjens, Reuvers en Portele), de te gebruiken netwerkprotocollen (idem), een procesmodel voor het publiceren en beheren van Linked Open Data (Van den Broek, Van Veenstra en Folmer), en richtlijnen voor het publiceren van ruimtelijke data (Portele, en ook Van den Brink, Janssen en Quak) en statistische data (Van Hage). Niet onbelangrijk is dat deze bundel hiermee de eerste (deels) Nederlandstalige beschrijving is van een zo compleet arsenaal aan technologieën van Linked Open Data.

Filosofische en ideologische beschouwingen Zoals elke nieuwe, ver reikende technische vernieuwing is Linked Open Data niet alleen maar technologie. Het is een combinatie van technologie, ideologie en filosofie. Ook die filosofische aspecten komen aan bod. En dat is goed, en zelfs noodzakelijk. Behalve overeenstemming over technische specificaties voor formaten en protocollen is ook een gedeeld ‘wereldbeeld’ (of zelfs: een gedeelde filosofie, een gedeelde ideologie) noodzakelijk als grondslag voor daadwerkelijke maatschappelijke vernieuwing. Een interessant vergezicht naar de toekomst is de bijdrage van Geerdink en Verhoeven, die handelt over de gevolgen van Linked Data voor de organisatievorm van ondernemingen, leidend tot wat ze noemen de ‘extended enterprise’. De bijdrage van Van Rijn en Santema is een soortgelijke beschouwing, maar nu juist gericht op de overheid. En bijna filosofisch van aard is de bijdrage van Van Mackelenbergh en Hoekstra, die nieuw Linked Open Data licht laten schijnen over aloude informatie-filosofische vragen: is informatie te begrijpen en gebruiken zonder context? Kan informatie überhaupt hergebruikt worden in een andere context dan waarin ze gemaakt werd? En evenzo bespreekt de bijdrage van Brandt en Daniele een andere filosofische

klassieker die raakt aan de kern van Linked Open Data: de balans tussen formele correctheid en pragmatische werkbaarheid. Zoals gezegd is dit niet slechts filosofische luchtfietserij. Overeenstemming over zulke ontastbare zaken is net zo van belang als overeenstemming over concrete formaten en protocollen.

Uitdagingen voor de nabije toekomst Uit deze bundel blijken ook enkele concrete uitdagingen die in de nabije toekomst zullen moeten worden opgelost om Linked Open Data tot volle bloei te laten komen. De belangrijkste twee daarvan zijn mijns inziens: bredere kennisoverdracht, en verlaging van technische drempels. Deze bundel levert een belangrijke bijdrage aan de kennisoverdracht van de eerstelijns pioniers naar een bredere groep toekomstige gebruikers en ontwikkelaars. Maar zoals elke publicatie zal ook deze bundel slechts een beperkte reikwijdte hebben. We zullen nog hard moeten werken aan kennisoverdracht naar brede groepen in de maatschappij: ontwikkelaars, gebruikers, beleidsmaker, bij de overheid (variërend van lokaal tot provinciaal en landelijk), bij de semioverheid, en bij het bedrijfsleven,

variërend van ZZP’ers en MKB tot multinationals. Er ligt hier een duidelijke taak voor organisaties in het hoger onderwijs, maar er ligt ook een grote markt voor commerciële partijen. Zulke brede kennisoverdracht is nodig als Linked Open Data gemeengoed wil worden, op hetzelfde niveau als bijvoorbeeld databases of web-technologiedata zijn. De tweede uitdaging ligt mijns inziens in het verlagen van technische drempels. Enerzijds is het mooi om te zien dat zoveel verschillende partijen in deze bundel rapporteren over het succesvol gebruik van Linked Open Data technologie. Anderzijds betreft het hier wel de pioniers in Nederland, en is het aantal mensen dat in staat is om zulke toepassingen te bouwen in Nederland beperkt tot enkele honderden (en dat lijkt me een optimistische schatting). Met andere woorden: Open Data is nu toch nog teveel een kunst die slechts door weinigen verstaan wordt. Natuurlijk is kennisoverdracht een manier om dat aantal te vergroten, maar nog beter is het om ervoor te zorgen dat veel van die kennis niet meer nodig is, doordat de techniek beter verpakt wordt in laagdrempelige tools en applicaties. Ook op dat gebied is nog veel te winnen.

Conclusie Al met al levert deze bundel een zeer bemoedigend beeld op over de toekomst van Linked Open Data in Nederland. Ten eerste is het goed om te zien dat technologie niet langer de beperkende factor is. Er zijn, mede door de bijdragen in deze bundel, nu heldere (deels Nederlandstalige) uiteenzettingen over vrijwel alle technologische ingrediĂŤnten. En wat belangrijk is: die uiteenzettingen zijn niet geschreven door de oorspronkelijke initiators, bedenkers en uitvinders van Linked Open Data, maar juist door de eerste generatie ontwikkelaars en gebruikers ervan. En die eerste generatie pioniers, die de bijdragen aan deze bundel hebben geschreven, zijn veel beter in staat om die kennis op de juiste wijze door te geven aan de veel grotere groep gebruikers en ontwikkelaars die klaar staan om hun voorbeeld te volgen. Het is ook een goed teken dat de bundel zelfs een stuk voor beleidsmakers en beslisser bevat (de bijdrage van Bauer en KaltenbĂśck). Als er eenmaal stukken voor beleidsmakers verschijnen, is dat een teken dat het met de basistechnologie wel goed zit.

Ook bemoedigend is om te zien wat er niet in de bundel staat. Er wordt (gelukkig) maar zeer weinig geschreven over problemen bij het verzamelen van data, en ik lees dit als een signaal dat het met de beschikbaarheid van die ruwe grondstof, de data, in Nederland in orde is. Nederland is in een bijzonder goede positie vanwege het relatief goed georganiseerde datalandschap in de publieke en semipublieke sector. Dat is dan ook de reden voor de titel van deze korte beschouwing. Linked Open Data in Nederland is een snelgroeiend gewas, dat in de vruchtbare bodem van het Nederlandse datalandschap snel tot bloei kan komen. â&#x20AC;&#x192;

Artikelen Deel 2 De samenvattingen

Artikelen Deel 2 De samenvattingen We eindigen deel 1 van deze publicatie met een overzicht van alle bijdrages die in deel 2 zijn opgenomen. We hopen dat deze samenvattingen uitnodigen om het volledige paper te gaan lezen. Dat kan enerzijds door deel 2 (het boek) erbij te pakken, maar anderzijds kunt u ook de QRcode met uw mobiele telefoon inscannen en dan wordt u doorgelinkt naar de online versie.

Deel A - Linked Open Data – The Essentials

Dit deel beschrijft een algemene introductie in Linked Open Data.

A1 - Linked Open Data: The Essentials Auteurs Florian Bauer (REEEP) Martin Kaltenböck (Semantic Web Company) The publication Linked Open Data: The Essentials gives decision makers a good overview of Open Government, Open Government Data, Open Data and Linked Open Data (LOD). It highlights the potentials and benefits of LOD, providing a quick guide with the most important steps for LOD publishing, a consumption strategy for your organisation and three best practice examples of LOD in use.

The original book has been written in 2011 to support the event ‘Linking Open Data to Accelerate LowCarbon Development,’ a workshop for decision makers in clean energy organisations that was held at the Masdar Institute in Abu Dhabi in January 2012 in the course of the World Future Energy Summit, organised by the Renewable Energy and Energy Efficiency Partnership (REEEP). But since then it has been widely used as resource on Linked Open Data, especially for decision makers to understand the potentials and benefits as well as the concepts of Linked Open Data, but also by project leaders, or technical experts, that need a starting point for Linked Open Data. This reprint contains the first three chapters of the original book, and is the ideal starting point for the remainder of this publication.

Deel B - Linked Open Data – De Toepassingen

Dit deel beschrijft toepassingen en casus beschrijvingen op basis van Linked Open Data in verschillende toepassingsdomeinen.

B1 - 5 sterren toepassingen Auteurs Paul Geurts (Gemeente Nijmegen) Thijs Brentjens (Brentjens Geo-ICT) Chris van Aart (2CoolMonkeys) Bij het maken van toepassingen zijn we er in de loop van de Pilot tegenaan gelopen dat er nog een brug te slaan is tussen de aanbieders van slimme Linked Data en de app-bouwers. Waar app-bouwers graag tegen een JSON of REST service aanpraten, of de data zelf verzamelen en bewerken, heeft de wereld van Linked Data een eigen taal en logica. En die kosten wat moeite om eigen te maken. Je loopt er als app-bouwer tegenaan dat je een nieuwe semantische wereld instapt, waarin je moet investeren om hiervan kennis op te doen. Uiteindelijk krijgt het zijn meerwaarde, de link tussen data ligt in de DNA van de data in tegenstelling tot de huidige werkwijze waar de links door de appbouwer worden gelegd door de data bij elkaar te sprokkelen, dan wel door webservices aan elkaar te knopen. In de app-wereld zou je dezelfde sterrenbenadering van Linked Data kunnen toepassen als die bij de data al geïntroduceerd is.

Harvesting van Data in open data formaten App-bouwers verzamelen data en lezen dit zelf in (Harvesting). De data is in principe al verouderd na het inlezen. Data wordt meegeladen in de app. Links worden gelegd in de eigen database.

Koppelen van dataservices App-bouwers koppelen dataservices binnen de app. Voor elke dataset maakt of configureert hij schermen. Logica en vertaling wordt dus binnen de app gelegd. Data is altijd actueel. Links worden binnen de app gelegd.

Linked Data App-bouwers koppelen Linked Data Services, zijn altijd actueel, en maken slechts één scherm voor het presenteren van de data. Links liggen in het DNA van de data.

Dit artikel gaat over het toegankelijk maken van deze nieuwe semantische wereld van aanbod, via een Linked Data viewer en een Linked Data API, naar een toepassing.

B2 - De Huiskluis, Open Samenwerken met Linked Data Auteurs Paul Francissen (Envolve BV) John van Echtelt (CGI) De ‘Huiskluis’ is een praktijkcase die ontwikkeld is tijdens de landelijke Pilot Linked Open Data. De Huiskluis ‘weet alles over je huis’. Hij bevat links naar digitale informatie van overheden (basisadministraties), bedrijven en instellingen over woningen en bedrijven in Nederland. Daarnaast kunnen bewoners en eigenaren zelf informatie toevoegen aan hún Huiskluis. Daarmee creëren zij een online informatiedossier over hun eigen woning of bedrijfspand. De Huiskluis biedt bovendien de mogelijkheid om verzamelde informatie te delen met anderen; met buren, hulpverleners, winkels en anderen. Dit kan op een eenvoudige en veilige manier. Deze manier van koppelen en delen van informatie maakt vele nieuwe toepassingen mogelijk. Denk aan overheidsinformatie op maat voor elk huis of bedrijf, historisch materiaal dat gedeeld wordt met buren en archiefdiensten, of specifieke diensten rond energiegebruik, woninginrichting of hypotheekverstrekking.

Het initiatief laat zien dat informatie over elk huis of bedrijf in Nederland op maat kan worden geleverd. Dit sluit aan bij het doel van de Pilot Linked Open Data om te verkennen hoe informatie uit verschillende bronnen op het web bijeengebracht kan worden en ontsloten kan worden voor concrete toepassingen.

B3 - Branden blussen met Linked Open Data Auteurs Bart van Leeuwen (Netage) Lian Pattje (Geonovum) Erwin Folmer (Geonovum) Informatie is van cruciaal belang voor de brandweer. Beslissingen moeten in zeer korte tijd en onder hoge druk gemaakt worden. Daarbij wordt gebruik gemaakt van alle informatie die voor handen is. In het huidige tijdperk, mede in het kader van Open Data, is er zeer veel informatie over onder meer gebouwen, verkeersinformatie, chemische stoffen, etc. beschikbaar, maar die wordt niet altijd gebruikt. De nachtmerrie van een brandweerman is dat hij verkeerde, noodlottige keuzes maakt, doordat beschikbare informatie niet is meegenomen in de besluitvorming. De brandweer (in samenwerking met Netage)

is daarom volop bezig om de mogelijkheden van Linked Open Data in de praktijk te testen. Dit om beschikbare en relevante open data aan elkaar te linken, gericht op het inzetten ervan bij een calamiteit (zoals een brand). Dit paper geeft inzicht in de problematiek en de uitdagingen van een brandweerkorps, en hoe Linked Data ingezet kan worden voor betere ontsluiting van relevante databronnen.

B4 - Linked Data & semantiek: we begrijpen elkaar steeds beter Auteur Marijke Salters (Bureau Forum Standaardisatie) De Linked Data methode biedt als open methode meerwaarde voor interoperabiliteit op de semantische laag. De e-overheid heeft steeds meer behoefte aan betekenis van begrippen. Steeds meer partijen wisselen data uit, ook om te komen tot beslissingen over uitkeringen, toeslagen etc.. Voor eenduidige uitwisseling van data tussen partijen is de juiste betekenis essentieel. De centrale vraag voor dit artikel is: Is Linked Data een oplossing voor het probleem van semantische interoperabiliteit? Om deze vraag te beantwoorden wordt in dit artikel de vergelijking gemaakt tussen een woordenboek in onze fysieke wereld en het gebruik van deze methodiek. Aan de hand van twee cases, Juriconnect en de Stelselcatalogus, wordt de meerwaarde van de Linked Data methode, aangetoond. Wel worden kanttekeningen geplaatst bij de haalbaarheid op korte termijn. Bovendien is een conclusie dat verkeerd gebruik van deze methode grote gevolgen heeft.

B5 - Casus OnderwijsBegrippenKader: de basis onder Educational Linkedscape Auteurs Jeroen Hamers Jos van der Arend Leonie Verhoeff Henk Nijstad (allen Kennisnet en Bureau EduStandaard) Jeroen van Vuuren (Verdonck, Klooster en Associates) Het Onderwijs Begrippenkader (OBK) is dé gemeenschappelijke online database met alle onderwijsbegrippen en hun onderlinge relaties – te beginnen met de niveaus en het curriculum. Het OBK is ontstaan in 2012 als oplossing voor knelpunten in de Educatieve Contentketen (ECK) bij het zoeken en vinden van leermateriaal. Doel van het OBK is om er voor te zorgen dat alle informatiesystemen in het Nederlandse onderwijs dezelfde onderwijstaal spreken door middel van het uniek identificeren en definiëren van de begrippen met hun onderlinge relaties. De inhoud van het OBK is volgens de semantisch web principes opgeslagen in een RDF-store en wordt als open Linked Data beschikbaar gesteld. De RDFstore kan op meerdere manieren

worden uitgelezen: Direct uitvragen door middel van een SPARQL end point, via een specifieke API of via een specifieke webbased ‘browser’. Voor de uitbreidingen van OBK is een beheerorganisatie opgezet. Het toepassingsgebied van de uitbreidingen van de inhoud wordt in toenemende mate breder dan alleen de Educatieve Contentketen: het OBK zal als generieke voorziening voor eenduidigheid en duurzaamheid in alle onderwijssemantiek een rol gaan spelen. Het OBK wordt zodoende de basis onder alle uitwisselingen binnen het ‘Educational Linkedscape’.

B6 - Casus De erfgoedthesaurus in de kennisketen van het cultureel erfgoed Auteurs Joop Vanderheiden (RCE) Kees Hendriks (RCE) Nico Verbeij (Verdonck Klooster & Associates, VKA) De Rijksdienst voor het Cultureel Erfgoed (RCE) wil haar elektronische dienstverlening vernieuwen én de eigen openbare gegevens zoveel mogelijk ter beschikking stellen voor verrijking en hergebruik. Daarom koppelt de RCE zijn bronnen door middel van een gemeenschappelijke erfgoedthesaurus aan andere

bronnen in het erfgoedveld. Het geheel wordt voor verder gebruik als Linked Open Data beschikbaar gesteld aan private en publieke partijen. Deskundige partners in het erfgoedveld krijgen de gelegenheid mee te bouwen aan dit gemeenschappelijke erfgoed begrippenkader en kunnen met behulp hiervan hun eigen gedigitaliseerde collecties beter vindbaar maken. Leveranciers van informatieproducten (websites, apps, widgets, enz.) krijgen direct toegang tot de thesaurus en de daaraan gekoppelde informatie over allerlei erfgoedobjecten. In deze casusbeschrijving gaan de schrijvers in op de visie van RCE met betrekking tot Linked Open Data in het erfgoedveld. Vervolgens beschrijven ze de activiteiten en bevindingen tot nu toe op het terrein van de ontwikkeling van de Erfgoedthesaurus, de gekozen informatiearchitectuur, de standaarden en de datamodellering die worden gehanteerd, de ontsloten gegevensbronnen en de eerste voorbeeldapplicaties. Er is extra aandacht voor de Erfgoedsuite, een certificering van online tools die erfgoedpartijen helpen bij het bouwen en onderhouden van een eigen webpresentatie en het duurzaam opslaan van de eigen

collectiedata. Door de inzet van de erfgoedthesaurus worden deze lokale collecties verbonden en nationaal toegankelijk gemaakt. Een doorkijk naar de toekomst besluit deze bijdrage.

B7 - OpenInc, Ondernemende mensen die zich met Linked Open Data op de toekomst voorbereiden Auteurs John van Echtelt (CGI) Pieter van Everdingen Het potentieel van Linked Open Data is enorm groot. De komende jaren zal worden ontdekt welke toepassingen succesvol zijn, wat de winstgevende verdienmodellen blijken te zijn en welke maatschappelijke thema’s het meest baat hebben met het slim koppelen van gegevens. De Pilot Linked Open Data heeft ons geleerd dat het delen van kennis over organisatiegrenzen heen een hele goede manier is om maatschappelijke en economische waarde met open data te creëren. Mensen die hun kennis en talenten inzetten om te leren en om mooie nieuwe dingen (zoals de Huiskluis) te creëren.

Deze ervaring is een van de redenen waarom in Utrecht de open samenwerkingsomgeving OpenInc wordt opgezet. OpenInc is een coรถperatieve netwerkorganisatie van en voor ondernemende mensen die nieuwe toepassingen willen ontwikkelen met (Linked) open data. OpenInc is vooral bedoeld voor studenten en werkzoekenden die hun kennis en ervaring op het gebied van (Linked) open data willen verbeteren en zich klaar willen stomen voor de beroepen van de toekomst.

B8 - Linked Open Data in electronics industry Auteurs John Walker (NXP) Tim Nelissen (NXP) In the electronics industry, the ability to get accurate, timely product data in front of the customer is a very important factor in the overall business process. Furthermore, enabling the customer to easily compare and select the right product for their application from the choice of literally hundreds, or even thousands, of candidates can reduce the overall time and costs involved in the purchasing process. Opening up access to the data is a key component, whether this is to free the data from existing silos for use within the organization, or making the data available to third parties. Also to facilitate the aggregation of data from multiple parties, it is very important to agree on a common schema that can be used to describe the products and enable easy mapping between schemata. In this paper we describe the approach we have used to manage and publish the data and discuss the questions that arise from a publishers perspective.

48 Deel C - Linked Open Data â&#x20AC;&#x201C; How to

De bijdragen in dit deel zijn gericht om toepassers van Linked Open Data te ondersteunen bij het uitvoeren van bepaalde activiteiten.

C1 - Walking the extra byte: A lifecycle model for Linked Open Data Auteurs Tijs van den Broek (TNO) Anne Fleur van Veenstra (TNO) Erwin Folmer (TNO) More and more public organizations publish their data in an open format to increase transparency and foster economic activity. In this modern gold rush, organizations strive to open up as many datasets as possible, without considering the strategic importance of open data. Especially linking data to other datasets can lead to the creation of innovative services. One issue that is often not explicitly addressed before opening up data is the format of the dataset. Central to open data is that the format is machine readable. But to allow for effortless linking of datasets, data being merely machine readable is not sufficient. Lifecycle models can guide the process of

publishing Linked Open Data. Current Linked Open Data lifecycle models focus on the technical steps that need to be taken by the internal IT organization and often forget to include actions to be taken after publication. The effectiveness of Linked Open Data, however, depends on how much the data is used. Hence, this paper develops a Linked Open Data lifecycle model that takes the multiple disciplines and stakeholders within and outside the organization into account as well as the steps to be taken after publication of the datasets. First, using existing Linked Open Data lifecycle models, this paper identifies generic phases of opening up Linked Data: identification, preparation, publication, re-use and evaluation. Then, investigating the process of opening up Linked Data in a semi-public organization in the Netherlands, the lifecycle model is refined and detailed. This case study shows that the involvement of relevant stakeholders, both within and outside the organization and of various disciplines, is essential to realize the support for the process and stimulate re-use.

C2 - How to publish Open Data on the Web Auteur Christophe Guéret (DANS, VU University Amsterdam) There is an increasing interest towards publishing data open on the Web. Opening what use to be closed data brings a lots of opportunities in terms of social and economic development, participatory governance and improvement of research processes. Although the motivation is clear the publication is in practice open to a lot of different options. Even for one motivated in publishing his data online, it remains still unclear _how_ to do it. This chapter discusses the wide range of data publication approaches and pays a particular attention to the Linked Open Data publication principles advoc-ated by the W3C.

C3 - Legacy dataformaten omzetten naar RDF met behulp van LODRefine Auteur Paul Hermans (ProXML) De meeste data zijn nog niet beschikbaar als triples, wat wel gewenst is voor Linked Data. Zij zitten in tabellen, spreadsheets en zijn soms beschikbaar als XML of JSON. De vraag is hoe deze data efficiënt naar RDF-triples kunnen omgezet worden. Een mogelijke tool om hierbij te helpen is LODRefine, een gespecialiseerde versie van de initieel door Google ontwikkelde ‘messy’ data cleaning tool ‘Open Refine’. Dit artikel schetst de mogelijkheden en manier van werken.

C4 - Semantiek en Linked Data Auteur Lieke Verhelst (Linked Data Factory) De waarde van data, ook Linked Data, wordt in grote mate bepaald door de aanwezige beschrijvende informatie. Bij Linked Data is deze beschrijving vastgelegd in een semantisch model of vocabulaire. Het vastleggen van de betekenis van data door semantische modellen gaat beter dan bij tabulaire data. Dit komt doordat een semantisch model niet beperkt is, maar juist oneindig. Iedereen kan een semantisch model maken waarmee een onderwerp wordt beschreven. Soms worden daardoor onderwerpen door meerdere partijen vastgelegd. Dit is geen probleem omdat elke partij het onderwerp vanuit zijn eigen context beschrijft. In dit hoofdstuk wordt verder uitgelegd hoe je zelf een semantisch model maakt, en hoe je bestaande vocabulaires integreert in je eigen model.

C5 - How to: Linking resources from two datasets Auteur Christophe Guéret (DANS, VU University Amsterdam) The Linked Data publication principles define a way to share data while using the Web as a publication platform. Just like the Web is used to publish documents it can also be used to publish factual data. URIs are used to design resources with are described with property/values pairs and connected to other resources with typed links. These links between resources makes it possible to browse Linked Data and jump from resource to resource. They are also used to enrich datasets by connecting the resources with related datasets. But the best part is that _anyone_ can create and publish these links! In this article we will describe how two relate resources from two public datasets using a tool called ‘SiLK’. The links will be published by a third party which is the linker tool provided by the semantic search engine ‘Sindice’.

C6 - How to use AllegroGraph to work with Linked Open Data Auteurs Jans Aasman (Franz Inc.) Roel Stap (Data for Use) Most articles in this publication focus on interesting applications of Linked Open Data. However, for most people to get going with their first application with triples and Linked Open Data is not an easy task, especially when you are not a trained programmer or computer scientist. Therefore, in this article we’ll describe some simple steps on how to use a triple store, how to load in some Linked Open Data and then how to write SPARQL queries with a graphical query builder.

C7 - BigData4Apps: Van Linked (Open Big) Data naar Contextualized Little Data Auteurs Chris van Aart (2CoolMonkeys) Reind van Olst (2CoolMonkeys) Michiel van Dijk (2CoolMonkeys) Dit artikel beschrijft de ervaringen opgedaan tijdens de ontwikkeling van het BigData4Apps platform. Het BigData4Apps platform is in staat om van (semi)gestructureerde data, mobile data te maken. Aan het begin van 2013 zijn er honderden Nederlandse data bronnen publiekelijk beschikbaar en via het brede aanbod van App Wedstrijden zijn er diverse App concepten ontstaan. Veel van deze apps maken gebruik van een aantal geïsoleerde (open)data bronnen. Met de belofte: ‘if you build it, they will come’ (uit de film Field of Dream) zijn er diverse dataregisters opgericht, waarbij ‘you’ de dataaanbieder is en ‘they’ de derde partijen zijn die de daadwerkelijke apps bouwen en zo uit de data toegevoegde waarde kunnen creëren. Deze derde partijen worden op dit moment geconfronteerd met gefragmenteerde en niet gecontextualiseerde databronnen. Dit betekend dat er dus pas waarde kan worden toegevoegd als de

bronnen geharmonieerd, verrijkt en gecontextualiseerd zijn. App-bouwers willen niet geconfronteerd worden met complexe datamodellen of vreemde opslagformaten, maar juist de beschikking hebben over app-componenten die de data ongefragmenteerd en gecontextualiseerd aanbieden. Uit diverse professionele app-projecten is dan ook het BigData4Appsplatform ontstaan: een combinatie tussen gedistribueerde data-, semantic web-, agent-, geo- en mobiele technologie. ‘BigData4Apps’ bestaat uit de volgende vier onderdelen: (1) De data-stekker, (2) De data-linker, (3) De query-agent; en de (4) De app-agent. De datastekker koppelt met API’s of leest data in een centrale data repository. De data-linker verrijkt deze data met semantic web URI’s. De query-agent leeft boven op de verrijkte data en onderhandelt met de app-agent, die op het target device leeft. Deze appagent kent de taak van een gebruiker. De app agent weet bijvoorbeeld dat de gebruiker een archeoloog is op zoek naar referentieopgravingen, een toerist op zoek naar een gerelateerd gebouw, een constructeur op zoek naar een leiding in de grond, een officier van dienst (brandweer) op zoek naar alle relevante gegevens van brandend pand, etc. De queryagent verstuurd in een compact

en gecontextualiseerd formaat de gegevens naar de app-agent. De app-agent onderhandelt vervolgens met de app-software over welke gegevens getoond moeten worden en wat er moet worden verwerkt. De Testaccio-app en de Spui-app laten de huidige (on)mogelijkheden zien van de Linked Data en BigData4Apps technologie.

C8 - Linked Open Data en ‘BI’: vervagende grenzen in de ‘extended enterprise’ Auteurs Bas Geerdink (CSC) John Verhoeven (Inspiring Data) Met het explosief groeien van de hoeveelheid Linked Open Data (LOD) worden bedrijven, overheden en kennisinstellingen uitgedaagd tot het ontwikkelen van nieuwe en krachtige instrumenten om zicht te krijgen op deze reusachtige bron van nieuwe kennis. Daarbij gaat het om het vinden van toegevoegde waarde in Open Data, maar tevens om het realiseren van verrassende koppelingen van open en gesloten datasets. Een derde element dat kwaliteit toevoegt aan data, is het gebruik ervan zelf: het toepassen en toevoegen van LOD kan, mits goed gestructureerd en geborgd in de organisatie, ook

resulteren in ‘verrijking’ door de gebruikers. Tegelijkertijd is een tweede grote trend zichtbaar: de opkomst van de ‘extended enterprise’. In een ‘extended enterprise’ komt informatie niet meer alleen van interne, en gescreende bronnen, maar ook van ‘buiten’. Deze externe informatiebronnen kunnen zowel professionele partners zijn als tijdelijke of incidentele allianties met partijen die over informatie beschikken (andere bedrijven, overheden, kennisinstellingen) of die kennis zelf genereren (de individuele burger). Deze externe informatiestroom kan zowel big data, small data, en gestructureerde of ongestructureerde data zijn. Deze bronnen van kennis bestaan nu nog goeddeels los van elkaar, waarbij van nature meer waarde wordt toegekend aan de ‘eigen’ enterprise data dan aan informatie van buiten. ‘Eigen data eerst’, zo zou je deze visie kunnen vertalen. In een innovatieve, professionele omgeving is dit onderscheid achterhaald. Linked Open Data en ‘enterprise data’ komen samen in een vruchtbare mix waarbij de toegevoegde waarde meer is dan de som der delen. ‘Joining and sharing’ zijn de nieuwe sleutelbegrippen zodra het gaat om data. Een bedrijf dat op zoek is naar meer kennis en inzicht

over klanten, producten en nieuwe markten, zal hier een competitief voordeel kunnen behalen. Centraal hierbij staat het vermogen van de organisatie om data goed te beoordelen, te linken en te verrijken. Zowel inhoudelijk als technisch vergt dit een nieuwe aanpak. Om dit proces handen en voeten te geven is binnen de ‘Open Data Value ‘Workshop een ‘maturity scan’ ontwikkeld die zichtbaar maakt in welke mate een instelling of bedrijf klaar is om open data en bedrijfsdata aan elkaar te linken en de toegevoegde waarde te vinden en vervolgens te optimaliseren. De scan maakt tevens inzichtelijk in welke mate een bedrijf op weg is een ‘extended enterprise’ te worden. Dit proces van integratie van open en gesloten Linked Data bezien we vanuit de consequenties voor de organisatie, voor de (eisen aan) de data zelf, en vanuit de consequenties voor de geleverde diensten en producten.

Deel D - Linked Open Data – Technical Considerations

De bijdragen in deel D zijn een verdere verdieping in Linked Open Data met antwoorden op inhoudelijke uitdagingen.

D1 - Designing A URI Strategy For The Dutch Public Sector Auteurs Linda van den Brink (Geonovum) Hans Overbeek (KOOP) Thijs Brentjens (Geonovum) An important part of any Linked Data initiative is coming up with good identifiers for the objects that are subject of this Linked Data. But what is a ‘good’ URI identifier? Over the last year, several Dutch organizations have begun to feel the need for a national URI strategy to answer this question. One of the drivers for this is the European INSPIRE directive, which requires that each spatial object has a unique and persistent identifier. INSPIRE recommends using URIs for this and moreover recommends each European member state to establish a national URI strategy for the creation of these URIs. Geonovum, responsible for the implementation of INSPIRE in the Netherlands, took the initiative to

develop a URI strategy together with other Dutch stakeholders, finding each other through the Pilot Linked Open Data. In the context of this pilot a draft NL URI strategy was developed, which could be used to investigate the consequences of the choices we made. Involved parties were, among others: Geonovum, the Knowledge Center for Official Government Publications and the Tax Service. The result is a draft URI-strategy not only for spatial objects, but for all government information. A NL URIstrategy should lead to recognizable, intuitive clear URIs that identify concepts of standard models, and reference objects from registers. A framework which leads to trustworthy URIs will stimulate organizations to reuse URIs and refer to them instead of creating copies and/or creating their own. This paper describes the background and goal of the NL URI strategy, focusing primarily on the technical aspects of a strategy; the organizational approach is to be settled in a next phase. Three categories of information resources are distinguished: standards, registers

and applications. An important insight gained during the pilot was that identifiers can only be properly managed by a register and that a lot of registers already exist, and can be re-used for the purpose of minting good URIs. The insight ‘no register, no identifier’ resulted in the choice to let an indication of the register be part of a URI, which results in the need of a ‘register of registers’. W3C recommends http-URIs as identifiers and we chose to follow this recommendation. The URI pattern suggested by the draft NL URI strategy is described in the paper. Four prerequisites for a ‘good’ URI identifier are given: it must be human readable and short, have a trustworthy appearance, be intuitive, and be persistent. The use of a generic upper-domain – we suggest data.gov.nl – should give the URIs trustworthy-ness and recognisability. The paper describes the four parts of the URI pattern: register, URI type, concept, and object reference. The URI pattern is applicable, in a slightly different way, for both reference objects and vocabulary terms. Rules, suggestions and naming conventions for each part of the URI pattern are given.

D2 - Geschiktheid van formaten voor Linked Open Data Auteurs Thijs Brentjens (Geonovum) Marcel Reuvers (Geonovum) Clemens Portele (Interactive Instruments) Bij het publiceren of gebruiken van Linked Open Data krijgt men met verscheidene technische aspecten te maken. Een belangrijk aspect is het gegevensformaat. Het W3C gaat sterk uit van RDFformaten voor Linked Open Data. Voor velen zijn andere formaten echter handiger voor publicatie en/ of in gebruik. Dit paper behandelt daarom een scala aan veel gebruikte formaten en encodings (zoals PDF, JSON, RDF, CSV, GML en metadataformaten) en hun geschiktheid voor Linked Open Data. Geschiktheid uitgedrukt in termen van leesbaarheid voor machine/software en mens, mate van structurering en openheid van een formaat. Ook is het essentieel om te kunnen verwijzen met links naar andere gegevens en andersom: dat anderen kunnen linken naar de gegevens. Kijkend naar deze aspecten, geeft dit paper een overzicht van de geschiktheid van veel gebruikte formaten voor Linked Open Data.

D3 - Het ophalen van gegevens met HTTP, URIs en links

D4 - Een nieuwe wereld, een nieuwe informatiearchitectuur

Auteurs Thijs Brentjens (Geonovum) Marcel Reuvers (Geonovum) Clemens Portele (Interactive Instruments)

Auteurs Ria van Rijn (Atelier Helder Informatie Architecten) Arjen Santema (Kadaster)

URI’s zijn essentieel voor Linked Open Data. Niet alleen als identifiers, maar ook een mechanisme om via HTTP de gegevens op te vragen, al dan niet via web API’s. Dit paper kijkt naar de technische werking van HTTP en URI’s in de context van Linked Open Data. Daarbij komen de mogelijkheden van HTTP voor doorverwijzingen (HTTP 303) naar de informatie aan bod en het opvragen van verschillende formaten via Content negotiation. Webgebaseerde API’s (Application Programming Interfaces) kunnen helpen bij het bevragen van data en opvragen van sets van gegeven. Het paper zet enkele API’s naast elkaar. Links alleen zijn niet genoeg, voor mens en machine, om op voorhand te weten waar de link nu precies naar verwijst en zo te kunnen bepalen of het nuttig is de link te volgen. Semantiek over de link kan daarbij helpen. Deze onderwerpen passeren de revue, vanuit een technisch perspectief, inclusief kort aandacht voor (technische) testen hierop.

De techniek van Linked Open Data maakt het mogelijk, dat gegevens die door verschillende partijen zijn gepubliceerd op internet, worden geïnterpreteerd en gebruikt door derden. Dit leidt tot een interessante business case voor overheidsorganisaties. De eigenaar van gegevens kan met Linked Open Data voor een fractie van de kosten voldoen aan zijn plicht gegevens te publiceren. En de afnemers hebben niet alleen lagere kosten, maar ook veel meer vrijheid in de manier van afnemen. Bovendien kunnen de gegevens gecombineerd worden tot verrassende, ongedachte toepassingen. Informatiearchitectuur gaat over het aanbrengen van samenhang tussen ontwikkelingen in een organisatie rond de informatievoorziening. De techniek van Linked Open Data is daar een voorbeeld van. Inzetten van Linked Open Data beperkt zich namelijk beslist niet tot technische veranderingen.

Hoewel Linked Open Data nog in de kinderschoenen staat, gaan de ontwikkelingen momenteel ook erg snel. Daarom is het belangrijk om de consequenties ervan nu al in kaart te brengen. Optimaal gebruiken van deze nieuwe techniek vereist namelijk ook veranderingen in het omgaan met gegevens (door mensen maar ook door applicaties). Bovendien veranderen de verantwoordelijkheden van de organisatie bijvoorbeeld met betrekking tot veiligheid en privacy. Een organisatie moet hiermee bij voorbaat rekening houden, wil zij ten volle kunnen gaan profiteren van de voordelen van Linked Open Data.

D5 - Het contextdilemma hanteren met Linked Data Auteurs Marcel van Mackelenbergh (Belastingdienst) Rinke Hoekstra (Vrije Universiteit) Hergebruik van gegevens kent een contextprobleem: een gegeven betekent iets anders in een andere context. Als mensen gegevens creĂŤren dan hebben ze daarmee een doel voor ogen. Ook hebben mensen een beeld van de wereld. Gegevens bevatten impliciet informatie die voortkomt uit dat doel en dat beeld. Geen rekening houden met deze

impliciete informatie veroorzaakt belangrijke fouten in de uitvoering. Linked Data erkent dat gegevens een context hebben en biedt een manier om hier mee om te gaan. Linked Data gaat uit van de â&#x20AC;&#x2DC;dingenâ&#x20AC;&#x2122; die bestaan, zogenaamde resources. Iedere resource wordt aangeduid middels een identifier (URI). Doordat partijen dezelfde URI gebruiken voor het aanduiden van een resource, zijn ze in staat om gegevens over die resource met elkaar uit te wisselen. Een afnemer van gegevens ziet welk gegeven een leverancier van gegevens hanteert voor die resource. De afnemer kan het gegeven van de leverancier overnemen maar hij kan ook altijd zijn eigen gegeven inzetten. Hierdoor ontstaat maximaal hergebruik met de flexibiliteit die de afnemer nodig heeft voor zijn eigen context. Er is een nieuw soort gegevens nodig in dit web van gegevens. Er bestaat aandacht voor de zogenaamde provenance van gegevens. Provenance-gegevens beschrijven onder andere hoe, wanneer, door wie en waarom gegevens zijn gemaakt. Deze provenance is relevant omdat een afnemer van gegevens hiermee een inschatting kan maken of de gegevens (her)bruikbaar zijn voor zijn eigen toepassing. In dit artikel wordt een voorstel gedaan om naast de provenance ook de bruikbaarheid

(usability) van gegevens te beheren. Bruikbaarheid van gegevens geeft aan in welke contexten een gegeven heeft geleid tot een succesvolle uitvoering.

D6 - Ontwerp van consistente domeinontologieën – hergebruik van bestaande sectorafspraken Auteur Roel Stap (Data for Use) In veel bedrijfssectoren en toepassingsgebieden zijn, of worden, gemeenschappelijk informatieafspraken gemaakt en vastgelegd in zogenaamde informatiemodellen. Het doel van die afspraken is om te komen tot gemeenschappelijke betekenis van gebruikte terminologie, die binnen het betreffende domein gebruikt wordt om effectief tussen organisaties te kunnen communiceren. Door de toenemende samenwerking zowel binnen als buiten de eigen organisatie, is het belang van duidelijke informatie in de communicatie enorm toegenomen.

Het vastleggen van deze gemeenschappelijke afspraken gebeurt veelal op een formele maar technologie- en toepassingsonafhankelijke wijze. Dat wil zeggen dat zij geen beperkingen kennen en toegepast kunnen worden in allerlei systemen en toepassingen waarin informatie wordt verwerkt. Met de opkomst van het semantische web en de daarbij behorende middelen om informatie op een eenduidige manier in de vorm van ontologieën vast te leggen, ontstaat de vraag of en hoe we gebruik kunnen maken van deze bestaande informatieafspraken. Het hergebruik van deze afspraken zou de adoptie en toepassing van semantisch web applicaties vergemakkelijken en de aansluiting op bestaande informatiesystemen in de sector bevorderen. Aan de hand van een IECinformatiestandaard uit de energiesector zal in dit artikel de aanpak besproken worden hoe dit informatiemodel gebruikt kan worden om tot domeinspecifieke ontologieën te komen. Als voorbeeld wordt een energieverbruikontologie ontwikkeld die de basis is om energieverbruikgegevens eenduidig te publiceren, onafhankelijk welke organisatie de bron van de data is en hoe die is vastgelegd.

D7 - INSPIRE and Linked Data Auteur Clemens Portele (interactive instruments) ‘Linked Data’ as such did not exist when the INSPIRE Directive or its technical foundation in Implementing Rules were designed. However, as the focus of Linked Data is on principles how data is to be published on the Web, there is overlap in the goals of INSPIRE and of Linked Data, but there are also – sometimes subtle – differences. For example: ll INSPIRE did not limit the ‘networks’ on which spatial data is to be made available while Linked Data is explicitly focused on the Web. However, so far INSPIRE has limited its technical guidance to the Web, so in reality this is not a significant difference, but the network-neutrality requirements in the Directive and Implementing Rules have impact, even if all INSPIRE data is published on the Web. This affects in particular identifiers. ll The scope of INSPIRE is about publishing existing data sets and excludes the collection of new data. Typically publishing data as Linked Data goes beyond this as it strongly encourages adding links to other, related data.

The compatibility of INSPIRE concepts and Linked Data were first analysed in 2009 and presented at the INSPIRE conference 2010. In that paper it was highlighted that Linked Data is not a technical subject per se. It uses the principles of the Web, and technologies of the Semantic Web, to develop the Web of data. Linked Data can be seen as a philosophy about using the Web to create a unified set of data. A key aspect is to interlink the data through Web mechanisms. All this is consistent with what is done in SDIs in general and INSPIRE in particular. There are some differences in technologies, but these are minor. The biggest issues are non-technical.

D8 - From Geo-Data to Linked Data: Automated Transformation from GML to RDF Auteurs Linda van den Brink (Geonovum) Paul Janssen (Geonovum) Wilko Quak (TU-Delft) Linked Data provide an alternative route for dissemination of spatial information as compared to the traditional SOA-based SDI approach. Where the latter is built on predefined structuring of semantics within domains, Linked Data is open to linking information to any data over the Web. In this respect both are complementary. The traditional approach providing a mechanism for a basis of standardized and structured data within domains, and Linked Data providing an open mechanism for sharing and combining. GML as the ISO standard for exchange of service based spatial data and RDF as the Linked Data format are therefore related. GML provides the format in which many spatial datasets are available and exchanged. This standardization process and effort has been realized on a large scale. Why not let the web of Linked Data take advantage of this effort? This article will focus on the use of GML structured data as a source for deriving RDF structured data.

The first part of the paper focusses on deriving Linked Data from GML data. The first version of GML, v1.0, was based on RDF. From version 2.0 onwards GML was based on XML and XML Schema, but the objectproperty structure was retained. We describe a transformation for translating any correctly structured GML to RDFS/OWL automatically, using XSLT. Because GMLâ&#x20AC;&#x2122;s objectproperty structure translates very well to triples, the transformation is straightforward. Well-known GML content elements such as names and descriptions are mapped to their RDF equivalent. However, any semantics specific to the input GML data (a.k.a. the application schema) are ignored in this translation. In the second part, we study how more meaningful RDF can be created from GML, given the underlying information model, by transforming it from UML to RDFS/OWL. There exists a straightforward mapping to convert a UML model into a RDFS/ OWL vocabulary. However, the re-use of existing concepts in vocabularies takes a central role in RDFS/OWL while in UML the use of vocabularies is not supported. We describe how annotating the UML model could improve this translation. Furthermore we discuss how the difference in

design philosophy between UML and RDFS/OWL (open world assumption vs. closed world assumption) results in a different approach of how the absence of a specific property should be handled.

D9 - Mapping Statistical Linked Data Auteur Willem Robert van Hage (SynerScope B.V.) In this paper we will demonstrate, step by step, how to analyze a combination of Linked Data and non-Linked Data with the R statistical programming language. We will show how to combine Linked Data from different sources, and how to join this data with tabular statistical data. Specifically, we will be working with Linked Data from the Land Registry (Kadaster), about addresses and buildings, the Basisregistratie voor Adressen en Gebouwen (BAG); Linked Data from DBpedia, and non-linked tabular statistical data from the Statistics Netherlands (CBS). We will investigate geographical correlations between building properties and the socio-economical status of their inhabitants. Topics covered in this tutorial are: simple SPARQL end-point interaction, joining of Linked Data, joining Linked Data with non-Linked Data by a shared key, basic statistics, and geographical visualization.

D10 - Pragmatism versus formalism: the relation between Linked Open Data, semantics and ontologies Auteurs Paul Brandt (TNO) Laura Daniele (TNO) This paper will present the relationship, or absence thereof, between Linked Open Data (LOD), Semantics and Ontologies. Clearly the central idea behind LOD as well as Ontologies is to facilitate data processing that is grounded in its semantics, e.g., establishing the meaning of data and act accordingly. Ontologies are engineering artifacts that represent the relevant state of

affairs in the world, their interrelations and, of course, their significance to the application. Linked Open Data essentially represents a vision where applications can automatically consume and apply externally published data in a way similar to how humans consume information that has been published on the world wide web. Since both approaches can be considered a means to achieve a similar goal, and hence represent distinct tools, it is necessary to become aware of their differences and similarities before one can decide when, and how, both tools can be applied best. To that end we will investigate the balance between the precision of formalism, coming from the ontological approach, and the speed and readiness of pragmatism, coming from the LOD approach.

Pilot Linked Open Data Nederland Deel 2 - De Verdieping

Voorwoord U bent nu aangekomen bij het tweede deel van het boek Pilot Linked Open Data. In deel 1 heeft u over de pilot kunnen lezen, evenals een introductie over Linked Open Data en een overzicht en beschrijvingen van de bijdragen die in deel 2 zijn opgenomen. Deze artikelen zijn ook ‘online’ op Internet geplaatst. In deel 1 en deel 2 zijn de artikelen voorzien van een QR-code die verwijst naar de online versie van het artikel. Dit boekwerk bevat de ‘offline’ versie van de artikelen zoals ze op 3 juli 2013 ‘online’ op het Internet stonden. Het is mogelijk dat de auteurs updates van hun artikel online hebben geplaatst sindsdien, vandaar dat om de laatste versie te kunnen raadplegen de QRcode is geplaatst.

De bijdragen zijn onder verdeeld in vier categorieën: A. The Essentials: Een algemene introductie in Linked Open Data B. De Toepassingen: Mogelijke toepassingen op basis van Linked Open Data C. How to: Gericht op toepassers van Linked Open Data D. Technical Considerations: Verdieping van inhoudelijke uitdagingen rond Linked Open Data De taal is wisselend: een combinatie van Nederlands en Engels, op basis van de voorkeuren van de auteurs. Enkele bijdragen zijn online zelfs beschikbaar in beide talen. De auteurs hebben veel energie gestoken in hun bijdrage, en horen graag uw mening of vragen over het artikel. Veel leesplezier!

Erwin Folmer (Geonovum) Projectleider Pilot Linked Open Data Nederland

A1 - Linked Open Data – The Essentials

This text is a reprint of Linked Open Data: The Essentials - A Quick Start Guide for Decision Makers by Florian Bauer (REEEP) and Martin Kaltenböck (Semantic Web Company). The full book is available as PDF file at: http:// www.semantic-web.at/LODTheEssentials.pdf

Auteurs

Florian Bauer (REEEP) Martin Kaltenböck (Semantic Web Company) From Open Data to Linked Open Data A brief history and factbook of Open Government, Open (Government) Data & Linked Open Data This introductory chapter will describe the principles of linking data; define important terms such as Open Government, Open (Government) Data and Linked Open (Government) Data; and explain relevant mechanisms to ensure a solid foundation before going more in-depth. Each subsequent chapter explains a specific topic and suggests additional resources, such as books and websites, for gaining more detailed insights on a particular theme. We hope that by

introducing you to the possibilities of Linked Open Data (LOD), you will be able to share our vision of the future semantic web. Open Government & Open (Government) Data When we talk about Open Government today, we refer to a movement that was initiated by ‘The Memorandum on Transparency and Open Government’ ([1] The Transparency Directive), a memorandum signed by US President Barack Obama shortly after his inauguration in January 2009. The basic idea of Open Government is to establish a modern cooperation among politicians, public administration, industry and private citizens by enabling more transparency, democracy, participation and collaboration. In European countries, Open Government is often viewed as a natural companion to e-government [2]. An important excerpt of the memorandum reads: ‘My Administration is committed to creating an unprecedented level of openness in Government. We will work together to ensure the public trust and establish a system of transparency, public participation, and collaboration. Openness will strengthen our democracy and promote efficiency and effectiveness in Government.’

The Open Government partnership [3] was launched on September 20, 2011, when the eight founding governments (Brazil, Indonesia, Mexico, Norway, Philippines, South Africa, United Kingdom, United States) endorsed an Open Government declaration, announced their countriesâ&#x20AC;&#x2122; action plans, and welcomed the commitment of 38 governments to join the partnership. In September 2011, there were 46 national government commitments to Open Government worldwide. Some of the most important enablers for Open Government are free access to information and the possibility to freely use and re-use this information (e.g. data, content, etc). After all, without information it is not possible to establish a culture of collaboration and participation among the relevant stakeholders. Therefore, Open Government Data (OGD) is often seen as a crucial aspect of Open Government. OGD is a worldwide movement to open up government/public administration data, information and content to both human and machine-readable non-proprietary formats for reuse by civil society, economy, media and academia as well as by politicians and public administrators. This would apply only to data and information produced or commissioned by government or government-controlled entities and is not related to data on individuals.

Being open means lowering barriers to ensure the widest possible re-use by anyone. With OGD, a new paradigm came into being for publishing government data that invites everyone to look, take and play! The often-used term â&#x20AC;&#x2DC;Open Dataâ&#x20AC;&#x2122; refers to data and information beyond just governmental institutions and includes those from other relevant stakeholder groups such as business/ industry, citizens, NPOs and NGOs, science or education. Some of the best-known institutions currently undertake Open Data activities include the World Bank [4], the United Nations [5], REEEP [6], the New York Times [7], The Guardian [8] and the Open Knowledge Foundation (OKFN) [9]. In 2007, 30 Open Government advocates came together in Sebastopol, California, USA to develop a set of OGD principles [10] that underscored why OGD is essential for democracy. In 2010, the Sunlight Foundation [11] expanded these to 10 principles. Even though these principles are neither set in stone nor legally binding, they are widely considered by the global open (government) data community as general guidelines on the topic.

Government Data shall be considered ‘open’ if the data is made public in a way that complies with the principles below: 1. Data must be complete All public data is made available. The term „data’ refers to electronically-stored information or recordings, including but not limited to documents, databases, transcripts, and audio/visual recordings. Public data is data that is not subject to valid privacy, security or privilege limitations, as governed by other statutes. 2. Data must be primary Data is published as collected at the source, with the finest possible level of granularity, and not in aggregate or modified forms. 3. Data must be timely Data is made available as quickly as necessary to preserve the value of the data. 4. Data must be accessible. Data is available to the widest range of users for the widest range of purposes. 5. Data must be machine-processable Data is structured so that it can be processed in an automated way. 6. Access must be non-discriminatory Data is available to anyone, with no registration requirement. 7. Data formats must be non-proprietary

Data is available in a format over which no entity has exclusive control. 8. Data must be license-free Data is not subject to any copyright, patent, trademark or trade secrets regulation. Reasonable privacy, security and privilege restrictions may be allowed as governed by other statutes. Compliance to these principles must be reviewable through the following means: ll A contact person must be designated to respond to people trying to use the data; or ll A contact person must be designated to respond to complaints about violations of the principles; or ll An administrative or judicial court must have the jurisdiction to review whether the agency has applied these principles appropriately. The two principles added by the Sunlight Foundation are as follows: 9. Permanence Permanence refers to the capability of finding information over time. 10. Usage costs One of the greatest barriers to access to ostensibly publicly available information is the cost imposed on the public for access – even when the cost is de minimus.

It has been acknowledged that the worldwide OGD movement originated in Australia, New Zealand, Europe and North America, but today we also see strong OGD engagement and activity in Asia, South America and Africa. For example, Kenya started Africa’s first data portal [12] in July 2011. The European Commission (EC) has also put the issue high up on its agenda and is actively pushing OGD forward in Europe. Neelie Kroes, VicePresident of the European Commission responsible for the Digital Agenda, has stated strong commitment to OGD through her announcement of an EC data portal by early 2012 and for a Pan-European data portal acting as a single point of access for all European national data portals by 2013. Open Data is an important part of both the Digital Agenda for Europe [13] and the European e-government Action Plan 2011–2015 [14]. In December 2011 the EC furthermore announced its Open Data Strategy for Europe: Turning Government Data into Gold [15]. The current leading countries in national Open Data activities and initiatives are definitely the governments of the United States of America [16], Australia [17], the Scandinavian countries and the UK government [18]. All of these countries have a high political commitment to both Open Data and central Open Data portals, and they

all have a strong Open Data community. These innovative countries and the people behind them can be considered the pioneers of OGD. Two very good resources about the worldwide OGD movement are: ll SWC world map of Open Data initiatives, activities and portals: http://bit.ly/open-data-map ll OKFN comprehensive list of data catalogs curated by experts from around the world: http://datacatalogs.org For a good example of a national OGD process, please refer to the following ‘UK Open Government Data Timeline’ by Tim Davies (next page). Links [1] The Memorandum on Transparency and Open Government: http://1.usa.gov/8eo8tl [2] e-government, Wikipedia: http://en.wikipedia.org/wiki/ EGovernment [3] Open Government Partnership: http://www.opengovpartnership. org [4] Open Data World Bank: http://data.un.org [5] Open Data United Nations: http://data.worldbank.org [6] Open Data REEEP: http://data.reegle.info [7] Open Data New York Times: http://data.nytimes.com

UK Open Government Data Timeline’, Tim Davies

[8] Open Data The Guardian: http://www.guardian.co.uk/ worldgovernment-data [9] Open Knowledge Foundation: http://okfn.org [10] 8 Principles of Open Government Data: http:// www.opengovdata.org/ home/8principles [11] Sunlight Foundation: 10 principles of Open Government Data: http://bit.ly/11LvBmm [12] Kenya Open Data Portal: http://opendata.go.ke [13] Digital Agenda for Europe: http://bit.ly/9kAgfy [14] eGovernment Action Plan Europe 2011–2015: http://bit.ly/13SPFYm [15] Announcement: Open Data Strategy for Europe: http://bit.ly/s5FiQo [16] Open Data Catalogue United States of America: http://data.gov [17] Open Data Catalogue of Australia: http://data.gov.au [18] Open Data Catalogue United Kingdom: http://data.gov.uk

Further Reading ll Open Government, Wikipedia: http://en.wikipedia.org/wiki/ Open_government ll Open Knowledge Foundation, OGD website: http://opengovernmentdata.org ll Open Data, Wikipedia: http:// en.wikipedia.org/wiki/Open_data ll Open Knowledge Foundation Blog: http://blog.okfn.org Putting the L in Front: From Open Data to Linked Open Data As mentioned above, OGD is all about opening up information and data, as well as making it possible to use and re-use it. An OGD requirements analysis was conducted in June 2011 in Austria and highlights the following eleven areas to consider when thinking about OGD: 1. Need for definitions 2. Open Government: transparency, democracy, participation and collaboration 3. Legal issues 4. Impact on society 5. Innovation and knowledge society 6. Impact on economy and industry 7. Licenses, models for exploitation, terms of use 8. Data relevant aspects 9. Data governance 10. Applications and use cases 11. Technological aspects

When considering how to fully benefit from OGD in concrete cases, it is clear that interoperability and standards are key. This is where LOD principles come into play. To fully benefit from Open Data, it is crucial to put information and data into a context that creates new knowledge and enables powerful services and applications. As LOD facilitates innovation and knowledge creation from interlinked data, it is an important mechanism for information management and integration. There are two equally important viewpoints to LOD: publishing and consuming. Throughout this guide, we will always address LOD from both the publishing and consumption perspectives. The path from open (government) data to linked open (government) data was best described by Sir Tim Berners-Lee [1] when he first presented his 5 Stars Model at the Gov 2.0 Expo in Washington DC in 2010. Since then, Berners-Leeâ&#x20AC;&#x2DC;s model has been adapted and explained in several ways; the following adaptation of the 5 Stars Model [2] by Michael Hausenblas [3] explains the costs and benefits for both publishers and consumers of LOD:

What are the costs and benefits of web data? Information is available on the Web (any format) under an open license

Information is available as structured data (e.g. Excel instead of an image scan of a table)

Non-proprietary formats are used (e.g. CSV instead of Excel)

URI identification is used so that people can point at individual data

Data is linked to other data to provide context

LOD is becoming increasingly important in the fields of state-of-the-art information and data management. It is already being used by many wellknown organisations, products and services to create portals, platforms, internet-based services and applications. LOD is domain-independent and penetrates various areas and domains, thus proving its advantage over traditional data management. For example, the project LOD2 [4] Creating Knowledge Out of Interlinked Data, which is funded by the European Commission under the 7th Framework Programme, develops powerful LOD mechanisms and tools based on three real use cases: OGD, linked enterprise data and LOD for media and publishers. For further reading on linked open (government) data, please refer to the Government Linked Data (GLD) W3C working group [5]. The following chapters discuss the benefits of LOD, as well as basic LOD consuming and publishing principles for creating powerful and innovative services for knowledge management, decision making and general data management. The best practice examples reegle.info [6] and OpenEI [7] show how LOD can have a great impact on their respective target groups. Another popular example of applied OGD is legislation.gov.uk.

Links [1] Sir Tim Berners-Lee (Wikipedia): http://en.wikipedia.org/wiki/ Tim_Berners-Lee [2] 5 Stars Model on Open Government Data by Michael Hausenblas: http://lab.linkeddata.deri.ie/2010/ star-scheme-by-example [3] Michael Hausenblas: http://semanticweb.org/wiki/ Michael_Hausenblas [4] LOD2 â&#x20AC;&#x201C; Creating Knowledge Out of Interlinked Data: http://www.lod2.eu [5] GLD W3C Working Group: http:// www.w3.org/2011/gld/charter [6] Clean energy info portal reegle. info: http://www.reegle.info [7] Open Energy Info (OpenEI): http://en.openei.org Further reading ll Linked Data, Wikipedia: http:// en.wikipedia.org/wiki/Linked_data ll Linked Data â&#x20AC;&#x201C; Connect Distributed Data Across the Web: http://linkeddata.org ll Linked Data: Evolving the Web into a Global Data Space, Heath and Bizer: http://linkeddatabook.com ll Linking Government Data, David Wood (Editor), Springer; 2011 edition (November 12, 2011), ISBN10: 146141766X, ISBN-13:9781461417668 ll W3C Linking Open Data Community Project: http://bit.ly/fBiPxG

The Power of Linked Open Data Understanding World Wide Web Consortium’s (W3C) [1] vision of a new web of data Imagine that the web is like a giant global database. You want to build a new application that shows the correspondence among economic growth, renewable energy consumption, mortality rates and public spending for education. You also want to improve user experience with mechanisms like faceted browsing. You can already do all of this today, but you probably won’t. Today’s measures for integrating information from different sources, otherwise known as mashing data, are often too time-consuming and too costly. Two driving factors can cause this unpleasant situation: First of all, databases are still seen as „silos’, and people often do not want others to touch the database for which they are responsible. This way of thinking is based on some assumptions from the 1970s: that only a handful of experts are able to deal with databases and that only the IT department’s inner circle is able to understand the schema and the meaning of the data. This is obsolete. In today’s internet age, millions of developers are able to build valuable applications whenever they get interesting data.

Secondly, data is still locked up in certain applications. The technical problem with today’s most common information architecture is that metadata and schema information are not separated well from application logics. Data cannot be re-used as easily as it should be. If someone designs a database, he or she often knows the certain application to be built on top. If we stop emphasising which applications will use our data and focus instead on a meaningful description of the data itself, we will gain more momentum in the long run. At its core, Open Data means that the data is open to any kind of application and this can be achieved if we use open standards like RDF [2] to describe metadata. Linked Data? Nowadays, the idea of linking web pages by using hyperlinks is obvious, but this was a groundbreaking concept 20 years ago. We are in a similar situation today since many organizations do not understand the idea of publishing data on the web, let alone why data on the web should be linked. The evolution of the web can be seen as follows:

Although the idea of Linked Open Data (LOD) has yet to be recognised as mainstream (like the web we all know today), there are a lot of LOD already available. The so called LOD cloud [3] covers more than an estimated 50 billion facts from many different domains like geography, media, biology, chemistry, economy, energy, etc. The data is of varying quality and most of it can also be re-used for commercial purposes. Please see a current version of the LOD Cloud diagram of 2011 as follows:

Why should we link data on the web and how do we do it? All of the different ways to publish information on the web are based on the idea that there is an audience out there that will make use of the published information, even if we are not sure who exactly it is and how they will use it. Here are some examples: ll Think of a twitter message: not only do you not know all of your followers, but you often don’t even know why they follow you and what they will do with your tweets. ll Think of your blog: it´s like an email to someone you don’t know yet. ll Think of your website: new people can contact you and offer new surprising kinds of information. ll Think of your email-address: you have shared it on the web and receive lots of spam since then. In some ways, we are all open to the web, but not all of us know how to deal with this rather new way of thinking. Most often the ‘digital natives’ and ‘digital immigrants’ who have learned to work and live with the social web have developed the best strategies to make use of this kind of ‘openness’. Whereas the idea of Open Data is built on the concept of a social web, the idea of Linked Data is a descendant of the semantic web. The basic idea of a semantic web is to provide cost-efficient ways to publish information in distributed environments. To reduce costs when

it comes to transferring information among systems, standards play the most crucial role. Either the transmitter or the receiver has to convert or map its data into a structure so it can be ‘understood’ by the receiver. This conversion or mapping must be done on at least three different levels: used syntax, schemas and vocabularies used to deliver meaningful information; it becomes even more time-consuming when information is provided by multiple systems. An ideal scenario would be a fully-harmonised internet where all of those layers are based on exactly one single standard, but the fact is that we face too many standards or ‘de-facto standards’ today. How can we overcome this chickenand-egg problem? There are at least three possible answers: ll Provide valuable, agreed-upon information in a standard, open format. ll Provide mechanisms to link individual schemas and vocabularies in a way so that people can note if their ideas are ‘similar’ and related, even if they are not exactly the same. ll Bring all this information to an environment which can be used by most, if not all of us. For example: don’t let users install proprietary software or lock them in one single social network or web application!

A brief history of LOD Corresponding to the three points above, here are the steps already done by the LOD community: ll W3C has published a stack of open standards for the semantic web built on top of the so-called ‘Resource Description Framework’ (RDF). This widely-adopted standard for describing metadata was also used to publish the most popular encyclopedia in the world: Wikipedia now has its ‘semantic sister’ called DBpedia [4], which became the LOD cloud’s nucleus. ll W3C´s semantic web standards also foresee the possibility to link data sets. For example, one can express in a machine-readable format that a certain resource is exactly (or closely) the same as another resource, and that both resources are somewhere on the web but not necessarily on the same server or published by the same author. This is very similar to linking resources to each other using hyperlinks within a document, and is the atomic unit for the giant global database previously mentioned. ll Semantic web standards are meant to be used in the most common IT infrastructure we know today: the worldwide web (WWW). Just use your browser and use HTTP! Most of the LOD cloud’s resources and the context information around them can be retrieved

by using a simple browser and by typing a URL in the address bar. This also means that web applications can make use of Linked Data by standard web services. Already reality – an example Paste the following URL in your browser: http://bit.ly/14iCcIh and you will receive a lot of well structured facts about REEEP. Follow the fact that REEEP ‘is owner of’ reegle (http:// dbpedia.org/resource/Reegle) and so on and so forth. You can see that the giant global database is already a reality! Complex systems and Linked Data Most systems today deal with huge amounts of information. All information is produced either within the system boundaries (and partly published to other systems) or it is consumed ‘from outside’, ‘mashed’ and ‘digested’ within the boundaries. Some of the growing complexity has been caused in a natural way due to a higher level of education and the technical improvements made by the ICT sector over the last 30 years.

Simply said, humanity is now able to handle much more information than ever before with probably the lowest costs ever (think of higher bandwidths and lower costs of data storage). However, most of the complexity we are struggling with is caused above all by structural insufficiencies due to the networked nature of our society. The specialist nature of many enterprises and experts is not yet mirrored well enough in the way we manage information and communicate. Instead of being findable and linked to other data, much information is still hidden. With its clear focus on high-quality metadata management, Linked Data is key to overcoming this problem. The value of data increases each time it is being re-used and linked to another resource. Re-usage can only be triggered by providing information about the available information. In order to undertake this task in a sustainable manner, information must be recognised as an important resource that should be managed just like any other. Examples for LOD applications Linked Open Data is already widely available in several industries, including the following three: ll Linked Data in libraries [5]: focusing on library data exchange and the potential for creating globally interlinked library data; exchanging

and jointly utilising data with nonlibrary institutions; growing trust in the growing semantic web; and maintaining a global cultural graph of information that is both reliable and persistent. ll Linked Data in biomedicine [6]: establishing a set of principles for ontology/vocabulary development with the goal of creating a suite of orthogonal interoperable reference ontologies in the biomedical domain; tempering the explosive proliferation of data in the biomedical domain; creating a coordinated family of ontologies that are interoperable and logical; and incorporating accurate representations of biological reality. ll Linked government data: re-using public sector information (PSI); improving internal administrative processes by integrating data based on Linked Data; and interlinking government and nongovernment information. The future of LOD The inherent dynamics of Open Data produced and consumed by the ‘big three’ stakeholder groups – media, industry, and government organizations/NGOs – will move forward the idea, quality and quantity of Linked Data – whether it is open or not: Whereas most of the current momentum can be observed in the government & NGO sectors, more and

more media companies are jumping on the bandwagon. Their assumption is that more and more industries will perceive Linked Data as a cost-efficient way to integrate data. Linking information from different sources is key for further innovation. If data can be placed in a new context, more and more valuable applications – and therefore knowledge – will be generated. Links [1] The World Wide Web Consortium (W3C): is an international community that develops open standards to ensure the longterm growth of the Web: http://www.w3.org [2] Resource Description Framework (RDF): http://www.w3.org/RDF [3] Linked Open Data Cloud: http://www.lod-cloud.net [4] DBpedia: http://dbpedia.org [5] Jan Hannemann, Jürgen Kett (German National Library): Linked Data for Libraries (2010) http://bit.ly/cDq3Ug [6] OBO Foundry: http://obofoundry.org

Linked Open Data Start Guide A quick guide for your own LOD strategy and appearance The following two sections review LOD publication and consumption and provide the essential information for establishing a powerful LOD strategy for your own organisation. We also provide further reading recommendations for anyone seeking more technical details on LOD publishing and consumption, as well as a list of the most important software tools for publishing and consuming LOD. The following figure is a technical overview of the necessary blocks for building your strategy for LOD publishing and consumption. The idea, benefit and effort of publishing LOD have already been mentioned in the previous chapters of this publication, and were discussed along the 5 Star Model of OGD. Publishing Linked Open Data - First steps for publishing your content as LOD

Publishing Linked Open DataLOD provides a powerful mechanism for sharing your own data and information along with your metadata and the respective data models for efficient re-use. Going LOD helps your organisation to become an important data hub within your domain. Quick guide for publishing LOD We have prepared a short guide for the most important issues that need to be taken into account when publishing LOD as well as a stepby-step model to get started. Analyse your data

Before you start publishing your data, it is crucial to take a deeper look at your data models, your metadata and the data itself. Get an overview and prepare a selection of data and information that is useful for publication. Clean your data

Data and information that comes from many distributed data sources and in several different formats (e.g. databases, XML, CSV, Geodata, etc.) require additional effort to ensure easy and efficient modelling. This includes ridding your data and information of any additional information that will not be included in your published data sets.

Model your data

Choose established vocabularies and additional models to ensure smooth data conversion to RDF. The next step is to create unified resource identifiers (URIs) [1] as names for each of your objects. To ensure sustainability, remember to develop data models for data that change over time. Choose appropriate vocabularies

There are lots of existing RDF vocabularies for re-use; please evaluate appropriate vocabularies for your data from existing ones. If there are no vocabularies that fit your needs, feel free to create your own. Specify license(s)

To ensure broad and efficient re-use of your data, evaluate, specify and provide a clear license for your data to avoid its re-use in a legal vacuum. If possible, specify an existing license that people already know. This enables interoperability with other data sets in the field of licensing. For example, Creative Commons [2] is a commonly-used license for OGD. Convert data to RDF

One of the final steps is to convert your data to RDF [3], a very powerful data model for LOD. RDF is an official W3C recommendation for semantic web data models. Remember to include your specified license(s) into your RDF files.

Link your data to other data

Before you publish, make sure that your data is linked to other data sets; links to your other data sets and to third party data sets are useful. These links ensure optimised data processing and integration for data (re-)use and allow for the creation of new knowledge from your data sets by putting them into a new context with other data. Evaluate and choose carefully the most relevant data sets to be linked with your own.

possible 4. Publish human- and machinereadable descriptions 5. Convert data to RDF 6. Specify an appropriate license 7. Announce the new Linked Data Set(s) The following life cycle of Linked Open (Government) Data by Bernadette Hyland [7] visualises the path for LOD publishing:

Publish and promote your LOD

Publish your data on the web and promote your new LOD sets to ensure wide re-use – even the best LOD will not be used if people cannot find it! Alongside other ways of promotion it is a great idea to add your LOD sets into the LOD cloud [4], a visual presentation of LOD sets by providing and updating the meta-information about your data sets on the data hub [5]. Remember to always provide human-readable descriptions of your data sets to make the data sets ‘self-describing’ for easy and efficient re-use. For a similar approach, we recommend the „Ingredients for high quality Linked (Open) Data’ by the W3C Linked Data Cookbook [6]. The essential steps to publishing your own LOD are: 1. Model and link the data 2. Name things with URIs 3. Re-use vocabularies whenever

The Four Rules of Linked Data (W3C Design Issues for Linked Data [8]) are also a good place to start understanding LOD principles: The semantic web isn‘t just about putting data on the web – that is the old „web of pages.’ It is about making links, so that a person or machine can explore the semantically connected ‘web of data.’ With Linked Data, you can find more related data. Like the web of hypertext, the web of data is constructed with documents on the web. However, unlike the web of hypertext, where links are relationships anchors in hypertext documents written in HTML, LOD functions through links between arbitrary things described by RDF. The URIs identify any kind of object or concept, but regardless of HTML or RDF, the same

expectations apply to make the web grow: 1. Use URIs as names for things 2. Use HTTP URIs so that people can look up those names. 3. When someone looks up a URI, provide useful information, using the established standards (e.g. RDF, SPARQL) 4. Include links to other URIs, so that more things can be discovered Furthermore, it is crucial to provide high quality information for developers and data workers about your data. Provide information about data provenance as well as its data collection to guarantee smooth and efficient work with your data. To ensure widest possible re-use, provide a (web) API [9] on top of the published data sets that allows users to query your data and to fetch data and information from your data collection tailored to their needs. A web API enables web developers to easily work with your data. Here are some best practice examples for publishing LOD: ll UK official National Open (Government) Data Portal â&#x20AC;&#x201C; Linked Data Area: http://data.gov.uk/linked-data

ll Official UK Legislation: http://www.legislation.gov.uk ll reegle.info LOD portal: http://data.reegle.info ll EU project: LATC â&#x20AC;&#x201C; LOD around the clock: http://latc-project.eu

Links [1] Uniform Resource Identifier, URI on Wikipedia: http://en.wikipedia.org/wiki/ Uniform_resource_identifier [2] Creative Commons: http://creativecommons.org [3] Resource Description Framework (RDF): http://www.w3.org/ RDF/RDF on Wikipedia: http:// en.wikipedia.org/wiki/ Resource_Description_Framework [4] The LOD Cloud: http:// richard.cyganiak.de/2007/10/lod [5] The Data Hub (formerly CKAN): http://thedatahub.org [6] W3C Linked (Open) Data Cookbook: http://bit.ly/vbopoH [7] Bernadette Hyland: http://bit.ly/11Oaz7E [8] W3C Design Issues for Linked Data: http://www.w3.org/ DesignIssues/LinkedData.html [9] Web API: http:// en.wikipedia.org/wiki/Web_API or Web Service: http:// en.wikipedia.org/wiki/Web_service

Further Reading ll How to publish Linked Data on the Web, Bizer et al: http://www4.wiwiss.fu-berlin.de/ bizer/pub/linkeddatatutorial ll Linked Data â&#x20AC;&#x201C; Connect Distributed Data across the Web: http://linkeddata.org ll Linked Data: Evolving the Web into a Global Data Space, Heath and Bizer: http://linkeddatabook.com ll Designing URI Sets for the UK Public Sector: http://www.cabinetoffice.gov.uk/ resource-library/designing-urisets-uk-public-sector ll Linked Data Patterns, Dodds & Davies: http://patterns.dataincubator.org/ book/linked-data-patterns.pdf ll Linking Government Data, David Wood (Editor), Springer; 2011 edition (November 12, 2011), ISBN10: 146141766X, ISBN-13:9781461417668 Consuming Linked Open Data - First steps for consuming content as LOD

making, disaster management, knowledge management and/or market intelligence solutions.Organisations can benefit and reach competitive advantage through the possibility to: 1) spontaneously generate dossiers and information mash ups from distributed information sources; create applications based on real time data with less replication; and 3) create new knowledge out of this interlinked data. Quick guide for consuming LOD Here are the most important issues and milestones to consider when consuming LOD: Specify concrete use cases

Always specify concrete (business) use cases for your new service or application. What is the concrete problem you would like to solve? What data is available internally and what will you need from third party sources? Evaluate relevant data sources and data sets

Consuming LOD enables you to integrate and provide high quality information and data collections to mix your own data and third party information. These enriched data collections can act as single points of access for a specific domain in the form of a LOD portal and as an internal or Open Data warehouse system that enables better decision

Based on your concrete use case(s), the next step is to evaluate relevant LOD sources for data integration. Find out what data sources are available and what quality of data these third party sources offer (data quality is often associated with the information source itself; well known organisations usually provide high quality data and information). A very good approach

for this evaluation is to use a LOD search engine like Sindice [1] or one of the globally available Open Data catalogues such as The Data Hub [2]. Also consider data set update cycles and when the data was last updated. Check the respective licenses

Evaluate the licenses for use and re-use provided by the owners of the data. Avoid using data where no clear and understandable license is available. If in doubt, contact the respective data holders and clarify these questions. It is also important to know what license these data sets provide for mashing up data sets with others. Create consumption patterns

Creating consumption patterns specifies in detail exactly which data is re-used from a certain data source. Not all data in a set will be relevant to the specified use case(s), in which case you can develop consumption patterns that clearly specify only the relevant data in the set. Manage alignment, caching and updating mechanisms

When LOD is consumed, the need for matching different vocabularies of the consumed (internal and external) data sets often occurs. This is relevant to ensure smooth data integration by vocabulary alignment [3]. Another concern is the fact that LOD sources are not absolutely stable nor always available to consume

data in real time. To prevent a specific data set from being unavailable at a certain time, create caching mechanisms for specific third party data and information. Another important issue is to consume up-to-date information; a feasible approach here is to implement updating mechanisms for LOD consumption. Please see the ‘Linked Open Data Tool Box Collection’ at the end of this chapter for more information. Create mash ups, GUIs, services and applications on top

To serve your users and to create powerful LOD applications or services on top of mashed up LOD, it is crucial to provide user-friendly graphical user interfaces (GUIs) and powerful services for end users. Establish sustainable new partnerships

When using third party data and information, contact the data providers to build new partnerships and offer your own data for vice versa use. As a conclusion, please consider some best practice examples for consuming LOD from these LOD players: ll UK Organograms: http://data.gov.uk/organogram/ hm-treasury ll reegle.info country profiles: http://www.reegle.info/countries ll EU project: LATC – Linked Open Data Around-The-Clock: http://latc-project.eu

Links [1] Sindice – the semantic web index: http://sindice.com/ [2] The Data Hub: http://thedatahub.org [3] Vocabulary / Ontology Alignment on Wikipedia: http://en.wikipedia.org/wiki/ Ontology_alignment Further Reading ll Second International Workshop on Consuming Linked Data: http://km.aifb.kit.edu/ws/cold2011 ll Semantic Web for the Masses, paper by Lisa Goddard: http://firstmonday.org/htbin/ cgiwrap/bin/ojs/index.php/fm/ article/view/3120/2633 ll Linked Data: The Future of Knowledge Organization on the Web: http://www.iskouk.org/events/ linked_data_sep2010.htm ll Linked Data: Evolving the Web into a Global Data Space, Heath & Bizer: http://linkeddatabook.com Linked Open Data Tool Box Collection The Linked Open Data Tool Box Collection provides a list of important software tools and services for LOD publishing and consumption. ll PoolParty Product Family: http://www.poolparty.biz Services and tools for LOD-based metadata management, enterprise search, text mining and data integration

ll LOD2 Technology Stack: http://lod2.eu/WikiArticle/ TechnologyStack.html Technology stack for LOD by the R&D project LOD2 – Creating Knowledge Out of Interlinked Data ll Silk: http:// www4.wiwiss.fu-berlin.de/bizer/silk A link discovery framework for the web of data ll LIMES: http://aksw.org/Projects/ LIMES Link discovery framework for metric spaces ll Virtuoso Universal Server: http://virtuoso.openlinksw.com Universal server for Linked Data consumption, storage and retrieval ll Callimachus Project: http://callimachusproject.org A framework for data-driven applications using Linked Data ll Sindice: http://sindice.com The semantic web Index ll RDF Alchemy / The LOD Manager: http://www.semanticweb.at/ linked-data-manager Management suite for scheduling alignment, caching and ll updating mechanisms for LOD A good resource for LOD projects and suppliers (in the domain of eGovernment) is W3C‘s community directory, which was launched in late 2011: http://dir.w3.org

B1 - 5 Sterren toepassingen: niet zo logisch als het lijkt Auteurs

Paul Geurts (Gemeente Nijmegen) Thijs Brentjens (Brentjens Geo-ICT) Chris van Aart (2CoolMonkeys) Samenvatting Bij het maken van toepassingen zijn we er in de loop van de Pilot LOD tegenaan gelopen dat er nog een brug te slaan is tussen de aanbieders van Linked data en de app bouwers. Waar app bouwers graag tegen een JSON of REST service aanpraten, of de data zelf verzamelen en bewerken, heeft de wereld van linked data een eigen taal en logica die wat moeite kost om eigen te maken. Je loopt er als appbouwer tegenaan dat je een nieuwe semantische wereld instapt, waarin je moet investeren om hiervan kennis op te doen. De achtergrond en ervaring per ontwikkelaar lopen uiteraard hierover uiteen. Uiteindelijk krijgt het zijn meerwaarde, want de link tussen data ligt in de DNA van de data, in tegenstelling tot de huidige werkwijze waar de links door de app bouwer worden gelegd door de data bij elkaar te sprokkelen, dan wel door webservices aan elkaar te knopen. In de app wereld zou je dezelfde sterrenbenadering van linked data

kunnen toepassen als die bij de data al geïntroduceerd is. De werkgroep monumenten heeft zich binnen de Pilot gericht op het maken van toepassingen met Linked Data. Cultuurhistorie en monumenten is een gebied waar veel open data beschikbaar is en waar door het linken van data een wereld aan informatie vrij komt. Denk maar aan een historisch pand in je eigen omgeving. Wat is daar in het verleden gebeurd; hoe en wanneer is dit gebouwd; welke bouwwerken zijn er nog meer van deze tijd; welke gebouwen zijn nog meer van de hand van deze architect; wie heeft hier gewoond; en wat is zijn familieband. Het aantal links dat te leggen is, is al snel niet meer op twee handen te tellen.

Vier sterren data en vier sterren toepassingen Figuur 1 laat zien hoe het mogelijk is om verschillende bronnen met cultuurhistorische informatie te ontsluiten via één toepassing of gisviewer. Een dergelijke atlas geeft de gebruiker de mogelijkheid om te gaan grasduinen naar informatie over het onderwerp dat hij heeft gekozen. De gebruikte informatie wordt via open standaarden, via services aangeboden (4 sterren). De services zijn standaard, persistent, betrouwbaar en leveren actuele informatie. Links tussen diverse informatiebronnen worden binnen de applicatie gelegd

Figuur 1 - Een voorbeeld van de bestaande historische @tlas van de gemeente Nijmegen waar al tal van cultuurhistorische bronnen zijn ontsloten.

Figuur 2 - Gegevens van verschillende informatiebronnen samengebracht in ĂŠĂŠn detailscherm.

op basis van het koppelen van sleutelvelden. De applicatie is vervolgens zo ingericht dat je door het gebruik van deze sleutelvelden verschillende informatiebronnen kan raadplegen over bijvoorbeeld een gebouw. De beheerder van de applicatie bepaalt de logica voor de gebruiker en de gegevenssets die dan beschikbaar zijn. Elk detailscherm wordt door de beheerder geconfigureerd en wordt beperkt door de mogelijkheden van de applicatie. Hier is natuurlijk niets mis mee. Het gros van de huidige web-toepassingen wordt op deze manier gemaakt.

Op naar vijf sterren Je kan de parallel leggen tussen de sterrenwaardering voor data en toepassingen. In onderstaande schema is dit hier verder uitgewerkt. De linkbaarheid van data en het gebruik ervan bepaalt ook de linkbaarheid en de wijze van ontwikkeling van de toepassingen.

ll Het is niet meer de beheerder die de links legt en beheert, maar de gebruiker kiest het link-pad naar zijn eigen voorkeur. ll Voor de gebruiker is het niet meer noodzakelijk om tussentijdse resultaten, zoals namen of nummers op te schrijven om vervolgens een andere databron te raadplegen.

Figuur 3 - Een overzicht van de sterrenbenadering voor toepassingen.

Het gebruiken van Linked data in een vijfsterren toepassing kan op meerdere manieren leiden tot een verbetering. ll Het is niet meer nodig om elk detailscherm handmatig in elkaar te klikken en links te leggen. EĂŠn detailscherm kan volstaan. Dit scheelt beheer capaciteit.

Bijvoorbeeld de naam van de architect opzoeken en vervolgens op DBPedia deze zoekterm weer invoeren om verder te kunnen zoeken. ll Het beheer van de links zit niet meer bij de beheerder van de applicatie maar bij de beheerder van de gegevens.

We hebben voor de Pilot ontwikkelaars uitgedaagd om een app- of webtoepassing te maken door gebruik te maken van Linked Open Data. Te beginnen met de monumenten datasets van Nijmegen en Amersfoort, de rijksmonumenten van het RCE en de gegevens set van DBPedia. De beschikbare datasets zijn opgewerkt naar vijf sterren Linked Data, waarbij gebruik gemaakt is van al beschikbare vocabulaires. Om de resultaten te kunnen bekijken, is een linked-data viewer ontwikkeld. Een eenvoudige viewer waar de informatie gelinkt ontsloten is.

De linked data viewer Tijdens het werken met Linked Data in een ruw formaat, zoals RDFXML, is het soms lastig een beeld te krijgen van de data zelf. Om RDFXML gegevens te kunnen verkennen, bijvoorbeeld voordat je een applicatie gaat maken, is het handig deze in een andere vorm gepresenteerd te krijgen. Hiervoor is nog niet veel tooling beschikbaar. Met dit idee is, voor monument gegevens in het kader van Pilot, een eerste basale versie van de linked data viewer ontwikkeld. De viewer is bedoeld om (data)ontwikkelaars te helpen linked data te bekijken via een eenvoudige web applicatie.

Figuur 4 - De linked data viewer toont monument gegevens en biedt functionaliteit op basis van vocabulaires

De linked data viewer leest een RDF-XML bestand in en toont de gegevens. In dit geval selecties van monumentgegevens van Nijmegen en Amersfoort en BAG-adressen. Op zichzelf is het kunnen inlezen van gegevens uit verschillende bronnen niet zo spannend, maar de viewer is ook (beperkt) in staat tot interpretatie van gegevens, mits er bepaalde standaard definities gebruikt worden. De titels van een popup worden bijvoorbeeld niet geconfigureerd, maar herkend in de data. De viewer kan adressen, gemodelleerd met W3Câ&#x20AC;&#x2122;s Location Core vocabulary, daadwerkelijk herkennen uit de gegevens. Ongeacht of de gegevens monumenten zijn, BAG-adressen of welke dataset dan ook. Als de adressen gemodelleerd zijn met de juiste vocabulary, snapt de viewer dit gelijk. En kan de viewer hierop filteren. Dit daadwerkelijk kunnen interpreteren van gegevens, zonder aanvullende configuratie per dataset, kan hele krachtige, slimme en flexibele clients mogelijk maken. Op basis van definities kan op voorhand namelijk al functionaliteit geboden worden. Dit maakt de ontwikkeling van standaard toolboxen mogelijk voor vocabularies, waarmee client toepassingen op den duur sneller en flexibeler ontwikkeld kunnen worden. De demonstratie viewer is te vinden op nieuwsinkaart.nl/rdfgeo.

En nu een echte app Verschillende ontwikkelaars (vaak van mobiele en webapps) hebben zich aangemeld bij de Pilot om een toepassing te gaan ontwikkelen met Linked Data. Afhankelijk van de toepassing kiest men voor een harvesting model (bv CBS data) of een online model (Twitter feed). Zo leent een monumenten app, die de gebruiker vooraf thuis download, zich beter voor harvesting en het meegeven van de data op het device, dan deze online te blijven raadplegen. Binnen de Pilot is de open data goed ter beschikking gekomen, maar dat is nog geen vanzelfsprekendheid binnen Nederland. Het vrijgeven van data als open data staat nog in de kinderschoenen. Ontwikkelaars zien nog steeds, dat het niet kunnen beschikken over data, als grootste knelpunt voor de verdere ontwikkeling van Linked Data en de hierop gebaseerde apps. Als data eenmaal beschikbaar is, wordt dit buiten de Pilot meestal maximaal als 3 sterren aangeboden. Ook ontwikkelaars zien nadrukkelijk de meerwaarde van het publiceren van data als linked data, zowel als download als online service. Waar de services binnen de Pilot beschikbaar, betrouwbaar en snel zijn, geldt dit niet voor andere data services. Dit is te verklaren doordat het publiceren van Linked Data nationaal en wereldwijd nog in de

kinderschoenen staat. Daarnaast is het voor overheidsinstanties, die een groot deel van het open data aanbod voor hun rekening nemen, nieuw om dergelijke services 24x7 beschikbaar, 100% betrouwbaar en voldoende snel te publiceren en te beheren. Als mogelijke oplossing hiervoor kan een tussenlaag zijn die deze verantwoordelijkheid kan overnemen. Een dergelijke tussenlaag wordt door een onafhankelijke partij ingericht, een zgn. service broker. Deze partij zorgt ervoor dat gegevens op verschillende manieren, via services of downloads ter beschikking komen. Zij zorgen ervoor dat deze services altijd beschikbaar zijn, onafhankelijk van de bronleverancier. Er hebben zich inmiddels bedrijven gemeld die zich op deze markt gaan richten en hiervoor producten en diensten gaan ontwikkelen. Gedurende de Pilot is ervaring opgedaan met het gebruik van RDF. Het is duidelijk te merken dat deze standaard zijn oorsprong kent in de document georiĂŤnteerde beschrijvende wereld. De geo-component is nog duidelijk onderbelicht. Ontwikkelaars gebruiken bij voorkeur GML of SHP om in te lezen in de eigen ontwikkelomgeving.

Figuur 5 - De oorlogsmonumenten app van 2CoolMonkeys

Conclusies Op basis van de ervaringen rondom het ontwikkelen van toepassingen rondom het monumententhema kunnen we de volgende conclusies trekken. ll Het gebruik van Linked Data, zowel als download als online service biedt grote voordelen bij het ontwikkelen van toepassingen. Dit komt doordat links (naar bijvoorbeeld definities binnen de overheid) zijn opgeslagen in het DNA van de data.

ll Linked Data Services moeten beschikbaar, betrouwbaar en snel zijn. Binnen de Pilot is dit gelukt, maar daarbuiten liggen hiervoor nog veel kansen, zeker op het gebied van service brokers, die deze verantwoordelijkheid kunnen overnemen van de bronhouders van data en tailor-made kunnen klaarzetten voor afnemers. ll De hoeveelheid Linked Data is nog beperkt, ontwikkelaars van apps en leveranciers van data moeten hierin samen optrekken, dan komt het resultaat vanzelf. ll De geo-component binnen RDF is nog onderbelicht. De oorlogsmonumenten app die in het kader van deze Pilot ontwikkeld is, kan je downloaden via de app-store. Zoek op: monumenten. De app kan je ook vinden via opendata.nijmegen.nl zodra hij beschikbaar is.

B2 - Huiskluis: basis voor nieuwe diensten Auteurs

Paul Francissen (Envolve) John van Echtelt (CGI) De ‘Huiskluis’ is een praktijktoepassing ontwikkeld tijdens de landelijke Linked Open Data (LOD) Pilot. De Huiskluis ‘weet alles over je huis’. Hij bevat links naar data/informatie van overheden (basisadministraties), bedrijven en instellingen, maar ook van bewoners en eigenaren zelf. De Huiskluis biedt bewoners en eigenaren van verblijfsobjecten (woonhuizen, bedrijfspanden, instellingsgebouwen, etc) de mogelijkheid om informatie eenvoudig te verzamelen en op een veilige manier te delen met leveranciers, overheden, buren, hulpverleners, en anderen. De toepassing laat zien dat informatie over elk pand in Nederland op maat kan worden geleverd, met behulp van het linked data principe. En dat dit vele nieuwe toepassingen mogelijk maakt. De praktijkcase heeft een bijdrage geleverd aan de doelstelling van de Linked Open Data pilot door te tonen dat het mogelijk is om informatie over verblijfsobjecten uit verschillende bronnen bijeen te brengen en te ontsluiten voor nieuwe diensten.

Stel dat we alle data over een huis of bedrijfspand op één plek bijeen brengen; data van de overheid, van bewoners, van buren, van bedrijven en van apparaten. En dat we de bewoner/eigenaar de sleutel geven van deze digitale kluis zodat hij kan bepalen wie toegang krijgt tot die informatie. Welke nieuwe diensten zou dit mogelijk maken? Deze uitdagende gedachte kwam op tafel tijdens de eerste bijeenkomst van de Linked Open Data (LOD). Henk van de Berk, Floris de Bree (Arcadis), John van Echtelt (CGI), Christophe Guéret (KNAW/DANS), Paul Francissen (Envolve), Andreas Hoogeveen (Royal Haskoning DHV), Paul Janssen (Geonovum), Jan Kooijman, Marcel van Mackelenbergh (Belastingdienst) en Holger Peters (GemGids) hebben het idee in de maanden daarna uitgewerkt. Samen ontdekten zij dat het linken van data over een huis vele nieuwe toepassingen mogelijk maakt. Het idee kreeg de naam ‘Huiskluis’. In dit artikel beschrijven we het concept van de Huiskluis en de toegevoegde waarde die wij zien. Vervolgens werken we 3 usecases van mogelijke toepassingen uit. We ronden af met een blik op de toekomst en enkele gedachten ten aanzien van het vervolg.

Concept Een huis of bedrijfspand wordt omgeven door een wolk aan informatie. Denk aan vergunningen, bouwtekeningen, energieverbruik, facturen, foto’s en koopaktes. Die informatie staat her en der verspreid op het web en op andere plekken, is vaak lastig te vinden en lang niet altijd vrij toegankelijk. Dit beperkt bewoners in het gebruik ervan. De Huiskluis is een digitaal platform dat alle gegevens over een huis of bedrijfspand samenbrengt op één centrale plek. De bewoner kan hier zijn eigen informatie aan toevoegen. Vervolgens kan hij bepalen welke gegevens hij met wie deelt. Er ontstaat een gepersonaliseerd datadossier over een woning of bedrijfsgebouw, met informative/ data van bewoners/eigenaren en van derden. Denk aan: Hoe de straat er vroeger uitzag. Wie er ooit woonden of werkten. Wie de architect was. Het oorspronkelijke ontwerp. De WOZ-waarde. Energieverbruik. Vergunningaanvragen. Bestemmingsplan. Welstandseisen. Hoeveel zonne-energie zijn dak kan opwekken. Vuilophaaltijden. Welke foto’s op Flickr staan. Of het een monument is. Wat daarover op Wikipedia staat. Wat de renovaties kostten (facturen). Inbraakpreventie. Waar de ondergrondse leidingen liggen. Wie de producent is van de ramen en deuren.

Signalen van rookmelders. Info over wie er thuis zijn. Handleidingen van apparaten. Etcetera. Het combineren en uitwisselen van deze data maakt vele nieuwe diensten mogelijk. Zo kan een bewoner met zijn energiegegevens en dakafmetingen laten berekenen of zonnepanelen interessant voor hem zijn. Met zijn buren kan hij afspraken gaan maken over gezamenlijke inkoop en onderhoud of hij kan gegevens met hen delen, zoals een bouwtekening of oude foto’s. Zijn beveiligingsbedrijf laat hij weten wanneer hij op vakantie is. Voor een gemeentelijke vergunningaanvraag haalt een bewoner alle gegevens uit zijn Huiskluis. Samen met hulpdiensten verbetert hij de veiligheid door levensreddende informatie te delen. Zijn verzekeraar geeft hij toegang tot foto’s van mijn inboedel. Zijn aannemer laat hij weten waar de leidingen liggen. En als hij zijn huis verkoopt, kan hij een compleet woondossier ter inzage aanbieden aan potentiële kopers of een hypotheekverstrekker. De Huiskluis is een open community met gestandaardiseerde koppelvlakken. Hierdoor staat het voor iedereen vrij om nieuwe diensten te ontwikkelen, welke slim gebruiken maken van de waardevolle informatie en groepsfuncties die samenkomen in de Huiskluis.

Bij het gebruik van de Huiskluis gelden een aantal gebruiksregels. De bewoners/eigenaren bepalen welke persoonlijke informatie zij opnemen in hun Huiskluis en aan wie zij die informatie tonen en/of beschikbaar stellen. Derden kunnen de Huiskluis gebruiken om data te koppelen aan verblijfsobjecten en om diensten aan te bieden die gebruik maken van informatie uit de Huiskluis, mits de bewoner/eigenaar daarvoor toestemming verleent.

Toegevoegde waarde

Het concept voor de Huiskluis is uitgewerkt in een video en een videoanimatie. Kijk op www.huiskluis.nl voor meer informatie.

De Huiskluis is bijzonder doordat het openbare (‘open’) en persoonlijke (‘gesloten’) informatie bijeenbrengt en de bewoner in staat stelt deze

Het bijeenbrengen van open data over een huis op één centrale plek is op zich niet bijzonder. Althans, niet in de wereld van linked data. Zodra dataobjecten aan elkaar gekoppeld zijn via linked data, is een eenvoudige Google-search voldoende om snel veel informatie te vinden over een specifiek huisadres.

Wat is dan wel bijzonder aan de Huiskluis?

Figuur 1 - Beelden uit de video-animatie over de Huiskluis

informatie te bewerken en te delen met anderen. Daarmee krijgt de bewoner controle over zijn gegevens en kan hij gebruik door derden toestaan. Bovendien maakt de Huiskluis een huis ‘digitaal bereikbaar’, iets wat met bestaande social media niet mogelijk is. De combinatie van ‘kluis’ en ‘messaging service’ maakt nieuwe diensten mogelijk.

Trends Het idee voor een Huiskluis-achtig digital platform is niet (geheel) nieuw. Er zijn initiatieven geweest zoals Privver en de Digitale Brievenbus om digitale informatie af te leveren op een huisadres. Ook zijn er diverse initiatieven om (open) data te koppelen aan huisadressen, zoals Funda en de app Open Huis. Voorzover bekend is de combinatie van functionaliteiten zoals hier beschreven voor de Huiskluis, nog niet eerder aangeboden. Of de Huiskluis daarmee voorziet in een brede behoefte weten we niet. Wel zien een een aantal trends waarop de Huiskluis zou kunnen aansluiten: ll Open data; steeds meer (overheids)data over woningen, bedrijfspanden en omgeving komt beschikbaar ll Slimme huizen; er is een ontwikkeling van slimme, begrijpelijke en toegankelijke technologische oplossingen en diensten in de persoonlijke woon- en leefomgeving. Denk aan beveiliging, zorgtoepassingen, draadloze bediening van

apparaten, etc. Slimme huizen sluiten daarmee aan op ‘smart cities’ en ‘smart grid’. Privacy; mensen hechten meer en meer waarde aan controle over de data die samenhangt met de persoonlijke levensfeer Cloud; netwerkdiensten maken het mogelijk snel toegang te geven tot nieuwe applicaties en mogelijkheden voor data-opslag Any device; er is een behoefte om apparaat-onafhankelijk te kunnen werken met applicaties en data Zelforganiserend vermogen vergroten; door inzet van internet en social media ontstaan nieuwe initiatieven tot samenwerking. Denk aan gezamenlijk inkoop van zonnepanelen, samenwerking in de wijk, etc. Sociale cohesie in de wijk; er is veel aandacht voor verbetering van samenhang in buurten en wijken Smart disclosure; slimme manieren om data te ontsluiten zodat het beter gebruikt kan worden in toepassingen

Mogelijke toepassingen Tijdens diverse brainstormsessies is nagedacht over mogelijke toepassingen van de Huiskluis. Een greep uit de ideeen die naar voren kwamen is weergegeven in de tabel op de volgende pagina. In bijlage 1 zijn drie toepassingen uitgewerkt tot usecases.

Mogelijke toepassingen van met gebruik van de Huiskluis Algemene informatie ll gepersonaliseerd informatiedossier via google ll welke bedrijven zitten in de buurt van de woning ll het weer bij mij thuis Financieel ll bepaling woz-waarde en uitwisselen met andere bewoners ll waardeontwikklingprognose ll kostenberekening: wat kost mijn huis ll mogelijkheden om huis te verbeteren ivm waardestijging Historie ll geschiedenis van mijn huis ll app met tijdlijn wat heeft het huis meegemaakt ll verhalen/boeken koppelen aan gebouwen foto’s delen ll monumenteninformatie ll archieven koppelen aan je huis Sociaal/organisatie ll gluren bij de buren, wat verkopen de buren op marktplaats? ll linken met gegevens van vereniging van eigenaren ll woningcorporatie kan onderhoud beter regelen door bewoners te laten meedenken en –beslissen ll afspraak; als iemand in de buurt komt krijg je een bericht ll zelfredzamheid bevorderen in de buurt

ll leen mijn spullen/ mijn auto ll bezorgafspraak maken met buren voor als je niet thuis bent ll Veiligheid ll huisdiagnose: welke risico’s gelden ll gevaarlijke bedrijven in de omgeving ll gegevens beschikbaar stellen aan buren/hulpdiensten als er een rookmelder afgaat ll mensen bereiken in geval van calamiteiten in straat of buurt Energie en milieu ll afsluiting energiecontracten ll inkoop zonnepanelen ll energievergelijken met soortgelijke huizen ll milieugegevens in kaart ll energiewedstrijd: wat verbruik je tov iemand anders Verzekeringen/hypotheken ll voorkomen van dubbele verzekeringen ll inboedel beter verzekeren met foto’s ll toegang tot informatie voor hypotheekverstrekking Overheidsdiensten ll gemeentelijkediensten: afval, bekendmakingen ll publiek rechtelijke beperkingen ll koppeling kadastrale uitreksels ll vergunningenhulp: alle relevante documenten meesturen

Onderhoud ll gezamenlijke inkoop ll tuinonderhoud ll onderhoudsplan ll documenten over onderhoud opslaan ll garantiebewijzen en handleidingen van producten Verkoop ll betere informatie bij verkoop: als ik wist dat die info beschikbaar was, was ik er nooit gaan wonen ll complete digital dossier meeleveren ll alle infomatie voor koopakte etc. bijeen op één plak ll publiek rechtelijke beperkingen ll notaris heeft gegevens over het huis ll verhuisknop: welke data blijft op dit adres Zorg en domotica ll huis automatisch op slot als je ver van je huis bent ll thuiszorg: dossiers koppelen aan een huis ll domoticavoorzieningen: in kaart brengen via Huiskluis ll burencontact: ik ken veel buren maar weet niet hoe ze heten Fun en gaming ll fun: wat zit er exact aan de andere kant van de wereld?

Een blik in de toekomst Steeds meer apparaten in ons huis worden verbonden met het internet. Uw huis wordt een ‘smart home’.Via uw digitale thermostaat kan u weersgegevens open delen met anderen. Uw wasmachine zal zelf aangeven wanneer een onderdeel aan vervanging toe is. Via uw digitale TV provider is bekend welke on demand film u wanneer heeft bekeken. Uw beveiligingssysteem heeft de bewakingsbeelden van uw huis ergens in de cloud opgeslagen. Slimme huizen veranderen de manier waarop we leven. Energieverbruik meters, op internet aangesloten huishoudelijke apparaten, op afstand bedienbare deursloten en in-house video bewaking brengen ons gemak, maar genereren ook enorme gegevenssets. Smart home producten verzamelen daarmee buitengewoon gedetailleerde gegevens over ons leven. Deze gegevens heeft waarde voor de rechtshandhavers, marketeers en hackers. Er is tegenwoordig al veel te doen over uitwisseling van persoonsgebonden informatie. Overheden, veiligheidsdiensten en bedrijven vragen nu al bij internet providers en mobiele telefoonaanbieders om persoonlijke gegevens van klanten. Deze informatie wordt verstrekt zonder de persoon om wie het gaat op de hoogte te stellen.

Nu onze huizen ook veel gegevens gaan produceren, zal de uitwisseling van huisgebonden informatie stijgen. Leveranciers van digitale TV-diensten, verzekeringsmaatschappijen en energiebedrijven en beveiligingsbedrijven zullen – al dan niet tegen betaling – huisgebonden informatie gaan verstrekken en uitwisselen. Onbevoegde gebruikers kunnen steeds makkelijker toegang krijgen tot gedetailleerde privé-informatie over uw thuissituatie. Daarom wordt een betrouwbare oplossing voor privacy gerelateerde vragen steeds belangrijker. Wie krijgt er toegang tot welke gegevens over uw huis? In onze visie mogen gegevens over je huis niet open worden gedeeld zonder dat de bewoner het weet. Daarom vinden we data huisgebonden informatie in de Huiskluis moet kunnen opgeslagen. De bewoner houdt de digitale huissleutel in handen en bepaalt zelf welke andere partijen over welke gegevens mogen beschikken.

Hoe nu verder In essentie gaat het bij de Huiskluis om ‘slim ontsluiten’ van open en gesloten data. Op 30 mei 2013 heeft de Task Force on Smart Disclosure van de Amerikaanse National Science and Technology Council het rapport ‘Smart Disclosure and Customer Decision Making’ uitgebracht. Dit

rapport onderstreept het belang om (open) data ‘direct’ en ‘bruikbaar’ aan consumenten beschikbaar te stellen. De Taskforce stelt dat nieuwe direct bruikbare datagedreven producten en diensten (zoals zorgdiensten, energiediensten) de transparantie vergroten en consumenten in staat stellen om betere keuzes te maken over aankopen. Dit maakt markten efficiënter, concurrerender en innovatiever en daarmee draagt het bij aan werkgelegenheid en economische groei. Location-Linked Data wordt in het rapport onderkend als een type data dat verschillende consumentensectoren overstijgt. In many domains, consumers are interested in finding out about products, services, and issues near where they live or in other specific locations. For example, smart disclosure data about local schools, recreation facilities, environmental quality, and other factors can help consumers decide where to buy or rent a home. Het rapport is een oproep aan overheidsinstellingen om in hun open data beleid veel meer aandacht te besteden aan ‘smart disclosure’. Een van de middelen is publiek private samenwerking. Wij willen vanuit deze gedachte de Linked Open Data pilot graag een praktisch vervolg geven.

Overheid, kennisinstellingen en bedrijven kunnen gezamenlijk een open project starten waarin de architectuur en de core van de Huiskluis wordt gerealiseerd. Er wordt een prototype gebouwd en in proof of concepts worden de ontologie en privacy-aspecten uitgewerkt. Gedurende deze pilot kan de overheid een ‘slim ontsluitingsbeleid’ formuleren en gezamenlijk worden afsprakenkaders voor het ontsluiten en uitwisselen van aan verblijfsobjecten gerelateerde informatie opgesteld. Daarna kunnen commerciële organisaties innovatieve Huiskluis gerelateerde diensten realiseren welke voorzien in de behoefte van bewoners en voldoen aan het ‘slim ontsluitingsbeleid’.

Referenties ll Dosi, G. (1982). Technological paradigms and technological trajectories. Research Policy, 11, pp.147-162. ll Kuhn, T.S. (1970). The Structure of Scientific Revolutions. III. Chicago: University of Chicago Press, 2nd Ed.

Bijlage 1: Usecases Huiskluis Om het idee van de Huiskluis verder uit te werken werd een aantal usecases bedacht. Hieronder worden deze beschreven. Usecase ‘er is brand in mijn huis’ Het is een gure zaterdagavond. Het heeft gesneeuwd en er staat een stevige noordoosten wind. Karel en Linda zijn een weekendje weg en opa en oma passen op de kinderen en blijven slapen. Opa heeft de open haard weer eens lekker opgestookt. Freek slaapt dit weekend bij zijn natuurlijke moeder. Om 11 uur gaat iedereen lekker slapen. De open haard is uit. Om 12.30 krijgt de brandweer via 112 een brandmelding. Schoorsteenbrand in het huis van Karel en Linda de Vries. Alles is donker, maar er komen vlammen uit de schoorsteen en de vonken vallen op het rieten dak. De brandweercommandant roept zijn collega’s op en om 12.37 rijdt het eerste brandweervoertuig uit. Via het informatiesysteem in het voertuig wordt alle informatie verzameld. Daarbij wordt ook de Huiskluis van het huis van Karel en Linda de Vries geraadpleegd. Die hebben hulpdiensten geautoriseerd om in geval van nood informatie uit de digitale kluis te halen. Brandweercommandant Piet leest de informatie en verdeelt de taken. In de Huiskluis vindt hij in welke vertrekken mensen slapen.

100

Er is haast geboden. Op zolder, direct onder het rieten dak, slapen Freek en Frits. Ze zijn 4 en 6 jaar oud. In de Huiskluis vindt men ook de contactgegevens van bewoners, omwonenden en familie. Het mobiele nummer van Karel wordt gebeld. Er wordt niet opgenomen… Gelukkig wordt er bij de ouders van Linda wel opgenomen. Via hen is het nummer van het hotel waar Karel en Linda verbleven snel opgespoord. Ook is het nu duidelijk dat opa en oma in het huis zijn. De ouders van Linda weten niet zeker of Freek dit weekend thuis slaapt. Bij het huis aangekomen ziet commandant Piet dat het rieten dak inmiddels vlam heeft gevat. Brandend riet vliegt door de lucht. De commandant schat in dat alle huizen binnen 200 meter ter zuidwesten van het huis direct gevaar lopen. Hij informeert de kazerne dat direct omwonenden direct hun huis uit moeten. In de kazerne wordt direct zichtbaar welke huizen gebeld moeten worden. Via de Huiskluis wordt een noodbericht verstuurd en alle bewoners worden tegelijkertijd geinformeerd via een boodschap op hun mobiele telefoon. De meesten melden direct terug dat ze het noodbericht hebben ontvangen. De huizen die niet reageren worden als eerste bezocht door de burgerbrandweer.

Commandant Piet ziet op dat moment een klein jongetje huilend het huis uit komen. Hoi Frits, hoe is het met je jongen? Heb je pijn?, vraagt hij. ‘Nee, ik ben mijn beer kwijt’. Dan gaan er twee brandweermannen het huis in. Via de Huiskluis hebben zij een plattegrond van het huis en weten ze waar de hoofdschakelaar zit. Ook weten ze dat er zuurstofflessen in de bijkeuken liggen. Die moeten als eerste weg. Via de kazerne krijgt hij Karel aan de lijn. Piet vraagt gelijk aan Karel of Freek in het huis slaapt of bij zijn moeder is. Karel bevestigd dat Freek bij zijn moeder slaapt. De brandweer hoeft niet de brandende zolder niet in. Door de goede samenwerking en de beschikbare informative in de Huiskluis werd iedereen snel gered en was er zelfs nog gelegenheid om het familieportret uit de kamer te halen. Piet is er trots op dat hierdoor werd veel schade voorkomen. Op de weg terug naar de kazerne rijdt de brandweer langs het huis van de ouders van Linda. Ze stoppen even om kleine Frits zijn beer terug te geven.

101

Use case ‘het huis dat ik lief heb’ In het huis waarin ik woon, woonde mij opa en de opa van mijn opa. Zolang is het al in de familie. Er is veel gebeurd rondom dit huis. Vroeger lagen hier alleen akkers. Nu is er een snelweg langsgekomen en is de hooischuur verbouwd tot slaapkamers. Graag deel ik de kennis over het huis voor toekomstige generaties of bewoners. Om de verhalen rondom mijn huis te vertellen stel ik een informatiedossier samen. Met zoveel mogelijk relevante informatie over mijn huis en omgeving, van mijzelf en van derden. Dat maak ik toegankelijk maken voor eenieder die geïnteresseerd is. Over welk soort informatie/data gaat het? Het gaat om informatie van de bewoner zelf. Zoals historische foto’s, films, bouwtekeningen, oude kaarten, ontwikkelingen in de buurt, tekeningen, geschreven documenten, etc. En het gaat ook om data van derden. Zoals archieffotos, luchtfoto’s, grondwaterstanden, leidingen ondergrond bronnen met verwijzing naar huis, zoals boeken, bodem, websites, kadastrale informative, etc. Bij het samenstellen van het dossier maak ik gebruik van de Huiskluis. Die geeft mij direct toegang tot alle informatie te die standaard al beschikbaar is over mijn huis en omgeving (open data). Waaronder informatie van archiefdiensten. Ook vind ik via de Huiskluis data die door andere

enthousiastelingen over de straat/ buurt beschikbaar is gemaakt (zoals de foto’s die door een archivaris aan het huis zijn gelinkt). En ik krijg als bewoner de mogelijkheid om informative van anderen van commentaar te voorzien. De Huiskluis helpt mij ook bij het vinden van online diensten/apps die mij helpen om historische informatie te verzamelen (historischefotos. nl). Die helpen me ook om te bepalen welk soort informatie je zelf beschikbaar kunt stellen over een pand, en hoe je die informatie vindt. Ze helpen bij het maken van mooie presentaties. De Huiskluis laat mij bepalen wie toegang krijgt tot de informatie. Mijn persoonlijke fotos’s zijn alleen toegankelijk voor mijn familie. Andere foto’s deel ik met de archiefdiensten en met de buren. De Huiskluis helpt mij ook bij de overdracht van het dossier naar nieuwe bewoner. Usecase ‘ik wil mijn huis verkopen’ Ik wil mijn huis verkopen. Om kopers te interesseren stel ik een informatiedossier samen. Met zoveel mogelijk relevante informatie over mijn huis en omgeving, van mijzelf en van derden. Dat maak ik toegankelijk maken voor potentiële kopers. Het gaat om een grote hoeveelheid informatie: ll Van mijzelf: facturen van onderhoud, renovatie, etc., onderhoudscontracten (glazenwasser,

102

schilder, cv, tuin, etc), energierekeningen, foto’s van onderhoud/ renovatie (leidingen, etc), planten in de tuin, incl onderhoudsplan, fotos (van jezelf en van anderen), tekeningen, ideeën/plannen/tips voor verbetering van het pand, beschrijving van de wijk, leverancier van mijn keuken, etc., link naar aannemers,  historie, maatregelen voor inbraakpreventie, info over Vereniging van eigenaren (incl notulen, etc.), aanbevelingen van buren hoe fijn het is om er te wonen/werken. ll Van derden (open data): vergunningen, bestemmingsplan, grondwaterstanden, leidingen ondergrond, criminaliteit, scholen/kinderopvang, archieffotos/ tekeningen, bodem, luchtkwaliteit, verkeer, fotos, websites (bijv van leverancier van keuken), energieverbruik / energielabel, BIM rapport incl 3d visualisaties en motivatie tot keuzes, etc. Om het dossier samen te stellen maak ik gebruik van de Huiskluis. Die helpt mij met het verzamelen van alle informatie die standaard beschikbaar over mijn huis en omgeving (open data). Als bewoner heb ik de mogelijkheid om een toelichting te geven bij die informatie. Bijvoorbeeld bij het bestemmingsplan geef ik aan dat er een uitzonderingsgrond is voor de dakgoothoogte. De Huiskluis geeft me ook tips welk soort informatie ik

zelf beschikbaar kan stellen over mijn pand en hoe ik die vind/verzamel. Ook wordt ik geholpen bij het vinden van apps die mij helpen om een mooie presentatie te maken van die informatie. Via de Huiskluis kan ik de verzamelde informatie koppelen aan verkoopdossier bij makelaar of op funda.  Doordat de Huiskluis werkt op basis van links is van veel informatie ook bekend wie de bronhouder is en wat de betrouwbaarheid is. Een koper hoeft dus niet te twijfelen aan de echtheid van een koopakte of een verstrekte vergunning. De Huiskluis biedt mij de mogelijkheid om te bepalen welke informatie ik met wie wil delen. Wie mag welk deel van het informatiedossier inzien, en op welk moment in het verkoopproces? Wanneer het huis is verkocht draag ik de Huiskluis met alle informative over het huis over aan de nieuwe eigenaar. Hij heeft da nook meteen alle foto’s en tekening van de renovaties en verbouwingen die ik de afgelopen jaren heb laten uitvoeren.

B3 - Branden blussen met Linked Open Data Auteurs

Bart van Leeuwen (Netage) Lian Pattje (Geonovum) Erwin Folmer (Geonovum) Samenvatting Informatie is van cruciaal belang voor de brandweer. Beslissingen moeten in zeer korte tijd en onder hoge druk gemaakt worden, daarbij gebruik makend van alle informatie die voor handen is. In het huidige tijdperk, mede in het kader van Open Data, is er zeer veel informatie over onder meer gebouwen, verkeersinformatie, chemische stoffen, etc. beschikbaar maar wordt niet altijd gebruikt. De nachtmerrie voor een brandweerman is om verkeerde noodlottige keuzes te maken doordat beschikbare informatie niet is meegenomen in de besluitvorming. De brandweer (in samenwerking met Netage) is daarom volop bezig om de mogelijkheden van Linked Open Data in de praktijk te testen om beschikbare en relevante open data aan elkaar te linken gericht op het inzetten voor een calamiteit (zoals een brand). Dit paper geeft inzicht in de problematiek en de uitdagingen van een brandweerkorps, en hoe Linked Data ingezet kan worden voor betere ontsluiting van relevante databronnen.

‘Mijn grootste angst is dat mij of mijn collega’s iets overkomt tijdens een brand en dat we dat hadden kunnen voorkomen met alle aanwezige informatie binnen onze organisatie’, vertelt Bart van Leeuwen. Als ergens een brand is, dan moeten we binnen vier minuten ter plaatse zijn. We denk op dat moment in ‘chaos’ en rijden met 120 db door de straten. Het klinkt vast niet vreemd als we zeggen dat we ondertussen geen andere apparaten kunnen bedienen. Navigatie werkt voor ons niet (hoor je het al ‘keer nu om’…), smartphones niet en tablets en boeken met allerhande informatie zijn prima, maar helpen ons op dat moment ook niet verder. Zo hebben we handboeken vol met achtergrondinformatie over bijvoorbeeld complexe panden zoals het Anne Frankhuis. En van parkeergarages weten we vaak wel hoeveel plaatsen er nog beschikbaar zijn, maar wat wij willen weten is: hoeveel auto’s zijn er op dat moment in een garage? Als brandweer hebben we behoefte aan slimme koppelingen van data die ons de juiste inzichten geven, die nodig zijn bij incidenten. Maar er zullen ook altijd ‘vreemde’ incidenten blijven, denk aan de brand bij Chemie-Pack. Het grote punt daar was dat er een grote ton met aceton stond die daar nooit had mogen staan. En wij wisten daar niets van. Dus wat zijn we gaan doen? Die brand is volledig uit de hand gelopen. Werkelijk alle plannen

104

en alle informatie die er op dat moment waren, konden zo de prullenbak in. Dat zijn momenten waarop je gewoon moet durven gaan en vreemde situaties moet durven tackelen. Dan moet je werken binnen de werkelijkheid. Op een gegeven moment zijn we zelf met RDF aan de slag gegaan en het resultaat daarvan is dat er nu in de kazerne een scherm hangt waarop iedereen meteen kan zien waar een incident in de stad zich voordoet. En wat wij nu gebruiken aan linked data? Met de Kamer van Koophandel zijn we aan het kijken welke data, die we hebben, we open kunnen maken. Verder halen we gegevens uit de BAG viewer en informatie over weten regelgeving halen we van overheid. nl. We werken nu aan een firebrary, om alle complexe terminologie die bij de brandweer gebruikt wordt, goed in op te slaan. Daarmee zijn we nog niet op het punt waar we willen zijn. Brandweermannen moeten allereerst nog veel beter geĂŻnformeerd worden. Om een voorbeeld te noemen: er rijdt iemand met een brandende auto in een hele oude parkeergarage, waar weinig informatie over bekend was. Wat doe je dan? De brandweer is uiteindelijk die garage in gegaan, waarbij ze enorm belemmerd werden door de rookontwikkeling. Na onderzoek bleek dat die parkeergarage al na 15 minuten brand niet meer veilig was.

Dan vraag je je wel af: hoe hadden we kunnen voorkomen dat onze mannen toch naar binnen gingen? In de toekomst willen we ook zelf linked data maken, ook samen met commerciĂŤle partijen. Hoe mooi zou het zijn als alle hotels in Amsterdam steeds realtime de bezettingsgraad van hun hotelkamers doorgeven?

B4 - Linked Data & semantiek: we begrijpen elkaar steeds beter Auteur

Marijke Salters (Bureau Forum Standaardisatie) Waarom dit artikel? Dit artikel is geschreven omdat er op dit moment steeds meer behoefte ontstaat naar betekenisvol uitwisselen van gegevens (semantische interoperabiliteit) en Linked Data een oplossing lijkt te bieden. De behoefte aan semantische interoperabiliteit is steeds groter omdat: ll De interactie met de burger en het bedrijfsleven steeds vaker geautomatiseerd plaatsvindt, waardoor de betekenis van de begrippen steeds belangrijker wordt, denk aan voorinvulling van de belastingaangifte. ll Onderlinge gegevensuitwisseling tussen overheidspartijen steeds vaker voorkomt, waarbij het ontbreken van een betekenis van een gegeven verstrekkende gevolgen kan hebben voor de betrokken burgers of bedrijven waarover de gegevensuitwisseling gaat. Denk aan het belang van een correct adres voor het verkrijgen van een uitkering.

ll De wet ‘éénmalige uitvraag’ draagt bij aan de noodzaak om hergebruik van gegevens toe te passen, terwijl iedere wet een eigen interpretatie van een gegeven kent. Er zijn bijvoorbeeld wettelijk 20 beschrijvingen van een varken, waarbij iedere beschrijving een eigen nut heeft binnen de context van die wetgeving. Sinds een jaar of drie wordt de Linked Data methodiek steeds vaker aangehaald als dé oplossing voor semantische problematiek. Linked Data is een methodiek die het verbinden en integreren van alle gegevens die men wil delen mogelijk maakt via webtechnologie. Deze methodiek wordt vaak genoemd in relatie tot het semantische web, wat ook suggereert dat het bijdraagt aan het begrijpen van gegevens (semantiek). In dit artikel een korte analyse of deze methodiek die belofte kan waarmaken. Het artikel beschrijft de mogelijke rol van Linked Data als open methode voor semantische interoperabiliteit Dit artikel is geschreven voor de geïnteresseerde leek met enige bekendheid met informatietechnologie, zodat hij de waarde van Linked Data beter kan inschatten. Aan het eind van het artikel zal de vraag beantwoord moeten worden: Is Linked Data een oplossing voor het probleem van semantische interoperabiliteit?

106

Wat is semantische interoperabiliteit? Semantische interoperabiliteit is in dit artikel het betekenisvol uitwisselen van gegevens. Semantiek is betekenisleer. Interoperabiliteit is de mogelijkheid van verschillende systemen, om met elkaar te communiceren en interacteren. Om dit te bewerkstelligen zijn standaarden, protocollen en procedures nodig. Dit artikel is geschreven vanuit het perspectief van de Nederlandse Overheid. De overheid heeft behoefte aan gegevensuitwisseling tussen overheidspartijen onderling en met bedrijven en burgers. De gegevensuitwisseling tussen partijen (interoperabiliteit) kan op verschillende niveaus beschouwd worden. Deze niveaus zijn in een raamwerk samen te vatten. (zie hieronder, bron: EIF)

Tot nog toe hebben de gekozen open standaarden binnen de Nederlandse overheid met name betrekking op de onderste, technische interoperabiliteitslaag. Deze open standaarden zorgen voor de mogelijkheid om in ieder geval gegevens tussen partijen uit te kunnen wisselen, qua transport en berichtafspraken. Semantiek vormt de tweede laag binnen dit raamwerk. Deze laag zorgt voor het betekenisvol uitwisselen van gegevens.

Wat is semantiek? Semantiek is betekenisleer. De semantiek of betekenisleer is een wetenschap die zich bezighoudt met de betekenis van symbolen, waarbij het in het bijzonder de bouwstenen van natuurlijke talen die voor de communicatie dienen ofwel woorden en zinnen betreft.

Figuur 1 EIF-model

107

Bedrijven en overheidsorganisaties bewaren, bewerken en ontsluiten hun elektronische informatie al lang niet meer binnen de grenzen van ĂŠĂŠn bedrijfsproces of informatiesysteem. Toch zijn maar weinig processen en systemen goed voorbereid op het onderling delen en combineren van informatie. Semantiek gaat over de inhoud, de betekenis en de bedoeling van uitgewisselde informatie. Het meest gebruikte voorbeeld om de betekenis van een begrip te beschrijven is het woordenboek. In het woordenboek kom je verschillende soorten van beschrijving tegen: ll Definitie van een begrip op basis van synoniemen ll Een verwijzing naar mogelijke context in voorbeeldzinnen ll Optioneel: beschrijving via eigenschappen van een begrip.

De woordenboekmethode is internationaal geaccepteerd en gebruikt. Ter illustratie in Figuur 2 een foto van een begripsbeschrijving in het oude vertrouwde woordenboek (bron Dikke van Dale). We zien vijf betekenissen van behandeling. Deze vijf zijn aangegeven door vijf aparte beschrijvingen met eigen synoniemen. Voor alle vijf de betekenissen worden voorbeelden gegeven in een zin om de juiste context aan te geven.

Wat is Linked Data? Linked Data biedt een set openstandaarden en technieken waardoor publicatie en het verbinden van gegevens mogelijk wordt. De bedoeling van Linked Data is het verbinden en integreren van alle gegevens die men wil delen. Linked Data is een webtechnologie benadering, die ook als semantisch web of web 3.0 gezien Figuur 2 Woordenboek

108

wordt. Hierbij spelen de gegevens zelf een substantiële rol met betekenis, ongeacht het document of de oorsprong van het bestand. De bijbehorende Linked-Data principes die door Tim Berners-Lee [1] in 2006 beschreven zijn, zijn: ll Gebruik URI’s als namen voor dingen [2] ll Gebruik http URIS’s zodat deze namen opgezocht kunnen worden ll Als iemand gebruik maakt van de URI, zorg voor zinvolle informatie, op basis van open standaarden (RDF, SPARQL) ll Zorg voor links naar andere URI’s, zodat meer dingen ontdekt kunnen worden De belangrijkste eigenschap van de Linked Data methodiek is de verbinding tussen gegevens. Zoals hierboven blijkt maakt de Linked Data methodiek gebruik van verschillende open standaarden.

Hoe ontstaat de verbinding tussen de gegevens? Het mechanisme om de verbindingen te maken, wordt geleverd door het ‘Resource Description Framework’ (RDF). Dit mechanisme wordt ook elders in deze publicatie uitvoerig beschreven. In RDF wordt de relatie beschreven door het verstrekken van een datamodel dat gegevens in de vorm van <onderwerp>-<predikaat><object> triples codeert. Het onderwerp en het doel van een dergelijke triple zijn beide URI’s. Deze identificeren elk een bron. Door een URI wordt ook beschreven hoe het subject en object zijn gerelateerd. Predikaat URI’s komen uit woordenlijsten die verzamelingen zijn van URI’s die relaties in een bepaald domein beschrijven.. Als voorbeeld: <medicijntoediening> <is een> <behandeling> Door het gebruik van ontologieën kan de ‘kennis’ over het specifieke domein verrijkt worden. Een ontologie is een bijbehorende structuur. Bijvoorbeeld behandelingen bestaan uit medicijntoediening, consulten en fysiotherapie. Deze ontologieën kunnen beschreven worden met een gerelateerde standaard: OWL [3]. Deze geregistreerde informatie kan worden uitgevraagd met behulp van de query language SPARQL. Bijvoorbeeld: Welke behandelingen zijn mogelijk?

109

Draagt de Linked Data methode bij aan begripsvorming? Heel ‘plat’ en instrumenteel vertaald: Kan Linked Data de rol van een woordenboek vervullen? 1. Zoals hiervoor geïllustreerd kan in een woordenboek een begrip beschrijven aan de hand van synoniemen. Dat is een begrip met een ‘is gelijk aan’ -relatie naar een ander begrip. Deze rol kan Linked Data zeker op zich nemen. De bovenstaande vijf betekenissen van behandeling en hun synoniemen zijn zeker vorm te geven met behulp van RDF. Als voorbeeld: <geneeskundige verzorging> <is een> <behandeling>. 2. Daarnaast wordt in het woordenboek de context beschreven in de vorm van zinnen waarin het begrip kan voorkomen. De Linked Data methodiek biedt hier ook de elementen voor. Een grammaticaal juiste zin kan bestaan uit een onderwerp (object) een werkwoordelijk gezegde (relatie/predicaat) en een leidend voorwerp (subject). In het woordenboek is echter de relatie tussen het te verduidelijken begrip en de voorbeeldzinnen vast. Vergelijk behandeling is gelijk aan in behandeling nemen in de context van wetgeving. Alleen een voorbeeldzin, waarin de term behandeling in de context van deze betekenis geïllustreerd wordt is zinvol. Voorbeeld: Hier kunnen we constateren dat de combina-

tie van beide niet zal lukken door het gebruikmaken van 1 ‘triple’, de toevoeging van de context vergt een quad. Voorbeeld uit het woordenboek: <behandeling> <is> <geneeskundige verzorging>, maar alleen in een bepaalde context. In het woordenboek staat daarvoor de zin ‘onder behandeling van dokter R. zijn’. Of: te wel: <dokter R> <is een> <geneesheer> en bepaalt daarmee de betekenis van <behandeling> nl: synoniem aan <geneeskundige verzorging>. Gesimplificeerd, zonder echte voorbeeldzin: <behandeling> <is> <geneeskundige verzorging> in de context van <geneeskunde> . Deze gevolgtrekking kan gemaakt worden als een <geneesheer> <behoort bij> <geneeskunde> 3. De beschrijvingswijze van een begrip aan de hand van eigenschappen/ attributen is via Linked-Data standaarden mogelijk. Het ‘heeft een’ predicaat kan gebruik worden voor attributen/ eigenschappen. Voorbeeld: Iedere behandeling (in alle vijf betekenissen) heeft een doorlooptijd als eigenschap. Een geneeskundige behandeling heeft een behandelend geneesheer als eigenschap. Door de set eigenschappen kan de ‘lezer’ de betekenis afleiden of interpreteren.. Bovenstaande drie voorbeelden tonen aan dat in vergelijking met het woordenboek de elementen voor de

110

functie van het woordenboek beschikbaar zijn. Het meegeven van de context door een voorbeeldzin is mogelijk, maar behoorlijk complex. Kortom het lijkt erop dat Linked Data als methodiek de rol van een woordenboek kan vervullen en betekenis aan begrippen kan toevoegen. De vervolgvraag is: Kan de omvorming naar Linked Data met de huidige stand van de automatisering uitgevoerd worden? Met andere woorden is de betekenis van de gepubliceerde informatie ook nu beschikbaar, zodat omvorming volgens deze methode mogelijk wordt? Helaas blijkt dit niet het geval. De huidige gegevens in databases zijn niet op deze manier opgezet. De structuur van een bestaande database gaat uit van data in velden, waarbij de betekenis van de velden binnen het werkgebied (context) al vaststaat. Deze betekenissen zijn niet gespecificeerd binnen de database. De ontwerpspecificaties zijn vaak allang verdwenen. Ieder veld kent dus een eigen betekenis binnen het werkingsgebied van de database. Voor semantische interoperabiliteit is begrip op metaniveau over de werkingsgebieden (lees databases) nodig. Dit is niet te vinden in de huidige digitale informatie, maar zal door een persoon moeten worden toegevoegd. De kwaliteit van de beschrijving hangt daardoor sterk af van

de menselijke factor. Alleen de ‘lezer’ kan goed interpreteren wat bijvoorbeeld met het woord ‘behandeling’ als veldnaam bedoeld wordt. In vergelijking: de velden in de databases moeten door kenners van de materie via een handmatige bewerking betekenis krijgen. Daarna kunnen deze gegevens een relatie krijgen naar andere velden in andere bestanden die hetzelfde betekenen. De kwaliteit van de relaties kan heel verkeerd uitpakken, denk bijvoorbeeld aan homoniemen. Een homoniem heeft eigenlijk geen relatie: Vergelijk de zinnen: Ik gaf haar een ring voor haar verjaardag. Of: Hij ging in de tweede ronde in de ring knockout. A≠A.

Wat kan Linked Data bijdragen? (2 cases) Juriconnect Doelstelling van het Platform Juriconnect, een samenwerkingsverband tussen meerdere overheidspartijen, is om met de betrokken partijen in de informatieketen van juridische informatie gezamenlijk te komen tot eenduidigheid in informatie-uitwisseling, structurering en metadatering. Het oogmerk hierbij is om de informatie zowel bij de bron, de leverancier, als bij de afnemer efficiënt en doeltreffend te kunnen beheren en in de werkprocessen toe te kunnen passen. Daarbij wordt een efficiënte inrichting van de informatieketen nagestreefd,

111

waarbij informatie- en waardetoevoeging zo dicht mogelijk bij de bron plaatsvindt en redundantie wordt tegengegaan. Gestreefd wordt met name naar gebruik van, respectievelijk standaardisatie in: ll Standaard-ID’s en verwijzingen naar weten regelgeving en jurisprudentie; ll Standaard-ID’s en verwijzingen naar andere informatiesoorten in het juridisch informatiedomein; met name: Internationale verdragen, officiële publicaties, commentaren, tijdschriftartikelen en boeken; ll Standaard ID’s en verwijzingen voor EU-jurisprudentie en –regelgeving; ll Uitwerking van gezamenlijke metadata op hoofdniveaus. Om deze doelstelling te bereiken is gekozen voor de Linked Data methodiek. De wetgeving brengt vele contexten bij elkaar en de kern van de Linked Data methodiek is dat er meerdere ‘waarheden’ (en dus meerdere contexten) zijn toegestaan. Tegelijkertijd biedt het daarmee inzicht in al deze verschillende waarheden. Het eerste wat bij dit project nodig bleek was een URI strategie. De Linked Data methode heeft deze nog niet gestandaardiseerd, terwijl de afspraak hoe een URI opgebouwd

wordt essentieel is voor de vindbaarheid, als er sprake moet zijn van domein overstijgende uitwisseling. Stelselcatalogus De stelselcatalogus biedt een overzicht van alle basisregistraties en de bijbehorende informatie elementen. Basisregistraties zijn registraties die door meerdere overheidsinstanties hergebruikt worden. Denk hierbij aan het GBA en de BAG. Evaluatie van het gebruik van de huidige Stelselcatalogus en wijzigende informatiebehoefte is in 2012 aanleiding geweest voor het realiseren van een toekomstvisie voor de Stelselcatalogus. Vanuit deze heroriëntatie heeft de stuurgroep Stelselcatalogus opdracht gegeven voor de ontwikkeling van Stelselcatalogus 2.0. De Stelselcatalogus 2.0 gaat de betekenis van (authentieke) gegevens en begrippen in de onderscheiden basisregistratie zodanig presenteren dat eigenaren van bedrijfsprocessen kunnen beoordelen of zij dit nuttig kunnen gebruiken in het eigen bedrijfsproces. De Stelselcatalogus 2.0 slaat een brug tussen begrippen uit het Stelsel van Basisregistraties en (nieuwe) wetgeving. De Stelselcatalogus gaat hiermee een brugfunctie vervullen tussen de wereld van informatici en de wetgevingsjuristen. Hiermee ontstaat transparantie van gegevens en begrippen. Daarbij wordt intensief

112

ingezet op een betere en actuelere vulling van de Stelselcatalogus, waarbij de basisregistraties nadrukkelijk worden betrokken en een grotere rol krijgen. Om dit te bereiken is ook hier gekozen voor de Linked Data methodiek. Dit project heeft nu al aangetoond dat de toevoeging van een vierde element (de context) van een gegeven nodig is om de betekenis als informatie element te definiëren. Het project maakt daarom gebruik van Quad’s in plaats van Triple’s: Daar waar de triple het formaat kent: <onderwerp> <predicaat> <object>, volgen quads het formaat: <context> <onderwerp> <predicaat> <object>. Het voorbeeld hiervan vindt u in de paragraaf: ‘Draagt Linked Data bij aan begripsvorming? Punt 2.’

Wat zijn de voor- en nadelen van een Linked Data methodiek voor semantische interoperabiliteit? Hieronder een aantal voor- en nadelen die ook door de projecten Juriconnect en de Stelselcatalogus 2..0 worden ervaren.

Voordelen ll Het gebruikte RDF mechanisme is domein neutraal. Linked Data is hierdoor te gebruiken voor ieder domein. Dit blijkt uit de toepasbaarheid voor beide projecten. Iedereen kan een eigen werkelijkheid publiceren via Linked Data. ll Er zijn veel aanvaarde open standaarden die het RDF-construct ondersteunen. Zoals SPARQL en OWL, zowel Juriconnect als de Stelselcatalogus maken hier gebruik van. ll Er zijn veel semantische webtechnologieën, in verschillende volwassenheidsstadia, zoals zoektechnologieën, collectieve kennissystemen en redeneermechanismen. De stelselcatalogus is opgebouwd uit verschillende webtechnologieën, die samen de catalogus inzichtelijk maken. Zie: http://bit.ly/13UeAJz. ll Er is een toenemend aantal hoogwaardige domeinontologieën. De twee genoemde cases publiceren de eigen ontologieën en dragen hierdoor bij aan verbetering van het aantal domeinanthologieën. ll RDF kan gelezen worden door de mens, maar is bedoeld om inhoud machinaal verwerkbare en begrijpelijk te maken. Voor een project als de Stelselcatalogus is inzicht belangrijk, het feit dat RDF leesbaar is door een mens draagt bij aan de transparantie van het stelsel van basisregistraties.

113

Nadelen of tekortkomingen ll Expressiviteit met behulp van alleen triples is te beperkt voor het meegeven van context. Het project ‘de nieuwe stelselcatalogus’ maakt daarom gebruik van de zogenaamde quad’s of toevoegingen van context. ll Het ontbreken van begrip of ontologie op metanivo . Dit is een gevolg van de automatiseringsaanpak tot nog toe en is dus heel algemeen. Voor samenhangende data over domeinen (databases) heen is nooit een ‘grand design’ geweest, dus deze is nu ook niet te vinden. De vraag is of deze achteraf nog te maken is? Voorbeeld: de interactieve plaat van het stelsel is achteraf gemaakt en over de exacte betekenis van de peilen

(relaties) tussen de basisregistraties is nu nog geen helderheid. Wat geen semantiek kent kan ook niet uitgewerkt worden in een semantische taal. Conversie van bestaande ongestructureerde content, maar ook van gestructureerde content uit databases is een enorme taak zijn. Computers zijn over het algemeen juist geschikt voor geautomatiseerde conversies, maar bij betekenisgeving is handmatige bewerking of controle nodig. Juriconnect probeert redundantie tegen te gaan, maar in de praktijk is zonder menselijke analyse niet te bepalen of het ene gebruikte begrip in de wetgeving echt hetzelfde betekent als het andere gebruikte begrip. Laat staan of een hele wet eigenlijk redundant is.

114

Conclusies Is Linked Data een oplossing voor het probleem van semantische interoperabiliteit? Het antwoord is: We begrijpen elkaar steeds beter, door het gebruik van betere methoden, zoals LinkedData , maar de volledige oplossing is nog niet beschikbaar. Hierboven is onderbouwd dat de Linked Data methodiek de rol van een woordenboek kan vervullen. De Linked Data methodiek biedt een sjabloon voor betekenistoekenning waar iedereen op kan aansluiten. Daardoor biedt het de belofte van een semantisch netwerk over organisatiegrenzen heen. Een groot voordeel daarbij is de openheid van deze set standaarden. Iedereen kan ze gebruiken. Het wenkend perspectief is een worldwide semantic web: Elk gegeven als spin in het web van een netwerk. Maar handmatige inspanning voor semantische interoperabiliteit zal altijd noodzakelijk blijven . Een verkeerd geĂŻnterpreteerde relatie/link is snel gemaakt, maar heeft in een volledig gelinkte omgeving grote gevolgen. Want ook voor Linked Data geldt â&#x20AC;&#x2DC;garbage in, garbage outâ&#x20AC;&#x2122;. Misschien nog wel meer dan ooit te voren. De impact van vrijblijvend linken van bestaande

data all over the World is veel groter dan in de conventionele systeemontwikkeling. Aan de andere kant: alle gepubliceerde informatie krijgt direct reactie van de vele communities die de publicaties op het internet volgen. Linked Data zal een zelfregulerend geheel moeten worden. Een kwestie van tijd? De migratie van de huidige situatie, waarbij de gegevens in databases staan in velden zonder toelichting, zal zeker niet vanzelf gaan. De relatie met bestaande technische standaarden in het EIF schema, waarmee tot nog toe de gegevensuitwisseling plaatsvindt zijn bijvoorbeeld nog nooit onderzocht. Kortom we zijn er nog niet, maar hoe meer gegevens via Linked Data beschikbaar komen hoe beter we elkaar gaan begrijpen.

115

Voetnoten

Bronnen

[1] Sir Tim Berners-Lee (Londen, 8 juni 1955) is samen met zijn toenmalig manager, de Belg Robert Cailliau, de bedenker en grondlegger van het World Wide Web (WWW). [2] De term URI staat voor Uniform Resource Identifier. Deze identificeert een term/object op het internet. Voorheen werden URLâ&#x20AC;&#x2122;s gebruikt. Dit staat voor Uniform Resource Locator , hierbij werd alleen de vindplaats van een pagina. aangegeven. Een URI is specifieker dan een URL. [3] In het semantisch web wordt ontologie als aanduiding gebruikt. Binnen het semantisch web moet een computer de betekenis van tekst en metadata kunnen afleiden en op basis van die betekenis kunnen redeneren en gevolgtrekkingen maken. (bron wikipedia)

ll Linked-Data, Opportunities for the Dutch e-Government , Marijke Abrahamse, MIM 27, March 4th 2013 ll http://www.e-overheid.nl/ onderwerpen/ stelselinformatiepunt/ stelsel-van-basisregistraties/ stelselvoorzieningen/ stelselcatalogus ll http://www.geonovum.nl/content/ slimmer-hergebruiken-met-linkeddata ll http://en.wikipedia.org/wiki/ Named_graph ll https://www.ictu.nl/archief/noiv.nl/ weblogs/bart-knubben/2011/ 02/23/het-web-is-plat-2/ index.html ll http://www.novay.nl/projecten/ essence/7781 ll www.wikipedia.org ll Van Dale: Het groot woordenboek der Nederlandse taal, deel a\i

B5 - Casus OnderwijsBegrippenKader: de basis onder Educational Linkedscape Auteurs

Jeroen Hamers Jos van der Arend Leonie Verhoeff Henk Nijstad (allen Kennisnet, leden van Bureau EduStandaard), Jeroen van Vuuren (Verdonck, Klooster en Associates). Het OnderwijsBegrippenkader (OBK) is dé gemeenschappelijke online database met alle onderwijsbegrippen en hun onderlinge relaties – te beginnen met de niveaus en het curriculum. Het OBK is ontstaan in 2012 als oplossing voor knelpunten in de Educatieve Contentketen (ECK) bij het zoeken en vinden van leermateriaal. Doel van het OBK is om er voor te zorgen dat alle informatiesystemen in het Nederlandse onderwijs dezelfde onderwijstaal spreken door middel van het uniek identificeren en definiëren van de begrippen met hun onderlinge relaties. De inhoud van het OBK is volgens de semantisch web principes opgeslagen in een RDFstore en wordt als open linked data beschikbaar gesteld. De RDF-store kan op meerdere manieren worden uitgelezen: Direct uitvragen door middel van een SPARQL end point, via

een specifieke API of via een specifieke webbased ‘browser’. De governance van het OBK is ondergebracht bij EduStandaard, het operationeel beheer bij Kennisnet. Het toepassingsgebied van de uitbreidingen van de inhoud wordt in toenemende mate breder dan alleen de Educatieve Contentketen: het OBK zal als generieke voorziening voor eenduidigheid en duurzaamheid in alle onderwijssemantiek een rol gaan spelen. Het OBK wordt zodoende de basis onder alle uitwisselingen binnen het ‘Educational Linkedscape’. Een OBK-promotiefilmpje vindt u op Youtube: http://youtu. be/ddkBk7WBaho Het OnderwijsBegrippenkader (OBK) is dé gemeenschappelijke online database met alle onderwijsbegrippen en hun onderlinge relaties – te beginnen met het curriculum. Het OBK is ontstaan in 2012 als oplossing voor knelpunten in de Educatieve Contentketen (ECK) voor het zoeken en vinden van leermateriaal. Het toepassingsgebied is echter veel breder: het OBK kan als generieke voorziening voor eenduidigheid en duurzaamheid in de onderwijssemantiek een rol spelen in toepassingen in alle richtingen van het onderwijsdomein, van het personaliseren van leerlijnen tot het internationaal benchmarken van onze Nederlandse opleidingen. Het OBK is een belangrijk onderdeel voor realisatie van het zogenaamde

117

kun je er mee en welke toepassingen worden beoogd? Daarnaast wordt er technische uitleg gegeven en worden toekomstige ontwikkelingen geschetst. Beide delen kunnen los van elkaar gelezen worden.

De ontstaansgeschiedenis van het OnderwijsBegrippenkader

Educational Linkedscape (ELS), de door Jeroen Hamers (Kennisnet, 2011) ontwikkelde visie over hoe we alle onderwijsgerelateerde data in de onderwijsketens kunnen delen. ELS is een groeimodel, een structuur die ingevuld moet worden en op bescheiden schaal begint. Iedere ketenpartner met relevante data kan meedoen, uiteraard met respect voor privacy en eigendom. ELS is gebaseerd op linked data en het semantisch web. Door data op een standaard wijze op te slaan en te omschrijven, wordt het uitwisselbaar. Het semantische web beschrijft informatie en verrijkt deze door relevante verbanden te leggen. In het eerste deel van dit artikel worden de ontwikkelingen beschreven die hebben geleid tot het OBK en de dienstverlening er omheen. In het tweede deel wordt het OBK uitvoerig beschreven en wordt antwoord gegeven op vragen als: wat is het, wat

Het OnderwijsBegrippenkader is ontstaan uit jarenlange ervaring binnen de Educatieve Contentketen (ECK). Dit is de keten voor het ontwikkelen, de toegang en het gebruik van educatieve (online) content. In dit eerste deel geven we een beeld van de ontstaansgeschiedenis en de ontwikkelingen tot aan dit moment.

Fase 1: Behoefte aan uitwisselen gegevens Rond 2004 ontstond er binnen de regionale en agrarische opleidingscentra (ROC’s en AOC’s) de behoefte om meer webgebaseerd digitaal leermateriaal te gaan gebruiken. Dit bracht een aantal vraagstukken met zich mee met betrekking tot het zoeken en vinden, de uitwisseling l en gebruik van het materiaal. Deze behoefte lag aan de basis van de start van het programma ‘Educatieve ContentKeten’ dat gericht was op de hele keten van ontwikkelen van materiaal tot en met het gebruik binnen het primair onderwijs (PO), voortgezet onderwijs (VO) en beroeps- en volwassenen educatie (BVE). Het richtte zich op het

118

wegnemen van de volgende gesignaleerde knelpunten: ll Gebrekkige standaardisatie: zowel voor de vindbaarheid van leermateriaal als voor de uitwisselbaarheid en het gebruik in verschillende leeromgevingen. Er waren in Nederland nauwelijks afspraken over het gebruik van internationale standaarden en specificaties. ll BarriĂ¨res bij contentontwikkeling: de ontwikkeling van webbased leermateriaal kwam onvoldoende op gang. Er waren geen goede exploitatiemodellen voor de ontwikkeling ĂŠn exploitatie van educatieve content. ll Verspreide initiatieven: er werd wel gewerkt aan het succesvol inzetten van leermateriaal in het onderwijs, maar er was beperkte uitwisseling van de resultaten, waardoor partijen niet van elkaar konden leren. Om deze knelpunten op te lossen zijn binnen het programma Educatieve ContentKeten toen verschillende projecten gestart. Een belangrijk deel van het programma bestond uit het gezamenlijk komen tot afspraken binnen de keten. Er werd aan een groot aantal afspraken gelijktijdig gewerkt. Om deze afspraken in perspectief te zien werd een overkoepelende architectuur ontwikkeld. De figuur hiernaast geeft weer welke hoofdprocessen binnen

119

de keten werden geïdentificeerd en waar binnen het programma aan de standaardisatie van de informatieuitwisseling gewerkt werd (de rode pijlen in het figuur). Een van eerste standaardisatie initiatieven was om te komen tot een afspraak over hoe in de keten leermateriaal eenduidig werd beschreven in metadata en hoe deze metadata uitgewisseld werd. Het betrof dus een afspraak over zowel de semantiek als de syntax van deze metadata. Deze afspraak werd op meerdere plekken in de keten gebruikt als onderdeel van de afspraken omtrent het uitwisselen van informatie binnen de keten. Zo zag een eerste versie van het ‘ContentZoekprofiel’ (CZP) in maart 2004 het levenslicht. Deze afspraak was gebaseerd op de internationale standaard ‘Learning Objects Metadata’ (LOM) en werd beschouwd als het Nederlandse toepassingsprofiel hiervan. LOM beschrijft zowel de semantische betekenis van eigenschappen (de velden) waarop gemetadateerd wordt als ook voor een deel het waardebereik wat gebruikt mag worden (vocabulaires). LOM is deels weer gebaseerd op de meer generieke Dublin Core standaard. De LOM-standaard bestaat uit een 9 onderdelen, waarvan met name veld 9 belangrijk is voor de relatering van het leerobject aan een curriculum: Het zogenaamde Classification-veld. Dit veld beslaat

de informatie uit voorgedefinieerde classificaties waarmee het leerobject vanuit een bepaald perspectief kan worden beschreven. Deze classificatie wordt niet door LOM voorgeschreven en is vrij. Het beheer van de afspraak werd belegd bij een gezamenlijke opgerichte vereniging ‘Edustandaard’. Tevens werd er binnen de keten een centrale zoekvoorziening, genaamd ‘Edurep’, ingericht die de metadata conform het CZP kon ontvangen en het middels een standaard interface doorzoekbaar maakte voor andere systemen en websites. Hiermee was er een goede basis gelegd voor de ‘Vinden’ stap in de educatieve contentketen, waar de eerste ervaringen mee opgedaan konden worden. Inmiddels is het CZP geharmoniseerd met LoreLOM (het toepassingsprofiel voor het hoger en wetenschappelijk onderwijs) tot NL LOM, de bij Forum Standaardisatie gedeponeerde metadatastandaard voor de hele onderwijskolom.

Fase 2: Behoefte naar betekenisvollere gegevens Nadat de afspraken waren gemaakt konden de systemen worden opgezet en aangepast. De jaren daarna lag de focus op het op gang krijgen en het gebruik van de standaarden. In die jaren werd een flink aantal grotere en kleinere collecties met digitaal leermateriaal aangesloten op Edurep zoals Davindi, de Digischool, de collecties van het Freudenthal Instituut, Klas-

120

Cement en de SchoolTV Beeldbank. Ook ontstonden er websites waar in de metadata gezocht kon worden en boden elektronische leeromgevingen zoals Teletop / ItsLearning mogelijkheden om door de content te zoeken op basis van de metadata. Door de toenemende groei van het gebruik van de standaarden uit de ECK voor het zoeken. kwam ook een aantal knelpunten hierin naar boven: ll Behoefte aan gedetailleerdere metadata aan de hand van classificaties. ll Beheer van het groeiend aantal vocabulaires. ll Herkennen van dezelfde begrippen en relaties tussen begrippen. Behoefte aan gedetailleerdere metadata aan de hand van classificaties

In het ContentZoekProfiel waren maar 9 velden verplicht, het ging hier met name om zeer algemene velden. Deze velden waren voor veel toepassingen niet voldoende voor het gericht kunnen zoeken naar leermateriaal. Een manier om specifieker te kunnen zoeken was door het gebruik van de mogelijkheid om specifieke classificaties binnen het CZP-record op te nemen. Het aantal gebruikte vocabulaires voor deze classificaties groeide op basis van deze behoefte. Zo werden vanuit Stichting Leerplan Ontwikkeling (SLO) een aantal vocabulaires opgesteld voor onder andere de vakken in het primair en voorgezet onderwijs.

Beheer van het groeiend aantal vocabulaires

Groeien in het aantal vocabulaires is natuurlijk een goed teken maar brengt ook een beheerverplichtingen met zich mee. Vanuit EduStandaard werd hiervoor een beheerproces ingericht voor het komen tot gemeenschappelijke vocabulaires. Er werd een ‘vocabulairebank’ ingericht door Kennisnet waarin het overzicht van de vocabulaires was opgenomen. Herkennen van dezelfde begrippen en relaties tussen begrippen

Bij het ontstaan van meerdere vocabulaires groeide de vraag of er overlap en relaties bestaan tussen de verschillende (versies van) vocabulaires. Zo kwam ‘Nederlands’ of ‘ Nederlandse taal’ voor in zowel de vocabulaire voor vakken voor PO als voor het VO. De vraag is of hier dan wel of niet sprake is van dezelfde term. Tevens kan je in dit voorbeeld de behoefte zien aan het leggen van relaties tussen begrippen. Je zou je voor kunnen stellen dat je één vocabulaire hebt voor vakken en door middel van relaties gaat aangeven welke vakken op welk niveau (PO, VO, enz) wordt gegeven. Deze discussie was de opmaat naar het ontstaan van het OnderwijsBegrippenKader (zie de volgende fase).

121

Fase 3: Behoefte naar uitwisselen gegevens en relaties Inmiddels, we spreken rond 2010, zijn er tientallen vocabulaires geregistreerd in de VocabulaireBank van Kennisnet. Hoewel het gebruik van de termen in de vocabulaires flink toeneemt door de groei van centrale voorzieningen als Edurep, wordt duidelijk dat diverse grote knelpunten een structurele doorgroei belemmeren. In januari 2011 start daarom het project â&#x20AC;&#x2DC;Ontwikkelen en beheren vocabulairesâ&#x20AC;&#x2122; binnen het programma ECK2 (Zie kader). Het programma Educatieve Contentketen 2 (ECK2) is gebaseerd op een integrale ketenbenadering met als doel ICT binnen het onderwijs beter te benutten en efficiĂŤnter in te zetten. Het programma is een unieke samenwerking tussen diverse belangrijke ketenpartijen uit het onderwijsveld zoals de educatieve uitgevers (GEU), SLO en Kennisnet, ondersteunt met subsidie van het Ministerie van Onderwijs gedurende 2011 en 2012. Door deze partijen is gezamenlijk gewerkt aan het bevorderen van aanbod, vindbaarheid, toegankelijkheid en bruikbaarheid van digitale leermiddelen. Op die manier kunnen docenten steeds vaker en eenvoudiger digitaal leermateriaal in de leermiddelenmix toepassen.

De belangrijkste knelpunten met betrekking tot het gebruik van vocabulaires ten behoeve van de vindbaarheid van leermateriaal zijn: Taken en verantwoordelijkheden

ll Het is niet duidelijk wie regie heeft bij het proces om een vocabulaire toe te voegen, en bovendien is niet transparant hoe het besluitvormingsproces plaatsvindt. Procedures

ll De doorlooptijd om een vocabulaire aangemeld te krijgen wordt als lang ervaren. ll De releasecycli van vocabulaires zijn onduidelijk en de regie hierop lijkt te ontbreken. Versiebeheer

ll De relatie tussen meerdere termen in vocabulaires wordt onvolledig bijgehouden en is moeilijk toegankelijk. ll Wijzigingen in vocabulaires dienen zo min mogelijk werk op te leveren voor collectie-eigenaren. ll Vocabulaires dienen zo actueel mogelijk te zijn.

122

Vocabulairemodel

ll Het vocabulairemodel dient voorbereid te zijn op de toekomstige toepassingen, het model dient dus flexibeler te worden en geschikt te worden voor geavanceerde toepassingen. ll Eigen, specialistische vocabulaires moeten kunnen worden gerelateerd aan bestaande, gangbare vocabulaires. Ge誰nspireerd door internationale ontwikkelingen, met name het Achievement Standards Network(zie kader in deel twee) in de VS, adviseert het ECK2-project om vocabulaires voortaan te baseren op een gezamenlijk begrippenkader, waarin onderwijsbegrippen en hun onderlinge relaties als open linked data beschikbaar zijn. De belangrijkste voordelen hiervan zijn: ll Groeimodel: het is niet nodig van te voren al alle mogelijke begrippen en relaties te kennen. De semantische verbanden kunnen geleidelijk aan rijker worden, naarmate daar behoefte aan ontstaat. Je kan dit vergelijken met metadata van een leerobject: eerst geef je het een titel en wat trefwoorden mee, maar na verloop van tijd ontstaat er de behoefte om ook vast te kunnen leggen voor wie het bedoeld is, over welk vak het gaat en welk leerdoel er mee kan worden behaald. De LOM metadata standaard kende daar veel beperkingen.

ll Open en gelinkt: Door het gebruik van semantisch webstandaarden wordt de semantiek en de techniek ontkoppeld en kan het op een gestandaardiseerde open manier worden aangeboden. Het wordt gemakkelijker van het begrippenkader te verwijzen naar de omgeving en vanuit de omgeving te verwijzen naar het begrippenkader. Samen met SLO als ontwikkelaar van leerplannen voor het PO en VO is Kennisnet in 2012 hard aan de slag gegaan met het advies vanuit ECK2. Inmiddels is het advies dan ook realiteit geworden en wordt het OBK als reguliere dienstverlening door Kennisnet aangeboden.

Deel 2 - Het OnderwijsBegrippenKader In dit hoofdstuk wordt uitgelegd wat het doel van het OBK is, hoe het datamodel er uit ziet, uit welke architectuur en systemen het OBK is opgebouwd, hoe de governance is ingericht en welke toekomstige ontwikkelingen er aan zitten te komen. Als algemene inleiding kunt u ook het OBK-promotiefilmpje bekijken op Youtube.

123

Doel van het OBK Doel van het OnderwijsBegrippenKader (OBK) is om er voor te zorgen dat alle informatiesystemen in het Nederlandse onderwijs, zoals elektronische leeromgevingen, zoekmachines als Wikiwijs en de systemen van educatieve uitgevers, dezelfde onderwijstaal spreken. Het OBK kan in alle domeinen van het onderwijs worden gezet denk hierbij aan de volgende toepassingen: ll Vinden - aanbieden en vinden van relevante leermiddelen, ook internationaal, ll Verrijken - eenvoudiger verrijken van leermiddelen, door het automatisch koppelen van gerelateerde lesmaterialen, ll Personaliseren - leren op basis van de behoefte van de leerling, mogelijk gestuurd door beslissingsondersteunende systemen, ll Vastleggen – vastleggen wat is geleerd, op een betekenisvolle manier, zodat dit ook (internationaal) kan worden uitgewisseld, bijvoorbeeld voor het bevorderen van studentmobiliteit. ll Vergelijken - benchmarken van leerplannen en leermaterialen, ook als basis voor wetenschappelijk onderzoek,

ll Verantwoorden - ontwikkelen van (geautomatiseerde) verantwoordingsinstrumenten - afstemmen wat wordt geleerd en wat wordt getoetst, ll Afstemmen - betere afstemming van leermiddelen en leerstrategieën op toetsen gebaseerd op nationale leerdoelen, ll Hergebruiken – eenvoudiger leerplannen, leerlijnen en leermaterialen hergebruiken, ll Oriënteren – eenvoudiger overzicht verkrijgen van leerplannen en leerlijnen bij leerdoelen.

Datamodel Iedere partij die voor het onderwijs relevante begrippen heeft kan deze aanmelden voor opname mits de begrippen aan bepaalde criteria voldoen. Op dit moment bevat het OBK veel begrippen die afkomstig zijn van SLO die het curriculum beschrijven (Leerplan in beeld, de kernprogramma’s) zoals vakken, vak- en subkernen, onderwijsinhouden, kerndoelen en leerniveaus. Ook van andere partijen, zoals bijvoorbeeld de MBO Raad, zijn relevante begrippen zoals bijvoorbeeld opleidingsdomeinen en studierichtingen, domeinoverstijgende vakken zoals loopbaan en burgerschap opgenomen. In de volgende paragrafen worden een aantal onderdelen van het model toegelicht.

124

Begrippen en relaties In het onderwijsbegrippenkader dienen ten minste de belangrijkste eigenschappen van een begrip vastgelegd te worden: ll Een unieke, persistente identifier ll Een omschrijving van het begrip ll EĂŠn of meerdere aanduidingen van het begrip ll De relaties met andere begrippen

Relaties die tussen begrippen kunnen bestaan, zijn zo mogelijk nog belangrijker, ze voegen context en betekenis toe. Ook deze relaties dienen rijk te worden beschreven. Deze begrippen en relaties kunnen onder andere gebruikt worden voor het samenstellen van vocabulaires. Deze vocabulaires kunnen in machine leesbare vorm (XML, VDEX) o.a. gebruikt worden

125

voor het metadateren van leermateriaal (in repositories) of zoeken naar leermateriaal (in zoekportalen). Het is afhankelijk van de wens en de beoogde toepassing van de gebruiker welke begrippen/termen er in een dergelijke vocabulaire opgenomen worden. Begriptypes en eigenschappen Elk begrip (BkBegrip) in het OBK is van een van de ‘hoofdtypes’ (itemType). Er zijn op dit moment vier itemTypes: Inhoud, Niveau, Doel en Kenmerk. Deze itemTypes zijn een hoog niveau indeling van de begrippen. Elk van de itemTypes hebben weer specifieke subtypes. Elk BkBegrip is dus ook van

In de VS is ASN (Achievements Standards Network) al sinds eind jaren 90 bezig met het als linked open data beschikbaar stellen van onderwijsbegrippen en hun relaties (detail curriculum). http:// asn.jesandco.org/. Het ASN is een uitbreidbaar raamwerk om leerlijnen mee te beschrijven, en een verzameling van digitaliseerde leerlijnen van vijftig staten in mens èn machine leesbare vorm. Oa. de veelgebruikte Common Core State Standards on Math and English zijn via de ASNmethodiek beschikbaar. Het ASN wordt algemeen beschouwd als dè basis voor de volgende generatie onderwijs.

het type van één of meerdere specifieke subtypes. Zo is het BkBegrip ‘Wiskunde A’ van het itemType ‘Inhoud’ en het subtype ‘Vak/leergebied’. Naast het itemType en subtype wordt van elk BkBegrip ook een aantal standaard eigenschappen vastgelegd, zoals bijvoorbeeld wie de beheerder (heeftBKbeheerder) is, wat de geldigheidsperiode van het begrip is (heeftBkGeldigheidsperiode), wat de voorkeursaanduiding is (skos:prefLabel) en een omschrijving (skos:description). Deze eigenschappen zijn deels gebaseerd op SKOS (Simple Knowledge Organization System) en deels onderwijsbegippenkader specifiek. Zie de figuur op de vorige pagina voor een schematische weergave van de typeringen en eigenschappen van elk begrippenkaderbegrip. Begriprelaties Zoals vermeld, zij er op dit moment 4 item itemTypes: BkNiveau, BkDoel, BkInhoud en BkKenmerk. Een begrip van het type ‘inhoud’ is geschikt voor een bepaald ‘niveau’ en heeft een bepaald ‘doel’ en kan een relatie met een andere (bijvoorbeeld gedetailleerdere) ‘inhoud’. De mogelijke relaties per itemType zijn in de figuur op de volgende pagina weergegeven. Zo wordt ‘Economie’ (Inhoud) op bijvoorbeeld zowel de ‘HAVO’ (Niveau) als VWO (Niveau) gegeven, heeft het onder andere het doel ‘De

126

leerling kan invloed van inflatie op de koopkracht uitleggen en rekenkundig onderbouwen’ en heeft het onder andere ‘Welvaart en groei’ en ‘Ruil’ als ‘vakkern’ (inhoud). Concreet, worden deze relaties in het begrippenkader als volgt vastgelegd en gepubliceerd (relatie onderstreept):

ll ‘Economie’ heeftBkNiveau ‘HAVO’ ll ‘Economie’ heeftBkNiveau ‘VWO’ ll ‘De leerling kan invloed van inflatie op de koopkracht …’ isBkDoelVan ‘Economie’ ll ‘Welvaart en groei’ isBkDeelinhoudVan ‘Economie’ ll ‘Ruil’ isBkDeelinhoudVan ‘Economie’ Werkwijze toevoegen nieuwe begrippensets, en wijzigingen Het toevoegen en wijzigen van (nieuwe) begrippensets verloopt volgens een formele door EduStandaard vastgestelde procedure. Begrippen en relaties worden door expertorganisaties zoals SLO, MBO Raad en DUO aangemeld voor opname in het OBK en waar nodig geharmoniseerd en aan elkaar gerelateerd. Dit gebeurt volgens een vaste (door Achievement Standards Network, ASN, geïnspireerde) cyclus van:

127

ll Atomise: het analyseren en atomiseren van begrippen. Hierbij wordt ook het niveau van granulariteit (kleinste eenheid) bepaald waarop een begrip beschikbaar wordt gesteld ll Describe: elk begrip wordt rijk en eenduidig beschreven door het gebruik van attributen ll Relate: relaties tussen begrippen worden vastgelegd en ook rijk en eenduidig beschreven. Eventueel worden begrippen die semantisch te dicht bij elkaar liggen, geharmoniseerd.

Wordt bijv. in het PO gesproken over (Nederlandse) taal, in het VO over (het vak) Nederlands en op de universiteit over (de studie) Nederlands: in het OBK zijn deze begrippen samengevoegd tot 1 begrip dat op diverse leerniveaus kan worden gebruikt. Er is een duidelijke scheiding tussen enerzijds inhoudelijke (semantische) onderwijsexpertise en anderzijds het modelleren en technisch beschikbaar stellen. Architectuur en systemen In de figuur hieronder is de huidige architectuur opgenomen van het OBK en de aanpalende systemen.

128

De begrippensets (onderaan in het figuur) worden veelal in de vorm van een elektronisch bestand (vaak MS Excel) door de begrippenset beheerder aangeleverd. Door de OBK beheerder worden deze in een importeerbaar MS Excel-formaat gezet. De OBK tooling heeft een importmodule waarmee dit format automatisch ingelezen kan worden in de ‘RNA toolset’. De’ RNA toolset’ is de beheeromgeving van het OBK, geleverd door Trezorix. Het bestaat uit een viewer en een editor. Vanuit de RNA omgeving vindt synchronisatie plaats met een RDF-store waarin alle begrippen en relaties worden opgeslagen. Dit is het daadwerkelijke ‘Onderwijsbegrippenkader’. Het OnderwijsBegrippenKader kan op twee manieren bevraagd worden. De eerste mogelijkheid is direct op de RDF-store doormiddel van een SPARQL end point. In eerste instantie was het de intentie om alle bevragingen via dit endpoint te laten lopen. Maar na enige ervaring opgedaan te hebben is besloten om naast het Endpoint ook een API beschikbaar te stellen die op basis van JSON (en in de toekomst meerdere formaten) de informatie op een standaard manier kan ontsluiten. Dit maakt het voor ontwikkelaars van externe applicaties makkelijker om op te ontwikkelen. In veel gevallen hebben de ontwikkelaars van deze systemen nog onvoldoende kennis van RDF/SPARQL en het

datamodel van het OBK om hier goed mee om te kunnen gaan. Daarnaast is JSON gemakkelijker te verwerken door deze applicaties dan RDF. Ook biedt de API ook de mogelijkheid om de performance te optimaliseren onder andere door de mogelijkheid om caching toe te passen. Op basis van het SPARQL endpoint zijn nu enkele applicaties geïmplementeerd: ll De PURL converter maakt het mogelijk dat een extern systeem de informatie van een specifiek begrip in RDF vorm opvraagt middels een persistente url. Zo geeft de url http://purl.edustandaard.nl/ begrippenkader/c001f86a-4f8f4420-bd78-381c615ecedc alle informatie die het begrippenkader heeft over het begrip ‘c001f86a4f8f-4420-bd78-381c615ecedc’ (aardrijkskunde). ll De RDF browser maakt het mogelijk om door de begrippen te zoeken en hun RDF data op een gebruiksvriendelijkere manier te bekijken dan in de PURL coverter. ll De proeftuin linked data 1.0 (zie volgende paragraaf) bevraagt ook het SPARQL endpoint. ll De Vdex builder: Deze stelt de beheerder instaat om vanuit het onderwijsbegrippenkader vocabulaires samen te stellen in een Vdex formaat. Deze kunnen daarna in de vocabulaire bank worden geïmporteerd. De vocabulaire bank

129

geeft een overzicht van alle beschikbare vocabulaires. Op basis van dit overzicht kunnen eigenaren en ontwikkelaars van externe applicaties zien welke vocabulaires zij kunnen inzetten in hun applicaties. De enige applicatie die nu nog via de API wordt ontsloten is de OBK begrippenbrowser, die wordt in de volgende paragraaf toegelicht. De OBK-BegrippenBrowser Het hart van het OBK is de RDFstore waarin de begrippen met hun relaties zijn opgeslagen. Het is wel zaak om deze schat aan informatie op een juiste manier voor de eindgebruikers te ontsluiten. Direct toegang tot de data (zoals via de purl converter en/of RDF-browser) geven aan de gebruikers van de begrippen

is niet gewenst. Vanuit de behoefte om door de begrippen te kunnen browsen is een eerste versie van de onderwijsbegrippenbrowser ontwikkeld (zie http://browser.onderwijsbegrippenkader.nl/). De doelgroep van deze gebruikers zijn de actieve ‘beheerders’ en ‘gebruikers’ van de begrippen, denk bijvoorbeeld aan de leerplanontwikkelaars bij SLO, SBB en andere leden van de SIG-werkgroep. Met de browser kunnen de gebruikers zoeken binnen de begrippen en de details van elk begrip opvragen,

maar daarnaast ook ‘browsen’. Uitdaging hierbij was het weergeven van relaties tussen meer dan twee begrippen. Veel websites (b.v. woordenboeken) tonen alle relaties vanuit het ene begrip naar andere begrippen. Wil je de relatie tus-

130

sen drie begrippen zien, is dat niet mogelijk. Zo kan je dan bijvoorbeeld niet de vraag stellen ‘Laat me alle onderwerpen van het vak aardrijkskunde van de 3de klas havo zien’. Binnen het browsen kiest de gebruiker eerst het type begrip, waarna hij alle begrippen van dit type ziet. Als hij dan een begrip kiest krijgt hij in de volgende kolom de types en begrippen te zien waarmee dit begrip een relatie heeft. Kiest hij dan weer een begrip dan ziet hij in de volgende kolom de types en begrippen waar deze twee begrippen beiden een relatie hebben (zie onderstaande schermprint voor de vraag ‘Laat me alle onderwerpen van het vak aardrijkskunde van de 3de klas havo zien’). Proeftuin Linked data 1.0 Binnen het project Proeftuin Linked Data van het al eerder genoemde programma ECK2 zijn twee prototypes ontwikkeld om te laten zien welke mogelijkheden ontstaan als het OBK als linked data ontsloten wordt (http://linked-data.kennisnet.nl): 1. Een prototype waarmee een ‘leerplanverantwoordingskaart’ (De verantwoording of het leermateriaal wel voldoet aan de verplichte leerdoelen en vakinhou-

den) van een onderwijsmethode gegenereerd kan worden door het ingeven van enkele begrippen, waarbij het prototype op basis van de relaties van deze begrippen in het OBK gehele ‘kaart’ kan invullen. Onderdeel hiervan is ook de Bronnenaanwijzer, die door het aangeven de ‘plaats’ van een ‘leerobject’ binenn de onderwijsmethode op basis van de relaties tussen de begrippen in het OBK een groot deel van de metadata af kan leiden. 2. Een prototype waarmee een leerplanverantwoordingskaart van een zelf samengesteld ‘arrangement’ van bronleermateriaal gegenereerd kan worden door het linken van de begrippen en hun relaties van het onderliggende leermateriaal aan het arrangement. Belangrijke conclusies van de proeftuin zijn: ll De ontwikkelde applicaties geven inspirerend inzicht in de mogelijkheden die ontstaan door toepassing van semantische technologie. ll De proeftuin heeft een route laten zien die het mogelijk maakt om veel meer relevante metadata (semi-) geautomatiseerd te genereren. Dit leidt tot tijdsbesparing en kwaliteitsverhoging. Toepassing van deze technologie kan dus leiden tot het vereenvoudigen en versnellen van het metadateerproces. Daarbij geldt: hoe rijker de

131

data en onderlinge relaties, des te rijker de afleidingen die kunnen worden gemaakt. ll De via het OBK aangeboden kernprogramma’s van SLO zijn zeer bruikbaar voor dergelijke toepassingen, met de kanttekening dat door het gebruik in deze proeftuin diverse verbeterpunten naar boven komen. ll Inhoudelijk experts zijn in deze fase onontbeerlijk om de informatie die zo ontstaan, op correctheid en relevantie te toetsen. Governance van het OBK: EduStandaard Naast een voorstel voor het ontwikkelen van een gemeenschappelijk begrippenkader adviseerde het project ‘Ontwikkelen en beheren vocabulaires’ ook om de governance en het beheer onder te brengen bij EduStandaard. In 2012 is het OBK ook daadwerkelijk onder de hoede van EduStandaard gebracht. De Standaardisatieraad, waarin bestuurders van vertegenwoordigers van publieke- en brancheorganisaties uit het onderwijs zitting hebben, registreert het OBK en formaliseert wijzigingen. Een speciale SIG-werkgroep OBK en vocabulaires (SIG = specialinterest group) adviseert

de Standaardisatieraad en komt hiertoe ca. 4 x per jaar bijeen. Het proces wordt ondersteund door Bureau EduStandaard dat bestaat uit medewerkers van SURF en Kennisnet. De procedures hiertoe voldoen aan de eisen van BOMOS2 voor het open beheer van standaarden. Naast ondersteuning van het standaardisatieproces is Kennisnet ook verantwoordelijk voor de dienstverlening rondom het OBK. Dat houdt onder meer in het dagelijks beheer van het OBK, het daadwerkelijk beschikbaar maken van het OBK voor onderwijsapplicaties en tooling om het OBk te kunnen beheren en te kunnen bekijken.

132

Toekomstige ontwikkelingen Het OBK kent in feite 3 terreinen waaraan op dit moment hard wordt gewerkt: uitbreiden, doorontwikkelen en inspireren. Uitbreiden nieuwe begrippen en modellering Allereerst zal het aantal begrippen sterk worden uitgebreid. De focus ligt daarbij op het curriculum voor PO, VO en MBO. Via SLO is het kerncurriculum voor de VO-onderbouw al beschikbaar, daarnaast wordt het kerncurriculum voor VO-bovenbouw en PO in 2013 en 2014 verwacht. Voor het MBO wordt op dit moment door Bureau EduStandaard (Kennisnet) samen met SBB (Samenwerking Beroepsonderwijs Bedrijfsleven) een eerste modelleringsslag gemaakt voor de nieuwe kwalificatiestructuur obv. OBK-methodiek. Daarnaast is de methodiek en de werkwijze van het OBK bruikbaar in diverse domeinen. Zo hebben DUO en Kennisnet samen met ketenpartners SBB, SLO en Studiekeuze123 een gemeenschappelijk, sectoroverstijgend semantisch model ontwikkeld voor het beschrijven van opleidingen voor de volle breedte van het Nederlandse onderwijs (van primair onderwijs t/m HO/WO): het Sectoroverstijgend Opledingseenheden Model (SOM). Dit model levert enkele nieuwe begrip-

pen en relaties op, en is onder meer gerelateerd aan de curriculummodellering van het kernprogramma’s van SLO zoals vak – niveau – inhoud; het is als concept aangeboden aan EduStandaard. In het programma SION (meerjarig door het ministerie van OCW ondersteund samenwerkingsverband voor de administratieve keten waarin de Onderwijsraden samenwerken met o.a. DUO en Kennisnet) wordt gewerkt aan het zgn. Kernmodel Onderwijsinformatie. Binnen de verschillende sectoren en ketenprocessen worden soortgelijke typen gegevens uitgewisseld. Echter, de labels, die aan gegevens hangen kunnen per onderwijssector sterk verschillen. Door begrippen te beschrijven en onderling te relateren wordt duidelijk gemaakt hoe labels zich tot elkaar verhouden: zijn ze synoniem? Of maken ze onderdeel uit van een ander begrip? Dit is de basis van het Kernmodel Onderwijsinformatie. Voor het beschrijven en relateren van de sectorspecifieke labels uit de berichtensets én generieke labels uit de objectenmodellen wordt gebruik gemaakt van het OnderwijsBegrippenKader.

133

Figuur 1 - Schets van het Kernmodel Onderwijsinformatie, in ontwikkeling binnen het SION-programma.

Doorontwikkelen Er wordt gewerkt aan een pilot waarbij gegevens van het OBK en van DUO gekoppeld worden aan gegevens van de stelselcatalogus voor de Basisregistraties volgens de linked data principes. Hierdoor wordt aangetoond dat dit een effectieve en geschikte manier is mogelijk is om verbanden te leggen tussen in het onderwijs gebruikte begrippen en begrippen uit andere domeinen, in dit geval het stelsel van basisregistraties, en verbanden met de achterliggende jurisprudentie en beleid.

Op het technische vlak wordt er een belangrijke uitbreiding gerealiseerd: context-relaties mbv. OAI-ORE. Hiermee kan een samenhangende set van bergrippen en relaties worden geduid. Het wordt nu bijv. mogelijk om relaties tussen begrippen afhankelijk te laten zijn van de context. Een eenvoudig voorbeeld: het VO-vak (VO = voortgezet onderwijs) Nederlands noemt men in het primair onderwijs bij voorkeur Taal. Of: gesprekken voeren en lezen zijn deelonderwerpen die bij ieder taalvak terug komen, wat er per deelonderwerp echter aan

134

bod komt hangt weer heel erg van het niveau af. Samenhangende begrippen zoals vocabulaires konden altijd al gedefinieerd worden. Door OAI-ORE nu echter ook te gebruiken voor het definiĂŤren van vocabulaires wordt het nog eenvoudiger om inzicht te krijgen in de verbanden tussen begrippen die vanuit verschillende gebruikswensen zijn samengesteld.

Inspireren: Proeftuin LinkedData 2.0 Om de partners in de ECK-leermiddelenketen verder te inspireren en inzicht te geven in de mogelijkheden die ontstaan door het combineren van (al dan niet open) linked data, wordt een vervolg op de proeftuin LinkedData uit het ECK2-programma ontwikkeld. Voor het vak Economie wordt een evaluatieinstrument voor het onderwijs in de bovenbouw ontwikkeld: eindexamenresultaten van leerlingen worden gekoppeld aan het Kernprogramma (opgesteld door SLO) en aan de op school gebruikte lesmethode. Door deze relaties te leggen kan de docent worden ondersteund in de analyse van de examenresultaten. Tevens wordt een diagnostisch instrument voor leerlingen ontwikkeld, door de bovenstaande data te verrijken met de oefenopgaven van centraal schriftelijk examen en de landelijke examenresultaten. Als het mogelijk is wordt tevens een koppeling gerealiseerd met een of meer adaptieve leersystemen, waardoor aanvullende

data beschikbaar komt. Al deze initiatieven betreffen het linken van data uit verschillende bronnen op basis van sematisch web standaarden. Meer informatie vindt u op www. edustandaard.nl en www.kennisnet.nl/ onderwijsbegrippenkader .

B6 - De erfgoedthesaurus in de kennisketen van het cultureel erfgoed Auteurs

Patrick Mout (RCE) Joop Vanderheiden (RCE) Kees Hendriks (RCE) Nico Verbeij (Verdonck Klooster & Associates) De Rijksdienst voor het Cultureel Erfgoed (RCE) wil haar elektronische dienstverlening vernieuwen ĂŠn de eigen openbare gegevens zoveel mogelijk ter beschikking stellen voor verrijking en hergebruik. Daarom koppelt de RCE zijn bronnen door middel van een gemeenschappelijke erfgoedthesaurus aan de bronnen in het erfgoedveld. Het geheel wordt voor hergebruik als open linked data beschikbaar gesteld aan private en publieke partijen. Deskundige partners in het erfgoedveld krijgen de gelegenheid mee te bouwen aan dit erfgoed-begrippenkader en kunnen met behulp hiervan hun eigen gedigitaliseerde collecties beter vindbaar maken. Leveranciers van informatieproducten (websites, apps, widgets) krijgen direct toegang tot de thesaurus en de daaraan gekoppelde informatie over allerlei erfgoedobjecten. In deze casusbeschrijving gaan de schrijvers in op de visie van RCE met betrekking tot open linked data in het erfgoedveld. Vervolgens beschrijven ze de activiteiten en bevindingen tot

nu toe op het terrein van de ontwikkeling van de Erfgoedthesaurus, de gekozen informatiearchitectuur, de standaarden en de datamodellering die worden gehanteerd, de ontsloten gegevensbronnen en de eerste voorbeeldapplicaties. Er is extra aandacht voor de Erfgoedsuite, een certificering voor online tools die erfgoedpartijen helpt bij het bouwen en onderhouden van een eigen webpresentatie en het duurzaam opslaan van de eigen collectiedata. Door de inzet van de erfgoedthesaurus komen deze lokale collecties verbonden en nationaal beschikbaar. Een doorkijk naar de toekomst besluit deze bijdrage.

Werken aan de kennisketen De Rijksdienst voor het Cultureel Erfgoed (RCE) werkt aan een beter functionerende erfgoedzorg. Onder erfgoed verstaan we zowel het roerende als het onroerende erfgoed, van kunstcollecties tot cultuurlandschappen en van archeologische vondsten tot rijksmonumenten. Aan dit erfgoed werken musea en archeologische onderzoeksbureaus, heemkundekring vrijwilligers en monumenten ambtenaren. De zorg voor ons cultuurgoed is sterk afhankelijk van een beschikbaarheid van de juiste informatie op het juiste moment. Het kan gaan om informatie over een nieuwe subsidieregeling voor monumentrestauratie of informatie

136

over de aard en betekenis van een archeologische vondst in een gebied waar een projectontwikkelaar plannen mee heeft. In 2009 constateerde Minister Plasterk in zijn beleidsbrief Modernisering Monumentenzorg: ‘kennis is niet altijd even toegankelijk voor de naar kennis zoekende burger, gemeente of monumenteneigenaar’. Genoeg reden voor de RCE om een programma te starten gericht op de realisatie van een verbeterde kennisinfrastructuur die de modernisering van de monumentenzorg schraagt. In het werken aan deze nieuwe infrastructuur formuleerde de RCE de volgende uitgangspunten: ll Eenmalige opslag en meervoudig gebruik van de eigen RCE data die zoveel mogelijk als linked open data onder creative commons licenties wordt gedeeld. ll Alle zoekacties op de data verlopen via semantisch gestructureerde metadata in één gemeenschappelijk Cultureel Erfgoed Begrippenkader: de Erfgoedthesaurus. ll Een architectuur op basis van een drie lagen model, toepassing van open standaarden en (zoveel mogelijk) open source. ll De bronhouder blijft altijd verantwoordelijk voor de eigen data en krijgt credits voor zijn bijdrage.

Het centrale thema is verbinden: van gegevensbronnen en organisaties, van mensen en ideeën. De RCE heeft de ramen en deuren geopend en werkt steeds meer samen met partijen en initiatieven die de erfgoedzorg verder brengen.

Drie lagenmodel RCE kennisinfrastructuur De bronnenlaag bevat de data van de RCE en andere erfgoedinstellingen. Deze bronnen worden lokaal beheerd en blijven onder de hoede van de bronhouder. In essentie is er voor koppeling niet meer nodig dan toegang via internet en de beschikbaarheid van metadata. De verbindingenlaag koppelt de metadata van de bronnen aan de Erfgoedthesaurus. Deze thesaurus levert de termen voor de metadatering van de bronnen en wordt ingezet voor de terugvindbaarheid van de bronnen. Bovendien biedt de erfgoedthesaurus een beeld van het cultureel erfgoed domein. Als sluitstuk van de architectuur fungeert de presentatieomgeving die de vorm heeft van allerlei elektronische diensten. Hier vinden we toepassingen die van de verbonden data gebruik maken zoals apps, widgets, websites e.d.. Deze eindgebruikerstoepassingen worden buiten de RCE ontwikkeld. Derde partijen, commercieel en ideëel, worden uitgedaagd om

137

Drielagenmodel: de RCE kennisinfrastructuur is ingericht op een drielagenmodel

de verbonden data in producten voor hun gebruikers toe te passen. De RCE richt zich in het werken aan de infrastructuur vooral op de inrichting van de bronnenlaag en de verbindingslaag. In de presentatieomgeving zijn enkele pilots uitgevoerd (waarover later meer). De eigen bronnen van de RCE bestaan voornamelijk uit de registers van archeologische onderzoeken en vondsten en de rijksmonumenten. Centraal in de nieuwe kennisinfrastructuur staat de verbindingslaag en de daarin opgenomen erfgoedthesaurus. De RCE is verantwoordelijk voor het inrichten, beheren en ontsluiten van deze erfgoedthesaurus. Hoewel de RCE het voortouw neemt is dit werk

bepaald geen solistische activiteit. De RCE richt zich vooral op de hoofdlijnen en op een ‘ondiepe’ inrichting van de hiërarchie. De specialisten in het veld stellen we in de gelegenheid om de verdere verdieping van het begrippenapparaat ter hand te nemen. Voor het werken aan de verbindingslaag is een speciaal cluster van medewerkers ingericht. In dit cluster (circa 4 fte) zijn onder andere informatiespecialisten actief die voorheen in de bibliotheek van het instituut werkzaam waren. Zij ontwikkelen de verbindingslaag, werken aan thesaurus structurering en uitbreiding, verbinden thesauri en verbinden de termen uit de Erfgoedthesaurus met brondata.

138

Crowd sourcing en de Erfgoedsuite In Nederland is heel veel expertise in het domein van het cultureel erfgoed, bij individuen en instellingen die zich hebben gespecialiseerd in bijvoorbeeld Molens, regionale archeologie, historische stuwen en sluizen of Saksische boerderijen. Om deze experts de ruimte te bieden om te participeren in de ontwikkeling van de gemeenschappelijke erfgoedthesaurus heeft RCE verschillende gereedschappen ingericht, variërend van het elektronisch kunnen ‘plakken van geeltjes’ op voorgestelde begrippenlijsten tot geavanceerd gereedschap om termen, beschrijvingen en hiërarchie toe te voegen of aan te passen. Er is overigens geen sprake van open crowd sourcing want de bijdragen aan de Erfgoedthesaurus zullen vaak op uitnodiging en in een aantal gevallen achter een wachtwoord hun beslag krijgen. Wij proberen zo wel optimaal gebruik te maken van de beschikbare kennis. Het belangrijkste crowd sourcing instrument is de Erfgoedsuite (zie www.erfgoedsuite.nl). Dit is gecertificeerde software die als ‘software as a service’ beschikbaar is. De essentie van deze voorziening is dat hij aan de ene kant gespecialiseerde instellingen helpt om hun gedigitaliseerde collecties duurzaam te beheren en daaromheen eenvoudig een website te kunnen bouwen. Aan de andere

kant krijgen deze instellingen direct de gelegenheid om voor de metadata gebruik te maken van de Erfgoedthesaurus. De objecten in de collectie zijn daarmee direct vindbaar geworden in de verschillende informatieproducten die gebruik maken van de RCE vindbaarheidslaag. De lokale gespecialiseerde instelling kan desgewenst ook een bijdrage leveren aan de uitbouw van de Erfgoedthesaurus. De voordelen zijn duidelijk. De (doorgaans) kleine erfgoedinstelling krijgt de beschikking over deugdelijke state of the art software, duurzame opslag en een begrippen apparaat (de erfgoedthesaurus) waar de collectie mee gemetadateerd kan worden. De RCE ziet een nationale collectie ontstaan waarin steeds meer erfgoedinformatie op basis van de gemeenschappelijke thesaurus is terug te vinden. De projecten www.veenkoloniaalmuseum.nl en www.hethoogeland. com zijn eerste toepassingen van de erfgoedsuite

De Erfgoedthesaurus De erfgoedthesaurus is opgebouwd uit een verzameling concepten en hun onderlinge relaties. Ieder concept vormt de weerslag van één begrip. Met een begrip bedoelen we, al hetgeen zonder oordeel begrepen en gedacht kan worden. Daarbij heeft elk concept een uniek nummer (ID) en mag het maar in een betekenis één keer voorkomen in de thesaurus.

139

Een concept bestaat uit de volgende onderdelen: ll naam, bij voorkeur een zelfstandig naamwoord m.u.v. activiteiten en personen ll scope note, omschrijving van de term in maximaal 50 woorden ll item type, onderwerpstype waartoe de term behoort ll facet, waartoe de term behoort ll termtype, voorkeursterm of nietvoorkeursterm ll concept id, uniek nummer ll bron, eigenaar/bron van de term ll bron id, broncode term

Een concept kan meer items bevatten, zoals: ll synoniemen, termen met gelijke betekenis ll taalvarianten, termen in andere taal of dialect ll varianten in schrijfwijze, termen in enkelvoud, als werkwoord ll use, bij niet-voorkeursterm verwijzing naar de voorkeursterm ll broader term, ouderterm ll narrower term, kindterm ll related term, associatieve term

Een voorbeeld van het concept â&#x20AC;&#x2DC;Stellingmolenâ&#x20AC;&#x2122; in de thesaurus Molentypen.

140

De lijsten en thesauri in de verbindingenlaag zijn opgedeeld in facetten. Deze facetten zijn voor een deel gebaseerd op de facetten die in gebruik zijn bij Art and Architecture Thesaurus (zie www.aat-ned.nl/home). Voorbeelden van facetten in de erfgoedthesaurus zijn: ll Abstracte begrippen: bijvoorbeeld ‘restauratie’ of ‘onderzoek’ ll Fysieke eigenschappen: ‘formaat’ of ‘materiaal’ ll Topografie: ‘gemeente’of ‘toponiem’ ll Actoren: ‘architect ’of ‘ vondstmelder’ ll Activiteiten: ‘restaureren’ of ‘opgraven’ ll Stijlen en Perioden: ‘Romantiek’ of ‘Prehistorie’ ll Objecten: ‘paleis’ of ‘aardewerk’ Om een werkbare en overzichtelijke taxonomie in te richten worden de facetten ingedeeld tot een maximum van drie niveaus. De facetten en twee onderliggende niveaus vormen samen de kapstok waaraan lijsten op een gestructureerde manier kunnen worden aangehangen. Het structureren van de lijsten (bijvoorbeeld door het aanbrengen van meer niveaus) gebeurt in samenspraak met experts uit het betreffende kennisdomein. Voor een semantische modellering zijn deze facetten niet vereist. Zij helpen ons wel in het presenteren van ons domein en in het hanteren van aan-

geboden trefwoordlijsten. Deze lijsten zijn vaak hybride en bevatten ook veel termen die al behandeld zijn. Om een goede vergelijking uit te kunnen voeren verdelen we de termen eerst per facet om vervolgens binnen facet een vergelijking uit te voeren. De erfgoedthesaurus is ‘werk in uitvoering’. In het erfgoeddomein zijn in het verleden veel verschillende (analoge) lijsten samengesteld. Nu eens als register voor een publicatie dan weer als een volwaardige deelgebied thesaurus. Deze lijsten vormden het startpunt. Ze zijn ontdubbeld en aangevuld met bijzondere lijsten die door derden zijn ontwikkeld. Daartoe is in enkele gevallen ook een beroep gedaan op commerciële uitgevers die papieren versies uitbrengen van deeldomein lijsten die voor de sector gezaghebbend zijn en een belangrijke aanvulling vormen op wat al beschikbaar is. In het archeologische domein konden we een vliegende start maken. Sinds einde jaren 80 werkt men in deze sector al met het zogenaamde Archeologisch basisregister. Dit register bestaat uit een aantal gestandaardiseerde lijsten waarmee archeologische onderzoeken, vondsten en sporen zijn beschreven. Na een actualisering die we in 2011-2012 uitvoerden is voor dit onderdeel nu een complete domein thesaurus beschikbaar.

141

Linked open data Met het ontwikkelen van het Referentienetwerk Erfgoed werkt de RCE aan voorzieningen waarmee de erfgoedinformatie van de RCE en van derden op het web kan worden gepubliceerd en terug gevonden in de vorm van linked open data. Voor de RCE is ook de duurzaamheid in dat terugvinden van groot belang. Hiertoe worden aan de linked open data uri’s persistent identifiers toegekend. Met toekenning van een persistent identifier krijgen elk concept in de Erfgoedthesaurus en elk contentitem op het web een uniek nummer dat dit digitale object duurzaam representeert. Zo wordt voorkomen dat metadata niet meer leiden naar de bedoelde content, omdat de weblocatie of de naam van het contentitem is veranderd. Het persistente nummer verwijst altijd naar het digitale object, ongeacht de veranderende onderliggende ‘locator’ technologie. Hiertoe wordt een register bijgehouden waar eventueel veranderde weblocaties moeten worden gemeld. Op basis van de Handle-technologie (standaard) is een webservice ontwikkeld, en beschikbaar, voor het toekennen, beheren en terughalen van persistent identifiers vanuit de collectieregistratie en -publicatiesystemen. Deze webservice is succesvol getest bij de RCE partners Instituut voor Beeld en Geluid en het Nationaal Archief.

In de Erfgoedthesaurus passen we Linked Data toe door de concepten uit de erfgoedthesaurus in RDFtriples op te slaan en beschikbaar te stellen. We maken dus gebruik van de internationale standaardtechnologie SKOS Core. SKOS maakt gebruik van Resource Description Framework of RDF. RDF is een model, dat uitgedrukt wordt in XML en uitgaat van drie onderdelen: onderwerp-eigenschapwaarde, in RDF notatie beschreven als een triple: subject-predicateobject. Met een RDF-triple wordt een uitspraak gedaan over een eigenschap van een object, persoon, begrip of bron. Een voorbeeld: ll Jacob van Campen bouwde het Paleis op de Dam. ll RDF-triple: subject: Jacob van Campen | predicate: bouwde | object: Paleis op de Dam Bij het beschrijven op basis van RDF moet er duidelijk verschil worden gemaakt tussen het beschrijven van een object en een begrip. Met een object bedoelen we een fysiek voorwerp of bouwwerk. Een fysiek object kan zijn het werkelijke object zoals het Paleis op de Dam aan Damplein 1 in Amsterdam, maar kan ook zijn een boek over, een foto of andere verbeelding van het Paleis op de Dam. Daarnaast verstaan wij onder objecten

142

niet alleen levenloze dingen maar ook fysieke personen, zoals Jacob van Campen of Daniël Stalpaert. Met een begrip bedoelen we de verbeelding van een object in algemene zin. Een voorbeeld is het begrip: Paleizen. Een paleis staat niet voor een specifiek object, maar is een categorisering van alle bestaande gebouwen die vallen onder het gebouwtype Paleizen. Naast het vastleggen van concepten in de Erfgoedthesaurus is het belangrijk om te definiëren welke relatietypen (in RDF-taal: predicates) er worden gebruikt tussen termen ofwel RDF-subject en RDF-object. En tot welk specifiek onderwerpstype (in RDF-taal: item type) een RDF-subject of RDF-object hoort. Dit uitgangspunt betekent dat één concept maar tot één item type kan behoren. Voorbeeld: ll De persoon Shakespeare is auteur van het toneelstuk Hamlet ll RDF-triple wordt dit beschreven als: PersonType: Shakespeare | isAuthorOf | NameType: Hamlet ‘PersonType’ en ‘NameType’ zijn in dit voorbeeld item types, ‘isAuthorOf’ is in dit geval de predicate. Naast het feit dat ieder subject (concept) meerdere eigenschappen of predicates kan hebben, kan ieder object ook zelf een subject zijn.

Erfgoedthesaurus: de tooling Voor het beheer van de Erfgoedthesaurus maakt RCE gebruik van tooling van het Delftse bedrijf Trezorix. Deze tooling is webgebaseerd en is ontwikkeld voor het inrichten en onderhouden van thesauri, het gemakkelijk kunnen koppelen van kennisbronnen op het web, en het op gemakkelijke en eenduidige manier vindbaar maken van alle verschillende soorten content in die bronnen. In de Referentie Netwerk Architectuur omgeving worden drie lagen onderscheiden: ll Datalaag. Aan de onderkant bevindt zich een datalaag. Hierin bevinden zich de bronnen: databases, filesystemen, webpagina’s enzovoort. Deze bronnen zijn bereikbaar via het internet. Deze laag vertegenwoordigt het aanbod van informatie. ll Applicatielaag. Aan de bovenkant bevindt zich een laag met applicaties, die gebruik willen maken van het informatie-aanbod uit de onderste laag. In deze applicatielaag wordt de vraag bepaald. ll Referentielaag. In de tussenliggende laag bevindt zich een netwerk van referenties. Deze referentielaag dient als een soort makelaar tussen de vraag- en de aanbodzijde, door hoogwaardige ontsluitingsfunctionaliteit te koppelen aan gedetailleerd overzicht van de beschikbare data.

143

De RNA omgeving voor het beheer van de Erfgoedthesaurus, Trezorix BV Delft

De voor vindbaarheid belangrijke data uit de bronnen wordt als metadata-records via connectoren naar de referentielaag gebracht. Deze metadata-records worden vanwege hun herkomst ook wel bronrecords genoemd. Ze worden gekoppeld aan thesaurusstructuren, die als het ware de landkaart vormen van het kennisdomein waaraan het netwerk gerelateerd is.

144

Applicaties raadplegen via application programmers interfaces (API’s) het referentienetwerk om heel gericht informatie uit de bronnen te kunnen halen. Een tweede manier van bevragen van de Referentielaag gaat via het stellen van SPARQL-queries. De referentielaag plus de interfaces die er zijn voor communicatie en uitwisseling met beide andere lagen noemen we een RNA-omgeving. Op deze omgeving is gereedschap voor redactionele bewerking van de thesaurus beschikbaar. Ook hulpmiddelen voor import en datatypering en -modellering zijn vervaardigd. De voorbereiding en batch bewerking van bestanden vindt vooral plaats in Microsoft Excel. Macro’s ondersteunen dit proces.

Pilots De erfgoedthesaurus is work in progress. Een aantal lijsten is ingericht, met name in het archeologische domein. Deze zijn te vinden via www. erfgoedthesaurus.nl. Hier is de mogelijkheid om commentaar te plaatsen in de vorm van geeltjes (zie pennetjes rechts bovenin bij de desbetreffende onderdelen). Ook is een tabblad ‘erfgoedsuite partners’ beschikbaar. De collecties van het Groninger Molenhuis en Openlucht Museum Hogeland worden getoond naast hun inspanningen op het terrein van structuring van hun eigen collectie met inzet van de erfgoedthesaurus.

Om de werking van de thesaurus bij ‘zoeken en vinden’ te demonstreren is een proof of concept ingericht met een volledige dataset van alle beschikbare archeologische onderzoeken http://archeologie.erfgoedthesaurus.nl/ Met behulp van zoekcriteria en de kaart kan de gebruiker de onderzoeken vinden met de daarbij behorende vondsten en grondsporen. Een vergelijkbare exercitie heeft plaatsgevonden voor de presentatie van rijksmonumentale molens: http:// molens.erfgoedthesaurus.nl. De ‘Molenwidget’ introduceert de rijksmonumentale molens en biedt (achter een inlog) leden van de molencommunity de mogelijkheid om te werken aan de molenthesaurus. http://rce.webgispublisher.nl/ ?map=Erfgoedatlas-concept-v4 biedt een eerste versie van de webgispublisher omgeving die de RCE zal inzetten om de geo halffabrikaten te ontwikkelen die dan als eindfabrikaat bijvoorbeeld terecht komen op www.atlasleefomgeving.nl. De website http://bit.ly/16zo2V2 [te bekijken met Google Chrome] biedt een tussentijdse oplevering van de linked open data demonstrator waarin Instituut voor Beeld en Geluid en de RCE samenwerken.

145

En verder In de komende periode werkt de RCE verder aan de modernisering van de kennisinfrastructuur voor de monumentenzorg. De Erfgoedthesaurus en de RNA-omgeving spelen daarin letterlijk een centrale rol. De verbetering van de vindbaarheid van erfgoedobjecten en verdere uitbouw van de Erfgoedthesaurus hebben binnen RCE een hoge prioriteit. Voor de archeologen werkt RCE aan een vernieuwing van het gemeenschappelijke archeologische informatiesysteem (Archis). Voor het beheer van de rijksmonumenten en het beschikbaar stellen van alle kennis over deze monumenten ontwikkelt RCE een nieuw Monumenten Registratie Systeem. Deze projecten kunnen

niet zonder de Erfgoedthesaurus. De RNA-omgeving gaat ook in de RCEzaken een belangrijke rol spelen. Om subsidie-aanvragen, Archeologische onderzoeksmeldingen en aanwijzingen van rijksmonumenten nog beter te ondersteunen werkt RCE aan een â&#x20AC;&#x2DC;zaakontologieâ&#x20AC;&#x2122;. Een op de GEMMA gebaseerde RDF modellering die o.a. het zoeken en vinden van zaakgegevens gaat verbeteren. In het DEN-project Erfgoed & Locatie participeert de RCE in de uitwerking van een semantische koppeling tussen een erfgoed geo-infrastructuur en woordsystemen. Zodoende krijgt ook de geocomponent in de verbindingslaag een verdere verdieping. DEN: www.den.nl.

B7 - OpenInc: waarde creëren met Open Data Auteurs

Open, Linked en Big Data

Pieter van Everdingen (OpenInc) John van Echtelt (CGI)

De primaire focus van de activiteiten van OpenInc ligt op het ontwikkelen van innovatieve oplossingen voor maatschappelijke vraagstukken op basis van open data en linked data. Het gaat daarbij niet alleen om data van overheidsinstanties als gemeentes, provincies en waterschappen, maar het gaat ook om de data van energiebedrijven, telecombedrijven, scholen, universiteiten, ziekenhuizen, zorginstellingen, musea en culturele instellingen en van maatschappelijke organisaties. Het gaat dus om alle vrij beschikbare data waar geen auteursrechten of andere rechten op berusten die door iedereen vrij gebruikt kunnen worden, gratis of tegen een geringe vergoeding [2].

Samenvatting Een interessant nieuw initiatief binnen de regio Utrecht is OpenInc. OpenInc is een open innovatie platform waar bedrijfsleven, overheid, kennisinstellingen en maatschappelijke instellingen samenwerken aan de ontwikkeling van innovatieve oplossingen voor maatschappelijke vraagstukken met open data als kerningrediënt. OpenInc faciliteert het proces van vraag en aanbod op het gebied van open data en de ontwikkeling van nieuwe diensten. In Nederland is al relatief veel data vrij beschikbaar gemaakt door diverse instanties en personen, maar we zien in de huidige praktijk dat het grote potentieel van deze open data nog onvoldoende benut wordt [1]. OpenInc wil daar verandering in brengen voor de regio Utrecht. Dit artikel beschrijft hoe OpenInc als open innovatie platform gaat opereren binnen de regio Utrecht en gaat samenwerken met burgers, het bedrijfsleven, overheidsinstanties, kennisinstellingen en maatschappelijke organisaties om innovatieve oplossingen te ontwikkelen voor maatschappelijke vraagstukken met open data als kerningrediënt.

Daarnaast zien we ook dat personen meer en meer hun data vrij beschikbaar maken via sociale mediakanalen als Twitter en Facebook en via apparaten als stappentellers, hartslagmeters en bloeddrukmeters die met een computer of mobiele telefoon verbonden zijn [3]. Zo zijn er recent door het beschikbaar komen van nieuwe technologieën een groot aantal nieuwe databronnen bijgekomen, die ook zeer geschikt zijn om nieuwe innovatieve diensten mee te ontwikkelen. Het gaat dan niet alleen om de data van personen, maar ook om de data van objecten, waarin sensoren zijn opgenomen die data elektronisch kunnen aanleveren. Deze

147

groep nieuwe databronnen valt binnen de categorieën big data en smart city data, die OpenInc ook binnen de scope van haar activiteiten heeft.

geo data om veel meer dan apps alleen. Het gaat ook om het oplossen van maatschappelijke vraagstukken, waarbij de gebruiker centraal staat. Het kan dan gaan om persoonlijke, wijkgerichte of regionale initiatieven voor een specifieke gebruiker of gebruikersgroep, waarbij data en data analyses gebruikt kunnen worden bij het oplossen van een maatschappelijk vraagstuk en waarvoor geen app ontwikkeld hoeft te worden.

Een belangrijk aspect bij open, linked en big data is de privacy van de gegevens. Bedrijven en instanties die data vrij beschikbaar maken, dienen dit zo te doen dat niet afgeleid kan worden om welke persoon of personen het gaat, ook niet door slim combineren van meerdere datasets (het zogenaamde mozaïek effect). Personen hebben een eigen verantwoordelijkheid om te bepalen welke data zij willen delen met de rest van de wereld [4]. Wel zien we hierin een trend van voorzichtigheid naar meer openheid, zeker waar dit een positief effect kan hebben op de gezondheid van mensen. Aan de ene kant maakt men zich zorgen over het ‘big brother’ effect, maar aan de andere kant ziet men gelukkig ook meer en meer de positieve kant van deze ontwikkelingen voor bijvoorbeeld de gezondheidszorg.

Regionaal Ecosysteem voor Open, Sociale Innovatie en Co-Creatie

Geo data speelt ook een zeer belangrijke rol bij het ontwikkelen van nieuwe innovatieve diensten, omdat gebruikers graag locatiegebonden, om maat gesneden informatie willen krijgen op hun mobiele telefoon, tablet of computer. Er zijn inmiddels vele apps beschikbaar die hun nut in de dagelijkse praktijk bewezen hebben, maar het gaat bij open, linked, big en

OpenInc wil een bijdrage leveren aan het verder opbouwen van een regionaal ecosysteem voor diensteninnovatie op basis van open, linked en big data voor de regio Utrecht en zal de samenwerking opzoeken met complementaire initiatieven in de regio die elkaar versterken bij de verdere uitbouw van dit ecosysteem. We zien daarbij dat innovaties zich meer en meer gaan organiseren van gesloten

Aan de hand van een aantal voorbeelden is een beeld geschetst van de soorten data die binnen de scope vallen van de OpenInc activiteiten. De primaire focus ligt daarbij op open en linked data, maar big data kan zeker ook een rol spelen binnen de activiteiten van OpenInc, waarbij OpenInc de samenwerking zal opzoeken met al bestaande big data initiatieven in de regio, wanneer een vraagstuk vooral een big data vraagstuk blijkt te zijn.

148

modellen naar meer open innovatiemodellen en innovatienetwerken, waarbij de samenwerking wordt opgezocht over bedrijfsgrenzen en over bedrijfssectoren heen (zie figuur 1) [5]. Zo ontstaat er een krachtiger en groter innovatiekennisnetwerk van bedrijven, instanties en personen die de nieuwe mogelijkheden van open, linked en big data en de bijbehorende technologieën mee wil helpen vertalen naar innovatieve, duurzame oplossingen voor maatschappelijke vraagstukken.

Figuur 1 - Via gesloten en open innovatie naar innovatie netwerken

Bij het oplossen van maatschappelijke vraagstukken staat de vraag van de gebruiker centraal (zie figuur 2). Gegeven de vraag, behoefte of probleem van een gebruiker of gebruikersgroep wordt gekeken welke partijen nodig zijn om dat maatschappelijke vraagstuk op te lossen. OpenInc wil daarbij samenwerken met vertegenwoordigers van de overheid, het bedrijfsleven, van kennisinstellingen en maatschappelijke organisaties om de aanwezige kennis en expertise in de regio maximaal te kunnen benutten ten behoeve van het oplossen van

maatschappelijke vraagstukken. Zoals al is aangegeven zal daarbij ook gekeken worden naar mogelijke nieuwe open samenwerkingsverbanden en cross-overs over bedrijfsgrenzen en over bedrijfssectoren heen. Dit is een nieuwe en groeiende markt die een goede basis biedt voor nieuwe innovaties door het maken van nieuwe, onverwachte innovatieve combinaties. OpenInc gaat een actieve rol spelen in het bij elkaar brengen van de verschillende partijen die willen werken aan innovatieve oplossingen voor maatschappelijke vraagstukken met open data als kerningrediënt. OpenInc wordt een van de ontmoetingsplaatsen voor personen, bedrijven en instanties binnen de regio Utrecht die geïnteresseerd zijn in het opzetten van nieuwe samenwerkingsverbanden, het oplossen van maatschappelijke vraagstukken, het ontwikkelen van nieuwe diensten en in het creëren van nieuwe business met open, linked en big data. Vanuit deze eerste gesprekken worden de meest kansrijke ideeën gefilterd die de moeite waard zijn om verder te ontwikkelen met een aantal partijen. OpenInc wil daarbij het totale proces van het bij elkaar brengen van vraag en aanbod op het gebied van open en linked data en de ontwikkeling van nieuwe diensten faciliteren vanuit het kennisnetwerk dat zij tot haar beschikking heeft. OpenInc is een

149

netwerkorganisatie van data experts die een breed scala van maatschappelijke vraagstukken kan helpen oplossen binnen de regio Utrecht.

Figuur 2 - User centric open innovatie en cocreatie met burgers en bedrijven

Per kansrijk idee zal bekeken worden naar de beste organisatievorm, aanpak en financiering van een vervolgtraject. OpenInc faciliteert dit proces en zorgt ervoor dat de afspraken voor een vervolgtraject vastgelegd worden in een samenwerkingsovereenkomst. De betrokken partijen bepalen vervolgens gezamenlijk welke aanpak het beste past bij het verder uitwerken van een idee, waarbij wel in alle gevallen de volgende fase-indeling aangehouden zal worden om tot de beste resultaten van het uitwerken van een idee te kunnen komen (zie figuur 3) [6]. Deze fase-indeling is zeer goed te combineren met andere

agile en lean methoden, zodat in alle gevallen een aanpak gekozen kan worden, waarin alle betrokken partijen zich kunnen vinden en die tot de beste resultaten leidt. Vervolgens zal voor een idee een eerste prototype worden ontwikkeld. Doelstelling is om in een kort tijdsbestek en tegen zo laag mogelijke kosten een kansrijk idee in een kleinschalige omgeving te kunnen bewijzen en te kunnen valideren met de betrokken partijen, zodat de levensvatbaarheid van een oplossing getoetst kan worden alvorens het uitgewerkt kan worden tot een duurzame en schaalbare oplossing. In de huidige praktijk zien we dat oplossingen vaak in de pilot fase blijven hangen en niet tot een duurzame, schaalbare oplossing komen. Voorbeelden daarvan zijn onder andere te vinden in de zorgsector. OpenInc wil met de samenwerkende partijen de kans op verduurzaming, opschaling en het goed kunnen vermarkten van oplossingen verhogen door te kijken naar alternatieve financieringsvormen en het aanhaken van nieuwe partijen die daarbij kunnen helpen. Door deze aanpak blijven de eerste initiĂŤle kosten laag, is er snel inzicht over de haalbaarheid en levensvatbaarheid van een oplossing en is er dus een laag afbreukrisico voor de betrokken partijen. Deze aanpak wordt succesvol toegepast bij

150

bedrijven als Google die continu proof of concepts en pilots uitvoeren om zo kansrijke ideeĂŤn te verkennen en te toetsen op levensvatbaarheid. En daarbij mogen ook een klein aantal trajecten mislukken (license to fail), mits dit leidt tot nieuwe, verbeterde inzichten hoe een maatschappelijk vraagstuk dan wel opgelost kan worden. Deze aanpak zal een belangrijke bijdrage leveren aan het verhogen van de innovatiekracht in de regio.

vanuit de expertise die daar aanwezig binnen Almere DataCapital [8]. Ook zullen de OpenInc activiteiten aansluiten bij de themaâ&#x20AC;&#x2122;s en speerpunten die belangrijk zijn voor onze regio, zoals die zijn geformuleerd door de Economic Board Utrecht (EBU) [7]. Op deze manier kan meer focus aangebracht worden in de activiteiten van OpenInc en kan gerichter gezocht worden naar mogelijke samenwerkingsverbanden om zo de innovatiekracht en de Figuur 3 - Sociale innovatie aanpak die leidt tot duurzame, schaalbare oplossingen

Focus op Regio Utrecht en de Noordvleugel De activiteiten van OpenInc richten zich op de regio Utrecht en mogelijk ook op samenwerkingsverbanden met de Noordvleugel (provincies Noord Holland, Flevoland en Utrecht). Zo kan er met Almere samengewerkt worden op het gebied van big data

economische bedrijvigheid met open, linked en big data binnen onze regio te verbeteren. OpenInc zal actief de samenwerking opzoeken met initiatieven in de regio en binnen de Noordvleugel, daar waar deze initiatieven elkaar kunnen versterken en elkaar verder kunnen helpen. OpenInc heeft inmiddels een

151

groot aantal gesprekken gevoerd met partijen met wie samengewerkt kan worden. Hierdoor wordt het kennisnetwerk binnen de regio verder versterkt en kunnen ook nieuwe verbindingen ontstaan tussen partijen die voorheen nog niet met elkaar samenwerkten. Belangrijk is de openheid van deze samenwerkingsverbanden. Ook nieuwe partijen moeten de ruimte krijgen om aan te sluiten binnen dit kennisnetwerk en om hun bijdrage te kunnen leveren. Nieuwe interessante innovaties kunnen dan ook uit andere hoeken komen dan wat men tot nu toe gewend was.

Kansen Creëren voor Burgers en Bedrijfsleven OpenInc wil kansen creëren voor burgers en het bedrijfsleven om actiever met open, linked en big data aan de slag te gaan en om deel te nemen in nieuwe samenwerkingsverbanden. Burgers kunnen ideeën aandragen, als gebruiker vragen en behoeften formuleren en lokale kennis in kunnen brengen voor een specifiek vraagstuk dat met behulp van open, linked en big data opgelost kan worden. Meer en meer zien we dat niet alleen top down vraagstukken opgelost worden, maar ook juist meer bottom up. Dit is een goede ontwikkeling, omdat hiermee de maatschappelijke betrokkenheid verder wordt verhoogd en daarmee ook de innovatiekracht binnen de regio. Zodoende kunnen burgers meehelpen aan het creëren

van maatschappelijke waarde met open, linked en big data. Ook wil OpenInc kansen creëren voor het midden- en kleinbedrijf (MKB) door deze groep meer te betrekken bij het ontwikkelen van nieuwe diensten op basis van open, linked en big data. OpenInc gaat partijen met elkaar verbinden en vraag en aanbod op het gebied van open, linked en big data op elkaar afstemmen, zodat de economische bedrijvigheid in de regio Utrecht rondom open, linked en big data verhoogd wordt. Daar waar de kennis ontbreekt met betrekking tot open, linked en big data zal OpenInc haar kennisnetwerk inzetten om aan actieve kennisdeling te doen en om best practices uit te wisselen die kunnen helpen om tot een goede oplossing te komen voor een vraagstuk. Het vooral de bedoeling om ook nieuwe partijen hierbij aan te haken om zo het data ondernemerschap binnen de regio naar een hoger plan te trekken en ook economische waarde te creëren met data. OpenInc is geen incubator, maar zal daar waar nodig samenwerken met de al bestaande incubators in de regio Utrecht om startende bedrijven te helpen bij het ontwikkelen en op de markt zetten van nieuwe innovatieve diensten die gebaseerd zijn op open, linked en big data. Aansluitend op het EU-beleid wil OpenInc ook kansen creëren voor

152

studenten en werkzoekenden om hen zo voor te bereiden op de banen van de toekomst. De verwachting is dat er in de nabije toekomst een groot tekort zal zijn aan goede data specialisten [9]. OpenInc zal daarom gaan samen werken met kennisinstellingen in de regio om zo een entry level data curriculum te ontwikkelen, laagdrempelig en tegen zo laag mogelijke kosten waarmee een zo groot mogelijke groep bereikt kan worden die interesse heeft in open, linked en big data, een ‘open, linked and big data for the masses’ initiatief, waarbij mogelijk ook samengewerkt gaat worden met partijen in Europees verband die al cursusmateriaal ontwikkeld hebben, zoals het Open Data Institute (ODI) in Engeland [10]. Door deze actieve kennisdeling en opleidingen kan de data literacy in onze regio verder verbeterd worden.

Conclusies OpenInc is een nieuw initiatief binnen de regio Utrecht, waarbinnen het bedrijfsleven, de overheid, kennis-instellingen en maatschappelijke organisaties samenwerken aan de ontwikkeling van innovatieve oplossingen voor maatschappelijke vraagstukken met open data als kerningrediënt. OpenInc faciliteert het proces van vraag en aanbod op het gebied van open data en de ontwikkeling van nieuwe diensten. Dit komt de economische bedrijvigheid en innovatiekracht van de regio ten goede en zal ook nieuwe

banen scheppen voor data specialisten die daar nog voor opgeleid moeten worden. OpenInc gaat in al deze facetten van open, linked en big data een actieve rol spelen en gaat actief samenwerken met complementaire initiatieven binnen het regionale innovatienetwerk.

Referenties [1] Kroes, N., Neelie Kroes on the value of open public data: ‘data is the new oil’ video, March 16, 2012 [2] Kroes, N., EU unlocks a great new source of online innovation blog, June 13, 2013 [3] Wu, T., Introduction to Quantified Self prezi, April 25, 2013 [4] European Commission, Justice, Data Protection, Protection of personal data video, January 25, 2012 [5] European Commission, Directorate-General for Communications Networks, Content and Technology, Open Innovation 2013 pp 20. [6] Murray, R. et al., The Open Book of Social Innovation pp 11, The Young Foundation 2010. [7] http:// www.economicboardutrecht.nl/ [8] http:// www.almeredatacapital.nl/ [9] http://ec.europa.eu/ digital-agenda/en/ grand-coalition-digital-jobs-0 [10] http://www.theodi.org/courses/ open-data-practice

B8 - Open Data in electronics industry Auteur

John Walker (NXP Semiconductors) In the electronics industry, the ability to get accurate, timely product data in front of the customer is a very important factor in the overall business process. Furthermore, enabling the customer to easily compare and select the right product for their application from the choice of literally hundreds, or even thousands, of candidates can reduce the overall time and costs involved in the purchasing process. Typically this product data has itâ&#x20AC;&#x2122;s source at the manufacturer where it is stored in multiple systems in a variety of structured and unstructured formats. Often the data is duplicated in multiple places via manual processes leading to additional work and huge inconsistencies. Eventually the product data is published in formats like PDF and HTML.

Typically the data is then scraped or manually captured by data aggregation companies who align the data from different manufacturers, then sell this information on to distributors who use the data on their own websites, paper catalogues, etc. Often the distributors also do additional data capture to supplement the purchased product data. Our goal is to simplify the overall process to reduce the time, effort and complexity required to manage, publish and use the product data, thereby reducing the costs of doing business and allowing manufacturers to get the latest information to the customer more quickly. The approach is to provide a single, trusted source of product and product-related data in semantically rich formats that can be used to communicate the data and generate the multiple publication deliverables. Opening up access to the data is a key component, whether this is to free the data from existing silos for use within the organization, or making the data available to third parties. Also to facilitate the aggregation of data from multiple parties, it is very important to agree on a common schema that can be used to describe the products and enable easy mapping between schemata.

154

A key part of the approach is to use a Component Data Dictionary based on the ISO 13584 data model and IEC 61360 standard. This dictionary is basically an ontology and provides a set of classes and properties that can be used to describe instances of electrical/electronic components. The dictionary then acts as a schema that can be used to validate, but crucially also describes and defines the meaning. This highly structured data can then be used to generate publications such as PDF data sheets, web pages, selection tables and mobile apps. For less structured natural language content we use the DITA XML standard from OASIS. For the past years we have been mainly using XML-based technologies (XSLT, XPath, XQuery, XSL-FO) as a way to store and publish the data. We have had a great deal of success in our approach, but have realized that using XML is not always the most ideal way to represent the data as the model is essentially a graph. Also working with proprietary XML schema is a barrier to the access and understanding of the data by third parties. As such we have begun experimenting with RDF and Linked Data.

The initial problem space we tackled has been the integration and publication of disparate data sets to enable a BW/BI solution to make sense of and connect data from several digital marketing systems to drive customer insights. The challenge being faced in the BW/BI solution was that several data sets had been supplied that were effectively disconnected. Without any way to relate the data sources there was no way to connect, for example, information about a customers product interests with information about which order lines they had placed sample orders for. Our approach was to publish the connecting data as RDF Linked Data with URIs defined for the various resources of interest and include the various identifiers used by other systems as literal values to enable the BW/BI solution to reconcile the various data sources and create business critical dashboard reports. The RDF is generated from XML and CSV sources on a scheduled basis. For the XML sources we already store the files in an XML database and use XQuery to generate an RDF dump file per class of resource. For CSV sources we transform the data to RDF using XSLT. The RDF data is regenerated and loaded each hour to an externally hosted RDF store from which we expose a SPARQL 1.1 endpoint. We also manage stored SELECT queries which are exposed

155

as REST services from which internal and external consumers can pull simple tabular data in XML, JSON and CSV/TSV format. Also we have configured a front end application which makes the URIs dereferenceable and supports content negotiation including a vanilla HTML representation. So far, most of our success has been within the enterprise, but now we would like to put more focus on the broader ecosystem with data flowing in both directions. Basically how can the parties involve provide, and make use of, more open access to the data? As we are beginning to use Linked Data, we can make use of the basic principles to allow the data to be accessed over the web. However, this raises a number of interesting questions:

ll What formats are preferred? Our experience so far is that knowledge of RDF is quite limited, also formats like XML and JSON are not used that extensively. Many people seem more comfortable using Excel friendly formats like comma- or tab-separated. ll To what extent is RDF technology commonly used and accepted for dynamic content publication (content on demand) for instance a corporate website? So far we experienced that relational models where you need to stick to 1-n relations in which you lose a lot of semantic meaning and XML which is a tree-based hierarchical model have their limits. The real world seems to be more complex for which flexibility of the data model and use of (HTTP) URIs as global unique identifiers are important enablers. Therefore for the publication site we believe RDF offers best fit for purpose. Is this also recognized by other parties?

156

ll How do organizations make sure the quality of data they publish is validated in an efficient way to be able to support high-quality, efficient publication? We believe this can be covered via a combination of methods: use of international standards and schema, publish content with itâ&#x20AC;&#x2122;s data model, add linguistic checking methods and make sure you publish only fit for purpose content including business rule embedding in the publication environment. Are there any other methods that can be used or which are available to enable this quality validation process? ll What are the security and access implications? Providing totally open access to the data makes a lot of managers nervous, so how can we ensure that only public data is made public. Also in many cases products are customerspecific, so how can we manage access control to give these specific customers access to data? ll How to manage semi-structured (natural language) and unstructured (images) content and be able to easily combine all these different types of content in publications? Obviously for some content types, XML can be a better choice than RDF due to the nature of that content, but how can we make use of the best that both have to offer in the processing pipelines.

ll Not another new technology? Introducing a new technology into an existing complex landscape raises many worries such as additional complexity, availability of knowledge, etc. How to convince management of the benefits to get buy in. ll Arenâ&#x20AC;&#x2122;t we giving away a key asset? The content is the lifeblood of an organization and giving it away (for free) makes many people nervous. How can we build a compelling story that opening up not only makes sense, but can actually bring big benefits. Are there other success stories we can reference? Rather than the goal being open data, how can we position open data as an enabler to other business benefits. ll How to drive standardization within the industry? This will require the use of a common vocabulary that can be used to describe products. Could we base this on existing standards such as Good Relations or eCl@ss. What body could be responsible for the maintenance of the vocabulary and how might this work in practice. Would companies be happy to use a standard vocabulary as-is, or would there be a need to extend the vocabulary? How could data from existing systems be mapped onto such a vocabulary?

C1 - Walking the extra byte: A lifecycle model for linked open data Auteurs

Tijs van den Broek (TNO) Anne Fleur van Veenstra (TNO) Erwin Folmer (TNO) Abstract More and more public organizations publish their data in an open format to increase transparency and foster economic activity. In this modern gold rush, organizations strive to open up as many datasets as possible, without considering the strategic importance of open data. Especially linking data to other datasets can lead to the creation of innovative services. One issue that is often not explicitly addressed before opening up data is the format of the dataset. Central to open data is that the format is machine readable. But to allow for effortless linking of datasets, data being merely machine readable is not sufficient. Lifecycle models can guide the process of publishing linked open data. Current linked open data lifecycle models focus on the technical steps that need to be taken by the internal IT organization and often forget to include actions to be taken after publication. The effectiveness of linked open data, however, depends on how much the data is used. Hence, this paper develops a linked open data

lifecycle model that takes the multiple disciplines and stakeholders within and outside the organization into account as well as the steps to be taken after publication of the datasets. Firstly, using existing linked open data lifecycle models, this paper identifies generic phases of opening up linked data: identification, preparation, publication, re-use and evaluation. Secondly, investigating the process of opening up data in a semi-public organization in the Netherlands, the lifecycle model is refined and detailed. This case study shows that the involvement of relevant stakeholders, both within and outside the organization and of various disciplines, is essential to realize the support for the process and stimulate re-use.

Keywords Open government, Linked data, Open data, Lifecycle model, Case study Linked open data as a strategic asset Open data gained momentum since President Obama of the United States announced his ‘open government’ strategy (McDermott, 2010). Since then, governments around the world have adopted ‘openness as a strategy’ for their organizations to become more transparent and thereby accountable to citizens (Jaeger & Bertot, 2010). Furthermore, open data is increasingly seen as a driver for economic activity (Harrison & Pardo, 2012): the European Commis-

158

sion expects that the re-use of public sector information could an annual economic impact of EUR 140 billion in the European Union (Vickery, 2011). Part of this economic impact comes from innovative services that combine two or more datasets. To allow for effortless linking of datasets, data being merely machine-readable is not sufficient. An extension of open data is linked open data. For linked open data, the semantics of the data are modelled and the data can be linked to and from external data sets (Bizer et al., 2009; Hausenblas, 2009), to allow government agencies to link their data while staying in control of their own data. The difference between open data and linked open data is clarified by the introduction of the 5-star classification of data (BernersLee, 2006). Figure 1 lists the five levels of data quality identified by BernersLee (2006). Figure 1 The 5-star data model (Berners-Lee, 2006)

Available on the web (in whatever format) but with an open license, to be open data.

Available as machine-readable structured data (e.g. excel instead of image scan of a table).

As (2), plus: Non-proprietary format (e.g. CSV instead of excel).

All the above, plus: Use the open standards from the World Wide Web consortium (RDF and SPARQL) to identify objects in the data, so that people can refer to them.

All the above, plus: Link your data to other peopleâ&#x20AC;&#x2122;s data to provide context. Data classified with 1, 2 or 3 stars are typically termed open data, while data with 4 or 5 stars are termed linked open data. Linked open data is seen as a requirement for effective data re-use and hence an essential extension of open data. Linked open data has been championed by the British government since the publication of the Putting the Frontline First action plan in 2009. Despite the guidance by the internet scientists Tim Berners-Lee and professor Nigel Shadbolt, there are merely 200 linked open datasets available in the British data portal data.gov.uk (Huijboom & Van den Broek, 2011). Organizations often find the process of opening up data burdensome (see

159

e.g. Janssen, Charalabidis & Zuiderwijk, 2012). They are often unaware which steps to take in the process of opening up linked data. Lifecycle models are used to guide this process. However, most of these linked open data lifecycle models focus on the technical steps that need to be taken by the internal IT organization and often forget to include actions to be taken after publication. Furthermore, most of these models focus strongly on merely making sure that data are opened up to the public (following the notion of â&#x20AC;&#x2DC;complianceâ&#x20AC;&#x2122; with open data) rather than ensuring that open data becomes part of the strategic mission of the organization. A strategic perspective of linked open data requires a process that involves internal and external stakeholders from a wide range of disciplines. Hence, this paper develops a linked open data lifecycle model that takes multiple disciplines and stakeholders within and outside the organization into account as well as the steps to be taken after publication of the datasets. We develop a revised linked open data lifecycle model in two steps. Firstly, we assess current linked open data lifecycle models to identify generic phases that organizations opening up linked data go through. Secondly, based on a case study of a research and technology organization (RTO) in the Netherlands the model is validated and detailed,

including the specific activities and roles to adopt in every phase. While the data in the case study was not published in a linked data format, the lessons learnt still add to current technically-oriented models. The next section presents existing linked open data lifecycle models and compares them, formulating five generic phases that all organizations go through to open up their data. The third section describes the case study of an RTO in the Netherlands. The fourth section presents the main lessons from the case study by formulating the refined linked open data lifecycle model. Section five formulates conclusions and recommendations for organizations that are considering to open up their data. An assessment of current linked open data lifecycle models One way of structurally capturing challenges of information systems and addressing them is by formulating a lifecycle model. A lifecycle is an examination of a system or proposed system that addresses all phases of its existence (Blanchard & Fabrycky, 2006). Often lifecycle models are associated with the development of tangible products, services or assets, such as software development (Stallinger et al., 2011). In that context, a lifecycle model defines the processes that apply to software throughout its lifecycle. Alongside these processes, it also defines activities, tasks and

160

outcomes for every phase of the lifecycle and serves as a common body of language. The purpose of lifecycle models is twofold: they describe the development of certain phenomena and predict the next steps in the development (Lane & Richardson, 2011). In contrast to maturity models, lifecycle models do not prescribe organizational stages of the software development process. We found seven lifecycle models describing the process of opening up linked data and guiding organizations through this process.

Table 1 gives an overview of these existing linked open data models and identifies the phases and activities in the lifecycle models that were found in literature. The column on the right lists the subsequent steps formulated in these models. Then, shown in the middle column of table 1, we formulated common actions identified based on these existing models. Finally, we identified five common phases of opening up data: identification, preparation, publication, re-use and evaluation. These are shown in the left-most column of table 1.

Table 1 - Linked open data lifecycle phases and the actions that are undertaken in every phase.

Lifecycle phase Steps per phase

Activities in literature

Identification

Setting the strategy

Setting aims of linked open data (Alani et al., 2007)

Data awareness (Hausenblas, 2011)

Deciding on making data available Janssen & Zuiderwijk, 2012)

Collecting databases (Alani et al., 2007)

Selecting the data

Supporting the data selection (Ferrara et al., 2011)

Finding data for potential re-use (Hyland, 2010)

Obtaining a copy of the models of the databases (Hyland & Wood, 2011)

Obtaining data extracts or create replicable data (Hyland & Wood, 2011)

Identifying real life objects in data (Hyland & Wood, 2011)

Identifying data (Janssen & Zuiderwijk, 2012)

161

Lifecycle phase Steps per phase Preparation

Activities in literature

Setting requirements Analysing requirements (Alani et al., 2007)

Modelling and describing data

Specifying, defining and analysing the data (Villazon-Terrazas et al., 2011; Hyland, 2010; Hyland & Wood, 2011))

Design and build an ontology for the data (Alani et al., 2007; Ferrara et al., 2011; Hausenblas, 2011; Hyland & Wood, 2011; Villazon-Terrazas et al., 2011)

Defining a schema pattern for the Unique Resource Identifier (Ferrara et al., 2011; Hyland, 2010; Hyland & Wood, 2011)

Planning for persistence of data, e.g., Persistent Uniform Resource Locators (Hyland, 2010)

Converting to machine-readable data format

Generating the data (Villazon-Terrazas et al., 2011)

Convert the data to machine-readable format (Alani et al. 2007; Ferrara et al., 2011; Hyland & Wood, 2011; Villazon-Terrazas et al., 2011) Cleaning the data (Villazon-Terrazas et al., 2011)

Linking data

Mapping the data and ontology to existing ontologies and database (Alani et al. 2007;Villazon-Terrazas et al., 2011)

Storing data

Storing data in a datastore (Ferrara et al., 2011)

Publication Publication of data

Publishing data (Hausenblas, 2011; Hyland, 2010; Hyland & Wood, 2011; Janssen & Zuiderwijk, 2012; Villazon-Terrazas et al., 2011)

Publication of metadata

Publishing metadata (Villazon-Terrazas et al., 2011)

Re-use Exploiting of published data

Creating an online data catalogue for data discovery (Hausenblas, 2011; Hyland, 2010; Janssen & Zuiderwijk, 2012; Villazon-terrazas et al. 2011)

Managing access rights to the dataset (Ferrara et al., 2011)

Exploiting the data (Villazon-Terrazas et al., 2011)

Data management

Maintaining of data (Hyland & Wood, 2011)

Processing and visualizing the data (Janssen & Zuiderwijk, 2012)

Discussing the quality and relevance of the data (Janssen & Zuiderwijk, 2012)

Recommending existing and future data (Janssen & Zuiderwijk, 2012)

162

Lifecycle phase Steps per phase

Activities in literature

Evaluation

Developing business propositions

Developing use cases of data (Hausenblas, 2011)

Monitoring and improving data

Monitoring data re-use (Janssen & Zuiderwijk, 2012)

Integrating and improving data (Hausenblas, 2011; Janssen & Zuiderwijk, 2012)

Most of these models have been based on cases of linked open data in the public sector, focusing strongly on merely making sure that data are technically opened up to the public rather than ensuring that linked open data becomes part of the strategic mission of the organization. Therefore, we found that there is a need to develop a revised linked open data lifecycle using a case study of a semipublic organization aiming to embed linked open data in its strategy and work processes.

Opening up open data in a semipublic organization Case study approach In the previous section, the different phases of the lifecycle model and the steps to be undertaken in these phases were identified. Using a longitudinal case study approach we aim to validate and refine the subsequent phases of the lifecycle model. The case selected is TNO (Netherlands Organisation for Applied Scientific Research), the national RTO of the Netherlands. This case was selected

as TNO is in the middle of opening up its data to the public. This means that data could be collected during the implementation of the open data strategy. For analysing the case study we combine action research and semi-structured interviews. The action research consisted of the research team keeping track of actions that were undertaken throughout the process of opening up data, which started in September 2012 and continued until February 2013. The observations of the action research were validated by conducting eight semi-structured interviews. These interviews were held with five data owners, a director or research, a strategist and an information manager who were all invited to reflect on the process of opening up data and on their role in this process. The interviews were held in November 2012 and January 2013 and lasted 45 minutes on average. Interview questions concerned the strategic choices for opening up data of the RTO, their experiences with opening data, the actions that were

163

undertaken and their significance, as well as the involvement of significant stakeholders. The findings from the desk research and case study result in a revised lifecycle model that formulate the steps and organizational stakeholders within each phase of the process. Case description: TNO TNO is the national RTO of the Netherlands and can thus be considered a semi-public organization. The organization has long opened some of its research data to the public; for some time, the organization even was the largest contributor of datasets to the national open data portal data.overheid.nl. However, opening up linked data was not undertaken in a structural manner, but took place incidentally. The RTO identified three different reasons to open up its data. Firstly, opening up data is seen as a necessity for transparency, for example to show how research data are gathered and how they are structured. Secondly, the data of the RTO can be re-used by others to develop new services and stimulate economic development. This is especially relevant as many research projects of the RTO are funded by the government and these data can thus be seen as a public good. Thirdly, the RTO also has a commercial interest in open data. Therefore, the RTO is looking for ways to use their data to develop new commercial activi-

ties, for example by forging strategic partnerships with other data owning organizations. To develop a structural way of opening data, during the fall of 2012 the RTO undertook a pilot project in which a few datasets were opened up to the public. During this pilot project three steps were taken. Firstly, suitable datasets that could be opened up were identified and the data owners of these datasets were invited to participate in this pilot. Three datasets were identified and subsequently prepared for opening up: traffic data, geological data and data on working conditions in the Netherlands. Secondly, the datasets were opened up especially to take part in a hackathon, a one-day workshop in which 150 participants could use the data to develop their own services. The hackathon was organized by the city of Rotterdam in October 2012 and aimed to promote the commercial use of public data in an urban environment. Data owners provided and pitched their data to teams of voluntary programmers. Several prizes (ranging from 500 to 3000 euro) were granted to the winning teams to stimulate the development of apps in specific areas of re-use: healthcare, business, tourism and mobility. And thirdly, these activities were evaluated with the data owners and other stakeholders that were involved

164

A revised linked open data lifecycle model To open up its data, the RTO took the steps visualized in the linked open data lifecycle model below (see figure 1). The model consists of five phases (identification, preparation, publication, re-use and evaluation), each consisting of two steps. Furthermore, the model distinguishes five organizational stakeholders: top management, information manager, legal advisor, community manager and data owner. The model and the lessons learnt in the RTO case study are described step by step below.

Identification The first phase of opening up data comprises the definition of the process of opening up data and the identification of data that are to be opened. In the case of the RTO, a meeting was organized in which all relevant organizational stakeholders were involved. Furthermore, as the purpose of the pilot project was to open up data during a hackathon, contact was made with the hacking community to identify which data would be interesting for re-use. We found this phase to consist of two steps: setting the strategy and identifying the data for opening up.

Figure 2 The revised linked open data lifecycle model

165

Setting the strategy The first step in the identification phase is to develop a linked open data strategy. Top management should develop a vision on how linked open data contributes to the organizational mission. A proper vision should not only include which data to publish, but also which data to re-use from others. Early top management support is of critical importance â&#x20AC;&#x201C; even if linked open data merely starts off as a pilot project. While this may imply that a full strategy is not yet in place, it does mean that support is given to the process. In case the linked open data strategy includes fostering economic activity, in this phase also the connection with potential users may be useful to identify their requirements and demands. Selecting the data In the second step of the identification phase, the information manager and the data owners identify datasets that can be opened up, based on the linked open data strategy. Especially for larger organizations it is impossible to open up all available datasets at once. From a long list of available datasets that comply to the above-mentioned criteria, the most meaningful datasets should be selected: the shortlist. This selection can be based on developing a business case, in which the interest among users and the costs for opening up

the data is taken into account. This leads to a prioritized shortlist of datasets, on which to base the decision for the selection. This step also includes the mobilization of the data owners of the datasets on the shortlist.

Which datasets can be opened up? ll Datasets that are fully owned by the organization that publishes the data or for which a consent for publication has been obtained ll Datasets that do not contain classified information or information that contains data that is linked to national security ll Datasets that do not contain information that can be linked to individuals ll Datasets that are not exempted by third-party Intellectual Property rights or other exemptions formulated in the upcoming revision of the PSI directive Source: EPSI platform, 2013

166

Preparation After the three datasets to be opened up for the hackathon were identified, the second phase of the project consisted of preparing the datasets for publication. We found that although the datasets that were identified were of high quality, it still required some work before they could be opened up. Except for the involvement of the legal advisor, who checks whether the data that are to be made public can indeed be opened up, the main work in this phase was carried out by the information manager and the data owners. This phase consists of two steps: setting the requirements, and (technically) preparing the data.

Setting the requirements In the first step of the preparation phase, the information manager and legal advisor formulate the requirements of the data. These requirements include technical requirements (such as data quality level, standards and metadata), economic requirements (such as value proposition and business model) and legal requirements (such as the open license). Consequently, the project manager needs to involve all relevant all stakeholders in setting the data requirements to prevent any undesirable surprises later in the process. Depending on the linked open data strategy, the quality level requires more or less attention. Setting requi-

rements for the data quality includes assessing the current quality of data, setting goals for data quality and selecting data standards. Firstly, it is worthwhile to assess the quality of a dataset, the current level of â&#x20AC;&#x2DC;starsâ&#x20AC;&#x2122;. Secondly, the desired level of stars for the data has to be set. When the goal is to publish linked open data, the desired level should be 4 or 5 stars. Based on the initial level of stars, each dataset needs a plan how to gradually reach the next levels towards linked open data. For example, when opening up new data without any stars, it is better to plan the first steps that aim for 1-3 star data, then directly go for 5 star data. Thirdly, the data standards need to be selected in advance. Linked open data helps to limit the selection of standards to the open semantic web standards (from W3C) , such as RDF (RDF-S), and presented in open formats such as XML, N3, Turtle, and SPARQL to query the data. It is also worthwhile to assess the intrinsic quality of a dataset with existing quality instruments (Folmer, 2012): how consistent, complete, reliable, etc. is the quality of the items in the dataset?

167

Preparing the data How to prepare data for publication? ll Anonymizing any information that can be linked to individuals ll Modelling the concepts and links within the data ll Labelling the data in a unique way according to a Unique Resource Identifier strategy (similar to a website URL strategy) ll Converting data into a machine readable and open structured format (for 3-star data) ll Adding metadata ll Documenting the data for future re-use ll Storing the data following the four design rules for linked open data (for 5-star data)

The second step is the technical preparation of the data. This is the responsibility of the information manager and the data owner (or the person that is made responsible by the data owner) for managing a specific dataset. Depending on the data requirements set, this step includes modelling, description, conversion and storing of data. Firstly, ownership of the data needs to be clear, otherwise data cannot be published freely.

Secondly, data that can be tracked to individuals cannot be published or the part of the data that can be linked to individuals needs to be left out or anonymized. Thirdly, data is often captured in an unstructured way that fits its original purpose. Therefore, this step includes modelling the concepts and links within the data, and labelling the data in a unique way. When preparing for linked open data the following design rules are advised (adapted from Berners-Lee, 2006): ll All elements in the dataset need to be uniquely identifiable by the use of Unique Resource Identifiers (URIs) as identifier, which is a strategy similar to URL. There are, however, many ways to construct a URI, and it is therefore preferred to adopt a naming convention. The concept URI strategy (for naming convention) for Dutch linked open (government) data is presented in this book (Brink, Overbeek & Brentjes, 2013), and is recommended to be used. ll Use HTTP URIs so that people can look up those names on the Internet. ll When someone looks up a URI, provide useful information, using open standards (e.g. RDF* and SPARQL) to provide this information. ll Include links to the URIs of other data sets so that data users can discover and link datasets.

168

ll Fourthly, to allow re-use, data is converted into a machine readable and open structured format, metadata is added, and the data is stored following a specified format (as defined in the requirements phase). The converting and preparing of data sets is often combined with improving the intrinsic quality of the data, simply because during conversion many intrinsic quality issues will become apparent and needs to be solved.

Publication The third phase of publication coincided in this case study with its re-use: the data was published during a hackathon and instantly used by programmers to develop apps. We found that two steps were taken during the publication phase: ensuring technical findability and advertising the data. We found these two steps to have different purposes. While many organizations focus on the technical findability of data, also engagement with the community of potential re-users and advertising the data was found necessary to ensure data re-use. Ensuring the findability The first step of publication is to make sure that the published data can be found by users. This can be done by registering the data and metadata in an existing data catalogue, for example the national data

portal. Finding the right platform for publishing datasets is essential for attracting attention and users. This registration is essential: it allows data users to diminish the costs of data discovery. This job is done by the project manager and information manager. In a later stage (see step 8), you can consider to open up your own data portal, for example data. yourorganization.eu. Linked open data can improve the findabilty of the data: the URIs in the data are traceable, so the user can browse through the dataset, explore new related data sets and link to them. With having a starting point with some data, other related data can be discovered (Berners-Lee, 2006). Advertising the data While registration of the data in the most suitable portal and adding metadata may ensure findability, it may not be enough to actually ensure reuse. This is the task of the community manager, who can reach out using different forms of communication, such as press releases, blogs, app contests, hackathons, information days, or app awards. Furthermore, the re-use conditions (license) need to be communicated to make sure that users understand the conditions. The involvement of external stakeholders should be linked to the business case for selecting datasets in order to make sure that those datasets are opened that attract users.

169

Re-use The fourth phase is the re-use of data. In the case study, however, we found that the data were not re-used during the hackathon â&#x20AC;&#x201C; much to the dismay of the data owners. It seemed that the datasets that were opened did not respond to the wishes and interests of the teams of programmers. They stated that the data that the RTO opened up was often very complex and they could not easily grasp its potential during the one-day hackathon. Potentially, linked data solves this issue (third design rule as presented earlier: provide useful information about the data). Furthermore, there were many other datasets brought in during the hackathon. This meant that especially the step of advertising the data was essential to make sure that data would be re-used. What initially seemed to be a simple activity within the relative confined environment of a hackathon, thereby became a serious bottleneck in the process of opening up data. Having a community manager to guide the data owners through this step in the process is essential. Building a community The first step in fostering re-use is building linked open data communities. Besides advertising the availability of data, the community manager should collaborate with external stakeholders in order to build an active network around your data. Stakehol-

ders can include civil rights organizations, web entrepreneurs, incubators, and research institutes. The community manager and legal advisor need to ensure that the technical, economic and legal requirements set in the preparation phase are implemented. The community manager should develop a plan that describes how to engage the right community, given the linked open data strategy from the beginning of the process. Active community building may also help the process of attracting feedback on the published data, which will help to improve the quality of the data. Managing the data How to manage linked open data? ll Regularly update the data and publish updates to ensure predictability ll Ask users to give feedback on data to increase data quality ll Update metadata ll Link data with new datasets within the community ll Track visitors and users

The responsibility of the information manager and the data owner does not stop after publication. They need to make a plan for how to manage the data and make sure that the data quality remains at the desired level.

170

The information manager needs to be prepared for receiving feedback from users, as well as requests for support during re-use. In time, organizations may even decide to open up their own data portal instead of connecting with existing portals to allow for better management and support.

Evaluation The last phase of the pilot project was the evaluation of the process of opening up data. While this was not a primary activity actually ensuring that data are opened up for the hackathon, it was found to be a crucial activity in the development of an open data strategy, spurred by the lack of re-use of the data that were opened up. Furthermore, during the fall of 2013 it was decided by the Ministry of Economic Affairs that the RTO needs to adopt an open data strategy (at least published under an open license) for all research carried out using public funding. Hence, open data needs to become part of the organizational processes. To prepare for this process, an evaluation of the pilot project was considered necessary. All stakeholders were involved to see how open data can become embedded in the organizational strategy and work processes. Furthermore, the issue of community building to create more value from the datasets that are opened up was also addressed during the evaluation. The RTO considered open data not just

as a ‘compliance’ issue that needs to be ‘ticked off’, but the organization feels the need to actively engage with the community that may want to use its data and support them in the process. Assessing the data proposition The first step of the evaluation phase is assessing the value proposition of linked open data. In this step, the results of publication should be evaluated against the business case that was created earlier. Furthermore, the project manager should assess the impact of the published datasets using other indicators, such as the number of downloads, combinations with other datasets, users, applications and end-users of these applications. This assessment should be shared and evaluated with top management. The project manager may need to keep in mind that the value of open data is broader than merely financial benefits. For example, its social impact, such as increased transparency, can be more important than an increase in revenue – depending on the linked open data strategy that was formulated. It is expected that the evaluation may trigger strategy setting, which will again lead to a new cycle of the lifecycle. Thus, the process of opening up linked data likely requires multiple iterations.

171

Embedding the strategy in the organization and work processes The last step of the evaluation phase is embedding linked open data in the organizational strategy and processes. Top management should follow up the lessons learned of the linked open data implementation in the organizational strategy, paying special attention to any changes in the organizational culture. This may mean an adjustment of the initial linked open data strategy. On the tactical level, the project manager should set practical guidelines for linked open data in the organizational processes. In this way, several steps of this linked open data process can be automated. The project manager and top management should balance innovation initiated top-down (implementing strategy) and bottom-up (encouraging new initiatives).

Conclusion Many public organizations publish their data in an open format to increase transparency and foster economic activity. Most of these organizations strive to open up as many datasets as possible, without considering the strategic importance of open data: how does re-use add to the mission of the organization? To allow for effortless linking of datasets, data being merely machine readable is not sufficient. The standards for linked open data can foster the re-use of open data. The process of opening up linked data is seen as cumbersome and the number of linked open datasets is lacking behind. Lifecycle models can guide the process of publishing linked open data. Current linked open data lifecycle models focus on the technical steps that need to be taken by the internal IT organization and often forget to include actions to be taken after publication. The effectiveness of linked open data, however, depends on how much the data is re-used. Therefore, we developed a linked open data lifecycle model based on literature and practice, using a case study of a semi-public organization in the Netherlands. Firstly, we identified five generic phases of opening up linked data: identification, preparation, publication, re-use, and evaluation. These phases were validated in the case study. The case study shows that the involvement of relevant sta-

172

keholders, both within and outside the organization and of various disciplines, is essential to realize the support for the process and stimulate re-use. The resulting linked open data lifecycle model is developed based on the notion that a clear strategy needs to be in place to successfully open linked data. Currently, many organizations merely focus on compliance with open data regulation rather than they think about the strategic importance. A proper strategy determines choices such as which data to open up, which stakeholders to include, which data quality level to aim for, which portal to use for publishing the data, how to organize legal ownership, etc. While it can be very useful to learn from other organizations, it is even more important to determine what opening up linked data can do for the strategic goals of the organization. If innovation from data re-use is an important goal, it may pay off to identify potential users and their needs in the beginning of the lifecycle, and strive for linked open data to ensure effortless linking. Organizations, however, need to remain open to new opportunities, as the case study shows that it is hard to determine the full potential of data upfront.

References ll Alani, H., Dupplaw, D., Sheridan, J., Oâ&#x20AC;&#x2122;Hara, K., Darlington, J., Shadbolt, N., & Tullo, C. (2007). Unlocking the potential of public sector information with Semantic Web technology. In: The 6th International Semantic Web Conference (ISWC), 11-15 Nov 2007, Busan, Korea. ll Berners-Lee, T. (2006). Linked Data - Design Issues. Retrieved June 5, 2013, http://www.w3.org/ DesignIssues/LinkedData.html ll Blanchard, B.S. & Fabrycky, W.J. (2006). Systems Engineering and Analysis, Fourth Edition. Prentice Hall. p. 19.Brink, van den, L. Overbeek, H., Brentjens, T. (2013). Designing A URI Strategy For The Dutch Public Sector, in Pilot Linked Open Data â&#x20AC;&#x201C; Part 2. http:// www.pilod.nl/Boek/BrinkEtAl-URI ll Ferrara, A., Genta, L., & Montanelli, S. (2012). Tailoring linked data exploration through inCloud filtering. In Proceedings of the 2012 Joint EDBT/ICDT Workshops (pp. 140143). ACM. ll Folmer, E. (2012). Quality of Semantic Standards, PhD Thesis, University of Twente. ll Harrison, T. M., Pardo, T. A., & Cook, M. (2012). Creating Open Government Ecosystems: A Research and Development Agenda. Future Internet, 4(4), 900-928.

173

ll Hausenblas, M. (2011). Linked data lifecycles, presentation from DERI research institute, Galway, Ireland, July 2011. ll Huijboom, N., Broek, T. van den (2011). Open data: an international comparison of strategies. European Journal of ePractice, 1 ll Hyland, B. (2010). Preparing for a linked data enterprise. Linking Enterprise Data, 51-64. ll Hyland, B., & Wood, D. (2011). The Joy of Data-A Cookbook for Publishing Linked Government Data on the Web. In Linking Government Data (pp. 3-26). Springer New York. ll Jaeger, P.T., & Bertot, J.C. (2010). Transparency and technological change: Ensuring equal and sustained public access to government information. Government Information Quarterly, 27(4), 371-376. ll Janssen, M. & Zuiderwijk, A. (2012). Open data and transformational government, presented at the eGov conference, 8-9 May 2012, Brunel University, United Kingdom. ll Janssen, M., Charalabidis, Y., & Zuiderwijk, A. (2012). Benefits, Adoption Barriers and Myths of Open Data and Open Government. Information Systems Management, 29(4), 258-268.

ll Lane, S., & Richardson, I. (2011). Process models for service-based applications: A systematic literature review. Information and Software Technology, 53(5), 424-439. ll McDermott, P. (2010). Building open government. Government Information Quarterly, 27, 401-413. ll Stallinger, F., Neumann, R., Schossleitner, R., & Zeilinger, R. (2011). Linking Software Life Cycle Activities with Product Strategy and Economics: Extending ISO/IEC 12207 with Product Management Best Practices. Software Process Improvement and Capability Determination, 157-168. ll Tsai, N., Choi, B., & Perry, M. (2009). Improving the process of E-Government initiative: An indepth case study of web-based GIS implementation. Government Information Quarterly, 26(2), 368-376. ll Vickery, G. (2011). Review of recent studies on PSI re-use and related market developments. Information Economics, Paris. ll Villaz贸n-Terrazas, B., Vilches-Bl谩zquez, L. M., Corcho, O., & G贸mezP茅rez, A. (2011). Methodological Guidelines for Publishing Government Linked Data. Linking Government Data, 27-49.

C2 - How to publish Open Data on the Web Auteur

Christophe Guéret (DANS, VU University Amsterdam) There is an increasing interest towards publishing data open on the Web. Opening what used to be closed data brings a lots of opportunities in terms of social and economical development, participatory governance and improvement of research processes. Although the motivation is clear the publication is in practice open to a lot of different options. Even for one motivated in publishing his data online, it remains still unclear how to do it. This chapter discusses the wide range of data publication approaches and pays a particular attention to the Linked Open Data publication principles advocated by the W3C.

Publishing Open Data According OpenDefinition [1] , Open Data is ‘A piece of data or content is open if anyone is free to use, reuse, and redistribute it — subject only, at most, to the requirement to attribute and/or share-alike.’ [A]. This implies no specific way to publish the data, it also gives no clear definition as to what data is. Both points are left up to the discretion of the data publisher.

In order to share his open data on the Web, a publisher will first make his data ready and then put it somewhere where it can be found and downloaded.

Get the data ready A first option for publishing data is the so called ‘CSV’ file. This simple and intuitive format defines a table with rows as data entries and columns as properties for the entries. The first row is typically used to indicate what the column contain and the first column is typically used as the identifier of the entry. Comas or tabs can be used to separate the cells, leading to Coma Separated Values document (CSV) in the former case and Tabular Separated Values document (TSV) in the later. Such documents can be opened by any spreadsheet software for easy manual manipulation and can also be parsed by most popular data processing software. The main drawback of CSV documents is that their semantics is very poor - if not inexistent. The Simple Data Format (SDF [2]) proposed by the OpenKnowledge Foundation is a way to tackle this by associating a JSON document to the raw CSV data. This additional document describes the type of the columns and provides some other meta data that make it easier to consume the CSV data. A similar approach can be found in the Dataset Publishing

175

Language (DSPL [3]) from Google. A DSPL package contains a CSV file with the raw data and an associated extended description of the content in an XML file. Both SDF and DSPL are two good approaches to keep the CSV file as is and provide the necessary meta-data next to it, with the goal of making these CSV files easier to reuse by adding more information related to their semantics. Once the data is ready to be published, either as a CSV or a bundle CSV+Semantics, the next step consists in putting it â&#x20AC;&#x2DC;on the Webâ&#x20AC;&#x2122;.

Put it online Since the advent of Web 2.0 that turned static Web sites into interactive publication platforms, it is now feasible to put anything on the Web in a matter of clicks. Filling in a form and attaching a file is all that it takes to share data on the Web. There are many platforms offering to store and serve open data (e.g. DataVerse [4], EASY [5] and FigShare [6]) and portals to index the content of data sharing platforms that facilitate finding data on the Web (e.g. DataHub [7], DataCatalogs [8], PublicData.eu [9]). Most of these tools offer some interesting features such as tagging of data sets, the attribution of unique identifiers and guaranteed digital preservation.

Consume the data Once the data has been packaged and put online two things happen: the data provider need to regularly update its deposit to ensure the data made available is timely and relevant. Data consumers download the data and then integrate it into their applications. These two processes imply some extra work for both parties. The data publisher has to export his data into another format (there is hardly any information system that uses CSV as a native data backend) regularly and update the meta-data file when something changes in the export procedure. The data consumer also has to keep up with the updates and do some curation and integration work to bind together the CSV files he may harvest from different sources - this is where these meta-data documents provided in SDF and DSPL bundles turn out to be important. Data consumers are also likely to have to deal with a lot more data than the amount they actually need for their application (e.g. download data about all the cities in the Netherlands to make a mobile application used in a small and unknown in advance - fraction of those places). The answer to these issues lies in the providing of so called REST application programming interfaces. ProgrammableWeb [10] references 5880 such

176

APIs on the Web, out of a collection of 9256. Following this approach the data publisher make available an API that is connected to his data. Instead of, or in parallel to, providing dumps of the content of a given information systems, data consumers can query this content through a number calls similar to those found when dealing with libraries in any programming language. APIs also have the advantage of providing an easy way to control the access to the data. As an example, the API of GeoNames can be freely used for a small amount of requests but has to be paid for for bigger information needs. Offering an API and semantically annotated data dumps, along with a proper HTML page describing the data provided and the interaction with its API is currently recognised as a good practice satisfying both the need of data consumers and publishers. In this picture Linked Data stands as a way to unify the publication of the data to its semantics and to its API. Data published as Linked Data uses the Web as the API for accessing it and allows for the publication of both the raw data and its semantics within the same platform.

Publishing Linked Open Data Publishing Linked Data boils down to using the Web as a plaform. It is publishing data in the Web rather than on the Web. For this reason, HTTP

URIs similar to those used for Web documents are used to identify resources [B]. The resources are most of the time equivalent to the data entries found in CSV documents (the rows of the files). When links are established among the different resources the data is said to be ‘5 stars’ [C]. Linked Open Data is commonly used to speak about Open Data published according to the Linked Data publication principles. There exist many good references to get to know more about the publication of 5-star data and tools to make this happen. Some of these will be covered in other chapters of this book. In the following two sections we will focus on some basic aspects around the publication of Linked Data: provide de-referencable URIs to the resources and making additional APIs available to query the data.

Create de-referencable resources To get a grasp of what making de-referencable URI for resources means let us have a look at how DBpedia does it. DBpedia is a Linked Data data set which is composed from factual information extracted from Wikipedia. One part of this data contains information such as the mayor name and the population size of cities in the world. If that data would be published as CSV, this part of the data set would be one huge ‘cities.csv’ with

177

one city per row and all the information (mayor name, population size, …) dispatched in as many columns. One such row would contain information about ‘Amsterdam’ in the Netherlands. In DBpedia, Amsterdam gets the identifier ‘dbpedia:Amsterdam’ [11] rather than an abstract code (e.g. ‘2759793’) or a raw name (e.g. ‘Amsterdam’).The main drawback of using a code is that this code is unique only within a given information system. Collisions are expected to raise when several files using different internal attribution schemes are brought together. Raw names are most often too ambiguous to be meaningful. In the present case ‘Amsterdam’ should be replaced by ‘Amsterdam, Netherlands’ to bring more context but this may not be enough in all the cases as some city names are sometimes re-used across the same country. It must be noted URNs solve the problem of

colliding code spaces but does not provide de-referencability directly. These URNs, such as DOI, have to be coupled with a de-referencing service to get to the resource and receive the information associated to it. Compared to abstract codes, raw names and URNs, the usage of HTTP URI provides both unique and dereferencable identifiers to data items. The command line tool ‘curl’ can very conveniently play the role of a software getting the data about Amsterdam. The following line asks for the RDF data about Amsterdam serialised in an XML file: curl -I -L -H “Accept: application/rdf+xml” http://dbpedia. org/resource/Amsterdam The answer from the server is that the description associated to this identifier is located at another URI. That information is provided along with other useful information:

HTTP/1.1 303 See Other Date: Mon, 07 Jan 2013 10:18:36 GMT Content-Type: application/rdf+xml; qs=0.95 Content-Length: 0 Connection: keep-alive Server: Virtuoso/06.04.3132 (Linux) x86_64-generic-linux-glibc212-64 VDB Accept-Ranges: bytes TCN: choice Vary: negotiate,accept Content-Location: /data/Amsterdam.xml Link: <http://mementoarchive.lanl.gov/dbpedia/timegate/http://dbpedia. org/resource/Amsterdam>; rel=”timegate” Location: http://dbpedia.org/data/Amsterdam.xml

178

Following the link that has been indicated to it, curl will open the XML page and get the following associated information. Among all the data provided, there are a number of links to other serialisation formats for the RDF data (for instance, N3) and also links to other encodings for the structured data (for instance, JSON). HTTP/1.1 200 OK Date: Mon, 07 Jan 2013 10:18:37 GMT Content-Type: application/rdf+xml; charset=UTF-8 Content-Length: 578553 Connection: keep-alive Vary: Accept-Encoding Server: Virtuoso/06.04.3132 (Linux) x86_64-generic-linux-glibc212-64 VDB Accept-Ranges: bytes Expires: Mon, 14 Jan 2013 10:18:36 GMT Link: <http://dbpedia.org/data/Amsterdam.n3>; rel=”alternate”; type=”text/n3”; title=”Structured Descriptor Document (N3/ Turtle format)”, <http://dbpedia.org/data/Amsterdam.json>; rel=”alternate”; type=”application/json”; title=”Structured Descriptor Document (RDF/JSON format)”, <http://dbpedia.org/data/ Amsterdam.atom>; rel=”alternate”; type=”application/atom+xml”; title=”OData (Atom+Feed format)”, <http://dbpedia.org/data/Amsterdam.jsod>; rel=”alternate”; type=”application/odata+json”; title=”OData (JSON format)”, <http://dbpedia.org/page/Amsterdam>; rel=”alternate”; type=”text/html”; title=”XHTML+RDFa”, <http://dbpedia.org/resource/Amsterdam>; rel=”http://xmlns.com/ foaf/0.1/primaryTopic”, <http://dbpedia.org/resource/Amsterdam>; rev=”describedby”, <http://mementoarchive.lanl.gov/dbpedia/timegate/http://dbpedia.org/data/Amsterdam.xml>; rel=”timegate” X-SPARQL-default-graph: http://dbpedia.org What happens is that curl is asking for information about the resource and negotiates the type of content to be

returned. This process is also depicted on the following picture from [D]:

179

Content negotiation It is a good practice to add a suffix indicating the nature of the serialisation being returned (‘.rdf’, ‘.n3’, etc) and not to use any suffix for the name of the resource itself. All the different serialisations can be served at different locations, it is a perfectly valid approach to have them being served by different servers. More information about the redirect ‘trick’ and de-referencing to different formats can be found online. There are tools that can be used to take care of dereferencing the entities properly and do the redirect (e.g. Pubby [12] Pages [13], D2RQ [14]).

Provide additional APIs Providing access to the data via dereferencing URIs makes it possible for applications to get all the data related to a particular resource in a easy way. It also makes it possible to cross reference the same unique identifier among different data sets. This however only covers parts of the need of applications.

A basic need such as searching for a particular resource within a data set is not covered by just making 5-star data. Just like publishing a Web site does not make it possible to search for its content. Linked Open Data sets have their search engine in the name of Sindice [15]. Just like Google, Bing and many others Sindice indexes the content of Linked Open Data sets and provide a search feature using this index. The result is a list of resources matching a particular keyword list entered by the users of the portal. In addition to relay on external crawlers, data publishers can provide a SPARQL end point to their LOD. SPARQL is a query language optimised for graph databases storing RDF data. DBpedia offers a SPARQL endpoint [16] , a query service for RDF data. Using this service and the following SPARQL query it is possible to ask for all the resources that correspond to a city with the English name ‘Amsterdam’:

select ?city where { ?city a <http://dbpedia.org/ontology/Place>. ?city <http://xmlns.com/foaf/0.1/name> “Amsterdam”@en. }

180

The result shows that there are several ‘Amsterdam’ in the world: city http://dbpedia.org/resource/Amsterdam http://dbpedia.org/resource/Amsterdam,_California http://dbpedia.org/resource/Amsterdam_(Amtrak_station) http://dbpedia.org/resource/Amsterdam,_New_York_(city) http://dbpedia.org/resource/Amsterdam,_New_York_(town) http://dbpedia.org/resource/Amsterdam,_Virginia

We can see on these results that Wikipedia extends ‘Amsterdam’ with additional qualifications to disambiguate the raw label. Another interesting thing to look at is the different output format provided by the interface for entering the SPARQL query. Results can be delivered in a wide range of encoding, from RDF/XML files to JSON documents. SPARQL is a query language that make is possible to express any kind of query over the data. In contrary to other query protocols such as SQL, its transport layer is HTTP. This make it possible to re-use caching and access control available for Web documents also for SPARQL requests, it also facilitates implementing SPARQL libraries.

But SPARQL is not the only API that can be deployed on top of data published as Linked Data. As showcased by the Ordnance Survey [E], combining de-referencing with SPARQL and a set of REST API is perfectly achievable and provide all the flexibility data consumers may require.

181

References [A] Open Knowledge Foundation, ‘Open definition’, http://opendefinition.org/ [Accessed June 2013] [B] Tim Berners-Lee, ‘Linked Data design issues’, http://www.w3.org/DesignIssues/LinkedData.html [Accessed June 2013] [C] Michael Hausenblas, ‘5 star data’, http://5stardata.info/ [Accessed June 2013] [D] Jeni Tenisson, ‘Creating URIs’, http://data.gov.uk/resources/uris [Accessed June 2013] [E] Ordnance Survey, ‘Ordnance Survey Linked Data’, http://data.ordnancesurvey.co.uk/datasets/os-linked-data [Accessed June 2013]

Notes [1] opendefinition.org [2] See http://www.dataprotocols.org/en/latest/simple-data-format.html [3] See https://developers.google.com/public-data/ [4] http://thedata.org/ [5] http://easy.dans.knaw.nl/ [6] http://figshare.com/ [7] http://datahub.io/ [8] http://datacatalogs.org/ [9] http://www.publicdata.eu/ [10] http://www.programmableweb.com/ [11] This notation ‘dbpedia:Amsterdam’ is a compact URI (‘CURIE’) using a namespace and an identifier. [12] http://wifo5-03.informatik.uni-mannheim.de/pubby/ [13] http://csarven.ca/statistical-linked-dataspaces#linked-data-pages [14] http://d2rq.org/ [15] http://www.sindice.com/ [16] http://dbpedia.org/sparql

C3 - How to use LODRefine? Auteur

Paul Hermans (ProXML) Context Most of the data are not yet available as triples. They exist in tables, spreadsheets, ...; they are serialised as XML or JSON. The question arises how these can be transformed to RDF triples in an efficient way. A possible tool that can be of help is LODRefine, which is a specialised version of the, initially developed by Google, ‘messy’ data cleaning tool ‘OpenRefine’.

OpenRefine OpenRefine (ex-Google Refine) is a powerful tool for working with messy data, cleaning it, transforming it from one format into another, extending it with web services, and linking it to databases like Freebase. The main functionalities of OpenRefine are: ll explore the contents of the dataset ll clean-up the dataset ll transform the dataset into other formats ll reconcile your data with external datasets using webservices

For more information on the basic non linked open data relatedfunctionalities, I refer to following documentation: ll http://openrefine.org/ ll the Refine tutorial: http://bit.ly/15cOTmM ll http://bit.ly/18BA9zP OpenRefine is an open system that allows to develop plugins to add additional functionalities. You will find the list of extensions here: https://github. com/OpenRefine/OpenRefine/wiki/ Extensions. One notices that some of these extensions are made specifically for bringing data into the linked open data web of for reconciling data with data already published on the web.

LODRefine Comes in LODRefine, which is a packaged version of OpenRefine that bundles these linked open data related extensions. We advise you to use this prepackaged version instead of assembling your own. You find LODRefine at http://code.zemanta. com/sparkica/. Some tutorial material can be found at: ll http://freeyourmetadata.org/ ll http://bit.ly/YVRga8 ll https://vimeo.com/62430786

183

How to use LODRefine Input The datafile used in this procedure is a spreadsheet file.

Opening LODRefine

Browse to the spreadsheet file and click ‘Next’.

184

OpenRefine dedected that it is an excel file. It opened the first worksheet. It will consider the first line as a header row and has some defaults for threating blanks. For this exercise we will use the second worksheet (‘Begrippen’) and skip blank rows.

Click ‘create project’ which gives us a view on 40 rows.

Investigate and clean-up your data There is a column with name ‘relations’. I want to generate a list of the values used. This can be done by choosing in the dropdown to the left of the column name (Facet > Text facet). Then I get following facet widget (below).

Result:

Someone has been using all caps, let’s uniformize this. OpenRefine comes with lots of prebuilt functions for modifying and transforming content. For this case I can use the ‘To titlecase’ function.

The next point that gets our attention is the strange double of ‘‘Buitenlandsevenootschap-adres’. By clicking the edit button next to the string we get a closer look on what the value exactly is.

186

We see that the second value has a trailing space. Remove it and confirm (Apply) and you get.

The initial action we should take is adding vocabularies we are going to need and establish prefixes for them. You see that rdf, rdfs, owl and foaf are preloaded. My habit is to always add dcterms and skos. In addition to these publicly available vocabularies we add also a for this project custom made one, which we have on file.

These are just a few possibilities to discover and cure the ‘messiness’ of your data. For more info on this we refer to the regular OpenRefine documentation, tutorials and video’s.

Export2RDF The functionality which is of most interest to us is the ability to map the table we have now to RDF. For this we need to establish a mapping between the cells of our table to corresponding triples. For this we use a RDF skeleton.

187

Next step is to assign a unique identifier for every thing e.g. Begrip the table describes. We follow here following URL pattern: http://data.stelselcatalogus.nl/ {basisregistratie}/id/concept/ {id}. Since we don’t have a real unique identifier in the source, we will build a the {id} part based on field ‘Naam’. To implement this pattern we can rely on the built-in GREL language (Google Refine Expression Language) of LODRefine (http://bit.ly/13O09Ig). Click URI, then you get the RDF Node configuration pane and go direclty to edit/preview.

A little bit of explanation. We concatenate using + 4 pieces of which 2 are fixed strings, hence surrounded with double quotes. “http://data.stelselcatalogus. nl/” + {basisregistratie} + “/ id/concept/” + {naam} We can fill in the variable {basisregistratie} with the information contained in column ‘BASISREGISTRATIE’. The {naam} we find in column ‘BEGRIP(PEN). The GREL function to grab cell content is cells[‘{columnname}’].value “http://data.stelselcatalogus.nl/” + cells[‘BASISREGISTRATIE’]. value + “/id/concept/” + cells[‘BEGRIP(PEN)’].value To finalize we need to lowercase the values of basisregistraties and need to replace the spaces en some other characters in the name, giving us “http://data.stelselcatalogus. nl/” + toLowercase(cells[‘BASISR EGISTRATIE’].value) + “/id/con-

188

cept/” + replaceChars(cells[‘BEG RIP(PEN)’].value,’ ()’,’_’) Now that we have established our identifiers, the next step is to indicate what we are talking about. Every item in this spreadsheet is an instance of a skos:Concept. Hence we click add rdf:type in the RDF skeleton and choose:skos:Concept. Next check what we have done by going to the RDF Preview. Our first triples :-).

Leaves us to map the existing columns on properties. Just one example, we decide to map the column ‘BEGRIP(PEN)’ to the property skos:prefLabel.

With following result:

189

A final adjustment we can make is to indicate the datatype or language of the value of skos:prefLabel.

Reconciling with other datasets The big idea behind linked data is that we reach out to other already published datasets. We can do so by replacing string values in our own dataset with unique identifiers existing elsewhere. In our example it would be good to replace the string name of the basisregistrations with an already existing identifier as available at a sparql endpoint. We use for this the built-in reconciliation service.

With result:

So this should be enough introduction to get you going on your own. Once all wihed mappings are done, the final step is to export to RDF.

We indicate the address of the SPARQL endpoint we want to use and all the labels that can be used to match the strings we have in the column of our source. In this case we added skos:altLabel. Now that we have defined our reconciliation service, we move back to our table. First we add an additional column based on the existing â&#x20AC;&#x2DC;BASISREGISTRATIEâ&#x20AC;&#x2122; one.

190

LODRefine proposes some classes that fit best your needs. Indicate the one that is most specific. Click ‘start reconciling’ and the quality of the matching result is indicated in the column header. In our case a 100% match.

And give the new column a name; we used ‘BR_recon’. Then we start the reconciliation using our previously defined reconciliation service with name ‘BR’.

191

The only thing left is to grab the identifiers. This is done by a transform using following GREL statement: cell. recon.match.id

Conclusion LODRefine should be part of any Linked Open Data toolchain. Next to all the cleaning goodness it allows you to map lots of legacy formats (csv, excel, json, xml, â&#x20AC;Ś) to be transformed into RDF. Furthermore it allows you to replace string values with identifiers already used in the Linked Open Data web, so your triples get linked into this cloud also.

C4 - Semantiek en Linked Data Auteur

Lieke Verhelst MSc (Linked Data Factory) De waarde van data, ook Linked Data, wordt in grote mate bepaald door de aanwezige beschrijvende informatie. Bij Linked Data is deze beschrijving vastgelegd in een semantisch model of vocabulair. Het vastleggen van de betekenis van data door semantische modellen gaat beter dan bij tabulaire data. Dit komt doordat een semantisch model niet beperkt is, maar juist oneindig. Iedereen kan een semantisch model maken waarmee een onderwerp wordt beschreven. Soms worden daardoor onderwerpen door meerdere partijen vastgelegd. Dit is geen probleem omdat volgens de principes van het Semantisch Web elke partij het onderwerp vanuit zijn eigen context mag beschrijven.

Neelie Kroes, Vice-President van de European Commissie en Eurocommissaris verantwoordelijk voor de Digitale Agenda, zegt het frequent: ‘Open Data is de olie van het digitale tijdperk’ (Kroes, N. 2012, 2011). De waarde van data is veelbelovend, enorm, en groeiend. Maar we moeten hier wel een kanttekening plaatsen. De kanttekening kunnen we illustreren met de onderstaande Tabel 1. Wat is de waarde van de data in deze tabel? Inderdaad. Niet veel. Wat betekenen de getallen? Die namen..wat voor mensen zijn dat? En dat kruisje..dat zal wel iets van ‘aanwezig’ betekenen zeker? Wat hier mist is de omschrijving van wat de gegevens in de tabel betekenen. Zonder de omschrijving is de tabel abacadabra, en dus zonder waarde. De omschrijving van gegevens staat, onder andere, in de kolomdefinitie (Tabel 2). Als we die hebben, weten we dan meer?

33 Amsterdam Johannes Janssen

428 Oegstgeest Peter

Michaels

5 Kerkrade Michiel

Vanberghe

Tabel 1 - Tabel met alleen data

aantal plaats

voornaam

achternaam betaald

33 Amsterdam Johannes Janssen

428 Oegstgeest Peter

Michaels

5 Kerkrade Michiel

Vanberghe

Tabel 2 - Tabel met kolomdefinitie en data

193

Door de toevoeging van de kolomnamen zou je kunnen concluderen dat het databestand een registratie van een vogeltelling bevat, gedaan op een bepaalde plaats, door de leden van een vereniging. Maar je zou ook kunnen denken dat het bij het aantal gaat om verkeersovertredingen, en dat de plaats de geboorteplaats is van de personen, en dat ze wel of niet de bekeuring hebben betaald. Het helpt als er een beschrijving is van het databestand. Bijvoorbeeld: wanneer het is gemaakt, en op welke manier, door wie. Als een dergelijke beschrijving er niet is, kunnen we afgaan op onze eigen inzicht. Dit wordt bepaald door onze ervaring, opleiding, leefwijze..dus onze context. Iemand die een rijbewijs heeft (en dus boven de 18 is) weet uit ervaring dat 428 verkeersovertredingen een beetje veel is, en 5 vogels bij een vogeltelling weer erg weinig. Aan de andere kant.. we weten niet wat de totale periode is waarin geteld zou zijn, dus wellicht is het aantal verkeersovertredingen best mogelijk. Met andere woorden: data krijgt waarde door een goede beschrijving van de betekenis. Daarbij is ook de context van de gebruiker van belang, en de context van de data zelf. Bij tabulaire data wordt de betekenis vastgelegd door de kolomdefinities, de tabelnamen en de relaties tussen de tabellen. En als er een beschrijving is van het dataset in zijn geheel dan

wordt dit vastgelegd in de metadata. Een ander woord voor ‘betekenis’ is semantiek. Het woord ‘semantiek’ is sterk verbonden met Linked Data. Tim Berners-Lee schreef zijn gedachten over het Semantisch Web al op in 1998 (Berners-Lee, 1998). In de volgende paragraaf wordt beschreven wat de relatie is tussen het Semantisch Web en Linked Data. Het geeft ook antwoord op de vraag waar de betekenis van de gegevens in Linked Data wordt vastgelegd.

Het Semantisch Web Tim Berners-Lee is de uitvinder van het World Wide Web. Hij bedacht in 1989 het mechanisme van het koppelen van webdocumenten via hyperlinks. Toen het web zich gedurende de jaren 90 van de vorige eeuw ging ontwikkelen tot een web van documenten noteerde hij zijn visie over het Semantisch Web in zijn webnotitieblok ‘Design Issues’. Dit was in 1998. Hij realiseerde zich dat het web van documenten vooral goed gebruikt kon worden door mensen. Hij stelde zich de vraag hoe het web zich zou moeten ontwikkelen wilde het ook ‘leesbaar’ zijn voor machines. Als dat namelijk het geval zou zijn, zou het web kunnen dienen als een soort informatierobot die allerlei taken voor ons zou kunnen uitvoeren. Het antwoord op die vraag was dat het web zich zou moeten ontwikkelen tot een web met beschrijvingen van concepten die door logi-

194

sche regels met elkaar in verbinding staan. Hiermee legde hij de blauwdruk voor het Semantisch Web. Het Semantisch Web is een netwerk van conceptuele beschrijvingen die de betekenis van ‘dingen’ vastleggen. Dit netwerk bestaat uit een grote hoeveelheid van sets van drie elementen, de zogenaamde triples. Elk triple bestaat uit een subject (onderwerp), predicate (eigenschap) en object (lijdend voorwerp of waarde). Bijvoorbeeld: <een schilder> <schilderde> <een schilderij>. Dit model heeft een richting, te zien aan de pijl in bovenstaande afbeelding. Je kunt ook

Figuur 1 - Een triple

zeggen: <het schilderij> <is geschilderd door> <een schilder>. De pijl staat dan de andere kant op en de betekenis van het predicate is anders. Om de betekenis van iets vast te leggen heb je natuurlijk niet genoeg aan één triple. Je hebt er een heleboel nodig en zo ontstaat een web van triples die gezamenlijk de betekenis van iets vastleggen. Net zoals bij het web van documenten publiceert

Figuur 2 - Meerdere triples maken samen het Semantisch Web

iedere deelnemende partij een deel van het gehele semantische web (figuur 2). Het voorbeeld van de schilder en het schilderij zou bijvoorbeeld door een museum kunnen zijn gemaakt. Een andere partij kan hieraan zijn eigen semantische schema koppelen. De stad waarin het museum staat zou bijvoorbeeld de beschrijving van het functioneren van een museum in de stad kunnen koppelen aan figuur 2.

Figuur 3 - De semantische beschrijving van het museum gezien vanuit de context van de stad

Het koppelen gaat via een of meerdere predicate beschrijvingen (het pijltje in de triple afbeelding). Zo beschrijft een museum het begrip ‘museum’ vanuit de context van de culturele inhoud, en de stad beschrijft hetzelfde begrip vanuit de context van de sociale functie van het gebouw. Hoe meer partijen het begrip ‘museum’ semantisch gaan beschrijven, des te waardevoller wordt de

omschrijving. Figuur 2 en 3 samenvoegend krijg je dan de afbeelding in figuur 4.

Figuur 4 - De twee contexten rond het begrip ‘museum’ samengevoegd

196

Het Semantisch Web is dus een op web technologie gebaseerd netwerk dat de semantiek van dingen vastlegt. De onderdelen van een triple bestaan op het web via HTTP webadressen (URL’s). Elk onderdeel heeft een uniek webadres. Dit netwerk kan heel goed gebruikt worden om data van betekenis te voorzien. Dat is het principe van Linked Data: de data worden gekoppeld aan de begrippen in het semantisch web. Wat is data eigenlijk? Data zijn gegevens die werkelijk bestaan. Dus in het voorbeeld van het schilderij is dat ‘de Mona Lisa’. De schilder is ‘Leonardo da Vinci’. Het conceptuele triple wordt voorzien van ingekapselde feiten, en zo ontstaat Linked Data: <een schilder> <Leonardo da Vinci> <schilderde> <een schilderij> <de Mona Lisa> Hoe je zelf een semantisch model maakt om je data te beschrijven wordt uitgelegd in de volgende paragraaf.

ontology editor te gebruiken. Hiervan zijn er vele in omloop. Sommige als betaald product, andere als open source. De in de pilot meest gebruikte commerciële editor is TopBraid Composer (www.topquadrant.com). Een goed alternatief is de open source editor Protégé (http:// protege.stanford.edu). Het semantische model maak je door subjecten en objecten vast te leggen, en deze te koppelen via properties (predicates). Een object kan twee verschillende gedaanten hebben. Het kan zelf weer een object zijn, of het kan een waarde hebben. In het eerste geval wordt de koppeling gelegd door een object property, en in het tweede geval van een datatype property. Een datatype property kan een tekstwaarde bevatten, of een getal, datum, boolean waarde etc. In de figuren 2, 3 en 4 zijn de pijlen die wijzen naar ovalen object properties, en de pijlen die wijzen naar een vierkant zijn datatype properties.

Het maken van een semantisch model

In de volgende afbeeldingen zal stap voor stap getoond worden hoe figuur 2 is gemodelleerd in de ontology editor Topbraid Composer Free edition (TBC).

Een semantisch model zoals bijvoorbeeld figuur 2 wordt vastgelegd in een machineleesbaar formaat. Dit model zou je in een tekst editor (zoals bijvoorbeeld windows notepad) kunnen maken, maar dat is wel een monnikenwerk. Het is makkelijker om een

Stap 1 Open TBC en je ziet een leeg scherm met vakken zoals figuur 5. Links is het vak waar de objecten en subjecten inkomen (classes) en rechts worden de predicates (properties) genoteerd.

Figuur 5 - Het openingsscherm van Topbraid Composer

Stap 2: Eerst moeten een leeg bestand aangemaakt worden via File..New..RDF/OWL file. Noem het bestand â&#x20AC;&#x2DC;museumâ&#x20AC;&#x2122;.

Figuur 7 - Het in Topbraid Composer geladen basisschema RDF/OWL Figuur 6: Maak een leeg RDF/OWL bestand

198

In het lege scherm is nu het basisschema geladen waarin we de classes en properties kunnen vastleggen. Stap 3: Maak de classes aan. Dit doe je door op het icon te klikken. Ga op owl:Thing staan en maak alle classes aan (figuur 8).

Stap 4: maak alle properties aan. Maak hierbij goed onderscheid tussen de datatype properties en de object properties (figuren 9 en 10). Figuur 9 - Het maken van een datatype property

Figuur 8 - Het aanmaken van de classes

Figuur 10 - Het maken van een object property.

In het semantische model van figuur 2 bestaat een pijl met als waarde ‘is een’. Dit geeft de klasse-subklasse relatie aan: een ‘Kwast’ is een subklasse van ‘Instrument’. Subclasses staan ingesprongen onder de klasses. In TBC kun je dit realiseren door de klasse ‘Kwast’ met de muis onder ‘Instrument’ te slepen.

Figuur 11 - Klasse ‘Instrument’ en subklasse ‘Kwast’

Figuur 12 - Alle klassen en properties zijn vastgelegd in het semantische model

Als alles gedefinieerd is ziet je scherm er uit zoals in figuur 12. Het semantische model is nu af (www.linkeddatafactory.nl/voc/museum.owl). Dit is de meest eenvoudige vorm. Het is mogelijk het model te vullen met logische regels (als..dan, NOT, AND, OR) die de beschrijving van de concepten nog meer bepalen, maar meer uitleg hierover valt buiten de scope van dit boek. Door het model te vullen met data bepaal je welke klassen welke properties krijgen. Hoe het vullen van het model met data in zijn werk gaat wordt beschreven in het hoofdstuk over LOD Refine.

Een ander woord voor een semantisch model is een vocabulaire. Omdat er behoefte was aan een standaardisatie in vocabulaires zijn er door specialistische organisaties, zoals de W3C en universiteiten, al een groot aantal vocabulaires gemaakt. Een aantal van de vocabulaires die in de LOD pilot zijn gebruikt zijn opgenomen in Tabel 3. De bestaande vocabulaires kun je gebruiken om Linked Data mee te maken. Je kunt ze ook aanvullen met elementen uit een vocabulaire dat je zelf hebt ontworpen. Gebruik hiervoor de ‘import’ functie (zie Figuur 12, het tabblad ‘imports’ onderaan in het midden van het scherm).

200

naam vocabulaire

eigenschappen beschrijving van

Dublin Core

‘Basis metadata’ voor simple en algemene beschrijvingen van informatiebronnen

http://dublincore.org/

FOAF (friend of a friend)

Sociale netwerken van vriendschap en menselijke samenwerkingsvormen, zakelijke netwerken en informatienetwerken

http://xmlns.com/foaf/spec/

WGS84

Geografische lengte- en breedtegraad en andere geografisch gerelateerde informatie. WGS84 is gebruikt als referentie.

http://www.w3.org/2003/01/geo/

Schema.org

Oorspronkelijk ontworpen om content van zoekmachines semantisch te annoteren. Bevat daarom veel onderwerpen die vaak gezocht worden zoals, muziek, kunst, afbeeldingen, gebeurtenissen, recepten, organisaties en mensen

http://schema.org/docs/schemas.html

webadres

Tabel 3 - Enkele vocabulaires die als een informele standaard worden gebruikt

De waarde van semantiek Data is de nieuwe olie van deze tijd mits de betekenis goed is beschreven en er rekening wordt gehouden met de context van de gebruiker en de data zelf. Dit geldt ook voor Linked Data! Het beschrijven van de betekenis en de context van data via semantische modellen gaat beter dan bij tabulaire data. Dit komt doordat een semantisch model niet beperkt is, maar juist oneindig. Iedereen kan een semantisch model maken waarmee een onderwerp wordt beschreven. Soms worden daardoor onderwerpen door meerdere partijen vastgelegd. Dit is geen probleem omdat elke partij het onderwerp vanuit zijn eigen context kan beschrijven. Mochten er zaken werkelijk dubbel zijn beschreven, dan

kunnen partijen de identieke relatie tussen de onderwerpen vastleggen via de property ‘sameAs’. We kunnen onderwerpen die al beschreven zijn in het Web van Documenten omzetten naar het Semantisch Web. Dat gebeurt bijvoorbeeld al bij Wikipedia. De onderwerpen die in Wikipedia staan zijn semantische beschreven en de Wikipedia pagina’s zijn met behulp van deze beschrijvingen omgezet naar Linked Data. Deze Linked Data versie van Wikipedia heet DBpedia. Dit is een goede bron om te gebruiken wanneer je je eigen Linked Data wilt verrijken met context informatie. In het voorbeeld van het museum vocabulaire is DBpedia te koppelen aan de ‘schilder’ ‘Leonardo da Vinci’ via de sameAs relatie:

201

semantische modellen is specialistenwerk. Met behulp van dergelijke vocabulaires is het mogelijk om reeds gepubliceerde Linked Data te verrijken via inference en links naar andere bronnen. Figuur 13 - Het semantisch koppelen van identieke begrippen

Via deze koppeling kun je vervolgens alle gerelateerde informatie over Leonardo Da Vinci uit DBpedia ophalen! Er is nog een andere manier om Linked Data te verrijken. Die manier heet inference (gevolgtrekking). Inference is gebaseerd op de logica die in de vocabulaires is opgenomen. Via deze logische regels worden de feiten die in de Linked Data zijn vastgelegd (feiten zoals: ‘Leonardo da Vinci schilderde de Mona Lisa’) geëvalueerd. Er worden overeenkomstige conclusies getrokken, die weer tot nieuwe feiten leiden. Deze nieuwe feiten zijn op zichzelf weer een bron voor inference, waardoor een vliegwieleffect optreedt.

Conclusie Om data werkelijk de waarde te geven die het in potentie heeft moet het voorzien zijn van de juiste betekenisbeschijvingen. Bij tabulaire data is dit geregeld via metadata, kolombeschrijvingen, tabelnamen en -relaties. Bij Linked Data wordt betekenis vastgelegd via semantische modellen. Het maken van kwalitatief goede

Referenties ll Kroes, N (2012) ‘From Crisis of Trust to Open Governing’, speech, Bratislava, 5 March 2012. http://europa.eu/rapid/ press-release_SPEECH-12-149_ en.htm ll Kroes, N (2011) ‘Data is the new gold’, speech, Brussel, 12 December 2011 http://europa.eu/rapid/ press-release_SPEECH-11-872_ en.htm ll Berners-Lee, T (1998)’Semantic Web Road map’ onderdeel van ‘Design Issues, Architectural and philosophical points’, Tim Berners-Lee, webpagina http://www.w3.org/DesignIssues/ Semantic.html

Verklarende woordenlijst ll Context - samenhang: het woord ontleent zijn betekenis aan de context aan het overige deel van de zin (bron: van Dale). ll Inference: het via logische regels die in een vocabulaire zijn opgeslagen afleiden van nieuwe feiten. ll Metadata: dossier/logboek van een databestand (bron: van Dale). ll Vocabulaire: semantisch model

C5 - How to: Linking resources from two datasets Auteur

Mapping ontologies

Christophe Guéret (DANS, VU Univerity Amsterdam)

There are many systems designed to establish mapping between concepts from ontologies, an overview of some of them can be found on the ontology matching website [2]. When looking for a specific matcher it is interesting to look at the results of the Ontology Alignment Evaluation Initiative (OAEI) [3]. This competition is held yearly to benchmark different systems against a set of varied datasets. The outcome is an overview of which matchers performs best on which type of dataset (among those that have been submitted to the benchmark).

The Linked Data publication principles define a way to share data while using the Web as a publication platform. Just like the Web is used to publish documents it can also be used to publish factual data. URIs are used to design resources with are described with property/values pairs and connected to other resources with typed links. These links between resources makes it possible to browse Linked Data and jump from resource to resource. They are also used to enrich datasets by connecting the resources with related datasets. But the best part is that anyone can create and publish these links! In this document we will describe how two relate resources from two public datasets using a tool called ‘SiLK’. The links will be published by a third party which is the linker tool provided by the semantic search engine Sindice [1].

How to link datasets? There are many tools that can be used to link resources across two datasets. Choosing one of them will depend on the type of resources you want to link and the preferences in term of interfaces.

Mapping instances In contrary to mapping ontologies, which involves aspects such as looking at the concept usages or their place in a tree, mapping instances is simpler. The problem typically consists in comparing the description of a resource with the description of another one and take a decision based on their similarity. Considering a set of resources from a dataset ‘Source’ and a set of resources from another dataset ‘Target’, the comparison will be run on the cross-product of all resources from ‘Source’ against all the resources from ‘Target’. There is again a variety of tools able to perform such comparisons. The Silk Link Discovery Framework (SILK) [4] and LInk discovery framework for MEtric Spaces (LIMES) [5] are two link discovery platforms that are doing all

203

these comparisons in an optimised way. Both make use of tricks to prune the list of comparisons to make and shorten the processing time. They are provided with a graphical interface to parameter the software and they can be executed on desktop computers as well as servers running Hadoop. An alternative is to generate the links manually if the URI are intuitive. For example, it is easy to guess the DBpedia resource associated to any Wikipedia page because they use the same identifiers, only the namespace changes. This makes it possible to guess that the resource associated to Amsterdam is dbpedia:Amsterdam [6] because its Wikipedia page is Wikipedia:Amsterdam. Intuitive URIs are very convenient for developers that can leverage them to generate links across datasets without having to use any linker software.

Letâ&#x20AC;&#x2122;s go! The Linker service [7] provided by the semantic search engine Sindice is a hosted version of SILK that let everyone create links without having to install SiLK locally. This is the reason why we will use this service in the remaining part of this chapter. Installing SiLK locally on a machine is not complicated though, we will come back to that a bit later. As an example, we will connect the categories found in Isidore [8] to those of DBpedia [9].

Get an account The linker service can be found at http://linker.sindice.com, the home page at this address shows the number of links the platform generated so far and feeds for these links. Anyone can subscribe to the feeds and get the links. The linking specifications hosted on the linker are re-executed

204

on a regular basis in order to cope with changes made in the datasets they interlink. A click on ‘Sign in or register’ leads to a variety of services that can be used to get an account on the linker. Whereas the links can be accessed without being logged in, this step in mandatory in order to submit new linking specifications.

creation of this specification with a simple drag and drop mechanism. A click on the ‘Access workbench’ button from the linker gets you to that workspace. It is relevant here to say that if SiLK is ran locally the exactly same workspace is provided. Everything that follows can thus be tested on the linker site as well as on any other machine. You’re ready to go!

The member area displayed once logged in is a private space with data related to the connected user. From that space it is possible to see the result of the execution of the linking specifications. There is also a link to the workbench on which we will click next. Although the linking specifications are created in XML using the SiLK notation, you will not have to start your favourite XML editor. SiLK comes with a workspace that facilitates the

Identify what to link Before editing the linking specification let us step back to the datasets. It is necessary to identify what will be linked. In Isidore, research documents are described in RDF with a number of properties related to their content. The following table contains the description of one of these documents . In the predicate column all the URIs have been shortened using the prefix registered on www.prefix.cc.

205

Predicate Object rdf:type http://www.rechercheisidore.fr/class/BibliographicalResource rdf:type http://www.openarchives.org/ore/terms/Aggregation dcterms:language http://lexvo.org/id/iso639-3/eng ore:similarTo “ID:REGARDS:63389” dcterms:provenance http://www.regards.cnrs.fr dc:date “2008” dcterms:date “2008-01-01T00:00:00+02:00” dcterms:date http://www.archivesdefrance.culture.gouv.fr/gerer/classement/ normes-outils/thesaurus/T4-46 dc:type Article sioc:topic http://www.rechercheisidore.fr/subject/SHS:SCIPO sioc:topic http://www.rechercheisidore.fr/subject/SHS:SOCIO sioc:topic http://www.rechercheisidore.fr/subject/SHS:ECO dc:language “Anglais” dc:source

“Contemporary (The) Pacific”

dcterms:coverage http://sws.geonames.org/4034749/ ore:aggregates http://regards.in2p3.fr/fiche.php?id=63389 dcterms:identifier “10670/1.2gbtg3” dcterms:identifier http://regards.in2p3.fr/fiche.php?id=63389 dcterms:title

“Wallis and Futuna. [en ligne]. Disponible sur Biblioshs”

dcterms:type http://www.rechercheisidore.fr/ontology/art http://www.rechercheisidore.fr/property/scope http://www.rechercheisidore.fr/subject/secondaires ore:isAggregatedBy http://www.rechercheisidore.fr/resource/10670/2.i2m6vw

Among all these properties, we will focus on sioc:topic [10]. The ontology SiOC [11] is designed to describe resources related to social networks. It is said in the ontology documentation that the property topic defines ‘A topic of interest, linking to the appropriate URI, e.g. in the Open Directory Project or of a SKOS category.’ The following table shows the description of the topic ‘Economies et Finances’ (‘SHS:ECO’).

206

Predicate Object rdf:type skos:Concept skos:broader http://www.rechercheisidore.fr/subject/SHS skos:inScheme http://www.rechercheisidore.fr/categorie skos:prefLabel

“Economies and finances”@en

skos:prefLabel

“Economies et finances”@fr

skos:exactMatch http://calenda.revues.org/categories.rdf#categorie22

Wikipedia also defines a number of topics wiki pages can be associated to. A manual search on the topic ‘Sociology’ allows to find the related DBpedia resource at dbpedia:Category:Sociology. It description contains links to other concepts and links to the similar concept in different localised versions of DBpedia. Predicate Object rdf:type skos:Concept owl:sameAs http://ru.dbpedia.org/resource/Категория:Социология owl:sameAs http://es.dbpedia.org/resource/Categoría:Sociología owl:sameAs http://ja.dbpedia.org/resource/Category:社会学 owl:sameAs http://cs.dbpedia.org/resource/Kategorie:Sociologie owl:sameAs http://pl.dbpedia.org/resource/Kategoria:Socjologia owl:sameAs http://el.dbpedia.org/resource/Κατηγορία:Κοινωνιολογία owl:sameAs http://it.dbpedia.org/resource/Categoria:Sociologia owl:sameAs http://pt.dbpedia.org/resource/Categoria:Sociologia owl:sameAs http://de.dbpedia.org/resource/Kategorie:Soziologie owl:sameAs http://fr.dbpedia.org/resource/Catégorie:Sociologie rdfs:label “Sociology”@en skos:broader http://dbpedia.org/resource/Category:Interdisciplinary_fields skos:broader http://dbpedia.org/resource/Category:Social_sciences skos:broader http://dbpedia.org/resource/Category:Society skos:prefLabel “Sociology”@en prov:wasDerivedFrom http://en.wikipedia.org/wiki/Category:Sociology?oldid=489438713

Our goal will be to establish connections between the topics defined in Isidore and those found in DBpedia. The connection will be expressed using the rdfs:seeAlso [12] property, indicating that when looking at a topic on Isidore more information could be found about this resource by looking at the resource pointed to in DBpedia. Now that we know what we want to link and how it is time to start writing the linking task in SiLK.

Prepare the task The first thing to do is to add the two SPARQL end points for the datasets. DBpedia’s can be found on http:// dbpedia.org/sparql. Click on the ‘+ Source’ button and fill in the form as follows:

Then proceed similarly to add Isidore’s SPARQL end point located at www.rechercheisidore.fr/sparql/:

The next thing to click on is the button ‘+ Task’. The form is used to indicate what is the type of the resources that will be use as a source for the link and where to they come from, along with similar information for the target and the type of link. We want to connect instances from the class skos:Concept [13]. This is the rdf:type [14] of both of our example resources for the topic “SHS:ECO” in Isidore and ‘Category:Sociology’ in DBpedia. When you are about to validate it, the form should have a content similar to this capture:

Once all these steps are completed the dashboard now contains two data sources and a linking task. The data sources can be re-used by many linking tasks, this is why they are declared separately. The next step consists in telling SiLK what to do exactly with the resources gathe-

208

red from the source and target data sources. This will be done by editing the linkage rule.

Edit the linkage rules To open the linkage rule editor click on the button Open located next to the linkage task you want to edit. The editor open and starts to load the properties (this can take some time). Once everything is ready to go, the editor looks like this:

The first block on the left contains the list of properties used to describe the resources found in the source dataset. The box below it contains the properties of the resources in the target dataset. The come the transformation, comparison and aggregation operators. All those items are to be dragged and dropped from their boxes into the big canvas on the right. SiLK allows establishing very complex rules including string transformation and aggregation of several rules. For example, it is possible to say that a link can be created between a source A and a target B is the lower-cased label of A is similar enough to that of B and if their geographical position is the same with a marginal error of 100 meters. But for the sake of clarity we will hereafter compose something much simpler: take the property ‘prefLabel’ from both the source and the target datasets, then drag and drop an equality comparison and connect its input to the two outputs of the ‘prefLabel’ boxes:

209

This simple matching rule says that two resources can be connected only if their label is strictly equivalent. Now it is time to generate the links!

Generate the links To make the linkage task run, click on the ‘Generate Links’ tab and press the button ‘Start’. After a couple of seconds you will see your links starting to appear:

This interface has some advanced features to see which linkage rules have been triggered and mark some of the links as valid or not. It is a good idea to validate a couple of them so that the linker platform can warn you when those are not generated anymore. This could happen if one of the dataset goes offline or changes the way its resources are described.

Now that the linkage rule is in place and that you verified it works you can close everything and just wait for Sindice to generate the links for you. These links will be made available on the homepage of the linker, along with all the other linkage tasks the platform uses.

210

A note about local installation When running SiLK locally on your machine you will have access to two other ways to get your links. The first one is to add an output file the link will be stored into. The second is to point SiLK to a SPARQL end point that supports update queries:

Notes [1] http://www.sindice.com/ [2] http://www.ontologymatching.org/projects.html [3] http://oaei.ontologymatching.org/ [4] http://www4.wiwiss.fu-berlin.de/bizer/silk/ [5] http://aksw.org/Projects/LIMES.html [6] This notation is a compact URI (‘CURIE’) using a namespace and an identifier separated by a ‘:’. [7] http://linker.sindice.com [8] http://www.rechercheisidore.fr/ [9] http://dbpedia.org/ [10] http://rdfs.org/sioc/ns#topic [11] http://sioc-project.org/ [12] http://www.w3.org/2000/01/rdf-schema#seeAlso [13] http://www.w3.org/2004/02/skos/core#Concept [14] http://www.w3.org/1999/02/22-rdf-syntax-ns#type

C6 - How to use AllegroGraph to work with Linked Open Data Auteurs

Dr. Jans Aasman (Franz Inc) Roel Stap (Data for Use) Introduction Most articles in this book focus on interesting applications of Linked Open Data (LOD). But this chapter describes some simple steps on how to use a triple store, how to load linked open data, and how to create SPARQL queries with a graphical query builder. This should allow users new to these topics to better understand the methods and techniques and thus to better understand the more complex examples later in the book.

What are triples and what is RDF? For completeness we’ll introduce the concept of triples here but we assume that the readers of this book are familiar with the RDF stack. The Resource Description Framework (RDF) language is used to express data about resources, where ‘resources’ can be interpreted to be anything (a web page, a person, an idea, etc.). The basic building block is the triple, consisting of subject, predicate, object. The subject is a URI, the predicate is some property that is defined for the type (class) of the subject, and the object is either a typed literal or the URI of some other subject.

Let’s look at a couple of assertions that express data about resources: bb:YogiBerra rdf:type bio:Person . bb:YogiBerra bb:playsPosition bb:Catcher . bb:YogiBerra bb:careerHomeRuns 358 . The first assertion says that a ‘resource,’ Yogi Berra, whose URI is defined in the bb: namespace, is of type Person (where the meaning of Person is defined in the bio: namespace), he played the catcher position (where the meaning of playsPosition and Catcher are defined in the bb: namespace), and he had 358 career home runs (where the meaning of careerHomeRuns is defined in the bb: namespace). This is what data looks like in RDF: triples expressed as a subject, a predicate, and an object, separated by spaces, and concluded with a period. The above description comes from a little mini course in RDF that can be found on the Franz website (www. franz.com).

What is a triple store? An introduction to AllegroGraph Most Linked Open Data comes in the form of files containing RDF triples. In order to work efficiently with triples you need to have a triple store database, that is specialized for storing the triples data format. A good triple

212

store allows you to store triples and index them for fast retrieval, to perform SPARQL queries, and to reason dynamically or through materialization. AllegroGraph is such a triple store with some additional unique capabilities. AllegroGraph Provides: ll All essential enterprise capabilities you expect in a major relational database: ACID transactions (Atomicity, Consistency, Isolation and Durability), backup/restore, point in time recovery, security, replication, warm fail over, clustering, triple level security. ll Geospatial reasoning, temporal reasoning, and social network analysis. These features are all directly accessible in SPARQL. ll Business rules with an ISO compatible Prolog compiler ll Server side JavaScript stored procedures [faulty parallelism. Why not delete Deploy?] ll Gruff, a powerful visualization tool which allows user friendly navigation of triples. Gruff’s graphical query editor allows easy composition of SPARQL queries. ll The ability to automatically discover patterns by highlighting nodes and turning them into SPARQL queries

The example In our example we are going to work with a data set that we extracted from DBPedia, the triple version of the Wikipedia. We took all the infor-

mation about movies and actors, producers and directors and stored that in a single file (N-Triples Format). This file can be downloaded from our website (see instructions below) We are going to use a powerful visual navigation tool called Gruff. Gruff is one of the interfaces to AllegroGraph and it allows you to create a new triple store, download triple files to populate the store, and then query triples or display triples on the screen. Gruff comes in two forms, a standalone version that includes a basic version of AllegroGraph, and the server edition. You will want the server edition if you are working with hundreds of millions to billions of triples. If you just want to look at a few million triples and you don’t have easy access to a Linux Server, then you can just install the standalone version. We are going to use the standalone version in this tutorial. Installing and starting the standalone version Gruff: Visit http://www.franz.com/agraph/ gruff and go to the download section. Assuming you have a 64-bit Windows machine you should download Gruff v5.0.x for AG 3.3. Extract the file that you downloaded into a convenient location (which we will refer to as the Gruff directory). Go into the Gruff directory and double click ‘gruff.exe’

213

Downloading the dataset for our example: The data for or example is in http://bit.ly/126Ng82. Please unzip it and place it in a convenient place.

Once you click ok, the database will ask you how many triples you expect. Just accept the default. This number is only important if you know you are going to use millions of triples.

Creating a new triple store: Creating a triple store is now about as easy as starting an Excel spreadsheet.

Loading data into Gruff: Now we are going to load the file with movies and actors in Gruff. File->Load Triples->Load N-Triples

First we create a new triple store: File -> New Triple-Store

Gruff will ask if you want to load the triples from a file or from the web. Chose ‘file’ for this tutorial. And find the place where you stored the file actors.ntriples downloaded from the Franz Inc website. Select it and load. You will see a yellow bar for a few seconds and if that bar disappears the data is ready to be used.

Because we work with a standalone version we use the name of your local machine, Gruff will probably fill it in for you already. As you can see my laptop is called JansSamsung. Note that you don’t have to fill in a port number. For the Store Folder you will type in the full name of the triple store you are going to create. Make sure it is not an existing directory because it will overwrite that.

Displaying some triples on the screen: To quickly test the data was loaded. From the Gruff menu: Display->Display All Triples Up To A Limit. And after a few seconds you’ll see activity on your screen. Use the wheel on your mouse (or shift- or shift+,) to zoom in and out and then press the letter ‘r’ to reformat the screen. Just for fun you might want to click on a node and go to the Tabular View. Click around a little bit to become familiar with the data. Go back to the Graph View (View->Graph View) or press the letter ‘g’. Now we are going to delete all the information from the screen by

214

Remove->Remove-All-Nodes (Don’t worry, it won’t delete any triples, it will just remove the nodes from the screen) Creating a freetext index and find Kevin Bacon: In many cases you start exploring a set of files by typing in some of the concepts that you know that might be in the file. For that we need text indexing (i.e. Key Word Search, like Google). Display -> Edit Free Text Predicates A widget will pop up, just select all and then click ok. Now we want to find Kevin Bacon: Display-> Display Triples by Freetext Index (or press ‘;’ ) and type Kevin Bacon in the search field. Browse through the results and choose Kevin Bacon and select ok. So now you have one node on the screen that we are going to use in the next section Exploring the Graph in the Graph View: So now we have Kevin Bacon on the screen and we want to see some triples where Kevin is the subject or object. The first thing we want to do is to select the predicates that we want to see on the screen. Type the letter ‘p’ and you’ll see a list of predicates. Choose DS, Director, and Starring and click OK

Now select the Kevin Bacon node and press the letter ‘f’. You’ll see a lot of new nodes come up. Click on a movie and see how that expands by pressing the letter ‘f’. Click a few times on nodes and you’ll see that the screen gets crowded with nodes and links. Zoom in a little bit (use the wheel on your mouse or shift-.) and press the letter ‘r’ to reformat (In the Layout Menu you see all the types of reorganization of the screen provided by Gruff). On the next page (top) is a screen shot that should look similar on your machine. Note how you see on the left side the names of the predicates and classes used as well as the corresponding colors. There are other ways to explore the graph on the screen. Press the letter ‘z’ a few times until only the Kevin Bacon node is on the screen (you might have to zoom back to see his name again). For example: right click on Kevin and play with the first two options (Display

215

connections between nodes. First let us clean up the screen by removing all triples from the screen (Remove -> Remove All Triples) Then use ‘;’ to find Kevin Bacon (or use Display->Display Triples by Freetext Query)

a Linked Node from Menus, Display Linked Nodes from a Tree) to show triples on the screen. Finding the Shortest Path Between Two Nodes: One significant advantage to using a triple store is to let the database find

Do this again to find Arnold Schwarzenegger (just type Arnold and you’ll find him). You should now have two nodes on the screen; Arnold Schwarzenegger and Kevin Bacon. Now select Arnold, press ‘shift-f’, and drag the cursor to Kevin and click and you should see something like the picture below:

216

Exploring a Graph in the Tab View and Outline View First let us discuss the Tabular View. Assuming that you see Kevin Bacon still on the screen, double click on his name (or press the letter ‘t’) and you are in the tabular view. See the picture below. It is kind of self evident on how to navigate through this view. Note that there is a thick grey line in the middle. Above the grey line you have triples that start with Kevin, below the grey line you have triples where Kevin is in the object position of the triple.

Another way to explore the triples is to use the outline view. Click on Kevin again and hit the letter ‘O’ and you’ll see this. Note that black text means that you are going deeper into the hierarchy, the blue text means that you see triples that point back at Kevin. Just play with it and you’ll soon understand intuitively.

Writing a SPARQL Query in Query View: Gruff will help you write SPARQL Queries. If you know SPARQL to some extent then you can go to the query view by pressing the ‘w’ or View>Query View. Select the SPARQL bullet and then just for fun type this little query that will select a hundred random triples from the triple store. Select * where { ?x ?y ?z . } limit 100

First click on the ‘Do Query’ button and then click on the Create Visual Graph button. Writing a SPARQL query with the Graphical Query Builder: Now you don’t need to type SPARQL Queries, you can also build them graphically. Here is a brief example. The query that we are going to build: ‘Who directed the movies that Kevin Bacon starred in?’ 1. Go to the Query Editor view (press ‘e’ or View->Graphical Query View) 2. Use Display->Display Triples by Freetext Query to find ‘Kevin Bacon’ 3. Right click on the screen and choose the first option: create variable node. Give it the name ‘film’ (although you could any name you like, do not add the ? in front of the variable, Gruff will do that for you) 4. Right click on the variable ‘? film’ and choose the first option: Add Predicate Link

5. Drag the cursor to Kevin Bacon and you get the option to choose the name of the link. Choose the option ‘Predicates of Object Kevin Bacon’. AllegroGraph already knows all the predicates pointing to Kevin Bacon so now you just have to choose. Please choose ‘starring’ 6. Now right click on the screen again and create a new variable node, call it ‘director’ 7. Right click on ‘? film’ and ‘Add Predicate Link’. Drag the cursor to ‘? director’. This time choose from ‘All Predicates ‘ and choose ‘director’. 8. Now click on the do-query button and you’ll see how a query gets created and executed.

Conclusion We have shown you a simple way to create a triple store, navigate the triples, and create queries. Please note that we only used Gruff with the built in triple store. For larger data sets and working with SPARQL 1.1 you will want to try the combination of the AllegroGraph server and the client side Gruff.

C7 - BigData4Apps: Van Linked (Open Big) Data naar Contextualized Little Data Auteurs

Chris van Aart Reind van Olst Michiel van Dijk (2CoolMonkeys)

ponenten. Uit diverse professionele app projecten is de BigData4Apps platform ontstaan: een combinatie van gedistribueerde data-, semantic web-, agent-, geo- en mobiele technologie.

Samenvatting

Inleiding

Dit artikel beschrijft ervaringen met het BigData4Apps platform: een platform dat in staat is om van (semi)gestructureerde data, mobile data te maken. Begin 2013 zijn er honderden Nederlandse data bronnen publiek beschikbaar en via App wedstrijden zijn er diverse App concepten bekend. Veel van deze apps maken gebruik van een of een aantal geïsoleerde (open) data bronnen. Met de belofte: is you build it, they will come (uit de film Field of Dream) zijn diverse dataregisters opgericht; waarbij you de data aanbieder is en they derde partijen zijn, de app bouwers die uit data waarde kunnen creëren. De derde partijen worden op dit moment geconfronteerd met gefragmenteerde en nietgecontextualiseerde databronnen. Er kan pas waarde toegevoegd worden als de bronnen geharmonieerd, verrijkt en gecontextualiseerd zijn. App bouwers willen niet geconfronteerd worden met complexe datamodellen, vreemde opslagformaten en onbetrouwbare webservices, maar juist beschikking hebben over app com-

We leven in een tijd waarin transparantie van de overheid meer en meer de norm wordt. Steeds meer overheidsinstanties komen voor keuzes te staan: welke data maken we openbaar? Wat kan de burger ermee? En hoe kunnen we er voordeel uit behalen? Open data hebben enorme potentie. Als ze op de juiste wijze ingezet worden, kunnen ze economische groei en ontwikkeling van de maatschappij stimuleren. Data worden optimaal benut wanneer zij op maat worden geïmplementeerd. Mobiele applicaties, ofwel apps, zijn het ultieme middel om open data op een gerichte en gedoseerde wijze te verspreiden. Apps kunnen eenvoudig gevonden worden in app stores en op het moment dat een app op een toestel van een gebruiker staat, komt het open data gebruik tot leven. De grote uitdaging is: hoe maak je van al die heterogene grote databronnen een goede app?

219

BigData4Apps eco-systeem In BigData4Apps kunnen data aanbieders, zoals overheden, hun data op diverse wijze publiceren. Dit kan via: ll platte tekst (zoals vraag en antwoord van Rijksoverheid.nl) ll tabellen (bijvoorbeeld statistiek van CBS Data) ll geodata (reisadvies van Buitenlandse zaken) ll topografisch informatie (de kadastrale kaart, BAG) ll procedurele kennis (welke stappen moet je doorlopen om een paspoort aan te vragen, gemeente Utrecht).

Figuur 1 - BigData4Apps eco-systeem

De technologie zet deze data om naar linked data en biedt deze vervolgens aan in een eenduidige component. In plaats van een webservice wordt aan de app bouwer een component in de vorm van bibliotheek aangeboden. De app bouwer hoeft zich niet druk te maken over connecties, protocollen, beveiliging, load balancing, etc. De communicatie tussen de app en de data wordt onderwater geregeld door de infrastructuur. De app bouwer kan zich bezig houden met het bouwen van functionele apps.

220

Het BigData4Apps eco-systeem bestaat uit vier onderdelen: 1. data-stekker 2. data-linker 3. query-agent 4. app-agent De data-stekker koppelt met API’s of leest data in via een centrale data repository. De data-linker verrijkt deze data met semantic web URI’s en metadata. De query-agent leeft boven op de verrijkte data en onderhandelt met de app-agent, die op het target device leeft. De app-agent kent de taak van een gebruiker, bijvoorbeeld een archeoloog op zoek naar referentieopgravingen, een toerist op zoek naar een gerelateerd gebouw, een constructeur op zoek naar een leiding in de grond, een officier van dienst (brandweer) op zoek naar alle relevante gegevens van brandend pand, etc. De query-agent verzorgt in een compact en gecontextualiseerd formaat de gegevens naar de app-agent. De app-agent onderhandelt vervolgens met de app-software welke gegevens te tonen en te laten verwerken.

Apps zijn booming Apps zijn ideaal om big/open data gedoseerd en gericht te verspreiden én ze zijn gigantisch populair. Uit cijfers blijkt dat smartphone-eigenaren ongeveer negen apps per maand downloaden, waarvan twee betaalde. iPod-bezitters downloaden zelfs zo’n twaalf apps per maand. In 2015 zal de wereldwijde app-omzet ruim 38 miljard dollar zijn. Er kan dus een groot publiek bereikt worden via apps. Voorbeeld 1: De overheid in de broekzak van de burger Overheidsinstanties kunnen mobiele applicaties gebruiken als extra service. Denk aan een app die de brandweer vliegensvlug inzage geeft in plattegronden van gebouwen. Of een variant die toeristen informeert

Figuur 2 - Voorbeeld toepassing BigData4Apps: gemeente Utrecht

over veiligheid in verschillende landen. Een ander voorbeeld is de bomenspotter (http://bit.ly/13O7gk7): deze app laat alle 180.000 bomen die door de gemeente Utrecht beheerd worden in een mobiele app. Naast het tonen van de bomen op een kaart, is elke boom verrijkt met een Wikipediapagina voor achtergrondinformatie. Voorbeeld 2: Open Huis app De Open Huis app (http:// bit.ly/11jEqZ6 en http://bit.ly/Wl2335) is de eerste mobiele BAG-Viewer. De dataset BAG (Basisregistratie Adressen en Gebouwen ) bevat alle bouwvlakken en adressen van Nederland. Het is gebaseerd op de gegevens van de Basisregistratie Adressen en Gebouwen (BAG). Gemeenten zijn bronhouders van de BAG. Zij zijn verantwoordelijk voor het opnemen van de gegevens in de BAG en voor de kwaliteit ervan. Alle gemeenten stellen gegevens over adressen en gebouwen centraal beschikbaar via de Landelijke Voorziening. De Datastekker van BigData4Apps communiceert met de Landelijke Voorziening. De data is vervolgens verrijkt met de wijken buurtkaart (CBS ). Deze toont de digitale geometrie van de grenzen van de buurten, wijken en gemeenten. De app geeft statistische, demografische en basisgegevens over panden, ook de WOZ. De app wordt gebruikt door makelaars, huizenzoekers, marketeers, bouwbedrijven en zonnepaneelleggers.

Voorbeeld 3: Monumenten App Samen met Gemeente Nijmegen, het NIOD en het Netwerkinstituut van de Vrije Universiteit is de monumentenapp ontwikkeld. Deze app laat ruim 3500 monumenten (http:// semanticweb.cs.vu.nl/verrijktkoninkrijk/ home) in Nederland zien. De BigData4Apps omgeving heeft hier geo- en achtergrondinformatie gecombineerd. De monumenten zijn o.a. verrijkt met geo-data en Wikipedia-paginaâ&#x20AC;&#x2122;s. Via een cubenavigatie heeft de gebruiker vier vrijheidsgraden: van boven naar beneden selectie tussen stad; van links naar rechts, selectie tussen de monumenten. Bij selectie van gemeente Nijmegen wordt een kaart getoond van Nijmegen, met diverse open data kaartlagen, waaronder een oude militaire kaart (1910) en bombardementen uit de Twee Wereldoorlog.

Voorbeeld 4: Testaccio app Testaccio (http://it.wikipedia.org/wiki/ Testaccio) is een wijk in Rome waarin de oudste vuilnisbelt van de wereld ligt. De Monte Testaccio (http://it.wikipedia.org/wiki/Monte_

Testaccio) bestaat uit resten van 53 miljoen kruiken achtergelaten door de Romeinen. Naast de vuilnisbelt bevinden zich diverse archeologische en architectonische objecten in deze wijk. Om al deze objecten inzichtelijk te

maken, is de Testaccio app (http://bit.ly/11KBf9u) ontwikkeld, in opdracht van Koninklijk Nederlands Instituut Rome, het Netwerkinstituut en het SpinLab van de Vrije Universiteit. In deze app zijn meer dan 300 kaarten, 500 fotoâ&#x20AC;&#x2122;s en metadata verwerkt. Voorheen bevond deze data zich in bibliotheken. De BigData4Apps omgeving heeft hier geo- en achtergrondinformatie gecombineerd, zodat de data ook offline beschikbaar is. Nu kunnen studenten, architecten en archeologen deze data onder hun arm in het veld meenemen.

Bottom line Met de belofte: is you build it, they will come (uit de film Field of Dream, http://en.wikipedia.org/wiki/ Field_of_Dreams), waarbij you de data aanbieder is en they zijn diverse

dataregisters opgericht; waarbij you de data aanbieder is en they derde partijen zijn, de app bouwers die uit data waarde kunnen creĂŤren. De derde partijen worden op dit moment geconfronteerd met gefragmenteerde en niet gecontextualiseerde databronnen. Er kan pas waarde toegevoegd worden als de bronnen beschikbaar, geharmonieerd, verrijkt en gecontextualiseerd zijn. Linked (open) data als concept en uitwisselingsformaat (RDF) is bij uitstek geschikt voor het uitwisselen van heterogene (open) data. Semantic web technologie, zoals SPARQL, is geschikt voor complexe data manipulatie. Daarboven op kunnen app eco systemen, zoals BigData4Apps toegevoegde waarde leveren om van Big Linked Data, simple apps te ondersteunen.

C8 - Linked Open Data en Linked Enterprise Data: vervagende grenzen in de ‘extended enterprise’ Auteurs

Bas Geerdink (CSC) John Verhoeven (Inspiring Data) Waarom is het in de ‘extended enterprise’ van toenemend belang om een synthese tot stand te brengen van de reguliere Enterprise Data en de grote hoeveelheden Open Data die uit diverse bronnen beschikbaar is en nog gaat komen? En hoe kunnen we deze synthese tot stand brengen? Om deze sleutelvragen te kunnen beantwoorden, gaan we dieper in op de specifieke dynamiek van de ‘extended enterprise’, en de centrale rol die daarin is weggelegd voor het slim toepassen van allerlei soorten data uit diverse bronnen. We leggen uit hoe je in dit proces toegevoegde waarde kunt vinden in de combinatie van ‘Enterprise Data’ en ‘Open Data’. Hierbij gaan we zowel in op inhoudelijke als op technisch/organisatorische aspecten. Met het explosief groeien van de hoeveelheid Linked Open Data (LOD) worden bedrijven, overheden en kennisinstellingen uitgedaagd tot het ontwikkelen van nieuwe en krachtige instrumenten om zicht te krijgen op deze reusachtige bron van nieuwe kennis. Met de groei van de hoeveelheid kwalitatief hoogstaande informa-

tie wordt het bovendien steeds interessanter om koppelingen te leggen tussen deze externe Open Data en de interne (gesloten) enterprise data. Een derde element dat kwaliteit kan toevoegen aan data, is het gebruik ervan zélf. Het gebruik van LOD in combinatie met enterprise data kan leiden tot verrijking, omdat in de combinatie van datasets nieuwe informatie naar voren komt. In dit verband is een belangrijke trend zichtbaar: de opkomst van de ‘extended enterprise’. In een ‘extended enterprise’ komt informatie niet meer alleen van interne, vertrouwde bronnen, maar ook van externe partners. Deze externe informatie kan zowel afkomstig zijn van professionele partners als van tijdelijke of incidentele allianties , zoals spelers die deze data zelf genereren (zoals de individuele burger). Het bedrijf van de toekomst, de ‘extended enterprise’, zal in staat moeten zijn om, ongeacht de herkomst ervan, data uit diverse bronnen en in diverse formaten te kunnen verwerken, beoordelen en toepassen, zodat de datastroom oplevert waarvoor het bedoeld is: toegevoegde waarde en nieuwe inzichten. Kathedraal of bazaar? Nog maar vijftien jaar geleden was dit een fundamentele tegenstelling tussen twee soorten organisaties. In een kathedraal doe je alles onder centrale aansturing, autonoom, binnen eigen

225

muren. Daar tegenover staat het model van de bazaar: in een open, maar afgebakende, constructie werken instellingen met dezelfde spelregels en doeleinden maar vanuit verschillende locaties en specialismen samen aan een product of een dienst. Het essay waarin Eric Raymond deze tegenstelling schetste, is een veelgebruikte metafoor geworden voor het verschil in denken tussen een traditioneel, hiërarchisch bedrijfsmodel, met dikke muren tussen ‘binnen’ en ‘buiten’, en anderzijds een bedrijf dat in een netwerk vrijelijk kennis deelt voor de gezamenlijke doelstelling. Zie ook: Eric Raymond, ‘The cathedral and the bazar’, http://nl.wikipedia.org/wiki/ The_Cathedral_and_the_Bazaar. Anno nu is deze tegenstelling grotendeels verdwenen. Elk bedrijf is op weg een ‘extended enterprise’ te worden. Dat stelt grote uitdagingen en nieuwe eisen aan de infrastructuur en de organisatie van datastromen. Maar het vergt vooral nieuwe vaardigheden en samenwerkingsverbanden van de mensen die in zo’n ‘extended enterprise’ met data werken. Een ‘extended enterprise’ is volgens Martin van den Berg (docent module ‘The Extended Enterprise’ van de opleiding Master of Informatics, Hogeschool Utrecht) ‘a smart business network which is:

ll linked together via one or more communication networks forming the links, ll with compatible goals, ll interacting in novel ways, ll perceived by each participant as increasing its own value, and ll sustainable over time as a network.’ In het perspectief van Linked Open Data springen er twee aspecten uit: de noodzaak om meerdere (en diverse) soorten communicatiekanalen met elkaar te verbinden, en de behoefte aan nieuwe vormen van interactie. In zo’n dynamische omgeving, waarbij de muren van een bedrijf zo dun als papier zijn geworden, is behoefte aan een levende, open en toegankelijke datastructuur waaraan gebruikers ook informatie kunnen toevoegen en dus verrijken. Een ‘linked data enterprise’ heeft de uitdaging om de diverse datastromen, die uit verschillende en soms ook wisselende bronnen komen, centraal te stellen in de organisatie. De datastroom is een levensader. De uitdaging is ervoor te zorgen dat deze aders tot in de kleinste delen van de ‘extended enterprise’ kunnen doordringen. In dit hoofdstuk gaan we verder in op de wijze van integratie van diverse soorten data en datastromen binnen een ‘extended enterprise’, en op de fundamentele inhoudelijke vraag welke doelen de data moeten dienen.

226

Daarna hebben we aandacht voor de gevolgen ervan voor de werkwijze van de mensen binnen een organisatie en hoe dit kan leiden tot meerwaarde. Tenslotte geven we ook aan welke stappen een ‘extended enterprise’ kan zetten om optimaal te kunnen kapitaliseren op de toegevoegde waarde van Open Data. Omdat er verwarring kan zijn omtrent de termen die in dit hoofdstuk staan, hierbij de definities die gehanteerd worden. Voor ‘Linked Open Data’ (LOD) hanteren we de definitie van Tim Berners-Lee, de directeur van het World Wide Web Consortium: LOD zijn gestructureerde gegevens die via URL’s over HTTP te benaderen zijn, en zelf informatie geven over hun inhoud via standaarden als RDF (http://bit.ly/FQVNV). Dit sluit aan bij de algemenere definitie van Open Data: gegevens die vrijelijk toegankelijk zijn, zonder restricties (opendefinition.org). Voorbeelden van Linked Open Dataset zijn te vinden op sites als data.gov.uk, data.overheid.nl en datahub.io. Onder ‘Enterprise Data’ verstaan we simpelweg alle gegevens, gestructureerd of ongestructureerd, die zich binnen een organisatie bevinden en niet gepubliceerd zijn. De data worden gedeeld door de medewerkers van de organisatie, maar niet daarbuiten. Voorbeelden van enterprise data zijn de gegevens in ERP en CRM

systemen, op het intranet, in databases van applicaties, op fileshares, en in e-mail. Een gezond lichaam Data als levensader heeft een fysieke component: er moet een infrastructuur zijn, de data moeten aan allerlei technische eisen voldoen om te kunnen worden gelinkt en gebruikt. Maar er is natuurlijk ook een inhoudelijk aspect. De vraag welke data nu eigenlijk van belang zijn is in deze tijden van informatie-overdaad veel lastiger te beantwoorden dan in het nog recente verleden (http://bit.ly/Bg0r). Wat stroomt er eigenlijk door die levensader? Hebben de beschikbare data wel voldoende kracht om het ‘lichaam’, de ‘extended enterprise’, gezond te laten groeien? De technische revoluties van het laatste decennium hebben het gedrag van de gebruiker fundamenteel veranderd: we gaan niet meer naar een bibliotheek om in te loggen op de database, we roepen de gewenste data op vanaf de plaats waar we op dat moment zijn. Achter het bureau, in de auto, of thuis. En we kijken verder; we gaan ook nog even het internet op, de grootste database van allemaal. Dit verandert niet alleen de manier waarop we data benaderen, het verandert ook de data zelf en de eisen die we eraan stellen. Enterprise Data kunnen door de gebruiker worden

227

aangevuld, verrijkt. Dit verandert ook de traditionele rol van de data-consument: de gebruiker wordt soms ook ‘producent’: een ‘prosumer’. Dit proces doet zich overal in de samenleving voor. Bij bedrijven, maatschappelijke organisaties, kennisinstellingen en overheden worden grote hoeveelheden data verzameld die steeds vaker beschikbaar komen voor de buitenwereld. Deze nieuwe vloedgolf van data (Big Data) is soms het gevolg van gericht overheidsbeleid (meer transparantie), vaak ook het gevolg van allianties tussen bedrijven en kennisinstellingen. Soms gebeurt het ook simpelweg ‘omdat het kan’. Dus waarom niet? Wat dit voor het bedrijfsleven betekent, laat zich raden: de ‘Open Data’ tsunami biedt veel kansen om gerichter, beter geïnformeerd en dus met meer kennis en inzicht te werken aan de eigen toekomst. Zie ook: Carlo Ratti e.a.: Open Data: Issues and opportunities for the enterprise?, An initiative by bluenove on the basis of the bluenove-BVA survey, nov 2011. ‘Eigen data eerst’ Van nature hecht een bedrijf meer waarde aan de eigen data, waarschijnlijk omdat men weet hoeveel moeite het heeft gekost om die te verzamelen en de betrouwbaarheid te borgen. Het is dan ook begrijpelijk dat een bedrijf meer waarde hecht aan de ‘eigen’ data dan aan infor-

matie van buiten. ‘Eigen data eerst!’, zo zou je deze visie kunnen vertalen. We zijn van mening dat zo’n houding in deze tijd niet meer productief is en zelfs een rem kan zijn op innovatie. De kernvraag is hoe je Enterprise Data kunt integreren en optimaal benutten zonder aan kwaliteit in te boeten. Dat is niet alleen een technische vraag, maar ook een psychologische. Het gaat immers ook om de vraag: welk gewicht de data krijgen in het proces van innovatie, en vooral als het gaat om inzichten die zijn ontleend aan ‘open’, al dan niet gestructureerde data. Toen Apple voortvarend aan de slag ging met touchscreens voor de eerste smartphones, zei directeur Steve Ballmer van concurrent Microsoft keihard ‘niet te geloven’ in de toegevoegde waarde van een touchscreen boven een fysiek toetsenbordje. Zijn visie kreeg vervolgens meer gewicht dan andere beschikbare data, vooropgesteld dat Microsoft zijn huiswerk had gedaan en een goed beeld had van de trends in consumentenproducten. Het geeft aan hoe lastig het is om ongelijksoortige data (trendonderzoek versus ‘persoonlijke mening’) het gewicht te geven dat hen toekomt. We weten hoe dit voor Microsoft en haar partners is afgelopen.

228

‘Bedrijven kunnen ruim twintig procent meer rendement boeken als ze in staat zijn om hoogkwalitatieve en heel diverse soorten van data te integreren in een samenhangende infrastructuur.‘ (Gartner, 2011)

Het organiseren van meerwaarde Met enterprise data hoeven we ons niet af te vragen wat de zin is van deze data voor de organisatie. Deze data komen immers tot stand omdat wij dat willen. Zodra de data niet meer voldoende worden benut of niet meer in staat zijn meerwaarde te bieden, kan de organisatie, als aanjager van de informatiestroom, daar iets aan doen. Bij het integreren van ‘Open Data’ in het informatiesysteem van een ‘extended enterprise’, is dat niet het geval. De Open Data zijn niet gemaakt met het directe belang van de eigen organisatie voor ogen. Bovendien is er heel erg veel van... Daarom is het ordenen, het organiseren, van deze data meer dan alleen een technisch of organisatorisch verhaal. Het vergt een helder antwoord op de vraag: wat wil ik van de data weten? Wat is werkelijk relevant voor mijn organisatie? Bij het integreren van diverse soorten data zien we iets opvallends ontstaan: de herkomst van data wordt van secundair belang. Relevant is ei-

genlijk alleen de vraag wat de stroom externe gegevens aan meerwaarde biedt (of verbergt). Die meerwaarde zit meestal niet alleen of zozeer in de intrinsieke data, in de data ‘an sich’, maar schuilt in de synthese ervan met de Enterprise Data. Pas in het samenbrengen van die verschillende data ontstaat het leeuwendeel van de meerwaarde: 1+1=3. Een gevoel van superioriteit met betrekking tot de eigen data versus de Open Data is daarom gevaarlijk – en in elk geval achterhaald. Ruimte voor ‘prosumers’ Bij het integreren van Open Data in de bedrijfsinformatie is het essentieel om niet alleen de data zelf, maar ook de gebruikers mee te nemen in dat proces. Immers: bij Open Data zijn de consumenten vaak ook de producenten. Voor het verbeteren/verrijken van de data is hun rol essentieel. Een voorbeeld van hoe je Open Data uit heel diverse bronnen integreert en hoe je deze producerende consumenten (‘prosumers’) een actieve rol kunt geven, is - met vallen en opstaan - ontwikkeld door wellicht het grootste Open Dataproject in de recente geschiedenis: Wikipedia. Deze online encyclopedie, die inmiddels meer content heeft en een even lage foutmarge als de traditionele, in een gesloten model gemaakte encyclopedieën, onderscheidt drie ‘prosumer’groepen: anonieme gebruikers (1),

229

geregistreerde gebruikers (2) en administrateurs (3). Opvallend is dat alle drie groepen content kunnen leveren, dus data kunnen verrijken – ja, ook de anonieme deelnemer. Waarbij de administrator de meeste bevoegdheden heeft (en bijvoorbeeld content weghalen). Deze dynamiek werkt dankzij een systeem van openlijke reviewing en een publiek debat over de content. De relatieve laagdrempeligheid voor het ‘prosumeren’ van informatie heeft dus een glasheldere keerzijde: het systeem van ‘reviewing’ is stevig neergezet en uitermate transparant. En met een echte ‘eindbaas’: de administrateur. Zie ook: The Role of Community-Driven Data Curation for Enterprises: Linking Enterprise Data, hoofdstuk 5, Edward Curry, Andre Freitas, and Sean O’Riain. Digital Enterprise Research Institute, National University of Ireland, Galway, Ireland. ‘Er wordt getwijfeld aan de juistheid van dit artikel...’ De ‘extended enterprise’ gaat allerlei allianties en samenwerkingen aan, in diverse gradaties van intensiteit en belang. In al die relaties gaan datastromen heen en weer. In een innovatieve omgeving kunnen de Enterprise Data een vruchtbare mix vormen met de Open Data die vanuit diverse hoeken en in diverse formats beschikbaar zijn. De vraag hoe je dit het beste kunt aansturen, is voor elke instelling anders te beantwoorden, maar in de basis is dus veel te leren van het

Wikipediamodel: zet de bevoegdheid tot dataverrijking en amenderen zo laag mogelijk in de organisatie en wijs een aantal administrateurs aan die knopen doorhakken en een oog je in het zeil houden. Er zijn allerlei gradaties van overleg met contribuanten, en bijbehorende procedures. Van alle informatie die nog niet voldoet aan de zelf opgelegde standaard, meldt dit massieve online project ook netjes: ‘overleg gewenst’ of, in het ergste geval: ‘Er wordt getwijfeld aan de juistheid van een of meer onderdelen van dit artikel’. In een bedrijfsomgeving is de identiteit van alle data-gebruikers bekend: wie wat bijdraagt kan door zijn collega’s of door de administrateurs worden bijgestaan/gecorrigeerd of gesteund. En misschien is anonimiteit van dataverrijkers, ook bínnen een bedrijf aan te bevelen. Hoe anders krijg je een slimme nieuwkomer binnen een hiërarchische organisatie zover om vraagtekens te zetten bij de data en deze te verbeteren? Deze vorm van data-management en integratie resulteert bovendien in een ‘agile’-aanpak: al doende bouw je voort aan een datasysteem dat zowel open als gesloten data bevat, je ziet snel genoeg waar de gaten zitten, en waar nog nieuwe inbreng gewenst is. Dat is zowel transparant als een prikkel voor vernieuwing. Deze innovatieve dimensie van de LOD-LED synthese is overigens ook goed te organiseren, bijvoorbeeld door middel

230

van kleine incentives voor de beste en ijverigste data-verbeteraars in huis. Het geeft bovendien een ander belangrijk signaal af naar de organisatie als geheel: ‘We werken met wat we weten. Morgen willen we meer weten dan vandaag’. De vermenging van LOD en LED zal bovendien leiden tot nieuwe en betere data. Het toepassen van allerlei soorten data en het terugploegen van de verrijkte data in de publieke ruimte geeft groei. ‘Joining and sharing’ zijn sleutelbegrippen geworden als het gaat om deze trend. Zie ook: ‘Joining and sharing’ als een kernbegrip van deze tijd. Uitspraak van Neelie Kroes, Europees Commissaris belast met de portefeuille Digitale Agenda, tijdens de Europadag van de ECP in Zeist, op 7 mei 2013. Vervagende datagrenzen Het is bepaald geen sinecure om hiervoor de juiste infrastructuur op te bouwen. De uitdagingen die hiermee samenhangen, worden elders in deze publicatie en in het LED-vakgebied al uitgebreid geanalyseerd. Daarover verderop meer. Het doel van de instrumenten verdient hier nog enige aandacht. Vanouds zijn datasystemen erop gericht om zoveel mogelijk data te linken en inzichtelijk te maken voor gebruikers. In de toekomst zullen de tools en de infrastructuur er vooral op gericht moeten zijn om het nuttige te scheiden van het nutteloze.

We denken dat binnen afzienbare tijd het onderscheid tussen Enterprise Data en Open Data een puur technische zal zijn. Waarbij zal blijken dat Open Data, eenmaal gelinkt, soms beter en betrouwbaarder is en dus meer waarde toevoegt, dan de ‘eigen’, vaak duur betaalde en gekoesterde bedrijfsdata. Open Data die door overheden zijn verzameld met het oog op het publiek belang, of die zijn te filteren uit natuurlijk gedrag van consumenten en burgers, bieden nu al inzichten die waardevol zijn voor hele bedrijfstakken. Google is, als zoekmachine, ‘s werelds grootste verzamelaar en analist van publieke data geworden. De ‘wisdom of the crowd’ kennen we natuurlijk al, zoals in het al genoemde Wikipedia. Maar inmiddels is Google Trends een nauwkeuriger voorspeller van, bijvoorbeeld, een griepgolf dan de gezondheidsinstellingen van de diverse overheden en van de verzamelde farmaceutische industrie. Terwijl die laatste er toch ettelijke miljarden per jaar aan verdienen. En bedenk dat Google nog geen vijftien jaar oud is. Deze trend is nog maar net begonnen. Er bestaan straks nog slechts twee categorieën data: nuttige data en nutteloze data. Waarbij de vraag „wat is nuttig?’ in een ‘extended enterprise’ lastiger is te beantwoorden dan menigeen misschien denkt.

231

De belofte van inzicht: ‘...asking the right questions...’ De kernvraag die we eerder stelden is: welke data kunnen mijn organisatie toegevoegde waarde bieden? Daar vloeien twee vervolgvragen uit voort: waar zitten die data dan? En: hoe kom ik er aan als ik ze nog niet heb? Bij discussies over Open Data en datamanagement gaat het vaak over (het verbeteren van) beheersstructuren en systemen. Begrijpelijk: binnen een bedrijf zijn de kwalitatieve data verspreid over tientallen, honderden of duizenden locaties: van diverse databases tot de individuele desktops en email accounts. Feitelijk weet geen enkel bedrijf precies welke kennis het nu al in huis heeft, laat staan waar die kennis zit. Het aanboren van additionele kennis in grote hoeveelheden Open Data is daarom geen sinecure. Data is, op zichzelf, gewoon data. Data wordt pas ‘informatie’ als het vindbaar en toegankelijk is, en liefst ook nog gekoppeld. Informatie kan tot kennis leiden zodra de informatie op het juiste moment op de juiste manier op de juiste plaats aanwezig is, gevraagd of ongevraagd. Maar pas als de betrokken ‘prosumer’ de juiste achtergrond heeft en de juiste mindset, kan deze kennis leiden tot inzichten. Pas dan – en niet eerder – lossen de data hun belofte in en geven ze hun toegevoegde waarde prijs. Vergelijk het met olie: pas als er een stevige infrastructuur is kan de

olie worden gewonnen en verwerkt, pas na raffinage wordt de olie tot brandstof. Maar pas als het ook nog in de tank terecht komt, is de belofte ingelost. Welke vragen stellen we aan de data? Welk probleem moeten de LOD en LED voor ons oplossen? Daarbij gaat het natuurlijk in de meeste gevallen om het verbeteren of versnellen van allerlei praktische processen binnen de organisatie of in een samenwerking met anderen. We formuleren een vraag of een claim en richten ons op de data voor antwoorden. We zijn van mening dat een goede synthese van LOD met LED tot iets kan leiden dat verder gaat dan de gebaande paden: je vindt nieuwe trends, inzichten die je niet had gezocht maar die zich aandienen door deze synthese van data uit diverse bronnen. Het helpt dan, dat de Open Data in de regel niet werden verzameld met een vooropgezette vraag uit het bedrijf, maar juist vanuit een heel andere vraag uit een andere sector. Neem bijvoorbeeld de gegevens van het Centraal Plan Bureau (CPB) of het CBS met betrekking tot sportief gedrag en beweging. Die zijn niet verzameld om vragen van bijvoorbeeld Nike of de Bond voor Gehandicaptensport te beantwoorden, maar om de politieke bestuurders een beeld te geven van de gezondheid van verschillende bevolkingsgroepen. Op basis hiervan

232

kunnen gemeenten beslissen of er een sporthal of een voetbalveld moet bijkomen, of dat er beter wat meer geld gestopt kan worden in fitness in buurthuizen voor allochtone vrouwen. Toch kunnen deze data veel vertellen aan de Nike’s en de sportbonden van deze wereld. De samensmelting van Open Data en Enterprise Data kan een bedrijf op het spoor zetten van nieuwe trends waarmee de concurrentie op achterstand komt te staan. Een bedrijf in sportartikelen kan producten gaan ontwikkelen voor een nieuwe markt van oudere ‚bewegers’, bijvoorbeeld. Een markt die nu nog nauwelijks zichtbaar is, maar die er volgens de Open Data van overheden snel aankomt. Met technologische snufjes die ook laagopgeleiden of allochtone ouderen kunnen snappen. Of met voorzieningen die ook voor bejaarden goed toegankelijk zijn. Wat weten we? De synthese van Open Data en Enterprise Data is vooral interessant voor bedrijven die innovatief naar hun producten en diensten willen kijken. Wie naar trends zoekt, kan naar Open Data kijken en daarin ‚zwakke signalen’ opsporen. De grote hoeveelheden al dan niet gestructureerde data waarover bedrijven kunnen beschikken, dwingen tot de hier al eerder geformuleerde kernvraag: ‘wat wil ik weten?’ Dit lijkt een simpele vraag. Maar eigenlijk raken we hier aan de

essentie van de hele discussie over nut en toepassing van data. Welke kennis is al aanwezig? Wat ontbreekt nog om tot een goed oordeel of besluit te komen? Waar halen we die ontbrekende kennis vandaan? Zonder te verzanden in filosofische verhandelingen willen we hier de vraag naar de behoefte aan kennis even aanstippen, omdat dit naar onze mening van wezenlijk belang is bij het maximaal benutten van de toegevoegde waarde van Open Data. Er zijn diverse soorten van kennis. Opvallend genoeg was het de Amerikaanse minister van Defensie Donald Rumsfeld die dit paradigma beroemd maakte. Hij gebruikte het om de beslissingen rondom het aanvallen van Saddam Hoesseins Irak te legitimeren - maar dit terzijde (http://bit.ly/ hUQDLF). Rumsfeld maakte onderscheid in drie soorten kennis: 1. Er zijn dingen waarvan je niet weet dat je ze weet. 2. De eerste van deze vier paradigma’s hebben we zelf toegevoegd, om de logica van Rumsfeld in zijn consequentie door te trekken naar een relevant element, namelijk het zicht op bestaande data. Binnen een onderdeel van het bedrijf is kennis aanwezig die onbekend is bij de rest van de organisatie. Bijvoorbeeld omdat die kennis op een spreadsheet staat van een

233

3. 4.

5. 6.

7. 8.

paar individuele collega’s of binnen de database die zo slecht is ‘getagt’ dat niemand het kan vinden. Er zijn dingen waarvan je weet dat je ze weet. Dit bestrijkt het hele veld van aanwezige ‚linked data’. Dit is wat we formeel weten. De meeste debatten over linked data beperken zich tot de twee bovenstaande categorieën. Er zijn dingen waarvan je weet dat je ze niet weet. Dit is het uitzicht dat we kunnen hebben op onze omgeving – mits we goed kijken. We kunnen trends zien waar we meer van willen of moeten weten, met het oog op verbetering van bestaande of het bedenken van nieuwe diensten of producten. Opleidingen en afdelingen R&D zijn veelal hierop gericht. Om dit potentieel aan te boren is veel creatieve capaciteit nodig. Uiteindelijk zullen de inspanningen in dit deel van het traject leiden tot het vermogen om ‘de juiste vragen te stellen’ aan de data. Dit is een essentiële vaardigheid. Er zijn dingen waarvan je niet weet dat je ze niet weet. Onwetendheid over wat er allemaal bestaat buiten onze eigen professionele leefwereld is iets wat iedereen zal herkennen en waar niemand aan ontsnapt. In dit ‘veld’, het grootste van alle vier geschetste terreinen, zitten de data waar we niet specifiek naar

zochten, maar die ons niettemin op nieuwe ideeën en inzichten kunnen brengen. De vloedgolf aan Open Data, al dan niet gestructureerd, brengen deze categorieën 3 en 4 van ‘kennis’ binnen handbereik. Het ‚niet-weten’ kan een belangrijke drijfveer zijn voor innovatie. Het openstaan voor nieuwe dingen waar we helemaal niet naar op zoek waren, maar die de organisatie verder kunnen helpen, klinkt voor sommigen misschien in de oren als luchtfietserij, fantasie of dagdromerij. Dit aspect van innovatie is echter niet afhankelijk van de creatieve ingeving van een enkeling, maar kan wel degelijk worden georganiseerd en gestructureerd. Vaak ontstaat het uit de synthese van twee ogenschijnlijk erg verschillende kennisvelden: bijvoorbeeld statistiek en sport (zoals in ‘Moneyball’, film: http://en.wikipedia.org/wiki/ Moneyball_(film)) en design versus techniek (Apple). Kunstenaars, maar ook mensen als Steve Jobs hebben een talent om dergelijke verbindingen te leggen. Op zoek naar ‘zwakke signalen’

Op organisatieniveau is op dit vlak nog een wereld te winnen. Juist de informatie in Open Data kan hier een sleutelrol in spelen, omdat deze met andere bedoelingen zijn verzameld dan waarvoor uw organisatie ze wil bestuderen. Het ontdekken van

234

dingen waar we niet naar op zoek waren - omdat we het bestaan niet hadden vermoed - is een belangrijke dynamiek waarvoor elke organisatie eigen antennes zou dienen te ontwikkelen. Die antennes kunnen ‘zwakke signalen’ opvangen, en in een ‘early warning system’ data uit diverse bronnen combineren tot een scenario voor de innovatie van producten of diensten. Diverse succesvolle bedrijven doen dit al: vaak in stilte, soms in het publieke domein. Een bedrijf als Shell heeft dit tot een van de belangrijkste hoekstenen van beleid gemaakt (http:// bit.ly/17gB79y). Met zeer gedegen scenario’s schetst de oliemaatschappij de megatrends van de toekomst, in meerdere variaties. Ze liggen aan de basis van nader onderzoek, en van strategisch beleid voor de langere termijn. Dankzij deze scenario’s was Shell goed voorbereid toen begin jaren zeventig plotseling de oliecrisis losbarstte. Dat werd namelijk al eens uitgewerkt in een van hun toekomstscenario’s. De scenario’s zijn opgebouwd uit een mix van Open en Enterprise Data, waarbij context en kruisbestuiving zorgen voor een 1+1=3. De scenario’s van Shell belanden anno nu op de directiebureaus van bedrijven en overheden in de hele wereld. Ze zijn een perfect voorbeeld van waar de synthese van Open Data en Enterprise Data toe kan leiden.

De ‘extended enterprise’ in de praktijk Waar gaat het nu echt om? In bovenstaande paragrafen komen een aantal thema’s en uitdagingen terug: ll Organisaties en systemen zijn ‘loosely coupled’; ll Interoperabiliteit speelt een belangrijke rol; ll Meerdere organisaties streven een gemeenschappelijk doel na. Om een ‘extended enterprise’ te vormen is het dus noodzakelijk om samen te werken. De manier van samenwerking kan verschillen. We hebben hier twee opties geselecteerd die een antwoord geven op de uitdagingen van de marsroute naar een ‘extended enterprise’ en de synthese van de diverse soorten Open en Enterrpise Data in een werkbaar systeem dat de koppeling van LOD en LED meerwaarde geeft: supply chain management en chain computerization. Deze opties zijn in de praktijk getoetst maar hebben ook een sterke wetenschappelijke verantwoording. Supply Chain Management Een goede optie is om een samenwerkingsverband tussen organisaties af te sluiten dat gebaseerd is op supply chain management (SCM, http://bit.ly/v4m6W). Dit is een manier die sinds de tachtiger jaren gebruikt wordt om te benadrukken dat bedrijfsprocessen binnen en tussen organisaties op elkaar afgestemd moeten worden. Het gaat hierbij om

235

de stroom van goederen, geld en diensten. De betrokken bedrijfsprocessen zijn onder andere logistiek, capaciteitsmanagement en werkverdeling. Een supply chain is een complex en dynamisch netwerk van vraag en aanbod (http://en.wikipedia.org/ wiki/Supply_chain). In zo’n netwerk is goede governance (bestuur) in de vorm van SCM noodzakelijk. Sinds de introductie van het internet en de toename in IT-services is SCM belangrijker geworden dan ooit tevoren. Chain-computerization Een andere insteek voor het invoeren van een ‘extended enterprise’ is chain-computerization. Dit is een relatief jong concept, geïntroduceerd door Jan Grijpink (http:// bit.ly/10qRTzL). Bij chain-computerization (of keteninformatisering) geldt dat er een ‘dominant ketenprobleem’ is dat moet worden opgelost (http://bit.ly/12EkvFZ). Een keten van organisaties bedenkt op ‘ketenniveau’ oplossingen voor het ketenprobleem. Hierbij is geen enkele instantie leidend of dominant aanwezig; het ketenprobleem in zichzelf is de drijvende kracht achter de keteninformatisering. De belangen van de individuele betrokken organisaties zijn in principe nevengeschikt aan het probleem. Voorbeelden van zulke ketens zijn de medicatieketen (keten-

probleem: er kan gezondheidsschade optreden door het onjuist toedienen van geneesmiddelen) en de voetbalvandalisme bestrijdingsketen (ketenprobleem: vandalisme en geweld gerelateerd aan voetbalwedstrijden). Architectuur en technologie Bij al deze vormen van samenwerking is technologie belangrijk. Een ‘extended enterprise’ bevat een IT-speelveld, waarin zaken als architectuurprincipes een belangrijke rol gaan spelen. Het denken in services volgens de SOA-gedachten en principes (http://bit.ly/ZKCR0v) is een goed startpunt om interoperabiliteit en digitale samenwerking te realiseren. Linked Open Data is natuurlijk een belangrijk onderdeel van deze aanpak; welke data worden gedeeld, met welke beveiliging? We zijn het tijdperk voorbij van Excel-bestanden aan elkaar doormailen; een organisatie die zich profileert als een onderdeel van een ‘extended enterprise’ kan hier niet meer mee wegkomen. Er zal dus serieus werk gemaakt moeten worden van (REST) web services, SaaSintegratie en open standaarden zoals SAML, EDI, EbXML en UDEF. In plaats van applicaties direct aan elkaar te koppelen, is het mogelijk om als middleware laag een integratieservice in te schakelen. In feite functioneert zo’n service als een Enterprise Service Bus (ESB): een technisch doorgeefluik voor berichten

236

met inhoud, die verantwoordelijk is voor zaken als autorisatie, authenticatie, orkestratie en logging. Een ESB is een belangrijk onderdeel van een service-oriented architecture (SOA). Een dergelijke architectuur biedt veel voordelen op het gebied van interoperabiliteit en standaardisatie, doordat applicaties als services gezien worden die via een generiek protocol met elkaar communiceren (bijvoorbeeld SOAP web services over http). Alle populaire ESB-producten, bijvoorbeeld Microsoft BizTalk en Tibco, kunnen ingezet worden in een Linked Open Data architectuur van een ‘extended enterprise’. Open Data volwassenheid De ‘volwassenheid’ van een organisatie op het gebied van Linked Open Data is lastig te bepalen. In 2013 hebben John van Echtel (CGI) en de auteurs van dit artikel een maturity model ontwikkeld in samenwerking met Hogeschool Utrecht en het Nederlands Architectuur Forum (NAF), op basis van bestaande modellen van onder andere Luftman, CMM, Gartner, Sacu en IDC. Het model bestaat uit een conceptueel raamwerk waarin de mate van volwassenheid van een organisatie kan worden bepaald op zes dimensies: Business model, Open Data consumptie, Open Data publicatie, Enterprise Data, Architectuur & technologie en Ontwikkel & beheerprocessen. Op elke dimensie wordt een score van 1 t/m 5 toegekend. Dit

model is onderdeel van de workshop ‘Open Data Value’. Deze aanpak heeft zich in de praktijk bewezen bij enkele organisaties, die daarmee hun positie in de ‘extended enterprise’ bepalen en een strategie ontwikkelen voor het gebruik (consumptie en publicatie) van Linked Open Data. De scan en de workshop waarin diverse ‘meedenkers’ uit andere disciplines aanschuiven, vormen samen zowel een technische tool als een psychologisch mechanisme om het denkproces hierover op gang te brengen en tegelijk een ‘foto’ te maken van de stand van zaken binnen een organisatie. De werkwijze wordt uitgelegd op http://www.utrechtopendata.org/ workshops.

Samenvatting Wat is een organisatie? Waar liggen de grenzen? Welk bedrijf of instelling staat nog op zich? Een organisatie is tegenwoordig een ‘beschouwingsniveau’, een relatief concept dat in feite zegt: alles is als een zelfstandige organisatie te kenmerken, onafhankelijk van de grootte. Op microniveau is een ‘extended enterprise’ een afdeling, een team, of een individu. Op macroniveau is een ‘extended enterprise’ een bedrijf, een multinational, of een conglomeraat. Elk van deze entiteiten kan niet functioneren zonder zijn omgeving, en die omgeving definieert wát de ‘extended enterprise’ inhoudt. We leven in een wereld van virtuele organisaties en smart

237

business networks. Een bouwproject is een gezamenlijke onderneming van bedrijven: infrastructuur, wegen waterbouw, ingenieurs, lokale overheden. De implementatie van een nieuw ERP-pakket is een ‘extended enterprise’ van de interne IT-afdeling, meerdere leveranciers, onderaannemers, ZZP’ers en toezichthouders. Een onderzoeksorganisatie doet onderzoek naar cultuur en sportbeoefening in Nederland, en werkt daarvoor samen met sportbonden, overheden en vrijwilligers. Zelfs de ‘bakker op de hoek’ is een onderdeel van de ‘extended enterprise’, namelijk de supply chain van boer tot consument. Met het explosief groeien van de hoeveelheid Linked Open Data (LOD) worden bedrijven, overheden en kennisinstellingen uitgedaagd tot het ontwikkelen van nieuwe en krachtige instrumenten om zicht te krijgen op deze reusachtige bron van nieuwe kennis. Daarbij gaat het om het vinden van toegevoegde waarde in Open Data, maar tevens om het realiseren van verrassende koppelingen van open en gesloten datasets. Een derde element dat kwaliteit toevoegt aan data, is het gebruik ervan zelf: het toepassen en toevoegen van LOD resulteert, mits goed gestructureerd en geborgd in de organisatie, in ‘verrijking’ door de gebruikers.

Tegelijkertijd is een tweede grote trend zichtbaar: de opkomst van de ‘extended enterprise’. In een ‘extended enterprise’ komt informatie niet meer alleen van interne, en gescreende bronnen, maar ook van ‘buiten’. Deze externe informatiebronnen kunnen zowel professionele partners zijn als tijdelijke of incidentele allianties met partijen die over informatie beschikken (andere bedrijven, overheden, kennisinstellingen) of die deze data zelf genereren (de individuele burger). Deze externe informatiestroom kan zowel big data, small data, en gestructureerde of ongestructureerde data zijn. Deze bronnen van kennis bestaan nu nog goeddeels los van elkaar, waarbij van nature meer waarde wordt toegekend aan de ‘eigen’ Enterprise Data dan aan informatie van buiten. ‘Eigen data eerst’, zo zou je deze visie kunnen vertalen. In een innovatieve, professionele omgeving is dit onderscheid achterhaald. LOD en ‘Enterprise Data’ komen samen in een vruchtbare mix waarbij de toegevoegde waarde meer is dan de som der delen. ‘Joining and sharing’ zijn de nieuwe sleutelbegrippen zodra het gaat om data. Een bedrijf dat op zoek is naar meer kennis en inzicht over klanten, producten en nieuwe markten, zal hier een competitief voordeel kunnen behalen. Centraal hierbij staat het vermogen van de organisatie om data goed te beoordelen, te linken en te verrijken.

238

Dat houdt in dat de organisatie geen volledige controle heeft over belangrijke onderdelen van de ‘extended enterprise’. Het is nu eenmaal niet altijd mogelijk eisen te stellen aan leveranciers of afnemers. Dat betekent dat selectie van de diensten en afstemming over integratie erg belangrijk wordt, naast de technische uitdagingen. Deze selectie moet gedaan worden op basis van criteria op gebied van beveiliging en interoperabiliteit. Als bijvoorbeeld communicatie op basis van open standaarden een must is, wordt dat een criterium voor het selecteren van partners en technologie. Als ontwikkelaars een open API nodig hebben om een extern systeem te kunnen benaderen, is dat ook een criterium. Als er eenmaal partners gekozen zijn en diensten worden aangeboden en afgenomen, moeten de leveranciers worden aangestuurd en de contracten worden beheerd. Om Linked Open Data op enterpriseniveau toe te passen en dus een succesvolle ‘extended enterprise’ te vormen, moeten beslissingen op strategisch, tactisch en operationeel niveau worden genomen:

ll Strategisch Op boardroom-niveau moeten bestaande governance modellen aangepast worden. Directieleden en managers moeten zich ervan bewust worden dat hun organisatie onderdeel is van een groter geheel; ‘eiland-denken’ is uit den boze. Het governancemodel dient daarin te voorzien door middel van de juiste standaarden, processen en rollen. ll Tactisch Het implementeren van een ‘extended enterprise’ met Linked Open Data biedt uitdagingen op gebied van architectuur, beveiliging, processen en menselijke zaken (bijvoorbeeld rollen en verantwoordelijkheden). Gemeenschappelijke afspraken (met leveranciers, tussen gebruikers) dienen te worden vastgelegd, uitgevoerd en gecontroleerd. ll Operationeel Ten slotte zijn er enkele technische (operationele) uitdagingen om ‘extended enterprises’ goed te laten werken. Interne software moet geïntegreerd worden met externe applicaties en services. Beveiliging en integratie is lastig doordat de leverancier ‘buiten de deur’ zit. Gelukkig vordert de IT-technologie razendsnel en zijn cloud, SaaS, SOA en Open Data gemeengoed geworden.

239

Conclusies 1. In de ‘extended enterprise’ vormt de enorme stroom data het kloppende hart van de onderneming. De tegenstelling tussen een bedrijf als Kathedraal of een bedrijf als Bazaar is ingehaald door de tijd. Zelfs een bedrijf dat als Kathedraal functioneert, zal in de talloze allianties met partijen buiten de muren, het karakter moeten kunnen aannemen van een Bazaar. In de Bazaar is het welslagen van de doelstelling volledig afhankelijk geworden van een geslaagde synthese van Linked Enterprise Data en Linked Open Data. Commerciële bedrijven en overheidsinstellingen hebben geen bestaansrecht zonder goede verbindingen naar buiten. Bovendien hoort het bij de hedendaagse cultuur: we zijn Open en transparant, werken samen op alle vlakken en vinden de technische stand van zaken de normaalste zaak van de wereld. We leven in een wereld van ‘extended enterprises’. Linked Open Data is daar een onlosmakelijk en, in sterk toenemende mate, onmisbaar onderdeel van voor elke organisatie die op zoek is naar toegevoegde waard en een competitief voordeel.

2. Bij de integratie van Open Data met Enterprise Data komen twee aspecten naar voren: de noodzaak om meerdere (en diverse) soorten van communicatiekanalen met elkaar te verbinden, en de behoefte aan nieuwe vormen van interactie. 3. De meerwaarde van Open Data voor een ‘extended enterprise’ is vaak niet op voorhand duidelijk, omdat deze data zijn niet geproduceerd met het belang van de eigen organisatie voor ogen. Daarom is het integreren van Open Data meer dan alleen en technische of organisatorische kwestie, maar ook een psychologische en intellectuele uitdaging. Het raakt aan de kernvraag: wat willen we eigenlijk weten? Welke kennis is relevant voor mijn organisatie? 4. Om Linked Open Data succesvol op enterprise niveau toe te passen, zijn beslissingen nodig op strategisch, tactisch en operationeel niveau. Strategisch moeten bestaande governance modellen aangepast worden. Op tactisch vlak is behoefte aan een heldere architectuur en afspraken. Operationeel ligt de uitdaging vooral in het benutten van de nieuwste ITmogelijkheden van transparante cloud-applicaties.

D1 - Aanzet tot een nationale URI-Strategie voor Linked Data van de Nederlandse overheid Auteurs

Hans Overbeek (KOOP) Linda van den Brink (Geonovum) Dit artikel is geschreven naar aanleiding van de Linked Data Pilot van Geonovum in 2012 en 2013. Het verwoordt de inzichten die de ‘Werkgroep URI-strategie’ binnen de actielijn techniek heeft opgedaan. De werkgroep is ingesteld om te onderzoeken of een nationale URI-strategie voor Linked Data van de overheid zinvol is en zo ja, wat de ingrediënten voor zo’n strategie zouden moeten zijn. De leden van de werkgroep concluderen dat een URI-strategie, of beter een Linked Data strategie, zinvol is omdat Linked Data een nieuw vakgebied is, de nodige complexiteit kent en domein-overstijgende vraagstukken behelst. Technische, maar ook organisatorische. Dit artikel gaat met name in op de technische aspecten van de identificatie van data door middel van URIs. Dit is nog geen URIStrategie, alleen een inventarisatie van de issues en enkele aanbevelingen. En tenslotte: deze versie van dit artikel zal op papier worden afgedrukt in het boek dat op de slotbijeenkomst zal worden gepresenteerd, maar bij het opstellen van deze versie zijn er nog enkele werkgroepsessies gepland. De elektronische versie zal

naar aanleiding daarvan mogelijk meer bevindingen bevatten. Ook zal de elektronische versie in het Engels vertaald worden, zodat we er ook internationaal feedback op kunnen vragen.

Achtergrond Over de toegevoegde waarde van Open Data voor de overheid en de BV Nederland is al veel gezegd. De belangrijkste baten hiervan zijn efficiëntere bedrijfsvoering door de overheid (kostenreductie en sneller handelen); betrouwbaarheid en transparantie van de overheid (duidelijkheid en verantwoording), en economische waarde van data. In de praktijk blijft de opbrengst echter vaak achter bij de beloften of verwachtingen. Veelgehoorde klachten zijn dat de data slecht vindbaar is en niet gemakkelijk in samenhang kan worden gebracht met andere data. Deze problemen worden bestreden door data van anderen te kopiëren, met hoge kosten voor verzamelen, converteren en synchroniseren, of door het bouwen van dure landelijke voorzieningen. Het resultaat is een veelheid aan kopieën en veel twijfel over authenticiteit van gegevens. Een betere oplossing is om de authentieke data duurzaam beschikbaar te maken zodat iedereen deze kan gebruiken. Daarvoor is het nodig dat de data voorzien wordt van betrouw-

241

bare identificatie, zodat je er naar kunt verwijzen en ook de verwijzingen van iemand anders begrijpt. Deze directe verwijzingen naar authentieke gegevens zorgen voor meer samenhang en betere vindbaarheid en maakt kopiëren en synchroniseren overbodig. De Basisregistraties zijn al opgezet om als authentieke bron te dienen voor referentie-gegevens. Wat ontbreekt is een goede strategie om deze bronnen ook voor de machine leesbaar te ontsluiten. Er is behoefte aan een soort klittenband waarmee datasets moeiteloos aan elkaar kunnen worden geplakt. Het doel van de Linked Open Data Pilot [1] van Geonovum was vooral om te onderzoeken wat er nodig is om van ‘Open Data’ bruikbare ‘Linked Data’ te maken. In de pilot is de behoefte geconstateerd aan een Linked Data strategie voor overheidsinformatie, te beginnen met de basisregistraties. Een aanzet voor zo’n strategie is gemaakt in de pilotwerkgroep ‘URI-strategie’. URI staat voor ‘Uniform Resource Identifier, een standaard voor identificatie van objecten en concepten (‘alles is een resource’) van het W3C’. Centraal in deze strategie staan de basisregistraties en andere authentieke bron-

nen voor referentiegegevens, zoals de collecties voor weten regelgeving en andere officiële overheidsinformatie op overheid.nl. Identificaties van authentieke referentiegegevens vormen namelijk de ‘links’ waar Linked Data mee gemaakt wordt. Laten we dit illustreren met een voorbeeld: ll Stel dat een uitvoeringsorganisatie een beleidsregel opstelt voor het uitvoeren van beleid. Deze beleidsregels hebben een wettelijke grondslag waarvoor de uitvoeringsorganisatie verwijst naar het betreffende lid in een artikel van de wet. De beleidsregel wordt gepubliceerd op hun website. ll Een rechter doet een uitspraak in een rechtszaak en baseert die uitspraak op datzelfde artikel. De uitspraak wordt gepubliceerd op rechtspraak.nl. ll Een rechtsgeleerde schrijft een commentaar op deze uitspraak en verwijst naar hetzelfde wetsartikel. Haar commentaar wordt gepubliceerd in een juridisch tijdschrift. ll Tenslotte wordt het wetsartikel besproken in de Tweede Kamer en de handelingen worden gepubliceerd op de parlementaire website.

Door nu de verwijzing naar het wetsartikel te standaardiseren kunnen de collecties van beleidsregels, uitspraken, commentaren en kamerstukken eenvoudig aan elkaar gelinkt worden. We kunnen nu bij elk van deze informatieobjecten eenvoudig een aantal gerelateerde documenten uit andere collecties aanreiken.

Het voorbeeld laat zien dat identificatie van de objecten essentieel is om de links tussen de informatieobjecten (de URIs) te kunnen leggen. Het zijn de haakjes en oog jes waarmee het klittenband tussen de informatiecollecties is gemaakt. Er is een andere vergelijking te maken, met de IBAN-nummers in de financi-

ële wereld. Na jaren van problemen in het internationale en interbancaire geldverkeer, voeren financiële instellingen nu eindelijk een standaard door voor identificatie van bankrekeningen. Dit is een langdurige en kostbare operatie. Voor databanken dreigen vergelijkbare problemen: er worden op tal van plaatsen koppelingen gemaakt tussen data-collecties en iedere koppeling wordt opnieuw bedacht. We kunnen nu echter tijdig een strategie ontwikkelen om de objecten uit onze authentieke databanken (registers) een standaard ‘bankrekeningnummer’ te geven, zodat we problemen in een vroeg stadium kunnen oplossen, of zelfs voor zijn, en later kostbare herstructurering voorkomen. Een heldere strategie, in samenspraak met de stakeholders opgesteld, moet ervoor zorgen dat partijen die met Linked Data aan de slag willen verantwoorde keuzes kunnen maken die nodig zijn om Linked Data-oplossingen te maken. Op de URI-strategie, gericht op de technische implementatie van de identificatie van authentieke data, moet een bredere Linked Data Strategie volgen waarin ook organisatorische aspecten worden meegenomen. Een goede strategie heeft toegevoegde waarde voor meerdere al lopende trajecten. ll Stelselcatalogus 2.0 stapt af van het idee van 1 overkoepelend

243

model voor alle basisregistraties en kiest voor het in kaart brengen van de – onvermijdelijke – verschillen die er zijn tussen de modellen van de respectievelijke basisregistraties. Linked Data blijkt hier veel geschikter voor dan traditionele methoden voor datamodellering. ll OWMS, de metadatastandaard voor overheidsinformatie op het web ondersteunt zowel tekstwaarden (labels, bijvoorbeeld creator=‘Utrecht’), als het gebruik van identifiers (pointers naar meer informatie, bijvoorbeeld creator=http://standaarden. overheid.nl/owms/terms/ Utrecht_(gemeente)). Het gebruik van identifiers levert veel nauwkeuriger verwijzingen op en biedt meer mogelijkheden dan labels. ll Datacollecties die (op data.overheid.nl) als Linked Data worden gepubliceerd, kunnen worden gelinkt met andere datasets en daardoor vaker en beter gebruikt dan datasets waar niet naar kan worden gelinkt. Die laatste moeten worden gekopieerd om te kunnen hergebruiken. ll In het Linked Data Overheid (LiDO) traject bij KOOP wordt weten regelgeving als bindmiddel voor Linked Data gebruikt. Hiermee wordt de samenhang en vindbaarheid van overheidsinformatie vergroot, wat contentintegratie eenvoudiger maakt.

De URI-strategie Belangrijke kennisbronnen die we gebruikt hebben bij de start van deze aanzet tot een nationale URI-strategie zijn: ll De Inspire richtlijn die een nationale strategie voorschrijft voor URIs voor geo-informatie met de aanbeveling om deze geostrategie te verbinden met een generieke nationale strategie ll Designing URI sets for the UK Public Sector. Een aanbeveling van de Britse overheid die voorlopers zijn op het gebied van het publiceren van Linked Open Overheids-Data ll 10 Rules for persistent URIs. Een veelomvattend rapport van de EU met vergelijkbare initiatieven en een waarvol overzicht van de laatste best-practices. Hieruit blijkt al hoe belangrijk het is om Europese en andere internationale ontwikkelingen te volgen [3]. Door deel te nemen in Europese en internationale programma’s krijgen we toegang tot internationale kennis en expertise, blijven we op de hoogte van de laatste inzichten en toekomstige ontwikkelingen en kunnen we zelfs invloed uitoefenen op ontwikkeling van standaarden zodat deze zich ontwikkelen in lijn met de Nederlandse behoefte. De Europese ECLI-standaard voor jurisprudentie is gestoeld op het Nederlandse LJN door inbreng van de Raad voor de Rechtspraak. Hierdoor

244

kan de ECLI zonder noemenswaardige inspanning in NL worden geïmplementeerd [4]. De werkgroep URI-strategie heeft geprobeerd om de kennis uit bovenstaande documenten te vertalen naar een strategie voor de Nederlandse situatie. We kwamen in de pilot op sommige punten tot andere inzichten die deels ook bevestigd werden door de ervaringen die inmiddels in de UK zijn opgedaan.

Scope Niet elke Linked Data applicatie is hetzelfde. We onderscheiden drie categorieën informatiebronnen: 1. Standaarden 2. Authentieke registraties 3. ‘gewone’ Applicaties

Elk met de nadruk op een van drie categorieën concepten: 1. Begrippen in conceptueel Model 2. Referentieobjecten 3. ‘gewone’ Data De grootte van een cel in het diagram geeft een indicatie van het gewicht van de categorie concepten in die categorie van informatiebronnen. De belangrijkste functie van een standaard is gewoonlijk om een conceptueel model te definiëren. (a1) Authentieke registraties worden doorgaans opgezet om een administratie van Referentieobjecten bij te houden (b2) en een ‘gewone’ Applicatie heeft gewoonlijk slechts de functie om Data te verzamelen voor een specifiek doel (c3). Uiteraard kunnen een Authentieke registratie en een Applicatie een eigen Model hebben (b1 en c1), sommige Standaarden verstrekken een lijst met Referentiewaarden (a2) en Applicaties kunnen lokale Referentietabellen hebben (c2). Ook kunnen Standaarden en Registers wat ‘gewone’ data nodig hebben (a3 en b3), bijvoorbeeld om wijzigingen en herkomst van hun referentiegegevens vast te leggen. De URI-strategie ondersteunt het hergebruik van concepten en referentieobjecten door andere data-collecties. De interessante categorieën zijn natuurlijk de termen in de Modellen en de Referentiegegevens.

245

Termen, zoals klassen en eigenschappen, die zijn gedefinieerd in de Modellen van een Standaard of een Authentieke registratie, worden gebruikt om Referentieobjecten en Data te classificeren.

De URI-strategie is bedoeld voor Modellen en Referentieobjecten van respectievelijk Standaarden en Authentieke registraties. Dus niet in eerste instantie voor de ‘gewone’ Data (rij 3) of concepten in ‘gewone’ Applicaties (kolom c) aangezien daar nou eenmaal minder naar wordt gelinkt.

‘No register, no identifier’

Referentieobjecten, gedefinieerd door Standaarden (Denk aan waardenlijsten), maar vooral die beheerd worden in Authentieke registraties, worden gebruikt in ‘gewone’ Applicaties.

In Linked Data theorie wordt nogal eens gezegd dat het nodig is om voor elk concept of object een URI te definiëren, waardoor het lijkt alsof je pas kunt beginnen als je voor elk concept of object een nieuwe Linked Data URI hebt verzonnen en ‘gemunt’ (to mint a URI). Maar waarom zou je? De mensheid definieert al eeuwen lang authentieke identificatie voor standaard begrippen en referentieobjecten. Denk aan encyclopedieën, taxonomieën en registraties van inwoners of van roerende goederen. We noemen een voorziening voor het authentiek definiëren en identificeren van concepten of objecten een register. Onder register verstaan we hier dus zowel een specificatie van

246

begrippen/concepten in een standaard, als een authentieke registratie van referentieobjecten. Doel van deze niet geringe inspanning is om vanuit verschillende administraties op een eenduidige manier naar abstracte begrippen en objecten te kunnen verwijzen zodat iedereen weet wat bedoeld wordt. Informatie uit verschillende administraties kan vervolgens gekoppeld worden door – handmatig – gelijke namen of nummers bij elkaar te zetten. Nu we dat willen gaan automatiseren is er niets op tegen om deze bestaande registers opnieuw te gebruiken. En de enige manier om voor ontbrekende begrippen en objecten een URI te munten is door deze vast te leggen in een nieuw register. Als we merken dat er voor bepaalde begrippen of objecten geen register bestaat, terwijl we hier wel URI’s voor willen hebben, dan is de enige manier om een register aan te leggen. Kortom: je kunt alleen URIs munten als deze vastliggen in een register. Dit belangrijke inzicht vatten we samen in het adagium: ‘No register, No identifier’.

Geen sector in de URI Een http-URI is een URL en bestaat dus uit ‘http://’, gevolgd door een domein en een lokaal pad. De UK-strategie gaat er van uit dat alle Linked Data URIs van de Engelse overheid worden ondergebracht op het hoofddomein ‘data.gov.uk’. Om dat schaalbaar te houden stellen zij voor om dat domein onder te verdelen in sectoren. Sectoren die genoemd worden zijn: location, education, transport en health. Dat levert twee problemen op: 1. Voor elke sector moet een partij gevonden worden die eigenaar en beheerder van dat sub-domein wil zijn. 2. Niet alle informatie valt duidelijk in één domein. Vallen treinstations onder ‘location’ of onder ‘transport’? Vandaar dat deze richtlijn niet is overgenomen in deze aanzet tot een Nederlandse strategie. In de UK onderkent men deze problemen inmiddels zelf ook. Bovendien zien zij ook problemen met het gebruik van het hoofddomein ‘data.gov.uk’. Zie hiervoor de sectie ‘Herkenbaar internetdomein’ onder ‘Open issues’.

247

Uitgangspunten Bij het opstellen van deze aanzet tot een URI-strategie hebben we de volgende uitgangspunten geformuleerd. 1. Sluit aan bij internationale bestpractices. Het heeft geen zin om in je eentje gelijk te hebben 2. Sluit aan bij bestaande ontwikkelingen. De strategie raakt vele partijen en systemen en kan niet in een keer als iets nieuws worden ingevoerd. Kijk daarom goed naar wat er al gebeurt en maak daar maximaal gebruik van. 3. Houd rekening met afwijkende strategieën. Ook als er systemen worden gemaakt die om wat voor reden dan ook niet de nationale strategie volgen, moet hiermee gelinkt kunnen worden. 4. Houd het zo simpel mogelijk, maar niet simpeler. Bij een te complexe benadering zal de strategie niet of onvoldoende worden toegepast, bij een te eenvoudige benadering zal de strategie niet voldoende opleveren. Denk bij standaardisatie goed na over: a. Persistentie Persistentie betekent dat oplossingen ook stand houden als de organisatie eromheen wijzigt. Het hoeft niet te betekenen dat een oplossing er voor de eeuwigheid is. We moeten accepteren dat

we nog niet alles weten en dat voortschrijdend inzicht tot andere keuzes kan leiden. Schaalbaarheid Schaalbaarheid is van belang om beheerkosten te kunnen blijven overzien, ook als toepassingen groeien. Het is onvoorspelbaar hoeveel applicaties er de komende jaren zullen ontstaan. Elk onderdeel van de strategie zal dan ook schaalbaar moeten worden opgezet. Begrijpelijkheid Begrijpelijkheid is noodzakelijk om te zorgen dat afspraken makkelijk worden opgepakt en overgenomen. Vertrouwen Vertrouwen is nodig om organisaties te bewegen om zelf strategisch te kiezen voor het gebruik en publicatie van Linked Data. Machine-leesbaarheid Machine-leesbaarheid zorgt ervoor dat er met Linked Data ook werkende oplossingen kunnen worden gebouwd. Menselijke leesbaarheid Menselijke leesbaarheid is ook belangrijk om te zorgen dat men oplossingen vertrouwt en begrijpt. Maar als de machine de data niet goed gebruiken kan, dan werkt het überhaupt niet.

…en in die volgorde.

248

URI-patroon Op basis van de hiervoor beschreven overwegingen en uitgangspunten komen we tot het volgende algemene patroon voor http-URIs: http://{domain}/{type}/ {concept}/{reference} {domain} Het {domain} deel bevat het internet domein en eventueel een pad binnen dat domein. {domain} = {internet domain}/ {path}. Het onderdeel {domein} van een URI zorgt voor twee dingen. Ten eerste is het een belangrijk instrument om unieke identificaties te verkrijgen. Twee objecten, die beheerd worden in twee verschillende databases, kunnen toevallig dezelfde identificatie krijgen (bijvoorbeeld: een kadastraal perceel met id 010101 en een rechtspersoon met id 010101). Als nu zowel het Kadaster als het NHR besluit deze objecten als linked data te publiceren, worden er toch twee unieke URIs gevormd: de een begint bijvoorbeeld met brk.nl en de ander met nhr.nl (of: brk.data.gov.nl en nhr.data.gov.nl). Ten tweede zorgt een goedgekozen domein voor vertrouwen. Kadastrale percelen met een URI als data. brk.nl/perceel/010101 stralen meer betrouwbaarheid uit dan bijvoorbeeld data.vindhethier.eu/perceel/010101.

Het {domain} geeft bij voorkeur het register aan waar het object in is geregistreerd – niet de organisatie (hierover later meer). Het {path} kan worden gebruikt als binnen een register verschillende verzamelingen objecten leven, waarbij dubbele id’s kunnen voorkomen. Het {path} kan dan toch voor unieke URIs zorgen. Voor grote en belangrijke registraties raadt de URI strategie aan om het gebruik van {path} te vermijden omdat zo een kortere URI verkregen wordt. Het is sterk af te raden om in het {domain} een organisatienaam op te nemen. Een belangrijk criterium voor betrouwbare URI’s, persistentie, speelt hierbij een rol. Organisaties kunnen immers gesplitst, gefuseerd, of hernoemd worden en zij kiezen dan doorgaans een nieuw internetdomein. Het hernoemen van de URIs verstoort de persistentie. Het blijven gebruiken van het oude domein– iets wat technisch prima kan – kan de indruk wekken dat de data ook verouderd is. Registers daarentegen zullen over het algemeen blijven bestaan zolang ze een bepaald nut dienen. Als deze worden vervangen zijn de modellen en referentieobjecten in het oude register ook daadwerkelijk uit de tijd.

249

Als we kiezen voor een landelijk domein speciaal voor linked data, dan zou data.gov.nl voor de hand liggen. Verschillende registers kunnen daar een plek vinden. Het {domain} krijgt dan de volgende vorm: {register}.data. gov.nl/. Bijvoorbeeld: bag.data.gov.nl, imgeo.data.gov. nl {type} Het {type} geeft aan om wat voor soort URI het gaat. Dit kan zijn: ll ‘def’: definitie van een term in een ontologie ll Deze URIs volgen een korter URI patroon, namelijk zonder het {reference} deel: http://{domain/def#{concept} ll ‘id’: identifier van een object (individual/instance) *in een register* ll ‘doc’: documentatie over het object in dit register Voor def-URI’s raden we het gebruik van hash-URI’s aan. Dit zorgt ervoor dat het verschil tussen termen in een ontologie en URIs die individuele objecten aanduiden, in één oogopslag duidelijk is. Bovendien is zo de gehele ontologie gemakkelijk te bereiken: als de URI van een term http://{domain}/ def#Pand is, kan men de hele ontologie vinden op http://{domain}/def. Als de ontologie erg omvangrijk is, kan ook gekozen worden niet gebruik te maken van hash-URIs.

{concept} en {reference} Het {concept} geeft aan wat voor soort ding de URI identificeert; {reference} is de identificerende naam of code van het individuele object .Een voorbeeld: http://bag.data.gov.nl/id/ Pand/010101 {concept} is belangrijk om twee redenen. Ten eerste kan het, in registraties waarin objecten geen binnen de registratie unieke identifiers hebben, maar wel uniek per soort object, een uitkomst bieden. Ten tweede, en dit is belangrijker, levert het een meer begrijpelijke URI op. Een menselijke lezer kan zien dat dit de URI van een pand uit de BAG is. Een mogelijk nadeel van het opnemen van {concept} in de URI is dat hiermee betekenis in de URI wordt opgenomen, terwijl betekenisloze IDs over het algemeen meer persistent zijn. Het is dan ook zeer onverstandig om {concept} enige betekenis toe te kennen voor de machine. Het is dus niet zo dat het {concept} met zekerheid de klasse is waartoe een object behoort. Als het in een registratie inderdaad denkbaar is dat objecttypen (klassen) van naam veranderen, maar dan nog wel dezelfde klasse vertegenwoordigen, is het niet verstandig dit onderdeel in de URI op te nemen.

250

Wat betreft het onderdeel {referentie} biedt de URI strategie slechts enkele handvatten aangezien de eisen in verschillende toepassingen sterk uiteen kunnen lopen. Een {referentie} kan zijn: een identificerend nummer, een alfanumerieke code, een woord of naam, etc. Elk register heeft wel een manier om de individuele objecten in de verzameling uniek aan te duiden. Deze unieke aanduiding kan worden opgenomen in de {referentie}. Denk er hierbij wel aan om geen vreemde tekens op te nemen, die in een URI vermeden moeten worden. Het beste is om zich te beperken tot lowercase letters, cijfers, en eventueel koppeltekens als scheidingsteken.

Open issues Een aantal issues hebben we wel gesignaleerd, maar hierover zijn nog geen conclusies getrokken of consensus bereikt. De vraag is ook of dat mogelijk en ook noodzakelijk is. Verschil van inzicht zal er altijd kunnen bestaan en ook dan moet Linked Data kunnen functioneren.

URNs vs. URIs Het W3C geeft als best-practice: 1. Use URIs as names for things 2. Use http-URIs, so that people can look up those names. 3. When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL) 4. Include links to other URIs. so that they can discover more things.

Dit is op zich een zeer krachtig paradigma: http-URIs maken gebruik van de bestaande infrastructuur van het web en elke browser is in staat om een http-URI op te vragen. Door middel van content negotiation – ook weer standaard http functionaliteit – vertaalt de server de aanvraag op basis van de ID naar het gevraagde formaat en levert een document – de ‘useful information’ – aan de client onder vermelding van de http-returncode ‘303-redirect’. Deze redirect is nodig omdat de documenten in verschillende formaten immers elk hun eigen URL hebben, die anders is dan de ID die opgevraagd wordt. En dat nu blijkt in de praktijk slecht begrepen en vaak verkeerd te worden geïmplementeerd. Daarnaast zien we op tal van domeinen al een standaardisatie plaatsvinden in de identificatie van informatie die online beschikbaar is. Dit is – ook als het geen Linked Data is – nodig omdat informatie op het internet op talrijke manieren kan worden gekopieerd en gecombineerd met andere informatie. Een groot verschil met de oude, papieren wereld waar kopieën spaarzaam gemaakt werden en de documenten waarnaar verwezen werd doorgaans in het dossier voorkwamen. Die standaardisatie heeft (vooralsnog?) zelden de vorm van een http-URI, maar is doorgaans een nummer, oftewel een URN (Unified Resource Name). Het bekendste

251

voorbeeld is het ISBN-nummer voor boeken. Een minder bekend, maar recenter en relevanter voorbeeld is de nieuwe standaard ECLI-code van de EU, waarmee rechterlijke uitspraken worden geïdentificeerd. Dus, denkend aan het uitgangspunt om te hergebruiken wat er al voorhanden is, zouden we kunnen overwegen om met de URNs die al gemaakt worden http-URIs te maken. Met een kleine aanpassing blijft de W3C best-practice intact: 1. Use URNs as names for things 2. Use REST-services as resolvers for those URNs, so that people can look up those names. 3. When someone looks up a URN, provide useful information, using the standards (RDF*, SPARQL) 4. Include links to other URNs. so that they can discover more things. Nu is helder dat de URN niets oplevert en dat de resolver een beschrijving van het object teruggeeft. Hiervoor is geen 303-redirect nodig. Deze benadering maakt het tevens mogelijk om verschillende resolvers te maken voor dezelfde URN. Elke resolver kan beslissen welke ‘useful information’ hij verstrekt over een concept. Een voordeel boven de http-URI die altijd naar één locatie leidt.

Herkenbaar internetdomein In de Engelse strategie is men er van uitgegaan dat alle http-URIs van Linked Data van de Engelse overheid ondergebracht worden onder één hoofddomein: ‘data.gov.uk’. Inmiddels zijn er plannen om de hele indeling van het ‘gov.uk’ domein te gaan herzien. Een belangrijk advies van een van de bedenkers van de Engelse strategie is dan ook dat het hoofddomein in de wet wordt vastgelegd, omdat anders de persistentie van de URIs niet gewaarborgd is. Het idee van een hoofddomein is echter wel degelijk aantrekkelijk. Het zorgt voor een grote herkenbaarheid van de URIs. Iets wat vertrouwen wekt bij de afnemers van de Linked Data. In Nederland zouden we hiervoor het domein data.gov.nl kunnen gebruiken. Bijkomend voordeel van dit domein is dat het nu niet in gebruik is en dus nog geen andere associaties heeft. Het zou een mooie manier zijn om deze IDs, die toch een technische functie hebben en eigenlijk onder de motorkap moeten blijven, onder te brengen. Aan de andere kant brengt één hoofddomein ook problemen met zich mee. Het domein moet onderverdeeld worden om deze oplossing schaalbaar te houden. Dat kan door sub-domeinen toe te wijzen. De sector-indeling is hierboven al verworpen. Maar ‘No register, no identifier’

252

geeft de oplossing: elk register zou zijn eigen sub-domein kunnen krijgen. Schaalbaarheid is hiermee gewaarborgd, maar er is natuurlijk wel een administratie van alle registers nodig: Een register van registers. Op zich is het natuurlijk wel handig om zo’n register te hebben, maar het brengt beheerkosten met zich mee en is een potentieel single point of failure.

Bijdragen Deze aanzet tot een nationale URIstrategie is tot stand gekomen met bijdragen van: ll Thijs Brentjens (Geonovum) ll Wilko Quak (Geonovum) ll Paul Hermans (ProXML) ll Hayo Schreijer (KOOP) ll Michel Grothe (Geonovum) ll Marcel van Mackelenbergh (Belastingdienst) ll Jan Jelle Boomgaardt (Digimelding) ll Rob van Dort (Mapplica) ll Arjen Santema (Kadaster) ll Bart van Leeuwen (Brandweer Amsterdam-Amstelland) ll Marco Brattinga (Kadaster) en andere deelnemers aan de Pilot Linked Open Data.

Referenties [1] Linked Open Data pilot (LODpilot): http://www.geonovum.nl/ dossiers/linkedopendata Projectplan pilot: http://bit.ly/17iWMhy [2] Eindrapport onderzoek ‘Op weg naar verbetering aanbod- en distributieproces open data’: http:// bit.ly/16Dyw66 [3] Joinup/Semic: http://joinup.ec.europa.eu/ European Legislation Identifier (ELI): http://bit.ly/11vhCCv W3C: http://www.w3.org/ Dublin Core: http://dublincore. org/ [4] ECLI: http://bit.ly/11vhDGw

D2 - The suitability of formats for Linked Open Data Auteurs

Thijs Brentjens (Geonovum) Marcel Reuvers (Geonovum) Clemens Portele (Interactive Instruments) When publishing or using Linked Open Data one encounters several technical aspects. An important aspect is the format for publishing data in. The W3C definition of linked data has a strong preference for RDF for encoding information about things. However, for many users it is easier to publish and/or process other formats. This paper deals with a wide range of formats and encodings, such as PDF, JSON, RDF, CSV, GML and metadata formats, and their suitability as format for linked open data. Suitability is expressed in terms of machine and human readability, abilities to structure data and openness of a format. In addition it is essential to allow for linking to other data and the other way around: to enable others to link to the data. This paper covers these aspects to provide an overview of the suitability of much used encodings and formats for Linked Open Data.

he W3C definition of linked data has a strong preference for RDF for encoding information about things. However, for many users it is easier to process other formats, e.g. CSV, JSON or XML-based grammars. Therefore, it is usually advisable to publish data in other formats, too. This technical paper provides an overview of relevant formats and provides general recommendations about their applicability in the context of Linked Open Data with special attention to the capability to represent links.

Five star model Over time, openness of the data was identified as a key element. In 2010 Berners-Lee introduced a five star rating for Linked Open Data [BernersLee]:

Available on the web (whatever format) but with an open license (Open Data)

All the above, plus available as machine-readable structured data (e.g. Excel instead of image scan of a table)

254

All the above, plus non-proprietary format (e.g. CSV instead of excel)

All the above, plus use open standards from W3C (RDF and SPARQL) to identify things, so that people can point at your stuff

All the above, plus: Link your data to other peopleâ&#x20AC;&#x2122;s data to provide context This five star model describes some requirements and recommendations on data formats and APIs for linked open data. The rest of this chapter deals with these recommendations, to facilitate the choice for data formats when publishing data as linked open data. Suitability of a format W3C and the star model of Tim Berners Lee mention RDF as a framework to use for Linked Data. But other formats than the most used RDF encodings, might be easier to publish data in and might be suitable as well. For example, URIs can be used with several formats to name things. And URIs can be used to create links between objects in several formats.

In the context of linked data, there are some considerations when choosing a data format (or multiple formats) for publishing. Looking at the star model and considering the fact that data is published on the web, the format should ideally (at least): ll be machine readable; ll allow for publishing structured data; ll be non-proprietary, so humans and machines can read the data with the software of their choice; ll be easy to read or process, using common and easily available (web) tools, browsers and technologies; ll allow to express links, both the link itself and provide information on the link (semantics), e.g. the type or role of a link (see http:// www.iana.org/assignments/linkrelations/link-relations.xml) and a human readable title; ll allow for linking to the data and/or objects, so a format should allow identifying objects / properties, preferably directly with URIs. This paper explores some commonly used formats for publishing data as linked data.

255

General purpose data formats Publishing structured data on the web is often done using XML formats, ATOM/RSS, spreadsheets or JSON. For the pilot Linked Open Data it is worth discussing these and other commonly used formats and RDF in both XML and Turtle / TTL encoding. Raw data in tabular formats: spreadsheets and CSV If data is available in tables, spreadsheets and CSV (Comma Separated Values) are often used to publish that (raw) data on the web. For many data publishers, uploading a Microsoft Excel spreadsheet to some website is a first and easy step. While this is easy to do and spreadsheets are flexible and powerful, this format has the main disadvantage that it is a proprietary format and requires special (heavy) software to read it: some office software. If just the raw data is published as CSV, many tools can read or process the data. Varying from plain text editors, to lightweight software libraries, to end-user applications. A disadvantage (albeit for the slightly more advanced use cases) is that it is hard to validate spreadsheets and CSV data. Using links is basic: links that point to other resources could be stored as values of â&#x20AC;&#x2DC;cellsâ&#x20AC;&#x2122; to, but this is limited to providing the link itself. There is no standard way of providing seman-

tics on the link. Linking to the data in the document is limited to linking to the location of the entire document. Linking to individual objects (rows) or properties (cells) is not supported by these formats. XML There are many XML-based data formats around. XML is designed to be machine readable, to allow publishing of data in a structured way. The structured character of XML can be seen in its syntactic rules and XML schemes. Domain specific languages make use of this, for example KML and GML for geospatial data. There are lots of software packages and libraries to deal with XML. Often, some domain specific languages are supported. Browsers and text editors can open (non-binary) XML documents directly, although making it easily readable for humans requires some processing or understanding of the format. XSLT is a language to transform XML data to other formats, for example to present it as HTML in a web browser. A powerful way of describing links in XML is with XLink. However, support for XLink in XML grammars and tools is limited. XLink defines XML elements for describing a link and (semantic) information on that link, to describe what the link means and how to deal with a link. For example, using the attributes xlink:href, xlink:type and xlink:role.

256

If an XML document is available on the web, linking to a fragment of the data in the document can be done using the standard XML ID attribute. This enables linking to objects, encoded in XML. Publishing data with ATOM ATOM is an XML format to syndicate resources on the web. This is also known as a web feed. These feeds contain descriptive elements of resources and links to them and other relevant information. ATOM is used, for example, for syndication of news or blog posts. The data the feed points to could be in another format. Support for ATOM feeds in software libraries is available and many web browsers have native support for ATOM. They can read (parts of) an ATOM-document and display them in a human-friendly way. ATOM has extensive capabilities for (typed) links. These links can be used to point to other resources, metadata or other feeds. The semantics of the links can be expressed, for example: the media type the link points to, the relation type and a human-friendly title. A feed can be linked to by using its identifier whose content is an IRI (a form of a URI). ATOM feeds offer entries with an identifier. Since this identifier is an IRI/URI, it is possible to link

to an entry. These identifiers are not necessarily resolvable (with HTTP). RDF: XML format and Turtle In the context of Linked Data, RDF is not to be left out. In itself RDF is not a format, but a framework to model information. RDF uses triples of a subject, predicate and object to model information on the web. These triples may use URIs, to identify all three the components.

Figure 1: RDF triple

In fact, RDF heavily relies on URIs for referring to and from other information. Also, the characterization of the predicate is referenced using URIs. RDF uses URI-based vocabularies to do so. In other words: using RDF allows for linking to and from other data. In this respect, RDF is a very suitable format for publishing linked data on the web. SKOS (Simple Knowledge Organization Systems) provides a standardized way to represent knowledge organization systems with RDF. SKOS aims to facilitate the sharing and linking of data. SKOS defines a data model for this and uses RDF.

257

There are several RDF encodings, most notably an RDF/XML (http:// www.w3.org/TR/rdf-syntax-grammar/) encoding and Turtle (http:// www.w3.org/TR/turtle/). There is support in tooling for both RDF/XML and Turtle, mostly for creating RDF and for processing it using software libraries. Using common XML-tools and technologies, RDF/ XML can be processed. Turtle requires some specific ‘parsers’. Support for RDF in web browsers to present it to users is very limited, mostly to default XML displaying, which makes it difficult to use for end-users. Support in clients (both general and spatially enabled clients) is very limited. Compared to other formats like CSV and ATOM and some geospatial formats as will be discussed later, RDF is harder to use at the moment. For validation and testing, some tooling is available. For example, the W3C RDF validator checks predicates for RDF-XML: http://www.w3.org/RDF/ Validator/. JSON Many websites and APIs use JSON to represent data. JSON is a text format that can be easily read (parsed) by machines. It is often used in web applications and preferred over XML (for example), since it uses an encoding similar to JavaScript, that web browsers can parse directly. Many

libraries offer support for reading / processing and writing JSON data. Just as with XML, plain text editors and web browsers can display the data in raw form, but interpreting the data requires some knowledge of the format. There are some plug-ins and tools that display JSON in a more user-friendly way, but in general support in clients that end-users use is limited. JSON does not have a specific type to express links or triples. There is discussion on this in the web community (For example http://bit.ly/rxDIiE) and some draft mechanisms/formats are defined (like JSON-LD or HAL), but none of them is prevailing at the moment. So there is no practically accepted or standardized way for links and describing link semantics in JSON currently. Identifying objects in a JSON document is not standardized either. JSON as such is a suitable format to publish data in, so that others (applications) can consume it, but for linked open data, JSON is less suitable – at least for now. This will likely change due to the popularity of JSON; for example, Facebook provides access to their linked data via their Graph API in both JSON and Turtle.

258

Documents Documents as intended in this section are generally not used to publish raw, structured data, for further processing (by machines), but provide a more human-friendly presentation of information. (X)HTML HTML is the markup language of the web. There is no need to say that HTML is one of the most common formats on the web for publishing (human readable) information. For publishing raw data HTML is generally less suitable. HTML itself can use links to other documents and parts of documents, for example to a specific section in a document using anchors (#). Expressing some link semantics in XHTML, like the media type and role is possible. If used properly, HTML can be processed by machines quite well. Search engines for example parse HTML. All kinds of tools and software libraries support HTML. For publishing documents in the context of linked data, HTML is suitable.

When using XHTML, one can add metadata about the document with RDF, and provide links to other resources, for example to provide information about the author, the subjects of the document and the sources used. This is discussed at the web page http:// www.w3.org/MarkUp/2004/02/ xhtml-rdf.html. PDF For documents on the web, PDF is a popular format. PDF started as a proprietary format, but is an open standard since 2008. Most users are able to directly open a PDF document, for example in their browser or using a viewer / reader. PDF documents are often used to publish a read-only document. The formatting of the document is preserved when opening. PDF is not designed to provide raw, structured data. Creating or saving documents as PDF can be done with all kinds of software and software libraries. Some libraries support the processing of PDF as well. Linking to a PDF document is easy, but it is not possible to link to fragments of a PDF document. PDF documents may contain links to resources on the web. Link semantics are hard to describe. PDF is a suitable format for publishing a document on the web for humans, but for publishing raw data and if advanced linking capabilities are required it is better not to use it.

259

Microsoft Word Publishing a document in Microsoft Word is not preferred, since this format requires additional software (office software or plug-ins) and is a proprietary format. It is harder to process data from the documents automatically. The linking capabilities are comparable to PDF.

Images and graphics Image formats In the context of linked data, image formats like PNG, JPEG and GIF can be treated similar. Linking to them is done in a regular way. Displaying images in these formats as well: web browsers and many other tools can deal with the formats. For further processing of the data they are less suitable. The raw data is hard to extract from the images. Linking to data in the images and linking to other information from the image is not directly possible. So for publishing data that requires some linking capabilities, these formats are not suitable. SVG SVG is an XML format for 2D vector and raster graphics. Linking to an SVG document is done the same as with images: just point to the URL of the SVG-file. However, SVG also supports fragment identifiers to point to parts of the SVG file or objects. SVG objects themselves may contain an HTML-link. For presenting data with

links and pointing to graphical objects (in a file), SVG could be a suitable format. For example: ll linking to an SVG document: http://www.w3.org/TR/SVG/ images/linking/link01.svg ll and to a part of an SVG document: http://www.w3.org/ TR/SVG/images/linking/link01. svg#svgView(viewBox(1,2,1,2)) ll link to an object in a SVG-document with identifier ‘object-123’: http://example.com/ drawing.svg#object-123 Some browsers have native support for SVG, but others require a plug-in. As such, publishing data in SVG is less suitable in the context of Linked Open Data.

Geographic information This section focuses on data formats for geographic information. When discussing client capabilities, these are considered to have capabilities to process geographic data. GML Looking at the considerations for suitability for publishing linked (open) data, GML fulfills many of them. The format is an open standard, it’s readable (since it is XML) and provides the ability to link to other information.

260

GMLâ&#x20AC;&#x2122;s model bears similarities with RDFâ&#x20AC;&#x2122;s model. GML uses XLink, so that it is possible to reference remote features and properties in a GML document. In other words: it is possible to link to information in other GML documents. Describing link semantics like role and title is possible as well. GML thus offers extensive linking capabilities. Support for GML in clients differs. Support is mainly found in the geospatial domain only. Many desktop clients support GML to some extent, for example reading and writing Simple Features GML. Native support for complex GML and resolving links is limited in clients. In geospatial software libraries and conversion tooling there is support for GML, often simple features only, sometimes more. Some libraries support resolving Xlinks. Support for complex GML is less widespread. OGC offers a GML validator as part of their compliance testing suite, currently in beta testing, at http://bit.ly/ ZZSNkw.

KML Where GML is concerned with the data only, KML focuses on visualization of geographic information and interaction with the users. KML is designed to be used in geographic browsers like Google Earth and adopted by the OGC. Besides in Google Earth, support for KML (sometimes limited) is offered by other freely available clients, like Google Maps, in geospatial software and software libraries. KML is an XML format and has some resemblance with GML. KML is not as rich in expressing geospatial data as GML is. Objects in KML can have an XML ID, so linking to a specific object in a KML file is possible. Linking from a KML document to other information is possible (e.g. in the description of an object or from a document to another document), but not as strong as in GML. For publishing data to end-users, KML is a suitable format. If some more advanced linking capabilities are required, KML is not the best to use. WKT/WKB geometry To represent the geometry of geographic data in a text encoding the Open Geospatial Consortium has defined Well-Known text (WKT). Several databases support this format and its binary equivalent (Well-known binary, WKB) to transfer and store

261

geometry. Some client-software supports WKT as well. WKT and WKB are only intended for geometry representation and not (entire) objects or features. Therefore linking capabilities are not relevant for WKT/WKB geometry. GeoRSS GeoRSS is an extension to add location to regular ATOM (and RSS) feeds and entries. The linking capabilities of GeoRSS are therefore the same as with ATOM feeds, see the ATOM section before. GeoRSS support is offered by several software libraries, clients and freely available online mapping platforms, like Google Maps. Shapefile Although much used and with a publicly available description, the shapefile format formally is not an open format. In practice there is lots of support for it in GIS clients and software libraries. However, if no GIS tooling is available, data in a Shapefile is not easy to read / process, because a shapefile in fact consists of several mostly binary files. Links could be provided as attributevalues of an object, but there is no native support for links and semantics of links. Linking to the file is more difficult. It is not possible to use a single URI to refer to a shapefile, unless it is a compressed / ZIP-ed file, which canâ&#x20AC;&#x2122;t be read directly.

GeoJSON GeoJSON is a format for encoding a variety of geographic data structures in JSON. GeoJSON focuses on the spatial properties of the data. See the section on JSON for general characteristics of JSON, like the linking capabilities. Several software libraries and APIs (like Google Maps, Bing Maps) offer direct support for reading and/or writing GeoJSON. Some geospatial ETL software and desktop clients are able to consume GeoJSON. GeoServices JSON GeoServices JSON is a specification of Esri, for formatting all kinds of objects in JSON, including geospatial features. It is part of the GeoServices REST API. The GeoServices REST API currently is supported by Esriâ&#x20AC;&#x2122;s ArcGIS software including the online platform ArcGIS Online as well as other geospatial client and server software. Similar to GeoJSON, GeoServices JSON has no additional linking capabilities, so for the linking capabilities see the section on JSON.

262

Metadata Metadata are used to provide information on data and/or the structure of data. For linked data and the standards as dealt with in this document, the following sections describe relevant standards / specifications to provide metadata. Dublin Core The Dublin Core metadata element set defines general metadata elements. For example title, subject, description, publisher, date and rights. Dublin Core metadata can be used for multiple purposes. There are syntaxes for RDF, HTML, an XML format and plain text. Dublin Core is often embedded in ATOM and RDF documents to annotate them with metadata. Standardization organizations like IETF and ISO use Dublin Core. In the Netherlands OWMS (the Overheid.nl Web Metadata Standard) is based on Dublin Core, for metadata on information of Dutch governments on the internet. VoID The Vocabulary of Interlinked Datasets (VoID) is concerned with metadata about RDF datasets (http:// www.w3.org/TR/void/). It is an RDF Schema vocabulary that provides

terms and patterns for describing RDF datasets, and is intended as a bridge between the publishers and users of RDF data. VoiD descriptions can be used in many situations, ranging from data discovery to cataloging and archiving of datasets, but most importantly it helps users find the right data for their tasks. VoiD covers four areas of metadata: ll General metadata following the Dublin Core model, e.g. where to find a SPARQL endpoint, data dumps; ll Access metadata describes how RDF data can be accessed using various protocols, e.g. where to find a SPARQL endpoint, data dumps; ll Structural metadata describes the structure and schema of datasets and is useful for tasks such as querying and data integration, e.g. metadata on the URI pattern, examples, used vocabularies, statistics; ll Description of links between datasets are helpful for understanding how multiple datasets are related and can be used together. VoID leverages Dublin Core and FOAF vocabularies and is used by several providers of RDF datasets.

263

Microdata, Microformats, RDFa Metadata can be provided as separate, standalone documents (accompanying or referring to the document / resource somehow) or in documents themselves. For (X)HTML and XML documents a commonly used approach is tagging (annotating) the documents with metadata elements. Microdata, microformats and RDFa are specifications to accomplish this. They are often considered relatively simple mechanisms to provide metadata and better semantics to documents. They define the usage of certain attributes, with standardized values and elements in (X)HTML and XML, to embed (meta)data on commonly published things like people, addresses or blog posts directly in the document. The contents of the document generally donâ&#x20AC;&#x2122;t change. The formats only add extra attributes and elements to annotate parts of the document as being (meta)data, making them more machine-readable. Search engines often index this information (see for example http://support. google.com/webmasters/bin/answer. py?hl=en&answer=99170) and browsers can extract it to provide extra or better functionality.

ISO 19115 ISO 19115 defines the schema required for describing geographic information and services (source: ISO 19115:2003). It provides information about the identification, the extent, the quality, the spatial and temporal schema, spatial reference, and distribution of digital geographic data. ISO 19115 metadata is used to describe datasets for discovery, for evaluation or in order to access the geographic data. There is an XML encoding for ISO 19115. Metadata on geographic data are often provided as standalone document for datasets (for example available in a catalogue service / metadata repository) or embedded in a GML feature for feature-level metadata.

References Berners-Lee, Tim. Linked Data, 2006. Retrieved June 7, 2013, from http://www.w3.org/DesignIssues/ LinkedData.html

D3 - Accessing data with HTTP, URIs and links Auteurs

Thijs Brentjens (Geonovum) Marcel Reuvers (Geonovum) Clemens Portele (Interactive Instruments) HTTP URIs are important building blocks of linked open data, on the web. An HTTP URI serves as an identifier and as a reference to a description on the object identified by that URI. This paper discusses HTTP and URIs in the context of Linked Open Data from a technical point of view. Topics also include HTTP’s abilities for redirecting a client (using HTTP 303) to information and for requesting different encodings of the information using Content negotiation. Web-based APIs (Application Programming Interfaces) enable users to work with data sets, for example to query data and retrieve parts of them. The paper discusses some of these APIs. Links alone are not sufficient, for humans and machines, to know where the link points to exactly; for example to determine if it is useful to follow that specific link. Semantics about the link can help to understand the link better.

URIs and HTTP play an essential role in the context of Linked Open Data on the web. URIs can be used to identify objects globally and allow for linking data on the internet. This paper provides an overview and explains the underlying concepts and how they are used in practice in the web today. After discussing HTTP and URIs as identifiers, it deals with resolving URIs and retrieving data using APIs. In order to understand what the URIs and links refer to, the paper concludes with a description on how to provide link semantics.

HTTP URIs to identify things on the web URIs are important building blocks of linked open data, as expressed in the first two principles of Linked Data: 1. Use URIs as names for things 2. Use HTTP URIs so that people can look up those names. The online book ‘Linked Data: Evolving the Web into a Global Data Space’ [Tom Heath and Christian Bizer, 2011] states on this: ‘[…] Linked Data uses only HTTP URIs, avoiding other URI schemes such as URNs and DOIs. HTTP URIs make good names for two reasons: 1. They provide a simple way to create globally unique names in a decentralized fashion, as every owner of a domain name, or delegate of the domain name owner, may create new URI references.

265

2. They serve not just as a name but also as a means of accessing information describing the identified entity.’ Publishing URIs allows others to look up information on objects and link their data to objects from other collections. This chapter takes a closer look at HTTP and URIs. From now on in this document URI also refers to HTTP URI, unless stated differently. In the Pilot Linked Open Data a draft URI strategy for e-government data in the Netherlands is developed. The URI strategy provides more details on the preferred URI pattern to identify things.

Identifiers In order to link to something on the web, it must be identifiable. [Tom Heath and Christian Bizer, 2011] describe this as: ‘To publish data on the Web, the items in a domain of interest must first be identified. These are the things whose properties and relationships will be described in the data, and may include Web documents as well as real-world entities and abstract concepts. As Linked Data builds directly on Web architecture, the Web architecture term resource is used to refer to these things of interest, which are, in turn, identified by HTTP URIs.’

Different organizations and different datasets within a single organisation may describe the same real-world thing; each within their own context. There could be for example a registration of a building by organisation A and one by organisation B, where B records more information on the buildings than A. Both refer to the same building and could use the same URI. By using the same object identifiers (in both registrations) these objects can be linked to each other. For Linked Open Data these identifiers take the form of a URI.

Closer look at URIs A URI is a string of characters to identify a name or a resource on the web [Uniform resource identifier]. A URI is either a Uniform Resource Name (URN) or a Uniform Resource Locator (URL). HTTP URIs for an object generally consist of: ll the scheme, for HTTP URIs this is ‘http’; ll an authority, in practice this is a domain name and optionally a port; ll a path to the object ll (optionally) a query using parameters after a question mark; ll (optionally) a fragment identifier, pointing to a specific part (fragment) of the resource.

266

Written as a URI, the above would result in a URI like: http://{authority}/ {path}?{query}#{fragment identifier} When the fragment identifier is used to identify an object, the URI is called a Hash URI. This type of URI is not recommended to use when the referred object is part of a large collection, since this results in retrieving the entire collection, while only a small part is needed. (For a discussion on hash URIs versus so called 303 URIs, see for example the section ‘Hash versus 303’ in http://bit.ly/19kE2vk .) Therefore, it is recommended to use one URI for each object. This type of URI is called a 303 URI, which is explained later. This results in URIs like: http:// example.com/id/roads/a12 to identify a road, with number A12.

URI as a reference to a description More than an identifier The scheme ‘http’ suggests that the URI can be resolved to a document. Technically, it is not necessary for a URI to be resolvable. However, it is often expected by users that if a URI is simply opened in a web browser, some information is shown. URIs thus offer both a mechanism to identify a resource on the web and a means to get information on this object. For example if http://example.com/

id/roads/a12 is the identifier of a road, then opening this URI with a web browser results in a description, e.g. in XML or HTML of that road. Techniques to resolve the URI are subject of the next section. Multiple representations There can be more than one description of a resource. For example descriptions in different formats (also called: media types), or other abstractions of the same real-world phenomenon in the context of different specific applications. So besides identifying the thing, there is a need to distinguish its different descriptions. For example, a description of a geospatial object could be available in RDF-XML but also in GML (for direct usage in some geospatial software) and in an HTML page, to provide a human friendly description. Each of these documents is a different representation of the same object. The question rises how to ask for a specific media type. Media types and content negotiation HTTP offers a way to ask for a specific media type, while using the same URI. This is done by sending extra information with the URI in an HTTP Header element, the Accept header. The server can use this to return the information in the appropriate media type. For example, if a software client such as a browser asks for text/html, the server is expected to return an

267

HTML document to the client. If the same URI is provided, but the client requests application/xml, the response should be encoded as XML. This mechanism is called content negotiation.

Since a server is not obligated to support all requested media types, it is advisable for clients to ask for commonly supported media types. Media-types of commonly used formats in are listed in table 1. For more media-types and formats, see http://www.iana.org/assignments/ media-types. Not all formats have officially registered media types. As part of the implementation of the European INSPIRE directive to establish a European Union spatial data infrastructure, the need for a register for media types for geographic information has been identified. This register is at http://inspire.ec.europa. eu/media-types.

For example, to ask for the HTML representation of an object identified by http://example.com/id/roads/a12 , the HTTP GET request could look like: ll GET /id/roads/a12 HTTP/1.1 ll Host: example.com ll Accept: text/html And for a JSON representation it could be: ll GET /id/roads/a12 HTTP/1.1 ll Host: example.com ll Accept: application/json

Table 1 - Media-types for commonly used data encodings, for documents, alphanumerical and geographic data Format Media-type Remarks ATOM application/atom+xml CSV text/csv Esri Shapefile

Shapefiles consist of multiple files, so there is not one media type. INSPIRE uses â&#x20AC;&#x2DC;application/ x-shapefileâ&#x20AC;&#x2122; for a zip archive that contains least the shop, shx and dbf files.

GeoJSON application/json GeoRSS application/rss+xml or application/atom+xml GeoServices JSON

GeoRSS has got a media type of its own, but since it extends RSS and ATOM, these media types are used.

application/json

GIF image/gif GML application/gml+xml HTML text/html

268

Format Media-type Remarks JPEG image/jpeg JSON application/json Format Media-type Remarks KML application/vnd.google- earth.kml+xml

This is for uncompressed KML.

KMZ application/vnd.google- earth.kml+xml

Compressed KML

Microsoft Excel

application/ms-excel

Microsoft Word

application/msword

PDF application/pdf PNG image/png RDF-Turtle text/turtle RDF-XML application/rdf+xml SVG image/svg+xml XHTML application/xhtml+xml XML application/xml

Strictly spoken content negotiation is sufficient to ask for a certain media type. However, it is also possible to have the media type as part of the URI (for example when putting a URL in the address bar of a browser or when ‘clicking’ on a link). This has the advantage that it is already clear which format to expect. This approach is common practice on the web. It results in several URIs, one for each representation. Typically this is done using suffixes (e.g. ‘.rdf’, ‘.html’, etc.) or query parameters (e.g. ‘f=json’, ‘outputFormat=application/xml’).

Often XML is used to define other formats with their own media types

For an HTML representation the URI of the object identified by http:// example.com/id/roads/a12 could be http://example.com/id/roads/a12. html and for a JSON representation http://example.com/id/roads/a12. json.

Technology for resolving HTTP URIs HTTP Basics The most relevant HTTP methods for Linked Data are HTTP GET and HTTP HEAD. HTTP GET is used to retrieve the resource at the URI, for example a document. HTTP HEAD is used to

269

discover if a resource is available at that URI or at another location (without retrieving it). Other HTTP methods, like POST and PUT, are intended for modifying data, which is out of scope for the pilot and this document. If a client sends a HTTP GET request, a (web)server is expected to get that resource and return it to the client. Mostly, when a user enters a URI in a browser, an HTTP GET request is sent. The server uses codes to tell the client what the response is. For example, if the resource is found, the HTTP code ‘200’ is returned. If the resource is not found, an HTTP 404 code is returned. For all HTTP response codes, see the HTTP specification.

fies an object, to a document about the object. URIs using 303 redirects are called 303 URIs [Tom Heath and Christian Bizer, 2011]. Conceptually this redirection is consistent. A web server can’t return the (real-world) object that is identified by a URI, but it can say where to find information on that object. So if a URI is resolved, the response is a location of a description of that object. Testing URIs The validator at http:// validator.linkeddata.org/vapour allows for testing URIs (of resources) for being resolvable and using the 303-mechanism, for supporting content-negotiation and provides links to other validators. This validators helps to understand these mechanisms.

HTTP 303 redirects and 303 URIs If the resource is not available at the requested location, but the web server knows where to find it, the server responds to an HTTP GET or HEAD request with the location of the resource. This mechanism is also known as redirection. The HTTP code 303 is the appropriate code for redirects in the context of linked data. Note that for end users this redirection mechanism isn’t visible in most cases. Web browsers resolve redirects automatically for the end user.

APIs for accessing resources

For linked data, 303 redirects are used to redirect a URI, which identi-

If an API supports the retrieval of an individual resource, through one

[subpar tot Linking data: provide context to data] Overview HTTP provides general methods to request and manipulate documents on the internet. For applications this may be sufficient, but (standardized) APIs can be very helpful for building applications, for example to perform queries on collections of resources. APIs are typically closely linked with a format or family of formats.

270

(HTTP GET) request, URIs can be mapped to the API directly. This means that only a mapping between the API requests and URI pattern of the data might be needed to publish data for linking. Others can then follow these links to inspect or use the data directly. SPARQL The most important query interface on RDF representations of data is SPARQL. This language, an official W3C recommendation, syntactically has some resemblance with SQL. With SPARQL a client can search through triple patterns, to retrieve data from collections in triple stores. SPARQL allows for federated searches, to get results from multiple SPARQL endpoints. Since SPARQL is designed for RDF and RDF relies on links, accessing linked data by means of SPARQL endpoints might be very useful. Many semantic web tools and software libraries offer support for SPARQL. The OGC has standardized an extension to SPARQL to support spatial predicates, GeoSPARQL. WFS The most important query interface on GML representations of data is by Web Feature Services (WFS). WFS is an OGC [OGC 09-025r1] and ISO standard to retrieve and manipu-

late geographic information, and in particular GML, over the internet. To access geographic information, the WFS specification describes operations to perform queries on resource collections of geographic objects. Both desktop clients and software libraries in the geospatial domain support WFS. One of the WFS operations allows to fetch a GML object using an HTTP GET request. If URIs are mapped to these requests, for example using 303 redirects of a URI to a WFS request, this could be used to access a GML representation of an object through a URI. The URI then redirects to the WFS request, which in turn results in a GML representation. WFS also defines mechanisms to deal with Xlinks, to resolve local and remote references. This way data that links to other data might be resolved at once and queries may include predicates on linked objects, by a WFS server. For accessing (linked) geospatial data this can be a powerful and useful mechanism. GeoServices REST API The most important query interface on GeoServices JSON representations of data is the GeoServices REST API. The GeoServices REST API was originally developed by Esri for their ArcGIS software, to access geospatial data, in particular in GeoServices

271

JSON format. The GeoServices REST API offers, among others, methods to query resource collections using HTTP. The GeoServices REST API provides structured patterns for URIs to request resources, but does not offer any extra linking capabilities, or server side mechanisms to resolve links to (other) resources.

Linking data: provide context to data To fully leverage linked data, it is important to link the data itself to other data: to create links from the dataset published and express what the link is about. This provides context to the data published and helps others understand the data. This section discusses what information on a link is important, to provide context. Links to discover more The fourth principle of Linked Data as defined by Tim Berners Lee is: ‘Include links to other URIs so that they can discover more things.’. Linking to other information is useful to provide context. Creating a link to another resource can be done for several reasons. For example: ll to define a relation with a resource (‘this object is part of object X’ or ‘this object extends object X’ or to add additional properties to a resource);

ll to point to a definition or type (‘this object is of type A, which is defined here’); ll to point to associated information; ll to refer to documentation in another format or language (‘for an HTML description in English, see here’). Links help people and computers to better understand and process the data. Links provide context and allow for more and related information to discover. Just providing the URI itself as a link, might not be enough for others to understand and use the link. Is the link for example an object identifier, a definition or a background information? For others to discover more things, in the context of linked data, it is important to provide information on the semantics of the link. This can be useful for another computer to process data, e.g. automatically provide more information on a resource, or for a human to understand what the link is about, e.g. to display a human readable title about a link, to provide titles in multiple languages, or to point to which definition is used to describe the thing. Information about links When following links it can be important to know something on what the link points to upfront. To express commonly used relation types and concepts of links, vocabularies and

272

descriptions are available on the web. For example FOAF and SKOS coming from the RDF world (RDF makes use of vocabulary and reusing vocabularies, published by others, is common practice) and the relation types as defined by IANA (http://bit.ly/hLkROI) for the web in general as used by for example ATOM. In addition, some information on the resource that the link points to, for further processing the link, can be useful for both machines and humans. For example: ll the media type of the referred resource, so that a computer might process the document accordingly; ll the language of the referred resource (e.g. English, Dutch), so that a user knows which language to expect. Not all formats have good support for links and describing links. Formats like CSV and Shapefiles have no built-in linking capabilities. They can still be useful to some extent though. Linking to an entire file is possible. And if a unique code per row is known, it is still possible to use links to objects. For example, assume that the statistics office provides a URI for statistical units using the NUTS code, then CSV data that includes NUTS codes effectively links to the statistical units, but requires additional knowledge to understand the links.

Other formats and frameworks do have capabilities to express semantics of links more strongly however. In RDF this is the URI of the relation type, e.g. if a link in an information resource of a person is classified as ‘http://xmlns.com/foaf/0.1/knows’, then the link expresses that persons knows another person, identified by the URI. In GML the name of the property element expresses the type, e.g. <app:owner xlink:href=‘…’/> expresses that the ‘app:owner’ property can be found at the location specified by xlink:href. In ATOM this is the value of the rel attribute, e.g. <link href=‘…’ rel=‘previous’/> expresses that a previous version can be found at the location specified by xlink:href.

References ll OGC 09-025r1, 2010. OpenGIS Web Feature Service 2.0 Interface Standard Open Geospatial Consortium. ll Tom Heath and Christian Bizer (2011). Linked Data: Evolving the Web into a Global Data Space (1st edition). Synthesis Lectures on the Semantic Web: Theory and Technology, 1:1, 1-136. Morgan & Claypool. ll Uniform resource identifier, Retrieved June 7, 2013, from http://en.wikipedia.org/wiki/ Uniform_resource_identifier

D4- Een nieuwe wereld, een nieuwe informatiearchitectuur Auteurs

Ria van Rijn (Atelier Helder Informatie Architecten) Arjen Santema (Kadaster) Linked Open Data maakt het mogelijk, dat gegevens die door verschillende partijen zijn gepubliceerd op internet, worden geïnterpreteerd en gebruikt door derden. Dit leidt tot een interessante business case voor overheidsorganisaties. De eigenaar van gegevens kan met Linked Open Data voor een fractie van de kosten voldoen aan zijn plicht gegevens te publiceren. En de afnemers hebben niet alleen lagere kosten, maar ook veel meer vrijheid in de manier van afnemen. Bovendien kunnen de gegevens gecombineerd worden tot verrassende, ongedachte toepassingen. Hoewel Linked Open Data nog in de kinderschoenen staat, gaan de ontwikkelingen ook erg snel. Daarom is het belangrijk om de consequenties ervan nu al in kaart te brengen. Optimaal gebruiken van deze nieuwe techniek vereist namelijk ook veranderingen in het omgaan met gegevens (door mensen maar ook door applicaties). Bovendien veranderen de verantwoordelijkheden van de organisatie met betrekking tot veiligheid en privacy. Een organisatie moet hiermee bij voorbaat rekening houden, wil zij ten volle kunnen gaan profiteren

Linked Data Linked Data is een techniek, die semantische en technische interoperabiliteit opheft. Bovendien kan redundantie van gegevens hiermee vermeden worden. Linked Data is niet noodzakelijk Open Data. Linked Data kan ook gebruikt worden om data integratie binnen één organisatie te realiseren, bijvoorbeeld binnen één gemeente. Open Data heeft tot doel gegevens beschikbaar te stellen aan om het even wie, om daar interessante toepassingen mee te maken. Voor overheden is het concept van Open Data interessant, omdat daardoor tegemoet gekomen kan worden aan wensen van burgers en bedrijven, terwijl de kosten voor toepassingen door derden gemaakt worden. Linked Open Data combineert de techniek van Linked Data met de doelstellingen van Open Data. In deze paper gaan we uit van Linked Open Data, tenzij anders is vermeld.

van de voordelen van Linked Open Data. Informatie architectuur gaat over het aanbrengen van samenhang tussen ontwikkelingen rond de informatievoorziening in een organisatie. Omgaan met de techniek van Linked Open Data is daar een voorbeeld van. Inzetten van Linked Open Data be-

274

perkt zich namelijk niet tot technische veranderingen. In dit artikel zullen we eerst laten zien, dat er voor overheidsorganisaties een goede business case is voor het via Linked Open Data verspreiden van overheidsgegevens. Vervolgens gaan we in op de consequenties, die het gebruik van deze techniek heeft op de andere aspecten van informatie architectuur, zoals gegevenskwaliteit en beveiliging. Dit artikel is nog maar het begin van een inzicht in consequenties van het gebruik van Linked Open Data voor de architectuur van overheidsorganisaties. De inzichten zijn nog pril, maar de ontwikkelingen gaan snel. Het is voor de organisaties, die Linked Open Data willen gaan toepassen, van groot belang om alle consequenties ervan in het oog te houden. Zo kan voorkomen worden, dat voordelen teniet worden gedaan omdat niet alle aspecten goed zijn geĂŻmplementeerd. Precies dat is het doel van werken met informatie architectuur.

Drijvende krachten bij de overheid: soberheid en transparantie Er zijn momenteel twee krachten, die de veranderingen bij de overheid drijven: soberheid en transparantie. Het toepassen van Linked Open Data door de Nederlandse overheid is kansrijk, omdat Linked Open Data zowel aspecten van openheid als van soberheid in zich heeft. Linked Open Data draagt namelijk niet alleen bij aan het open beschikbaar stellen van gegevens, wat de transparantie bevordert, maar kan dit uiteindelijk ook voor een fractie van de kosten doen, omdat het kostbare interoperabiliteitsproblemen kan oplossen. Een duidelijke formulering van de politieke waarde van transparantie is te vinden in de Open Government Initiative van Obama: â&#x20AC;&#x2DC;My Administration is committed to an unprecedented level of openess in Government. We will work together to ensure the public trust and establish a system of transparancy, public participation, and collaboration. Openness will strengthen our democracy and promote efficiency and effectiveness in Governmentâ&#x20AC;&#x2122; [7]. De overheid is immers van iedereen, dus ook de kennis van de overheid. (Deze openheid krijgt wel een enigszins cynische ondertoon in het kader van de ophef rond het PRISM-project van de NSA, waarin deze dienst alle internet- en sociale media verkeer blijkt af te luisteren.)

275

Ook Europa [9] en Nederland [10] hebben transparantie en het delen van gegevens hoog op de agenda staan. Onder andere het Inspire programma is een belangrijke drijfveer om met name geo-data binnen de EU te standaardiseren en te delen middels open data. Dat er een mogelijkheid is drastisch te besparen op de kosten door het beschikbaar stellen van gegevens bewijst het voorbeeld van het KNMI. In het EU rapport ‘Pricing Of Public Sector Information Study’ [2] wordt becijferd dat het KNMI in 1999 met 25 FTE nog €650.000 kosten maakte voor het verspreiden van gegevens over het weer. Daarbij waren toen in de markt nog 5 hergebruikers met een totale omzet van €5 miljoen door 50 FTE. In 2010, na vrijgave van de weergegevens, werd door het KNMI met nog maar 1,5 FTE €250.000 aan kosten gemaakt. Daar stond tegenover dat er in de markt inmiddels 50 meteorologische dienstverleners gebruik maakten van de weerdata, met een totale omzet van €20 miljoen door 150 FTE. Dat betekent €4 miljoen omzetbelasting. Het KNMI hoeft geen diensten meer te ondersteunen voor het verspreiden van data. Dat doet de markt. In plaats van kosten te maken genereert de overheid inkomsten; zie hier de business case voor de Nederlandse overheid.

Soberheid en transparantie zijn echter zeer algemene politieke uitgangspunten. Deze kunnen ook op andere manieren dan uitsluitend met Linked Open Data worden gerealiseerd. Transparantie kan ook geboden worden door miljoenen documenten on line toegankelijk te maken (Open Data). Soberheid kan ook bereikt worden door binnen de overheid gegevens te delen via de techniek van Linked Data. In deze paper gaan we echter uit van Linked Open Data en de voordelen die dit biedt voor de overheid, namelijk een elegante en uiteindelijk goedkope oplossing voor technische en semantische interoperabiliteitsproblemen gecombineerd met de mogelijkheid het gebruik van de gegevens deel voor rekening van de markt te laten plaatsvinden. Vanuit die gedachte is het interessant om te onderzoeken of het stelsel van basisregistraties gerealiseerd kan worden met Linked Open Data.

Nederlands stelsel van basisregistraties Het stelsel van basisregistraties is in oorsprong bedoeld voor hergebruik van enkele aangewezen gegevensverzamelingen door de overheid zelf. Centraal staat de gemeentelijke Basis Registratie Personen (RNI en GBA), met daarin de natuurlijke personen. Deze kunnen Rechtspersonen of Samenwerkingsverbanden oprichten die in het Nieuw Handels Register van de Kamer van Koophandel worden

276

geregistreerd. Onroerende zaken (Kadaster) en roerende zaken (vaaren vliegtuigen bij het Kadaster en voertuigen bij de RDW) zijn zodanig van economische waarde dat ze in registers worden vastgelegd. Van onroerende zaken wordt bovendien de waarde bijgehouden in de basisregistratie voor de Waardering Onroerende Zaken (WOZ). Ruimtelijke objecten worden vastgelegd in de Basis Registratie Topografie (1:10.000 – TOP10), ‘verblijfsobjecten’

in de gemeentelijke Basisregistraties Adressen en Gebouwen (BAG), objecten met een oorsprong in de Grootschalige Basis Kaart voor Nederland (GBKN) in de Basisregistratie Grootschalige Topografie (BGT). Voor de ondergrond is er de Basis Registratie Ondergrond (BRO). De belastingdienst legt de Basis Registratie Inkomens (BRI) vast en de Basisregistratie Lonen, Arbeidsverhoudingen en Uitkeringsverhoudingen (BLAU) wordt beheerd door het UWV.

Figuur 1 - Samenhang tussen de verschillende basisregistraties. Groen geeft aan wat begin 2013 al is gerealiseerd, geel geeft aan wat nog wordt gebouwd.

277

Figuur 1 geeft aan hoe deze basisregistraties onderling zijn gerelateerd [1]. Groen geeft aan wat begin 2013 al is gerealiseerd, geel geeft aan wat nog wordt gebouwd. Overheidsorganisaties zijn verplicht gebruik te maken van de in deze basisregistraties vastgelegde gegevens. Dat betekent, dat de beheerders daarvan – de bronhouders – verplicht zijn deze gegevens beschikbaar te stellen. Momenteel worden de gegevens tussen de diverse overheidspartijen gedeeld door een complex stelsel van infrastructurele voorzieningen, zogenaamde digikoppelingen, digimeldingen e.d.. De begroting van Logius, de organisatie, die hiervoor verantwoordelijk is, bedroeg 59 miljoen in 2010 en 44 miljoen in 2011 [5]. De voorzieningen bestaan meestal uit een one size fits all voorziening (soms twee), waarvan iedere overheidsinstelling min of meer gedwongen gebruik moet maken. De afnemers zijn vaak ontevreden over de verhouding kosten baten van deze voorzieningen. Bovendien duurt het doorvoeren van veranderingen onaanvaardbaar lang. Tenslotte kunnen veel organisaties en/of applicaties niet uit de voeten met de voorzieningen. Belangrijker probleem is echter, dat de Basisregistraties slechts een fractie van de door de overheid beheerde gegevens omvat. Bovendien ontstaat er steeds meer vraag van buiten de

overheid naar toegang van de in de basisregistraties vastgelegde gegevens, bijvoorbeeld als gevolg van weten regelgeving. Een zeer bekend voorbeeld is de vraag van woningbouwcorporaties naar het belastbaar inkomen van huurders in verband met de huurverhoging voor scheefwoners. Voor (roerende en onroerende) zaken met economische waarde is het van belang zeker te weten dat degenen met wie je zaken doet daadwerkelijk de eigenaar is. De in dit boek beschreven Huiskluis is een ander voorbeeld, waarbij publieke en private gegevens worden samengevoegd tot een voor veel partijen zinvolle toepassing.

Business case voor (basis)registraties met Linked Open Data De business case voor een stelsel van basisregistraties met Linked Open data is gemakkelijk te maken. Bij Linked Open Data voldoet een veilige en robuuste architectuur voor het delen van data, waarbij gebruik kan worden gemaakt van bestaande semantischweb technieken. Niet langer zijn de infrastructurele voorzieningen van Logius nodig, die tot nu toe in het stelsel voor basisregistraties worden gebruikt om data ‘rond te pompen’ tussen overheidsorganisaties en andere gerechtigden. Dat bespaart tientallen miljoenen op jaarbasis.

Figuur 2 Semantische kern stelsel van basisregistraties

Maar de voordelen beperken zich niet alleen tot de distributie van gegevens. Rond de semantische kern [8] die de samenhang tussen de registraties definieert kan iedere registratie zijn eigen ontologie definiëren en publiceren. In zo’n ontologie wordt de samenhang van alle begrippen binnen de registratie vastgelegd. Dit maakt een federatief beheer van alle registraties op zich mogelijk. Alleen de structuur van de samenhang (de semantische kern) hoeft centraal te worden beheerd. Bovendien kan iedere overheidsorganisatie op deze manier ook méér gegevens publiceren dan is vastgelegd in de wetgeving rond de basisregistraties. Het is bekend dat bijvoorbeeld gemeenten en provincies véél meer gegevens kunnen en willen delen dan zij wettelijk verplicht zijn.

Op het niveau van de data zelf kan iedereen zelf zijn eigen samenhang vaststellen. Zo kan een formele landelijk voorziening van de BAG aangeven dat een pand niet meer geschikt is om in te wonen, kan een gemeente vaststellen dat er toch iemand (illegaal) woont en kan de belastingdienst concluderen dat dit een meerpersoonshuishouden betreft. Voor zover niet strijdig met privacy kan dit soort data worden gedeeld tussen overheden en/of met de buitenwereld. Daardoor wordt data betrouwbaarder. Ook relaties tussen registraties kunnen worden gedeeld. Op die manier weten bijvoorbeeld gemeenten en belastingdienst welke WOZ waarde bij welke onroerende zaak en bij welk adres hoort, ofwel hoe de WOZ, BRK

279

en BAG zijn gekoppeld. Als het niet klopt dan reageert de belastingplichtige immers wel. Een dergelijke simpele koppeling is goed genoeg voor degenen die er belang bij hebben. Het gebruik van Linked Open data bij stelsel van basisregistraties leidt dus niet alleen tot lagere kosten maar ook nog eens tot méér flexibiliteit voor bronhouders en afnemers, met andere woorden: meer voor minder geld. De combinatie lage kosten en minder centraal beheer leidt bovendien tot het publiceren van meer gegevens, met andere woorden: meer transparantie. Hierdoor heeft het ook een politieke appeal: soberheid en transparantie zijn immers de drijvende krachten momenteel.

Stelsel van basisregistraties en Linked Open Data in de huidige praktijk De nieuwe stelselcatalogus is een mooi voorbeeld waarin metadata van basisregistraties als Linked Open Data is vastgelegd. Dit is een belangrijke eerste stap om data te kunnen verbinden. Het Kadaster heeft de BRK geheel gedefinieerd als semantisch netwerk, inclusief de link naar wetgeving, die ook op het punt staat te worden ontsloten als Linked Open Data. Zo kan de stelselcatalogus voor de betekenis van de BRK data doorlinken naar de semantische definities van het Kadaster, waardoor extra context wordt toegevoegd, terwijl die

op zijn beurt doorlinkt naar de betreffende bron in de wetgeving. Zo ontstaat maximaal inzicht in de betekenis en achtergrond van deze registratie. Een logische volgende stap is het als Linked Open Data publiceren van de data zelf, tenminste waar dit zonder privacybedreigingen kan. Voor geografische data is dat al beleid en in het kader van Inspire in Europees verband vastgelegd. Ook bijvoorbeeld het ministerie van I&M heeft expliciet als beleid al haar basisregistratiedata uiterlijk 1 januari 2015 als |Linked Open Data beschikbaar te hebben, mits er geen privacybelemmeringen zijn. De concept uri-strategie geeft houvast voor het toekennen de door Inspire gevraagde namespaces voor geografische registraties, bijvoorbeeld http://bag.gov.nl voor de landelijke voorziening voor de BAG. Consequent doorvoeren van deze strategie impliceert ook het gebruik van ‘resolvable uri’s’ voor Nen3610 id’s voor geografische data. Dergelijke id’s moeten persistent zijn en kunnen dus maar beter direct goed worden toegekend. Daarmee zou het concept van Linked Open Data voor geografische data zo maar eens op korte termijn een flinke vlucht kunnen nemen.

280

Informatie integratie met Linked Open Data Een keuze voor Linked Open Data voor het delen van gegevens binnen de buiten de overheid zal leiden tot een andere soort informatie architectuur voor overheidsorganisaties. Interoperabiliteit is voor de overheid het grootste probleem. Interoperabiliteit staat centraal in referentie architecturen zoals de NORA en de GEMMA. Momenteel worden deze interoperabiliteitsproblemen vooral infrastructureel opgelost: door het koppelen van applicaties. Een grote gemeente besteedt tientallen miljoenen per jaar om gegevens, die vastgelegd zijn in de ene applicatie, te kopiëren naar andere applicaties, zodat deze gebruik kunnen maken van deze gegevens. De semantische interoperabiliteit wordt binnen die koppeling opgelost. Dit is niet alleen initieel kostbaar, maar leidt ook tot steeds grotere beheers- en onderhoudskosten. Ook voor uitvoerings-organisaties zijn infrastructurele koppelingen miljoenenprojecten. Van de te kopiëren gegevens kan 70 tot 80% geautomatiseerd worden overgenomen, 20 tot 30% is arbeidsintensief uitzoekwerk van enkele miljoenen gevallen. Ook wanneer de infrastructurele koppelingen met behulp van webservices zijn geïmplementeerd, doen zich problemen voor. Webservices zijn erg ge-

schikt voor het verwerken van transacties, maar minder om het probleem van data integratie op te lossen [3]. In de praktijk worden binnen de overheid duizenden XML-schema’s gebruikt, al dan niet conform de StUF-standaard. Al deze schema´s kunnen – net als traditionele applicaties – verschillende definities hanteren van min of meer overlappende gegevens. Als deze in de loop van de tijd veranderen, doet zich voor beheer en onderhoud van XML-schema’s een vergelijkbaar data integratie probleem als met traditionele applicaties voor, dat iedere organisatie voor zich moet zien op te lossen. Door het gebruik van Linked Data zijn infrastructurele koppelingen tussen applicaties niet meer nodig. Met Linked Data kan de toepassingen direct naar de gezochte gegevens worden verwezen. Data hoeft niet steeds te worden gekopieerd naar een eigen database voor de toepassing omdat ze via een uri (unique resource identifier) beschikbaar is op het web. Dit impliceert dat de uri-strategie voor het stelsel uit moet gaan van ‘resolvable uri’s’, dat wil zeggen uri’s die direct naar de data zelf leiden. Gegevens zijn niet langer onverbrekelijk verbonden met de context van hun applicatie, maar dragen zelf hun betekenis bij zich in de vorm van semantiek en metadata. Deze semantiek wordt niet meer vastge-

281

legd in databases en beschreven in losse documenten, maar met behulp van gestandaardiseerde vocabulaires die het mogelijk maken data door computers te laten interpreteren en te linken. Metadata betreft onder andere zaken als kwaliteit, volledigheid en tijdsaspecten zoals wanneer data is vastgelegd en wanneer en na welke kwaliteitscontroles ze beschikbaar is gesteld voor derden. Voor de aanbieder is een goed ingericht beheer van deze metadata (metadatamanagement) een absolute voorwaarde om data als Linked Open Data te kunnen publiceren. De afnemer is niet langer afhankelijk van (de techniek van) de aanbieder om de gegevens te verkrijgen. Wanneer de gegevens met voldoende semantiek worden gepubliceerd kan de afnemer de gegevens ook verantwoord gebruiken. Gegevens krijgen een geheel eigen, centrale plek in deze architectuur [4]. Een organisatie kan een compleet logisch gegevensmodel voor haar eigen processen samenstellen op basis van een combinatie van eigen en externe gegevens. De gegevens in dit model kunnen afkomstig zijn uit de eigen applicaties en databases, maar het kunnen ook gegevens zijn waarover de organisatie niet zelf beschikt en die via Linked (Open) Data van (betrouwbare) derden worden verkregen. Andersom moet een organisatie ook

steeds explicieter onderzoeken welke eigen gegevens zij via welke techniek beschikbaar wil stellen aan processen buiten de eigen organisatie. (Al dan niet open; al dan niet linked.) Zijn deze keuzes gemaakt, dan moet de organisatie investeren in de kwaliteit van de aangeboden gegevens. Voor een individuele medewerker heeft het natuurlijk wel gevolgen of deze een lijstje in Excel bijhoudt voor eigen gebruik, of dat zijn of haar gegevens juist, volledig en actueel gepubliceerd dienen te worden en bovendien door enkele veelgebruikte apps worden benut. Aangezien de organisatie op foute gegevens wordt aangesproken, zal ook de organisatie als geheel zich voor de kwaliteit van de gepubliceerde gegevens verantwoordelijk moeten voelen.

Veiligheid en privacy Het credo van de overheid is: open wat open kan, gesloten en veilig waar privacy moet worden geborgd. In de privacywetgeving wordt hiervoor het principe van â&#x20AC;&#x2DC;doelbindingâ&#x20AC;&#x2122; gebruikt. Doelbinding is het principe dat iemand (persoon of organisatie) alleen informatie mag vragen, opslaan, gebruiken en delen ten behoeve van welbepaalde, uitdrukkelijk omschreven en gerechtvaardigde doeleinden [6]. Dat betekent dat informatie die direct of indirect herleidbaar is tot personen alleen mag worden verstrekt voor een bepaald welomschreven doel. Omdat bij Linked Open Data de data wordt

282

losgekoppeld van de toepassing, is dit doel bij het aanbieden van data niet bij voorbaat welomschreven. Om die reden kan het verstrekken van Linked Open Data tot gevoelige privacy kwesties leiden. De eigenaar van de gegevens is namelijk verantwoordelijk voor het juiste gebruik ervan, ook als dat gebeurt in toepassingen waar hij niet eens weet van heeft. Privacy issues kunnen gedeeltelijk omzeild worden door privacy gevoelige gegevens niet open beschikbaar te stellen, maar in een strikt beveiligde omgeving. De relatie tussen deze beveiligde, persoonlijke data en open data kan worden gelegd middels verwijsindexen die hiertussen de link leggen. Toegang tot beveiligde data kan worden geregeld via authenticatieservices als digid en E-herkenning. Autorisatie kan bestaan uit een combinatie van doel en identiteit van de afnemer. Waar nodig kan de sterkte van deze authenticatieservices worden verbeterd. Langs dit soort wegen kan privacy in principe maximaal worden geborgd. Daarnaast is het ‘huiskluis’ concept interessant. Dit concept geeft de eigenaar van persoonlijke en/of privacygevoelige data zelf de regie over deze data. Dit concept kan ook worden gegeneraliseerd naar een MijnOverheid 2.0, waar de overheid haar gegevens deelt met de burger en de burger persoonlijke dingen, tot

aan bijvoorbeeld ingevulde belastingaanslagen, veilig kan bewaren. Ook biedt dit concept van delen van data van de burger met door de burger zelf te bepalen organisaties nieuwe mogelijkheden voor toepassingen als het elektronisch patiëntendossier. In beide oplossingen is er echter geen sprake meer van open data. Veiligheid en privacy in de context van Linked Open Data zal daarom voorlopig wel een issue blijven. Een aanbieder van privacy gevoelige gegevens doet er goed aan de risico’s en de technische mogelijkheden goed tegen elkaar af te wegen.

Conclusie Linked Open Data draagt hoe dan ook bij aan de twee belangrijkste politieke drijfveren van dit moment: transparantie en soberheid. Linked Data is een geschiktere techniek om de gegevens van het stelsel van basisregistraties mee te ontsluiten voor overheidsorganisaties dan de huidige infrastructurele koppelingen, al dan niet met web services. Al deze koppelingen leiden namelijk nog steeds tot grote problemen voor data integratie binnen overheidsorganisaties. Het grote voordeel van Linked Data is dat het een oplossing biedt voor zowel technische als semantische interoperabiliteitsproblemen.

283

Het aanbieden van Linked Open Data brengt wel nieuwe verantwoordelijkheden met zich mee voor de aanbiedende partij. In de eerste plaats zal deze moeten investeren in de kwaliteit (juist, volledig, actueel) van de gegevens. Maar ook wordt de aanbiedende partij in het kader van de privacy wetgeving verantwoordelijk gehouden voor het gebruik van haar gegevens voor toepassingen waar zij niet eens weet van heeft. Dit leidt tot privacy issues, die wel technisch omzeild kunnen worden, maar dan is er geen sprake meer van open data. Voorlopig zal veiligheid en privacy daarom nog wel een issue blijven. De praktijk moet nog uitwijzen hoe de links worden onderhouden en hoe, zeker in het stelsel van basisregistraties wordt geborgd dat deze betrouwbaar blijven. Als eerste registratie die in dit nieuwe paradigma wordt opgepakt kan de informatievoorziening omgevingswet wel eens heel goed domein zijn. Daar zit relatief veel ruimtelijke informatie in en minder privacy en bestaat nog ruimte voor de oplossingsrichting.

Referenties [1] Interactieve Stelselplaat: http://bit.ly/XJPGHB [2] http://bit.ly/128H8w3 [3] Frischmuth, P. et al., Linked Data in Enterprise Information Integration, Semantic Web 0 (2012) 1-0. [4] Rijn van, Ria (2013). Itâ&#x20AC;&#x2122;s the Data, Stupid! Informatie, 55/1, pp 18-24. [5] http://www.logius.nl/organisatie/ jaaroverzicht/ [6] http://www.noraonline.nl/wiki/ Doelbinding [7] http://www.whitehouse.gov/open [8] http://www.wikixl.nl/wiki/ ictu/index.php/ Component_semantisch_model [9] http://ec.europa.eu/ digital-agenda/en/open-data-0 [10] http://bit.ly/ot1l9H

D5 - Het contextdilemma hanteren met Linked Data Auteurs

Marcel van Mackelenbergh (Belastingdienst) Rinke Hoekstra (Vrije Universiteit) Inleiding Hergebruik van data kent een context-probleem: data betekent niet hetzelfde in elke context. Als mensen data creëren dan hebben ze daarmee een doel voor ogen. Ook hebben mensen een beeld van de wereld. Data bevatten impliciet betekenis die voortkomt uit dat doel en uit dat beeld. Geen rekening houden met deze impliciete betekenis veroorzaakt belangrijke fouten in de uitvoering. Linked Data erkent dat data een context hebben en biedt een manier om hier mee om te gaan. Linked Data gaat uit van de ‘dingen’ die bestaan, gerepresenteerd als zogenaamde resources. Iedere resource wordt aangeduid middels een identifier (URI). Doordat partijen dezelfde URI gebruiken voor het aanduiden van een resource, zijn ze in staat om data over die resource met elkaar uit te wisselen. Een afnemer van data ziet op deze manier welke data een leverancier vastlegt over een bepaalde resource. De afnemer is echter ook altijd vrij om zijn eigen data in te zetten. Hierdoor ontstaat maximaal

hergebruik met de flexibiliteit die de afnemer nodig heeft voor zijn eigen context. De URI van resources geeft een indicatie van de context waarin data is geproduceerd. Een URI binnen het domein ‘belastingdienst.nl’ heeft duidelijk een andere status dan URIs binnen ‘vu.nl’. Het domein representeert de procudent van de data. Dit is echter niet voldoende, want het reflecteert het beeld van de data slechts ten dele, en het doel helemaal niet. Er is dus een nieuw soort data nodig in dit web van data. Er bestaat nu al aandacht voor de herkomst, de zogenaamde provenance van data. Provenance data beschrijven onder andere hoe, wanneer, door wie en waarom data zijn gemaakt. Deze provenance is relevant omdat een afnemer van data hiermee een inschatting kan maken of de data (her) bruikbaar zijn voor zijn eigen context. In dit artikel stellen wij voor om naast de provenance ook de bruikbaarheid (usability) van data vast te leggen. Bruikbaarheid van data geeft aan in welke contexten data heeft geleid tot een succesvolle uitvoering.

Interoperabiliteit Interoperabiliteit tussen systemen betekent dat er gebruik gemaakt wordt van data die niet voor dat gebruik (een systeem) zijn gecre-

285

ëerd. Data wordt altijd gecreëerd ten behoeve van een bepaald gebruik(sdoel). Bijvoorbeeld voor het afdragen van inkomstenbelasting. De data heeft een bepaalde betekenis. Bij interoperabiliteit willen we informatie die vergaard is voor een bepaald gebruik, inzetten voor een ander gebruik. Partijen kunnen de behoefte hebben om samen te werken vanuit één enkele bron van data. Voordelen van het werken vanuit één enkele bron zijn onder andere dat de samenwerkende partijen: ll werken vanuit dezelfde waarheid, er zijn geen tegenstrijdigheden ll minder werken met verouderde informatie ll samen werken aan het verhogen van de kwaliteit van de data ll slechts op één plaats data verzamelen en bijwerken: efficiëntie

Master data management Master data management (MDM) heeft tot doel om tot een overkoepelend datamodel te komen (Bonnet, 2010). Een overkoepelend datamodel stelt partijen in staat om te werken met één bron. MDM wordt ook wel aangeduid met canonical modelling. Master data management wordt onder andere gehanteerd bij ketenautomatisering. Voor MDM moeten partijen in standaardisatietrajecten samenwerken om te komen tot overeenstemming

over de betekenis in het datamodel. Indien partijen verschillend denken over een betekenis dan heeft de samenwerking grofweg drie mogelijkheden: 1. de betekenis algemener (ruimer) definiëren 2. één of meer partijen vragen om te werken met een veranderde betekenis (standaardisatie) 3. de eigen data vertalen naar de master data Het gevolg van 1. Is dat er op het niveau van de master data minder informatie is. Er kan hierdoor op het niveau van MDM minder informatie uitgewisseld worden. Het gevolg van 2. is dat de partijen die werken met een veranderde betekenis,vaak minder in staat zijn om hun doelen te bereiken. Met 3. wordt de betekenis van de data vaak verwrongen: de masterdata geven niet goed weer wat er met de oorspronkelijke de data bedoeld was.

Open World Assumption De Open World Assumption zegt dat je alleen impliciet kunt stellen ‘dat je iets niet weet’ maar dat je niet kunt stellen ‘dat iets niet bestaat’ (Allemang & Handler, 2011). Deze stelling maakt het beeld op data zoveel anders. Namelijk door te stellen dat je het niet weet, laat je open dat er misschien iemand anders is, die het wel weet. Welke databron de informatie bevat, is van tevoren niet bekend. Een

286

gevolg van deze veronderstelling is dat een ontwerper van Linked Data zich richt op het vinden van data in plaats van het zelf creëren en beheren van data. Vandaag zien we dit al voor de informatie die te vinden is op het internet: op heel veel vragen heeft iemand een antwoord en is ook nog zo aardig geweest om dat antwoord op het internet te publiceren. Het idee van Linked Data is dat dit ook met data gaat gebeuren. Niet langer meer zelf de data creëren en beheren maar linken naar de databron waar deze data reeds bestaat en wordt onderhouden.

Anybody can say Anything about Anything (AAA) Een methodologie gestoeld op Linked Data hanteert een andere werkwijze dan MDM. Linked Data vereist niet dat er overeenstemming bestaat over de betekenis in het datamodel. Linked Data biedt volledige vrijheid in het bestaan van verschillen tussen de betekenissen. Linked Data heeft niet tot doel om tot een consistent geheel van betekenis te komen. Binnen Linked Data mogen schijnbare tegenstrijdigheden voorkomen: Anybody can say Anything about Anything. (Charaudeau, 2011)

Linked Data Linked Data is, net zoals Master Data Management, gericht op het hergebruiken van data van anderen. De focus van Linked Data richt zich echter op de sleutels (identifiers), niet op een datamodel. Met Linked Data richt de ontwerper zich op wat er bestaat. Daarbij vraagt de ontwerper zich af hoe hij van de dingen die bestaan, een aanduiding kan maken. Een aanduiding wordt in de informatiekunde een sleutel of identifier genoemd. Bij kinderen is dit ‘vaststellen wat bestaat’ nog goed te zien als een aparte mentale handeling (Vygotski, 1933). Een ouder en een kind wijzen naar dingen en geven daar een naam aan. Al wijzend herhalen beiden elkaars uitroepen, bijvoorbeeld ‘poes’ of ‘auto’. Dat allereerste stapje is nodig voor kennisoverdracht: als er een sleutel is, kunnen mensen het met elkaar hebben over ‘de dingen’ ook als die dingen niet aanwezig zijn. Dat is precies hetgeen gebeurt bij Linked Data. Partijen wijzen naar dingen en geven er een sleutel (URI) aan. Via deze sleutels zijn partijen in staat met elkaar te praten. De ontwerper kijkt daarom of anderen reeds sleutels hebben voor de dingen die hij wil aanduiden. Als de ontwerper een bekende sleutel gebruikt, dan kan hij zijn data eenvoudig koppelen met die van anderen en andersom. Sleutels vormen de infrastructuur waarlangs communicatie plaatsvindt.

287

Interoperabiliteit met Linked Data Op het moment dat de ontwerper de data van andere partijen wil gaan gebruiken, moet de ontwerper beslissen of de data van de ander voldoet voor het doel waarvoor hij de data wil gaan inzetten. Voor het creĂŤren van interoperabiliteit denkt de ontwerper aan: 1. compatibiliteit: kan de structuur van de databron a. gelezen worden? (syntax) b. tot op bepaalde hoogte begrepen worden? (semantiek) 2. consistentie: wanneer wijkt de betekenis volgens de databron af van de betekenis die men er zelf aan hecht? Op ieder van deze gebieden kan de ontwerper zijn eisen stellen. De ontwerper kan: ll iedere structuur van data accepteren (NoSQL) of een hoge validatie (schema) vereisen ll de data oppervlakkig begrijpen (bijv. alleen de kolomnamen) of een diepgaande studie doen naar de manier van denken en de drijfveren van de beheerder van de databron ll de betekenisverschillen (die voor de ontwerper afwijkingen zijn) toestaan of ieder verschil afkeuren ll Een belangrijk verschil tussen Master Data Management en Linked Data is dat bij MDM er vooral vooraf streng wordt vast-

gehouden aan eisen. Bij Linked Data worden structuren meestal geaccepteerd (NoSQL) en wordt van tevoren niet te streng gekeken naar mogelijke betekenisverschillen. Bij Linked Data wordt veel meer achteraf gecompenseerd voor afwijkingen in compatibiliteit en/of consistentie. Achteraf compenseren is mogelijk bij Linked Data omdat er andere databronnen zijn die kunnen compenseren voor de tekortkomingen van de gebruikte databron. â&#x20AC;&#x2DC;Beter iets dan nietsâ&#x20AC;&#x2122; is het motto bij Linked Data. Hierdoor ontwikkelt men Linked Data sneller en met meer, maar soms wat onnauwkeurig resultaat. Deze onnauwkeurigheid moet tijdens de uitvoering gecompenseerd worden. Het kunnen koppelen staat voorop bij Linked Data. Onvolkomenheden worden op een later moment ondervangen.

Samenwerking Linked Data gaat op een geheel andere manier om met samenwerking dan Master Data Management. Master Data Management vormt een gesloten systeem waar sterk wordt vastgehouden aan mogelijke verschillen in compatibiliteit en consistentie. Linked Data vormt een open systeem waarbij alles er op gericht is dat partijen elkaars data kunnen koppelen. Over mogelijke verschillen in compatibiliteit en consistentie wordt

288

van tevoren niet te moeilijk gedaan en gaat men ervan uit dat men kan compenseren voor een gebrek aan compatibiliteit en consistentie indien de uitvoering daar om vraagt. Linked Data maakt de verwarring over betekenis een stuk minder groot door zich in eerste instantie te richten op wat is, de waarneming zo men wil. Dat wat is, wordt aangeduid met een URI, de identifier binnen Linked Data.

Metadata Het hergebruiken van data moet ondersteund worden. Degene die de data wil hergebruiken, heeft behoefte aan informatie over de data. ‘Wanneer is de data gemaakt?’, ‘Wie maakte de data?’ en ‘Voor welke toepassing is de data gemaakt?’ zijn een aantal vragen waarop de ontwerper antwoord probeert te krijgen. De leverancier geeft deze informatie middels zogenaamde metadata: data over de data. De metadata die het ontstaan van de data beschrijven, worden ook wel provenance data genoemd (Freire e.a. 2008). Provenance komt van het franse provenir wat ‘vandaan komen’ betekent. Het kan voor de hergebruiker ook interessant zijn om te leren in welke situaties de data succesvol door iemand is toegepast. Deze data geeft de bruikbaarheid (usability) van data

weer. Deze bruikbaarheid-data kan bijvoorbeeld een antwoord geven op de vragen: ‘Voor welk doel is de data toegepast?’, ‘Wat beschouwt men een succesvolle toepassing? en ‘Op welke wijze stelt men vast dat het doel werd behaald?’ Data die de bruikbaarheid aangeeft, kan ook voor Linked Data van grote waarde zijn. Deze data zegt veel over de kwaliteit van de data voor die toepassing. Deze data kan een goede voorspeller zijn voor succesvolle toepassing van de data binnen een andere toepassing. Voor Linked Data is recentelijk het PROV vocabulaire gestandaardiseerd door het W3C (Zie http://www.w3.org/TR/provoverview). Dit vocabulair stelt ons in staat om provenance metadata in Linked Data uit te drukken.

Usability als a priori Provenance Op dezelfde wijze als provenance metadata een indicatie geeft van de betrouwbaarheid en bruikbaarheid van data, stellen wij voor om bij de productie van data tevens het doel van de data expliciet te maken. Een voorbeeld waarbij expliciete usability metadata nuttig kan zijn is de postcode. Postcodes zijn ooit in het leven geroepen om de distributie van post binnen Nederland efficienter te laten verlopen. Echter, zij worden steeds vaker gebruikt als algemene, fijnmazige geografische indeling. Dit kan leiden tot bijvoorbeeld de ver-

289

onderstelling dat alle objecten in de BAG die een straat en huisnummer hebben, ook een postcode hebben. Dit is niet het geval. Gemeenten staat het vrij om objecten zoals transformatorhuisjes van een huisnummer te voorzien; zonder brievenbus krijgt het huisje echter geen postcode toegewezen. Expliciete usability metadata stelt de producent van data in de gelegenheid om tot op zekere hoogte controle te houden over het gebruik van de data door derden, overheidsinstellingen danwel bedrijven of particulieren. Zo zou bijvoorbeeld aansprakelijkheid kunnen worden afgewezen voor conclusies die gebaseerd zijn op gebruik van de data dat afwijkt van het voorgeschreven gebruik. Vergt dit dan verdergaande specificatie van de mogelijke operaties op de data? Niet noodzakelijkerwijs. Een organisatie die goed zicht heeft op haar taken, daaraan gekoppelde interne bedrijfsprocessen, en dus op de intern geproduceerde provenance informatie, kan deze informatie eenvoudig inzetten voor het aangeven van toegestane operaties. In het geval van overheidsinstellingen zijn deze taken veelal verankerd in wet en regelgeving. Wanneer taken uniek identificeerbaar zijn door middel van URIs, kan tevens compatibiliteit tussen de taken expliciet gemaakt worden.

Discussie In de voorgaande secties beschrijven wij de aspecten die in zijn algemeenheid gelden voor het bruikbaar uitwisselen van data tussen organisaties (data interoperabiliteit). Data is altijd geproduceerd binnen een context, met een bepaald beeld van de wereld en met een doel: de data wordt geproduceerd voor het uitvoeren van een specifieke (overheids-) taak. Linked Data is een uitermate flexibel middel voor het verhogen van interoperabiliteit door het uitwisselen en hergebruiken van globaal uniek geidentificeerde data items (resources). Provenance metadata, uitgedrukt als Linked Data, geeft een indicatie van de processen die ten grondslag lagen aan de productie van de data. Hierdoor ontstaat een beeld van de kwaliteit en betrouwbaarheid van data. Provenance metadata kan gebruikt worden om een inschatting te maken van de bruikbaarheid. Om bruikbaarheid voor bepaalde doeleinden vast te stellen, is echter meer nodig. Op dezelfde wijze als processenworden geidentificeerd in provenance data, kan ook een usability profiel voor Linked Data worden gespecifieerd. Middels een dergelijk profiel geeft de producent van data aan voor welke doeleinden zij de data ter beschikking stelt.

290

Literatuur ll Allemang, Dean & Hendler, James ‘Semantic Web for the Working Ontologist’, 2nd edition, Morgan Kaufmann, 2011ISBN 9780123859655 ll Bonnet, Pierre ‘Master Data Management And Semantic Modeling’ Wiley-ISTE, 2010 ISBN 9781848211827 ll Charaudeau, Patrick ‘Les médias et l’information: l’impossible transparence du discours’ 2ndedition, De Boeck, 2011 ll Freire, Juliana; Koop, David (Eds.) ‘Provenance and Annotation of Data and Processes’ Second International Provenance and Annotation Workshop, IPAW 2008, Salt Lake City, UT, USA, June 1718, 2008 Series: Lecture Notes in Computer Science, Vol. 5272 ll Vygotsky, Lev ‘Play And It’s Role in The Mental Development of The Child’ in Voprosy psikhologii, 1966, No. 6 (vertaald door Catherine Mulholland) eerste publicatie in 1933

D6 - Ontwerp van consistente domein-ontologie hergebruik van bestaande sectorafspraken Auteur

Roel Stap (Data for Use) Veel organisaties in verschillende bedrijfssectoren en toepassingsgebieden zijn vandaag de dag actief in het opstellen en vastleggen van gemeenschappelijke informatieafspraken. Het doel van deze activiteiten is het vergroten van het gemeenschappelijke begrip binnen de sector of het toepassingsgebied, om daarmee de samenwerking tussen organisaties te bevorderen. Voorbeelden hiervan zijn RosettaNet voor supply chain management-, Inspire & OpenGIS voor geo- en IEC CIM voor energiemanagement. Ook in Nederland kennen we vergelijkbare initiatieven zoals SETU voor informatie-uitwisseling tussen organisaties over flexibele arbeid. Met de opkomst van linked data als middel voor organisaties om informatie op een eenduidige wijze te publiceren neemt ook de ontwikkeling van ontologieën een vlucht. Veel organisaties zijn op dit moment zich aan het oriënteren welk voordeel zij van deze nieuwe aanpak hebben en hoe het aansluit bij de bestaande omgeving. Daarbij lopen veel organisaties aan tegen de vraag wat ontologieën zijn en waarom ze vaak nodig zijn om eenduidigheid binnen de sector te blijven borgen. Om aan dit bezwaar

tegemoet te komen en de introductie van linked data te vergemakkelijken, zullen we in dit artikel ingaan op de mogelijkheden die er zijn om specifieke ontologieën te ontwikkelen op basis van bestaande informatiespecificaties in de sector. Door gebruik te maken van bestaande afspraken en standaarden kan de acceptatie van het linked data gedachtegoed worden versneld. Op dit moment ontwikkelen en beheren domeinexperts van verschillende organisaties deze informatieafspraken, veelal georganiseerd in een formeel (gestandaardiseerd) verband. Deze afspraken zijn nu al de basis voor verschillende oplossingen die gerealiseerd worden. Door ook de ontologie ontwikkeling te baseren op deze gemeenschappelijk afspraken sluit deze aan op reeds bestaande werkwijzen en wordt de acceptatie van linked data daarmee vereenvoudigd. Als voorbeeld zullen we in dit artikel een en ander uitleggen aan de hand van het IEC CIM model. Dit is een wereldwijd geaccepteerde informatiestandaard voor de energiesector, uitgedrukt in UML diagrammen. In deze sector is in toenemende mate behoefte om informatie te delen met steeds meer en nieuwe stakeholders. Dit model is ontwikkeld om uitgewisselde informatie consistent te maken en te houden. Zij wordt gebruikt door leveranciers van producten en dien-

292

sten die informatie met elkaar delen binnen het complexe energiesysteem (de keten van opwekking-, transport-, distributie- en handel van energie). Dit model is behalve voor berichtspecificatie en database schema’s ook geschikt om als basis te dienen voor de ontwikkeling van specifieke RDF gebaseerde energieontologieën. In het introductiehoofdstuk hebben we gezien welke rol een ontologie speelt in de publicatie van linked data, we gaan in dit artikel hier niet verder op in. Indien nodig verwijzen we u graag naar deze introductie over RDF en de ontologie.

Ontology Ontology is op dit moment een containerbegrip en kent geen eenduidige definitie [4] en wordt gebruikt om verschillende semantische begrippen te duiden: thesauri (waardelijst), vocabulaire (entitieten-relatie lijst) en ontology voor complexe en/of formele vocabuaires. In sommige gevallen wordt FOAF daarom niet als een ontologie beschouwd maar als vocabulair gezien. Nadere uitleg valt buiten de scope van dit artikel.

Waarom eenduidige onlogieën? Een ontologie speelt een voorname rol bij het betekenisvol publiceren van informatie. Op dit moment zijn er een aantal veel gebruikte ontologieën in omloop die voor algemene toepassingen geschikt zijn. Als voorbeeld kunnen genoemd worden de FOAF ontology om personen en relaties vast te leggen en Good Relations voor het beschijven van online verkochte productinformatie. Het voordeel van deze gemeenschappelijk te gebruiken ontologieën is dat datasets die deze ontologieën gebruiken eenvoudig met elkaar kunnen worden gelinked, en data uit verschillende bronnen een gelijke en eenduidige betekenis krijgen.

Naast de gemeenschappelijk te gebruiken ontologieën is er een ontwikkeling te zien waar voor specifieke toepassingen een ontologie wordt ontwikkeld. Deze ontwikkeling is gericht op bijvoorbeeld het maken van afspraken over betekenis van terminologie en onderlinge relaties op een specifiek terrein. Dit heeft tot gevolg dat er een (wild)groei is aan ontologieën met ‘eigen’ terminologie en relaties. De consequentie hiervan is dat gepubliceerde data wel betekenisvol is, maar dat de gebruikte ‘taal’ weinig wordt gesproken, het is als het ware een beperkt gesproken dialect. Het gevolg hiervan is dat deze datasets niet direct kunnen worden gelinked met andere datasets door het ontbreken van standaard mappingen. Tussen veel gebruikte ontologieën zijn

293

standaard mappingen beschikbaar die dit linken vergemakkelijken. Om te voorkomen dat er binnen een sector verschillende ‘talen’ wordt gesproken en er vele mappingen gemaakt en onderhouden moeten worden, is enige stroomlijning hier wenselijk. Het is echter goed hier op te merken dat deze wenselijk stroomlijning vanuit het linked data perspectief noodzakelijk is. De open gedachten van het Internet is ook op de ontologie van toepassing; iedereen mag van alles op het internet beweren, ook in zijn eigen ontologie. Het effect van de beweringen in een veel gebruikte ontologie zal door de brede acceptatie zeker groter zijn. Om te zorgen voor een georganiseerde ontologieontwikkeling binnen een sector of toepassingsgebied kunnen we gebruik maken van bestaande informatieafspraken en specificaties. In veel sectoren spelen deze afspraken al een belangrijke rol als het gaat om opslag en uitwisseling van data. Mits de specificaties voldoen aan bepaalde voorwaarden, kunnen zij ook dienen als basis voor de ontwikkeling van ontologieën. Het voordeel van deze benadering is dat de acceptatie van ontologieën wordt vergroot door gebruik te maken van afspraken die binnen de sector zijn gemaakt. In de energiesector zijn deze informatieafspraken vastgelegd in een IEC informatiestandaard (IEC CIM). Dit is één groot informatiemodel waar ver-

schillende subdomeinen zijn onderscheiden. Het model definieert per subdomein classes, eigenschappen en relaties die het subdomein nader specificeren. Op deze wijze is binnen de energiesector overeenstemming vastgelegd hoe ‘dingen’ worden benoemd en welke eigenschappen en relaties relevant zijn. Op basis van deze afspraken kunnen schema’s voor databases, berichten en ontologieën voor linked data worden gedefinieerd die allen gebruik maken van dezelfde terminologie en definities. Ook wanneer er verschillende ontologieën worden ontwikkeld vanuit deze gemeenschappelijke specificatie, wordt onderlinge interoperabiliteit tussen ontologieën gewaarborgd. Binnen sectoren zoals de energiesector is dit van groot belang, de sector is zo groot en complex dat vele toepassingsontologieen zullen worden ontwikkeld. Het gebruik van een gemeenschappelijke informatieafspraak die als basis voor de ontologieën dient, versnelt deze ontwikkeling en vergroot de acceptatie van de linked data.

Relatie UML en RDF Informatieafspraken en standaarden zijn vaak vastgelegd met behulp van UML. Dit is een veelgebruikt modelleringstaal waarmee onder andere klassendiagrammen (Entity-Relation diagram) worden vastgelegd. Dit diagram is een veelgebruikt middel om (statische) metadata en metarelaties vast te leggen. De UML diagrammen

294

zijn grafische diagrammen die door een modelleur worden gemaakt. Ze zijn daarom niet direct geschikt om te worden toegepast in tekstgebaseerde ontologieën. Het grafisch georiënteerde model zal allereerst vertaald moeten worden naar een taal die de betekenis van het UML-diagram tekstueel representeert. Hiervoor is XMI (XML metadata interchange) ontwikkeld en wordt onder andere gebruikt om het UML model te transformeren naar een RDF representatie. Op dit moment zijn veel UML modelleringtools in staat om XMI te exporteren die vervolgens (eventueel met een tussenstap) in ontologie ontwikkel tools kunnen worden geïmporteerd. Door de conceptuele verschillen die er tussen UML en RDF zijn (objectorientatie vs verzamelingen-orientatie), worden er door de tools bij het interpreteren van de UML_XMI informatie keuzes gemaakt hoe te transformeren naar RDF. Het voert hier te ver om er dieper op in te gaan. In voorkomende gevallen is het goed om de transformatie goed te onderzoeken en na te gaan welke tools en XMI-versies geschikt zijn om in het betreffende domein te gebruiken.

Model matching Hoe groot en omvattend een model ook is, op de randen zal aansluiting en overlap plaats vinden met andere modellen uit andere sectoren en/ of toepassingsgebieden. We hebben gezien dat de UML modellen spe-

cificaties bevatten waarvan ontologieën kunnen worden afgeleidt. In gemeenschappelijke ontologieën zoals OWL worden statements (predicate) gedefinieerd waarmee semantische overeenkomsten en verschillen tussen klassen en relaties kunnen worden vastgelegd. Wanneer we model interoperabiliteit willen vastleggen is de vraag waar we dit doen. Op specificatie niveau zal een en ander vastgelegd moeten worden door domeinexperts, waarna de transformatie naar semantische RDF-ontologieen de linked data oplossingen realiseren. Opmerking: in dit artikel beschouwen we OWL als een ontologie. OWL is een zogenaamde fomele of foundational ontology en wordt in het algemeen niet als een ‘normale’ ontologie beschouwd. Algemene aanpak zal gebaseerd zijn om op de koppelvlakken in de betreffende modellen de semantische overeenkomsten en verschillen vast te leggen (werk voor domeinexperts). Door de overeenkomsten en verschillen in een nieuw ‘verzoend’ model vast te leggen wordt de verbinding gemaakt met de betreffende domeinen, en wordt de basis gelegd voor een gemeenschappelijke specificatie tussen de sectoren. Dit hoeft niet noodzakelijk te leiden tot gelijke termen en definities, maar kan resulte-

295

ren in het vinden en specificeren van synonieme entiteiten die onderdeel zijn van de gemeenschappelijke ontologie. Aan de hand van twee voorbeelden zal de aanpak op hoofdlijnen worden getoond. Het eerste voorbeeld gaat uit van twee synonieme entiteiten in beide modellen maar waarvoor verschillende termen gehanteerd worden. De tweede benadering gaat uit van twee entiteiten die een gedeeltelijke semantische overlap hebben. Hier zullen we op model niveau eerst de overeenkomsten en verschillen specificeren alvorens over te gaan tot de ontologie transformatie. Het zijn twee voorbeelden hoe de transformatie aangepakt kan worden, in de praktijk zullen ook andere methoden voor kunnen komen.

Semantische overlap, verschillende terminologie In figuur 1 is een voorbeeld gegeven van een transformatie waarbij op UML model niveau sprake is van semantische overeenkomst tussen de entiteiten, maar waarin de gebruikte terminologie verschilt. Het voorbeeld laat zien hoe het X-model en IEC CIM model verzoend kunnen worden op het X:Adres en CIM:Locatie entiteit. Deze benadering gaat uit van de veronderstelling dat beide termen semantisch gelijk zijn. De vertaling van het UML model naar RDF representatie is redelijk eenduidig. De transformatie maakt gebruikt van aanpasbare transformatie regels. De naam van het UML entiteit wordt gebruikt als RDF klassenaam en de UML attribuutnaam is de basis voor

Figuur 1 - UML model naar ontologietransformatie - gelijke semantiek, verschillende terminologie

296

de RDF property naam (hier met prefix ‘has’). Op deze wijze krijgen we uit beide modellen een RDF ontologie die we met een verzoeningsontologie aan elkaar kunnen linked. De relaties worden eenmalig vastgelegd in een verzoeningsontologie waarin we met de OWL predicates equivalentClass en equivalenetProperty de verschillende klassen semantisch kunnen linked (ontologie-verzoening). We drukken hiermee in de ontologie de overeenkomst tussen de klassen en de properties uit en hiermee worden termen uitwisselbaar tussen de verschillende ontologieën. Om de interoperabiliteit tussen de voorbeeldontologieen te vergroten, is het raadzaam om bij het publiceren van data die gebruik maakt van een van de ontologieën de verzoeningsontologie ook mee te nemen. Het zal niet altijd mogelijk zijn om terminologie één-op-één op elkaar af te beelden. Het zal voorkomen dat termen een deels overlappende betekenis hebben, en de kunst is dan om die overlap expliciet te maken. Het zal dan afhangen van de gedetailleerdheid (granulariteit) van de modellen hoe makkelijk het is om die overlap in betekenis expliciet te maken. In onderstaande figuur is een overzicht gegeven hoe we in die gevallen tot verzoening kunnen komen.

De eerste stap is hier om beide UML modellen eerst te verzoenen. In het getoonde voorbeeld is het gemeenschappelijke attribute (postcode) expliciet gemaakt in een nieuwe klas CIMX. De twee oorspronkelijke klassen uit het model zijn aangepast waarbij postcode geen onderdeel meer is van de oorspronkelijke klassen. Vervolgens is de stap gemaakt naar de ontologietransformatie en is een voorbeeld gegeven hoe resources die behoren tot de CIM:Location of X:Adres klasse synoniem aan elkaar kunnen worden gemaakt. In dit voorbeeld zit de semantische overlap in het property Postcode. Een RDF restrictie definieert wanneer resources van de CIM:Location of X:Adres klasse ook tot de CIMX:Postcode klasse behoren. Resources die via deze restrictie tot de CIMX klasse horen hebben een deels overlappende semantiek. De voorbeelden tonen aan dat er mogelijkheden zijn om te transformeren van UML naar RDF ontologieën. Hierbij kan worden omgegaan met semantische verschillen en per situatie zal moeten worden bekeken hoe die het beste kan worden ingericht. Afhankelijk van de situatie wordt dit nu door tools ondersteund, maar in specifieke gevallen zal nader onderzoek nodig zijn hoe dan de transformatie in te richten.

297

Figuur 2 - UML model naar ontologietransformatie semantische modelverzoening via OWL restriction method.

IEC CIM transformatie naar RDF ontologie Het IEC CIM is een UML gebaseerd Class-specificatie (class-diagram). De verschillende diagrammen die samen de specificaties vormen, kunnen beschouwd worden als een uitgebreid entity-relation diagram (ERD) waarmee metadata is gespecificeerd. Dit model van IEC CIM [1] is groot en uitgebreid en bevat meer dan duizend verschillende classes met bijbehorende eigenschappen en relaties. De complexiteit die hierdoor ontstaat wordt gestructureerd door de classes in packages en diagrammen te verdelen. Deze packages en diagrammen specificeren relevante sub-domeinen binnen het energie-

systeem (bv. Metering, Distributie en Transport van energie). Dit is een generiek UML-mechanisme om grote, complexe modellen voor de mens toegankelijk, begrijpbaar en onderhoudbaar te houden. De UML specificaties die op deze manier zijn vastgelegd bevatten informatie om specifieke ontologieĂŤn te ontwikkelen. Bestaande CASE tools (bv Enterprise Architect) bieden mogelijkheden aan gebruikers om zogenaamde profielen te definiĂŤren. Dit is een selectiemethode om een relevant deel uit het grote model te selecteren en die te gebruiken als basis voor een specifieke toepassing. Op basis van deze doorsnede kan

298

een transformatie worden gemaakt naar een RDF gebaseerde ontologie die gebruikt kan worden als metadata voor de te ontsluiten dataset. Hoewel deze transformatie triviaal lijkt moet deze stap met zorgvuldigheid worden genomen, het luistert nauw hoe de notatiewijze van het object georiënteerde UML wordt geïnterpreteerd om de juiste statements te genereren voor de RDF/OWL ontologie. Binnen de energiesector is een aparte tool ontwikkeld (CIMTool [2]) die zorg draagt voor deze interpretatie en vertaling naar verschillende schema’s voor berichten, databases en ontologieën.

In dit voorbeeld is een klein model gemaakt om energieverbruikdata te specificeren. Voor het ontsluiten van de data is een selectie gemaakt van classes uit het IEC CIM en is er een regionaal specifieke class gedefinieerd (DutchSDPArea == Verbruiksgebied). In bovenstaande figuur is een voorbeeld gegeven van dit diagram. Het model toont een class-specificatie met eigenschappen voor een energieverbruikgebied (DutchSDPArea), energieproduct categorie (ServiceCategory) en een service delivery point locatie (SDPLoFiguur 3 - UML–profile: CIM extensie model

299

cation). Bedenk wel, het gaat hier om een klein deel van het totale model en bedoeld als basis voor de verbruiksontologie. In het voorbeeld wordt gebruik gemaakt van twee IEC CIM gedefinieerde classes (ServiceCategory en SDPLocation), en een regionaal specifieke extensie (DutchSDPArea). De dataset, die met de gegenereerde ontologie is ontsloten, zal voor een deel bruikbaar zijn voor generieke CIM gebruikers en bruikbaar voor die toepassingen (of gebruikers) die de extensies op het model ook hebben geïmplementeerd.

Ter illustratie is hieronder een deel van de gegenereerde ontologie gepresenteerd die uit het IEC CIM is getransformeerd. De volledige ontologie is groter en bevat alle RDF specificaties die uit het UML model worden gehaald. Dit zijn naast de entiteiten en de relaties ook de cardinaliteiten van de associaties en de attributen. Deze worden omgezet naar complexe RDF notaties met onder andere ‘blank nodes’. Het voert in dit artikel te ver om hier dieper op in te gaan, maar geïnteresseerden kunnen meer informatie vinden in het W3C RDFprimer document [3].

<rdf:Description rdf:nodeID=”Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7fed”> <rdf:type rdf:resource=”http://www.w3.org/2002/07/owl#Class”/> <rdfs:subClassOf rdf:resource=”http://iec.ch/TC57/2009/ CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/ Customers#ServiceCategory”/> <rdfs:label>delivers</rdfs:label> <owl:unionOf rdf:nodeID=”Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7fe7”/> </rdf:Description> <rdf:Description rdf:nodeID=”Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7ffd”> <rdf:type rdf:resource=”http://www.w3.org/2002/07/ owl#Restriction”/> <owl:onProperty rdf:resource=”http://iec.ch/TC57/2009/CIM-schemacim14/DutchCIM/DcimMetering#DutchSDPArea.activeSDPPerc”/> <owl:minCardinality rdf:datatype=”http://www.w3.org/2001/ XMLSchema#int”>1</owl:minCardinality> </rdf:Description> <rdf:Description rdf:nodeID=”Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7ff2”> <rdf:type rdf:resource=”http://www.w3.org/2002/07/ owl#Restriction”/> <owl:onProperty rdf:resource=”http://iec.ch/TC57/2009/CIM-schemacim14/DutchCIM/DcimMetering#DutchSDPArea.serviceReceptionPerc”/>

300

<owl:allValuesFrom rdf:nodeID=”Xd2X795e06cdXa3X13bdbe47cb3Xa3X7ff3”/> </rdf:Description> <rdf:Description rdf:nodeID=”Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7fe9”> <rdf:type rdf:resource=”http://www.w3.org/2002/07/ owl#Restriction”/> <owl:onProperty rdf:resource=”http://iec.ch/TC57/2009/CIM-schemacim14/DutchCIM/DcimMetering#DutchSDPArea.serviceArea”/> <owl:allValuesFrom rdf:nodeID=”Xd2X795e06cdXa3X13bdbe47cb3Xa3X7fea”/> </rdf:Description> <rdf:Description rdf:nodeID=”Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fa4”> <rdf:type rdf:resource=”http://www.w3.org/2002/07/ owl#Restriction”/> <owl:onProperty rdf:resource=”http://iec.ch/TC57/2009/CIM-schemacim14/IEC61970_IEC61968_combined/IEC61968/Common#TownDetail.name”/> <owl:minCardinality rdf:datatype=”http://www.w3.org/2001/ XMLSchema#int”>1</owl:minCardinality> </rdf:Description> <rdf:Description rdf:nodeID=”Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fa8”> <rdf:type rdf:resource=”http://www.w3.org/2002/07/ owl#Restriction”/> <owl:onProperty rdf:resource=”http://iec.ch/TC57/2009/CIM-schemacim14/IEC61970_IEC61968_combined/IEC61968/Common#TownDetail.country”/> <owl:allValuesFrom rdf:nodeID=”Xd2X36af7a62Xa3X13bb77c32c5Xa3X7fa9”/> </rdf:Description> <rdf:Description rdf:nodeID=”Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fdb”> <rdf:type rdf:resource=”http://www.w3.org/2002/07/owl#Class”/> <rdfs:subClassOf rdf:resource=”http://iec.ch/TC57/2009/CIM-schemacim14/IEC61970_IEC61968_combined/IEC61968/Customers#ServiceKind”/> <rdfs:label>kind</rdfs:label> <owl:unionOf rdf:nodeID=”Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fd2”/> </rdf:Description>

301

<rdf:Description rdf:nodeID=”Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fcc”> <rdf:type rdf:resource=”http://www.w3.org/2002/07/ owl#Restriction”/> <owl:onProperty rdf:resource=”http://iec.ch/TC57/2009/ CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/ Customers#ServiceDeliveryPoint.ServiceCategory”/> <owl:minCardinality rdf:datatype=”http://www.w3.org/2001/ XMLSchema#int”>1</owl:minCardinality> </rdf:Description> <rdf:Description rdf:nodeID=”Xd2X36af7a62Xa3X13bb77c32c5Xa3X-7fd0”> <rdf:type rdf:resource=”http://www.w3.org/2002/07/ owl#Restriction”/> <owl:onProperty rdf:resource=”http://iec.ch/TC57/2009/ CIM-schema-cim14/IEC61970_IEC61968_combined/IEC61968/ Metering#ServiceDeliveryPoint.SDPLocations”/> <owl:allValuesFrom rdf:nodeID=”Xd2X36af7a62Xa3X13bb77c32c5Xa3X7fd1”/> </rdf:Description> <rdf:Description rdf:nodeID=”Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7ff8”> <rdf:type rdf:resource=”http://www.w3.org/2002/07/ owl#Restriction”/> <owl:onProperty rdf:resource=”http://iec.ch/TC57/2009/CIM-schemacim14/DutchCIM/DcimMetering#DutchSDPArea.housingSDPPerc”/> <owl:allValuesFrom rdf:nodeID=”Xd2X795e06cdXa3X13bdbe47cb3Xa3X7ff9”/> </rdf:Description> <rdf:Description rdf:nodeID=”Xd2X795e06cdXa3X13bdbe47cb3Xa3X-7fe8”> <rdf:type rdf:resource=”http://www.w3.org/2002/07/ owl#Restriction”/> <owl:onProperty rdf:resource=”http://iec.ch/TC57/2009/CIM-schemacim14/DutchCIM/DcimMetering#DutchSDPArea.serviceArea”/> <owl:minCardinality rdf:datatype=”http://www.w3.org/2001/ XMLSchema#int”>1</owl:minCardinality> </rdf:Description>

302

Een aspect dat we bij het ontsluiten van data als RDF-based data nog niet hebben benoemd is het URI mechanisme. In de bijdrage ‘Designing A URI Strategy For The Dutch Public Sector’ is een introductie gegeven wat URIs zijn en hoe die worden gebruikt bij het identificeren van ontologieën, resources en data. Bij de vastlegging van classes, attributen en relaties in het UML model bestaat in sommige CASE tools de mogelijkheid per model, package, class en relatie een URI te specificeren. Hiermee worden termen in het model uniek geïdentificeerd en wordt die identificaties gebruikt bij het generen van de ontologie. Hiermee wordt gezorgd dat gelijke terminologie uit verschillende ontologieën (maar gebaseerd op hetzelfde informatie model) dezelfde identificatie krijgen waardoor onderlinge consistentie tussen de ontologieën wordt gekregen. Wanneer CASE tools deze URI identificatie (nog) niet ondersteunen zijn aparte tools beschikbaar om tijdens het maken van profielen uit een UML model deze identificatie alsnog toe te voegen.

Samenvatting en conclusie In dit artikel is aandacht gegeven aan het gestructureerd en eenduidig ontwikkelen van sector ontologieën. In veel sectoren en toepassingsgebieden is veel kennis en kunde vastgelegd in informatiemodellen, die geschikt zijn om als basis te dienen voor ontologieontwikkeling. Met het hergebruik van deze modellen wordt gebruik gemaakt van bestaande en vertrouwde afspraken die binnen de sector al bekend zijn. Door de afspraken te gebruiken in de ontologieontwikkeling wordt de acceptatie van linked data methode en technieken vergemakkelijkt en wordt gezorgd voor onderlinge consistentie tussen ontologieën. De onderlinge interoperabiliteit wordt hiermee gewaarborgd. Door het hergebruik van de informatiemodellen voor de ontwikkeling van ontologieën wordt ook het belang van deze modellen verder vergroot als eenduidig informatiespecificatie document. Deze informatiemodellen worden vaak al op een consistente wijze onderhouden en zijn actueel en upto-date. Dit mechanisme kan ook gebruikt worden om de ontologieën die op deze modellen zijn gebaseerd

303

op een goede manier te onderhouden. Bij het verschijnen van nieuwe versies van het model kunnen ook nieuwe versies van ontologieĂŤn worden gepubliceerd. Daarbij kunnen ook bijbehorende mappingontologieĂŤn op een gecontroleerde manier worden gepubliceerd, en wordt de interoperabiliteit met andere modellen gewaarborgd. Door de technologie- en leverancieronafhankelijke wijze van vastlegging van een informatiemodel, wordt alle ruimte gelaten voor een vrije keuze hoe de afspraken te implementeren in systemen. Veel bestaande CASE-tools maken gebruik van modelleringtalen zoals UML en bieden ruime mogelijkheden om die te transformeren naar specifieke componenten voor bijvoorbeeld Java, XML of RDF specifieke toepassingen. Die componenten leveren de gewenste functionaliteit in een specifieke technologie, de specificaties zijn technologie neutraal. Dit bevordert de eenduidigheid binnen de sector en de interoperabiliteit tussen organisaties en applicaties, terwijl er vrijheid bestaat in de technologie keuze om oplossingen te realiseren.

References [1] Dr Alan W. McMorran (2007), An Introduction to IEC 61970-301 & 61968-11-The Common Information Model. Institute for Energy and Environment Department of Electronic and Electrical Engineering. University of Strathclyde Glasgow, UK [2] CIMTool: http://www.cimtool.org/ [3] RDF Primer: http://www.w3.org/ TR/rdf-primer/ [4] W3C: http://www.w3.org/ standards/semanticweb/ontology

D7 - INSPIRE and Linked Data Auteur

Clemens Portele (Interactive Instruments) Linked Data as such did not exist when the INSPIRE Directive or its technical foundation in Implementing Rules were designed. However, as the focus of linked data is on principles how data is to be published on the Web, there is overlap in the goals of INSPIRE and of linked data, but there are also â&#x20AC;&#x201C; sometimes subtle â&#x20AC;&#x201C; differences. For example: ll INSPIRE did not limit the networks on which spatial data is to be made available while linked data is explicitly focussed on the Web. However, so far INSPIRE has limited its technical guidance to the Web, so in reality this is not a significant difference, but the network-neutrality requirements in the Directive and Implementing Rules have impact, even if all INSPIRE data is published on the Web. This affects in particular identifiers. ll The scope of INSPIRE is about publishing existing data sets and excludes the collection of new data. Typically publishing data as linked data goes beyond this as it strongly encourages adding links to other, related data.

The compatibility of INSPIRE concepts and linked data were first analysed in 2009 and presented at the INSPIRE conference 2010. In that paper it was highlighted that linked data is not a technical subject per se. It uses the principles of the Web, and technologies of the Semantic Web, to develop the Web of data. Linked data can be seen as a philosophy about using the Web to create a unified set of data. A key aspect is to interlink the data through Web mechanisms. All this is consistent with what is done in SDIs in general and INSPIRE in particular. There are some differences in technologies, but these are minor. The biggest issues are non-technical. INSPIRE is a European Directive that entered into force in May 2007. It aims to create a European Union spatial data infrastructure. This will enable the sharing of environmental spatial information among public sector organisations and better facilitate public access to spatial information across Europe. The Directive addresses 34 spatial data themes needed for environmental applications, with key components specified through technical implementing rules. Implementation of INSPIRE is ongoing. INSPIRE is based on a number of common principles:

305

ll Data should be collected only once and kept where it can be maintained most effectively. ll It should be possible to combine seamless spatial information from different sources across Europe and share it with many users and applications. ll It should be possible for information collected at one level/scale to be shared with all levels/scales; detailed for thorough investigations, general for strategic purposes. ll Geographic information needed for good governance at all levels should be readily and transparently available. ll Easy to find what geographic information is available, how it can be used to meet a particular need, and under which conditions it can be acquired and used.

Technical Comparison of Linked Data and INSPIRE In the table below we compare how different technical aspects related to (spatial) data are treated in both linked data and INSPIRE. For INSPIRE we take the technical guidelines, which are not legally binding, as the basis. We can distinguish two main causes for the differences shown in the table. First, INSPIRE – and SDIs in general – developed using a different set of web technologies than linked data. Linked data is firmly based on semantic web technologies while SDIs are mostly based on web services sending XML messages via HTTP, typically based on OGC and ISO/TC 211 standards. Second, there are differences that are due to the way the INSPIRE Directive was worded.

Table 1 - Comparison of technical characteristics of spatial data in linked data and INSPIRE

Aspect

Linked Data

INSPIRE

Schema description

RDF-S / OWL are preferred; UML as specified by ISO 19109 other languages are ok, too

Data encoding

RDF (XML or TTL) are the preferred encoding; other encodings are ok, too; any encoding should use an open specification or at least provide the data in a structured form GeoSPARQL specifies two RDF geometry encoding options using WKT and GML

GML – derived from the UML model using the standard GML encoding rule – as default encoding; other encodings are ok, too Over the next years a broad variety of encodings will be used, see http://inspire.ec.europa.eu/media-types

Terms and vocabularies

Managed as resources, typically encoded in SKOS

Managed as resources, currently encoded in GML and in the future likely using SKOS, too

306

Aspect

Linked Data

INSPIRE

Identifiers HTTP URIs for all resources The identifiers should be stable and not depend on implementation

Identifiers not required for all data HTTP URIs may be used, but this is only a recommendation, not a requirement

Links Links to other data is qualified by a link type HTTP URIs are used to reference the linked resource

Links to other features are qualified by a link type (property) URIs are used to reference linked resource in GML encoding Links are restricted to associations identified in application schemas Most datasets do not have links to external resources

Access to resources Using HTTP

Pre-defined Dataset Download Service (Atom feed option): no access to individual resources, only datasets Pre-defined Dataset and Direct Access Download Service (WFS option): GetFeatureById query supports access to each feature using a HTTP URI

Queries on datasets

Optional, but typically provided using a SPARQL endpoint, if RDF is supported as an encoding GeoSPARQL provides extensions for spatial query predicates

Only supported in Direct Access Download Services (WFS)

Extensions

Linked data follows the open world assumption: Additional information may be attached to any resource by anyone Extensions may be part of another dataset

INSPIRE follows a closed world assumption: Extensions are supported and specified in extensions to the UML schema The complete information about a feature is always part of one dataset

In order to understand the differences better, we will discuss what data publishers that have a mandate to publish spatial data in INSPIRE need to do, if they want to provide their data consistent with linked data practices, too.

ll use persistent, resolvable HTTP URIs as identifiers for all features, ll support RDF as an additional encoding, optionally provide a SPARQL endpoint for queries, ll add and maintain links to other data

There are three tasks that they would have to address beyond the INSPIRE interoperability requirements:

Letâ&#x20AC;&#x2122;s have a look at each topic separately.

307

HTTP URIs as Identifiers Identifiers in the legal framework of INSPIRE have been defined independent of a specific platform as a combination of a namespace and a local identifier in that namespace. This is a direct consequence of supporting multiple types of platforms, at least conceptually. In practice, however, INSPIRE is implemented as part of the web and no other type of platform is supported by the implementing rules and technical guidance documents. In a way it could also be said that INSPIRE is implemented on the web, but with additional conventions that make it hard for the rest of the web to link to and use the spatial data in INSPIRE. Similar things can be said about the semantic web. Both linked data and INSPIRE/SDIs add an additional layer of conventions on top of the web and both conventions are supported by different communities. However, these conventions should honour the basic conventions of the web in order to avoid ending up as a closed platform that simply uses the web as a basic network infrastructure. Identifiers of resources are an important case where INSPIRE currently does not follow the conventions of the web as it is today. I.e., HTTP URIs should be used for all information resources and these URIs must

be stable. There is also the expectation that information about the identified resource can be retrieved using HTTP. Supporting HTTP URIs for features in INSPIRE is a pre-condition for the other tasks necessary to provide INSPIRE data consistent with linked data practices. Even without considering linked data, this is a general prerequisite for publishing data on the web in general. This has been recognised and the technical guidance in INSPIRE already includes a strong recommendation to use such HTTP URIs for all features (http://inspire.ec.europa.eu/ids). A key issue is that this requires business processes and technical infrastructure that many providers of spatial data are not used to. As INSPIRE has no legal requirement for using HTTP URIs as identifiers it is likely that without supporting measures this recommendation will not be followed. The Netherlands has acknowledged this and is developing a URI strategy that also includes spatial data (see the separate paper in this book). To implement the recommendation, two actions are needed: First, all identifiers in INSPIRE need to be mapped to stable HTTP URIs. For features without identifiers, it should be considered whether such

308

identifiers could be defined. A challenge in this process is that URIs must be independent of implementation details. For example, a URI of a GetFeatureById request to a WFS is not appropriate as this is likely to change with time. Second, the necessary technical infrastructure needs to be set up, configured and maintained to resolve the HTTP URIs and return information resources. Typically this will involve a standard HTTP redirect to a current location of a resource, for example the URI of a WFS GetFeatureById request. For features and data sets, this is the responsibility of the data/service providers. For code lists, this is the responsibility of the European Commission (for the INSPIRE code lists) and the Member States (when extending the standard code lists). For coordinate reference systems this has already been done by the Open Geospatial Consortium. If this is accomplished, others may use the spatial data in INSPIRE to provide location context to their business information in a way that is consistent with web technologies. For example, one could associate property rights with a parcel, a timetable with a railway station, with statistical information to a statistical unit, materials with an industrial facility, etc.

Openness of the data will be important in this, too, as links to data that turns out to be inaccessible will not be useful and minimize the acceptance and uptake of spatial data that is published on the web. RDF encoding and SPARQL endpoints The linked data movement has a string preference for using RDF as an encoding of data, but this is not a strict requirement and the importance will depend on the context. However, to integrate a dataset into the linked data cloud it is likely that RDF needs to be supported. I.e., data providers that want to provide their spatial data also need to provide the data in an RDF encoding. Technically this will be straightforward as the INSPIRE application schemas and GML encoding are both largely isomorphic with RDF. Typically the RDF will be stored in a triple store and be published via a SPARQL endpoint that also supports queries on the data. The challenge here lie in the additional workflows that needs to be supported. In particular, updates to the dataset imply an update of the triple store, too. In addition, the technical infrastructure needs to be maintained.

309

Links to other data The fifth star of the linked data deployment scheme is to link your data to other data to provide context. If spatial data in INSPIRE is published with HTTP URIs as identifiers, this enables others to provide location context to their data as we have discussed above. Likewise spatial data should be linked to related data. Otherwise the contribution to interlinking data would be limited. The web depends on links. Today, most spatial datasets do not contain links to features maintained in other datasets or other resources. Spatial datasets are typically closed collections of data. The experiences with GML are relevant here: The Geography Markup Language (GML) was created more than a decade ago to web-enable spatial data and their schemas. Still today spatial data is in most cases without links to other data and GML is mostly used as just another spatial data format and not as originally intended. Maybe the time was not ready when GML was developed, but there is also a good chance that the spatial data community is still not ready to adapt to the web. The INSPIRE application schemas reflect this and support for references to other data is limited. Using the open world assumption of the semantic web, spatial data that is

encoded using RDF may of course be enriched with additional link types not included in the INSPIRE application schemas. In INSPIRE there are no legal requirements to collect additional data â&#x20AC;&#x201C; including links.

Conclusions This paper provides a brief look at the gaps between INSPIRE and linked data. Technologically, the gap is small. The main challenges are: ll Whether organisations see sufficient benefit in publishing their features and related data with persistent HTTP URIs (and keep the data up-to-date) - encoded in RDF via SPARQL endpoints; ll Whether organisations see sufficient benefit in establishing and maintaining links to other data. Today this is typically not the case and over the last 10-15 years not much of the existing spatial data has been adapted to web principles and it is unclear, if this is changing. Publishing five star linked data in most cases introduces new data workflows as we have seen from the discussion in this paper and research providing a clear assessments of the value and benefits is not available at the moment.

310

References ll Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) ll Commission Regulation 1089/2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services ll INSPIRE Generic Conceptual Model (D2.5), version 3.4rc3: http:// bit.ly/11lhloQ ll INSPIRE Guidelines for the encoding of spatial data (D2.7), version 3.3rc3, tbd ll Cox, S., Schade, S., Portele, C. Linked Data in SDI, INSPIRE Conference 2010: http://bit.ly/12SDWMK ll Bizer, C., Heath, T., Berners-Lee, T. Linked Data - The Story So Far. Special Issue on Linked Data, International Journal on Semantic Web and Information Systems (IJSWIS), http://linkeddata.org/ docs/ijswis-special-issue ll Berners-Lee, T. Linked Data, http://www.w3.org/DesignIssues/ LinkedData.html

D8 - From Geo-Data to Linked Data: Automated Transformation from GML to RDF Auteurs

Linda van den Brink (Geonovum) Paul Janssen (Geonovum) Wilko Quak (TU-Delft) Linked data provide an alternative route for dissemination of spatial information as compared to the traditional SOA-based SDI approach. Where the latter is built on predefined structuring of semantics within domains, linked data is open to linking information to any data over the Web. In this respect both are complementary. The traditional approach providing a mechanism for a basis of standardized and structured data within domains, and linked data providing an open mechanism for sharing and combining. GML as the ISO standard for exchange of service based spatial data and RDF as the linked data format are therefore related. GML provides the format in which many spatial datasets are available and exchanged. This standardization process and effort has been realized on a large scale. Why not let the web of linked data take advantage of this effort? This article will focus on the use of GML structured data as a source for deriving RDF structured data.

The first part of the paper focusses on deriving linked data from GML data. The first version of GML, v1.0, was based on RDF. From version 2.0 onwards GML was based on XML and XML Schema, but the objectproperty structure was retained. We describe a transformation for translating any correctly structured GML to RDFS/OWL automatically, using XSLT. Because GMLâ&#x20AC;&#x2122;s objectproperty structure translates very well to triples, the transformation is straightforward. Well-known GML content elements such as names and descriptions are mapped to their RDF equivalent. However, any semantics specific to the input GML data (a.k.a. the application schema) are ignored in this translation. In the second part, we study how more meaningful RDF can be created from GML, given the underlying information model, by transforming it from UML to RDFS/OWL. There exists a straightforward mapping to convert a UML model into a RDFS/ OWL vocabulary. However, the re-use of existing concepts in vocabularies takes a central role in RDFS/OWL while in UML the use of vocabularies is not supported. We describe how annotating the UML model could improve this translation.

312

Background Linked data is the new kid on the block in the set of standards relevant for geographic information. It provides an alternative route for dissemination of spatial information as compared to the already considered traditional SOA-based SDI approach. Basically the difference is about flexibility and openness. Where the latter is built on predefined structuring of semantics within domains, linked data is open to linking information to any data over the Web. In this respect it much more appeals to the web 3.0 philosophy: unique information features that are there, floating around, and can be accessed and or extended any time by anyone for any purpose. But what does that mean to what has been done and realized in the spatial information infrastructure until now? We state that it is complementary. The traditional approach providing a mechanism for a basis of standardized and structured data within domains, and linked data providing an open mechanism for sharing and combining. The traditional approach is characterized by a service based dissemination of GML structured data. In that approach data specifications provide clear definitions of semantics in predefined domains and use cases. These are implemented in XML schema, providing a well defined and verifiable means of information exchange. The strong point of it is that the proper purpose of standar-

dization and harmonisation, being interoperability can be addressed through agreement and sharing of vocabulary. Once agreed the requirements and rules for communication are set and can be implemented in a verifiable way. The quality of implementation can be measured and therefore managed. But there is a downside: the vocabulary, semantics are defined within information domains. Resulting in predefined information silos each related to different information domains. Within the silo interoperability is assured by shared and foreseen concepts, but between silos little harmonization takes place, and for not yet foreseen concepts and relations the structure is too rigid. This is exactly the weak spot where linked data can be of help. In a spatial data infrastructure GML data are generated and served from different feature based sources. Generally transformation services will do the transformation from these local sources to the GML structured data. In many SDI projects and programmes a lot of effort has been put into that activity. For linked data, including the related RDF format and GeoSPARQL, a similar way can be followed. Transformation services acting on local sources and generating GeoSPARQL endpoints. But why not reuse the already existing GML sources? Since these are already structured in a standardized and defined way, RDF

313

transformation can be standardized as well. Linked date can therefore build on the structure already provided. One would expect a simple rule of benefit: profiting twice by reusing work that has been done once. The challenge therefore is to investigate this way of generating linked data out of GML. In the process we will come to understand more about principal differences between linked data and GML and their complementary roles. The following diagram depicts several ways of building linked data on top of an SDI. Figure 1 - RDF as part of SDI

Principal ways of integrating linked data in a spatial data infrastructure [1]. Related to the diagram GML to RDF transformation can be considered in the RDF-izer part. The Linked Data Wrapper is also interesting but for this article out of scope. Deriving linked data from GML Geography Markup Language is a standard for the storage and transport of geographic information. The first version of GML, v1.0 [2], was published in May of the year 2000. Key concepts in the GML model of the world are the feature: an abstrac-

314

tion of a real world phenomenon, the geographic feature: a feature which is associated with a location relative to the Earth, and the feature collection, a collection of features that can itself be regarded as a feature and that gives a digital representation of the real world. Features have properties, geographic features have properties whose value may be a geometry. GML 1.0 used a geometry model called ‘Simple Features’, with definitions for point, line string, polygon, and some other basic geometric shapes. In addition it provided a coordinates element for encoding coordinates, and a Box element for defining extents. In its simplest form, GML contains no more semantics than this: geographic features with associated geometric shapes. The standard, however, includes an extension mechanism which makes it possible to define application-specific extensions with added semantics, for example distinct object classes for River and Road, each with their specific properties. GML 1.0 described three encoding profiles for geographic features, two of which were based on XML (Extensible Markup Language) and DTD (Document Type Definition: similar to XML Schema which was not used because it was not yet standardized at that time), while the third was based on RDF and RDF Schema. This means that it was possible to write GML

1.0 as an RDF file! OGC intentionally created the model of GML as consistent with RDF. Like RDF, the model of GML was basically a set of triples. GML features have properties; each property is a {name, type, value} triple. Properties can have either simple values or have a geometry object as value (‘geometric value’). According to the naming conventions of GML, object properties always had names starting with a lowercase letter, while GML object classes had names starting with an uppercase letter. All objects had an optional ID which could be used together with the GML document URI as a fragment identifier. In this manner, GML objects could be referenced as resource – very much the linked data way of working! GML 1.0 example, in which ‘yourhouse’ and ‘myhouse’ have the same location: <Building ID = ‘yourhouse’ .. > <location> <Point ID = ‘134’> <coordinates> 2455.12, 3443.78 </coordinates> </Point> </location> </Building> <Building ID = ‘myhouse’ .. > <location> <Point resource = ‘#134’ /> </location> </Building>

315

Figure 2 - Sample XSLT fragment

From version 2.0 onwards GML was based on XML and XML Schema, and the RDF profile was no longer used. But an interesting fact is that the object-property structure, in which objects have properties and properties have either simple values or objects as values - basically a triple structure â&#x20AC;&#x201C; always stayed, up until the latest version, 3.3 [3]. And because GML and RDF both have a triple structure, it is easy to define a transformation for translating any correctly structured (that is, conformant to the object-property /triple structure) GML data to RDFS/OWL automatically. As an experiment, we implemented such a transformation using XSLT 2.0 [4]. Well-known GML content elements such as names and descriptions are mapped to their RDF equivalent. Objects and properties are recognized based on their place in the triple structure and are transformed accordingly. The experimental implementation has 8 templates; counting whitespace and comments it has 88 lines. This shows the simplicity of the trans-

formation. The full XSLT stylesheet is included as an appendix. The stylesheet was tested on a sample GML file containing land use plans, conforming to the Dutch standard IMRO (Information Model Ruimtelijke Ordening - spatial planning) .

Workings of the transformation The transformation starts at the top of the GML file and selects all features, even the ones that are nested as property value of another feature. The features can be recognized because they always have an even number of ancestors (levels in the XML hierarchy). The GML file starts with a feature (usually a feature collection), which has properties, which in turn have features as values. A simple filter can take advantage of this fact. Those elements that have an even number of ancestors (levels in the XML hierarchy) are transformed to rdf:Description elements. The rdf:about attribute is filled with gml:id if itâ&#x20AC;&#x2122;s present; if not, an id is generated.

316

Well-known, standardized GML properties are transformed to an appropriate property. When possible a standard property from RDF or RDFS is used. For example, gml:description is transformed to rdfs:comment, gml:name to rdfs:label. Properties that are not known (i.e. not standard GML, but from some domain-specific extension) are not changed, but receive the same name in the RDF output. Properties with nested content (they have a feature as value, which is not referenced but included directly) receive special treatment. The nested feature is already recognized, and transformed to an rdf:Description, by the first templates. The property with nested content is transformed to a property that references the feature that was nested, using an rdf:resource attribute containing Figure 3 - Line geometry in GML

the id of the feature prefixed with a hash â&#x20AC;&#x2DC;#â&#x20AC;&#x2122;. Usually an id is not present in these cases, and one is generated automatically. Properties that link to a feature in the GML are transformed to their RDF equivalent, an RDF property with an rdf:resource attribute containing the id of the referenced feature.

Geometry Geometry is encoded in GML as objects with properties, so it has the same triple structure. This structure is translated directly to RDF, in the same way as described above for the other features. But this is not the most useful way to represent geometry in RDF. Because geometries like curves and polygons are heavily nested structures in GML, it takes a lot of resources to represent them in RDF. A sample line geometry:

317

Figure 4 - The same Line geometry (fragment) in RDF

The example shows a curve with several nested segments in GML. In RDF these nested segments become links to these segments as separate Description resources (only the first segment, with id ‘d1e67460’ is shown). This becomes even more complex with polygons that have patches, interior and exterior rings, which are built up from curves, etc. This way of encoding geometry makes locationbased querying the RDF very hard. In this short experiment there was no time to look at different, easier ways of encoding the geometry in RDF, but several possibilities exist. These alternatives range from very simple solutions, such as Basic Geo [5], usable for representing latitude and longitude Figure 5 - Fragment IMRO GML

using WGS84 as reference datum; to more full-fledged solutions like GeoSPARQL [6], which allows a WKT (Well Known Text) serialization and a GML serialization. Which of these to use is a very relevant question we must answer before starting to create geo-linked data on a larger scale.

More semantics The XSLT stylesheet described above transforms GML data to RDF in a generic way, based on GML’s objectproperty structure. But it ignores any domain-specific semantics the GML may have. The IMRO sample file has a lot of domain-specific semantics, defined in the IMRO GML application schema:

318

imro:Bouwaanduiding (building indication) is translated to an rdf:Description of rdf:type http:// someuri#Bouwaanduiding. Instead of â&#x20AC;&#x2DC;someuriâ&#x20AC;&#x2122; this should refer to some location where the IMRO ontology is published. All properties of imro:Bouwaanduiding are transformed to RDF properties of the same name (see Figure 6). These should all be defined in the IMRO ontology (which we do not have, at least not in RDF/OWL at this stage). Some of the properties could be mapped to Linked Data vocabularies. For example, it would be appropriate to translate imro:naam to rdfs:label, but this is not known to the transformation, as it is a generic tool and is not aware of the meaning of the IMRO vocabulary.

This aspect must be addressed because usually the GML is extended for a certain domain. It contains rich semantics, which would be lost in the translation to RDF: in the context of the semantic web these semantics are of course crucial! These semantic extensions are described in a standardized way in a so-called GML application schema. For the Dutch IMRO standard such an application schema is available. Therefore not only the GML, but also the GML application schema should be translated to Linked Data standards. Also, domain-specific knowledge about the application schema could improve the mapping, taking into account established Linked Data languages and vocabularies like RDF and RDFS, but

Figure 6: Same fragment; IMRO RDF

also for example Dublin Core or SKOS. In our experiments we looked at this, and the next section describes some interesting aspects on the translation to RDF of specific semantics from an application-specific GML structure like IMRO.

319

Creating meaningful RDF from Geo-information models

jects. A combination of both would be best and this can be achieved by defining specific mappings from UML for spatial modelling constructs. Currently these mappings are partially stable: for spatial datatypes (OGC simple Features) a mapping is described in [6]. How to map UML stereotypes used in spatial models (such as <<FeatureType>>) is still under development. Shapechange [8] implements an experimental version of these mapping rules and it has been successfully applied to the IMRO model resulting in a IMRO vocabulary (Figure 7). By slightly adapting the GML2RDF script it is possible to generate IMRO RDF that refers to the IMRO vocabulary.

Meaning in the semantic web comes from vocabularies and the method in the previous section does not provide or use a vocabulary. By using (or creating) a vocabulary for IMRO the mapping from GML to RDF would more useful. Such a vocabulary can be automatically derived from the IMRO information model. The IMRO information model is available as UML diagram which is then automatically converted into a GML application schema. Now there are two options to generate an OWL vocabulary. First to derive it from the UML model directly, second to derive it from the GML application schema. The first option has the advantage that UML

Figure 7: IMRO Bouwaanduiding vocabulary entry as generated by ShapeChange

is more mainstream IT than GML application schema and that a welldefined mapping from UML to OWL is defined by the OMG [7]. The second option (mapping from the GML application schema) has the advantage that it is spatially aware (since a GML application schema has well defined spatial semantics) which would result in a better mapping for spatial ob-

By using the automatically generated IMRO vocabulary one harmonizing aspect of RDF is not used: no existing RDF vocabularies are used. So imro:naam would get an entry in the IMRO vocabulary where it would be more meaningful to map it to rdfs:label. However the knowledge that imro:naam is in fact an rdfs:label is not available in the UML model and

320

cannot be automatically mapped. In order to improve the UML model for better mapping to RDF one could extend the UML model by annotating the UML attributes that have a special meaning in RDF with a link to their RDF counterpart. If, for example, the imro:naam attribute in the UML model would be get the following annotation (via a tagged value): ‘rdfVocabulary=rdfs.label’ it would be possible to make an optimal link between UML and RDF. We plan to make a proposal for the extension of UML modeling.

References [1] Francisco .J. Lopez-Pellicer, Luis M. Vilches-Blazquez, F.Javier Zarazaga-Soria, Pedro R. MuroMedrano, O. Corcho, The Delft Report: Linked Data and the Challenges for Geographic Information Standardization – and also An RM-ODP Enterprise View for Spatial Data Infrastructures, Revista Catalana de Geografía. 2012, vol. XVII, nº 44. ISSN 19882459. [2] Lake, R. and Cuthbert, A. Geography Markup Language (GML) v1.0. OpenGIS® Consortium (OCG), 12 May 2000. http:// portal.opengeospatial.org/ files/?artifact_id=7197

[3] Portele, C. OGC® Geography Markup Language (GML) — Extended schemas and encoding rules. Open Geospatial Consortium, 7 February 2012. https:// portal.opengeospatial.org/ files/?artifact_id=46568 [4] Kay, M. XSL Transformations (XSLT) Version 2.0. World Wide Web Consortium (W3C), 23 January 2007. http://www.w3.org/ TR/xslt20/ [5] Brickley, D. Basic Geo (WGS84 lat/long) Vocabulary. W3C Semantic Web Interest Group. http://www.w3.org/2003/01/geo/ [6] Perry, M. and Herring, J. OGC GeoSPARQL - A Geographic Query Language for RDF Data. Open Geospatial Consortium, 10 September 2010. http://www. opengeospatial.org/standards/ geosparql [7] Object Management Group, Ontology Definition Metamodel (version 1.0) http://www.omg.org/ spec/ODM/1.0/ [8] ShapeChange, Processing application schemas for geographic information. http://www.shapechange.net/

321

XSLT stylesheet GML > RDF <?xml version=‘1.0’ encoding=‘UTF-8’?> <xsl:stylesheet xmlns:xsl=‘http://www.w3.org/1999/XSL/Transform’ xmlns:xs=‘http://www.w3.org/2001/XMLSchema’ xmlns:imro=‘http://www.geonovum.nl/imro/2008/1’ xmlns:xlink=‘http://www.w3.org/1999/xlink’ xmlns:gml=‘http://www.opengis.net/gml’ xmlns:math=‘http://www.w3.org/2005/xpath-functions/math’ xmlns:rdf=‘http://www.w3.org/1999/02/22-rdf-syntax-ns#’ xmlns:dc=‘http://purl.org/dc/elements/1.1/’ xmlns:owl=‘http://www.w3.org/2002/07/owl#’ xmlns:rdfs=‘http://www.w3.org/2000/01/rdf-schema#’ exclude-result-prefixes=‘xs’ version=‘2.0’> <xsl:output indent=‘yes’/> <xsl:strip-space elements=‘*’/>  <xsl:template match=‘/’> <rdf:RDF> <xsl:apply-templates select=‘//*[count(ancestor::*) mod 2 = 0]’/> </rdf:RDF> </xsl:template>  <xsl:template match=‘*[count(ancestor::*) mod 2 = 0]’>

322

<rdf:Description rdf:about=‘{if (@gml:id) then @gml:id else generate-id(.)}’ rdf-type=‘http://someuri#{local-name()}’> <xsl:apply-templates select=‘@srsName’/> <xsl:apply-templates/> </rdf:Description> </xsl:template>  <xsl:template match=‘@srsName’> <gml:srsName rdf:resource=‘{.}’/> </xsl:template>  <xsl:template match=‘gml:description’> <rdfs:comment><xsl:value-of select=‘text()’/></rdfs:comment> </xsl:template>  <xsl:template match=‘gml:name’> <rdfs:label><xsl:value-of select=‘text()’/></rdfs:label> </xsl:template>  <xsl:template match=‘*[count(ancestor::*) mod 2 != 0 and not(child::*)]’> <xsl:element name=‘{name()}’> <xsl:value-of select=‘text()’/> </xsl:element> </xsl:template>

323

<xsl:template match=‘*[count(ancestor::*) mod 2 != 0 and child::*]’> <xsl:for-each select=‘*’> <xsl:element name=‘{parent::*/name()}’> <xsl:attribute name=‘rdf:resource’ select=‘concat(‘#’, if (@ gml:id) then @gml:id else generate-id(.))’></xsl:attribute> </xsl:element> </xsl:for-each> </xsl:template>  <xsl:template match=‘*[count(ancestor::*) mod 2 != 0 and normalizespace(@xlink:href)]’> <xsl:element name=‘{name()}’> <xsl:attribute name=‘rdf:resource’ select=‘@xlink:href’/> </xsl:element> </xsl:template> </xsl:stylesheet>

D9 - Mapping Statistical Linked Data: A Tutorial on Combining Linked Open Data and Tabular Data in R Auteur

2- Importing Linked Data

Willem Robert van Hage (SynerScope)

To start with this tutorial, you will need a running setup of the R programming language (R, http://r-project. org). We advise you to use the RStudio graphical user interface for R (RStudio, http://rstudio.org), which provides many useful editing features. Inside R, we will make use of two contributed libraries, SPARQL and ggmap, that respectively provide access to SPARQL end-points over the Web, and plotting of data on Google Maps. These libraries can be installed automatically from inside R by typing the following command inside R:

1 - Introduction This chapter is a tutorial on data analysis. We will demonstrate, step by step, how to analyze a combination of linked data and non-linked data with the R statistical programming language. We will show how to join linked data with tabular statistical data. Specifically, we will be working with linked data from the Netherlands’ Cadastre, Land Registry, and Mapping Agency (Kadaster), about addreses and buildings, the Basisregistratie voor Adressen en Gebouwen (BAG); linked data from DBpedia, and non-linked tabular statistical data from the Statistics Netherlands (CBS). We will investigate geographical correlations between building properties and the socio-economical status of their inhabitants. Topics covered in this tutorial are: simple SPARQL endpoint interaction (Section 2), loading tabular CSV data (Section 3), preprocessing the data (Section 4), joining linked data with non-linked data by a shared key (Section 5), basic data exploration and statistics (Section 6), aggregation (Section 7), and geographical visualization (Section 6 and 7).

> install.packages(c(‘SPARQL’,’g gmap’),dependencies=TRUE) Once these libraries are installed they can be loaded using the library function. > # load the SPARQL and ggmap libraries > library(SPARQL) > library(ggmap) Now that we’ve prepared our system and loaded the necessary libraries we can get started with loading the data from the BAG SPARQL endpoint using a SPARQL query. This can be done with the SPARQL function. We need to tell this function a few things: At which URL to get the data, and which query to use to get the data. We will define two variables to

325

contain exactly these bits of information, so that we can pass these variables to the SPARQL function. We can get the data from the BAG end-point at Geodan: > endpoint <- “http://lod.geodan.nl/BAG/sparql”; The data in the triple store behind the SPARQL store follows a schema defined by Geodan. The specific part of the data we will use in this tutorial is the link between the postal code (postcode), street name (straatnaam), usage (gebruiksdoel), the lo> > + + + + + + + + + + + + + + + + + + +

cation (wkt, short forWell-Known Text geometry), and building year (bouwjaar). Per address, these are linked together in little graphs of nodes and edges. We will define a query that looks up occurrences of graph patterns that link them together and we will find one occurrence for each address in the store. To make this tutorial run, we limit ourselves to a subset of the addresses, specifically, those that are in the city of Amsterdam. This can also be specified as part of the SPARQL graph pattern query. In Figure 1 you can see a picture of the graph pattern that we will look up with the SPARQL query listed below.

# define a SPARQL query to load data q <- ‘PREFIX bagv: <http://lod.geodan.nl/BAG/vocab/resource/> PREFIX bag: <http://lod.geodan.nl/BAG/> PREFIX ogc: <http://lod.geodan.nl/geosparql_vocab_all.rdf#> SELECT ?postcode ?straatnaam ?gebruiksdoel ?wkt ?bouwjaar WHERE { ?wp bagv:woonplaats_naam “Amsterdam”^^xsd:string . ?or bagv:woonplaats ?wp ; bagv:openbareruimte_naam ?straatnaam . ?na bagv:openbareruimte ?or ; bagv:nummeraanduiding_postcode ?pc . BIND(str(?pc) AS ?postcode) ?vo bagv:nummeraanduiding ?na ; ogc:WKTLiteral ?shape . FILTER(regex(str(?shape),”^[^<]”)) BIND(str(?shape) AS ?wkt) ?p bagv:verblijfsobject ?vo ; bagv:pand_bouwjaar ?bouwjaar . ?vo bagv:gebruiksdoel ?gd . ?gd bagv:gebruiksdoel_gebruiksdoel ?gebruiksdoel . }’

326

Figure 1 - Part of the RDF schema used in the Geodan RDF version of the BAG that we will extract using SPARQL.

The query can be any SPARQL statement (SPARQL, http://www.w3.org/ TR/sparql11-query/). Detailed descriptions of SPARQL can be found on the Web. A brief discussion of the query we use in this tutorial follows. The PREFIX statements declare abbreviations we can use in the query to specify the URIs of the graph edges, which represent properties of things. For instance, we can write bagv:woonplaats instead of http:// lod.geodan.nl/BAG/vocab/resource/ woonplaats. With the SELECT statement, which is analogous to the SQL SELECT statement, we delare which variables (the keywords that start with a questionmark) we want to return as columns of a result table. Each row in the result table will be a distinct match of the graph pattern specified in the WHERE expression.

The WHERE expression contains a graph pattern in a concise notation, as well as additional variable bindings and filters. For example, on line four and five of the graph pattern we match a triple consisting of a property bagv:openbareruimte between two variables, ?na and ?or, and a property bagv:nummeraanduiding_ postcode between ?na and ?pc. The BIND statement selects the string value of the postal code captured in the variable ?pc, which contains a typed string (e.g. we select ‘1081HV’ from ‘1081HV’^^xsd:string). The FILTER statement three lines below states that we want shapes that do not start with an opening bracket (‘<‘), which in the case of the Geodan version of the BAG separate WGS84 coordinates from coordinates in the Dutch coordinate system Rijksdriehoeksmeting.

327

Now that we have a specification of which variable instantiations we want to gather obeying which pattern in the form of a SPARQL query, we can send the query to the input with the SPARQL function. The table is stored in R as a data frame called bag_res. > # fire the query at the SPARQL end-point > bag_res <- SPARQL(url=endpoint ,query=q)$results To demonstrate what comes back we use the head function to show the first three lines of the result table.

3 - Importing Tabular Data In the previous section we demonstrated how to get tabular data from a triple store using the SPARQL package for R. A much simpler way to read and write data frames is character separated files with the read. table and write.table functions in R. We will quickly show how this is done by loading a file, ‘Eindbestand SEC. dat’ from the CBS on social economical classification of addresses (CBS SEC, http://bit.ly/146jcfH). This file contains tab separated values per row delimited by newline characters. Missing data values are indicated with

> # show the first lines of the resulting data frame > head(bag_res,n=3) postcode 1 1019GM 2 1019GW 3 1019GW

straatnaam Vriesseveem Jollemanhof Jollemanhof

gebruiksdoel overige gebruiksfunctie kantoorfunctie kantoorfunctie

wkt bouwjaar 1 POINT(4.91891809473891 52.3773045855061) 2005 2 POINT(4.91978793944898 52.376984465474) 2005 3 POINT(4.9198026246807 52.3769845234389) 2005 The first line contains an address with postal code 1019GM in the street Vriesseveem with a aspecific usage (gebruiksdoel), the other two are offices in the street Jollemanhof. All three addresses are in a building built in 2005.

the letter x. We can specify that the first line contains column names and that we would like to treat the missing data values as ‘Not Available’ values in R. These are displayed differently for numerical values (‘<NA>‘) and categorical values (‘NA’).

328

> > + >

# load Social Economic figures from the CBS from a CSV table file sec <- read.table(“Eindbestand SEC.dat”, header=TRUE,sep=”\t”,na.strings=”x”) head(sec,n=3)

1 2 3

pc6 1011AB 1011AC 1011AE

gemeentecode 363 363 363

Inkomensontvangers Laaginkomen Hooginkomen NA <NA> <NA> 10 <NA> <NA> NA <NA> <NA>

1 2 3

Uitkeringsontvangers Zelfstandigen NA NA NA NA NA NA

You can see that this table contains a postal code column, pc6, with compatible values to the postcode column in the BAG. In Section 5 we will join these two data frames into a single data frame with all the values on this shared column. Caching SPARQL results as Tabular Data You can use the table reading and writing functions to store SPARQL result tables in a character separated file as follows.

Fiscaalmaandinkomen NA 2300 NA

This saves you the latency of Web lookups and the parsing of SPARQL result XML files. Also, it allows you to keep working when Web access is unavailable, and it reduces the stress on the SPARQL server.

4 - Data Preprocessing Quite often when loading data from third parties, you will run into data representations that are different from how they are needed for analysis. In this case, we would like to plot points on a Google map using the ggmap

> # write results to a cache file > write.table(bag_res,file=”amst erdam_bag_res.tsv”,sep=”\t”) > # read from a cached result file > bag_res <- read.table(“amsterdam_bag_res.tsv”,+ header=TRUE,sep=”\t”)

329

package, which requires vectors of latitude and longitude coordinates. Our data is supplied in WKT shapes. We we use a quick and dirty way to get the coordinates out of the WKT strings. We simply useregular expression substitusion to get the coordinates out of the WKT strings. A more robust, but slower, way would be to use a WKT parser, like the parser in the rgeos package. > bag_res$long <+ as.numeric(gsub(“POINT\$(\\ S+) (\\S+)\$.*”,”\\1”,bag_ res$wkt)) > bag_res$lat <+ as.numeric(gsub(“POINT\$(\\ S+) (\\S+)\$.*”,”\\2”,bag_ res$wkt)) In the CBS data the letter x was used for missing values. In the BAG we see that the number 9999 is used to indicate unknown building years. Also we noticed that the building years below 1850 are suddenly very sparse and that the number 1005 is used for unknown early dates. To make visualization easier (the few old buildings upset the coloring if we want a color gradient over time) we restrict the range of viable building years to everything since 1850. We treat every year below that and the year 9999 as ‘Not Available’ by replacing these years by NA.

> # interpret the building date 9999 as “Not Available” > bag_res[which(bag_res$bouwjaar == 9999 | + bag_res$bouwjaar < 1850),]$bouwjaar = NA

5 - Joining Data Sets on a Shared Key In this section we will join the BAG data with the CBS socio economical classification data by postal code. This enables us to combine, for example, the average monthly income from the CBS (smoothed numbers for anonymization) with the geocoordinates and building years from the BAG. We can join two data frames in R with the merge function. We simply call it on the two data frames and specify which column from each of them to match the rows by. This means, if a value in the CBS SEC pc6 column literally matches a value in the BAG postcode column, the two rows are concatenated.

330

> # perform an inner join between the CBS and BAG data on postal code > sec_bag <- merge(sec,bag_res,by.x=”pc6”,by.y=”postcode”) > head(sec_bag,n=2) pc6

gemeentecode Inkomensontvangers Laaginkomen Hooginkomen

1 1011AB 363

NA <NA>

<NA>

2 1011AB 363

NA <NA>

<NA>

Uitkeringsontvangers

Zelfstandigen

Fiscaalmaandinkomen straatnaam

1 NA NA NA De Ruijterkade 2 NA NA NA De Ruijterkade

gebruiksdoel

wkt

woonfunctie

POINT(4.90560744056207 52.3777814734737) 1916 4.905607

bouwjaar

long

kantoorfunctie POINT(4.90578386133317 52.3777642154535) 1916 4.905784

lat 1 52.37778 2 52.37776

In this case the match is a literal equality match, but it is quite possible to use merge in combination with subset and a custom similarity function to do approximate matching. This is shown in detail in a tutorial on the Web by Tony Hirst (5R-bloggers, http://bit.ly/15gnjoQ).

6 - Data Analysis In this section we will explore the CBS and BAG data. We will start by plotting the building year distribution from the BAG and the average monthly

income from the CBS data to get an overview. Then we will exploit the join over the postal code to see whether or not there is a correlation between the two. This will answer the question: ‘Do rich people live in new buildings in Amsterdam?’. Visualizing Distributions In R you can make a histogram of values with the hist function. You can specify the bin size, i.e. the aggregation interval or the width of the bars, with the breaks parameter.

331

> > + + +

# overview of building years hist(sec_bag$bouwjaar, xlab=”Building year”, main=”Distribution of building year of buildings”, breaks=seq(1850,2015,by=5)) In Figure 3 notice social security at the bottom of the distribution and the cap set at 10000 euro per month.

Figure 2 - Distribution of building years.

As you can see in Figure 2, big urbanization started at the end of the 19th century and there are clear dips in the second world war and the crisis of the 1970s. Now we will do the same with average monthly income. When bin sizes are not supplied, R decides for itself how to bin the data. > # overview of income per month > hist(sec_ bag$Fiscaalmaandinkomen, + xlab=”Fiscal income per month”, + main=”Distribution of income”)

Statistical Correlation If rich people live in new buildings then rows with a high income also have a high building year. By joining the tables on postal code we can simply select the column containing monthly incomes and the column with building years, because these will match up according to postal code. To compute a Pearson correlation (r) in R, you can simply use the cor function on these two vectors. A slight complication is that some values, both in the building year column and in the income column, are not available. These are not necessarily in the same rows. To do a fair correlation test, we leave out all rows with unavailable data in either column. This does introduce a non-response bias, but there is no simple way around this methodological problem. A proper treatment of missing data falls outside of the scope of this tutorial.

332

> # compute correlation between monthly income and building date, > # ignoring incomplete data > cor(sec_bag$Fiscaalmaandinkomen,sec_bag$bouwjaar,use=”complete.obs”) Figure 3 - Monthly income distribution.

As you can see, the correlation is slightly negative. We can not conclude there is any correlation. To illustrate this, let’s plot income and building year on the map to see where the rich people live and where the new buildings are. Mapping the Data To plot values on a map, you can use the qmap function from the ggmap package. This requires you to specify which coordinates to put on the x and y axis of the map plot. qmap uses Google maps, which in turn use WGS84 coordinates, so the x and y coordinates have to use latitude and longitude as well. The ggmap package uses the Grammar of Graphics (GOG) pradigm to combine visualization type, data specification, and styling in a modular way. The implementation

of GOG in R overloads the + operator to “add” up these different aspects of a graphical visualization. In Figure 4 you can see that the rich people prefer to live near to the water, but also in the south of the central part of Amsterdam, “Amsterdam zuid”, specifically in the area south of the Vondel park. We transformed the income logarithmically, to get more definition in the coloring of the higher incomes. If we do the same visualization, but with a square root transform to get a better definition of the coloring of the newer buildings. > qmap(location=’Amsterdam’, zoom=12) + + geom_point(aes(x=long,y=lat,co lour=bouwjaar), + data=sec_bag,size=0.5) + + scale_colour_gradientn(colour s=c(“black”,”green”),trans=”sq rt”) In Figure 5 you can see that Amsterdam clearly grew from the inside out, and that the buildings on the harbor islands are the newest developments. This in combination with Figure 4 shows why there is no conclusive correlation result. Rich people live in the new harbor estates, but also in the old area in Amsterdam zuid, south of the Vondelpark.

Figure 4 - Monthly income per address, unavailable data are shown in gray.

Figure 5 - Year at which the building of each address was built, unavailable data are shown in gray.

7 - Data Aggregation Until now we have dealt with concrete, unaggregated data. However, if we want to answer questions like â&#x20AC;&#x2DC;Which streets have the highest average income?â&#x20AC;&#x2122;, we have to average the income over the addresses per street. There are a few ways to accomplish

this in R, such as the wonderful plyr and reshape packages, but here we will show the simplest way to aggregate data, the built-in aggregate function. The following code applies the mean function to all values in the Fiscaalmaandincome column with the same straatnaam.

334

> > + >

# aggregate the location and income by street name agg_inkomen <- aggregate(Fiscaalmaandinkomen ~ straatnaam, data=sec_bag,mean) head(agg_inkomen,head=5)

straatnaam 1 Aaf Bouberstraat 2 Aagtdorperpad 3 A.A.H. Struijckenkade 4 Aakstraat 5 Aalbersestraat 6 Aalsmeerplein

Fiscaalmaandinkomen 1819.643 2600.000 1700.000 2342.105 1599.673 2700.000

We can do the same aggregation on latitude and longitude to calculate the centroids of the streets. These can then be attached to the aggregated income values with the merge function we introducted in Section 5. > > > > > + + + + >

# aggregate geocoordinates by street name # and join with the aggregated income agg_lat <- aggregate(lat ~ straatnaam, data=sec_bag,mean) agg_long <- aggregate(long ~ straatnaam, data=sec_bag,mean) agg_street <- merge(agg_inkomen, merge(agg_lat, agg_long, by=”straatnaam”), by=”straatnaam”) head(agg_street,n=5)

straatnaam 1 Aaf Bouberstraat 2 Aagtdorperpad 3 A.A.H. Struijckenkade 4 Aakstraat 5 Aalbersestraat

Fiscaalmaandinkomen lat long 1819.643 52.35684 4.820258 2600.000 52.39764 4.956488 1700.000 52.38203 4.812593 2342.105 52.40763 4.911949 1599.673 52.37904 4.797936

Let’s look at the top-25 richest streets of Amsterdam. We can sort a data frame by the values of a column with the order function. If we need them in decreasing order, we can simply add a minus before the column name.

335

> # show the top-25 streets with the highest average income > top_agg <- head(agg_street[order(-agg_ street$Fiscaalmaandinkomen),],+ n=25) > top_agg straatnaam Fiscaalmaandinkomen lat long 487 Chopinstraat 10000.000 52.34760 4.879134 589 David Ricardostraat 10000.000 52.34157 4.826554 1150 Herinkhave 10000 10000.000 52.33059 4.860133 1151 Herman Gorterstraat 10000.000 52.34648 4.883591 1433 Johannes Vermeerplein 10000.000 52.35545 4.883748 1505 Karthuizersplantsoen 10000.000 52.37931 4.881732 1562 Koerierstersplein 10000.000 52.36949 4.907647 1680 Lassusstraat 10000.000 52.35265 4.865783 2165 Ouborg 10000.000 52.32339 4.887754 2442 Richard Wagnerstraat 10000.000 52.34656 4.880149 2500 Rossinistraat 10000.000 52.34574 4.879246 2788 Tesselschadestraat 10000.000 52.36204 4.879180 3027 Verdistraat 10000.000 52.34791 4.880510 3225 Willem Royaardsstraat 10000.000 52.34627 4.884454 657 Diepenbrockstraat 9531.250 52.34542 4.882581 2371 Prins Hendriklaan 9390.323 52.35390 4.862630 1733 Lijnbaansstraat 9100.000 52.36950 4.879062 1057 Hacquartstraat 8890.000 52.35293 4.874257 3250 Withoedenveem 8700.000 52.37615 4.925104 265 Bernard Zweerskade 8588.235 52.34563 4.878846 1904 Memlingstraat 8515.789 52.34969 4.874836 154 Artemisstraat 8478.947 52.34548 4.852965 929 Gaffelaarspad 8400.000 52.33324 4.855981 2979 Van Limburg Stirumplein 8300.000 52.38431 4.874713 1043 Guido Gezellestraat 8200.000 52.34585 4.883473 As a final visualization task, letâ&#x20AC;&#x2122;s plot the top-25 richest streets, labeled with their street name, on the map, rescaling the dots to make them more visible.

336

> > + + + + + + +

# The top-25 highest income streets plotted on the map qmap(location=’Amsterdam’, zoom=12) + geom_point(aes(x=long,y=lat,color=Fiscaalmaandinkomen,size=1), data=top_agg) + scale_colour_gradientn(colours=c(“black”, “green”)) + scale_size(range=8,guide=”none”) + geom_text(aes(x=long,y=lat,label=straatnaam), data=top_agg, size=3,vjust=0,hjust=0)

Conclusion In this tutorial we have treated how to load Linked Open Data from a SPARQL endpoint into R and how to join it with non-linked data from tabular files, such as tabseparated value files, to combine knowledge from multiple sources to answer questions that could not be answered with one data set alone. We have treated basic distribution exploration, correlation between two properties with missing values, and visualization of point data on a map. Finally, we have shown how to do simple aggregation in R. Figure 6: Monthly income aggregated at street level. Shown are the 25 streets with the highest average income.

The data and the R code used for this tutorial (in Sweave format) can be found on the Web, along with other tutorials on SPARQL and R, in the tutorials section of the Linked Science weblog: http://linkedscience.org/.

Acknowledgements Thanks go to Jorik Blaas, Niels Willems, Jesper Hoeksema, for their support with the triple store, data gathering, and visualization.

References ll R; http://r-project.org ll RStudio: http://rstudio.org ll SPARQL: http://www.w3.org/TR/ sparql11-query/ ll CBS SEC: http://bit.ly/16EoKRb ll R-bloggers: http://bit.ly/15gnjoQ

D10 - Pragmatism versus formalism: the relation between Linked Open Data, semantics and ontologies Auteurs

Laura Daniele (TNO) Paul Brandt (TNO) Clearly the central idea behind LOD as well as Ontologies is to facilitate data processing that is grounded in its semantics, e.g., establishing the meaning of data and act accordingly. Ontologies are engineering artifacts that represent the relevant state of affairs in the world, their interrelations and, of course, their significance to the application. Linked open data essentially represents a vision where applications can automatically consume and apply externally published data in a way similar to how humans consume information that has been published on the world wide web. Since both approaches can be considered a means to achieve a similar goal, and hence represent distinct tools, it is necessary to become aware of their differences and similarities before one can decide when, and how, both tools can be applied best. To that end we will investigate the balance between the precision of formalism, coming from the ontological approach, and the speed and readiness of pragmatism, coming from the LOD approach.

This is a preliminary version of this chapter â&#x20AC;&#x201C; the final version will be available online.

The term ontology has been used (and often misused) in many different ways in the literature and on the Internet, so we first characterize ontologies here before we can put them in relation with Linked Open Data.

In a nutshell: what are ontologies? We regard an ontology as an engineering artifact that consists of a set of concepts and definitions used to describe a certain reality, relations among these concepts, plus a set of axioms to constrain the intended meaning of these concepts [1]. Concepts are abstractions of relevant entities in the application domain under consideration and can represent either tangible entities, e.g., a person, a bridge or a piece of paper, or intangible entities, e.g., a color, a flu or a symphony. Moreover, concepts can represent a universal type, e.g., females, but can also be instantiated to represent individuals existing in reality, e.g., the queen Elizabeth II. Relations are relevant associations to be established between concepts and between instances of these concepts, e.g., a marriage between two people and the marriage between John and Alice, respectively. Axioms allow to specify constraints on the

338

usage of concepts and relations, e.g., the number of passengers that can board a Fokker 70 aircraft should not exceed a certain threshold. Ontologies, then, capture mental images of the reality, the so-called conceptualizations in the Ullmann triangle [2] in Figure 1. Conceptualization are abstractions of reality that are based on a set of concepts. However, conceptualizations exist in principle in the mind of those who produce them, but they have to be unambiguously communicated to others. Therefore, conceptualizations require a language that allows them to be represented and communicated as concrete explicit specifications, which we call ontologies. This language should be suitable to represent instances of the concepts underlying the conceptualization and should have a formal Figure 1 - The Ullman Triangle conceptualizations are abstractions of reality, represented in a language

semantics, which allows not only unambiguous interpretation but also rigorous analysis and reasoning.

Using ontologies Ontologies are first of all a conceptual tool that can be used to establish a shared model of consensus among humans in a certain domain [3]. In such cases, an ontology should be represented using a general-purpose language that is expressive enough to represent the domain under consideration, regardless of specific technological platforms. In this way, one can abstract from the ways the ontology might be implemented in order to focus on the concepts, relations and axioms that need be specified, ignoring the issue of selecting the most suitable language to express them.

Figure 2 - A map of a city tube: an example of a representation of a conceptualization, using a (visual) language that refers to a certain portion of reality

Secondly, ontologies can be used as a means for establishing interoperability among multiple heterogeneous systems. In this case, an ontology provides a reference model that allows translation and matching, possibly automatically, among multiple heterogeneous systems [4, 5] that have been developed based on different semantic representations. Different systems should be integrated using interfaces that specify the information necessary for interoperability and these interfaces should be built upon a shared model of consensus that is specified by the ontology. In order to allow automated translation

and matching, the ontology needs to be represented (implemented) using a language that can be processed by machines. Finally, ontologies are used to specify and share knowledge about a certain domain in order to facilitate automated reasoning by inference engines {Uschold:2004dx}. This comes very close to application of artificial intelligence, and indeed a popular view is to consider ontologies a subarea of AI where they are applied as knowledge representation backbone, serving as vehicle for carrying domain knowledge.

340

The language underlying a model Ontologies, like any other model, need a language for their representation. More precisely, the concepts underlying a certain conceptualization need to be mapped onto the elements of a suitable language. For example, the concept of a motor vehicle as a kind of object that moves on its own for the purpose of transporting people, can be referred to by using the term car (English), auto (Dutch), or macchina (Italian). The ontological commitment of a given language, namely the entities the primitives of a language commit to the existence of [6], influences the expressiveness, accuracy and complexity of the ontology that is being represented. For instance, the original entityrelationship model commits to a view that accounts for the existence, in the world, of entities, relations and properties; nothing more and nothing less. Consequently, temporal aspects cannot be distinguished. Although the database engineer will be able to create a database schema that can store relations to time, it is important to note that this is an artificial model, a codification artifact, as opposed to a conceptual model representing a truthful abstraction of time. The database schema, no matter the qualifications of the database engineer, can never be expected to describe time accurately since the language lacks a decent construct for it. Hence, in order to understand the possible ap-

â&#x20AC;&#x2DC;The point here is that the choice of a particular codification language can only be justified as a design choice. To put it baldly, the question is not whether, for instance, OWL is good or not for representing ontologies. The question is whether OWL is justifiable as an adequate design choice in a specific design scenario.â&#x20AC;&#x2122; - G. Guizzardi [12] plications for which ontologies can be used, one needs to understand their underlying representational language. Depending on that language, then, ontologies range from being highly informal, namely loosely expressed in natural language, to rigorously formal, namely strictly expressed using formal semantics, theorems and proofs. Informal ontologies may lead to ambiguities, and systems that are based on such ontologies are more error-prone than systems based on formal ontologies, which, in contrast, allow automated reasoning and consistency checking. However, there is a trade-off between the expressiveness of a language and its computational power: the more expressive the language, the more complex to process it using machines, up to and beyond the point that its expressive power exceeds the computational power of the machines.

Figure 3 - A range of different kind of ontologies, their complexity and support for automated reasoning

Different kinds of ontologies Several ontology forms are currently used in information systems and on the Web, with varying expressiveness and complexity. These ontologies span from simple catalogues of concepts related by subsumption relationships, to complete representations of concepts related by complex relationships, including axioms to constrain their intended interpretation. This has been depicted below (taken from [7]). Going from left to right on this scale, with increasing complexity (i.e., increasing amount of meaning that can be specified), at some point an informal language becomes insufficient to unambiguously express the semantics with the required level of accuracy. Therefore, the degree of formality

should increase, providing also more and better support for automated processing of the ontology. The socalled â&#x20AC;&#x2DC;lightweight ontologiesâ&#x20AC;&#x2122; as being used in the Semantic Web are usually less complex ontologies represented in the form of a catalog, thesaurus or taxonomy, possibly with a few logical constraints, and are expressed in languages that allow the ontology to be interpreted by machines, such as OWL and RDF. These languages have limited expressiveness that results from their humble ontological commitment, and can therefore carry large ontologies due to the mentioned trade-off with computational power. Hence lightweight ontologies can be easily and readily processed by machines, but remain limited in their expressiveness and their ontological commitment.

342

The case of Linked Open Data LOD and RDF are powerful technologies conceived for publishing and exchanging data between machines. As a means for establishing interoperability, LOD are therefore commonly associated with ontologies. However, ontologies are not LOD. Ontologies can be implemented using LOD, making it one out of more possible technological platforms of choice. LOD and RDF are a way to implement lightweight ontologies. In case of RDF as underlying modeling language, the statements that can be formulated express binary relationship instances. As explained in [8], these statements are represented as (subject, predicate, object) triples, where subjects and predicates are so-called resources, and objects are either resources or literals (constants). Resources are ‘(…) treated here as synonymous with ‘entity’, i.e. as a generic term for anything in the universe of discourse’ (http://bit.ly/11Mn7wr, accessed June 14, 2013), and, can be identified by Uniform Resource Identifier (URI) references. Literals may be untyped (e.g., ‘Netherlands’) or typed (e.g., ‘42’^^xsd:Integer), and are considered to ‘denote themselves’2, which implies that their semantics is considered to be self-explanatory.

The ontological commitment of a language is to be sought in its primitives, and in case of RDF we should consider resources and literals as its primitives. The RDF language, therefore, is suitable to represent lightweight ontologies, but is insufficient to cater for the accuracy and expressiveness that are required for more rigorous ontologies with high ontological commitment [9, 10]. Therefore, one should be aware that RDF is a powerful tool to link data using triples, and is driven by the pragmatism of providing timely technological solutions, rather than the precision coming from the world of formal ontologies. As a result, RDF is a suitable tool to improve the accessibility of the data that one wants to publish on the Web. Moreover, RDF enables interoperability to big data stores since it has been widely acknowledged as de-facto standard for semantic representations of data on the Web. However, one should be aware of the limits of the RDF semantic representation, which introduces risks of datasets redundancy, inconsistency, ambiguity and potential false agreements [6, 11]. These problems should not be underestimated because sooner or later they may grow out of proportion and, eventually harm an effective interoperability instead of enable it.

343

In conclusion: When to use ontologies, when to use LOD? Formal ontologies are a powerful tool to represent a limited portion of reality (small/medium ontologies) with lots of details (high precision) using languages that allow to express concepts, relationships between these concepts and axioms to constrain the intended meaning of these concepts. Formal languages allow ontologies to be machine interpretable, enabling automated reasoning and consistency checking, while informal languages are more suitable and expressive for human communication, allowing an ontology to be a shared model of consensus among people rather than an artifact interpretable by machines. LOD, at the other hand, are more suitable to represent a big portion of reality (big, lightweight ontologies) with not much details (low precision) using subject/predicate/object triples. Since formal ontologies allow high precision and ontological commitment, there is a bigger chance to make mistakes and introduce inconsistencies, so one should carefully check the correctness and consistency of the ontology, possibly using automated tools. In contrast, the pragmatics of LOD allow for course-grained semantics that is not very accurate, and, therefore, leaves limited room for mistakes (in other words, what you do not state

cannot be wrong). This is currently the reason for the success of LOD, however in future will represent the source of emergent false agreements. By then, hopefully, tooling will become available that will assist us in turning this massive LOD data set into something that is based upon a more formal ontological commitment to cater for fine-grained semantics, and that does so with high accuracy and without mistakes: ‘The quality of any implementation artifact based on a model is ultimately bound by the quality of that model.’ [12]

References [1] N. Guarino, ‘Formal Ontology in Information Systems’, in Proceedings of the 1st International Conference on Formal Ontology in Information Systems (FOIS), 1998, pp. 3-15. [2] S. Ullmann, ‘Semantics: An Introduction to the Science of Meaning’, Barnes & Noble, 1979. [3] R. Burkhard and M. Meier, ‘Tube map: Evaluation of a visual metaphor for interfunctional communication of complex projects’, in Proceedings of I-KNOW’04, 2004. [4] A. M. Ouksel and A. Sheth, ‘Semantic interoperability in global information systems’, ACM SIGMOD record, vol. 28, nr. 1, pp. 5-12, mrt. 1999.

344

[5] M. Uschold and M. Gruninger, ‘Ontologies and semantics for seamless connectivity’, ACM SIGMOD record, vol. 33, nr. 4, p. 58, dec. 2004. [6] G. Guizzardi, Ontological foundations for structural conceptual models, CTIT, Centre for Telematics and Information Technology, 2005. [7] B. Smith and C. Welty, ‘Ontology: Towards a New Synthesis’, in Proceedings of the international conference on Formal Ontology in Information Systems - FOIS ‘01, 2001, vol. 2001, pp. 3-9. [8] C. Bizer, T. Heath, and T. BernersLee, ‘Linked data-the story so far’, International Journal on Semantic Web and Information Systems (IJSWIS), vol. 5, nr. 3, pp. 1-22, 2009.

[9] H. Kim, ‘Pragmatics of the Semantic Web’, in Semantic Web Workshop, 2002, pp. 1-2. [10] P. Jain, P. Hitzler, P. Z. Yeh, K. Verma, and A. P. Sheth, ‘Linked Data Is Merely More Data’, in AAAI Spring Symposium on Linked Data Meets Artificial Intelligence, 2010, pp. 82-86. [11] N. Guarino, D. Oberle, and S. Staab, ‘What is an Ontology?’, in in Handbook on Ontologies, 2009. [12] G. Guizzardi, ‘Theoretical foundations and engineering tools for building ontologies as reference conceptual models’, Semantic Web, vol. 1, nr. 1, pp. 3-10, jan. 2010.

Samenwerking cruciaal voor Linked Open Data Interview met

Joop Vanderheiden (RCE) Bart Broex (RCE) Auteur

Lian Pattje ‘De Rijksdienst voor het Cultureel Erfgoed (RCE) experimenteert al enige tijd met Linked Open Data’, vertellen Joop Vanderheiden en Bart Broex, beide werkzaam bij de RCE. ‘Het is een praktische manier om een bijdrage te leveren aan een web van verbanden, het semantische web. Informatie die als Linked Open Data wordt gepubliceerd, stimuleert het hergebruik van data, omdat we verwijzingen leggen naar andere kennisbronnen en omdat anderen gemakkelijk naar onze informatie kunnen verwijzen’, aldus Bart Broex. ‘Linked Open Data zijn niet alleen van de Rijksdienst, van Nederland of van Europa’, zegt Joop Vanderheiden. ‘Het is een wereldwijd fenomeen, waarbij we eigen data openzetten voor gebruik voor en door anderen. Linked Open Data gaat over ‘naar buiten treden’ en over verbinden, verbinden en nog eens verbinden.’

Linked Open Data Met Linked Open Data wordt het hergebruik van data gestimuleerd, doordat er zoveel mogelijk verwijzingen van en naar kennisbronnen gemaakt worden. Linked Open Data maakt van woorden, zoals de stad ‘Den Haag’, unieke concepten. Elk concept wint aan betekenis als er meer beschrijvingen aan gelinkt worden. Daardoor krijgt de inhoud van webdocumenten meer betekenis en worden zoekresultaten nauwkeuriger. Het maakt dan niet meer zoveel uit of er op Den Haag of The Hague gezocht wordt.

Erfgoed Voor de erfgoedsector ligt de meerwaarde van Linked Data in het kunnen linken van objecten uit verschillende collecties aan elkaar en aan data die van buiten de sector afkomstig zijn. Joop Vanderheiden, coördinator Kennissystemen, vertelt dat vroeger iedereen op zijn eigen data ‘zat’. Vooral archeologen waren terughoudend met het openbaar maken van archeologische vindplaatsen, in verband met mogelijke beschadigingen. ‘Wij hebben veel van onze informatie opengesteld, zodat die kan worden gecombineerd met informatie van andere partijen: Linked Open Data. Door gegevens te ontsluiten, komen we steeds verder. En het levert ook veel reacties op. Bij-

346

voorbeeld dat er nog een klooster uit een bepaalde eeuw is, maar dat nog niet in de database staat. Dergelijke reacties maken onze informatie weer beter en completer.’

Layartechniek Voorbeelden van wat je met Linked Open Data kunt, zijn Europeana (www.europeana.eu), het Europese platform voor cultuur en erfgoed en Rijksmonumenten.info.’ Bart Broex, specialist geografische informatie van de RCE, legt uit: ‘Rijksmonumenten. info maakt gebruik van diverse beeldbanken zoals Wikipedia, beeldbank van Amersfoort en onze beeldbank. Via een applicatie die gebruik maakt van layartechniek ontsluit je de informatie. Sta je bijvoorbeeld voor de Koppelpoort in Amersfoort, dan kun je via de app op je telefoon alle informatie over de Koppelpoort zien.’

Samenwerking ‘Via CARARE (www.carare.eu),dat onder Europeana valt, wordt digitale informatie over architectuur en archeologie breed bekendgemaakt’, aldus Bart Broex. ‘Daarbij zit onder andere een 16e eeuws klooster in België. Via gelinkte informatie zie je dat zich in Duitsland een soortgelijk klooster bevindt, in dezelfde bouwstijl.’ Joop Vanderheiden vult aan dat samenwerking tussen diverse partijen zeer waardevolle informatie kan opleveren. ‘Zo zou TNO verkeersstromen langs monumenten kunnen

gaan registreren. Daar kan uit naar voren komen dat bepaalde delen van monumenten door de luchtvervuiling meer verweren dan andere. Data van de RCE over de locatie van monumenten, gecombineerd met onderzoeksgegevens van TNO, kan interessante informatie opleveren die van belang is voor het onderhoud van gebouwen. Ook de samenwerking met het 3TU datacentrum van de TU Delft kan interessante gegevens opleveren over de invloed van neerslag op de verwering van monumenten. Het is nog toekomstmuziek, maar dergelijke samenwerkingen kunnen wel erg waardevolle informatie voortbrengen.’

Wens ‘We moeten vooral niet bang zijn om data te publiceren’, is Joop Vanderheiden van mening. ‘Wij hebben niet de wijsheid in pacht en juist door het samen te doen, komen we verder. Het gaat er uiteindelijk om dat we kennis toegankelijker maken, voor een breed publiek. Maar dan moeten we beginnen met het open maken van data. Mijn wens is dan ook om andere partijen te vinden en om samen te weken. Alle data op één hoop, daarmee aan de slag gaan en kijken wat er uitkomt… Het zou mooi zijn als we via de Pilot Linked Open Data partijen vinden met wie we aan de slag kunnen.’

Tijd is rijp voor Linked Open Data Interview met

Frank van Harmelen (Vrije Universiteit, Amsterdam) Auteur

Lian Pattje Hoogleraar Frank van Harmelen aan de Vrije Universiteit, Faculteit der Exacte Wetenschappen, werkt al zeker tien jaar aan wetenschappelijk onderzoek naar RDF (Resource Description Framework) en Open Data. De laatste tijd zien we steeds vaker toepassingen op dit gebied. Maar waarom zijn die nu ‘pas’ zichtbaar? Waarop hij lachend antwoordt: ‘Nú al zul je bedoelen. Voor veel sectoren, zoals voedsel, medicijnen, energie, is een periode van tien jaar echt niet veel. Eigenlijk is dat best snel. Kijk maar eens hoe lang er al zonnecellen op de markt zijn. En nu, zo’n vijftien jaar later, leggen we ze meer en meer op onze daken. Dat sneeuwbaleffect verwacht ik binnenkort ook met Open Data.’ ‘De ontwikkelingen rond Open Data vergelijk ik met een kar die we de heuvel op aan het duwen zijn. Dat is duwen, duwen en nog eens duwen tot ie op de top staat. En dan komt het moment dat die kar met een noodgang de heuvel af gaat en dat je moet rennen om hem bij te houden.

Dat omslagmoment is nu met Open Data bereikt. Die ‘kar’ staat op de top en kan elk moment als een sneeuwbal naar beneden gaan rollen. De tijd is er rijp voor. Internationaal gezien neemt Open Data een enorme vlucht. Ik denk wel dat we in Nederland flink vaart moeten gaan maken. We zitten op dit moment wat achter in het peloton. Maar Nederland is een goed georganiseerd land, de data zijn goed op orde, vooral de gemeentelijke basisgegevens en de geografische en kadastrale data. Er is een goede voedingsbodem, dus laten we beginnen om die inhaalslag te maken.’

Pilot als katalysator Volgens Van Harmelen is een initiatief als de Pilot Linked Open Data zeer welkom, omdat die kan dienen als katalysator. ‘Ik heb mijn hoop echt gevestigd op die zaal vol mensen die steeds bij de bijeenkomsten van de Pilot Linked Open Data aanwezig zijn. Die ‘gewone’ mensen van veel (semi) overheidsorganisaties die laten zien dat hun werk nog nuttiger wordt met Linked Open Data, dat is belangrijk. Het besef moet van onder naar boven organisaties binnendringen. Want kijk, de techniek is geen belemmering meer voor het openstellen van data. Het online zetten van een spreadsheet kan iedereen. Wel geef ik toe dat de technische drempel voor Linked Open Data nog vrij hoog is. Gelukkig komen er wel steeds meer (midden- en kleine) bedrijven

348

die de technologie snappen en die daar diensten voor verlenen. Het zou mooi zijn als zij die techniek bij al die gemeentehuizen en overheidsinstellingen binnen fietsen…’

Beter gebruik van data ‘De overheid gebruikt data over bijvoorbeeld bevolking, stadsdelen of natuur, vaak voor eigen doeleinden om er beleid mee te maken of om het te kunnen monitoren’, legt Van Harmelen uit. ‘Veel (semi)overheden, cultuurinstellingen, dienstverleners en de gezondheidszorg bieden data aan die interessant kunnen zijn voor bepaalde groepen. Zo zijn ziekenhuizen tegenwoordig verplicht om data te publiceren over de kwaliteit. Dat is interessant voor patiëntenverenigingen want dat maakt het mogelijk om verschillende ziekenhuizen gemakkelijker met elkaar te vergelijken. En zo zijn data van overheden bijvoorbeeld interessant voor politieke partijen of bepaalde belangengroeperingen. In de wereld van grote organisaties zoals ziekenhuizen maar ook universiteiten weet de linkerhand vaak niet wat de rechterhand doet. Door beter gebruik te maken van data, kun je veel fricties wegnemen. Waarom zou je data niet beschikbaar willen stellen voor een ander?’

Onverwacht hergebruik ‘Ik zeg altijd: het openlijk beschikbaar stellen van data, levert vaak ‘onverwacht hergebruik’ op. Je zult nog versteld staan van wat een ander van ‘jouw’ data kan maken. Een mooi voorbeeld is de website fixmystreet. com. Hier kunnen burgers problemen in de wijk online signaleren. Bijvoorbeeld een oude bank die al weken langs de weg staat en steeds niet wordt meegenomen door het grofvuil. Dit wordt dan door iemand gerapporteerd als open data. De gemeente kijkt vervolgens naar de reports op de website en gaat er mee aan de slag. Op die manier los je alledaagse problemen samen op. Waarom stellen ziekenhuizen wachtlijsten niet als open data beschikbaar? Patiëntenverenigingen zouden er veel baat bij hebben, want patiënten kunnen dan veel gemakkelijker zien waar ze snel geholpen kunnen worden voor een bepaalde behandeling. En zo vallen er nog legio mogelijkheden te bedenken.’

Web van data ‘In plaats van data openbaar te maken, zijn ze nu juist nog vaak weggestopt. Hierdoor kunnen mensen van buiten er niet bij. En de mensen die wel toegang hebben, kunnen vaak maar bij één dataverzameling, waardoor het niet mogelijk is om verschillende datasets te combineren. Het zijn allemaal aparte silo’s met data die niet aan elkaar gelinkt zijn. We streven juist naar Open Data, en

349

liever nog een stap verder: Linked Open Data. Bij Open Data wordt data in algemeen toegankelijke formats gepubliceerd, waardoor mensen er gemakkelijk bij kunnen. Door die open data dan vervolgens ‘te linken’, zorg je dat er verbanden worden gelegd tussen al die data. Eigenlijk zouden data net zo gemakkelijk te vinden moeten zijn als je websites vindt al surfend over het internet. Het WWW is een web voor tekst en plaatjes is: open en onderling verbonden. Hetzelfde geldt voor Linked Open Data, maar dan in de vorm van een web voor data.’

Standaarden ‘En waarom het web nou zo goed werkt? Omdat we een aantal afspraken hebben gemaakt waar iedereen zich aan houdt’, aldus de hoogleraar. ‘We hebben gekozen voor HTML als gemeenschappelijke taal, en webadressen beginnen altijd met http://. De rol van standaarden is de interoperabiliteit. Dat is dus interoperabiliteit zonder dat mensen elkaar hoeven te kennen of spreken. We houden ons aan die afspraken, die standaarden. En als iedereen zich er aan houdt, dan werkt het. En zo is het ook voor data. Tot en met de vijf sterren (van Tim Berners-Lee) zijn er goed bruikbare standaarden voor het publiceren van data, die wereldwijd gebruikt worden. Een technische barrière is er niet. Nu nog de adoptie: mensen moeten het willen, het willen gebruiken.’

Geodata centraal ‘Linked Open Data zal geen buzzword worden. Die illusie heb ik niet. Zo is ook HTML geen alledaags woord geworden. Maar als je ziet wat het ons heeft gebracht? De dienstverlening die ontstaat door Linked Open Data is enorm. Daar zit nog een gat in de markt’. Frank van Harmelen is optimistisch over de toekomst van Linked Open Data. ‘Die kar is over de heuvel en gaat nu vaart maken. Nederland gaat een inhaalslag maken, terwijl Europa enorm duwt. Europese instanties publiceren al veel in open data formaat, daar wordt veel in geïnvesteerd. Economisch gezien, zal dit een interessante sector worden. Ik zie kansen voor datamakelaars die gaan bemiddelen in vraag en aanbod, maar ook voor het midden- en kleinbedrijf. Daar zit de innovatie. Op sommige momenten ben ik heel optimistisch en dan denk ik dat er een omslag zal komen. Dan zijn data altijd open, op enkele uitzonderingsgevallen na. En geodata spelen hier een bijzondere rol in, want locatie neemt altijd een centrale rol in bij het aan elkaar koppelen van data. Geodata is de spil.’

Slimmer (her)gebruiken met linked data Interview met

Hayo Schreijer (KOOP) Auteur

Lian Pattje ‘De overheid koopt enorm veel data in en produceert zelf ook veel data. Dat leidt tot veel informatie in heel veel losse bronnen, waardoor overheidsfunctionarissen door de bomen het bos niet meer zien. Zij kunnen informatie niet gemakkelijk vinden en ook de bruikbaarheid is onvoldoende. Dit zorgt voor veel tijdverlies en dus geldverspilling’, aldus Hayo Schreijer, projectleider Linked Data bij het Kennis- en exploitatiecentrum voor Officiële Overheids Publicaties (KOOP). KOOP is door het Ministerie van Financiën gevraagd om te helpen met het oplossen van de problemen rondom het gebruik van overheidsinformatie zoals weten regelgeving, officiële publicaties en jurisprudentie. Hiervoor is het project Linked Data Overheid opgestart.

‘De overheid kan flink besparen door eigen informatie beter en slimmer te structureren en te hergebruiken. Wanneer overheidsinformatie bovendien meer gedeeld wordt, kan dit ook leiden tot meer afstemming in beleid en weten regelgeving’, legt Schreijer uit. ‘Het project Linked Data Overheid wil op de korte termijn een betere structuur in overheidsinformatie realiseren met meer samenhang. Dat doen we met behulp van linked data, waarbij we verschillende informatiebronnen op basis van links naar weten regelgevingaan elkaar koppelen. Door informatie zoals beleidstukken, voorlichting, jurisprudentie en uitvoeringsaanwijzingen in relatie tot weten regelgeving te presenteren, bieden we een samenhangende en effectieveinformatievoorziening voor overheidsfunctionarissen. Het werk van deze mensen is namelijk gerelateerd aan weten regelgeving. De bijdrage die dit levert aan de kwaliteit van de regels en uitvoering ervan is echter een vergezicht.’

Kracht van linked data Volgens Schreijer is de essentie van dit project dat de overheid haar eigen overheidsinformatie beter gaat structureren en(her)gebruiken. ‘Een overheidsfunctionaris weet als geen ander met welke weten regelgeving zijn werk te maken heeft. Wij vragen hem om dit expliciet te maken met een ‘duurzame’ link naar de betreffende regelgeving. Duurzame links

351

zorgen voor minder beheer en archiveringskosten. En de overheidsfunctionaris krijgt daar iets voor terug, want ook collega’s maken deze links naar weten regelgeving expliciet. Dat leidt tot kennisdeling en uiteindelijk tot minder werk voor iedere individuele kenniswerker. Nu raadpleegt een overheidsfunctionaris Google en verschillende andere bronnen en vindt veel zoekresultaten waarvan onduidelijk is of deze relevant zijn en wat de bron ervan is. Zoeken naar informatie is daardoor een tijdrovend en onzeker proces.En daar komt bij dat veel bronnen ook nog eens kopieën van de oorspronkelijke weten regelgeving en jurisprudentie maken. Wij stimuleren overheidsfunctionarissen dus om gebruik te maken van eigen overheidsinformatie en de links die collega’s hebben gelegd naar relevante informatie.’

Hergebruik en transparantie ‘Een ander effect van linked data is dat het leidt tot hergebruik, als je in het werkproces laat zien wat anderen doen. Een beleidsmedewerker van de SVB, een medewerker van UWV of de Belastingdienst, geven vaak uitvoering aan gerelateerde weten regelgeving. Als je inzichtelijk maakt wat een ander doet of hoe een ander iets heeft gedaan, dan is de kans groot dat dit leidt tot hergebruik. Ten slotte zorgt linked data voor transparantie.’ Hayo Schreijer licht het toe:‘Omdat informatie in samenhang wordt

getoond, is de oorsprong en toepassing ervan makkelijker te begrijpen. En als je bijvoorbeeld kunt laten zien dat rondom een beleidsonderwerp al rechtszaken gevoerd zijn, door een link naar jurisprudentie te tonen, kan een ondernemer of burger een betere afweging maken of het nuttig is om te procederen.’

Aan de voorkant ‘Dit project laat de samenhang zien tussen verschillende bronnen - met behulp van linked data - aan overheden, maar ook aan burgers en ondernemers. We pretenderen geen problemen in weten regelgeving te kunnen oplossen, we maken het alleen inzichtelijk. Daarbij doen we één ding wel echt heel anders. We willen de kwaliteit van de bronnen, de kwaliteit van de links, verbeteren. En daarom beginnen we aan de voorkant, bij de jurist of beleidsmedewerker die overheidsinformatie produceert. We vragen die jurist of beleidsmedewerker om de links naar weten regelgeving nu expliciet te maken en daar ondersteunen we bij. Dus kijken we al mee op het moment dat die links gecreëerd worden, in plaats van dat we wachten tot de informatie beschikbaar is en we met rekenkracht van computers de betekenis van verwijzingen in de tekst moeten achterhalen.’

352

At your service

Kennis delen

‘Om de kwaliteit van links te verbeteren, bieden we een service aan. We helpen kenniswerkers om duurzaam te linken, met zogenaamde URI’s (Unique Resource Identifier). Daarbij zorgen we er tegelijkertijd voor dat de links naar de juiste versie van weten regelgeving blijven verwijzen. Bovendien hebben wij de service in een vorm ‘gegoten’ waar ook marktpartijen, die toegevoegde waarde op de overheidsinformatie produceren, gebruik van kunnen maken.’ Schreijer spreekt nadrukkelijk van een ‘service’ en niet over software. ‘De services zijn bruikbaar in de software van marktpartijen die deze aan overheden leveren, want de overheid is geen softwareleverancier. Het nadeel van een service is wel dat deze niet eenvoudig voor een gebruiker te demonstreren is. Daarom ontwikkelen we nu een demoportaal. Naast de service om makkelijk links te maken, levert het project nog twee services. Eén service levert gerelateerde links bij een wetgevingsonderdeel. Geef aan deze service een trefwoord of een onderdeel van de wetgeving, en je krijgt een lijst met gerelateerde links terug. En de tweede service is voor het attenderen van organisaties die linken naar een wetonderdeel, als er wijzigingen in de informatie optreden.’

‘We vinden het van belang om gedurende het project ook kennis uit te wisselen met andere partijen en organisaties. Onze deelname aan de Pilot Linked Open Data heeft dan ook zeker meerwaarde. De geo-wereld, als initiatiefnemer van de Pilot, is voor ons een interessant domein omdat deze al zes stappen voorloopt met linked data, vanwege de van nature aanwezige ‘links’ met geo-locaties. Maar ook voor de geo-wereld leveren wij interessante content. Zo is het zinvol om te weten welke weten regelgeving er op een bepaalde locatie geldt. Verder is het van strategisch belang om samen te werken aan een betere samenhang, toegankelijkheid en structuur van overheidsinformatie. Dat kunnen we doen door deze zowel duurzaam te linken met geo-locaties, weten regelgeving als ook met de begrippen in de basisregistraties. Dat zouden, wat ons betreft, de uitkomsten van de Pilot moeten zijn.’ Hayo Schreijer is projectleider Linked Data en Open Data bij het Kennis- en exploitatiecentrum Officiële Overheids Publicaties (KOOP). KOOP is onderdeel van het Ministerie van BZK en exploiteert onder andere de portalen www.wetten.nl en www.officielebekendmakingen.nl, de digitale Staatscourant.

Linken van data is complex maar leerzaam proces Interview met

Willem Melder (Nederlands Instituut voor Beeld en Geluid) Auteur

Lian Pattje

Een thesaurus is een gecontroleerde woordenlijst die gebruikt wordt om het exacte woord voor een voorwerp (een bepaalde vakterm) te vinden. Dus Naturalis heeft een thesaurus voor de biodiversiteit, NIOD een oorlogsthesaurus en wij hebben een audiovisuele variant.’

Vanuit het project Digitale Collectie Nederland wilden we onder andere de collecties van het Nederlands Instituut voor Beeld en Geluid en de Rijksdienst voor het Cultureel Erfgoed (RCE) verzamelen en doorzoekbaar maken. Ons doel is om een nationaal verzamelpunt te creëren. Door context te bieden aan onze collecties en door te linken naar andere collecties, willen we de archieven hergebruiken, verbonden raken met andere archieven en uiteindelijk zelf meer gevonden en bezocht worden’, aldus Willem Melder, projectleider en software engineer van het Nederlands Instituut voor Beeld en Geluid. ‘En zo zijn we het project Demonstrator Linked Data gestart.’

‘Al snel bleek dit makkelijker bedacht dan te realiseren. Er bleken veel haken en ogen te zijn. Je kunt namelijk niet rechtstreeks linken van de ene naar de andere collectie. Want de ene organisatie hanteert een open formaat en de andere een gesloten. En diverse organisaties spreken verschillende ‘talen’. Zo gebruiken wij SKOS, een taal die op RDF gebaseerd is, waar iedereen bij kan en die uitwisselbaar is. Het is dus de kunst om de kennis van verschillende domeinbeheerders in RDF weer te geven met URI’s (Unique Resource Identifiers) en uitgedrukt in standaard dataschema’s , zodat je precies weet naar welke informatie verwezen wordt. We moeten leren om onszelf uit te drukken in een universele taal. Maar jarenlang heeft iedereen dat op zijn eigen manier gedaan...’

‘Twee collecties van twee instellingen, met ook nog eens twee verschillende thesauri aan elkaar verbinden, uitwisselbaar en doorzoekbaar maken. Daar wilden we mee beginnen’, legt Melder uit. ‘Elke erfgoedinstelling zoals RCE, Naturalis en ook Beeld en Geluid heeft een eigen thesaurus.

Willem Melder vertelt dat ze er gaandeweg achter kwamen dat zowel in de thesaurus van de RCE als in die van Beeld en Geluid ‘locaties’ zijn verzameld. ‘Bij ons zijn die volgens een bepaalde structuur verzameld,maar die van de RCE bevat veel meer

354

geografische gegevens met meer niveaus. Dus beide thesauri hebben een label ‘Utrecht - Nederland’, alleen de ene thesaurus heeft ook ‘Utrecht - plaats’ en ‘Utrecht - provincie’. Dus dan weet je nog niets. Welk Utrecht wordt bedoeld? Het is belangrijk om de juiste relaties te leggen tussen twee structuren. En het lastige daarvan is dat die begrippen door verschillende mensen met verschillende ideeën gemaakt zijn. Ze bevatten veel impliciete kennis van die mensen. Dus automatiseren is moeilijk, want het gaat om veel ‘concepten’ en termen.’ ‘Verder ontdekten we dat het lastig bleek om de ene aan de andere collectie te linken, omdat de RCE een beschrijving van een monument had en wij een video. Hoe koppel je die? We kwamen op het idee om de geografische informatie te gebruiken, van zowel het monument als de video, zodat we de erfgoedlocaties konden tonen op een kaart’, aldus Melder. ‘Op die manier maakten we het mogelijk om de collecties te linken via de gemeenschappelijke kenmerken van de locatie. Voor het tonen van een exacte locatie heb je echter meer nodig dan alleen een plaatsnaam. Onze data was eigenlijk niet precies genoeg. Dus besloten we voor elke locatie de bijbehorende longitude en latitude dat zijn de x- en y-coördinaten die ook voor GPS worden gebruikt -te gebruiken. De crux van linked data is dat je heel precies moet omschrijven

en dus moet je heel goed weten waar je het over hebt. Alleen aan ‘Amsterdam’ heb je niets, want waar heb je het dan over? De plaats, de provincie of misschien wel een hockeyclub? Je moet dus de exacte locatie toevoegen aan een object.’ Melder: ‘Een ander voorbeeld is dat de video’s uit onze open beeldencollectie een veld bevatten met ‘plaatsnaam’, bijvoorbeeld Kinderdijk. Dan weet je alleen nog niet wat precies bedoeld wordt. Het is een letterlijke term. Wat we gedaan hebben, is het label ‘Kinderdijk’ vervangen door een resource description en die resource hebben we een URI gegeven, zodat je iedere resource uniek kunt onderscheiden. Voor Kinderdijk is dat bijvoorbeeld in onze GTAA thesaurus (Gemeenschappelijke Thesaurus Audiovisuele Archieven): http://data. beeldengeluid.nl/gtaa/37605. Deze URI is te resolven, zodat een weergave van het concept op het web beschikbaar is. Elke video bevat een verwijzing naar een concept, een resource. En een resource bevat een geografische locatie. Op die manier kunnen we een video op een kaart ‘pinnen’. Je weet dan nog steeds niet de precieze link tussen de video en die plaats, maar je weet dat er een relatie is. Als je dat voor alle collecties doet, kun je voor elke plek interessante erfgoedobjecten bepalen.’

355

‘We hebben al doende geleerd dat het heel belangrijk is om een URIstrategie te hanteren binnen onze collectiesystemen. Door URI’s te gebruiken, kun je op een unieke manier naar een resource verwijzen en ze daardoor uniek onderscheiden. Het belangrijkste dat ik van deze pilot heb geleerd is dat de informatie die in erfgoedcollecties ligt opgeslagen nog te vaak alleen binnen het eigen systeem te gebruiken is. Om de informatie als linked data aan te bieden, en daarmee de collectie in potentie te linken aan de rest van de wereld, moet nog aan de data gesleuteld worden. De genoemde URI-strategie is het begin. Ook het uitdrukken van de data in RDF en universele gebruikte schema’s is een belangrijke stap. Wat we nog niet genoemd hebben, is dat de data bij voorkeur ook als open data beschikbaar moet zijn. Dan kan er ook daadwerkelijk door de rest van de wereld gewerkt kan worden aan links tussen erfgoed wereldwijd.’

Alfabetische lijst van auteurs Anne Fleur van Veenstra (TNO)

157

Arjen Santema (Kadaster)

273

Bart Broex (RCE)

345

Bart van Leeuwen (Netage) Bas Geerdink (CSC) Chris van Aart (2CoolMonkeys) Christophe GuĂŠret (DANS / Free University Amsterdam) Clemens Portele (Interactive Instruments) Erwin Folmer (Geonovum / TNO / Universiteit Twente) Florian Bauer (REEEP)

103 224 85 + 218 174 + 202 253 + 264 + 304 103 + 157 65

Frank van Harmelen (Vrije Universiteit, Amsterdam)

347

Hans Overbeek (KOOP)

240

Hayo Schreijer (KOOP)

350

Henk Nijstad (Kennisnet / Bureau EduStandaard)

116

Jans Aasman (Franz Inc)

211

Jeroen Hamers (Kennisnet / Bureau EduStandaard)

116

Jeroen van Vuuren (Verdonck, Klooster en Associates)

116

John van Echtelt (CGI) John Verhoeven (Inspiring Data) John Walker (NXP Semiconductors) Joop Vanderheiden (RCE)

92 + 146 224 153 135 + 345

Jos van der Arend (Kennisnet / Bureau EduStandaard)

116

Kees Hendriks (RCE)

135

Laura Daniele (TNO)

337

Leonie Verhoeff (Kennisnet / Bureau EduStandaard)

116

357

Lian Pattje (Geonovum)

103 + 345 + 347 + 350 + 353

Lieke Verhelst (Linked Data Factory) Linda van den Brink (Geonovum) Marcel van Mackelenbergh (Belastingdienst) Marcel Reuvers (Geonovum) Marijke Salters (Bureau Forum Standaardisatie) Martin Kaltenbรถck (Semantic Web Company)

192 240 + 311 284 253 + 264 105 65

Michiel van Dijk (2CoolMonkeys)

218

Nico Verbeij (Verdonck Klooster & Associates)

135

Patrick Mout (RCE)

135

Paul Brandt (TNO)

337

Paul Francissen (Envolve)

Paul Geurts (Gemeente Nijmegen)

Paul Hermans (ProXML)

181

Paul Janssen (Geonovum)

311

Pieter van Everdingen (OpenInc)

146

Reind van Olst (2CoolMonkeys)

218

Ria van Rijn (Atelier Helder Informatie Architecten)

273

Rinke Hoekstra (Vrije Universiteit)

284

Roel Stap (Data for Use) Thijs Brentjens (Geonovum / Brentjens Geo-ICT)

211 + 291 85 + 253 + 264

Tijs van den Broek (TNO)

157

Wilko Quak (TU-Delft)

311

Willem Melder (Nederlands Instituut voor Beeld en Geluid)

353

Willem Robert van Hage (SynerScope)

324

Aan de Pilot Linked Open Data hebben bijgedragen: Aad Kamsteeg - Aart van Sloten - Adriaan van Oosten - Alessandra Scotta Andreas Hoogeveen - Anne Fleur van Veenstra - Anneke Zuiderwijk Arian Nasiri - Arjan Borggreve - Arjan Loeffen - Arjan Stuurman Arjanna van der Plas - Arjen Santema - Arn van der Pluijm - Arnold Reinders Bart Broex - Bart Huijbers - Bart Knubben - Bart Kusse - Bart van Leeuwen Bas Geerdink - Bert Spaan - Bert ten Brinke - Bert van Rest - Bob Coret Bram van Beek - Camille van der Harten - Chris van Aart - Christophe GuĂŠret Clemens Portele - Corstiaan Kanters - Dennis Krukkert - Dennis Ramondt Denny Boelens - Dimitri van Hees - Dirk Melenberg - Dirk van Barneveld Dorine Berkvens - Dylan de Jong - Eelke Jager - Elvin Martha - Emil Zegers Erik de Rooij - Erik Jonker - Erik Orbons - Erik van der Zee - Erik Vrind Erwin Folmer - Erwin Hoogman - Eugene Tjoa - Felix Faassen - Ferry de Groot Fiemke Griffioen - Florian Bauer - Floris de Bree - Frank van Harmelen Frans Knibbe - Frans van der Zande - Gabriel Hopmans - Gerard Houtman Gerard Kuys - Gerard Nienhuis - Gerard Wildenbeest - Gerrit Hendriksen Gijs van Duijn - Haico van der Vegt - Hans Overbeek - Hans van der Burg Harrie van der Werf - Hayo Schreijer - Heidy van Kaam - Hein Bisterbosch Henk Kuipers - Henk Nijstad - Henk van den Berk - Herko Coomans Herman Assink - Holger Peters - Huib Verweij - Huibert-Jan Lekkerkerk Hylke Muntinga - Imke Vrijling - Jaap van den Heuvel - Jack Ruibing Jan Boerstra - Jan Bruin - Jan Bruinenberg - Jan Hidders Jan Jelle Boomgaardt - Jan Kooijman - Jan Meijer - Jan Voskuil Jandirk Bulens - Jans Aasman - Jasper Roes - Jasper Soetendal Jean-Louis Roso - Jene van der Heide - Jeroen Baltussen - Jeroen Hamers Jeroen van Vuuren - John van Echtelt - John Verhoeven - John Walker Joop Kielema - Joop Rasser - Joop Vanderheiden - Joris Booman -

359

Jos van der Arend - Jurriaan van Diggelen - Just van den Broecke Karin Swets - Kees Hendriks - Kees van der Graaf - Kees Waterman Koen Rutten - Laura Daniele - Leen van Doorn - Leonie Verhoeff - Lian Pattje Lieke Verhelst - Linda van den Brink - Loek Pfundt - Maarten Kroon Makx Dekkers - Marc de Vries - Marcel Reuvers - Marcel van Mackelenbergh Marco Aarts - Marco Brattinga - Marco Geuze -Marian de Vries Marijke Salters - Marjan Vernooy-Gerritsen - Mark Backer - Mark Peeters Mark Wiseman - Marleen Peters - Marten Terpstra - Martijn Snel Martin KaltenbĂśck - Martin Kodde - Martin Leenheer Maurice Vanderfeesten - Michel de Ru - Michel Grothe - Michiel Boelhouwer Michiel van Dijk - Milco Wansleeben - Nico Verbeij - NoĂŤl Van Herreweghe Oliver Bartlett - Pano Maria - Patrick Koetsier - Paul Brandt - Paul Francissen Paul Geurts - Paul Hermans - Paul Janssen - Peter Keijzers - Peter Klaver Pieter Bresters - Pieter van Everdingen - Pim Wijna - Ramon de Louw Raymond Sluiter - Reind van Olst - Reinout van Schouwen - Rene Bakker Reza Ahmadi - Ria van Rijn - Richard Zijlstra - Rinke Hoekstra Rob Schuurbiers - Rob van de Velde - Rob van Dort - Rob van Winden Roel Stap - Ron Wardenier - Roos Groeneveld - Ruby Beltman Ruud Steltenpool - Silja Eckartz - Sjako ten Haken - Steven IJzer Steven Mekking - Stijn Goedertier - Theo Scholl - Theo Versteeg Thies Mesdag - Thijs Brentjens - Thomas van der Woude - Ties Blaauw Tijs van den Broek - Tim Nelissen - Tine van Nierop - Tom Vijlbrief Victor Budke - Victor van Katwijk - Wilko Quak - Wilko Stalknecht Willem Koeman - Willem Melder - Willem Robert van Hage Wim van der Heiden - Yvette Ellenkamp - Yvonne Verdonk