Hoe wordt omgegaan met uri-persistence en historie?

Toepassingen LocatieServer
#1

Ik ben benieuwd wat het beleid is van het gebruik van persistent uri’s en historie in locatieserver.

Is er een beleid om uri’s persistent te houden na data updates? Zo niet, is het een optie om vanuit ieder zoekresultaat te verwijzen naar een persistent uri van het betreffende object? Als een object uit de bag komt, een verwijzing naar het object in de bag op te nemen.

Achtergrond voor de vraag is dat we voor nationaal georegister een locatie server zoeken waarmee gebruikers op eenvoudige wijze een locatie kunnen koppelen die de locatie van een beschreven dataset representeert. De uri van dit object wordt vervolgens opgeslagen in de metadata. Daartoe moet er echter wel een uri-persistence strategie beschikbaar zijn. Alternatief zijn de locaties van http://standaarden.overheid.nl/owms/4.0/doc/waardelijsten, echter het nadeel is dat deze data slechts beschikbaar zijn tot op deelgemeente niveau en geen geometrie kennen.

Een voorwaarde voor persistence is dat er historie bijgehouden wordt na data updates? Wat is het beleid hieromtrent? ik kan me voorstellen dat het voor doelgroepen interessant is om ook historische objecten in de locatie server te vinden.

#2

Beste Paul, in ieder geval de ID’s zijn persistent. Hierdoor blijf je altijd informatie over hetzelfde object terugkrijgen als je het object o.b.v. ID zoekt, bijv. met de lookup service: …/lookup?id={id}. Dus je zou de URL die je gebruikt ook als een persistente URI kunnen zien. Verder hebben we nog niet over een URI-persistence strategie nagedacht.

Waar van toepassing bevat een object ook de nodige verwijzingen naar de BAG of andere relevante bronnen. Dit zijn de attributen provinciecode (CBS), gemeentecode (CBS), woonplaatscode (BAG), openbareruimteid (BAG), adresseerbaarobjectid (BAG) en nummeraanduidingid (BAG).

Historie wordt momenteel nog niet ondersteund. Dit staat wel op de backlog, maar het is niet bekend wanneer dit gerealiseerd wordt. Om ID’s persistent te houden, is dit nog geen vereiste, maar natuurlijk wel voor persistente URI’s.

#3

Voor gemeenten is er Gemeentegeschiedenis op basis van het Repertorium van Nederlandse gemeenten vanaf 1812. Samen met het IISG wordt dit onderhouden.

#4

De ID’s van de objecten in de locatieserver zijn uniek en gebruiken de authentiek sleutels. Het is een goede suggestie om een attribuut op te nemen met een uri die naar de bron verwijst. Dit zou de linked data store in het geval van de BAG kunnen zijn. Deze heeft echter nog niet deze status. In ieder geval goed punt om in de volgende release van de locatieserver mee te nemen als functionele wens.

#5

Beetje late reactie, maar ik krijg dit topic net onder ogen.

Ik ben mij al een tijd aan het specialiseren in historie in gegevens, ben ook bezig met de ontwikkeling van een product “EntityGrid” dat dit complexe probleem eenvoudig maakt (zowel voor gegevensbeheer als voor access / publicatie).

Ik probeer de concepten rond gegevenshistorie en de oplossing al een tijdje bij het Kadaster voor het voetlicht te krijgen maar dat valt nog niet mee…

Ik ben bezig om de BAG als showcase in EntityGrid te krijgen, inclusief mutaties en ook inclusief gemeentehistorie wat moet om een consistente gegevensset te krijgen. Dat is veel werk, en ook de gemeentehistorie incl. indeling van woonplaatsen is (zo is mij gebleken na uitvoerig onderzoek) niet integraal als dataset beschikbaar.

De gemeentes worden bij de BAG geleverd als zgn. “Tabel 33”, een pdf met gemeentenamen en data van ontstaan / opheffing: http://publicaties.rvig.nl/dsresource?objectid=4789&type=org
Het CBS levert tabellen met geldige gemeentes per jaar, voor 2015 Gemeenten numeriek op gemeentecode 2015
Ook de gemeentegeschiedenis website is mij bekend.
Ik heb een studente de verschillende gemeentegegevens laten integreren in een enkel Excel bestand en dat viel nog niet mee, ook omdat de diverse bronnen elkaar qua data van ontstaan / opheffing nog wel eens tegenspreken.

Stap 2 (nog meer werk) is het opstellen van de historie van de gemeentelijke indeling van woonplaatsen…

Gelukkig worden ID’s / URI’s constant gehouden bij het verversen van datasets, anders waren we helemaal lost in (data) space…

Overigens ben ik helemaal niet happy met het periodiek verversen van datasets: waarom geen real / near time updates? Kan allemaal eenvoudig met EntityGrid…

Als ik op enigerlei wijze nog iets kan bijdragen aan het goed en makkelijk beheren en publiceren van data MET historie (en eventueel taal) dan hoor ik dat graag!

Rob van Dort
rob.van.dort@gmail.com

#6

De Locatieserver van PDOK verwerkt dagelijks de BAG in de Locatieserver maar is geen bronhouder of eigenaar van de data. Wij ontvangen deze dus net als andere partijen via het reguliere leveringskanaal van de BAG. De Locatieserver gaat momenteel nog niet uit van historie. Wellicht dat dit in de toekomst nog eens naar gekeken gaat worden maar daar kunnen we voorlopig nog niet iets over roepen. Mocht dit het geval zijn dan kijken wij graag naar mogelijke oplossingen, we zullen die van u dan ook meenemen!

#7

Ha Jeroen, het lijkt mij onlogisch dat een doorgeefluik als locatieserver zelf historie opbouwt. De BAG registratie zal zelf die historie bevatten en (indien aangevraagd) mee uit kunnen leveren met een data leverantie (zie http://inspire.ec.europa.eu/file/1533/download?token=ouzQkBuP).

Ten behoeve van uri-persistentie zou locatieserver zelf geen historie hoeven bevatten, mits zij bag uri’s gebruikt bij het identificeren van objecten (waarbij de uri-persistentie dan op BAG niveau ingeregeld wordt)

Uit het verhaal van Rob begrijp ik dat de BAG daar mogelijk nog wel wat uitdagingen heeft, maar dan is het geen locatieserver issue meer.

Rob heb je een url met meer informatie over dat entitygrid product?

#8

Hoi Paul. Ik bedoelde niet het zelf opbouwen van historie maar het ontsluiten van reeds aanwezig BAG historie :slight_smile: Dit zit er nu niet in en wellicht dat dit nog eens besproken gaat worden.

#9

Een interessante uitdaging wordt het wel wanneer we besluiten om datasets te ontsluiten die van zichzelf geen historie bevatten. Zouden we voor Locatieserver standaard voor iedere dataset historie moeten opbouwen, of is dat overkill? Wat als de dataset wordt gecombineerd met andere datasets die wel historie bevatten?

Een concreet voorbeeld: we zijn van plan om de BAG openbare ruimtes (met historie) te combineren met NWB (geen historie). Wil je, als historische openbare ruimtes ontsloten worden, dan ook de bijbehorende historische weggeometrie?

Ook is het zo dat datasets die historie bevatten je persistente ID’s hebt, waardoor URI-persistentie wordt “gegarandeerd” (in theorie i.i.g.). Maar bij datasets die geen historie bevatten, heb je misschien ook niet de garantie dat de ID’s persistent zijn, zeker niet als de dataset geen unieke ID’s heeft.

#10

@fsteggink goed punt, maakt het alleen nog maar lastiger. Voor nu staat dit in ieder geval niet op de planning maar goede input mocht dit ooit ter sprake komen!

#11

Sorry voor de late reactie mannen, het forum was even aan mijn aandacht ontsnapt.

Wat betreft mijn idee van historie in datasets: een dataset is een zich ontwikkelend iets. Je begint met de toestand (waarde) van een zeker moment en door voortdurende mutaties “evolueert” deze toestand.
Bij datasets van waarde (en daar spreken we hier over) wil je in elk geval op beheersniveau alle mutaties tot op detailniveau bijhouden (full detail audit trail). Dus niet alleen wie op welk moment “iets” aan een zeker object gewijzigd heeft. maar ook “wat” er gewijzigd is, tot op attribuutniveau. Een cluster van zulke wijzigingen kan samen een logische transactie vormen, met verwijzing naar een brondocument.
Dit is op een bepaalde manier ingeregeld in bijv. de BAG. Probleem daarbij is dat de BAG de “huidige toestand” van een object bevat en “vorige toestanden”. Het begrip “huidige toestand” refereert aan iets buiten de dataset, nl. “de” datum (timestamp) van de dataset op het moment van dumpen. Gezien de continue stroom van mutaties en de duur van het proces van dumpen, transformeren, publiceren is dit tijdstip al snel verlopen. Door het dagelijks verversen van de dump creëer je weliswaar een pseudo-continuüm maar het is natuurlijk een dagelijks gesleep met grote datasets waar per dag maar een relatief klein deel daadwerkelijk wordt gemuteerd. Dit wil eigenlijk niemand…
Met EntityGrid wordt het mogelijk om “seamless data management” te realiseren: voer alleen de mutaties door en door de standaard bi-temporele features wordt het mogelijk om op zeer eenvoudige wijze de toestand van elk geregistreerd object op elk moment in de tijd op te vragen. En, want bi-temporal, op geavanceerde wijze, met goed inzicht in eventuele terugwerkende kracht mutaties (ook forward trouwens).

Wat betreft URI’s: een object moet een permanente URI hebben anders creëer je een niet te overziene ellende. Wat betreft wijzigingen en object-versies: daarvoor is van alles te verzinnen, heb ik ook wel ideeën over, bespreek ik graag maar voert hier nu even te ver.

Wat betreft EntityGrid: het is een product in ontwikkeling, ik ben nog in stealth modus maar bespreek het graag in kleinere contexts.

rob.van.dort -at- gmail.com