Naast informatiemodellen leverde het OSLO project ook een Vlaamse URI standaard en een Proof of Concept implementatie op die gebruik maakt van Linked Data technologie als Triple Stores. Om de voordelen van OSLO en Linked Data ten volle te benutten is het noodzakelijk om ook in de informatie- en applicatiearchitectuur enkele overwegingen te maken.

Gebruik van URI's

De Vlaamse URI standaard bepaalt dat wanneer een applicatie via een service data ontsluit, en deze data persistent moeten zijn, de vormregels zoals vastgelegd in de URI standaard gevolgd moeten worden. Dit houdt in dat de identificator voor de data objecten een URI moet zijn die het volgend patroon volgt: http(s)://{domein}/id/{concept}(/{referentie})*


Verduidelijking: Wanneer moet mijn data persistent zijn en wanneer moet ik een URI als identificator gebruiken én ontsluiten?

  • Is mijn organisatie de beheerder van het data object?
  • Heeft het data object een waarde voor gebruikers van mijn toepassingen nadat deze klaar is met het bewerken of behandelen van het data object?
  • Verlaat de data de grenzen van mijn applicatie, nu of in de toekomst, bijvoorbeeld in het kader van gegevensuitwisseling of de koppeling van applicaties?

Indien het antwoord op bovenstaande ‘ja’ is moet de applicatie gebruik maken van persistente URI’s in lijn met de Vlaamse URI standaard, voor het ontsluiten van data.
Voorbeeld: een URI ontsluiten als identificator voor mijn data.

Stel, je informatiemodel bestaat uit de volgende entiteiten (klassen): Gebouw en Energieprestatiecertificaat. De applicatie heeft als doel een centraal register uit te bouwen voor energieprestatiecertificaten.

Object Gebouw: de beheerder van het data object gebouw en de bijbehorende informatie is het gebouwenregister. Aangezien ik niet de beheerder ben van dit data object kan ik de identificator (URI) voor een gebouw overnemen van het gebouwenregister, bijvoorbeeld: http://data.vlaanderen.be/id/gebouw/{referentie}

Object Energieprestatiecertificaat: mijn applicatie heeft als doel de centrale bron te zijn voor informatie m.b.t. Energieprestatiecertificaten, bijgevolg valt het toekennen van een URI als persistente identificator onder mijn verantwoordelijkheid (1). Nadat een energieprestatiecertificaat werd aangemaakt of bewerkt in de applicatie, moeten derden informatie over dit certificaat kunnen raadplegen aan de hand van de identificator van het Energieprestatiecertificaat, de identificator voor energieprestatiecertificaat moet dus persistent zijn aangezien het gebruikt wordt in toepassingen van derden (2). Tot slot moeten derden deze informatie rechtstreeks kunnen opvragen aan de hand van deze identificator (3).

Conclusie: mijn organisatie moet voorzien in persistente URI’s voor het ontsluiten van gegevens m.b.t. Energieprestatiecertificaten, deze worden gelinkt aan de bestaande URI’s voor gebouwen.
Aanbeveling: Wanneer in bovenstaand voorbeeld data over het energieprestatiecertificaat de applicatie niet verlaat is niet voldaan aan de derde voorwaarde voor het gebruik van persistente URI’s als identificator. Bijgevolg is het gebruik en beheer ervan niet verplicht. Echter, met het oog op toekomstbestendigheid kan het alsnog wenselijk zijn om URI’s als identificator op te nemen zonder ze dereferenceable te maken.

Doorverwijzen naar een beschrijving van de resource

Regel 4.2 van de URI standaard stelt dat: “Voor elke URI van het type id moet een gelijkvormige URI van het type doc bestaan. Die doc- URI mag eventueel opnieuw één of meerdere keren doorverwijzen naar de URI waar het eigenlijke document zich bevindt. De URI van het uiteindelijke document hoeft zich niet noodzakelijk aan de vormregels te conformeren.”. In praktijk betekent dit dat de identificator (URI) van een data object kan gebruikt worden om rechtstreeks meer informatie over het object op te vragen, maar dat deze URI mag doorverwijzen naar een URI die niet noodzakelijk conform is met de URI standaard.


Voorbeeld: doorverwijzing van /id naar /doc

http://data.vlaanderen.be/id/organisatie/1234 wordt gebruikt als identificator voor de organisatie Example NV. Wanneer deze URI zou worden ingevoerd in een browser, zou de gebruiker worden doorverwezen naar http://data.vlaanderen.be/doc/organisatie/1234 waar een beschrijving van deze organisatie te zien is. Een alternatief is dat deze URI voor de beschrijving van de organisatie opnieuw doorverwijst naar een derde URI, bijvoorbeeld http://example.com.

Gebruik van HTTP status codes

Interpretatie van de HTTP status codes (bij gebruik URI’s als identificator):


  • 2XX Success: de URI identificeert een web-document en is succesvol opgehaald.
  • 303 See Other: de URI identificeert een niet-informatieresource. Een object uit de reële wereld zoals een persoon of een gebouw die beschreven wordt aan de hand van een document op het web. De 303 HTTP status code wordt gebruikt om de gebruiker door te verwijzen naar een document dat het object beschrijft.
  • 410 Gone: het object waar de URI naar verwijst is verwijderd omdat het niet meer bestaat of omdat het niet meer beschikbaar is (bijvoorbeeld omdat de informatie is gearchiveerd).

Voorbeeld: gebruik van HTTP status codes

Stel, Example NV is een bedrijf dat huisdieren verkoopt, meer bepaald konijnen. Example NV heeft een website, http://www.example.com/, het resolven van deze URI resulteert in een HTTP 200 OK response aangezien het om een web-document gaat.


Het bedrijf heeft momenteel twee konijnen in stock: Bob en Alice. Deze konijnen worden beschreven op de website: foto’s, naam, geslacht, herkomst,... en worden geïdentificeerd met behulp van onderstaande URIs:
http://www.example.com/id/konijn/bob
http://www.example.com/id/konijn/alice


Deze URI’s resolven zal resulteren in een HTTP 303 See Other status code die de gebruiker respectievelijk verwijst naar onderstaande pagina's, waar de informatie met betrekking tot deze konijnen te vinden is:
http://www.example.com/doc/konijn/bob
http://www.example.com/doc/konijn/alice


Wanneer Alice verkocht wordt, wil het bedrijf niet langer dat deze informatie te raadplegen is via hun website. Als een gebruiker na de verkoop toch nog informatie zou opvragen over het konijn Alice ontvangt deze een HTTP 410 Gone status code.

Content Negotiation

Content negotiation kan gebruikt worden om een persoon dan wel machineleesbare versie van het document weer te geven. Zo kan eenzelfde informatie object in HTML, JSON, RDF of ander formaat worden getoond. Meer informatie: URI-richtlijnen voor data.vlaanderen.be.


Voorbeeld: gebruik van content negotiation

Gebruiker vraagt een persoonleesbare versie op van het document:

GET http://www.example.com/id/alice HTTP/1.1
Host: www.example.com
Accept: text/html
Accept-Language: en, nl

Gebruiker vraagt een machineleesbare versie op van het document:

GET http://www.example.com/id/alice HTTP/1.1
Host: www.example.com
Accept: application/ld+json,application/rdf+xml
Accept-Language: en, nl

Gebruik van NoSQL databases en Triplestores

Zie handreiking voor de ontwikkelaar.

Gebruik van REST API's

Zie handreiking voor de ontwikkelaar.