IRI Strategie

IRI strategie

In de IRI strategie BGT wordt vastgelegd hoe namen voor objecten in de linked data versie van de BGT zullen worden uitgegeven. Hierbij volgen we grotendeels de Aanzet tot een nationale URI-Strategie voor Linked Data van de Nederlandse overheid (hierna 'Aanzet') en de manier waarop het Kadaster Data Platform (KDP) op dit moment IRIs uitgeeft.

Op sommige punten zullen wij echter afwijken van de Aanzet en/of van de KDP aanpak. We zullen dit doen op onderdelen waar de Aanzet en de KDP methode achterhaald zijn, en op onderdelen waar het letterlijk volgen van de Aanzet en de KDP methode tot nodeloze complexiteit zou leiden.

In lijn met de Aanzet en de KDP aanpak kan een linked data IRI worden opgedeeld in de volgende componenten:

{schema}://{domein}/{type}/{subtype}/{referentie}

We zullen elk van deze componenten kort behandelen in een eigen subsectie. Ten slotte zullen we een aantal voorbeelden geven van BGT IRIs die volgens deze strategie zijn aangemaakt.

`{schema}`

Voor de linked data BGT gebruiken we het https schema. In de Aanzet en in KDP wordt het http schema gebruikt. Het verschil tussen deze twee schema's is dat HTTP IRIs geen gebruiken maken van het beveiligingsprotocol SSL, terwijl HTTPS IRIs hier wel gebruik van maken. Het gebruik van het beveiligingsprotocol SSL is de laatste jaren gemeengoed geworden op het Internet. Moderne web browsers laten waarschuwingen zien wanneer een niet-SSL HTTP IRI wordt ingevoerd. Het gebruik van een niet-SSL HTTP IRI binnen een beveiligde applicatie of web pagina wordt eveneens door moderne web browsers aangeduid met een waarschuwing. Ten slotte worden niet-SSL HTTP IRIs lager getoond in zoekresultaten in moderne web zoekmachines. De kans bestaat dat het gebruik van niet-SSL HTTP IRIs op termijn verder ontmoedigd zal worden, en ― binnen sommige omgevingen ― zelfs geheel zal worden geweerd.

Het is technisch mogelijk om zowel niet-SSL HTTP IRIs alsook HTTPS IRIs gelijktijdig te ondersteunen. Hierbij resulteert het bevragen van een niet-SSL HTTP IRI in een doorverwijzing ('redirect') naar de corresponderende HTTPS IRI. Deze oplossing is technisch in te richten, maar heeft de volgende nadelen:

Verwarring bij gebruikers Er komen 2 IRIs in omloop die allebei hetzelfde BGT object identificeren. Sommige gebruikers zullen de HTTP IRI gaan gebruiken en anderen zullen de HTTPS IRI, mogelijk ook door elkaar heen, gaan gebruiken. Dit kan voor verwarring bij de gebruiker leiden. De vraag "Welke IRI moet ik gebruiken?" zal frequent en helder beantwoord moeten worden.
Hogere onderhoudskosten Het gebruik van 2 IRIs voor hetzelfde object betekent dat in BGT bevragingen en in BGT applicaties rekening moet worden gehouden met het mogelijke gebruik van 2 soorten IRIs. Bijvoorbeeld een software onderdeel dat op basis van een BGT object identificatie een ander gegeven teruggeeft moet zowel de HTTP IRI alsook de HTTPS IRI kunnen accepteren en verwerken. Per individuele bevraging is dit een relatief kleine investering, echter keert deze investering op veel plekken terug. Daarnaast moeten ontwikkelaars zich blijvend bewust zijn van het mogelijke gebruik van 2 soorten IRIs. Over de tijd heen moet daarom rekening gehouden worden met hogere beheerskosten wanneer voor het gebruik van 2 IRIs gekozen wordt.
Hogere server belasting Wanneer een HTTP IRI bevraagt wordt moet de server doorverwijzen naar de corresponderende HTTPS IRI. Dit betekent dat gebruikers twee bevragingen in plaats van één bevraging moeten uitvoeren. Daarnaast moet de server twee bevragingen in plaats van één bevraging afhandelen. Merk op dat deze extra server belasting in de praktijk zal meevallen, en mogelijk slechts enkele procent extra performance zal kosten. Tegelijkertijd is het niet ondersteunen van HTTP IRIs een eenvoudige manier om een kleine besparing op toekomstige server capaciteit te realiseren.

`{domein}`

Voor het domein volgen we de manier waarop de bestaande linked data basisregistraties door KDP worden ontsloten. Hierbij wordt tevens de Aanpak gevolgd, waarin wordt gewaarschuwd voor het gebruik van een organisatienaam als onderdeel van het domain. (Organisatienamen veranderen namelijk regelmatig.) Dit betekent dat het volgende domein voor de linked data BGT wordt gebruikt:

bgt.basisregistraties.overheid.nl

Dat is in lijn met de volgende bestaande IRI prefixen die door KDP worden aangeboden:

bag.basisregistraties.overheid.nl
brt.basisregistraties.overheid.nl

`{type}`

We stellen voor om de volgende types te gebruiken:

def/ voor definities; dat wil zeggen BGT klassen en BGT eigenschappen.
id/ voor instanties; dat wil zeggen individuele BGT objecten.

In de Aanzet wordt naast def/ en id/ type, ook het gebruik van het doc/ type voorgesteld. Het gebruik van het doc/ type hangt samen met een onderscheiding die traditioneel in linked data gemaakt wordt tussen een object (aangeduid met type id/) en een pagina over dat object (aangeduid met type doc/). Het idee is dat op het moment dat de id/ IRI in een web browser gebruikt wordt een doorverwijzing gevolgd wordt naar de corresponderende doc/ IRI. Merk op dat voor def/ IRIs een dergelijke doorverwijzing niet wordt voorgesteld, alhoewel het onderscheid tussen een concept en een pagina over dat concept theoretisch gezien ook gemaakt zou kunnen worden.

Voor de linked data BGT wordt geen gebruik gemaakt van deze traditionele doorverwijzingspraktijk, omdat het gebruik van id/ en doc/ in de praktijk de volgende problemen veroorzaakt:

Verwarring bij de gebruiker Wanneer gebruik gemaakt wordt van een id/ IRI, wordt deze binnen de web browser automatisch vervangen door de corresponderende doc/ IRI. Dit betekent dat de gebruiker niet zomaar de URL in de web browser kan gebruiken om het opgezochte object mee te identificeren. Een gebruiker moet zich er van bewust zijn dat er een onderscheid wordt gemaakt tussen een object (type id/) en een pagina over dat object in de web browser (type doc/). Omdat dit onderscheid nergens anders op het web gemaakt wordt kan dit tot verwarring leiden bij de gebruiker.
Trager gebruik Wanneer wordt doorverwezen van id/ naar doc/ IRIs duurt een bevraging van een IRI in de web browser langer dan wanneer de id/ IRI direct toegang verschaft tot het opgevraagde web document. Dit is een relatief kleine vertraging van enkele tientallen procenten. Echter, het niet implementeren van de doc/ doorverwijzing is een eenvoudige manier om alle bevragingen van IRIs een klein beetje sneller te maken.
Hogere onderhoudskosten Wanneer wordt doorverwezen van id/ naar doc/ IRIs moet extra code onderhouden worden: er moet immers een doorverwijzing worden onderhouden van de ene naar de andere IRI. De doorverwijzingen in sectie 2.1, van HTTP naar HTTPS IRIs, is een standaard operatie die door bestaande software componenten ondersteund wordt. Dat is niet het geval voor de doorverwijzing van id/ naar doc/ IRIs. Deze laatste vereist in veel gevallen code die geschreven en onderhouden moet worden.
Hogere server belasting Evenals bij de doorverwijzing van HTTP naar HTTPS IRI (sectie 2.1), resulteren doorverwijzingen van id/ naar doc/ IRIs tot een verdubbeling van het aantal bevragingen dat door de server moet worden afgehandeld. Ook dit is weer een performance penalty van ten minste enkele procenten.

`{subtype}`

Het subtype wordt eveneens gebruikt in combinatie met het id/ type om het soort instantie weer te gegeven. Bijvoorbeeld, voor een pand wordt het subtype pand/ gebruikt, waardoor het pand met /id/pand/ begint. Hierin volgt de linked data BGT de Aanzet en de KDP methode.

Omdat het aantal instanties in de BGT er groot is (vele miljoenen) en de referentie vaak betekenisloos is (een arbitraire code), biedt het subtype enige houvast voor het soort van instantie waar we mee te maken hebben. De subtypes zorgen ervoor dat de grote ruimte van instantie IRIs wordt opgedeeld in betekenisvolle categorieën.

Hierbij is het wel van belang dat iedere id/ IRI precies één subtype heeft, die bovendien eenvoudig vast te stellen is. Voor de BGT garanderen we dat voor iedere instantie IRI één directe hoofdklasse wordt toegekend. Bijvoorbeeld, ieder pand is een instantie van klasse bgt:Pand, ieder onbegroeid terreindeel is een instantie van klasse bgt:OnbegroeidTerreindeel, etc. Het {subtype} wordt vervolgens gevormd door de referentie van de klasse te nemen, met een kleine beginletter. Bijvoorbeeld /id/pand/ voor instanties van klasse bgt:Pand, en /id/onbegroeidTerreindeel/ voor instanties van klasse bgt:OnbegroeidTerreindeel.

Voor het def/ type wordt geen subtype gebruikt. De belangrijkste redenen hiervoor zijn dat (1) er veel minder definitie IRIs zijn (enkele tientallen), en (2) de referentie namen voor definitie IRIs vaak al betekenisvol zijn (bijvoorbeeld bgt:Pand of bgt:bestaand).

`{referentie}`

Voor definities wordt gebruik gemaakt van een betekenisvolle naam als referentie. Deze naam moet aan bepaalde syntactische eisen voldoen waardoor deze binnen een IRI gebruikt kan worden. De referentie naam voor een begroeid terreindeel is bijvoorbeeld BegroeidTerreindeel aan elkaar geschreven, omdat spaties in IRIs niet zijn toegestaan.

Daarnaast wordt de referentie voor een eigenschap traditioneel met een kleine letter geschreven, terwijl de referentie voor een klasse traditioneel met een grote letter geschreven wordt. Deze conventie is nuttig omdat er soms een eigenschap is die dezelfde naam heeft als de klasse waar deze eigenschap naar verwijst. Bijvoorbeeld, het NEN 3610 vocabulaire bevat klasse nen3610:Identificatie en een eigenschap nen3610:identificatie.

Voorbeelden van referenties voor definitie IRIs in de BGT zijn Wegdeel voor een klasse, en relatieveHoogteligging voor een eigenschap.

Voor instanties wordt gebruik gemaakt van een betekenisloze identificatiecode. Dit wordt specifiek voor instanties gedaan omdat deze vaak geen betekenisvolle naam hebben. In de context van de BGT is het bijvoorbeeld niet aannemelijk dat ieder begroeid terreindeel of ieder individueel pand een betekenisvolle naam heeft. Om deze instantie IRIs toch nog enigszins te kunnen duiden worden betekenisvolle subtypes gebruikt (zie sectie 2.4).

Scheidingsteken

Tussen elke twee linked data IRI componenten komt een scheidingsteken voor: - Het scheidingsteken tussen het {schema} en het {domein} is de drie-karakter sequentie ://. - Het scheidingsteken tussen de andere componenten is de voorwaartse slash (/).

In de Aanzet wordt een alternatieve aanpak beschreven voor het laatste scheidingsteken: het teken dat direct voor de {referentie} staat. Hiervoor kan in plaats van een voorwaartse slash (/) namelijk een hekje (#) gebruikt worden. Dit alternatieve scheidingsteken kan uitsluitend gebruikt worden voor IRIs die definities aangeven (de def/ IRIs). In de KDP aanpak wordt voor definities gebruik gemaakt van dit alternatieve scheidingsteken.

Het verschil tussen een / en een # teken heeft een belangrijke functionele consequentie: - Wanneer het laatste scheidingsteken een voorwaartse slash (/) is, wordt elke individuele IRI apart opgevraagd. Wanneer een klasse of een eigenschap wordt op gevraagd wordt alleen die ene klasse of die ene eigenschap door de server teruggegeven. - Wanneer het laatste scheidingsteken een hekje (#) is, wordt alle data in één keer opgevraagd. Dit is ook de reden waarom het hekje alleen wordt voorgesteld voor definitie IRIs, omdat het aantal definitie IRIs voor veel datasets klein is (in tegenstelling tot het aantal instantie IRIs). Wanneer een klasse of een eigenschap wordt opgevraagd worden alle klassen en alle eigenschappen teruggegeven.

Voor de linked data BGT wordt als laatste scheidingsteken de voorwaartse slash (/) gebruikt, om de volgende redenen:

Verwarring bij de gebruiker Bij het bevragen van een instantie IRI is de gebruiker gewend om de beschrijving van die ene specifieke instantie terug te krijgen. Wanneer een gebruiker een definitie IRI bevraagt krijgt deze ineens meerdere definities terug. Dit kan verwarrend zijn voor gebruikers die niet bekend zijn met linked data. Daarnaast kan het voor de gebruiker enige moeite kosten om uit de totaliteit van teruggegeven definities de ene definitie op te halen die ook daadwerkelijk bevraagd is. Wanneer de gebruiker goede linked data libraries gebruikt om de gegevens te verwerken is deze extra moeite echter relatief beperkt, omdat goede linked data libraries ondersteuning bieden voor het uitfilteren van de opgevraagde informatie.
Trager in het gebruik Wanneer alle definities worden doorverwezen wanneer één definitie wordt opgevraagd betekent dit dat er meer gegevens moeten worden verstuurd. Hierbij speelt mee dat het model van de BGT ― zeker met inachtneming van de IMGeo uitbreiding ― omvangrijker is dan de meeste modellen die door het KDP worden ontsloten. Dit betekent dat bij gebruikmaking van een hash (#), voor elke bevraging van 1 definitie IRI de teruggegeven hoeveelheid 100 tot 1,000 keer groter zal zijn dan met de voorwaartse slash (/) methode. Wanneer de gebruiker over een minder snelle Internet verbinding beschikt kan deze vermenigvuldiging van de teruggegeven gegevensgrootte voor de gebruiker merkbaar trager zijn. Bij een snellere Internet verbinding zal het verschil minder of geheel niet merkbaar zijn. Tegelijkertijd is de keuze voor de voorwaartse slash aanpak een eenvoudige manier om het benodigde gegevensverkeer te verkleinen.

Conclusie

Op basis van de overwegingen in de voorgaande subsecties komen we tot de volgende IRI strategie voor de linked data BGT:

https://bgt.basisregistraties.overheid.nl/def/{eigenschap}
https://bgt.basisregistraties.overheid.nl/def/{Klasse}
https://bgt.basisregistraties.overheid.nl/id/{subtype}/{referentie}

Aan de hand van bovenstaande IRI templates kunnen concrete IRIs er als volgt uit komen te zien:

De mogelijke IRI voor de BGT klasse die wegdelen aanduidt: https://bgt.basisregistraties.overheid.nl/def/Wegdeel
De mogelijke IRI voor de BGT eigenschap die de relatieve hoogteligging van geospatiële objecten aanduidt: https://bgt.basisregistraties.overheid.nl/def/relatieveHoogteligging
De mogelijke IRI voor een specifiek BGT wegdeel (instantie): https://bgt.basisregistraties.overheid.nl/id/wegdeel/{referentie}

Afwijking van de Aanzet

Zoals in de voorgaande subsecties besproken wijkt de IRI strategie voor de linked data BGT op de volgende punten af van de Aanzet en de KDP aanpak:

De BGT maakt gebruik van HTTPS IRIs.
De BGT verwijst niet door van id/ IRIs naar doc/ IRIs.
De BGT gebruikt de voorwaartse slash (/`) als laatste scheidingsteken.

Menselijk gebruik en machine gebruik

Voor al deze IRIs zal content negotiation ondersteund worden. Dit betekent dat voor menselijk gebruik een HTML pagina met menselijk leesbare inhoud zal worden getoond. Deze HTML pagina wordt automatisch geserveerd door web browsers, die op de achtergrond om content van het Media Type text/html vragen. Voor machine gebruik zal een RDF bestand worden uitgegeven. Dit machine formaat kan worden opgevraagd door een ander Media Type op te geven. Bijvoorbeeld application/n-triples geeft de beschrijving van de bevraagde IRI in het N-Triples formaat terug.