Publicatie:Linked Open Data Roadmap

Samenvatting

Referentie

Titel	Linked Open Data Roadmap (Voorkeurstitel)
Locatie
Uitgever
Jaar van uitgave	2024
Rechten	CC-BY-SA
Persistent ID

Trefwoorden

handleiding | bibliotheekcollecties | museumcollecties | archiefcollecties | audiovisuele collecties | archeologische collecties | immaterieel erfgoed | onroerend erfgoed | documentaire collecties | linked (open) data | semantisch web | tekst |

Auteurs

• Bart Magnus
• Lise Ruts
• Alina Saenko
• Astrid Vergauwe
• Rony Vissers

Deze roadmap werd gereviewed door Rutger Goeminne, Ellen Van Keer en Miel Vander Sande. Alle auteurs en reviewers zijn medewerkers van meemoo, Vlaams instituut voor het archief.

Wat is linked open data?

Binnen het domein van linked open data worden er doorgaans drie termen gebruikt om de aard/type van data te beschrijven. Deze termen zijn: open data, linked data en linked open data. Hieronder leggen we het verschil uit en kaderen we de eigenheid van iedere term.

Open data

Open data zijn data die iedereen vrij kan raadplegen, gebruiken, bewerken en delen.

Bij het definiëren van de openheid dient rekening gehouden te worden met:

• Beschikbaarheid en toegankelijkheid: de data moeten in zijn geheel beschikbaar zijn, in een vorm die makkelijk bruikbaar en aanpasbaar (en dus technisch open) is en bij voorkeur door middel van downloaden via het internet. Aspecten zoals (open) bestandsformaat, -structuur en machineleesbaarheid maken de data beter bruikbaar en ze moeten dus zorgvuldig overwogen worden.
• Hergebruik en herverspreiding: eens de gebruiker over de data beschikt, mag hij ze vrij gebruiken, hergebruiken en opnieuw verspreiden. Ook het samenvoegen van de data met andere datasets moet toegestaan zijn. De data moet dus juridisch open zijn.
• Universele deelname: iedereen moet de data kunnen gebruiken, hergebruiken en herverspreiden. Bepaalde ondernemingen, personen of groepen mogen niet gediscrimineerd worden. Bijvoorbeeld: ‘commercieel’ gebruik mag niet worden uitgesloten met behulp van ‘niet-commerciële’ beperkingen of beperkingen die enkel het gebruik van de data voor bepaalde doeleinden toestaan (bv. alleen in het onderwijs).
• Kosten: open data moeten vrij kunnen worden gebruikt. Dat betekent niet noodzakelijk dat ze ook gratis verstrekt moeten worden. Er kunnen immers kosten verbonden zijn aan het creëren, onderhouden en publiceren van bruikbare data. Idealiter mag de vergoeding voor toegang tot open data echter niet hoger zijn dan de redelijke servicekosten voor het geheel van de gevraagde data. Meestal zijn de reproductiekosten (van data) verwaarloosbaar. Live data en big data kunnen wel lopende kosten met zich meebrengen die voortvloeien uit een betrouwbare dienstverlening.

Bij open data is het streefdoel de beperkingen in hergebruik tot een minimum te beperken. In de cultureelerfgoedsector wordt open data meestal gepubliceerd onder publiekdomeinverklaring (bv. Public Domain Mark of PDM) of een open / vrije licentie (Creative Commons Zero of CC0, of desnoods Creative Commons Naamsvermelding of CC BY of Creative Commons Naamsvermelding-GelijkDelen of CC BY-SA). Hoe minder beperkingen, hoe groter de hergebruiksmogelijkheden zijn. Meer beperkende Creative Commons-licenties zoals Creative Commons Naamsvermelding-NietCommercieel of CC BY-NC, Creative Commons Naamsvermelding-NietCommercieel-Gelijkdelen of CC BY-NC-SA, Creative Commons Naamsvermelding-GeenAfgeleideWerken of CC BY-ND of Creative Commons Naamsvermelding-NietCommercieel-GeenAfgeleideWerken of CC BY-NC-ND worden daarom uitgesloten. De Vlaamse overheid hanteert drie modellicenties: Creative Commons Zero of CC0, Modellicentie voor gratis hergebruik en Modellicentie voor hergebruik tegen vergoeding.

De term open data kan toegepast worden op een brede waaier van digitale data(sets), van documenten in natuurlijke taal tot gestructureerde tekenreeksen of twee- en driedimensionale digitale representaties.

Linked data

Linked data is een set van best practices (bv. W3C-aanbevelingen en vocabularies) om gestructureerde data op een uniforme manier  te beschrijven, modelleren, opslaan, publiceren en onderling te koppelen via het internet met behulp van RDF-gebaseerde open standaarden en Uniform Resource Identifiers of URI's. Kortom, linked data ontstaan door data uit verschillende bronnen te combineren met behulp van koppelingen (links). Het resultaat van deze koppelingen zijn betekenisvolle netwerken van informatie.

Met linked data breng je met behulp van semantische koppelingen via het World Wide Web samenhang aan in je gegevens. Linked data gebruiken URI's in plaats van woorden voor dingen, zoals bv. ‘Gent’ of ‘schilderij’. Elk concept wint aan betekenis naarmate er meer beschrijvingen aan gelinkt worden, bv. uit Wikidata en GeoNames in het geval van ‘Gent’ of uit bv. Wikidata en Art & Architecture Thesaurus (AAT) in het geval van ‘schilderij’. Zo worden de dingen die initieel enkel door mensen geïnterpreteerd konden worden, ook leesbaar en interpreteerbaar voor machines. Ook krijgt de inhoud van webdocumenten (bv. een online collectiecatalogus) hierdoor meer betekenis (context) en worden zoekresultaten nauwkeuriger (relevanter).

Omdat linkeddatabronnen heel divers kunnen zijn, vaak verspreid staan en op een verschillende manier door verschillende organisaties beheerd worden, zijn goede afspraken nodig. Enkel als je goede afspraken maakt over hoe je die uiteenlopende databronnen verbindt, kun je zinvolle en goed doorzoekbare koppelingen maken. Open standaarden zijn daarbij essentieel.

Linked open data

Linked open data (LOD) zijn data die zijn gepubliceerd als open data en bovendien aan andere (linked) data zijn gekoppeld. Open data zijn 'linked' als er door middel van koppelingen op gestructureerde wijze contextuele betekenis aan is toegevoegd, zodat ze machineleesbaar zijn en door computers te herkennen en te verwerken zijn. Data die open én linked zijn, worden beter vindbaar, doorzoekbaar en uitwisselbaar en verrijken elkaar semantisch op het World Wide Web.

De basisprincipes van LOD zijn:

1. Geef alle dingen waaraan je wilt kunnen linken, een uniek adres op het web (Uniform Resource Identifiers of URI’s), conform de standaarden zoals de Vlaamse URI-standaard of Archival Resource Key (ARK).
2. Gebruik het HTTP-protocol voor die URI’s zodat er naar de dingen kan worden verwezen en ze kunnen worden opgezocht door mensen en machines op het web.
3. Lever de informatie over het concept aan in een ‘triple’ (subject-predicaat-objectrelatie) op basis van standaarden, zoals RDF, SPARQL, OWL, JSON-LD of SKOS.
4. Neem links naar andere gerelateerde, opendata­concepten of databronnen op om het ontdekken van gerelateerde informatie op het web te verbeteren.

Vijfsterrenmodel

Om organisaties die open data publiceren aan te moedigen hun data in een zo herbruikbaar mogelijk formaat beschikbaar te stellen, heeft Tim Berners-Lee, één van de bedenkers en grondleggers van de technologie en de verzameling afspraken die het web mogelijk maken, een vijfsterrenmodel ontwikkeld. Het is een hulpmiddel waarmee organisaties kunnen toewerken naar herbruikbare linked (open) data die automatisch door computers kunnen worden verwerkt.

Hoe meer sterren aan de op het web gepubliceerde data toegekend kunnen worden, hoe beter hun bruikbaarheid en de openheid én hoe beter ze geschikt zijn voor geautomatiseerde verwerking. Gepubliceerde datasets, zoals basisregistraties van publieke erfgoedcollecties, hebben bij voorkeur vijf sterren.

De eerste drie sterren betreffen open data en vanaf de vierde en vijfde ster wordt gesproken over linked (open) data.

• 1 ster: de informatie is beschikbaar op het internet, in welk formaat dan ook;
• 2 sterren: de informatie is online beschikbaar in een gestructureerd formaat, dat machineleesbaar is (zoals een spreadsheet in plaats van een afbeelding van een tabel);
• 3 sterren: de informatie is online beschikbaar in een open bestandsformaat (zoals CSV in plaats van Microsoft Excel);
• 4 sterren: al de bovenstaande eigenschappen, met de toevoeging van URI’s en gebruik van linkeddatastandaarden (bv. RDF en SKOS) zodat anderen makkelijk naar de data kunnen verwijzen;
• 5 sterren: al de bovenstaande eigenschappen, en bovendien wordt er duurzaam naar externe data verwezen voor meer contextinformatie.

Met andere woorden: bij vier sterren zijn de data ‘linkable’ (door gebruik van o.a. URI’s en RDF) en bij vijf sterren zijn de data ook daadwerkelijk gelinkt aan andere data.

Wat is de meerwaarde van linked open data?

De meerwaarde van linked open data is veelzijdig. De toepassing ervan draagt bij aan:

• Interconnectiviteit: linked open data maken het mogelijk om gegevens uit verschillende bronnen en domeinen met elkaar te koppelen aan de hand van links. Hierdoor ontstaat een netwerk van onderling gerelateerde gegevens, waardoor verbanden gelegd worden tussen verschillende informatiebronnen. Zo is het mogelijk om als gebruiker een dieper begrip te krijgen van complexe onderwerpen.
• Verbeterde zoekmogelijkheden: linked open data maken complexe zoekopdrachten en datamining mogelijk. Door het leggen van koppelingen, krijgen gegevens meer betekenis (context) en worden ze leesbaar en interpreteerbaar voor machines. Linked open data zorgt ervoor dat machines door rijke, contextuele metadata kunnen zoeken. Dit verbetert op zijn beurt de nauwkeurigheid en de relevantie van de zoekresultaten.
• Herbruikbaarheid: linked open data bevorderen het hergebruik van gegevens. Data die open en toegankelijk zijn, kunnen gemakkelijker worden hergebruikt in verschillende contexten en toepassingen. Dit voorkomt het opnieuw verzamelen, repliceren en dupliceren van gegevens.
• Interoperabiliteit: linked open data maken het mogelijk om gegevens te integreren en te delen tussen verschillende systemen en platforms. Dit vereenvoudigt de uitwisseling van informatie tussen organisaties en verbetert onderlinge samenwerkingen.
• Decentralisatie: linked open data ondersteunen het principe van een decentrale (systeem)architectuur. De koppelingen bestaan uit persistente links (URL’s) die direct naar de bron van de gegevens doorverwijzen. Dit maakt het mogelijk om datasets uit verschillende domeinen, beheerd in uiteenlopende systemen op diverse servers, te verbinden met elkaar.
• Kwaliteitscontrole: omdat linked open data openbaar toegankelijk zijn en kunnen worden hergebruikt door een breed publiek, worden beheerders van (gelinkte) bronsystemen aangemoedigd om gegevens van hoge kwaliteit te publiceren en te onderhouden.
• Onderwijs en onderzoek: academici en onderzoekers kunnen linked open data gebruiken voor gegevensgestuurde onderzoeksprojecten en om nieuwe inzichten te genereren.
• Innovatie: door zo laagdrempelig mogelijk toegang te bieden tot gestructureerde en gelinkte gegevens, stimuleren linked open data innovatie. Ontwikkelaars kunnen nieuwe applicaties, diensten en inzichten creëren op basis van bestaande datasets.
• Transparantie: het publiceren van gegevens als linked open data bevordert transparantie en verantwoording, vooral bij overheidsinstanties en andere organisaties die een publieke opdracht hebben en overheidsinformatie bezitten. Dit helpt bij het opbouwen van vertrouwen.

Hoe passen linked open data in de beleidsvisie van de Vlaamse overheid voor de cultuursector?

De Vlaamse Regering zet momenteel sterk in op de digitale transformatie van Vlaanderen. Ze ziet dat onder invloed van snel wijzigende technologie een dergelijke transformatie ook elders in de wereld plaatsvindt, ze wil mee zijn met die evolutie en waar mogelijk ook koploper zijn.

De Vlaamse Regering beschouwt de valorisatie van data als grondstof van de economie en de maatschappij als een belangrijk middel om die digitale transformatie te realiseren. Ze wil daarom alle mogelijke data vlot, veilig en privacybestendig laten doorstromen en ontsluiten, zodat digitale toepassingen vlotter ontwikkeld en ingezet kunnen worden, zowel bij de overheid als in de privésector. Ze vindt dat de data vandaag nog te vaak versnipperd zijn.

De Vlaamse overheid is ervan overtuigd dat open data een rol kan spelen in haar betrachting om transparant en participatief te zijn. Ze beschikt over een enorme schat aan kwalitatieve en betrouwbare data die kan worden opengesteld naar andere overheden, burgers, bedrijven en organisaties. Niet alleen verhoogt daardoor de transparantie, maar het gebruik van open data maakt ook de weg vrij voor innovatie en de ontwikkeling van nieuwe producten of diensten. De Vlaamse overheid ambieert om haar opendatasets zoveel mogelijk als Linked Open Data (LOD) te publiceren. En ze verwacht een gelijkaardige ambitie van de (door haar gesubsidieerde) cultuursector.

De Vlaamse overheid wil dat de cultuursector datagedreven leert werken en de muren tussen individuele organisaties neerhaalt. Het Departement Cultuur, Jeugd en Media (DCJM) streeft ernaar dat de cultuursector haar data zowel standaardiseert als – binnen de grenzen van de regels voor de bescherming van persoonsgegevens, auteurs- of het contractenrecht en de gehanteerde verdienmodellen – open verkrijgbaar maakt en vrij laat stromen tussen cultuurorganisaties. Op die manier kunnen (ook) in de cultuursector nieuwe businessmodellen, processen, relaties en dienstverleningen worden ontwikkeld, ook naar andere maatschappelijke sectoren. Om het gebruik en de bruikbaarheid van de data te verhogen stimuleert DCJM o.a. het koppelen van data uit verschillende bronnen en het gebruik van uitwisselingsstandaarden zoals Open Standaarden voor Linkende Organisaties (OSLO).

Linked open data en OSLO

OSLO vindt zijn oorsprong in de ambitie van de Vlaamse overheid om haar dienstverlening te optimaliseren en de uitwisseling van informatie vlotter te laten verlopen. Een moeilijkheid daarbij is dat de overheidsdiensten aan burgers en ondernemers worden ondersteund door gespecialiseerde toepassingen van verschillende softwareleveranciers, en dat de verschillende overheidsdiensten (en bijbehorende beleidsdomeinen) vaak werken met eigen systemen en standaarden die onderling verschillen.

Met OSLO wil de Vlaamse overheid inzetten op een uniforme samenwerking over sectoren heen opdat (linked open) data op dezelfde manier zouden uitgewisseld worden tussen verschillende domeinen. OSLO moet ervoor zorgen dat data op een uniforme wijze worden aangeboden, waardoor uitwisseling eenvoudig kan plaatsvinden en de interoperabiliteit verhoogd wordt.

Omdat OSLO opgesteld is op basis van verschillende (internationale) standaarden kan de standaard in verschillende beleidsdomeinen en sectoren worden toegepast, ook binnen het beleidsdomein Cultuur en dus de cultuursector. Vertrouwde standaarden uit de cultureelerfgoedsector waarop OSLO voortbouwt, zijn CIDOC-CRM en FRBRoo.

De OSLO-standaard voor cultureel erfgoed kwam in 2021 tot stand op initiatief van DCJM en Digitaal Vlaanderen. Deze domeinontologie werd vormgegeven door een werkgroep van experten gespecialiseerd in linked data, en experten uit de cultureelerfgoedsector. Wil je meer weten over hoe OSLO tot stand is gekomen, wat de standaard inhoudt en wat er concreet werd ontwikkeld? Bekijk dan zeker de publicatie OSLO Cultureel Erfgoed.

Ben je op zoek naar goede (voorbeeld)praktijken, documentatie, ontwikkelde instrumenten of mogelijke ondersteuning mbt de OSLO cultureel erfgoed standaard? Raadpleeg dan de OSLO-Wegwijzer. Wil je graag aan de slag met de standaard, maar weet je niet goed hoe? Dan kan de OSLO toolkit en/of het dataprofiel “basisregistratie als OSLO JSON/LD” je mogelijk verder helpen.

Stappenplan voor de creatie van linked open data

In dit onderdeel kaderen we stap per stap hoe je linked open data kunt creëren en beheren. De aanpak bestaat uit negen stappen:

1. Data selecteren: de selectie van de te publiceren data.
2. Data voorbereiden: de beoordeling van de kwaliteit van de data, de schoning van de data, de integratie van de data en het klaren van de rechten.
3. Data modelleren: het vastleggen van de betekenis van data in de vorm van een graaf.
4. Data voorzien van persistente URI’s: de data duurzaam identificeren.
5. Data converteren: het serialiseren van de data in triples.
6. Databeheer: het opzetten van een beheermodel voor de data.
7. Toevoegen van metadata: toekennen van contextuele metadata aan de dataset.
8. Koppelen van data: het duurzaam koppelen van de data aan externe datasets.
9. Publiceren van data: het beschikbaar maken van de data.

Stap één: data selecteren

De eerste stap die je dient te ondernemen als je data als linked open data wil publiceren is het selecteren van de te publiceren data. Je stelt je daarbij best de volgende drie vragen:

1. Welke doelstellingen wil mijn organisatie realiseren met de publicatie van linked (open) data?
2. Met de publicatie van welke data kan mijn organisatie deze beoogde doelstellingen realiseren?
3. Welke van de data die geschikt zijn om de beoogde doelstellingen te realiseren, kan mijn organisatie daadwerkelijk publiceren als linked (open) data?

Deze doelstellingen kunnen sterk variëren naargelang de aard van je organisatie. Enkele voorbeelden van doelstellingen zijn:

• de werking van je met publieke middelen gefinancierde organisatie verantwoorden;
• de maatschappelijke relevantie van je organisatie / data versterken door innovatieve toepassingen te faciliteren;
• de kwaliteit van je data vergroten door
  • ze inhoudelijk te verrijken met koppelingen naar externe databronnen;
  • het verkrijgen van feedback van de datagebruikers.

Houd bij de keuze van de te publiceren data rekening met de mogelijkheid dat anderen de data van jouw organisatie misschien kunnen gebruiken voor doeleinden of toepassingen waaraan je zelf nog niet hebt gedacht.

Houd er ook rekening mee dat data onder de bescherming van persoonsgegevens kunnen vallen en misschien niet onversleuteld gepubliceerd kunnen worden en ook niet als linked open data beschikbaar kunnen worden gemaakt. Hetzelfde geldt voor data waarop auteursrechten rusten en die geen vrije licentie hebben.

Naast de bescherming van persoonsgegevens en de auteursrechtelijke bescherming kunnen er in sommige gevallen ook nog contractuele afspraken spelen die het onmogelijk kunnen maken om de data als linked open data beschikbaar te maken, bv. wanneer een derde partij de data aan jouw organisatie heeft overgedragen en daarbij een embargoperiode voor publicatie is afgesproken.

Ook is het mogelijk dat je organisatie rekent op een verdienmodel waardoor de publicatie van bepaalde data als linked open data uitgesloten is. De kwaliteit en het technisch formaat van de data kunnen eveneens bepaalde factoren zijn om bepaalde data al dan niet te selecteren voor linkedopendatapublicatie.

Indien er in een bepaalde situatie inderdaad zo’n beperking is, betekent dit niet noodzakelijk dat het definitief uitgesloten is om de data als linked (open) data te publiceren. Je kunt immers nog bekijken of je deze beperking kunt remediëren. Bijvoorbeeld: wanneer publicatie van je data onmogelijk is omdat ze vallen onder de bescherming van persoonsgegevens, kun je bekijken of versleuteling van je data een oplossing biedt.

Enkel wanneer er zowel met betrekking tot de bescherming van persoonsgegevens, de auteursrechten en contractuele overeenkomsten, de verdienmodellen, de datakwaliteit als het technisch formaat geen beperkingen meer zijn, kunnen je data als linked open data worden gepubliceerd.

Stap twee: data voorbereiden

Zodra je de te publiceren data hebt geselecteerd, volgt er een reeks stappen die de voorbereiding van de geselecteerde data als doel hebben. Indien de data die je als linked open data wil publiceren niet je eigen data zijn, moet je vanzelfsprekend eerst toegang tot de databron en/of data-extracten verkrijgen of zelf een nieuwe dataset creëren. Ook heb je een kopie van het logische en fysieke model van de databank nodig (zie 5.3 Data modelleren). Daarna volgen:

• de beoordeling van de kwaliteit van de data;
• de schoning van de data;
• de integratie van de data;
• het toekennen van een rechtenverklaring of licentie.

Je kunt bij deze stappen verschillende tools gebruiken, bv. OpenRefine, Publiekdomeintool, Cyberduck, Exiftool en je eigen collectiebeheersysteem.

Beoordelen van de kwaliteit van de data

Het is belangrijk dat je een goed beeld krijgt van de kwaliteit van je te publiceren data, niet alleen van de dataset als geheel maar ook van de individuele data-elementen. De volgende kwaliteitsaspecten moeten beoordeeld te worden:

• validiteit, d.i. de mate waarin de data correct en betrouwbaar is;
• volledigheid, d.i. de mate waarin er geen data ontbreken (bv. alle vereiste data-elementen zijn beschikbaar);
• consistentie, d.i. de mate waarin de data worden gepresenteerd in eenzelfde formaat en compatibel zijn met eerdere data, en geen interne tegenstrijdigheden bevatten;
• uniciteit, d.i. het uniek zijn het data-element, wat betekent dat er geen dubbele waarden zijn;
• tijdigheid, d.i. de mate waarin de data voldoende actueel zijn;
• correctheid, d.i. de mate waarin de data-elementwaarden correct zijn toegewezen en foutloos zijn;
• nauwkeurigheid, d.i. de mate waarin de datakenmerken goed worden begrepen en het data-element correct wordt gebruikt (dus enkel voor het beoogde doel).

Schonen van de data

In bepaalde gevallen is het nodig om je data te schonen vooraleer je verdere stappen kan ondernemen richting linked open data. Vuile data bestaan bijvoorbeeld uit verouderde of in onbruik geraakte informatie, inconsistenties of irrelevante informatie. Het schonen van je data zal de datakwaliteit verbeteren. Hoe schoner je data, hoe gemakkelijker je met de data aan de slag kan gaan. Data kun je handmatig opschonen in een CSV-bestand. Als je een uitgebreide dataschoning wil uitvoeren, kun je ook een (gratis) tool gebruiken zoals OpenRefine.

Integreren van de data

Het integreren van data is het samenbrengen van datasets uit verschillende databronnen. Zo is het mogelijk dat je een dataset over de werken uit de collectie van je organisatie wil als linked open data publiceren, maar dat de data over de vervaardigers van die werken in een ander systeem dan je collectiebeheersysteem worden beheerd. Het gevolg is dat je dus eerst de datasets uit de twee verschillende systemen zal moeten integreren. Vaak gebeurt zo’n integratie tegenwoordig (deels) automatisch. Het doel van data-integratie is de lezer een coherent overzicht te geven van de data. Een mogelijke actie tijdens het data-integratieproces is ook bijvoorbeeld de anonimisering van persoonsgegevens.

Toekennen van een rechtenverklaring of licentie

Wanneer je beoogt data als open data te publiceren, zal je moeten aangeven of er juridische beperkingen aan die openheid zijn. Dit gebeurt best op een zo gestandaardiseerd mogelijke manier, hetzij via gestandaardiseerde vrije licenties, hetzij via een rechtenverklaring (in het bijzonder de Public Domain Mark of PDM).

Feitelijke metadata (bv. de creatiedatum, het gebruikte materiaal of de naam van de vervaardiger) zijn niet origineel en kunnen daardoor geen auteursrechtelijke bescherming genieten. Ze behoren tot het publiek domein. In zo'n geval is het aanbevolen om de rechtverklaring PDM te gebruiken. Je geeft hiermee aan dat de gebruiker je data zonder toestemming mag kopiëren, veranderen, verspreiden en uitvoeren, en dat zonder beperking - dus zelfs voor commerciële doeleinden.

Bij een eventuele auteursrechtelijke bescherming op bepaalde data is het belangrijk om na te gaan wie de rechthebbende is. De organisatie die de data publiceert, kan immers enkel een licentie toekennen als ze zelf de rechthebbende is. Wanneer je organisatie zelf de rechthebbende is, is het aangewezen om Creative Commons Zero (CC0) te gebruiken. Je geeft daarmee aan dat je verzaakt aan de uitoefening van je auteursrechten voor zover dat door de wet is toegestaan. Ook bij data gepubliceerd onder CC0 mag de gebruiker dus je data zonder toestemming kopiëren, veranderen, verspreiden en uitvoeren, zelfs voor commerciële doeleinden.

Indien je organisatie zelf niet de auteursrechthebbende is en de auteursrechtelijke status onduidelijk is, kun je strikt genomen de data niet publiceren als linked open data.

Stap drie: data modelleren

De volgende stap is het modelleren van de data. Het modelleren van data is het proces waarbij er betekenis wordt gegeven aan de data. Op basis van een standaard wordt een gestructureerde representatie gemaakt van gegevens en de gegevenstypes die in een informatiesysteem beheerd en bewaard worden. Hierdoor krijg je inzicht in de onderlinge ordening, de relaties en de eigenschappen van de data. Op basis van een standaard of ontologie, wordt de data gestructureerd in een conceptueel model, een netwerk of een graaf. De graaf wordt opgebouwd aan de hand van het vocabularium van een ontologie. Dit bestaat op haar beurt uit entiteiten, mogelijks attributen en hun eigenschappen of relaties.

• Een entiteit is een klasse of concept in een ontologie.
• Een attribuut doet een uitspraak voor een karaktereigenschap van een entiteit.
• Een relatie verbindt twee entiteiten met elkaar, waardoor met behulp van de ene entiteit een eigenschap wordt toegekend aan de andere entiteit.

Voorbeeld:

Dit vormt samen een netwerk dat de onderlinge verbanden van de data nauwkeurig weergeeft: een graaf.

Na het modelleren wordt het conceptueel model geformaliseerd naar een technisch, semantisch formaat. Deze formalisering noemen we de serialisatie. Het serialiseren zorgt ervoor dat de data omgezet wordt in code zodat de data geïnterpreteerd en leesbaar wordt voor machines. Lees hier verder over in stap 5.5.’data converteren’.

In de praktijk kan het modelleren van de data in drie stappen uitgevoerd worden. Binnen deze stappen kan je op diverse manieren koppelingen leggen tussen data-elementen.

Datamodellering, stap één

Je ontwikkelt een graaf aan de hand van je eigen terminologie/vocabularium worden uitgedrukt met eigen termen. Dit kunnen waarden of termen zijn die gebruikt worden in de velden en/of elementen in een informatiebeheersysteem.

Voorbeeld: “Deze film uit onze collectie heeft een objectnummer en dat objectnummer heeft een waarde (bv. F00001)”. Deze uitdrukking in je eigen terminologie wordt in de praktijk gemodelleerd naar:

Het conceptueel model kun je op verschillende manieren uitwerken.

1. Je tekent de graaf fysiek uit op bijvoorbeeld een whiteboard of een blad papier. De entiteiten worden gerepresenteerd door cirkels. De cirkels worden met elkaar verbonden door lijnen. De lijnen beschrijven de relaties tussen de entiteiten (zie voorbeeld bij Datamodellering, stap 1). Zo leg je koppelingen tussen verschillende data-elementen en creëer je een netwerk. Voorbeeld: https://coghent.gitbook.io/oslo-implementatie/NQiMpFtkbk5lS15pXauq/implementatie/strategie-tot-implementatie/graaf.
2. De graaf kan ook digitaal uitgewerkt worden (zie voorbeeld bij Datamodellering, stap 1). Hiervoor gebruik je een entiteit-relatie-diagram. Deze diagrammen worden met een diagram- en grafiektool of een ontology editor uitgewerkt. Veel gebruikte software is: Mermaid, Topbraider composor, Protégé, Miro of draw.io.
3. Je beschrijft de graaf aan de hand van een pattern of patroon. Het patroon bestaat uit een reeks entiteiten en relaties die een veldwaarde uit het beheersysteem definiëren. Je gebruikt (ronde haakjes) voor het beschrijven van de entiteiten en [rechte haakjes] voor het beschrijven van eigenschappen/relaties. Alles wordt op een lijn na elkaar beschreven. De entiteiten en eigenschappen worden van elkaar gescheiden door een liggend streepje. Dit is een tweede methode om data-elementen aan elkaar te linken. Voorbeeld: (Film)-[wordt geïdentificeerd door]-(Identificatienummer)-[heeft waarde]-(string). Deze patterns documenteer je in een dataprofiel. Het dataprofiel biedt de mogelijkheid om aanvullende informatie m.b.t. de dataset te documenteren. Zo kunnen o.a. de elementwaarden, de veldwaarden, de gebruikte terminologie, de datatypes en de andere gebruikte standaarden ook beschreven worden. Op deze manier creëer je niet alleen een datamodel van je eigen dataset, maar ook een crosswalk tussen systemen en standaarden. Voorbeelden: dataprofiel CIDOC-CRM mapping Stad Antwerpen en dataprofiel MMP1917.

Datamodellering, stap twee

Je vertaalt de graaf in je eigen terminologie naar het vocabularium van een geprefereerde datastandaard of ontologie. Om gegevens te kunnen combineren en verrijken met andere (bv. internationale) datasets, zijn goede afspraken nodig. Die afspraken worden vastgelegd in datastandaarden en ontologieën. Zij zorgen voor context, samenhang en een betere interoperabiliteit om data makkelijker uitwisselbaar te maken. Het gebruik van datastandaarden en ontologieën is dus noodzakelijk. Je gebruikt best algemeen aanvaarde datastandaarden die de noden van jouw use case zo volledig mogelijk vervullen. Voorbeeld: OSLO-mapping CAG

Concreet vervang je je eigen terminologie door het vocabularium van de gekozen ontologie. Deze stap kan zowel fysiek, digitaal of aan de hand van een dataprofiel uitgewerkt worden.

Datamodellering, stap drie

De laatste stap is het formaliseren van het uitgetekende conceptueel model. Gebruik hiervoor een technisch, semantisch formaat zoals JSON-LD, OWL, SKOS of RDF. Hoe dit praktisch gebeurt, behandelen we in 5.5. Data converteren. Een handige toepassing om dit te realiseren is de sandbox. In deze omgeving kan de serialisatie gesimuleerd en gevisualiseerd worden. Dit is een derde methode van hoe data-elementen aan elkaar gekoppeld kunnen worden. Voorbeeld: Dataprofiel Basisregistratie als OSLO JSON-LD.

Het modelleren van data kan een tijdsintensieve onderneming zijn, maar het biedt een grote meerwaarde. Het biedt inzicht in de onderlinge ordening, de relaties en de eigenschappen van de data die een organisatie bewaart en beheert. Daarnaast biedt het ook inzicht in hoe deze data ingezet en gebruikt kunnen worden. Een datamodellering kan bijvoorbeeld helpen bij het bepalen van een datamodel en/of van de functionele en technische vereisten van een informatiebeheersysteem. Deze kennis is van cruciaal belang bij de ontwikkeling van databanken, softwaretoepassingen of andere systeemarchitectuur die gegevens opslaan, verwerken en analyseren.

Stap vier: data voorzien van persistente URI’s

Deze stap overloopt richtlijnen voor de implementatie van persistente URI’s om je data duurzaam te identificeren.

Een belangrijk linkeddataprincipe is dat elke entiteit en de relaties tussen entiteiten voorzien zijn van unieke persistente URI’s en zo duurzaam aan elkaar gelinkt kunnen worden. De unieke persistente URI’s worden dus toegekend aan zowel de volledige dataset als elk apart stukje data. Dit is een belangrijk aspect van de kwaliteit van je data. Er is dus nood aan een duurzaam beleid en beheer van je implementatie van persistente URI’s. Volg hiervoor bestaande (nationale) richtlijnen en standaarden, bijvoorbeeld die van W3C, het SEMIC-project of de Vlaamse URI-standaard.

Om persistente URI’s te implementeren dien je aan twee belangrijke aspecten te denken: de syntax en de resolving.

Syntax

Voor persistente URI’s in de cultureelerfgoedsector bestaat er een set van regels:

• Een persistente URI MOET het HTTP(S) URI-schema gebruiken. HTTP (HyperText Transfer Protocol) en HTTP(S) zijn één van de belangrijkste protocollen voor het versturen en ontvangen van bestanden op het World Wide Web. Het wordt ook gebruikt voor indexering van World Wide Web-documenten. De persistente URI’s moeten dus met http(s):// beginnen.
• Een persistente URI MOET de volgende elementen bevatten: http(s):// {domein} / {identificatienummer}.
  • De elementen {domein} en {identificatienummer} zijn verplicht.
  • Het {domein} identificeert de webserver waar de persistente URI geregistreerd en beheerd wordt. Een persistente URI MOET een domeinnaam of subdomeinnaam bevatten die enkel en alleen voor het publiceren van persistente URI’s wordt gebruikt. Bijvoorbeeld: {hdl.handle.net}, {data.archief.be} of {id.momu.be}. Je kiest best voor een domeinnaam die onafhankelijk is van bijvoorbeeld merk, organisatie of product. Wanneer men achteraf de domeinnaam toch zou willen veranderen, dient er een doorverwijzing van de oude naar de nieuwe domeinnaam worden ingericht. Zorg er zeker voor dat je organisatie of je PID-leverancier controle heeft over de domeinnaam.
  • Het {identificatienummer} identificeert de resource waarvoor de persistente URI wordt aangemaakt. Hier kies je best voor een logica die unieke onveranderlijke identifiers oplevert, bijvoorbeeld:
    • hergebruik van reeds bestaande identifiers (bv. onveranderlijke databanknummers of inventarisnummers);
    • software en best practices voor het maken (minten) van o.a. UUID’s en NOID’s;
    • gebruik van andere bestaande PID-protocollen: handle, DOI, ARK.
• Een persistente URI MAG bijkomende elementen bevatten. Afhankelijk van welke standaard je wil volgen en welke use case je hebt, kan je tussen {domein} en {identificatienummer} bijkomende elementen opnemen in de persistente URI:
  • {type} duidt aan welk soort resource via de URI toegankelijk is. Hiervoor kan je bijvoorbeeld de volgende termen gebruiken, die in de use cases in de cultureelerfgoedsector van toepassing zijn:
    • id: de URI identificeert louter het cultureelerfgoedobject;
    • data: de URI identificeert een dataset met informatie over een cultureelerfgoedobject;
    • representation: de URI identificeert een grafische representatie van een cultureelerfgoedobject.

De Vlaamse URI-standaard spreekt over volgende types:

• • • id: identifier is een referentie naar een object uit de echte wereld of een abstract concept;
    • doc: document dat een representatie op het web, of een beschrijving is van objecten in de echte wereld of abstracte concepten. Het gaat hier om algemene beschrijvende informatie (webdocumenten);
    • ns: namespace van een taxonomie, ontologie of vocabularium.
  • {concept} duidt aan welke categorie cultureelerfgoedobjecten persistent geïdentificeerd wordt. Hiervoor kan je de volgende termen gebruiken:
    • work;
    • concept;
    • agent;
    • place;
    • event.

Deze termen zijn ontleend aan de CIDOC CRM-ontologie en de ‘The Europeana Data Model’-ontologie.

Resolving

De persistentie van een webadres staat of valt met de gebruikte infrastructuur en het duurzaam beheer ervan. Die infrastructuur bestaat uit twee belangrijke elementen: een webserver met de URL forwarding-functie en software die het mogelijk maakt om de URL forwarding of URL redirection te beheren. Het principe van URL forwarding zorgt ervoor dat wanneer een gebruiker op een persistente URI klikt, hij wordt ‘doorverwezen’ naar de locatie op het web waar de digitale resource vandaag aanwezig is (bv. een andere website, databank of beeldbank). De software die het beheer van de forwarding mogelijk maakt, wordt de resolver genoemd. Met behulp van deze software kan de beheerder ervoor zorgen dat elke gebruiker bij het aanspreken van een persistente URI steeds op de meest recente locatie van de digitale resource belandt.

Deze infrastructuur kan op verschillende manieren opgesteld worden:

• Resolving met behulp van een eigen webserver:
  • je zet (met behulp van een IT-partner) een Apache- of een nginx-server op die de URL forwarding kan ondersteunen,
  • je schrijft zelf een stukje code om het beheer van de URL forwarding mogelijk te maken: https://en.wikipedia.org/wiki/URL_redirection#Implementation, of
  • je maakt gebruik van reeds bestaande code om je eigen resolver op te zetten, bv. CultURIze of CultURIze web.
• Resolving met behulp van een PID-webdienst: er bestaan reeds meerdere PID-leveranciers die het aanmaken en activeren van persistente URI’s als een dienst aanbieden:
  • N2T resolver van ARK Alliance: https://n2t.net/;
  • Handle system: http://www.handle.net/;
  • Persistent URL (PURL): https://purl.archive.org/;
  • Digital Object Identifier (DOI): http://www.doi.org/.

De persistentie van de URI’s kan enkel verzekerd worden door een duurzaam beleid hieromtrent. Volg het stappenplan om je persistente URI’s te implementeren.

Stap vijf: data converteren

Na het bepalen van het persistente URI-schema, kunnen we overgaan naar het converteren van de brondata naar een technisch, semantisch formaat. Dit noemen we het serialiseren of formaliseren van de data. Het serialiseren zorgt ervoor dat de data omgezet wordt in code zodat de data geïnterpreteerd en leesbaar wordt voor machines. Binnen deze stap wordt de data omgezet naar RDF-triples. Hiervoor gebruiken we het PURI-schema dat in 5.4. Stap vier: data voorzien van persistente URI’s werd opgesteld.

Het Resource Description Framework is een voor het web ontwikkeld standaardmodel voor het coderen van metadata. Het model gaat uit van drie onderdelen: subject-eigenschap-object (een 'RDF-triple'). Het subject is de bron die beschreven wordt, de eigenschappen zijn generieke kenmerken van die bron, het object geeft invulling aan een eigenschap. Bijvoorbeeld: tafel-kleur-rood. Door subjecten op deze wijze te beschrijven, kunnen grote en complexe dataverzamelingen op een uniforme wijze doorzocht worden. De gegevens worden meestal uitgedrukt en verwerkt in XML, maar JSON(-LD) en Turtle zijn gebruikelijke alternatieven. RDF-triples worden doorgaans opgeslagen in een databank die we een triplestore noemen.

Vooraleer de data geconverteerd kan worden naar RDF, moet er eerst beslist worden hoe de data gepubliceerd zullen worden. Kortom, hoe wil je de data aanbieden of beschikbaar maken voor derden? Gebeurt dit in de vorm van een periodieke datadump die manueel gecreëerd wordt? Of kan de data opgevraagd worden via een webservice zoals een Application Programming Interface (API) of een SPARQL endpoint? Lees hier verder over in stap 5.8. Deze keuze moet afgestemd worden op de noden van de doelgroep die je wenst te bereiken. Een onderzoeker zal misschien eerder de gegevens willen consulteren en downloaden terwijl een ontwikkelaar waarschijnlijk de voorkeur heeft aan het automatisch opvragen van data via een API. Inzicht hebben in het gebruikersgedrag van de bepaalde doelgroepen, is cruciaal bij het maken van deze keuze.

Een conversie kan op drie manieren uitgevoerd worden:

1. geautomatiseerd, ook wel de ‘triplication’ of verdrievoudiging genoemd;
2. semi-geautomatiseerd aan de hand van een script;
3. manueel.

De modellering wordt uitgevoerd voor experten (zowel inhoudelijk als technisch), vervolgens wordt het model of graaf manueel omgezet in code (zie Datamodellering, stap 3 in 5.3. Data modelleren).

Er zijn verschillende tools die de conversie van brondata naar RDF helpen faciliteren:

• RDF Translator;
• Spyder.

Daarnaast bestaat er heel wat ondersteunende documentatie en handleidingen:

• het project Simile heeft diverse conversietools geïnventariseerd voor verschillende formaten.
• een gelijkaardige lijst kan je ook terugvinden bij W3C.
• Oracle voorziet verschillende tutorials voor het converteren van brondata.
• R2RML language documenteert verschillende (aangepaste) mappings van relationele databanken naar RDF.

De volgende stap is het opzetten van een governancestructuur die instaat voor het beheer en onderhoud van de geconverteerde brondata. Een helder afsprakenkader met mature werkprocessen en afgebakende rollen en verantwoordelijkheden, is noodzakelijk voor een duurzaam beheer van de data.

Stap zes: databeheer

Je kan bij het publiceren en hergebruiken van linked open data botsen op verschillende obstakels, o.a. slechte datakwaliteit, afwezigheid van beschrijvende metadata, gebrekkige infrastructuur, beperkte mankracht en resources, en onduidelijk gedefinieerde use cases voor hergebruik. Het potentieel van linked open data zal pas echt gerealiseerd worden als die obstakels overwonnen zijn en de data effectief hergebruikt kan worden.

Om de obstakels te kunnen overwinnen, dien je een beheermodel op te zetten en te implementeren. In zo’n beheermodel dienen de keuzes i.v.m. de bescherming van persoonsgegevens, de technische architectuur, de beschrijvende metadata en de herkomst van je data te worden vastgelegd. Het model zal ervoor zorgen dat je linked open data effectief zal hergebruikt worden en voor lange termijn beschikbaar blijft.

Het organiseren van het beheer vergt veel doorlooptijd, omdat er afstemming met de betrokken stakeholders nodig is. Daarom is het belangrijk om al vroeg in het datapublicatieproces met deze stap te beginnen en hem parallel met de andere stappen uit te voeren.

Er zijn verschillende voorbeelden van beheermodellen online beschikbaar, een voorbeeld is het BOMOD-model (Beheer en Ontwikkel Model Open Data). Dit model geeft een overzicht van de activiteiten die organisaties ondersteunen bij het beheer van (open) data. Het omvat vijf clusters of blokken van activiteiten:

1. Algemene Strategie, omvat de visie, het algemeen beheer en het financieel beheer.
2. Tactieken, omvat zowel alle activiteiten m.b.t. het communitybeheer, het rechtenbeleid, het hergebruik, het releasemanagement en datakwaliteit als het datamodel.
3. Operaties, omvat alle activiteiten m.b.t. het initiëren van een nieuw data-initiatief, de ontwikkeling van opendatasets of nieuwe conceptuele koppelingen tussen de sets, de publicatie van een opendataset, het identificeren van voorkeuren en vereisten van datagebruikers en data-eigenaars en het documenteren van de opendataset.
4. Implementatie, omvat alle activiteiten m.b.t. ondersteuning, training, ondersteunende tools, pilootimplementaties en validatie en certificatie.
5. Communicatie, omvat alle activiteiten m.b.t. promotie van de data, publicatie van de data en het verzekeren dat klachten ernstig worden genomen.

De eerste drie blokken Algemene strategie, Tactieken en Operaties zijn de centrale blokken van het BOMOD-model. De twee laatste blokken, Implementatie en Communicatie, vervullen eerder een ondersteunende rol.

Een organisatie die slechts één linkedopendataset wil publiceren moet niet noodzakelijk alle activiteiten uitrollen die in het BOMOD-model zijn opgenomen. Afhankelijk van de omvang van de organisatie, de dataset en het doel dat de organisatie nastreeft met publicatie van haar (open) data, zijn sommige activiteiten belangrijker dan andere. Het model beschrijft op welke manier een organisatie de verschillende activiteiten kan invullen en uitrollen. Het maakt daarbij een onderscheid in drie maturiteitsniveaus. Zo wordt aangegeven welke activiteiten essentieel zijn en daarom als eerste moeten gebeuren, en welke activiteiten minder cruciaal zijn en dus later kunnen gebeuren.

Het uitwerken en implementeren van een goed beheermodel dient te gebeuren door een specifiek hiervoor aangeduide (of nieuw gecreëerde) entiteit of persoon binnen of buiten je organisatie die verantwoordelijk is voor databeheer, bijvoorbeeld een dataconservator of een data-uitgever.

Een recent voorbeeld van een opendatabeheerplan is het Data Management Plan (2021), een deliverable die voortkwam uit het project Collectie van de Gentenaar.

Stap zeven: toevoegen van metadata

Deze stap betreft het metadateren van de dataset die je als linked open data wil publiceren. Je dient extra informatie aan je dataset toe te voegen om hem zelfbeschrijvend te maken en zo het hergebruik van je data te ondersteunen. Informatie over onder andere de herkomst van je data, het moment waarop ze zijn gecreëerd en voor welke toepassingen ze kunnen worden gebruikt, is hierbij belangrijk. De herkomst van je data kan een belangrijke aanwijzing zijn voor de betrouwbaarheid van je data. Op basis van de creatiedatum van je data zal de hergebruiker een inschatting kunnen maken of ze al dan niet verouderd is. En informatie over succesvolle toepassingen van je data door andere (her)gebruikers kan een goede aanwijzing zijn om het mogelijke succes van gelijkaardige toepassing in te schatten.

Metadata kunnen worden toegevoegd door triples toe te voegen aan de RDF-versie van de dataset die werd verkregen in stap 5 Data Converteren. Ze bevatten feitelijke informatie over je dataset. Linked open data die op web worden gepubliceerd, moeten zo zelfbeschrijvend mogelijk zijn opdat gebruikers ze zo gemakkelijk mogelijk kunnen begrijpen en gebruiken. Je maakt je data zelfbeschrijvend door de in de metadata gebruikte termen te koppelen met termen uit gangbare vocabularies.

We onderscheiden drie niveaus in de mate waarop je metadata aan je dataset toevoegt:

1. basismetadata;
2. minimale metadata;
3. volledige metadata.

De basismetadata omvat:

• naam / titel: een unieke naam of identifier voor de dataset;
• uitgever / auteur: de naam van de publicerende organisatie en/of persoon, inclusief contactgegevens (bijvoorbeeld e-mailadres);
• identifier: een unieke naam van de dataset die wordt gebruikt in URL’s en voor identificatie;
• locatie / URL: een unieke link naar de (online) plek/website waar de dataset kan worden geraadpleegd of gedownload;
• licentie: informatie over de licentie waaronder de dataset wordt vrijgegeven.

De minimale metadata vertrekt van de basismetadata, maar voegt daar nog informatie aan toe over onder andere het potentiële gebruik, de creatiedatum, het formaat, het type data, de taal, het geografische bereik, het gebruikte datamodel en de grootte van de dataset.

De volledige metadata omvat niet enkel de basismetadata en de minimale metadata, maar ook de volgende informatie:

• beschrijving: een korte beschrijving van de dataset, inclusief de volledige naam en het oorspronkelijke beoogde gebruik;
• website met toelichting: (link naar) een website die zowel uitleg verschaft over de dataset als richtlijnen geeft over het gebruik van de dataset;
• herkomst: informatie die inzicht geeft in mogelijke problemen bij het creëren, transformeren en kopiëren van de data;
• gebruik van termenlijsten / codelijsten / schema’s: informatie die toelicht of er aangepaste vocabulaires of schema's gebruikt zijn die aangeven welke kolommen of eigenschappen voor de opgenomen data zijn gebruikt;
• LOD-sterren: de mate waarin de dataset voldoet aan criteria voor linked open data uitgedrukt in het sterrenmodel van Tim Berners-Lee;
• tijdsperiode: informatie over de tijdsperiode die door de dataset wordt bestreken.

Stap acht: koppelen van data

Eén van de laatste stappen in het proces om je de vijf sterren te bekomen en je data beschikbaar te maken als linked (open) data is het duurzaam koppelen van je data aan externe data. Door dit linkeddataprincipe te volgen, kan je bijkomende context aan je data toevoegen, zonder dat je deze onmiddellijk in je eigen dataset moet opnemen. Denk bijvoorbeeld aan een dataset met adressen uit verschillende steden. Het is waarschijnlijk dat er al meer informatie over deze steden beschikbaar is op het web, bijvoorbeeld Wikidata en DBpedia bevatten informatie over heel veel steden.

Linked data biedt, in tegenstelling tot andere manieren om data te structureren en beschikbaar te stellen, een eenvoudig mechanisme voor het combineren van gegevens uit meerdere bronnen op het web. Voor andere data, personen of concepten hergebruik je best de persistente URI’s die reeds door andere organisaties zijn toegekend en elders zijn beschreven, bijvoorbeeld omdat de corresponderende metadata en beelden vollediger en actueler zijn dan jouw eigen data of omdat deze URI’s al door veel andere organisaties worden gebruikt. De persistente URI van het concept van een fles is bijvoorbeeld al reeds toegekend door de Art & Architecture Thesaurus (AAT) van Getty: http://vocab.getty.edu/aat/300045627.

Door toepassing van dit linkeddataprincipe ontstaat er op het web een netwerk van gekoppelde authorities en data. De data over uiteenlopende collecties die worden ontsloten via verschillende websites kunnen zowel met elkaar als met data van buiten de cultureelerfgoedsector (bv. data uit Wikidata) verbonden worden.

Je kunt je eigen data koppelen aan data uit een externe dataset door ze met behulp van Open Refine te reconciliëren met andere data, bijvoorbeeld met gecontroleerde woordenlijsten of andere authorities die in de erfgoedsector of daarbuiten gangbaar zijn (bv. Wikidata). Om je dataset te kunnen reconciliëren met een externe dataset, moet die dataset wel een webservice hebben die voldoet aan de Reconciliation Service API-standaarden.

Stap negen: publiceren van data

Zoals beschreven in stap 5 Data converteren moet er nagedacht worden over hoe je de data zal publiceren op het web. Deze keuze moet afgestemd zijn op de noden van de doelgroep die je wenst te bereiken.

Er zijn verschillende opties voor het publiceren van de dataset:

1. De meest statische optie is het publiceren van de dataset in de vorm van een periodieke en manueel gecreëerde datadump. Die kan de vorm hebben van een bestand in het RDF/XML-, JSON-LD- of Turtle-formaat, een website (bv. Rijksdienst voor het Cultureel Erfgoed Nederland) of bijvoorbeeld op Github-repository (zoals bv. National Portrait Gallery en American Art Collaborative Linked Open Data Consortium deden).).
2. Een meer 'machinevriendelijke' manier om data beschikbaar te maken is het aanbieden van de data via een API, een koppelstuk om gegevens tussen verschillende computersystemen en programma’s uit te wisselen. Op deze tussenlaag kan bijvoorbeeld een ontwikkelaar tools bouwen en zo specifieke data verkrijgen zonder dat hij de interne werking van de databank moet kennen. Het is belangrijk om duidelijke en uitgebreide documentatie rond het gebruik van de API en de structuur van je dataset te voorzien. Goede documentatie bevat de volgende informatie: ieder commando dat je kan gebruiken, de parameters die je kan gebruiken om resultaten te filteren, het resultaat dat je verkrijgt en enkele voorbeelden. Je gepubliceerde open datasets zijn niet bruikbaar zonder deze bijkomende informatie. Je kan hiervoor een aparte pagina op je website voorzien, zoals bijvoorbeeld de API van het Rijksmuseum of de Datapagina van Bibliotheek van UGent.
3. Er bestaat ook een API om beelden beschikbaar te maken, nl. een API die de IIIF-specificatie volgt. Er zijn verschillende soorten IIIF API’s. De twee belangrijkste zijn IIIF Image API en IIIF Presentation API. De Image API maakt het mogelijk om verschillende vormen van een beeld op te vragen via een URL (webadres), op beelden in te zoomen en te kiezen in welke grootte je het beeld toont of welk deel van het beeld je toont. De Presentation API zorgt ervoor dat een erfgoedobject op een correcte manier getoond wordt op een scherm, voorzien van de nodige metadata om het object te identificeren en de rechtenstatus te kennen.
4. Een andere, meer geavanceerde manier om de data machineleesbaar beschikbaar te maken dan via een API, is deze op te slaan in een triple store waarop een SPARQL-endpoint wordt voorzien. Zo’n endpoint biedt de mogelijkheid om heel specifieke queries voor je data op te stellen m.b.v. SPARQL-taal en de gelinkte data en metadata op te vragen. Hierbij kan een onderscheid gemaakt worden tussen een SPARQL-endpoint en een SPARQL-webservice. Het eerste is bedoeld voor machines die de endpoint direct kunnen aanspreken via een URL query terwijl de tweede een interface voor mensen is die zo queries kunnen opstellen en doorgeven, en vervolgens antwoorden in verschillende formaten terugkrijgen. Enkele voorbeelden: de SPARQL-endpoint van Wikidata, van DBPedia, het Europeana SPARQL endpoint of van het Nationaal Archief Nederland).

Een datadump biedt de gebruiker volledige flexibiliteit om te kiezen hoe de data zullen worden verwerkt, maar hij moet wel de datadump volledig downloaden om de data te kunnen gebruiken en dat dumpbestanden meerdere gigabytes groot kunnen zijn. Het up-to-date houden van de data vergt een inspanning: de datadump moet opnieuw gedownload worden of er moet een combinatie van download en incrementele patches gebeuren. Bij terbeschikkingstelling via een API hebben de gebruikers steeds rechtstreekse toegang tot (alleen) de data waarin zij geïnteresseerd zijn. Er is slechts zeer weinig bandbreedte nodig en de data zijn steeds up-to-date. De kosten per aanvraag voor SPARQL-endpoints zijn veel hoger dan voor andere HTTP-servers, en er zijn maar weinig servers die willekeurige ingewikkelde zoekopdrachten toestaan.

Met behulp van technologieën zoals federated queries en Linked Data Fragments, kunnen gebruikers bovendien tegelijkertijd meerdere linked data datasets doorzoeken. Federated queries is een technologie die onder andere toelaat om RDF-datasets te doorzoeken die niet in dezelfde triple store zijn opgeslagen, en elk apart als linked data via verschillende SPARQL-endpoints beschikbaar worden gemaakt. Een nadeel van federated queries is dat zij veel rekencapaciteit vereisen. Dat kan ondervangen worden door gebruik te maken van Linked Data Fragments, een technologie waarbij zowel de linkeddataset (aan de kant van de aanbieder) als de SPARQL-queries (aan de kant van de bevrager) in kleinere clusters worden opgesplitst. De zoekacties worden zo minder log.

Een goede praktijk is om gebruik te maken van meerdere opties. Datagebruikers kunnen dan zelf de methode kiezen die het beste past bij hun doeleinden. Het is aangeraden om zowel een datadumpbestand te voorzien als de data via een API beschikbaar te maken. Het downloaden van bestanden ontlast je server van zware crawl- en query-activiteiten van gebruikers die geïnteresseerd zijn in het bulksgewijs laden van je dataset (bijvoorbeeld indexeren). Met een API of een SPARQL-endpoint kunnen gebruikers via een query een subset van je data selecteren die beantwoordt aan hun interesse. Voorbeelden van instellingen die meerdere opties inzetten zijn:

• Nationaal Archief (Nederland): downloadbare datasets en toegang via een SPARQL-endpoint / -webservice aanbiedt;
• National Library of Finland: downloadbare datasets en toegang via allerhande API’s;
• Bibliothèque nationale de France: downloadbare datasets, SPARQL-endpoint en Sparnatural SPARQL query builder.

Daarnaast kan je ook gebruik maken van gecentraliseerde online platformen om je data te publiceren. Deze platformen hebben een groter bereik en visibiliteit, wat het hergebruik van je data kan vergroten. Sommige platformen bieden ook een API-functionaliteit aan, zodat je data met behulp van specifieke queries systematisch en op een gestructureerde manier bevraagd kan worden:

• generieke internationale platformen:
  • Wikidata (met SPARQL-endpoint);
• internationale platformen voor erfgoeddata:
  • Europeana (met SPARQL-endpoint);
  • Archives Portal Europe;
• landelijke of stedelijke platformen:
  • Data.gov.be;
  • Datavindplaats;
  • Open Data Portaal Gent;
  • Open Data Antwerpen.