Deze release bevat weinig zichtbare nieuwe functies voor eindgebruikers; de meeste verbeteringen zijn technisch van aard en verhogen de stabiliteit van de toepassing. Eén nieuwe functie is een eenvoudige boomweergave waarmee het afdrukken van een thesaurus haalbaar wordt.

De breaking change heeft te maken met hoe en wanneer skosprovider.registry.Registry geïnstantieerd wordt: voorheen gebeurde dit bij het opstarten van de toepassing, nu gebeurt dit per request. De oude manier van werken zorgde voor problemen met SQLAlchemy-providers op een webserver met meerdere threads. Zie de customisation-documentatie voor hoe dit nu werkt, en de documentatie van pyramid_skosprovider voor achtergrond.

Python 2-ondersteuning wordt over de hele softwarestack afgebouwd:

• atramhasis laat dit vallen vanaf 1.0.0
• skosprovider vanaf 0.8.0
• language-tags liet dit al vallen vanaf 1.0.0
• pyramid_skosprovider vanaf 0.10.0
• skosprovider_sqlalchemy vanaf 0.7.0
• skosprovider_atramhasis liet dit al vallen vanaf 0.4.0
• skosprovider_getty vanaf 0.6.0
• skosprovider_rdf vanaf 0.9.0
• skosprovider_heritagedata wordt momenteel niet meer onderhouden

Ook SKOS-collecties kregen een fix: we gingen er steeds van uit dat concepten in een collectie ook smallere concepten waren van het overkoepelende concept van die collectie, maar de implementatie hiervan was onvolledig en bevatte bugs. Collecties hebben nu een boolean-attribuut infer_concept_relations: staat dit op true, dan worden concepten in de collectie beschouwd als smallere concepten van het overkoepelende concept; staat het op false, dan niet. Dit heeft vooral invloed op de expand-functie van een provider en op hoe thesaurus arrays of node labels geïnterpreteerd worden.

We hebben ook geïnvesteerd in SEO: conceptdetailpagina's bevatten nu HTML-metadata zoals een canonical URL, een Twitter card en OpenGraph-info, en een nieuw script kan een XML-sitemap genereren voor je installatie.

De Atramhasis admin-interface

Weet je niet goed hoe Atramhasis er uitziet of wat het doet? De documentatie heeft nu een aparte sectie die dit uitlegt.

Zoals steeds zijn er bugs opgelost; zie de release notes van 0.7.0 voor de volledige lijst van wijzigingen. Bekijk een werkend voorbeeld op thesaurus.onroerenderfgoed.be. Vragen of problemen: het forum of onze GitHub tracker.

Binnen het agentschap Onroerend Erfgoed proberen we al heel lang (sinds 2005 of zo) zo stabiel mogelijke URI's te hebben. Moeten we een URL toch wijzigen of opheffen, dan zetten we op de oude URL een doorverwijzing (redirect) naar een pagina met dezelfde of gelijkaardige informatie. Zo surf je nog steeds naar de inventaris via https://inventaris.vioe.be, ook al is https://inventaris.onroerenderfgoed.be al jaren de canonieke URL, en stuurt https://www.erfgoed.net/beschermingen je nog altijd naar het zoekformulier voor beschermd erfgoed, ook al bestaat die oorspronkelijke pagina al bijna tien jaar niet meer.

Nadeel: veel mensen beseffen niet dat URL's gewijzigd zijn, en oude URL's blijven her en der op websites staan, doorverwijzend naar nieuwe. Hoe langer dat duurt, hoe complexer de logica van doorverwijzingen wordt — oude URL's die naar minder oude URL's leiden, die op hun beurt weer naar actuele URL's doorverwijzen. Eens de herinnering aan die oude systemen vervaagt, wordt het ook voor ons moeilijker om alles draaiend te houden. Daarom geven we vandaag een overzicht van een aantal veelvoorkomende oude links, met de focus op beschermd erfgoed (de inventaris zelf komt in een later bericht aan bod).

Informatiesystemen voor beschermd erfgoed​

Lang voor het internet echt een ding was, bestond er al een eerste informatiesysteem voor beschermd erfgoed: Melanie, voluit Monumenten En LANdschappen InformatiEsysteem. Aanvankelijk helemaal niet verbonden met het internet, kreeg het later een online ontsluiting van de beschermde objecten in een schaduwdatabank. Ondanks het ontbreken van URI's kreeg elk beschermd object toen al een uniek nummer volgens een vast stramien: een O (voor object), een letter per provincie (W, O, A, L, B), en zes cijfers tussen 000000 en 999999 — het Melanie Object Nummer, zoals OO003255 of OW000678. Dit soort nummers duik je vaak nog op in hedendaagse fiches van aanduidingsobjecten. Daarnaast bestonden er Melanie Dossier Nummers, met dezelfde structuur maar een D in plaats van een O — meerdere objecten konden immers samen in één dossier beschermd worden, zoals DA002378, dat over 4 beschermde monumenten van 1 architect ging.

Toen Monumenten en Landschappen opging in het agentschap Ruimte en Erfgoed, werden ook de informatiesystemen samengevoegd. Melanie werd bedankt voor bewezen diensten, en haar taken werden overgenomen door Bredero, het dossieropvolgingssysteem dat al langer voor Ruimtelijke Ordening gebruikt werd. Ook hier bestonden de concepten object en dossier. Een Bredero-nummer bestaat uit drie delen, gescheiden door schuine strepen: het type document (beschermd monument, stadsgezicht, beschermingsdossier, ...), een 5-cijferige NIS-code voor de gemeente of provincie, en een volgnummer. Een volledig nummer ziet er dan uit als 4.01/43005/162.1 (een beschermd monument), 4.03/40000/107.1 (een beschermd landschap) of 4.001/30000/2517.1 (een beschermingsdossier).

Bij de oprichting van het agentschap Onroerend Erfgoed in 2011 werd al snel duidelijk dat Bredero wel geschikt was voor dossieropvolging, maar niet voor een stabiele omgeving met doorgedreven objectgerelateerde erfgoedinformatie. De bestaande Inventaris Onroerend Erfgoed bood daarvoor veel meer mogelijkheden, en uit die synergie ontstonden de aanduidingsobjecten (zie Erfgoedobjecten en aanduidingsobjecten). Bij het opbouwen van die dataset namen we de oude identificatoren maximaal over, waardoor je vandaag op de pagina van een aanduidingsobject onder Beschermingsdossiers nog een lijst van oudere nummers terugvindt. De inventaris zelf leefde altijd al op het web en werkte altijd al met URI's, en sinds het ontstaan van de aanduidingsobjecten volgen we de URI-richtlijnen van de Vlaamse Overheid. Zo vind je de parochiekerk Sint-Petrus en Sint-Paulus te Hansbeke terug onder het oude Melanie-nummer OO001175, het equivalente Bredero-nummer 4.01/44049/119.1, én de nieuwe URI https://id.erfgoed.net/aanduidingsobjecten/10535.

Zoeken naar Melanie- of Bredero-nummers op het zoekformulier van de aanduidingsobjecten

Het project beschermingsdatabank omvatte onder meer het overzetten van beschermde objecten uit Bredero naar de aanduidingsobjecten, met veel aandacht voor datakwaliteit, een herevaluatie van oude gegevens, en het toevoegen van nieuwe informatie zoals locatiegegevens en thesaurustermen. Soms was het nodig om een oud Melanie- of Bredero-nummer op te splitsen in verschillende delen, waardoor één oud nummer vandaag soms door meerdere fiches wordt voorgesteld — eerder uitzondering dan regel. Om het jou makkelijk te maken kan je gewoon zoeken op een oud nummer: ga naar het zoekformulier van de aanduidingsobjecten en tik onderaan bij Ander nummer? het Melanie- of Bredero-nummer in.

Oude URL's​

Heb je nog ergens een oude URL in gebruik, dan zal daarin steeds een Melanie- of Bredero-nummer staan. URL's uit de periode 2012-2016 zien er wellicht zo uit: https://beschermingen.onroerenderfgoed.be/object/id/OO001175 of https://beschermingen.onroerenderfgoed.be/object/id/4.01/44049/119.1. Na 2016 stuurden we dat verkeer door naar een pagina op de inventaris zoals https://inventaris.onroerenderfgoed.be/erfgoed/beschermd/OO001175, waar alle gekoppelde aanduidingsobjecten getoond werden (of je werd rechtstreeks doorgestuurd als er maar één was). Vandaag sturen we dat verkeer naar bijvoorbeeld https://inventaris.onroerenderfgoed.be/aanduidingsobjecten?ander_nummer=OO001175, waar je alle aanduidingsobjecten ziet die met dat oude nummer overeenkomen.

Heb je nog oudere URL's zoals http://paola.erfgoed.net/engine/fiche.php?id=000816&pv=O, dan werken die niet meer, maar kan je het Melanie-nummer makkelijk reconstrueren: neem de waarde van pv, gevolgd door een O, gevolgd door de waarde van id — dat geeft OO000816, dat je dan weer kan opzoeken onder ander nummer in de nieuwe inventaris. Zo kom je uiteindelijk uit bij de Motte de Hoge Wal in Ertvelde.

Heb je oude links, dan raden we sterk aan om ze om te zetten naar onze nieuwe URI's. Let op het onderscheid tussen de document-URI (bijvoorbeeld de pagina die je kan lezen over de Hoge Wal) en de concept-URI (die het concept van de Hoge Wal als tastbaar object voorstelt). We garanderen enkel persistentie op die laatste: de document-URI hangt vast aan onze domeinnaam onroerenderfgoed.be, gebonden aan onze organisatienaam, terwijl de concept-URI's op erfgoed.net daar geen last van hebben.

Zeg het met een script​

Heb je veel links naar onze site, dan is het best wat werk om die één voor één op te zoeken. Daarom bieden we een kort Python-script aan waarmee je in één keer van heel wat oude Melanie- of Bredero-nummers de bijhorende URI's te weten komt: bewaar het script, voorzie een csv-bestand met een lijst oude identificatoren, en laat het script lopen. Het volledige script vind je terug in de bronrepository van deze blog op GitHub.

Paginering op webschaal​

Bij Onroerend Erfgoed zijn we onze informatiesystemen beginnen afstemmen op deze standaard, vooral op de bouwsteen paginering. Voorlopig kiezen we voor de HTTP Link-header-methode van paginering, zoals hier gespecificeerd en gedetailleerd in RFC 5988.

Om dit in actie te zien, kijk je naar de Link-HTTP-header — via een commandolijntool zoals cURL, een browserplug-in of een REST-client. Wij gebruiken cURL, aangezien die meestal al aanwezig of makkelijk te installeren is op Linux en Mac.

Stel dat we geïnteresseerd zijn in boeken en documenten over Knokke, een kustgemeente in Vlaanderen. De REST API-documentatie op https://bib.onroerenderfgoed.be/api_docs leert ons dat we https://bib.onroerenderfgoed.be/werken kunnen aanroepen met een parameter titel, dus https://bib.onroerenderfgoed.be/werken?titel=knokke geeft ons werken met Knokke in de titel, of in een hoofdstuktitel:

$ curl -G -i -H Accept:application/json https://bib.onroerenderfgoed.be/werken?titel=knokke
HTTP/1.1 200 OK
Date: Mon, 16 Dec 2019 19:51:07 GMT
Server: Apache
Content-Type: application/json
Content-Length: 3933
Access-Control-Expose-Headers: Content-Range, X-Content-Range
Accept-Ranges: items
Content-Range: items 0-9/167
Link: <https://bib.onroerenderfgoed.be/werken?titel=knokke&per_pagina=10&pagina=2>; rel="next", <https://bib.onroerenderfgoed.be/werken?titel=knokke&per_pagina=10&pagina=17>; rel="last", <https://bib.onroerenderfgoed.be/werken?titel=knokke&per_pagina=10&pagina=1>; rel="first"
X-Content-Type-Options: nosniff
Access-Control-Allow-Origin: *
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 1; mode=block

[{"publicatietype": {"url": "http://purl.org/ontology/bibo/Document", "naam": "Document", "id": 1}, "titel": "Het landelijke Knokke", "self": "https://bib.onroerenderfgoed.be/werken/552291", "uri": "https://id.erfgoed.net/infocat/werken/552291", "auteur": "D'hont A.", "id": 552291}, "... nog 9 resultaten ..."]

Deze curl-aanroep haalt boeken en documenten (werken) op uit onze bibliotheekcatalogus met knokke in de titel, en vraagt om ook de headers af te drukken. De header waar het ons hier om gaat is Link:

Link: <https://bib.onroerenderfgoed.be/werken?titel=knokke&per_pagina=10&pagina=2>; rel="next", <https://bib.onroerenderfgoed.be/werken?titel=knokke&per_pagina=10&pagina=17>; rel="last", <https://bib.onroerenderfgoed.be/werken?titel=knokke&per_pagina=10&pagina=1>; rel="first"

We krijgen resultaten terug, maar slechts een gedeeltelijke set. De Link-header vertelt ons dat er een next-pagina, een last-pagina en een first-pagina bestaan — en omdat we op pagina 1 zitten, geen previous. We kunnen deze links volgen om pagina per pagina verder te gaan, of meteen naar het einde springen. Belangrijk: een client mag niets veronderstellen buiten wat de links letterlijk zeggen. Je zou uit "17 pagina's van elk maximaal 10 records" kunnen afleiden dat er tussen de 161 en 170 resultaten zijn, maar de server is niet verplicht om die rekensom te laten kloppen, of om andere informatie in de link te steken. Dit toont meteen een echte beperking van paginering via de Link-header: er is geen manier om te weten hoeveel resultaten er in totaal zijn, of hoeveel pagina's er nog volgen. De client weet enkel of er een next-link is; is die er niet, dan zit je op de laatste pagina, en zijn next en last identiek, dan zit je op de voorlaatste. Het voordeel: de client hoeft niets te weten over de interne structuur van de URL — geen page versus pagina, geen limit/offset — waardoor dezelfde clientcode makkelijk hergebruikt kan worden voor heel verschillende webservices. Het enige wat de client moet weten: is er een next-link, dan is er meer op te halen.

Voor de tweede pagina:

$ curl -G -i -H Accept:application/json https://bib.onroerenderfgoed.be/werken?titel=knokke\&per_pagina=10\&pagina=2

Al jullie data is van ons!​

Om dit te demonstreren schreven we een klein Python-script dat verschillende van onze informatiesystemen bevraagt en de paginering via de Link-header automatisch afhandelt. In Python is de bibliotheek requests de standaard voor REST-aanroepen, en handig genoeg heeft die al ingebouwde ondersteuning voor de Link-header, waardoor het triviaal wordt om over alle resultaten te itereren. Voor dit voorbeeld halen we alle afbeeldingen (Zoeken in de beeldbank), thema's (Thema's, personen en gebeurtenissen), erfgoed- en aanduidingsobjecten (Erfgoedobjecten en aanduidingsobjecten) op voor de gemeente Knokke-Heist. Het is een kort scriptje dat een berg URI's aan je voeten legt, door de verschillende API's te doorlopen en telkens de next-link te volgen.

Als je het script uitvoert, krijg je een lange lijst URI's te zien — functioneel, maar niet meteen bevredigend: een URI is fijn voor een machine, maar zegt een mens op zich weinig.

Geen context, geen informatie​

Een andere interessante techniek in de Linked Data-wereld is JSON-LD (JSON for Linking Data), dat gewone JSON omzet naar linked data door ze via een context te koppelen aan RDF — je definieert daarin welke JSON-sleutels met welke RDF-eigenschappen overeenkomen. Hier is een eenvoudige context die je zou kunnen gebruiken op ons beeldbank-endpoint:

{
    "dct": "http://purl.org/dc/terms/",
    "title": "dct:title",
    "description": "dct:description",
    "uri": "@id"
}

Dit definieert een naamruimte-afkorting dct voor de Dublin Core Terms-naamruimte, zodat dct:title staat voor het volledige http://purl.org/dc/terms/title, en koppelt uri aan @id, de manier waarop JSON-LD de unieke identificator van een record aanduidt. Pas je deze context toe op een afbeelding uit onze beeldbank, dan krijg je:

{
    "@id": "https://id.erfgoed.net/afbeeldingen/392715",
    "http://purl.org/dc/terms/title": "Villa Cools met kinesistenpraktijk",
    "http://purl.org/dc/terms/description": ""
}

Dit vertelt ons dat er een resource is met identificator https://id.erfgoed.net/afbeeldingen/392715, te beschrijven met een Dublin Core title. In JSON-LD is het gebruikelijk om ook een @type toe te kennen, een URI die verwijst naar een klasse in een RDF-vocabulaire, zodat records uit verschillende bronnen onderscheidbaar blijven eens samengevoegd:

{
    "@id": "https://id.erfgoed.net/afbeeldingen/392715",
    "@type": "http://purl.org/dc/dcmitype/Image",
    "http://purl.org/dc/terms/title": "Villa Cools met kinesistenpraktijk",
    "http://purl.org/dc/terms/description": ""
}

Nog eens, met gevoel​

Laten we JSON-LD gebruiken om ons script te verbeteren. We willen een homogene dataset met alles wat we weten over Knokke-Heist, waarbij elk record dezelfde structuur deelt — dus bouwden we twee JSON-LD-contexten, één voor de beeldbank en één gedeeld door de drie nauw verwante inventarisdatasets. Omdat geen van deze datasets standaard hun eigen resourcetype meegeven, voegen we dat zelf toe. Ons inventarissysteem heeft ook een veld locatie_samenvatting dat de geografische locatie van een object samenvat — de onderliggende samenvattingslogica kan behoorlijk complex zijn (sommige dingen liggen in meer dan één straat, gemeente of zelfs provincie), maar is erg handig voor een mens die snel door resultaten bladert. De beeldbank heeft zo'n veld niet, dus berekenen we er zelf een eenvoudig equivalent voor (de locatie van afbeeldingen is veel eenvoudiger dan die van erfgoedobjecten).

Het script haalt alles op zoals voorheen, voegt het recordtype en een locatiesamenvatting voor afbeeldingen toe, en expandeert alles naar JSON-LD met de Python-bibliotheek pyLD. Dat levert geldige, maar onhandige JSON-LD op — elke sleutel is nu een URI. Dus comprimeren we opnieuw, met een derde context gebaseerd op Dublin Core Terms, en drukken we het resultaat af.

Om dit script te draaien, installeer je eerst requests en pyLD. Voor grotere gemeenten zoals Gent of Antwerpen kan het wel even duren. Als extraatje schreven we ook een variant die de resulterende dataset naar een csv wegschrijft in plaats van af te drukken — pas gerust één van beide scripts aan om je eigen dataset voor een andere gemeente op te bouwen.

Interesseren Hypermedia API's en Linked Data je? Op https://data.vlaanderen.be/ vind je veel meer achtergrond en verwijzingen naar de relevante standaarden en documenten, en er is een hele community van Linked Data-mensen die je vragen graag beantwoordt — een aantal van hen vind je op Twitter. Zoals steeds, neem gerust contact op met verdere vragen.

Het geoportaal van Onroerend Erfgoed in 2014

Onze eerste en belangrijkste vereiste was iets dat makkelijk te gebruiken is voor een breed publiek. We merkten dat andere geoportalen vaak vooral GIS-professionals bedienden, en zo eigenlijk een online desktop-GIS bouwden: veelzijdig en krachtig voor wie al met GIS werkt, maar ontoegankelijk voor iedereen anders. Wij wilden een ervaring dichter bij Google Maps, specifiek toegespitst op mensen die informatie over cultureel erfgoed in Vlaanderen zoeken. We wilden ook dat het geoportaal aanvoelde als onderdeel van onze online informatiesystemen, niet als een aparte geodata-silo, en bouwden daarom rapporten die teruglinken naar onze online bronnen via hun persistente URI's. Die URI's zitten als metadata in al onze geografische data, en koppelen elke feature terug aan de authentieke bron waar de ruwe data (inclusief geodata) leeft — zo kan je altijd doorklikken naar de volledige set attributen en alles wat we over een resource weten.

Het geoportaal van Onroerend Erfgoed in 2019

Een tweede vereiste kwam voort uit de data zelf. Onroerend Erfgoed maakt en publiceert geodata over onroerend erfgoed, maar geen andere geodata, en dat wilden we niet apart gaan doen voor het geoportaal — dus steunen we sterk op publiek beschikbare webservices. Informatie Vlaanderen (vroeger AGIV) is al sinds het begin onze partner voor achtergrondkaarten en niet-erfgoedlagen, en we namen ook lagen op van andere partijen, zoals Mercator of buitenlandse instanties (bv. de Nederlandse Rijksdienst voor het Cultureel Erfgoed). Informatie Vlaanderen levert ook alfanumerieke diensten om kaarten te navigeren: de CRAB-dienst met alle adresgegevens in Vlaanderen, de CAPAKEY-dienst met kadastrale percelen, en een geolocatiedienst voor vrije-tekst adreszoekopdrachten. We wilden deze diensten gebruiken zonder hun data volledig te kopiëren, zoals tien jaar eerder misschien wel gebeurd was — we bewaren er zo weinig mogelijk van, hoogstens een cache hier en daar, zodat wat we tonen altijd overeenkomt met de bron.

Tot slot wilden we, vanuit technisch oogpunt, met open source software werken (kostenefficiënt, en een goede match met onze stack) en een portaal dat eenvoudig te onderhouden is, maar toch fijn configureerbaar — eenvoudige zaken (een nieuwe databron toevoegen) moeten eenvoudig zijn, moeilijke zaken (bepaalde requests optimaliseren) moeten mogelijk zijn. Die filosofie werkt goed: een vrij lichte codebase bedient onze bezoekers al jaren.

Softwarearchitectuur van het geoportaal

Waar bracht dat ons? Zoals elke moderne toepassing bestaat het geoportaal uit een back- en een frontend. De frontend is het grootste deel van de code (ongeveer 98% JavaScript, HTML en CSS): de kaartlay-out, UI/UX en algemene presentatie. Omdat die code al enkele jaren geleden geschreven werd, draait ze nog op een ouder JavaScript-framework, Dojo, met OpenLayers (en PROJ4) voor de kaartinterface, en HTML/CSS gebouwd op de Vlaamse huisstijl met het Zurb Foundation-framework. De frontend communiceert uitsluitend via services, met onze eigen geoportaal-backend of met andere webservices.

Die andere services zijn grotendeels INSPIRE-conforme WMS-, WMTS- en WFS-diensten, gehost door verschillende partijen:

• Informatie Vlaanderen host een groot aantal referentiedatasets — achtergrondkaarten, luchtfoto's, historische kaarten, adresgegevens, kadastrale percelen — via de officiële Vlaamse INSPIRE-node.
• Mercator is een INSPIRE-subnode voor datasets binnen het beleidsdomein Omgeving, een cluster van Vlaamse overheidsentiteiten rond thema's als milieu, vervuiling, energie, erfgoed en ruimtelijke ordening. Onroerend Erfgoed publiceert zijn eigen INSPIRE-conforme erfgoeddata via deze subnode.
• Terwijl eindgebruikers onze lagen doorgaans via Mercator ophalen, draaien we voor ons eigen geoportaal een eigen Geoserver-instantie, wat ons meer controle geeft over de presentatie en toelaat om een aantal interne of enkel-geauthenticeerde lagen niet te publiceren.
• We namen ook Nederlandse INSPIRE-erfgoedlagen op van onze collega's bij de Rijksdienst voor het Cultureel Erfgoed — erfgoed houdt zich niet aan politieke grenzen, dus is het nuttig voor onze gebruikers om ook over de grens te kijken, en een gepubliceerde WMS-dienst van een andere partij is makkelijk te integreren.

We gebruiken ook een paar niet-INSPIRE-lagen: OpenStreetMap als degelijke algemene achtergrondkaart, de NGI-topografische kaart voor wie daarin geïnteresseerd is, en, vooral voor de fun, de Pelagios-kaart van het Romeinse Rijk.

De backend van het geoportaal is een eenvoudige Python-toepassing gebouwd op het Pyramid-framework. Naast het serveren van de statische bestanden voor de frontend, is haar voornaamste taak het proxyen van een aantal locatiediensten van Informatie Vlaanderen:

• Geolocatie, die adressen suggereert op basis van vrije tekst en coördinaten teruggeeft — een snelle manier om op de kaart te navigeren.
• CRAB, een uitgebreidere dienst met volledige adresgegevens (gemeenten, straten, huisnummers en hun locatie). We gebruiken deze dienst in vrijwel al onze systemen om binnenkomende data te valideren; in het geoportaal dient ze als navigatiehulp, waarmee gebruikers van provincie naar gemeente, straat en adres kunnen doorklikken.
• CAPAKEY, een REST-service met perceelgegevens (gemeenten, kadastrale afdelingen, secties en perceelnummers), die op een gelijkaardige manier gebruikers door het Belgische kadastersysteem naar een specifiek perceel leidt.

Deze drie diensten zijn vandaag vrij en open beschikbaar, waardoor het proxyen ervan minder vanzelfsprekend lijkt dan toen we in 2013 begonnen:

• Aanvankelijk waren zowel CRAB als CAPAKEY SOAP-diensten, moeilijk of onmogelijk rechtstreeks vanuit browser-JS aan te spreken. CAPAKEY is intussen overgeschakeld naar REST, maar CRAB is nog steeds SOAP. Beide vereisten in het begin ook authenticatie, waardoor we via een proxy de inloggegevens konden afschermen.
• Het bespaart ons gedoe met CORS-headers — we gebruiken CORS al veel, maar alles goed op elkaar afgestemd krijgen kan lastig zijn, en de geolocatiedienst ondersteunt CORS helemaal niet, wat ons anders zou dwingen tot iets als JSON-P.
• Het beschermt ons tegen wijzigingen aan de bovenliggende API's: omdat onze toepassingen altijd onze eigen proxies aanspreken, moet enkel de proxy een upstream-wijziging (zoals de overstap van CAPAKEY van SOAP naar REST) opvolgen, waardoor de impact op onze systemen minimaal en beperkt blijft.
• De proxies voor CRAB en CAPAKEY dienen ook als cache, wat het aantal oproepen naar de bovenliggende diensten sterk vermindert.
• We breidden deze diensten op een paar punten uit voor onze eigen noden — met een lijst van Vlaamse provincies (die noch CRAB noch CAPAKEY bevat), en met een lijst van landcodes voor adresvalidatie.

Heb je zelf Vlaamse adres- of perceelgegevens nodig en werk je met Python, gebruik dan gerust onze CRABpy-bibliotheek; werk je met Pyramid, dan vereenvoudigt CRABpy_pyramid de integratie en voegt het een reeks kant-en-klare JSON-views toe.

De andere grote backend-component is een open source project genaamd Mapproxy, dat een tijdlang het lastigste aspect van het bouwen van het geoportaal oploste: omgaan met niet-publiek toegankelijke ruimtelijke data. Ons belangrijkste voorbeeld is een databank van archeologische vindplaatsen die, om verschillende redenen, niet publiek is — de data maakt geen deel uit van INSPIRE, maar heeft wel WMS/WFS-diensten op onze eigen Geoserver, beveiligd met gebruikersnaam en wachtwoord. Deze dienst rechtstreeks in onze frontend opnemen zou die inloggegevens blootstellen aan clients; Mapproxy lost dit op door de dienst te proxyen op onze geoportaal-server en zelf authenticatie en autorisatie af te handelen, waardoor we dezelfde Pyramid-authenticatie- en autorisatiebeleidsregels die we in al onze webtoepassingen gebruiken, kunnen vertalen naar regels over wie welke GIS-lagen mag zien.

Naast dit veiligheidsgerelateerde proxyen, routeren we ook WMS GetFeatureInfo-requests via Mapproxy om CORS-problemen te vermijden, en overwegen we op termijn ook de cachingfunctionaliteit ervan te gebruiken, al deden we dat tot nu toe nog niet.

Al bij al is ons geoportaal een belangrijk platform gebleken, gebruikt door zo'n 12.000 mensen per maand in vrij intensieve sessies, en toch goedkoop om te bouwen en te onderhouden — het portaal zelf vraagt weinig middelen, want het zware werk gebeurt door onderliggende diensten die ook voor andere toepassingen en processen gebruikt worden. Interesse in onze opzet? Bekijk het geoportaal, onze bibliotheken op GitHub, lees meer berichten met de tag geoportaal, of stuur ons een mail naar ict@onroerenderfgoed.be.

Geen innovatie zonder verspreiding​

Bij innovatie denk je snel aan technologie, maar ook de samenleving zelf innoveert voortdurend — soms als motor, soms als volger van technologische vooruitgang. Eén van de duidelijkste evoluties van het voorbije decennium is de beweging naar openheid: open source software, open data en open access staan centraal in de hedendaagse informatiemaatschappij. Zowel Onroerend Erfgoed als de Vlaamse Overheid ondersteunen open data en open access. Op het vlak van open data onderschrijft de overheid het Smart Flanders Open Data Charter; Onroerend Erfgoed publiceerde al verschillende open datasets, zoals onze thesauri en gecontroleerde vocabulaires, onder de Vlaamse open data-licentie, en we publiceren ook de software waarmee we ze onderhouden als open source.

Op het vlak van wetenschappelijke open access willen we al onze publicaties gratis toegankelijk maken. Vrijwel al onze onderzoeksoutput verschijnt via OAR, ons Open Access Repository. De voorbije jaren investeerden we in het digitaliseren van publicaties van onze voorgangers, en we hebben nu een online archief dat teruggaat tot de jaren tachtig, volledig vrij te downloaden. Digitaliseren klinkt misschien triviaal — scannen en online zetten — maar auteursrecht en het opstellen van goede metadata maken het bewerkelijker dan het lijkt. Het loont wel: sinds we onze back catalogue digitaliseerden en publiceerden, verdubbelde het aantal downloads per maand, en raadplegen intussen zo'n 15.000 publicaties per maand digitaal geraadpleegd worden.

Aantal downloads per maand via OAR

Beelden zeggen meer dan woorden​

Onze publicaties blijven een belangrijk geschreven informatiekanaal, maar visuele informatie wint alsmaar aan belang. Erfgoedprofessionals documenteren erfgoed en zijn toestand al sinds het bestaan van de camera, en digitale camera's — recenter smartphones met goede camera's — hebben dat proces alleen maar versneld. We schatten dat er enkele miljoenen foto's circuleren binnen ons agentschap, zowel analoog als digitaal. In 2019 lanceerden we een nieuwe online beeldbank met zo'n 280.000 afbeeldingen van erfgoed in Vlaanderen, deels recent, deels gedigitaliseerd uit analoge archieven. Ook hier was hergebruik belangrijk: waar mogelijk publiceren we onder een open licentie die hergebruik toelaat, zelfs commercieel, zolang de bron vermeld wordt.

Een reeks afbeeldingen in de beeldbank, gevonden via de zoekterm "Bijloke"

Het systeem draait nu al een tijdje en onze basisbehoeften blijken gedekt, dus pakken we nu complexere problemen aan. Eerst en vooral AVG en privacy: onze foto's worden weliswaar op openbaar toegankelijke plekken genomen, maar zaken als nummerplaten en gezichten gelden als gevoelige data. We hebben manuele controleprocedures, maar die zijn traag en arbeidsintensief, dus onderzoeken we automatische detectie en vervaging van nummerplaten en gezichten met OpenCV. Voor nummerplaten zijn de resultaten goed; voor gezichten wisselvalliger, wellicht omdat nummerplaten een eenvoudig, voorspelbaar formaat volgen, terwijl gezichtsherkenning nogal gretig is en de neiging heeft om ook schilderijen, beeldhouwwerken of billboards als gezicht te herkennen. Er is nog verfijning nodig voor grootschalig gebruik.

De nummerplaat links werd automatisch vervaagd met OpenCV

Een ander spoor is automatische detectie van dubbele afbeeldingen. Zoals in elke grote organisatie worden bestanden gekopieerd, verspreid en gemaild, en zo komt een afbeelding op meerdere plaatsen terecht — wat opslagruimte kost en, omdat elke afbeelding metadata nodig heeft, ook die inspanning verdubbelt. We onderzoeken automatische detectie van duplicaten; image hashing blijkt veelbelovend, en we zullen wellicht voor het dHash-algoritme kiezen. We zoeken nu uit hoe we dit netjes kunnen integreren in onze archiveringsworkflows, zodat collega's er de vruchten van plukken zonder met de technische details geconfronteerd te worden — innovatie wordt pas echt productief als ze samengaat met bruikbaarheid.

Als overheidsagentschap dat met onroerend erfgoed werkt, heeft vrijwel alles wat we verzamelen een ruimtelijke component, en onze afbeeldingen vormen daarop geen uitzondering. Bijna elke foto die we nemen toont een vorm van onroerend erfgoed — een archeologische site, een cultuurlandschap, een gebouw, een begraafplaats, ... — dus investeerden we flink in het geolokaliseren van de afbeeldingen in onze beeldbank. Oudere afbeeldingen koppelen we aan de erfgoedobjecten die ze tonen en erven zo hun locatie; nieuwere afbeeldingen steunen op de automatische geolocatie van moderne smartphones en camera's. De resulterende GIS-laag met puntlocaties kan je bekijken op ons geoportaal of downloaden voor eigen gebruik, en elke foto linkt door naar de beeldbank voor meer info, download en hergebruik — mits je de licentie respecteert.

Een zicht op de Bijloke-site in Gent met alle gekende afbeeldingen van deze omgeving

Geef me een kaart en ik verdwaal nooit meer​

Bijna alles wat we doen heeft een ruimtelijke component, en dus zijn kaarten essentieel voor ons. Als overheidsagentschap publiceren we INSPIRE-conforme datasets, verspreid via het INSPIRE-netwerk in heel Europa — vooral gericht op professionele GIS-gebruikers met eigen desktopsoftware. Maar we voelden dat we een deel van ons doelpubliek misten: mensen die snel willen weten wat er gekend is over hun buurt, hun eigendom, of een plek uit hun kindertijd. Daarom bouwden we ons eigen Geoportaal, een website waar een gewone, niet-GIS-gebruiker een (hopelijk) intuïtieve kaart van Vlaanderen kan raadplegen — zowat "Google Maps voor Erfgoed". Niet meer nieuw, maar nog steeds erg populair, en omdat het specifiek geoptimaliseerd is voor erfgoeddata, werkt het daarvoor beter dan een algemeen portaal. Voor algemene ruimtelijke data verwijzen we graag naar Geopunt, het geoportaal van de Vlaamse Overheid voor alle ruimtelijke data — dat bevat veel meer data dan wij nodig hebben, maar is niet specifiek geoptimaliseerd voor erfgoedinformatie.

De hedendaagse stad Zottegem en haar beschermd erfgoed op de Villaretkaart (1745-1748)

Bezoek je het Geoportaal voor het eerst, dan kies je uit twee profielen — vaste combinaties van kaartlagen, één een goede standaardkeuze voor de meeste mensen, de andere afgestemd op gebruikers die vooral in de juridische kant van erfgoed geïnteresseerd zijn (notarissen, vastgoedmakelaars, projectontwikkelaars, andere overheden, ...). Je kan altijd andere lagen laden. Sommige verwijzen naar onze andere systemen, zoals de eerder genoemde beeldbank, of naar archeologische rapporten die archeologen indienen. Onder de achtergrondlagen zitten verschillende orthofotolagen, maar ook historische kaarten, sommige daterend uit de 18e en 19e eeuw — deels geleverd door Informatie Vlaanderen, andere, zoals de Villaretkaart (1745-1748), door onszelf gedigitaliseerd in samenwerking met hen.

Bekijk ons portaal, surf over de kaart en verdiep je in de plekken en beelden die je er vindt.

Wanneer punten wolken van informatie worden​

De stad Damme en haar verdedigingswerken op de multidirectionele hillshade

Tot slot nog een laatste project rond kaarten. Onze collega's bij Informatie Vlaanderen creëerden het Digitaal Hoogtemodel Vlaanderen (DHMV), een LIDAR-dataset bestaande uit een Digital Surface Model en een Digital Terrain Model, die samen hoogtegegevens geven waarmee je het Vlaamse terrein op verschillende manieren kan visualiseren. De ruwe data is open, maar er nuttige visualisaties van maken vraagt heel wat expertise, dus bestaan er al een tijdje enkele standaardweergaves. We wisten dat er visualisaties mogelijk waren die beter geschikt zijn voor archeologen, en die het makkelijker maken om archeologische sites te detecteren op basis van micro-topografie. Daarom werkten Onroerend Erfgoed en Informatie Vlaanderen samen aan twee nieuwe verwerkingen van het DHMV en publiceerden die. Elke verwerking gebruikt andere technieken en parameters, dus welke het meest helpt hangt af van wat je zoekt.

Loopgraven en een fort bij Kapellen op de skyview factor

Het resultaat is erg nuttig gebleken voor archeologen in hun dagelijkse werk — met een blik op deze twee lagen, op het Geoportaal of gedownload in hun eigen GIS, kunnen ze snel het potentieel van een site of locatie inschatten. Wil je het zelf uitproberen, ga dan naar het Geoportaal en kies onder Lagen > Achtergrondlagen > Digitaal Hoogtemodel > DHMV II, multidirectionele hillshade of DHMV II, skyview factor. Dit project bleek succesvoller dan verwacht, en de impact reikte verder dan archeologie of erfgoed alleen — het werd zelfs genomineerd voor een Datanews ICT Project of the Year en een Agoria e-Gov Award Open Data.

We hopen dat dit toont dat er een echte synergie bestaat tussen erfgoed en technologie, nu we verder de 21e eeuw intrekken. Zoals bij elke organisatie is technologie diep verweven geraakt met onze dagelijkse werking. Satya Nadella, CEO van Microsoft, zei het ooit zo: "Every company is now a software company" — en dat geldt evengoed voor een overheidsagentschap of een cultureel-erfgoedinstelling. Software is overal, digitaal is overal, en hoewel ons cultureel erfgoed nog grotendeels analoog is, zijn de instrumenten en informatiebronnen waarmee we het bestuderen dat allang niet meer, en zullen ze dat ook nooit meer worden.

Vragen? Neem contact op, blader door de rest van deze blog, bekijk onze open source projecten of bezoek onze website.

De homepagina van de beeldbank

Op de homepagina van de beeldbank vind je bovenaan een eenvoudige zoekbalk, waarmee je zoals bij elke typische zoekmachine op één of meerdere termen kan zoeken. Zoek je bijvoorbeeld naar Knokkestraat, dan krijg je 18 resultaten, gesorteerd op relevantie — net als bij de inventaris (Full text zoeken in de inventaris) staat het meest "Knokkestraat-achtige" resultaat bovenaan: een aantal afbeeldingen van huizen in de Knokkestraat te Knokke-Heist, waar de straatnaam zowel in de titel als in het adres voorkomt. Daarna volgen afbeeldingen uit de Knokkestraat in Diksmuide, Zwevegem en Wachtebeke, waar de naam wel in de titel maar niet in het adres staat.

Afbeeldingen waarin de zoekterm knokkestraat voorkomt, met enkele facetten

Op deze zoekpagina kan je het resultaat verfijnen met facetten: filters op de bestaande dataset, zoals Provincie, Gemeente, Jaar, Maker en Licentie. Elk facet toont alle mogelijke waarden met hun aantal — zo zie je meteen dat er 8 afbeeldingen uit Knokke-Heist zijn en maar 1 uit Diksmuide. Het facet Licentie toont onder welke voorwaarden een afbeelding hergebruikt mag worden.

Het vrije tekstveld ondersteunt dezelfde full-text zoekoperatoren als de inventaris:

• Meerdere zoektermen worden impliciet als EN gecombineerd: molen knokke is gelijk aan molen & knokke.
• Voor OF gebruik je het |-teken: molen | knokke.
• Voor NIET gebruik je een - vlak voor de term: molen -knokke.
• Meerdere termen als één laten gelden kan met aanhalingstekens: zoek je naar van daele, dan krijg je 7 afbeeldingen met zowel van als daele, maar zoek je naar "van daele", dan vind je enkel afbeeldingen van de fotograaf met die naam.
• Met een postfix-wildcard * zoek je op een deel van een woord (enkel aan het einde): roze* vindt zowel rozendale, rozeveldstraat als rozebeekstraat.
• Haakjes () groeperen operatoren: dorp* (knokke-heist | brugge) zoekt afbeeldingen met een term die begint met dorp, gekoppeld aan knokke-heist of brugge.

Denk eraan dat het algemene zoekveld op woorden zoekt, wat zowel naar "een gemeente" als "iets anders" kan verwijzen — een zoekopdracht naar brugge* vindt zowel afbeeldingen van bruggen als afbeeldingen uit de gemeente Brugge. Onze zoekmachine rangschikt standaard op relevantie: een afbeelding waarin een term vaker voorkomt weegt zwaarder, en bepaalde velden (titel, locatie, beschrijving) wegen meer door dan andere. Wil je dat niet, dan kan je op de resultatenpagina het veld Sorteren op aanpassen naar titel of opnamedatum.

Full-text zoeken combineert perfect met facetten: zoek je naar brugge* en vink je het jaar 2019 aan, dan zie je alle afbeeldingen uit 2019 met een term die begint met brugge.

Een erfgoedobject in de inventaris onroerend erfgoed met links naar de beeldbank

Naast het zoekformulier zijn er nog andere manieren om afbeeldingen te vinden. De meeste afbeeldingen zijn gekoppeld aan de inventaris onroerend erfgoed: zoek je daar een erfgoedobject op, dan zie je er een aantal afbeeldingen, met een link om ze allemaal te bekijken.

De afbeeldingen uit de beeldbank bekijken op het geoportaal

Je kan ook gebruikmaken van ons geoportaal, waar een optionele laag Beeldbank bestaat (standaard uit, aan te vinken onder Lagen). Eens aangevinkt verschijnen er camera-icoontjes zodra je ver genoeg inzoomt; klik erop om alle afbeeldingen op die locatie te zien. Deze laag kan je ook downloaden en integreren in je eigen GIS-werking — de attributentabel bevat telkens de downloadlink voor alle beschikbare formaten.

Er zijn dus meerdere manieren om afbeeldingen terug te vinden in onze beeldbank. Denk er wel steeds aan de licentievoorwaarden te respecteren en iedereen correct te erkennen voor het geleverde werk. Vragen of suggesties zijn welkom via ict@onroerenderfgoed.be.

De dataset personen en collectieven bestaat al sinds de lancering van de eerste inventaris in mei 2009. Ze bevat personen en organisaties die belangrijk waren bij het tot stand komen van het erfgoed: architecten, aannemers, bouwmeesters, opdrachtgevers, kunstenaars, beeldhouwers, ... De dataset ontstond in 2007-2009 tijdens het toekennen van thesaurustermen aan erfgoedobjecten. Tot dan waren erfgoedobjecten vooral documenten, wat het zoeken bemoeilijkte — zeker bij veelvoorkomende namen was het lastig om bijvoorbeeld "alle gebouwen van een bepaalde architect" te vinden. (Wist je trouwens dat er een architect Baksteen bestond?) Daarom bouwden we naast de thesauri ook een authority file op met canonieke versies van betrokken ontwerpers en andere personen. Voor het agentschap is deze dataset, net als onze thesauri, geen kerndataset op zich — zonder de inventaris zouden we er geen nood aan hebben.

Over de jaren groeide de dataset uit tot een mooie staalkaart van ontwerpers, kunstenaars en architecten die een rol speelden voor ons Vlaamse erfgoed. Waar mogelijk vullen we elke persoon aan met andere gekende namen, geboorte- en sterfdata (of oprichtingsdata bij organisaties), woon- en werkplaatsen, beroepen, opleidingen en een korte biografie, en koppelen we elke persoon of elk collectief aan de erfgoedobjecten waarmee ze een band hebben als ontwerper, uitvoerder of opdrachtgever. Zo vind je via onze personendataset snel een who's who van het Vlaamse onroerend erfgoed.

De dataset gebeurtenissen bestaat eveneens sinds mei 2009, al was ze lange tijd enkel intern raadpleegbaar. Een gebeurtenis is een actie of handeling, uitgevoerd op een bepaald moment door één of meerdere personen of organisaties — in de praktijk beperkt tot handelingen op of over onroerend erfgoed. Dat kan een korte handeling zijn zoals de opmeting van een boom, een opgraving of een werfcontrole, tot een groot project zoals een inventarisatiecampagne. Steeds komt het neer op: X en Y voerden werk van het type A uit op locatie L, van datum I tot J. Soms voegen we een uitgebreide tekstuele beschrijving toe met links naar verdere bronnen, met als doel informatie te kunnen duiden en te tonen hoe ze ontstond. Zo kan je bij een erfgoedobject zien in welke inventarisatiecampagne het voor het eerst werd opgenomen, wanneer het opnieuw geïnventariseerd werd, en wanneer het adres laatst gecontroleerd werd.

De derde dataset, thema's, bestaat uit twee subtypes: één dat er al was bij de inventaris van 2009, en één dat vrij recent toegevoegd werd. Een thema omvat kaderende informatie over erfgoedobjecten, zodat bepaalde informatie niet telkens opnieuw aan individuele objecten moet toegevoegd worden. De eerste thema's, toegevoegd in 2014, vallen onder het subtype inhoudelijke thema's — vaak een combinatie van typologie, stijl of periode en locatie, zoals Militaire verdedigingswerken uit de Eerste Wereldoorlog in de frontzone, Welkomstbomen of Prehistorische grafheuvelcomplexen en urnenvelden. Bij de lancering van de nieuwe inventaris werden oudere beschrijvingen van geografische gehelen omgezet naar geografische thema's — de oude gemeente- en straatinleidingen uit de reeks Bouwen door de Eeuwen Heen, die net als de inhoudelijke thema's context bieden, maar dan puur op basis van locatie. Zo kan je meer lezen over de historische kern van Gent, de Lippenslaan te Knokke of de haven van Antwerpen. Sommige van deze themateksten behoren tot onze meest geraadpleegde pagina's, en worden ook vaak door externen gebruikt als historisch kader.

Geen van deze drie datasets vormt de essentie van de inventaris onroerend erfgoed, maar samen maken ze de inventaris interessanter en nuttiger. Wil je meer weten over de nieuwe inventaris, lees dan Tien jaar inventaris. Vragen of suggesties zijn welkom via ict@onroerenderfgoed.be.

Wat toen nieuw was, is nu oud​

De nieuwe inventaris volgt de technologische principes en architectuur die het agentschap Onroerend Erfgoed hanteert sinds 2014, na de samensmelting van het Vlaams Instituut voor het Onroerend Erfgoed (VIOE) en het agentschap Ruimte en Erfgoed. Op dat moment beschikte het agentschap over een erg divers technologisch landschap, en werd al snel beslist over te gaan tot een nieuwe technology stack.

Er bestond bij het VIOE al lang een sterke voorkeur voor open source software, een keuze die behouden bleef: qua systeembeheer bleven we werken met *nix-servers (Debian of Ubuntu), en op het vlak van databanken bleef PostgreSQL de evidente keuze — geen licentiekost, ruim voldoende volumecapaciteit, en met de PostGIS-plugin een uitstekende GIS-motor.

De grootste wijziging was de keuze van programmeertaal. Waar het VIOE in PHP ontwikkelde en Ruimte en Erfgoed met Java en .NET werkte, koos het nieuwe agentschap voor Python. Van de drie grote Python-webframeworks van dat moment (Django, Flask en Pyramid) werd uiteindelijk voor Pyramid gekozen. Daarnaast kwam er Elasticsearch bij voor performant zoeken in grote datasets, en Redis voor caches en queues bij asynchrone opdrachten.

Onze frontends gebruiken sindsdien een CSS-framework zoals Foundation, en net als veel andere webontwikkelaars zetten we de stap naar Single Page Applications (SPA's) — webtoepassingen die grotendeels op JavaScript draaien en continu via REST-services met de backend communiceren. Die zetten we intensief in voor beheersomgevingen en complexe toepassingen zoals ons geoportaal; voor publieke pagina's houden we het bewust functioneel met weinig JavaScript, zodat ze goed werken op oudere toestellen en goed indexeerbaar zijn voor zoekmachines. Onze eerste SPA's gebruikten nog Dojo, recentere toepassingen gebruiken Aurelia.

Waar de oude inventaris begon met klassieke HTML-forms en HTTP POST-requests, evolueerde ze de voorbije tien jaar steeds meer naar een systeem waarin REST-services een centrale rol spelen. In de nieuwe inventaris, zoals in al onze hedendaagse toepassingen, trokken we die kaart resoluut door: we ontwikkelden een Resource Oriented Architecture waarin we overstappen van enkele grote, monolithische toepassingen naar een netwerk van kleinere, meer gefocuste toepassingen met elk hun eigen specialisatie. De nieuwe inventaris vormt vandaag de centrale component van dat netwerk.

Ook op het vlak van uitrol en beheer evolueerden we sterk: waar we tien jaar geleden nog manueel ingrepen op enkele servers in één datacenter, werken we nu met geautomatiseerde deploys in twee datacenters, met Ansible voor het opzetten van basis servers, fabric voor het uitrollen van toepassingen, en Alembic voor het beheer van databankschema's onder versiecontrole.

Niet enkel de technologie wijzigt​

Niet alleen de technologie veranderde, ook de inhoud en focus evolueerden sterk. Toen we in 2009 de inventaris lanceerden, was het Vlaams Instituut voor het Onroerend Erfgoed net opgericht als wetenschappelijke instelling die voor het eerst al het onderzoek naar archeologie, bouwkundig erfgoed en landschappen verenigde. Verschillende inventarissen en informatiesystemen (databanken, maar ook boeken zoals Bouwen door de Eeuwen Heen) kwamen voor het eerst samen in beheer. Omdat die systemen elk hun eigen invalshoek hadden, werd de eerste versie van de Inventaris Onroerend Erfgoed opgevat als een portaal, met één look-and-feel maar elk inventaris met een eigen datamodel. Bij de lancering in mei 2009 bevatte het portaal de inventaris bouwkundig erfgoed en de inventaris wereldoorlogerfgoed, met ondersteunende modules voor afbeeldingen, gebeurtenissen en thesaurustermen.

Tussen 2009 en 2015 kwamen nieuwe modules bij: orgels, archeologische zones, historische tuinen en parken, houtige beplantingen met erfgoedwaarde, ankerplaatsen uit de landschapsatlas, en varend erfgoed. Al snel bleek dat die inventarissen, ondanks methodologische verschillen (een gebouw wordt gesloopt, een boom wordt gerooid), in essentie hetzelfde deden: beschrijven welk erfgoed zich waar bevindt, gedocumenteerd met afbeeldingen, beschrijvingen en thesaurustermen. Elke nieuwe module kreeg dan ook de vorm van een aangepaste versie van de inventaris bouwkundig erfgoed, met als voornaamste verschil de locatiecomponent: precieze adresgegevens voor kleine elementen versus grotere erfgoedgehelen voor de andere modules.

Toen het VIOE in 2012 samenging met het agentschap Ruimte en Erfgoed, kwam ook de databank van het beschermd erfgoed mee. Die bleek vooral juridische gegevens te bevatten en weinig inhoudelijke informatie, dus werd ze toegevoegd aan de inventaris als een aparte module die grotendeels hetzelfde datamodel deelde. Dit mondde uiteindelijk uit in de dataset van de aanduidingsobjecten (zie Erfgoedobjecten en aanduidingsobjecten), publiek gemaakt in juni 2016.

Naarmate de inventaris evolueerde, werd steeds duidelijker dat al die verschillende inventarissen helemaal niet zo verschillend waren, en gingen we ze meer als één geïntegreerde inventaris beschouwen — wat ook leidde tot meer communicatie en samenwerking tussen de verschillende erfgoedonderzoekers. Samen met de lancering van de aanduidingsobjecten voerden we ook de term erfgoedobjecten in: elk object uit de wetenschappelijke inventarissen kreeg een erfgoedobject met een eigen URI. In 2016 waren dit grotendeels cosmetische aanpassingen — de verschillende detailpagina's werden samengevoegd tot één pagina, maar achterliggend bleven het nog aparte datasets met een eigen datamodel. Op dat moment werd duidelijk dat de oude inventaris zo ver gebracht was als mogelijk binnen haar oorspronkelijke opzet.

Dus startten de voorbereidingen voor wat uiteindelijk de nieuwe inventaris zou worden — enerzijds omdat onze visie op de wetenschappelijke inventarissen sterk gewijzigd was, van losse silo's naar één grote inventaris van erfgoedobjecten, en anderzijds omdat de technologische componenten aan vervanging toe waren. Nu de nieuwe inventaris er is, blijven we schaven tot ze helemaal doet wat we willen binnen de huidige mogelijkheden.

Meer weten over de inventaris? Nog wat andere blogs op een rijtje:

• Algemene informatie over de nieuwe inventaris
• Erfgoedobjecten en aanduidingsobjecten: wat zijn ze en waarom bestaan ze?
• Thema's, personen en gebeurtenissen: waarvoor dienen de drie ondersteunende modules?
• Van zoeken naar vinden op de nieuwe inventaris: hoe zijn de zoekmogelijkheden opgebouwd?
• Full text zoeken in de inventaris: hoe werkt full-text zoeken, met voorbeelden bij de erfgoedobjecten?

De IT-wereld evolueert nog steeds snel. Onze corebusiness is misschien het verleden, maar we willen dat verleden op een toekomstgerichte manier beheren — met een continue, adaptieve aanpak die openstaat voor nieuwe inzichten, zowel over ons erfgoed zelf als over de technologie waarmee we het beheren en ontsluiten. Vragen hierover mag je altijd stellen.

Full-text zoeken werkt zoals een grote internetzoekmachine: je bent op zoek naar een vrij specifiek object of document, en de zoekmachine probeert het best passende resultaat bovenaan te zetten. Zoek je naar Gravensteen, dan krijg je het meest "Gravensteenige" object te zien.

Om te bepalen wat het meest relevante object is, spelen meerdere factoren mee: hoe vaker je zoekterm in een object voorkomt, hoe relevanter; hoe kleiner het veld waarin de term voorkomt, hoe relevanter; en hoe vaker de term over alle objecten heen voorkomt, hoe minder relevant. Bepaalde velden wegen ook zwaarder door dan andere — een titel telt zwaarder dan de tekst van een fiche. Zoek je naar Gravensteen, dan scoort een object met die titel hoger dan een object waarin de term slechts één keer in de tekst voorkomt.

Typ je Gravensteen in het veld Algemeen van het zoekformulier voor erfgoedobjecten, dan krijg je https://inventaris.onroerenderfgoed.be/erfgoedobjecten?tekst=gravensteen, met het Gravensteen uit Gent bovenaan. Hoofdletters maken daarbij geen verschil.

Wil je iets weten over het Gravensteen in Aalst specifiek? Zoek je naar Gravensteen Aalst, dan krijg je maar 2 resultaten: objecten waarin zowel Gravensteen als Aalst voorkomen. Standaard wordt elk woord dus als aparte term gezien, gecombineerd met AND (EN) — voorgesteld met een +, dus Gravensteen Aalst is gelijk aan Gravensteen+Aalst. Zoek je liever naar het één óf het ander, gebruik dan de OR (OF)-operator, het pipe-teken |: Gravensteen|Aalst. De derde operator is NOT (NIET), een --teken: Gravensteen -Aalst geeft je alles met Gravensteen, maar niet Aalst.

Standaard splitst de zoekmachine je zoekterm op spaties. Zoek je naar Grote Markt Aalst, dan krijg je best wat resultaten, waaronder helemaal achteraan Paviljoen De Notelaer — de woorden grote, markt en aalst komen er wel in voor, maar niet naast elkaar. Wil je expliciet naar de exacte frase zoeken, gebruik dan aanhalingstekens: "Grote Markt" Aalst zoekt naar twee termen in plaats van drie, en levert minder (en relevantere) resultaten op.

Voor complexere combinaties kan je haakjes gebruiken om de volgorde van operatoren te sturen. Zoek je naar vismarkt brugge gent, dan zoek je naar objecten waarin alle drie de termen voorkomen — niet wat je bedoelde. vismarkt + brugge | gent levert dan weer te veel resultaten op, want operatoren hebben een vaste voorrang. De oplossing: groepeer met haakjes, vismarkt + (brugge|gent), om fiches te vinden over de vismarkt met daarbij Brugge óf Gent.

Je kan ook op een deel van een woord zoeken met een postfix-wildcard: gedenk* vindt onder meer gedenksteen, gedenkplaat en gelijkaardige woorden. Dit werkt enkel op het einde van een term — *linde levert dus niets op voor herdenkingslinde. Alles combineren kan ook: visgraat* (oost-vlaanderen|west-vlaanderen) -brugge zoekt naar objecten met een woord dat begint met visgraat, in Oost- of West-Vlaanderen, maar niet in Brugge.

Welke velden worden nu precies full-text doorzocht, en in welke volgorde van belang? De tekst, de titel van de tekst, de korte beschrijving (die je in een zoekresultaat ziet), provincie, gemeente, deelgemeente en straatnamen, thesaurustermen en de naam van het object zelf. We tonen alle objecten waarin je term voorkomt, tenzij er meer dan 10.000 zijn (het maximum aantal zoekresultaten).

Kort samengevat, deze operatoren kan je gebruiken:

• Meerdere termen worden impliciet gecombineerd met AND; expliciet kan met +
• OR-combinatie via |
• Een term uitsluiten met NOT via -
• Meerdere woorden tot één term maken met aanhalingstekens "
• Volgorde van operatoren aanpassen met haakjes ()
• Zoeken op een prefix met een postfix-wildcard *

Veel zoekplezier! Vragen over zoeken mag je altijd aan ons stellen.

De erfgoedobjecten zijn het kloppend hart van de inventaris: de dingen die wij en jullie als erfgoed beschouwen, van de Onze-Lieve-Vrouwekathedraal en het Gravensteen tot het Zwin, een kapel, een boom, een schip of een orgel. De focus ligt niet op de juridische gevolgen, maar op de wetenschappelijke informatie: wat is het, hoe groot, waar, hoe oud, hoe ziet het eruit, wie was betrokken, waar vind je meer info? De afbakening van zo'n erfgoedobject is in de praktijk vaak wat vaag — bij het Gravensteen zal de ene enkel de burcht zien, een andere ook de gracht, en nog een derde het Sint-Veerleplein erbij rekenen. We kiezen telkens één afbakening, zonder die als heel exact te beschouwen.

De aanduidingsobjecten zijn daarentegen het erfgoed zoals het juridisch verankerd is: de bescherming of vaststelling van een erfgoedobject. Waar de grens van een erfgoedobject wat vaag mag zijn, moet die van een aanduidingsobject onbetwistbaar zijn, want ze bepaalt welke rechtsgevolgen gelden op een stuk Vlaanderen. Sinds het nieuwe Onroerenderfgoeddecreet bakenen we ook vastgesteld erfgoed af met een polygoon in plaats van punten. Bij een aanduidingsobject draait het om: hoe groot precies, welk type aanduiding, waarom heeft dit erfgoedwaarde, en welk besluit of document onderbouwt die beslissing? Eén erfgoedobject kan trouwens meerdere keren verankerd zijn onder verschillende statuten.

De Onze-Lieve-Vrouwekathedraal, een erfgoedobject en zijn aanduidingen

Bekijk je bijvoorbeeld de Onze-Lieve-Vrouwekathedraal, dan zie je vier aanduidingen: een vaststelling als bouwkundig erfgoed, een aanduiding als Unesco-werelderfgoed, een bescherming als monument, en een bijkomende bescherming van een stukje muur als monument. Het erfgoedobject "de kathedraal" vertelt je wat het is; de aanduidingsobjecten vertellen je in detail wat er met de verschillende onderdelen ervan kan.

Kon het niet eenvoudiger?​

Dit onderscheid lijkt op het eerste gezicht complex en arbitrair. Het ontstond bij het project van de beschermingsdatabank, kort na de samensmelting van het agentschap Ruimte en Erfgoed en het Vlaams Instituut voor het Onroerend Erfgoed. Het eerste beheerde de beschermingsdatabank, het tweede de inventarisdatabank, die toen bestond uit een aantal aparte inventarissen (bouwkundig erfgoed, tuinen en parken, houtige beplantingen, ...), elk met een eigen fiche per element.

Omdat de beschermingsdatabank op dat moment veel minder mogelijkheden bood dan de inventarisdatabank, werd al het beschermde erfgoed toegevoegd aan de inventarisdatabank, meteen voorzien van afbeeldingen, thesaurustermen en uitgebreide beschrijvingen. In dat eerste datamodel werd beschermd erfgoed identiek beschreven als geïnventariseerd erfgoed: een fiche voor een kerk in de inventaris bouwkundig erfgoed, een aparte fiche voor diezelfde kerk als beschermd monument, en mogelijk nog een fiche als onderdeel van een dorpsgezicht. Die fiches herhaalden grotendeels dezelfde inhoud, met soms lichte verschillen door een afwijkende afbakening — een nachtmerrie om te onderhouden zodra er nieuwe inzichten over een gebouw aan het licht kwamen.

Een gelijkaardig probleem speelde tussen de verschillende inventarissen zelf. Toen ze nog op papier verschenen (zoals de reeksen M&L Cahiers en Bouwen door de Eeuwen Heen), was overlap tussen bijvoorbeeld een historische tuin en het bijhorende bouwkundig erfgoed nog behapbaar; online bleek dat minder evident, met soms tegensprekelijke fiches.

Uiteindelijk gooiden we het roer om door twee zaken strikt te scheiden. Enerzijds de inhoudelijke informatie, die we op zo weinig mogelijk plaatsen tegelijk willen bijhouden: elk erfgoedobject krijgt nu één of meerdere disciplines (archeologisch, bouwkundig, landschappelijk, varend), en we brengen zo veel mogelijk informatie samen in één fiche, ongeacht welk deel ervan beschermd is. Anderzijds de juridische informatie, die we los willen kunnen behandelen — een bescherming kan bijvoorbeeld ophouden te bestaan zonder dat het erfgoed zelf verdwijnt. Zo herwerkten we de beschermingsdatabank tot een databank van aanduidingsobjecten, een term die we ontleenden aan Historic England, waar men spreekt van designation voor het formeel toekennen van rechtsgevolgen aan erfgoed.

Alles is verbonden​

Ons erfgoed is groot en verscheiden, en elke fiche zet maar een klein stukje van de werkelijkheid in de schijnwerper — stukjes die met elkaar verbonden zijn. Daarom leggen we al een tiental jaar relaties tussen objecten. Waar erfgoed vroeger vooral puntsgewijs beheerd werd, is er al jaren een beweging naar grotere gehelen en contexten die even belangrijk zijn als de kleine elementen. Vroegere bouwkundige gehelen, archeologische zones en ankerplaatsen zijn intussen allemaal erfgoedobjecten geworden, met een consequent onderscheid tussen gehelen (grote oppervlaktes) en elementen (kleinschalige stukjes erfgoed). Sinds 2009 koppelen we erfgoedobjecten met drie relaties:

• is gerelateerd aan: een verband tussen twee objecten, zonder dat het ene het andere omvat — bijvoorbeeld een kolenmijn en een mijnwerkerscité.
• omvat: het ene erfgoedobject omvat het andere, zoals een kasteeldomein dat het koetshuis omvat, of een kerk die een apart beschreven orgel bevat.
• is deel van: het omgekeerde van omvat — het orgel is deel van de kerk, het koetshuis deel van het domein.

Voor de interactie tussen erfgoed- en aanduidingsobjecten onderscheiden we drie relaties:

• is aangeduid als: het erfgoedobject en het aanduidingsobject zijn (quasi) identiek qua afbakening — het erfgoedobject is dus (ongeveer) volledig beschermd of vastgesteld.
• omvat de aanduiding als: het erfgoedobject is groter dan het aanduidingsobject, bijvoorbeeld een kerk waarvan enkel de toren beschermd is.
• is deel van de aanduiding als: het erfgoedobject is kleiner dan het aanduidingsobject, bijvoorbeeld een individuele boom in een beschermd landschap.

Help, ik zoek iets!​

Wanneer gebruik je nu welke dataset? Je kan zoeken naar erfgoedobjecten of zoeken naar aanduidingsobjecten, en beide formulieren bieden filters die met rechtsgevolgen te maken hebben. Bij de erfgoedobjecten zoek je primair op inhoudelijke kenmerken — de eenheid van informatie is erfgoed. Bij de aanduidingsobjecten zoek je op kenmerken van de aanduiding zelf — de eenheid van informatie is een juridische beslissing over erfgoed.

Zoek je bijvoorbeeld naar beschermde bibliotheken, dan geeft typologie=bibliotheken + rechtsgevolgen=beschermd bij de erfgoedobjecten 17 resultaten, terwijl typologie=bibliotheken + categorie=beschermingen + geldig=true bij de aanduidingsobjecten 22 resultaten oplevert — niet helemaal hetzelfde. In het eerste geval gaat het om 17 erfgoedobjecten die (deels) een bibliotheek zijn en waarop een bescherming rust; in het tweede om 22 beschermde objecten die iets met een bibliotheek te maken hebben. Zo is het Kasteeldomein van Loppem tweemaal beschermd: als landschap in zijn geheel, en het landhuis met bijgebouwen apart als monument.

Door onze informatie op te delen in erfgoedobjecten en aanduidingsobjecten kunnen we flexibel omgaan met inhoudelijke informatie en aanvullingen doen, zonder te raken aan de wettelijk verankerde gegevens. Heb je zelf nog suggesties om onze informatie begrijpelijker te maken, neem dan contact met ons op.

De inventaris bevat momenteel vijf grote datasets: erfgoedobjecten, aanduidingsobjecten, personen, thema's en gebeurtenissen. Veel zoekmogelijkheden en principes worden gedeeld tussen die datasets — zoeken naar erfgoedobjecten of aanduidingsobjecten in een bepaalde gemeente verloopt bijvoorbeeld identiek, net als zoeken met thesaurustermen.

User interface vs. REST-service​

Bij zoeken maken we een onderscheid tussen de zoekservice zelf en de UI (user interface) die er gebruik van maakt. Zoeken is complexe materie: meerdere parameters, booleaanse combinaties (dit EN dat, dit OF dat, NIET dit), zoeken op id of op tekst, wildcards, ... en dat moet allemaal simpel en eenduidig blijven. In de praktijk bestaat de perfecte zoek-UI niet — die hangt altijd af van de gebruiker, en dat is moeilijk te voorspellen. Daarom bieden onze zoekservices vaak méér mogelijkheden dan wat de standaard-UI ontsluit: die laatste bouwen we voor de doorsnee gebruiker, de service zelf richt zich op ontwikkelaars en ervaren gebruikers.

Onder de UI verstaan we de zoekformulieren zelf, zoals https://inventaris.onroerenderfgoed.be/erfgoedobjecten/zoeken, waar je op een begeleide manier zoekparameters kan ingeven (met bijvoorbeeld suggestielijstjes voor gemeente- en straatnamen). Nadeel: een UI is duur om te ontwikkelen, en complexe zoekopdrachten passen er niet altijd goed in.

Via de user interface kan je vlot eenvoudige zoekopdrachten ingeven

De service zelf is een door machines bevraagbare REST-dienst die JSON gebruikt om informatie door te sturen. Een zoekresultaat in de nieuwe inventaris kan je zowel als HTML doorbladeren als downloaden als JSON of CSV — door dezelfde URL simpelweg met een andere Accept-header op te vragen, bijvoorbeeld application/json. Dat kan met een command-line tool zoals curl, met een REST-client, of met je favoriete programmeertaal:

$ curl -X GET -H "Accept: application/json" https://inventaris.onroerenderfgoed.be/erfgoedobjecten?gemeente=278

Full-text zoeken vs. filteren​

De zoekformulieren ondersteunen zowel full-text zoeken (kortweg "zoeken") als filteren. Dat klinkt gelijkaardig, maar dient een heel ander doel — al zorgen beide ervoor dat je niet-relevante gegevens niet hoeft te zien.

Filteren is een zwart/wit-verhaal: een object voldoet aan een criterium of niet. Je wil bijvoorbeeld al het erfgoed in een gemeente of straat, of alle kerken, of alle kerken in een bepaalde gemeente — vaak ben je niet op zoek naar één specifiek object, soms wil je enkel weten hoeveel er zijn.

Full-text zoeken is een grijs verhaal: de zoekmachine probeert het meest relevante resultaat te geven. Zoek je naar Gravensteen of Sint-Veerle, dan ben je meestal op zoek naar een klein aantal objecten, en wil je vooral het meest relevante bovenaan — net zoals grote internetzoekmachines zoals Google dat doen.

Je kan beide uiteraard combineren. Full-text zoeken naar het Gravensteen geeft tien objecten, met het Gravensteen in Gent bovenaan — het laatste object is de archeologische zone van Aalst, omdat ook daar "gravensteen" in de beschrijving voorkomt. Filter je bijkomend op de gemeente Gent, dan blijven er nog zeven resultaten over, met het Gravensteen nog steeds bovenaan.

Zolang je een full-text zoekactie uitvoert via het veld Algemeen, sorteert de toepassing standaard op relevantie; zonder full-text zoeken wordt op locatie gesorteerd. Bij full-text zoeken kan je de sorteervolgorde nog wijzigen, al is dat zelden aangewezen.

In een volgend bericht leggen we uit hoe je gerichter full-text kan zoeken (Full text zoeken in de inventaris), en hoe we precies bepalen wat de meest relevante fiche is voor een bepaalde vraag.

Vroeger vroeg het opzetten van een demo-omgeving wat manueel werk. We bieden nu een Docker-image aan dat zowel een demo-toepassing als de bijhorende Linked Data Fragments-server bundelt, zodat je in enkele minuten een werkende instantie hebt.

Na het installeren van Docker (de CE-editie volstaat ruimschoots) haal en start je de image:

$ sudo docker pull atramhasis/demo
$ sudo docker run -p 6543:6543 -p 3000:3000 atramhasis/demo

De demo-toepassing is dan beschikbaar op http://localhost:6543, en de meegeleverde Linked Data Fragments-server op http://localhost:3000.

Je kan ook een specifieke versie kiezen (vanaf Atramhasis 0.6.4):

$ sudo docker pull atramhasis/demo:0.6.4
$ sudo docker run -p 6543:6543 -p 3000:3000 atramhasis/demo:0.6.4

Houd er rekening mee dat dit vooral bedoeld is om snel kennis te maken met de toepassing: wijzigingen die je aanbrengt gaan verloren zodra je de container stopt. Heb je nood aan persistentie, maar wil je toch met Docker werken, dan kan je de Dockerfile aanpassen naar je eigen noden.

Static map generator​

Om dit soort kaarten te genereren gebruik je de statische kaartgenerator, een module ontwikkeld voor het agentschap Onroerend Erfgoed in samenwerking met externe partners. Het doel: statische kaarten samenstellen uit verschillende geografische formaten (zoals GeoJSON), een achtergrondlaag (zoals WMS) en lay-out-overlays zoals tekst en schaal. Op basis van een configuratiebestand voegt de generator alle lagen samen tot één afbeelding met schaalbalk, terug te geven als foto of in base64-formaat.

De generator is zowel als Python-module als als REST-service te gebruiken, en dus makkelijk in je eigen project in te bouwen — als bibliotheek als je met Python werkt, of als losse toepassing op een server als je dat niet doet.

De erfgoedatlas van een gemeente​

De inventaris is een prima werkinstrument om ons erfgoed te leren kennen, maar soms is een lokale kopie handig — bijvoorbeeld om de baan op te gaan zonder internetverbinding. Door een paar van onze diensten te combineren, maak je zo je eigen erfgoedatlas.

Als voorbeeld gebruiken we de gemeente Edegem. Eerst worden alle erfgoedobjecten en aanduidingsobjecten binnen de gemeente opgevraagd via de geozoekdiensten. Dan stel je een basisconfiguratie op voor de afbeelding: achtergrondlaag, tekst, breedte en hoogte. De geometrie van elk object wordt als aparte laag toegevoegd, en tot slot geef je de configuratie mee aan de statische kaartgenerator, die de afbeelding teruggeeft. De afbakening van Edegem zelf komt uit een GeoJSON-bestand op basis van gegevens van Informatie Vlaanderen. Het volledige scriptje staat op Github.

Zo bekom je een kaart van al het erfgoed dat we kennen in Edegem:

Inzoomen op de objecten op kaart​

Je kan ook per erfgoedobject afzonderlijk een kaartje genereren, met bijvoorbeeld een andere achtergrondlaag en de naam van het object er telkens bij. Zo bekom je een kaartje per object uit de inventaris, klaar om af te drukken of verder te verwerken. Ook hier geldt: zowel onze gegevens als die van Informatie Vlaanderen zijn open data, dus vrij te gebruiken.

Fort 5

Hazeschranshoeven

Kasteel Hof ter Linden

Garden City Elsdonk

Wil je zelf aan de slag met de kaartgenerator? Kijk dan naar de statische kaartgenerator op Github, of bekijk de levende API-documentatie op https://geo.onroerenderfgoed.be/zoekdiensten/api_doc.

Onze collega's bij Historic England omschrijven een thesaurus als een gestructureerde woordenlijst die gebruikt wordt om terminologie te standaardiseren, en die helpt bij het indexeren en terugvinden van informatie in databanken die dezelfde terminologie gebruiken. Het structureren van verwante termen op deze manier biedt een aantal voordelen.

Ten eerste kan je zo equivalenties uitdrukken. In plaats van te zeggen dat twee termen "synoniemen" zijn, zeggen we dat beide een verbale uitdrukking zijn van hetzelfde onderliggende concept — dus in plaats van te stellen dat Jugendstil gelijk is aan Art Nouveau, zeggen we dat er één concept bestaat voor die artistieke stijl, met beide termen als label. Een subtiel verschil, maar het verandert hoe je met de thesaurus omgaat.

Ten tweede zijn er hiërarchische relaties: de ene term is breder dan de andere, die op zijn beurt smaller is. Een kathedraal is een kerk, een kerk is een religieus gebouw, dus een kathedraal is ook een religieus gebouw. Niet alle hiërarchische relaties zijn strikt "is een" — ook "is deel van" en "is een instantie van" komen voor, en die maken het er niet eenvoudiger op. Zie On the composition of ISO 25964 hierarchical relations (BTG, BTP, BTI) voor hoe deze op elkaar inwerken.

Ten derde is er de associatieve relatie — de "zachtste" van de drie, die enkel aangeeft dat twee termen of concepten verwant zijn. Steenkoolmijn is verwant met mijnwerkershuizen, omdat in Vlaanderen elke steenkoolmijn zijn eigen kleine woonwijk had waar de mijnwerkers samen leefden.

Thesauri laten je ook toe om een scope note toe te voegen: een geschreven definitie van een concept en hoe het gebruikt moet worden. Dit blijkt in de praktijk erg belangrijk — experts vragen om concepten te definiëren die ze als vanzelfsprekend beschouwden, heeft al meer dan eens tot verhitte discussies geleid. Zonder definitie gebruikt iedereen een concept zoals het hen uitkomt, zonder rekening te houden met andersdenkenden.

Thesauri helpen ons dus om tot een consensus te komen over wat concepten betekenen, en die kennis te delen met de buitenwereld (vandaar dat we ze als open data publiceren). Maar er is ook een heel praktische reden om ze te bouwen en te onderhouden: indexering. Wanneer iemand zoekt naar fonteinen in ons inventarissysteem, wordt de thesaurus geraadpleegd. Is fontein geen gekende term, dan wordt er niets onder geïndexeerd en stopt de zoekopdracht daar. Is het dat wel, dan controleert het systeem ook op smallere termen — in dit geval is bedriegertje een gedefinieerde smallere term voor een type fontein — waardoor een zoekopdracht naar fonteinen zowel records met fontein als met bedriegertje teruggeeft.

Die bedriegertjes tonen meteen nog een handige functie. Bekijk het record voor bedriegertjes en je ziet dat we er zelf nooit een Engels label voor gemaakt hebben. Gelukkig hebben we ons concept van bedriegertje gekoppeld aan hetzelfde concept in de Art & Architecture Thesaurus, die ons vertelt dat de Engelse termen water tricks of joke fountains zijn — en zelfs de Duitse en Spaanse equivalenten geeft. Dat opent heel wat mogelijkheden om met andere systemen te interageren.

Uiteindelijk zijn thesauri een middel, geen doel op zich — onze kerntaak is het beheren van erfgoed, niet het bouwen van thesauri. Maar ze helpen ons enorm om te bepalen wat dat erfgoed precies is, erdoorheen te zoeken en het te linken van ons lokale niveau naar het transnationale niveau. Wil je meer weten over hoe we onze thesauri gebouwd hebben, inclusief een aantal do's en don'ts: de oorspronkelijke post verwees hiervoor naar een bibliografische referentie (Mortier e.a., 2017) die we hier niet exact konden overnemen.

Een voorbeeld zegt meer dan duizend woorden. Stel dat we al het erfgoed willen kennen binnen honderd meter van een punt in Vlaanderen:

$ curl -X GET --header 'Accept: application/json' 'https://geo.onroerenderfgoed.be/zoekdiensten/afbakeningen?categorie=aanduidingsobjecten&geometrie=%7B%22type%22%3A%20%22Point%22%2C%20%22coordinates%22%3A%20%5B4.7676665601685%2C50.985228897907%5D%7D&buffer=100'

Dat geeft een lijst resultaten terug, elk een JSON-object met de attributen id, uri, categorie, type, naam en geometrie. Het attribuut naam is een korte omschrijving. De id identificeert het object uniek binnen de dataset waar het uit komt; de uri is gegarandeerd uniek over alle datasets heen — een globale identificator die eigenlijk gewoon een link is naar meer informatie. Vraag je bijvoorbeeld https://inventaris.onroerenderfgoed.be/erfgoedobjecten/134454 op via de browser, dan land je op een pagina over het object in de Inventaris Onroerend Erfgoed. Wil je liever de ruwe data in JSON, stuur dan een Accept: application/json header mee:

$ curl -L -X GET --header 'Accept: application/json' 'https://id.erfgoed.net/erfgoedobjecten/134454'

In dit voorbeeld vinden we een erfgoedobject uit de wetenschappelijke inventaris van tuinen en parken — af te leiden uit het attribuut type, een object met een uri en een label. Die uri verwijst naar een term in een thesaurus van inventaristypes of aanduidingstypes; volg de uri voor meer info, bijvoorbeeld dat deze inventaris intern soms ook ile_park genoemd wordt.

De geometrie zelf komt als GeoJSON mee, en omdat die nogal groot kan zijn en niet altijd relevant is, kan je de service vragen die weg te laten:

$ curl -X GET https://geo.onroerenderfgoed.be/zoekdiensten/afbakeningen?&buffer=100&geef_geometrie=0

Standaard doorzoekt de service alle soorten objecten, maar je kan filteren met de parameter categorie:

• Erfgoedobjecten: de inhoudelijke objecten die met erfgoed te maken hebben — de wetenschappelijke inventarissen.
• Aanduidingsobjecten: de juridische verankeringen van erfgoedobjecten, zowel beschermd als vastgesteld (af te leiden uit de URI van het type), inclusief erfgoedlandschappen, Unesco kernzones en Unesco bufferzones.
• Plannen: momenteel enkel beheersplannen, later uit te breiden met erfgoedrichtplannen.

Wil je bijvoorbeeld enkel de aangeduide objecten zien:

$ curl -X GET https://geo.onroerenderfgoed.be/zoekdiensten/afbakeningen?&buffer=100&geef_geometrie=0&categorie=aanduidingsobjecten

Voor simpele vragen zoals "geef me al het erfgoed rond een punt" volstaat bovenstaande. Je bent daarbij niet beperkt tot punten — (multi-)polygonen en lijnen kunnen ook, al wordt het dan snel onhandig om de volledige GeoJSON-geometrie in de URL te stoppen. Daarom ondersteunt de service ook een POST-request, waarbij je de vraag in de body van het verzoek meegeeft.

De service is vrij toegankelijk en hergebruik wordt aangemoedigd. Om snel te zien wat ze kan, raden we onze levende API-documentatie aan op https://geo.onroerenderfgoed.be/zoekdiensten/api_doc.

We hopen dat deze vrij eenvoudige webservice voor jullie even nuttig is als voor ons. Opmerkingen, vragen of extra noden mag je altijd sturen naar ict@onroerenderfgoed.be.

Als mens heb je daarvoor verschillende opties. Je kan naar ons Geoportaal surfen en inzoomen op de plaats die je interesseert om met een paar muisklikken te zien welk erfgoed daar te vinden is. Geen zin om op een kaart te kijken? Dan kan je via onze Inventaris met een zoekformulier zoeken naar al het erfgoed in een bepaalde straat of gemeente — minder exact misschien, maar je duikt sneller in de geschiedenis en architectuur van je buurt.

Alle geografische informatie over onroerend erfgoed vind je op https://geo.onroerenderfgoed.be

Voor wie liever zelf aan de slag gaat: onze erfgoedinventarissen en de beschermde en vastgestelde aanduidingsobjecten kan je downloaden als GIS-bestanden, telkens met een URL naar meer informatie per geometrie. Handig zonder netwerkverbinding, maar wel elke nacht opnieuw gegenereerd — na een dag zijn je bestanden dus alweer verouderd. Wil je steeds de actuele versie, dan kan je in plaats daarvan onze OGC-webservices raadplegen via onze Geoserver: die geven je, in tegenstelling tot de downloads, altijd de meest recente stand van zaken.

Wie voldoende technisch onderlegd is en onze data rechtstreeks in eigen systemen wil gebruiken, kan tot slot ook terecht bij onze Geozoekdiensten. Deze bestaan vandaag uit één enkele webservice, gebouwd om exact één vraag te beantwoorden: wat ligt er in een bepaald gebied? Je stuurt een geometrie naar de service, en die geeft je terug welk erfgoed er geheel of gedeeltelijk in die geometrie ligt — als een eenvoudige JSON-structuur met voor elk object een id, een uri, een type en de volledige geometrie. We gebruiken deze zoekdienst zelf al een tijdje intern, en delen ze nu graag met jullie.

In een volgend bericht (Geozoekdiensten. Wat ligt er hier?) leggen we exact uit hoe je deze zoekdienst kan gebruiken.