Aanpak Basisregistraties

Doelstelling[bewerken]

Het project 'semantische aanpak van basisregistraties' richt zich op het ontwikkelen van een vocabulaire waarmee begrippen (inclusief hun samenhang en de link naar hun definitie in de wet), gebeurtenissen en gegevenselementen in een basisregistratie kunnen worden beschreven en een “recept” voor toepassing van dit vocabulaire op een concrete registratie. Daarbij wordt de Basisregistratie Adressen en Gebouwen (BAG) gebruikt als showcase voor een 'end-to-end' publicatie van een basisregistratie als linked data, dat wil zeggen van dagelijse bijwerking tot en met (Json/LD) api's voor ontwikkelaars.

Trekker[bewerken]

Naam	Organisatie
Arjen Santema	Kadaster

Resultaten[bewerken]

Werkgroep SKOS-AX

Deelnemers en geïnteresseerden (op basis van bijeenkomsten 29 augustus 2014 en 12 februari 2015)[bewerken]

Uitgangssituatie: resultaten PILOD 2013/2014[bewerken]

In de PILOD 2013/2014 hebben we gewerkt aan een model om een bestaande basisregistratie volgens een aantal stappen om te zetten naar Linked Data. Daarvoor hebben we de BAG als casus genomen.

We hebben zichtbaar gemaakt hoe het begrippenkader kan worden opgesteld en beschreven als een samenhangend semantisch netwerk, inclusief de verwijzing naar de bron.
Ook hebben we laten zien hoe op basis van dit begrippenkader een model kan worden opgesteld waarin de BAG gegevens kunnen worden gerepresenteerd als Linked Data.
Bovendien zijn de BAG data zelf eenmalig omgezet naar Linked Data. Daarmee zijn de BAG data van begin 2014 beschikbaar als Linked Data en via hun uri beschikbaar via het web, bijvoorbeeld http://bag.kadaster.nl/id/pand/0200100000001088 voor het pand 'de Grift' in Apeldoorn.
Daarmee hebben we ook de uri-strategie praktisch vorm gegeven. De uri bestaat uit:
- Domein (bag.kadaster.nl)
- Type (id als afkorting van identificatie)
- Concept (pand)
- Referentie (het BAG-nummer van het pand: 0200100000001088)
De gevolgde methodiek en onderliggende principes zijn vastgelegd in het boekje ‘betekenisvol modelleren met BP4mc2’, dat ook digitaal beschikbaar is op http://bp4mc2.org.

Het begrippenkader staat op een cloudomgeving van het Kadaster die specifiek voor dit doel is ingericht (http://bag.kadaster.nl). Dit heeft een formele status en is ook bedoeld als basis voor de stelselcatalogus (http://stelselcatalogus.nl) . De BAG data zelf staan op de cloudomgeving die in Almere is ingericht voor het Platform Linked Data (http://almere.pilod.nl). Deze data hebben een pilot status.

Over het toepassen van de uri-strategie is enige discussie ontstaan omdat we daarin een organisatienaam (Kadaster) gebruiken. Dit is tegenstrijdig met de Joinup richtlijnen voor persistente uri’s (https://joinup.ec.europa.eu/community/semic/document/10-rules-persistent-uris), namelijk ‘bij voorkeur geen organisatienaam in de uri’. Dit heeft geleid tot een voorstel voor de Programmaraad Stelsel Basisregistraties voor een uri-strategie voor basisregistraties, met als 3rd level domeinnaam 'basisregistraties' binnen het domein 'overheid.nl' en 4th level de afkorting van de basisregistratie. De uri voor de Grift wordt dan bag.basisregistraties.overheid.nl/pand/0200100000001088.

Voor wat betreft de persistentie van de uri hoeft dit geen probleem te zijn. Met een statement als <kadaster-uri> owl:sameAs <overheid-uri> bljiven de eerder uitgegeven bag.kadaster.nl uri's gewoon werken. Ook kan een http-303 strategie worden gegebruikt, waarbij de kadaster.nl/id –uri refereert naar de overheid.nl/doc –uri. Dit zou dan een best-practice kunnen zijn in het kader van persistente URI’s (URI’s die zelf een eigen identiteit overleven).

Op 29 september is het concept van de BAG als Linked Data gepresenteerd in een werkgroep van het BAG/BAO (Bronhouders en Afnemers Overleg). Daar kwam onder andere naar voren dat het gebruik van de BAG zeer divers is, waardoor er ook zeer diverse wensen ontstaan. Een potentiële oplossing is het publiceren van een sobere BAG als Linked Data die door diverse afnemers kan worden verrijkt met gelinkte data die relevant zijn voor hun specifieke doeleinden.

Ambities doorontwikkeling methodiek basisregistraties en semantiek 2014/2015[bewerken]

In september 2014 was de ambitie in eerste instantie geformuleerd als het doorontwikkelen van de BAG showcase. Deze ambitie staat begin 2015 nog steeds overeind. Deze showcase is bedoeld om te laten zien wat de meerwaarde is van een als linked data gebpubliceerde (basis)registratie. Dit moet er zo uit gaan zien dat iedere beheerder van een (basis)registratie zegt 'dat wil ik ook'.

doorontwikkelen BAG showcase

Met name vanuit het ministerie van I&M wordt inmiddels steeds serieuzer gekeken naar Linked Data. Dit lijkt ook een bruikbare standaard om in de Laan voor de Leefomving, de ICT infrastructuur tbv de Omgevingswet, vorm te geven. Daarom is begin 2015 de ambitie uitgebreid om de semantiek van een basisregistratie nog strakker uit te werken rond W3C standaarden. Dit geldt voor:

het axiomatisch begrippenkader
het vocabuliare voor juridische events
patronen voor 'conditions', c.q. voorwaarden en regels bij juridische “handelingen”.
data schemes voor het beschrijven van de structuur van de registratie
meta data voor de gegevens in de registratie

Hieronder worden de ambities per deelonderwerp beschreven.

Bij de uitwerking van deze deelonderwerpen wordt zoveel mogelijk aansluiting gezocht bij de Data on the Web Best Practices Working Group.

Doorontwikkelen BAG showcase[bewerken]

Deelnemers:

De ambitie voor het onderwerp basisregistraties en semantiek in 2014/2015 is de showcase van de BAG door te ontwikkelen op de volgende onderwerpen/deliverables:

Toevoeging geometrie aan panden en verblijfsobjecten.
Koppeling semantiek aan core location (Locn) vocabulaire van Inspire en aan Vcard vocabulaire van de W3C en construeren van Vcard en Locn adressen in de linked data store. Daardoor kan bijvoorbeeld een app op basis van Vcard visitekaartgegevens combineren met adresinformatie uit de BAG, zonder de interne structuur van de BAG te hoeven kennen.
Dagelijkse bijwerking linked data store.
Ondersteuning van queries via de browser.
Beschikbaar stelling van een (Geo)Json/LD api op de BAG voor bouwers van toepassingen zoals apps.
Verbetering van het huidige webportaal, onder andere met een mogelijkheid van het tonen van adressen op een achtergrondkaart (OpenStreetmap).
Verbindingen met andere Linked Data verzamelingen als Geonames en Dbpedia.

‘The proof of the pudding is the eating’. Dat betekent dat de cirkel pas rond is als de ontwikkelaars community enthousiast wordt over deze vorm van publiceren van dat en ook daadwerkelijk wat gaat doen met deze data, dus toepassingen gaat bouwen. Een hackathon is een mogelijk middel om dit proces op gang te brengen.

Axiomatisch begrippenkader[bewerken]

Deelnemers:

Bij het beschrijven van een registratie wordt onderscheid gemaakt tussen de begrippen waarmee de dingen in de registratie worden beschreven en de registratie zelf. Begrippen maken duidelijk welke 'onderwerpen van gesprek' er bestaan, ofwel waar de registratie over gaat.

De W3C standaard om een begrippenkader of taxonomie te definieëren is SKOS (Simple Knowledge Organisation System). Belangrijke constructies in SKOS waarmee de samenhang tussen begrippen kan worden gedefinieerd zijn skos:broader, skos:narrower en skos:semanticRelation. Daarbij zijn skos:broader en skos:narrower gespiegeld, dat wil zeggen als het ene begrip een meer omvattend (broader) begrip is dan het ander is het andere begrip een enger (narrower) begrip dan dat ene. Dat zelfde geldt voor skos:related: als het ene begrip een relatie heeft met het andere heeft het andere impliciet een relatie met het eerste.

Een (basis)registratie wordt in de regel strak gedefinieerd in een wet of uitvoeringsregeling. In het begrippenkader wordt de relatie met de bron in de wet gelegd via dcterms:source. In een juridisch begrippenstelsel (of liever: institutioneel begrippenstelsel, het kan ook een instituut zijn dat het begrippenstelsel definieert) wordt elk begrip uitgelegd in termen van andere begrippen, totdat dat niet meer zinvol is. Dat is het geval bij begrippen waarvan de betekenis als 'vanzelfsprekend' wordt aangenomen. In een logisch model worden dit axioma's genoemd. Een voorbeeld is het begrip 'erfpacht'. Dit is een 'zakelijk recht'. Een 'zakelijk recht' is een 'recht' op een 'zaak'. Als je 'recht' gaat definiëren kom je in diepgaande filosofische discussies die bij het uitleggen van het begrip aan bijvoorbeeld je schoonmoeder niet echt helpen. Dit is een voorbeeld van een axioma.

In een axiomatisch begrippenstelsel wordt dus 1 kant op geredeneerd: van moeilijk naar makkelijk. Het stelsel is opgebouwd vanuit axioma’s. In een axiomatisch begrippenstelsel mogen geen cirkels voorkomen. Daaruit volgt dat symmetrische relaties en inverse relaties niet mogen voorkomen. Wel geld dat elke relatie transitief is. (dus: als A->B en B->C, dan is er geen D waarvoor geldt D->A en C->D, maar juist WEL geldt dat A->C)

De gedachte is dat een axiomatisch begrippenstelsel nodig is om de samenhang tussen de begrippen of onderwerpen van gesprek in een registratie te kunnen begrijpen en dat SKOS het geëigende vocabulaire voor een begrippenstelsel. Om axiomatisch redeneren mogelijk te maken is het idee om SKOS uit te breiden met 3 elementen (zie ook http://www.w3.org/2004/02/skos/extensions/spec/2004-10-18.html):

skos:broaderGeneric (An extension of the 'broader' property to specify the class subsumption (sub-class/super-class) relationship between two concepts).
skos:narrowerGeneric (This property is the inverse of the 'broaderGeneric' property)
skos:relatedTransitive

Een punt van discussie is of ook deel- geheel relaties toegevoegde waarde hebben in een axiomatisch begrippenkader. Het gaat dan om:

skos:broaderPartitive (An extension of the 'skos:broader' property to specify an instantiation (instance of) relationship between two concepts.)
skos:narrowerPartitive (This property is the inverse of the 'broaderPartitive' property)

Voor dit onderwerp wordt eerst via LinkedIn een discussie gestart of deze uitbreiding echt wel gewenst is om tot een strak begrippenkader te komen en of dit dan nog wel 'des SKOS's is'.

Vervolgens is de bedoeling om deze uitbreidingen in een werksessie tijdens een conceptual friday semantisch te definiëren en aan de W3C aan te bieden in een vorm waarin ze kunnen worden gepucliceerd als potentiële aanvulling op SKOS: SKOS-AX.

Zie Werkgroep SKOS-AX voor de resultaten van de werksessies.

Vocabulaire juridische events[bewerken]

Deelnemers:

In een axiomatisch begrippenstelsel worden de dingen waar het om gaat in de juridische (of institutionele) werkelijkheid gedefinieerd en wordt de samenhang met de wet of regelgeving vastgelegd. De wet of regelgeving beschrijft ook hoe de registratie werkt. Wat er allemaal kan gebeuren met de dingen waar de registratie over gaat en welke regels daarvoor gelden.

Net als een begrippenstelsel nodig is om begrijpen waar een registratie over gaat is een beschrijving van (juridische of institutionele) gebeurtenissen of 'handelingen' nodig om te begrijpen hoe een registratie zich gedraagt. Dingen waar het over gaat in het begrippenstelsel zijn het onderwerp (van gesprek) en worden aangeduid met zelfstandige naamwoorden. Gebeurtenissen worden aangeduid met een werkwoordsvorm.

Een juridische of institutionele gebeurtenis vindt altijd plaats naar aanleiding van een real-life event in de 'echte' werkelijkheid.
Daarvoor gelden regels (aanleiding), bijvoorbeeld 'als er een nieuw huis wordt bijgebouwd in een straat moet daar een huisnummer aan worden toegekend'.
Bij de gebeurtenis of uitvoering van de rechtshandeling worden eveneens regels (onder voorwaarde dat...) gehanteerd, bijvoorbeeld 'de huisnummers in een straat zijn altijd oplopend'.
De laatste categorie regels bepaalt de eindsituatie waarin een juridisch of insitutioneel feit is gecreëerd.

De bedoeling is juridische of institutionele gebeurtenissen te beschrijven op basis van een standaard vocabulaire, waar mogelijk een bestaande (W3C) standaard. Als het nodig blijkt kunnen ook hier voorstellen worden geformullerd om het vocabulaire uit te breiden. Een kandidaat lijkt ODRL (Open Digital Rights Language) van de W3C. De ODRL community group zegt over ODRL: 'The ODRL Policy model is targeted to support the business models of open, educational, government, and commercial communities through Profiles that enhance the model to align to their requirements whilst providing a common semantic layer for interoperability.'

Stappen om te komen tot een beschrijving voor juridische events:

op basis van de theorie van de rechtsinformatica vaststellen van de concepten waarmee juridische events worden beschreven (zie onder andere http://bp4mc2.org/#gebeurtenissen).
het beschrijven van tijds- en locatie-aspecten (temporal en spatial) bij deze events
het beschrijven van de modaliteit (wat de relatie is van de actor tot handeling), bijvoorbeeld dat de actor de bevoegdheid heeft om de handeling uit te voeren, of juist dat dit moet, of juist niet mag, etc…
onderzoeken of deze concepten kunnen worden geplot op ODRL en of dit voldoende structuur geeft.

Ook voor dit onderwerp is de opzet om te starten met een discussie via LinkedIn en op basis van de resultaten in deze discussie in een werksessie tijdens een Conceptual Friday de projectie op ODRL of een eventueel ander raamwerk uit te werken.

Patronen voor conditions[bewerken]

Deelnemers:

Bij gebeurtenissen komen 3 soorten regels (zie http://bp4mc2.org/#samenhang) naar voren:

aanleiding
voorwaarden
derivatieregels

Doel van dit deelproject is:

vast te stellen of deze drie categorieën regels afdoende zijn om de werking van een basisrigstratie (of in bredere zin: van het handelen van de overheid) te beschrijven.
patronen voor het beschrijven van deze catagorieën regels te beschrijven.
het gaat hierbij om een standaard voor het annoteren van wetgeving en het inventariseren van regels. Daarmee worden de regels zelf gescheiden van de toepassing van die regels in bijvoorbeeld beslissingsbomen. Daarmee wordt met het beheer van regels ten aanzien van de realisatie (in de vorm van bijvoorbeeld beslisbomen) in een regelbeheersysteem hetzelfde gedaan als met het beheer van begrippen ten aanzien van de realisatie (in de vorm van informatie) in een informatiesysteem.

Voor het beschrijven van patronen zijn twee mogelijkheden:

uitwerken van regels in de vorm van een vaste structuur. In linked data termen krijgt dan alleen de regel een uri. De regel zelf is dan niet interpreteerbaar als Linked Data.
het toekennen van een vocabulair waarmee deze structuur wordt beschreven en computer interpreteerbaar wordt.

Data schemes[bewerken]

Deelnmers:

In het proces van 'ver-linken' van de BAG is eerst het begrippenkader gedefinieerd in een axiomatisch begrippenkader zoals hierboven beschreven. Nadat deze 'onderwerpen van gesprek' voor deze registratie op een rij waren gezet is op basis van dit begrippenkader een instantieerbare ontologie in OWL gedefinieerd.

OWL is echter niet meer dan een ontologie die uit gaat van het open world principe. Als een object of eigenschap in een OWL ontologie niet aanwezig is, betekent dat nog niet dat het niet bestaat. Constraints als 'een nummeraanduiding hoort altijd bij 1 openbare ruimte in 1 woonplaats', of in gewone mensentaal 'een combinatie van straat en huisnummer is uniek binnen een woonplaats', kunnen niet worden uitgedrukt in OWL. Dit soort inherente consistenties in de registratie worden traditioneel meegemodelleerd in informatiemodellen, bijvoorbeeld in XML schema's, al dan niet aangevuld met XML Schematron. Dat is handig en vaak nodig voor systemen die deze gegevens gebruiken. Die weten dan waar ze op kunnen rekenen.

SHACL (Shapes Constraint Language) is bedoeld om dergelijke 'schema-regels' te definiëren. De W3C data shapes werkgroep heeft als missie 'to produce a language for defining structural constraints on RDF graphs. In the same way that SPARQL made it possible to query RDF data, the product of the RDF Data Shapes WG will enable the definition of graph topologies for interface specification, code development, and data verification.' Zie ook de data shapes wiki.

Het ligt voor de hand aan te haken bij de resultaten van deze werkgroep. De editors draft is op 9 maar 2015 uitgebracht, maar is gebaseerd op een al langer bestaand vocabulair, de resource shape ontology.

De voorgenomen werkwijze voor dit onderwerp is:

een werksessie in de vorm van een conceptual friday waarin dit vocabulair wordt toegepast op de 'ver-linkte' BAG.

Metadata[bewerken]

Deelnemers:

Instanties van gegevens hebben allerlei meta kenmerken. Typische vocabulairs die hiervoor in de Linked Data wereld worden gebruikt zijn Dublin Core Metadata Initiative (DCMI), Data Catalog Vocabulary (DCAT) en uitbreidingen of profielen daarop. Ook de Provenance Ontology is van belang om de provenance data te beschrijven.

Veel denkwerk over welke metadata relevant zijn voor een (basis)registratie is al gedaan vanuit de stelselcatalogus en vanuit het Kenniscentrum Officiële OverheidsPublicaties (KOOP).

Ook voor dit onderwerp is de intentie om:

in een werksessie in de vorm van een conceptual friday een concept toepassingsprofiel voor alle metadata voor een (basis)registratie te definiëren op basis van DCMI, DCAT en PROV-O.

Werkwijze[bewerken]

Deelnemers:

De rol voor het platform in dit proces is die van een 'open innovatie platform'. Het proces om te komen tot de beschreven deliverables wordt aangestuurd vanuit de open innovatie omgeving zoals die het afgelopen jaar in het platform via de LinkedIn groep en via fysieke bijeenkomsten op de conceptual fridays is opgebouwd. Deze omgeving biedt de kans om een gedeeld raamwerk neer te zetten dat wordt gedragen door eigenaren, bronhouders en afnemers (ook van andere registratie) en niet te vergeten de deskundigen in de (internationale) standaarden. Daardoor wordt ook de aansluiting bij internationale ontwikkelingen geborgd.

De opzet is dat dit raamwerk zich door het werken vanuit een brede community ontwikkelt tot een algemeen raamwerk dat ook kan worden toegepast op andere basisregistraties. Juist het karakter van linked data (federatief beheer, anyone can say anthing about anything) leent zich voor deze werkwijze. Sterker nog, door dit karakter is dit waarschijnlijk de enige werkwijze waarmee iets in eerste instantie klein kan worden neergezet en in samenhang met andere ontwikkelingen en zich ontwikkelende standaarden de goede kant op kan doorgroeien naar het beoogde raamwerk.

Naast deze denktank waarin we zoveel mogelijk ‘thought leaders’ proberen te betrekken zal ook ‘echt werk’ verzet moeten worden zoals het laden van data, monitoring van het gebruik en het ontwikkelen van api’s en portalen. Het idee is om dit te doen met een mix van mensen die hierin de weg kunnen wijzen en daartoe (betaalde) professionele inzet leveren en mensen die willen leren en meekijken hoe dit werkt voor Linked Data omgevingen.

Verslagen[bewerken]

Verslag conceptual friday 29 augustus 2014[bewerken]

aankondiging[bewerken]

Afgelopen jaar hebben we de BAG gebruikt als casus om een basisregistratie om te zetten naar linked data. Daarbij hebben we een bepaalde strategie gehanteerd een een aantal ontwerpbesliissingen genomen. Bart van Leeuwen vanuit Netage en Frans Knibbe vanuit Geodan hebben beiden ook een linked data implementatie van de BAG gemaakt en op een aantal plaatsen een andere strategie gehanteerd en andere ontwerpbeslissingen genomen.

Enkele onderwerpen:

onderscheid (juridisch) begrippenkader versus ontologie van de BAG objecten
1 op 1 vertalen huidige gepubliceerde BAG model naar linked data versus eerst begrippenkader maken en op basis van die inzichten een ontologie maken
provenance data als graph properties versus meenemen in het model
....

Wat zijn good practices?

Verslag[bewerken]

Aanwezig:

Bart van Leeuwen (Netage, brandweer Amsterdam)
Frans Knibbe (Geodan)
Marco Brattinga (Ordina)
Janette Storm (Kadaster, BAG)
Leo Meerman (CELT)
Hans Overbeek (KOOP)
Bert ten Brinke (Nieuwland)
Arjen Santema (Kadaster)

Doel van deze conceptual Friday was om de verschillende implementaties van de BAG als Linked Data op een rij te zetten en daaruit best practices te distilleren. De 3 implementaties zijn:

De implementatie van Netage door Bart Van Leeuwen: http://data.resc.info/bag
De implementatie van Geodan door Frans Knibbe: http://lod.geodan.nl/vocab/bag/index.html
De implementatie van PiLOD door Marco Brattinga en Arjen Santema: http://bag.kadaster.nl

Implementatie Netage (Bart)

Bart heeft nlextract (nlextract.nl) als bron gebruikt. Hij heeft een eigen PostGIS server ingericht, met daarboven op een SPARQL endpoint. De data worden vanuit dit SPRAQL endpoint dynamisch met behulp van D2R opgehaald uit de database en geserveerd als linked data. De BAG data krijgen een uri op basis van de Kadaster identificatie en zijn ze via het web opvraagbaar.
De use case is voornamelijk gebaseerd op gebruik door de brandweer.
De keuze voor een eigen server is mede ingegeven om afhankelijkheid van een externe server te voorkomen.
Iedere 3 maanden wordt de database bijgewerkt.
De dataset bevat geen historie. Wel wordt de laatste wijzigingsdatum vastgelegd. Een recente wijzigingsdatum is soms informatief.
Op basis van de standaard vocabulaires vcard (http://www.w3.org/TR/vcard-rdf/) en locn (Location Core Vocabulary, zie http://www.w3.org/ns/locn#) worden adressen gepresenteerd.
Een aandachtspunt is het referentiestelsel bij de geometrie.
Er is geen koppeling met de begripsdefinities in de stelselcatalogus.

Implementatie Geodan (Frans)

Frans heeft recent een verbeterde versie van de BAG neergezet.
De URI van de BAG van Geodan is http://lod.geodan.nl/basisreg/bag/. Dat is de URI van de dataset. De URI van de HTML-weergave van het BAG-vocabularium is http://lod.geodan.nl/vocab/bag/index.html.
De data worden als RDF weggeschreven uit de PostgreSQL-database via SQL-commando's. D2R komt er niet aan te pas.
Na publicatie zijn de gegevens nog niet vernieuwd. Wat niet wegneemt dat dat wel zou kunnen gebeuren als daar vraag naar is.
Deze opzet is gericht op zoveel mogelijk, ook misschien nu nog onbekende, use cases.
De database is mutatiegericht.
Er een graaf per type BAG-object.
Het vocabularium is tweetalig. Het is niet echt gebaseerd op de beschrijving van de stelselcatalogus, maar geeft wel een koppeling naar de stelselcatalogus als dat mogelijk is.
Er is een mapping gemaakt naar locn.
De HTML-weergave van het vocabularium is gegenereerd door Topbraid Composer. Voor wat betreft documentatie kan worden verwezen naar een serie blogjes. Het eerste deel is http://www.geodan.nl/basisregistratie-adressen-gebouwen-bag-vijfsterrendataset/, de vervolgartikelen zijn van daar uit te vinden.

Implementatie PiLOD (Marco)

De implementatie van Marco voor PiLOD gebruikt een dump van de PDOK database. De data wordt ook hier via D2R ingelezen in Virtuoso.
De data is eenmalig ingelezen, er is nog geen proces voor bijwerking.
Deze opzet is gericht op zoveel mogelijk, ook misschien nu nog onbekende, use cases.
Voor het model is als eerste stap een begrippenmodel gemaakt op basis van de wet. De begrippen beschrijven samen met de bijbehorende gebeurtenissen de ‘juridische werkelijkheid’.
Voor het begrippenmodel is een eigen vocabulaire ontwikkeld omdat alle begrippen worden herleid tot enkele ‘axioma’s’. Dit vocabulaire kan grotendeels worden herleid tot SKOS.
Uitgaand van het begrippenmodel is een ontologie gedefinieerd met objecten en properties.
Het begrippenmodel is bedoeld als basis voor de stelselcatalogus: de stelselcatalogus linkt dan naar deze begrippen. Dit maakt ook terugmelding op de semantiek mogelijk.
De database is gebeurtenisgericht, waarbij een gebeurtenis een event in de juridische werkelijkheid is. Dat is net iets anders als een administratieve mutatie.
Per gebeurtenis wordt een graph gemaakt, waardoor tijdreizen en provenance informatie direct beschikbaar is.

Aandachtspunten en vervolgstappen:

Munten van uri’s lijkt een kerntaak voor de beheerder (i.c. het Kadaster).
Gebruikers worden beter bediend wanneer ook uri’s aan adressen worden toegekend.
Een bron bron voor de BAG als linked data ligt voor de hand, maar replicatie op verschillende servers blijft waarschijnlijk handig voor de rubuustheid.
De implementatie van Geodan is 2e generatie en bevat voortschrijdend inzicht naar aanleiding van de eerste versie. De implementatie van de PiLOD heeft net als die van Geodan de pretentie om zoveel mogelijk use cases te ondersteunen. De implementatie van Netage is vooral gericht op gebruik door de brandweer met een tamelijk plat datamodel en kent bijvoorbeeld geen opvraagmogelijkheid op geometrie.
Arjen maakt een vergelijking tussen het datamodel van Geodan en het datamodel van de PiLOD implementatie.
Janette kijkt naar de vraag of en hoe gebruikers beter worden bediend met een linked data implementatie, c.q. de business case voor het Kadaster in de rol van beheerder van de landelijke voorziening van de BAG.
Bart bewaakt vanuit zijn netwerk in de W3C de aansluiting bij internationale ontwikkelingen.

Verslag werksessie12 februari[bewerken]

Aanwezig:

In de werksessie bij Semaku in Eindhoven op 12 februari zijn de aanvankelijke ambities voor het uitbreiden van de BAG als Linked Data tot een complete showcase aangevuld met nieuwe ambities op het vlak van een nauwere aansluiting bij W3C standaarden. De presentatie is te vinden op http://www.pilod.nl/w/images/1/1b/20150212_Semaku_Aanpak_Basisregistraties.pdf.

Naar aanleiding van deze sessie heeft een aantal mensen zich aangemeld om actief mee te denken over dan wel mee te werken aan deze onderwerpen:

Verlsag conceptual friday 29 mei 2015[bewerken]

Aanwezig:

In deze werksessie zijn de doelstellingen en uitgangspunten voor de Werkgroep SKOS-AX uitgewerkt. Zie Werkgroep_SKOS-AX

Verslag werksessie PLDN 1 juli 2015[bewerken]

In een inleidende presentatie werd de Laan van de Leefomgeving als digitaals stelsel voor de omgevingswet gebruikt als use case waarin semantiek een vebindend element is. Daarbij is het vocabulair voor het beschrijven van de semantiek van datasets en registraties met W3C standaarden als DCAT, OWL, SHACL (in ontwikkeling) etc. tamelijk goed afgedekt. De basis voor het uitleggen van een registratie, gebeurtenissen en regels aan mensen is voor wat betreft begrippen voor een belangrijk deel aanwezig in de W3C standaard SKOS.

Als je gericht, zonder circelredeneringen waarom-waarom-waarom vragen wilt beantwooden heb je gerichte, transitieve realaies tussen begrippen nodig. Ook partitieve relaties zijn daarbij soms nodig. Hiervoor willen we SKOS uitbreiden met enkele concepten die een gerichte uitleg mogelijk maken. Het verslag van de discussie over dit onderwerp is opgenomen op de pagina van de werkgroep SKOS-AX.
Een missing link in de beschikbare vocabulaires is het beschrijven van gebeurtenissen. De discussies over dit onderwerp is ogenomen op de pagina van de werkgroep gebeurtenissen.

Aanpak Basisregistraties

Inhoud

Doelstelling[bewerken]

Trekker[bewerken]

Resultaten[bewerken]

Deelnemers en geïnteresseerden (op basis van bijeenkomsten 29 augustus 2014 en 12 februari 2015)[bewerken]

Uitgangssituatie: resultaten PILOD 2013/2014[bewerken]

Ambities doorontwikkeling methodiek basisregistraties en semantiek 2014/2015[bewerken]

Doorontwikkelen BAG showcase[bewerken]

Axiomatisch begrippenkader[bewerken]

Vocabulaire juridische events[bewerken]

Patronen voor conditions[bewerken]

Data schemes[bewerken]

Metadata[bewerken]

Werkwijze[bewerken]

Verslagen[bewerken]

Verslag conceptual friday 29 augustus 2014[bewerken]

aankondiging[bewerken]

Verslag[bewerken]

Verslag werksessie12 februari[bewerken]

Verlsag conceptual friday 29 mei 2015[bewerken]

Verslag werksessie PLDN 1 juli 2015[bewerken]

Nieuwsbrief

Mogelijk gemaakt door

Leden