Informatiemodel Officiële Publicaties (IMOP)

Transcriptie

1 Informatiemodel Officiële Publicaties (IMOP) Versie 0.85 Geonovum KOOP Datum 15 januari 2018

2

3 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 Colofon Documentnaam Informatiemodel Officiële Publicaties Projectnaam Standaard Officiële Publicaties met specifieke toepassing voor omgevingsdocumenten Projectnummer PR04 Versienummer 0.85 Locatie Amersfoort Contactpersoon Eric van Capelleveen Auteurs Matthijs Breebaart (KOOP) Gerard Houtman (KOOP) Frank Robijn (KOOP) Paul Janssen (Geonovum) Wilko Quak (KOOP) Hans Overbeek (Geonovum) Gerard Wolbers (Geonovum) Versiehistorie Versie Datum Door Sectie Omschrijving PR04 alles Nieuw document met enkel hoofdstukindeling PR04 alles Eerste oplevering buiten PR PR04 H4 en H6 Oplevering voor gebruikersgroep. Geomodel is aangepast. De review opmerkingen op 0.2 (0.52) zijn niet verwerkt PR04 alles Kopie van v0.521 voor gebruikersgroep 2 november PR04 alles Oplevering t.b.v. 0.6 versie PR04 alles Redactionele aanpassingen en terminologie PR04 alles Actualisering inhoud PR04 H4, H5 en H7 In hoofdstuk 4 is subparagraaf vervangen door paragraaf 4.3. In overige paragrafen zijn lichte wijzigingen doorgevoerd. Voormalig hoofdstuk 5 Metadata is herschreven. Hoofdstuk 7 Muteren en consolideren is substantieel gewijzigd PR04 alles Gehele inhoud is opnieuw doorgelopen op interne consistentie en terminologie. Onder andere is gekeken naar zo consequent mogelijk gebruik van de termen uit de IMOP Vocabulaire en aansluiting op de ideeën rond het toepassingsmechanisme. Deze consistentie is nog niet volledig bereikt. Pagina 3 van 53

4 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER 2017 Inhoud Colofon 3 1 Inleiding Toepassingsdomein Uitgangspunten Gerelateerde documenten 7 2 Modelbeschrijving Document en Tekststructuur-objecten Aanvullende objecten IMOP-relaties IMOP-eigenschappen IMOP-vocabulaire en IMOP-namespace Documenttype-objecten 12 3 Document en Tekst Abstracte entiteiten Container Block Inline Marker Globale restricties Entiteiten Documentniveau RegelingStructuur VrijeTekstStructuur Gedeelde klassen Overige aandachtspunten Overzicht 20 4 Geo-informatie Uitgangspunten bij modellering van imop:locatie Een imop:locatie kan niet los van tekst bestaan Geometrie is gebiedsgericht Koppeling tussen tekst en geometrie Semantiek van geometrie Geometriemodel imop:locatieomschrijving imop:locatieverwijzing imop:geometrie imop:locatiegroep Gebruik van GML voor codering van geometrie GML en GML GML profielen 24 Pagina 4 van 53

5 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI Data Data Atomaire objecten Klasse imop:object Klasse imop:reeks Relatie tussen lopende tekst en data Juridische betekenis van data Relatie met RDF en JSON 27 6 Identifiers Identificatie van documenten FRBR Globale identifiers https {domein} {context} Identificatie van een imop:werk (frbr:work) {lokale identificatie} Identificatie van een imop:versie (frbr:expression) {versie} Identificatie van een imop:formaat (frbr:manifestation) {formaat} Identificatie van onderdelen van officiële publicaties Het FRBR-patroon toegepast op onderdelen Algoritme Het proces van toekenning van identifiers De LVBB Relatie met andere standaarden voor identificatie Akoma Ntoso/LegalDocMl ELI identifiers Juriconnect-standaarden 39 7 Muteren en consolideren Inleiding Uitgangspunten Proces Referentie procesmodel wijzigingsbesluiten Toestanden en berichten Model Mutatie Publicatiecontainers Toestandsovergang Objectspecificaties 49 8 IMOP vocabulaire 52 9 Normatieve referenties 53 Pagina 5 van 53

6 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER 2017 Pagina 6 van 53

7 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI Inleiding 1.1 Toepassingsdomein Dit document beschrijft het informatiemodel voor officiële publicaties van bekendmakingen en consolidaties van de door de overheid gestelde besluiten van algemene strekking. Het model heet Informatiemodel voor Officiële Publicaties, wat wordt afgekort tot IMOP. Het IMOP bevat de generieke, abstracte basis voor beschrijving van structuur en inhoud van officiële publicaties in officiële publicatiebladen van overheden en de daaruit afgeleide consolidaties, alsmede het aan die publicaties gerelateerde berichtenverkeer. 1.2 Uitgangspunten Uitgangspunten zijn verwerkt in het document Toelichting op Standaard Officiële Publicaties met Toepassingsprofiel Omgevingsdocumenten (STOP/TPOD). 1.3 Gerelateerde documenten IMOP is onderdeel van de Standaard Officiële Publicaties (STOP) en moet begrepen worden in samenhang met de daarin genoemde standaarden en producten. IMOP zelf bestaat ook weer uit verschillende onderdelen die in samenhang toegepast moeten worden. Figuur 1 beschrijft de decompositie van STOP, de positie van IMOP daarin en de onderdelen daarvan. Pagina 7 van 53

8 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER 2017 Figuur 1 Decompositie van de standaard STOP in de verschillende onderdelen. (bron: PID PR04. Daar heette het Presentatiemodel nog Verbeeldingsstandaard OP en het Berichtenmodel nog Uitwisselingsstandaard OP). IMOP omvat de volgende onderdelen: IMOP dataspecificatie: Beschrijving van de concepten die in IMOP worden gehanteerd. IMOP waardenlijsten: Door IMOP gedefinieerde en gerefereerde waardenlijsten. IMOP business rules: Binnen IMOP gedefinieerde business rules. Naast IMOP zijn er als onderdeel van STOP nog twee standaarden: Presentatiemodel VSOP: standaard voor de presentatie van publicaties aan de menselijke lezer. Berichtenmodel USOP: berichtenmodel met specificaties voor de berichten waarmee publicaties worden uitgewisseld. In Figuur 1 is te zien dat ook de IMOP dataspecificatie bestaat uit verschillende onderdelen: IMOP dataspecificatie normatieve beschrijving: Dit document. IMOP UML-model: Publicatie van het UML in een technisch formaat. IMOP XSD s: De implementatie van het model in XML schema s. IMOP registerpublicatie: De publicatie van het model in de vorm van een vocabulaire, bijvoorbeeld in een stelselcatalogus. Pagina 8 van 53

9 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 Al deze onderdelen gezamenlijk beschrijven de specificaties van IMOP. Dit document is daarbij het integrerende document van waaruit naar de onderdelen gerefereerd wordt. Een overzicht van de normatieve referenties waarnaar in dit document verwezen wordt, is opgenomen in bijlage 1. Pagina 9 van 53

10 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER Modelbeschrijving Het informatiemodel IMOP is een verzameling van informatieobjecten (klassen) en relatietypen. IMOP is gericht op het coderen van documenten die door het bevoegd gezag worden opgesteld voor verwerking in de keten van bekendmaken en gebruiken door diverse toepassingen. Deze documenten bevatten tekst. In aanvulling op de tekst bevatten documenten andere informatie. Dit betreft bijvoorbeeld metadata of geometrische informatie. IMOP biedt ook klassen om dergelijke informatie te coderen, maar dit is altijd in relatie tot en gekoppeld aan de tekstuele klassen. 2.1 Document en Tekststructuur-objecten Het Document is een klasse die dient om een afgebakende verzameling van lopende tekstobjecten met daarbij behorende aanvullende informatie te coderen. Subklassen van Document zijn Bericht, Blad, Toestand. Een Bericht kan bijvoorbeeld een besluit van een bevoegd gezag bevatten, met motivatie en geografische informatie. IMOP is gericht op officiële bekendmakingen. Deze kunnen sterk verschillen naar manier waarop de inhoud is gestructureerd. Klasse Tekststructuur representeert een manier van schrijven, en kan worden gezien als de bundeling van objecten die beschikbaar zijn om de lopende tekst te coderen. Een voorbeeld van Tekststructuur is de klasse RegelingStructuur. Deze klasse is gericht op het coderen van regelingen, met een aanhef, lichaam en sluiting. Klasse VrijeTekstStructuur is een voorbeeld van een Tekststructuur die een minder formele inhoud heeft en dus ook gebruikt zou kunnen worden voor een eenregelige aankondiging. In hoofdstuk 3 worden de klassen beschreven die binnen ieder tekststructuur beschikbaar zijn. De relatie tussen Document en Tekststructuur is dat de eerste verplicht een implementatie van Tekststructuur moet bevatten. Met andere woorden: een IMOP-document bevat altijd een regeling of een vrije tekst. 2.2 Aanvullende objecten Tekststructuur-objecten zijn gericht op het coderen van de lopende tekst. Er is echter ook informatie in het Document die geen onderdeel uitmaakt van de lopende tekst, maar gaat over (onderdelen van) de lopende tekst. Deze informatie wordt als metadata gekoppeld met behulp van eigenschappen en relaties. Een eigenschap betreft altijd een atomair object (string, datum, numerieke waarde etc.). Een relatie wordt vastgelegd als een samengesteld object. De samengestelde objecten zijn subklassen van imop:object of subklassen van imop:locatie. Pagina 10 van 53

11 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 De abstracte klasse imop:object representeert een bundeling van eigenschappen die waarden hebben. Een concrete specialisatie van imop:object zal definiëren welke eigenschappen verplicht of optioneel zijn en welk bereik iedere eigenschap heeft. De klasse Locatie is een abstracte klasse voor geografische informatie. Deze klasse wordt gebruikt als bereik van een aantal relaties, waaronder werkingsgebied. De concrete klasse Geometrie is een Locatie die vlakken (gebieden) in de wereld representeert. De klasse Locatiegroep is een andere implementatie van Locatie, die een aantal Geometrie- en/of Locatiegroep-objecten kan bundelen. Locatiegroep en Geometrie vormen samen de groep van Geo-objecten. 2.3 IMOP-relaties Relaties verbinden objecten. IMOP kent een aantal standaard relatietypen: imop:onderdeel imop:werkingsgebied Relatietypen beginnen net als eigenschappen met een kleine letter, terwijl klassen een naam hebben die begint met een hoofdletter. Het relatietype imop:onderdeel is bedoeld voor een sterke deel-geheel relatie en komt overeen met de UML composition relatie. Implicaties zijn bijvoorbeeld dat een deel maximaal onderdeel kan zijn van 1 geheel. Het relatietype imop:werkingsgebied is een relatie tussen een imop:klasse en een imop:locatie klasse waarbij de eerste (het domein) zelf niet mag afstammen van imop:locatie. In essentie maakt de relatie het mogelijk om een relatie te leggen tussen tekst en geo. 2.4 IMOP-eigenschappen IMOP schrijft het gebruik van OWMS voor. Modelmatig worden de negen OWMS kern eigenschappen voorgeschreven als eigenschappen van de abstracte Document klasse, en daarmee van alle implementaties daarvan. Het betreft de volgende eigenschappen: dcterms:identifier; dcterms:title; dcterms:type; dcterms:language; overheid:authority; dcterms:creator; dcterms:modified; dcterms:temporal; dcterms:spatial. De laatste twee eigenschappen zijn optioneel. Pagina 11 van 53

12 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER IMOP-vocabulaire en IMOP-namespace Elk concept uit IMOP heeft een definitie en wordt aangeduid met een term. Deze termen en definities leggen we vast in een vocabulaire. Om te zorgen dat steeds duidelijk is dat we met een term precies het concept bedoelen zoals dat in IMOP is gedefinieerd, maken we gebruik van een namespace voor IMOP. Een namespace heeft een URI en een alias. De URI voor de IMOP namespace moet nog bepaald worden. De alias schrijven we als imop. Als we het over concepten uit IMOP hebben zetten we imop: voor de term. Bijvoorbeeld imop:artikel. 2.6 Documenttype-objecten De IMOP-standaard is gericht op officiële bekendmakingen van Nederlandse overheidsinstanties. Dit varieert van een verkeersbesluit door een gemeente tot een verdrag met een buitenlandse mogendheid, en alles daartussen. Het documenttype is een definitie van de informatie die in een specifiek soort document gaat voorkomen. Gezien het verschil in informatie is het de verwachting dat er aparte documenttypes nodig zullen zijn voor verkeersbesluiten en voor verdragen. Een documenttype wordt gerealiseerd met behulp van een zogeheten toepassingsprofiel waarin gedefinieerd wordt welke IMOP-objecten op welke manier toegepast worden. Dit werkt via restricties. Stel bijvoorbeeld dat een documenttype Verkeersbesluit nodig is. Dit is dan een imop:document met een aantal restricties daarop. Een voorbeeld van een restrictie is dat de verplichte eigenschap dcterms:type van Document de waarde Verkeersbesluit heeft. Een andere restrictie kan zijn dat de tekststructuur van een Verkeersbesluit een RegelingStructuur is. IMOP definieert wel het idee van documenttype maar niet de concrete implementaties daarvan zoals Verkeersbesluit of Verdrag. Hiervoor dient IMTP, het informatiemodel voor toepassingsprofielen. Voor IMTP is een aparte specificatie opgesteld. Pagina 12 van 53

13 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI Document en Tekst IMOP is gericht op het coderen van overheidspublicaties. Deze publicaties zijn semigestructureerd; ze bevatten een combinatie van relatief ongestructureerde leesbare tekst en gestructureerde eigenschap-waarde paren. Het coderen van de leesbare tekst van een publicatie neemt een centrale plaats in bij IMOP. De opeenvolging van tekens, geordend in alinea s, tabellen, lijsten, etc. is de kapstok waaraan aanvullende informatie wordt opgehangen. Het tekstmodel beschrijft welke entiteiten relevant zijn bij het coderen van de tekst en de additionele informatie. IMOP is in principe syntax-neutraal en implementatie-vrij. Entiteiten als hoofdstuk of artikel kunnen op meerdere manieren vastgelegd worden. In de praktijk wordt XML gebruikt als bronformaat voor de publicaties. De beperkingen en mogelijkheden van XML hebben op diverse plaatsen impact op IMOP. Dit wordt dan aangegeven. 3.1 Abstracte entiteiten IMOP maakt gebruik van een aantal abstracte entiteiten die gebruikt worden voor classificatie van de niet abstracte entiteiten (de klassen). Dit is vergelijkbaar met de manier waarop de ISO standaard Akoma Ntoso is opgezet 1. Tekstfragment + id: anyuri Container Block Inline Figuur 2 De drie hoofdklasses onder Tekstfragment In de volgende secties wordt nader beschreven welke rol de abstracte entiteiten vervullen, welke implementaties beschikbaar zijn, welke eigenschappen ze hebben, en hoe uitbreidingen kunnen plaatsvinden. Wanneer in de volgende paragrafen wordt gesproken over Block dan wordt hiermee bedoeld een concrete klasse die gecategoriseerd is als imop:block. De prefix imop wordt omwille van de leesbaarheid 1 Zie Pagina 13 van 53

14 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER 2017 zoveel mogelijk weggelaten; op het moment dat Block, etc. met een hoofdletter wordt geschreven dat wordt hier imop:block bedoeld. Hetzelfde geldt voor concrete klassen als Artikel Container Een Container is een groepering van één of meer Containers en/of één of meer Structuurelementen. De Container bevat zelf geen tekst daarvoor dient Block - en heeft geen default vormgeving. Containers zijn over het algemeen grote logische blokken binnen een publicatie. De inhoud van een Container varieert sterk. Document en Structuurelement zijn specialisaties van Container. Er zijn twee (nog steeds abstracte) subtypen van Container gedefinieerd: ContainerBlocks en ContainerContainers. De eerste representeert een Container die zelf alleen Blocks mag bevatten; de laatste representeert een Container die alleen Container elementen mag bevatten. Binnen ContainerContainers zijn nog twee subtypen gedefinieerd: Document en Structuurelement. Document is de container op het hoogste niveau, met andere woorden een container die zelf geen onderdeel is van een andere ContainerContainers. Structuurelement is een classificatie van klassen die gericht zijn op het ordenen van Artikelen. Het gaat dan om bijvoorbeeld Hoofdstuk en Paragraaf Block Een Block bevat tekst en optioneel Inline, Marker en/of Block elementen. Een Block is daarmee een entiteit die fungeert als een soort container op tekstniveau. Een voorbeeld van een Block is het alinea element. In een aantal gevallen is een klasse onder Block gehangen terwijl het eigenlijk strikt genomen meer lijkt op een Container. Dit is gedaan omdat deze dan gemengd moet kunnen worden met echte Block klassen. Een voorbeeld is klasse Table. Deze heeft zelf geen tekst want de tekst zit diep verborgen in de object hiërarchie in cellen maar moet toch combineerbaar zijn met alinea's en lijsten. Om deze gevallen tegemoet te komen, is er een abstracte subklasse van Block gemaakt: BlockContainerVirtueelType Inline Een Inline bevat tekst en/of (één of meer) Inline elementen. Een voorbeeld van een Inline is de aanduiding voor superscript, nadruk vet, etc. Een Inline kan ook gebruikt worden als anker om aan tekst eigenschappen toe te kennen, waarbij bijvoorbeeld de rol van een stukje tekst nader gespecificeerd kan worden. Het is niet mogelijk om een Inline te definiëren die over de grenzen van een Block heengaat. Deze beperking is het gevolg van de manier waarop tekst in XML wordt gecodeerd. Er kan een onderscheid gemaakt worden tussen een Inline die zelf weer (andere) Inlines kan bevatten (InlineComplexType) en een Inline die alleen tekst mag bevatten (InlineSimpleType). Pagina 14 van 53

15 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI Marker Een Marker is een positie in de tekst waaraan informatie gekoppeld is. Deze informatie staat dan buiten de lopende tekst. In tegenstelling tot een Inline omvat een Marker zelf geen tekst. Een voorbeeld van een Marker is een voetnootreferentie of een afbeelding Globale restricties Er bestaan restricties ten aanzien van de mogelijke samenstelling van de abstracte entiteiten. Het is niet toegestaan om een Inline direct in een Container te plaatsen. Hier moet een Block tussen zitten. Het is ook niet de toegestaan dat Block en Container worden gecombineerd als siblings 2. Met andere woorden: indien een Block als kind van Container wordt gebruikt, dan moeten de andere kinderen van die Container verplicht ook een Block zijn. 3.2 Entiteiten In deze paragraaf wordt een overzicht gegeven van de (niet-abstracte) IMOP entiteiten. Er is gekozen voor een logische onderverdeling (in plaats van een groepering per abstracte entiteit). Details als kardinaliteit worden op deze plaats zoveel mogelijk vermeden Documentniveau [deze paragraaf zal nog veranderen] Er zijn drie concrete klassen die als Document geclassificeerd worden: 1 OfficieelBericht; 2 OfficielePublicatie; 3 Toestand. Ad 1) Een OfficieelBericht wordt door het bevoegd gezag naar de LVBB gestuurd. Een OfficieelBericht kan leiden tot een OfficielePublicatie en/of 1 of meer Toestanden. De meerderheid van IMOP documenttypen leidt alleen tot een OfficielePublicatie, slechts een beperkt aantal documenttypen met RegelingStructuur kan geconsolideerd worden tot een Toestand. Ad 2) Een OfficielePublicatie is een bekendmaking in een officieel goedgekeurd blad volgens de bekendmakingsprocedures die bij dat blad horen. Een OfficieelBericht is nodig voor een OfficielePublicatie. Kenmerkend voor een OfficielePublicatie is dat deze een Container bevat die het publicatieblad representeert, zoals Staatscourant of Gemeenteblad. 2 Een sibling is hier een voorloper of opvolger op hetzelfde niveau; siblings hebben dezelfde ouder. Pagina 15 van 53

16 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER 2017 Ad 3) Een Toestand is het gevolg van toepassing van wijzigingsinstructies in een OfficieelBericht op het moment van inwerkingtreding van die wijzigingsinstructies (consolidatie). Een OfficieelBericht kan leiden tot meer dan 1 nieuwe Toestand. Consolidatie vereist een RegelingStructuur. Entiteit Toestand is een Container die bestaat uit een Metadata Container (verplicht) en een Regeling Container (verplicht) RegelingStructuur RegelingStructuur representeert een Regeling zoals gespecificeerd in Aanwijzingen voor de regelgeving, aanwijzing Een regeling bestaat dan uit een Opschrift, Aanhef, Lichaam, Slotformulier, Ondertekening, en eventuele bijlagen 4. De volgorde van deze entiteiten is relevant. Opschrift Het Opschrift is een omschrijving (titel) van de regeling. Het komt overeen met wat voorheen werd aangeduid als intitulé. Alhoewel het Opschrift veelal bestaat uit een enkele string, is er modelmatig in IMOP een Opschrift Container, die bestaat uit een (1) alinea blok, en pas daarbinnen tekst. Aanhef Een Aanhef bevat inleidende tekst over de regeling, waaronder de considerans. Aanhef is een Container, die een of meer Block(s) bevat (alinea of lijst, geen tabel). Lichaam Een Lichaam is een Container die de hoofdtekst van de regeling bevat. Dit komt overeen met element Regelingtekst in voorlopers van IMOP. Een Lichaam bevat of een tekst volgens artikelstructuur (met optioneel groepering via hoofdstuk, paragraaf, etc.) of een vrije tekst (eventueel geordend via een divisiestructuur). Slotformulier Het Slotformulier bevat afsluitende (procedurele) tekst over de regeling. De Ondertekening bevat zaken als datum en plaats van publicatie, en rol plus naam van de ondertekenaar(s). Beide voorgaande entiteiten worden gecombineerd tot een entiteit RegelingSluiting. Dit is een Container. Bijlage De entiteit Bijlage is een Container die één of meer Blocks bevat. Dit kunnen tabellen, afbeeldingen, of tekst zijn. Let op: er zijn twee soorten bijlagen binnen IMOP. Binnen de Regeling gaat het om bijlage(n) die formeel tot de regeling behoren (en dus ook op hetzelfde niveau bindend zijn). Buiten Regeling (dus in Nawerk) gaat het om toelichtende bijlagen. 3 Omdat een toestand niet in een publicatieblad wordt gepubliceerd, is er hier geen noodzaak voor een publicatieblad-entiteit. 4 In de aanwijzingen voor de regelgeving wordt Opschrift, Lichaam etc. met kleine letter geschreven. Binnen IMOP is de conventie aangehouden dat klassenamen met een hoofdletter worden geschreven. Pagina 16 van 53

17 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 Er bestaat een verschil tussen OfficielePublicatie en Toestand voor wat betreft de inhoud van Regeling. Bij Toestand zijn de aanhef en de regeling-sluiting niet relevant, en binnen Lichaam is informatie over was-wordt voor een Toestand niet relevant (die is immers dan reeds gebruikt bij de totstandkoming van de toestand). Binnen OfficielePublicatie is was-wordt informatie juist wel relevant voor die publicaties die als basis voor een toestand dienen. In hoofdstuk 7 Muteren en consolideren wordt hier nader op ingegaan Artikel Een artikel is een bepaling in een regelgevend document, bijvoorbeeld een wet, een regeling of een verdrag. Het artikel is bedoeld om een concrete regel te geven op het laagste niveau van de regeling Deel, Hoofdstuk, Titel, Afdeling, en Paragraaf Indien het aantal artikelen toeneemt dan kan omwille van de toegankelijkheid gekozen worden voor een groepering van artikelen. In aanwijzing 3.56 van de Aanwijzingen voor de regelgeving wordt hier nader op ingegaan: 2 Bij een verdeling op één niveau worden de onderdelen hoofdstuk of paragraaf genoemd. 3 Bij een verdeling op twee niveaus worden de onderdelen van het eerste niveau hoofdstuk en de onderdelen van het tweede niveau paragraaf genoemd. 4 Bij een verdeling op meer dan twee niveaus worden de onderdelen in volgorde van omvang deel, hoofdstuk, titel, afdeling en paragraaf genoemd, met dien verstande dat in ieder geval de aanduidingen hoofdstuk en paragraaf worden gebruikt. In lijn met bovenstaande aanwijzingen zijn er binnen het IMOP entiteiten aangemaakt voor Afdeling, Boek, Deel, Hoofdstuk, Paragraaf en Titel. Deze entiteiten worden in IMOP geclassificeerd als Structuurelement. Bij de definitie van de entiteiten zelf zijn bovenstaande regels uit aanwijzing 3.56 niet gevolgd, maar via IMTP kunnen ze aangezet worden binnen een bepaald toepassingsprofiel. Het is belangrijk om te benadrukken dat er een essentieel verschil qua semantiek is tussen een Artikel en de Structuurelementen. Het artikel is de kern: hier staan de bepalingen (de tekst) en dit is de eenheid van wijziging. De groeperingen zijn optioneel, en worden geacht geen of louter redactionele tekst te bevatten (bijvoorbeeld Dit hoofdstuk is vervallen ) Lid Een Artikel bevat een kop en daarnaast een keuze tussen vrije tekst (in de vorm van Block(s)) of een of meer Lid entiteiten. De vrije tekst kan bestaan uit alle soorten Blocks. Een lid is genummerd en bevat tekst 6. Aangezien vrije tekst binnen een artikel ook een lijst kan bevatten en de lijstitems ook genummerd zijn kan verwarring 5 Zie (recht). 6 De aanwijzingen voor de regelgeving zijn aanmerkelijk beperkter dan de praktijk (zie aanwijzing 3.58). IMOP laat meer toe dan 1 alinea, maar kan via IMTP alsnog aanwijzing 3.58 implementeren indien dit voor een bepaald documenttype gewenst is. Pagina 17 van 53

18 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER 2017 ontstaan met leden. In de praktijk is een opsomming veelal gecombineerd met één of meer alinea s. In zo'n geval moet het om vrije tekst gaan in plaats van Lid omdat buiten de leden geen alinea's mogen staan. De toegestane Block elementen binnen Artikel bevat tekst, optioneel gemengd met Inline elementen. Hiervoor mogen de algemeen beschikbare Inline elementen toegepast worden (zoals nadruk) maar is ook de specifieke Inline volzin beschikbaar Wijzig-Artikel en Inwerkingtreding-Artikel Een regelgevend document kan naast algemene artikelen ook artikelen bevatten die specifiek bedoeld zijn voor het wijzigen van een bestaande regeling, of het inwerking laten treden van een bepaling of wijziging in een ander artikel. Hiervoor zijn de Was- Word-Mutatie entiteiten beschikbaar die nader worden beschreven in het hoofdstuk Muteren en consolideren VrijeTekstStructuur VrijeTekstStructuur bevat een generieke structuur om teksten te structureren. Het is te vergelijken met de manier waarop een tekstverwerker als Word teksten vastlegt, met algemene opties als sectie, kop, niveau, alinea etc. Het grootste verschil tussen RegelingStructuur en VrijeTekstStructuur zit in het aantal specifieke containers dat gedefinieerd is. In de RegelingStructuur zijn betekenisvolle containers als Aanhef, Sluiting en Lichaam gedefinieerd. Deze ontbreken in de VrijeTekstStructuur. Voor de hiërarchische structurering is alleen de recursieve Divisie beschikbaar. Om toch inhoudelijke informatie over de structuur vast te leggen is op containers, alinea s, inlines etc. een eigenschap class beschikbaar om eventueel een inhoudelijke of hiërarchische betekenis toe te kennen Gedeelde klassen Een aantal tekstuele klassen kan zowel in RegelingStructuur als in VrijeTekstStructuur voorkomen Tabellen Een tabel is een Block. Hierdoor kunnen tabellen (als siblings) gecombineerd worden met alinea s, lijsten en afbeeldingen binnen een Container. Het IMOP ondersteunt het CALS-model voor tabellen 7. Omwille van de interoperabiliteit is gekozen voor het CALS Exchange Table Model 8. In afwijking op voorlopers wordt binnen het IMOP ook het HTML-tabel model ondersteund. Het betreft hier de implementatie zoals deze is opgenomen binnen XHTML 1.0 Strict. Deze elementen worden net zoals bij Akoma Ntoso niet in de XHTML namespace opgeslagen formeel zijn het dus pseudo XHTML-elementen Lijsten Er zijn diverse typen lijsten beschikbaar in IMOP. 7 Zie 8 Zie Pagina 18 van 53

19 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 Lijst Een Lijst is geclassificeerd als een Block. Deze keuze is met name gebaseerd op de manier waarop lijsten in de tekst worden gebruikt. Lijst is geclassificeerd als BlockContainerVirtueelType omdat het sterk lijkt op een Container (lijsten zijn potentieel recursief en tekst zit nooit op lijstniveau maar altijd binnen Lijst-items). Begrippenlijst Een Begrippenlijst is een specifieke vorm van een Lijst die gericht is op het coderen van een lijst met definities. Een Begrippenlijst bevat één of meer Begrip entiteit. Deze bestaan uit een (optioneel) volgnummer, een term en een definitie Overige aandachtspunten Vormgeving Vormgeving is een onderwerp dat afgehandeld wordt door IMTP. In toepassingsprofielen wordt aan de hand van concepten uit het Presentatiemodel ('VSOP' in het PID) gespecificeerd hoe content eruit komt te zien. Voor het informatiemodel is de vraag wel relevant in hoeverre vormgeving leidt tot extra eigenschappen of relaties. De enige plaats waarbij vormgeving zichtbaar wordt bij de klassen zijn de eigenschappen class en style die op ieder Block en Container klasse optioneel gebruikt mogen worden. Het eerste attribuut kan gebruikt worden om vormgevingsklassen te definiëren die in een toepassingsprofiel worden ingevuld. Met het tweede attribuut kan rechtstreeks 1 of meer geldige CSS waarde worden gekoppeld. Het is de bedoeling dat style alleen in uitzonderingssituaties nodig Werkingsgebied Werkingsgebied is een relatietype dat een verbinding legt tussen een Block, Container of Inline en een geografische Locatie. Dit wordt in hoofdstuk 5 nader toegelicht Implementatie (XML) klassen Bij de realisatie van het informatiemodel IMOP als XML is in een aantal gevallen een element toegevoegd aan de XML dat geen betekenis heeft in IMOP. Dit is gedaan om makkelijker met de XML te kunnen werken. Het gaat onder meer om de volgende gevallen: Metadata element; Inhoud element; Locaties element. In de IMOP XSD wordt via annotaties aangegeven of en wanneer een element een echt IMOP element is of een XML hulpconstructie of implementatieklasse Identificatie Alle elementen binnen het IMOP hebben een optionele identifier. In een toepassing kan het gebruik van de identifier verplicht gesteld worden voor een of meer elementen. Ook kunnen in een toepassing eisen worden gesteld aan de vorm van de identifier (bijvoorbeeld een GUID). 9 Zie Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification Pagina 19 van 53

20 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER Bijlage Er zijn diverse soorten Bijlagen in IMOP. In de eerste plaats zijn er twee soorten tekstuele Bijlages: formeel binnen de Regeling en niet-formele bijlage binnen het Document. Het is daarnaast ook mogelijk om een externe resource als bijlage mee te sturen met een OfficieelBericht. Dit heet een externe bijlage. Een externe bijlage is niet of hooguit via een verwijzing gekoppeld aan de lopende tekst 3.3 Overzicht Een volledig overzicht van de mogelijk entiteiten onder Container, Block en Inline staat in onderstaande figuren. Tekstfragment Inline IntRef ExtRef Aanhaling Lijsteitemnummer Figuur 3 Tekstklasse Inline Pagina 20 van 53

21 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 Regeling Lichaam Metadata Uitspraak Nawerk Toelichting Inhoudsopgav e Sluitung Bijlage Aanhef Regelingopschrift Tekstfragment Container Begrip Redactioneel Artikel Div isie Boek Deel Hoofdstuk Titel Afdeling Paragraaf Lid Figuur 4 Tekstklasse Container LijstAanhef Block Lijstitem Tabel Citaat Alinea Figuur Lijst Begrippenlijst Bron Bijschrift Figuur 5 Tekstklasse Block Pagina 21 van 53

22 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER Geo-informatie Geoinformatie geeft antwoord op de ruimtelijke vraag waar beleid of wetgeving van toepassing is. Alle tekstfragmenten kunnen een werkingsgebied hebben, ofwel direct gekoppeld, ofwel via de hiërarchie van de tekst afgeleid van bovenliggende structuurelementen. 4.1 Uitgangspunten bij modellering van imop:locatie Voor het beschrijven van de geografische component van het IMOP maken we gebruik van de NEN3610 standaarden Een imop:locatie kan niet los van tekst bestaan De relatie imop:werkingsgebied koppelt tekst aan een imop:locatie. Dat wil zeggen dat er middels geometrie niets anders dan locatiegegevens of specifiek locatiegebonden gegevens worden geduid. Dat betekent dat: Een imop:locatie altijd aan een tekst is gekoppeld; Er geen informatie bij een imop:locatie is opgenomen die niet in de tekst wordt geduid (een tekst als waarde zoals opgenomen bij het werkingsgebied is ook een tekstduiding); Potentiële conflicten tussen de geo-standaarden en de onderdelen tekst en semantiek in dit document opgelost worden met als uitgangspunt dat tekst leidend is (de NEN3610 standaarden beschrijven vele aspecten van het geowerkveld) Geometrie is gebiedsgericht Tekst heeft een relatie met een gebied in de werkelijkheid. Voor de ruimtelijke representatie van dat gebied wordt gebruik gemaakt van een vlak 10 (en dus geen punt of lijn). Ruimtelijke informatie wordt daarmee ruimtelijk bevraagbaar en integreerbaar. Voorbeeld: als rondom een windmolen in een straal van 500 meter niet gebouwd mag worden, is de imop:locatie van het imop:werkingsgebied een cirkel met een straal van 500 meter en niet een puntobject met daarbij de verboden bouwafstand als kenmerk Koppeling tussen tekst en geometrie Imop:Locaties zijn zelfstandige objecten met een eigen identiteit. Ze kunnen meervoudig worden gebruikt door tekstobjecten. Verwijzing naar een imp:locatie gebeurt via zijn identifier Semantiek van geometrie Het geometriemodel is zo eenvoudig mogelijk. De inhoudelijke betekenis wordt geregeld in de tekst. Het is echter voor visualisatie en ruimtelijke bevraging nodig om imop:locaties te kunnen classificeren. Ook voor de vraag waar mag wat is dit noodzakelijk. Een koppeling met inhoudelijke of semantische gegevens is daarom nodig. 10 Of een volume in 3D. Pagina 22 van 53

23 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI Geometriemodel Alle identificeerbare imop:structuurelementen kunnen een eigenschap imop:werkingsgebied hebben. Dit imop:werkingsgebied bestaat uit een aantal objecten van het type imop:locatie. Imop:Locatie is een GeoObject volgens de NEN3610 standaard. Een imop:locatie bevat alleen geometrie-specifieke informatie zoals de coördinaten en metadata over die coördinaten, zoals bijvoorbeeld de nauwkeurigheid. Andere eigenschappen zijn gekoppeld aan de tekst. Er zijn vier sub-klassen van een imop:locatie: - imop:locatieomschrijving - imop:locatieverwijzing - imop:geometrie - imop:locatiegroep. Zie ook paragraaf imop:locatieomschrijving Bij een imop:locatieomschrijving wordt de locatie in de tekst door een tekstuele omschrijving geduid, bijvoorbeeld Het Koninkrijk der Nederlanden. In dit geval is niet de expliciete geometrie van het gebied opgenomen, omdat deze bekend wordt geacht imop:locatieverwijzing Bij sommige besluiten wordt een werkingsgebied gebruikt waar elders de exacte geometrie is vastgelegd (in een ander besluit of in een basisregistratie). In dit geval kan enkel een verwijzing opgenomen worden opgenomen naar de plaats waar de geometrie wel is vastgelegd. Discussie: Deze klasse sorteert voor op een nieuwe vorm van een besluit dat een Locatie definieert die in andere besluiten gebruikt kan worden; zolang hier geen duidelijkheid over is zal deze klasse niet gebruikt worden imop:geometrie Bij een imop:geometrie wordt expliciet de geometrie van de locatie opgenomen met coördinaten. Een imop:geometrie kan een verwijzing naar een bron hebben. Deze verwijzing naar een bron is te gebruiken om veranderingen te signaleren, bijvoorbeeld: wanneer een imop:geometrie is gekopieerd van een BAG-pand en aan dat pand verandert iets in de BAG dan verandert niet automatisch de imop:geometrie, de coördinaten zitten namelijk onveranderlijk in het besluit. Door de link naar de bron op te nemen is het wel mogelijk te signaleren dat er iets veranderd is in de geobrongegevens imop:locatiegroep Als laatste is er de mogelijkheid om locaties te groeperen, dit geeft de mogelijkheid om regels die over een groep gebieden gaat te verwoorden Pagina 23 van 53

24 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER Gebruik van GML voor codering van geometrie Geometrie, coördinaten, worden uitgewisseld in Geography Markup Language (GML), ook bekend als ISO Voor codering van geometrie biedt GML een breed scala aan geometrietypes. Hier zijn ook exotische types bij die nuttig zijn binnen bepaalde toepassingsdomeinen maar die daarbuiten niet door software ondersteund worden. Deze paragraaf gaat in op de keuze voor geometrietypes, die voor de omgevingswet nodig zijn GML en GML 3.3 De GML 3 standaard is modulair opgezet. De verschillende geometrietypes zijn ondergebracht in modules. De standaard GML 3.3 is een uitbreiding op standaard GML en voegt een aantal modules toe GML profielen Door de modulaire opzet van de GML 3 standaard is het mogelijk om GML profielen samen te stellen, specifiek voor een beoogde toepassing. Software ontwikkelaars hoeven daardoor alleen dat deel van de standaard te implementeren dat ook daadwerkelijk gebruikt wordt. Voor verschillende toepassingen zijn er al profielen in omloop. Deze werkwijze sluit goed aan bij de gedachte achter IMOP en TPOD. De IMOP standaard sluit aan op GML 3.3. Voor de verschillende omgevingsdocumenten wordt in ieder geval een simpel 2D-profiel voorzien en op langere termijn is ook een 3D-profiel nodig.: Voor 2D-geometrie: GML Simple Feature Profile is een bestaand GML profiel dat door de meeste GIS software standaard te verwerken is. Voor veel toepassingen is dit voldoende. Voor 3D-geometrie: Sommige onderdelen van de omgevingswet maken gebruik van 3D-geometrietypen. Hiervoor moet een 3D profiel ontwikkeld worden. In de toepassingsprofielen wordt aangegeven welk GML profiel volstaat. Pagina 24 van 53

25 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI Data In de voorgaande hoofdstukken is ingegaan op entiteiten die de lopende tekst en geografische informatie representeren. In dit hoofdstuk wordt nader ingegaan op de entiteiten binnen IMOP ten behoeve van aanvullende informatie. Het betreft hier enerzijds atomaire objecten en anderzijds samengestelde objecten. Deze worden via eigenschappen aan lopende tekst objecten gekoppeld. 5.1 Data Onder data wordt hier verstaan: gegevens die geen onderdeel zijn van de lopende tekst maar wel gekoppeld worden aan die lopende tekst. Een klassiek voorbeeld van data is documentaire metadata, zoals een titel, identifier, etc. die aan het document zijn gekoppeld. IMOP ondersteunt documentaire metadata en hanteert hiervoor een generieke aanpak die breder inzetbaar is. Het is niet alleen mogelijk om informatie aan documentniveau te koppelen, maar aan ieder IMOP object. Bovendien ondersteunt IMOP niet alleen atomaire waarden (string; uri) maar ook complexe samengestelde objecten. De combinatie hiervan maakt IMOP geschikt om relatief complexe use cases te ondersteunen. Geo (in het vorige hoofdstuk) kan worden gezien als een bijzondere vorm van data bij een lopende tekst Atomaire objecten Een atomaire object is een imop:waarde met een bijbehorend type. Voor het type wordt gebruik gemaakt van een subset van de XML Schema datatypes 11 : xs:string (default); xs:date; xs:decimal; xs:anyuri; In aanvulling op deze vier datatypen ondersteunt IMOP ook twee specifieke referentiedatatypen: imop:literalref en imop:objectref. Met de eerste wordt de mogelijkheid geboden om een verwijzing op te nemen naar een tekstfragment in hetzelfde document. De laatste biedt de mogelijkheid om een verwijzing op te nemen naar een object in hetzelfde document Klasse imop:object De klasse imop:object representeert een ongeordende set van imop:eigenschap objecten. Een imop:eigenschap fungeert als key-value paar, waarbij de value een atomaire waarde kan zijn, een samengesteld object of een reeks van atomaire waardes / samengestelde objecten. Doordat een object weer als waarde een object kan hebben, is het mogelijk om waarden een willekeurige diepte te geven (recursie) Klasse imop:reeks De klasse imop:reeks representeert een geordende reeks van 0, 1, meer Waarde, Object of Reeks objecten. 11 Zie Pagina 25 van 53

26 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER Relatie tussen lopende tekst en data Data kan binnen IMOP niet op zichzelf bestaan maar moet gekoppeld worden aan een Document of lopende tekst klasse. Deze koppeling wordt gerealiseerd via een getypeerde relatie. Het idee is dat via IMTP nieuwe relatietypen kunnen worden afgeleid en toegepast binnen 1 of meer documenttypen. IMOP klassen hebben een beperkt aantal ingebouwde eigenschappen, zoals id, class, en style. Dit betreft in zekere zin "systeemeigenschappen". In aanvulling daarop biedt het toepassingsprofiel de mogelijkheid om 1 of meer eigenschappen toe te voegen. Dit leidt dan tot een (van IMOP) afgeleide klasse met de systeemeigenschappen en de nieuw gedefinieerde eigenschappen. Dit mechanisme wordt nader uitgelegd in de IMTP specificatie, en valt als zodanig buiten de scope van dit hoofdstuk. Modelmatig loopt de koppeling tussen IMOP klassen via een Uitspraak klasse. Een Uitspraak is een klasse die een binaire relatie representeert tussen een IMOP object en een waarde object zoals gespecificeerd in de vorige paragraaf. Ieder Uitspraak object heeft verplicht de eigenschap "eigenschap". Deze waarde is het relatietype. De rollen van de IMOP klasse en waarde object worden niet apart vastgelegd. Uitspraak komt in de XML serialisatie terug als Uitspraak element. Alhoewel een Uitspraak over ieder IMOP object kan gaan, is er in de serialisatie voor gekozen om Uitspraken alleen toe te staan binnen Metadata containers. Deze zijn toegevoegd aan Document, Artikel en Structuurelement elementen. In die gevallen is het onderwerp van de Uitspraak gelijk aan de ouder van het Metadata element waartoe het Uitspraak element behoort (dus bijvoorbeeld een Artikel). Voor de overige IMOP klassen moet gebruik worden gemaakt van het optionele "onderwerp" attribuut op het Uitspraak element. De waarde van dit attribuut is dan de id waarde van het IMOP object in de XML van een Lid). 5.3 Juridische betekenis van data Juridisch gezien is bepalend hetgeen zichtbaar is voor het bevoegd gezag op het moment dat zij een besluit neemt. Dit wordt de primaire verbeelding genoemd. Voor publicaties in de Staatscourant is dit bijvoorbeeld momenteel de PDF/a versie die aan eisen van de Bekendmakingswet voldoet. Vuistregel is dat als informatie in het besluit nodig is om de primaire verbeelding te genereren, dat deze dan juridisch gezien - belangrijker is dan informatie die niet nodig is bij het genereren van de primaire verbeelding. De lopende tekst zal over het algemeen integraal terecht komen in de primaire verbeelding. Voor data die geen onderdeel van de lopende tekst is, is dit minder eenduidig. Dit hangt af van de regels die gebruikt worden om de primaire verbeelding te genereren. Het is dus denkbaar dat data alleen een gebruiksdoel dient verder in de keten, maar het is ook mogelijk dat data gebruikt wordt in de primaire verbeelding. Dit wordt bepaald door het toepassingsprofiel, en het is dus een IMTP vraag die verder niet op deze plaats beantwoord hoeft te worden. Pagina 26 van 53

27 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI Relatie met RDF en JSON RDF is een datamodel waarin zogeheten triples centraal staan. JSON is een datamodel en serialisatie dat een meer traditionele aanpak met dictionary en array objecten heeft. Beiden zijn niet erg geschikt voor het werken met tekst. Er is daarom in IMOP voor gekozen om een aantal principes over te nemen zonder de suggestie te willen wekken dat er volledige ondersteuning is. Hierdoor zal het wel mogelijk worden om op relatief eenvoudige wijze JSON en / of RDF te genereren uit IMOP. Pagina 27 van 53

28 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER Identifiers Identifiers zijn aanduidingen die verwijzen naar exact 1 object. Identifiers vervullen vrijwel letterlijk een sleutelrol bij het uniek en eenduidig verwijzen naar officiële publicaties en onderdelen daarvan. In dit hoofdstuk wordt nader ingegaan op de vraag welke identifiers nodig zijn voor officiële bekendmakingen en onderdelen daarvan. Tevens wordt aandacht gegeven aan de vraag hoe identifiers worden toegekend. Identifiers bepalen onder andere waarnaar verwezen kan worden. Omgekeerd zijn niet alle verwijzingen ook identifiers. Dit verschil is essentieel. Juriconnect is een standaard voor verwijzingen naar (onderdelen van) wetgeving, maar geen standaard voor identificatie. Een verwijzingsstandaard geeft meerdere mogelijkheden om naar één object te verwijzen, terwijl een identificatiestandaard bepaalt hoe een object geïdentificeerd wordt. Met Juriconnect kun je bijvoorbeeld alle dagen binnen een geldigheidsperiode van één versie van een regeling gebruiken om naar die versie te verwijzen. Maar deze versie heeft bij voorkeur maar 1 identifier. 6.1 Identificatie van documenten IMOP is een model voor officiële bekendmakingen die als document 12 gepubliceerd worden. Ieder IMOP document moet uniek identificeerbaar zijn. Omwille van rechtszekerheid en gerelateerde juridische overwegingen moet een eenmaal uitgegeven identifier ook voor altijd gekoppeld blijven aan hetzelfde object. Implicatie is dat een nieuwe versie van een officiële bekendmaking een andere identifier krijgt toegewezen zelfs wanneer er maar een komma is veranderd. Maar ook alle versies tezamen ("de Grondwet") willen we kunnen identificeren FRBR Alhoewel het bij versies om twee verschillende identifiers gaat ze moeten immers uniek zijn is het wel wenselijk om de logische samenhang van deze versies zichtbaar te maken. Dit veronderstelt dat er een logisch model wordt gemaakt waarin versies een rol spelen. Voor officiële bekendmakingen is in dit kader inspiratie opgedaan bij het IFLA FRBR model. Conform FRBR wordt een onderscheid gemaakt tussen Work, Expression, Manifestation en Item de zogeheten Group 1 entities. 12 Document is hier bewust nog niet nader gedefinieerd. IMOP definieert verschillende begrippen waarmee documenten op verschillende wijzen worden gemodelleerd. Pagina 28 van 53

29 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 Figuur 6 Het FRBR-model en imop FRBR is een generiek raamwerk dat onafhankelijk is van het soort documenten. Het kan dan ook op alle domeinen toegepast worden. Het idee van FRBR is dat abstracte verzamelingen worden gebruikt om documenten te ordenen. Deze abstracte verzamelingen krijgen een identifier. Dit werkt in de praktijk als volgt. Stel bijvoorbeeld dat er een Staatscourant publicatie stcrt pdf is gemaakt. In FRBR termen is de publicatie van die pdf op stcrt pdf een Item een concreet voorkomen van een officiële bekendmaking. Het direct bovenliggende niveau in FRBR is dat van de manifestation. Een Manifestation is een verzameling Items die op dezelfde manier zijn opgemaakt. Dit komt meestal overeen met mediatype zoals PDF versus HTML, maar het kan PDF volgens spec1 en PDF volgens spec2 zijn. In het voorbeeld leidt dit tot een Manifestation genaamd stcrt pdf. Weer een niveau hoger gaat het om verzamelingen met dezelfde informatie (versie) ongeacht de verschijningsvorm. In FRBR termen zijn dit Expressions. Het idee hierachter is dat het niet uitmaakt of een document als PDF of als HTML is gepubliceerd, zolang de inhoud maar gelijk is. In het voorbeeld leidt dit tot een Expression 1 (voor eerste versie), die gevuld is met 1 Manifestation genaamd pdf. Het FRBR Work niveau bundelt een aantal gerelateerde versies (Expressions). Het idee hierachter is dat een versie nog steeds een uitdrukking is van hetzelfde achterliggende idee, ook al zijn er (kleine) wijzigingen. In het voorbeeld is het Work dan de Staatscourant publicatie ongeacht versie en ongeacht verschijningsvorm. Dit Work bestaat hier uit 1 Expression. Binnen IMOP worden twee hoofdcategorieën van werken onderscheiden: de bekendmaking van regelingen en de consolidatie van in werking getreden regelingen. Een bekendmaking kan leiden tot wijziging van een werkende regel. Consolidatie van die bekendmaking leidt tot een nieuwe versie van de werkende regel die toestand wordt genoemd. Bekendmaking en consolidatie zijn in IMOP dus twee verschillende Works. De relatie tussen beide Works wordt gelegd via metadata. Het Work dat de bekendmaking representeert, zal meestal uit slechts 1 Expression bestaan. Dit is de Versie op een bepaalde datum van publicatie. Van iedere versie wordt minimaal 1 Manifestation gemaakt: de weergave als authentieke bron. Pagina 29 van 53

30 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER 2017 Zeker bij langer lopende wetgeving is de kans groot dat het Work dat de geconsolideerde regelgeving representeert uit meerdere Expressions bestaat. Iedere Expression heeft een unieke combinatie van datum inwerkingtreding en zichtdatum. Een Expression is het gevolg van 1 of meer bekendmakingen. Iedere toestand heeft minimaal 1 Manifestation. Bovenstaand voorbeeld kan nader worden verduidelijkt door aan te geven wat er gebeurt bij publicatie van een herdruk van stcrt pdf. Volgens de systematiek van wordt dit een Item genaamd stcrt n1.pdf. Dit Item leidt tot een nieuwe versie, genaamd 2. Deze Expression wordt geplaatst onder het bestaande Work (als tweede Expression). Het Item wordt geplaatst in een Manifestation pdf binnen de nieuwe Expression 2. Identifiers voor Work, Expression, Manifestation en Item moeten uniek zijn binnen de scope van het bovenliggende niveau. Met andere woorden: identifiers van Expressions moeten uniek zijn binnen het Work waartoe ze behoren, identifiers van Manifestations moeten uniek zijn binnen de Expression waartoe ze behoren, en identifiers van Items moeten uniek zijn binnen de Manifestation waartoe ze behoren. Aangezien er geen bovenliggend niveau voor Work is, moeten Work identifiers globaal uniek zijn. Door identifiers op verschillende niveaus te combineren kan elk niveau globaal uniek geïdentificeerd worden. 6.2 Globale identifiers Voor identifiers die globaal uniek moeten zijn maakt imop gebruik van http-uris. Door gebruik te maken van een domein dat in handen is van degene die de http-uri uitgeeft en aan een resource toekent (ook wel het "munten" genoemd) zijn deze URIs globaal uniek. De URIs voor documenten hebben een vast patroon waarvan de onderdelen in de loop van deze tekst steeds verder worden uitgewerkt. Het hoofdpatroon van een http-uri van een document is: {globale identificatie} = identificatie} https Https wordt in toenemende mate de standaard om op een betrouwbare manier informatie op te vragen. Aangezien de URI, naast de primaire functie van identificatie van een resource, tevens de functie heeft om informatie over een resource op te vragen, ligt het voor de hand om officiële publicaties met https-uris te identificeren {domein} Beslissing PR04: Het domein van de LVBB is "regelgeving.overheid.nl". Mogelijke bedenking: Valt enkel regelgeving binnen STOP? Ook parlementaire informatie, raadsinformatie en bijvoorbeeld rechterlijke uitspraken kunnen met STOP gepubliceerd worden. Het domein van de LVBB is "regelgeving.overheid.nl". Dit domein wordt beheerd door KOOP. Pagina 30 van 53

31 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 Dus STOP URIs beginnen met: identificatie} {context} De {context} heeft het volgende patroon: {context} = {soort}[/{blad}][/{bevoegd gezag}] {soort} De {soort} geeft aan of het document een publicatie in een publicatieblad betreft of een consolidatie. Soort Publicatie in publicatieblad Consolidatie {soort} "publ" "cons" {blad} Elk {blad} heeft een eigen kenmerk: Collectie {soort} {collectie} Tractatenblad "publ" "trb" Staatsblad "publ" "stb" Staatscourant "publ" "stcrt" Provinciaal blad "publ" "prb" Waterschapsblad "publ" "wsb" Gemeenteblad "publ" "gmb" Blad gemeenschappelijke regeling "publ" "bgr" De bladen hebben dus de volgende URIs: Tractatenblad: Staatsblad: Staatscourant: Provinciaal blad: Waterschapsblad: Pagina 31 van 53

32 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER 2017 Gemeenteblad: Blad gemeenschappelijke regeling: De consolidatiecollecties hebben de volgende URIs {bevoegd gezag} De context van Tractatenblad, Staatsblad en Staatscourant en het Basis Wetten Bestand (BWB) wordt niet verder gespecialiseerd. Deze publicatiebladen worden niet per bevoegd gezag uitgegeven en ook in het BWB wordt geen onderscheid naar organisatie gemaakt, omdat het voor landelijke regelgeving niet relevant is van welk ministerie een regeling afkomstig is. Anders dan bij de lokale regelingen is bij een herindeling van taken en regelgeving over de ministeries altijd sprake van een omhanging waarbij regelingen niet opnieuw worden gepubliceerd maar alleen sprake is van een verantwoordelijkheidswijziging. De context van de publicatiebladen en consolidatiecollecties van decentrale overheden worden wel nader gespecialiseerd naar bevoegd gezag. De LVBB wijst aan elke publicerende organisatie een kenmerk toe dat wordt opgenomen in de URI. Om de URI enigszins herkenbaar te houden wordt dit kenmerk gebaseerd op de naam van de organisatie. Uitgangspunten voor het organisatiekenmerk zijn: De code bevat enkel de letters a-z. Uit de naam worden hoofdletters omgezet naar kleine letters, diakrieten en andere tekens dan letters a-z worden weggelaten. Homoniemen worden opgelost door een extra onderscheid toe te voegen. Lange kenmerken en homoniemen en dienen te worden vermeden. Voorbeelden: Bevoegd gezag Arnhem Reusel-De Mierden Skarsterlân 's-hertogenbosch Bergen (NH) Bergen (L) Regionale uitvoeringsdienst Zeeland {bevoegd gezag} "arnhem" "reuseldemierden" "skarsterlan" "shertogenbosch" "bergennh" "bergenl" "rudzld" Pagina 32 van 53

33 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 Dit levert de volgende URIs op: Gemeentebladen: Geconsolideerde regelgeving van gemeenten: Blad gemeenschappelijke regeling: Geconsolideerde regelgeving van gemeenschappelijke regelingen: Identificatie van een imop:werk (frbr:work) {lokale identificatie} De {lokale identificatie} heeft het volgende patroon: {lokale identificatie} = [{jaargang}/]{werk}[/{versie}][.{formaat}] {jaargang} De component {jaargang} komt alleen voor bij publicaties in een publicatieblad, niet bij consolidaties en bestaat uit de vier cijfers van het jaar waarin de publicatie plaatsvond {werk} Het werk is het kenmerk dat de LVBB uitgeeft bij publicatie in het publicatieblad of bij de eerste consolidatie van een besluit. 6.4 Identificatie van een imop:versie (frbr:expression) De beschrijving van identificatie van versies is nog gebaseerd op de huidige situatie en kan nog veranderen onder invloed van nieuwe inzichten omtrent muteren/consolideren. Pagina 33 van 53

34 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER {versie} De {versie} duidt de toestand van het document of het onderdeel aan met twee datums aangegeven in W3CDate formaat (jjjj-mm-dd): {versie} = {datum geldigheid}/{datum ontstaan} {datum geldigheid} De {datum geldigheid} is de datum waarop een regeling of een regel van kracht is. Deze datum wordt bepaald door het inwerkingtredingsbesluit. In reguliere gevallen is dit de datum inwerkingtreding, alleen in geval van terugwerkende kracht is de datum geldigheid gelijk aan de datum tot wanneer het besluit terugwerkt. De datum wordt geschreven volgens de specificaties van de datum-component van W3C DateTime: "jjjj-mm-dd", bijvoorbeeld " " {datum ontstaan} De {datum ontstaan} is de datum waarop de toestand in juridische zin is ontstaan, aangegeven in W3Cdate formaat. Dit is de datum waarop de bekendmaking van de inwerkingtreding van het wijzigingsbesluit heeft plaatsgevonden. In de regel is dit ook de datum waarop de consolidatie administratief wordt doorgevoerd, maar dat zou ook op een latere datum kunnen plaatsvinden. Deze laatste datum is juridisch echter niet relevant. De {datum ontstaan} wordt gebruikt om na te gaan of een toestand in juridische zin 'zichtbaar' is op een bepaalde datum (de 'zichtdatum' die in Juriconnect wordt gebruikt). 6.5 Identificatie van een imop:formaat (frbr:manifestation) {formaat} Het {formaat} wordt aangegeven door een punt, gevolgd door een extensie op basis van het bestandsformaat. Dus ".html", ".pdf", ".xml". Dit zal nog nader worden uitgewerkt, aangezien alleen een extensie waarschijnlijk niet zal voldoen. 6.6 Identificatie van onderdelen van officiële publicaties Deze paragraaf zal nog wijzigen onder voortschrijdend inzicht rond muteren/consolideren. Een versie van een officiële publicatie bestaat altijd uit een hoofddocument en potentieel uit een aantal bijlagen. Deze onderdelen worden in Akoma Ntoso "components" genoemd. De bijlagen zijn onderdeel van de imop:formaten (frbr:manifestations) van een imop:werk. Dus ook als een bijlage in twee versies niet veranderd is, wordt deze logisch gezien als twee aparte objecten beschouwd, die ieder een eigen identifier hebben. Pas op item niveau wordt geoptimaliseerd voor efficiënt ruimtegebruik. De kern van ieder IMOP document is de tekst zoals die door het bevoegd gezag wordt vastgesteld. Deze tekst is een sequentiële opvolging van tekens. Aan tekst wordt Pagina 34 van 53

35 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 machineleesbare betekenis toegekend door middel van codering via tags, zoals bijvoorbeeld de start- en sluittags <aanhef> en </aanhef> rondom de tekens die de aanhef vormen. De gecodeerde tekst vormt de eerste schil rondom de kern. Vervolgens worden uitspraken over gecodeerde tekst gedaan. Dit is de tweede schil. De hiërarchische structuur van de lopende tekst wordt door de codering machineleesbaar. Een regeling bevat onder meer een lichaam, en die bevat mogelijk weer hoofdstukken, en die bevatten weer artikelen, etc. Er is sprake van deel geheel relaties waarbij het deel op zijn beurt vaak ook weer de rol van geheel speelt in de volgende deel geheel relatie. Dit gaat behoorlijk diep, soms tot wel 10 niveaus. Aan alle onderdelen van de deel-geheel relaties kan een identifier toegekend worden. In feite is dit een uitwerking van een eigenschap die het hoofdstuk Datamodel is gedefinieerd. Een minder eenvoudige vraag is welke vorm de identifier moet aannemen. De keuze is tussen een betekenisloze string, een leesbare (betekenisvolle) string of een mengvorm van beiden. Een leesbare identifier kan bijvoorbeeld lijken op een Juriconnect verwijzing met enkele toevoegingen die uniciteit garanderen. Juriconnect 1.31 kan nu niet alle objecten uniek identificeren. Gezien de nadelen wordt ook gekeken naar de mogelijkheden van een volledig betekenisloze identifier voor onderdelen. Omwille van eenvoud van verwerking in XML moet de waarde van de identifier een XML NCName zijn. Bij IMOP worden de additionele restricties gedefinieerd dat louter kleine letters en cijfers gebruikt mogen worden. Hierdoor is een IMOP onderdeel-identifier nog steeds een geldige XML NCName Het FRBR-patroon toegepast op onderdelen Bij de identificatie van documenten is gebruik gemaakt van FRBR om onderscheid te maken tussen identificatie van een werk en van versies van een werk. Hetzelfde principe kun je toepassen op onderdelen van documenten, bijvoorbeeld artikelen. In verschillende versies van een document kunnen verschillende versies van 'hetzelfde' artikel voorkomen. En het biedt ook voordelen dat een artikel dat in een nieuwe versie van het document niet verandert, herkenbaar is aan dezelfde identifier. Ook in uitzonderingsgevallen, waarin artikelen een andere nummeraanduiding krijgen, maar niet inhoudelijk wijzigen, wil je kunnen aangeven dat het om dezelfde expressie van hetzelfde artikel gaat. Om te bepalen of er sprake is van 'hetzelfde' artikel (equivalentie) kunnen we een algoritme opstellen. De simpelste variant hiervan is een letterlijke vergelijking van de tekst. Er is echter meer dan tekst alleen. De eigenschap imop:werkingsgebied is overerfbaar bij artikelen en structuurelementen. Voor equivalentie moet dan dus mogelijk ook eerst de overerving toegepast worden. Open punt: Ook moet het effect van deel geheel relaties nader gedefinieerd worden. Betekent het invoegen van een artikel dat er een nieuw hoofdstuk ontstaat? Betekent het wijzigen van de tekst van een artikel dat het omvattende hoofdstuk verandert? En het wijzigen van een lid binnen een artikel? Pagina 35 van 53

36 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER Algoritme IMOP ondersteunt meerdere algoritmes voor de bepaling van equivalentie van onderdelen. 1 ID1: alleen vergelijking letterlijke tekst 2 ID2: vergelijking tekst en werkingsgebied (geometrie) 3 ID3: vergelijking tekst, werkingsgebied (geometrie) en metadata ID1 Het algoritme ID1 neemt de tekst van een onderdeel mee in de overweging maar niet werkingsgebied en metadata. De definitie wat precies de tekst van een onderdeel is, kan verschillen. Het algoritme werkt als volgt: 1 Voor ieder artikel geldt dat de tekst bestaat uit alle tekst binnen artikel start- en sluittags. Vervolgens wordt de volgende procedure uitgevoerd: a Maak een UTF-8 Unicode string door concatenatie van alle XML tekst nodes uit (.//text()); b Bereken SHA1 hexdigest voor de concetanatie van work-id, een underscore, en de string uit a) (resulterend in digest met hexadecimale tekens); c Neem de rechter 10 posities van de hexdigest uit b). 2 Voor ieder hoofdstuk, paragraaf, deel, titel, afdeling, regeling-tekst (lichaam): a Maak een UTF-8 Unicode string door concatenatie van alle XML tekst nodes uit de eigen kop (./kop//text()) en de kop van de niet-kop kinderen./[localname()!='kop']/*/kop//text() b Bereken SHA1 hexdigest voor de concatenatie van work-id, een underscore, en de string uit a) (resulterend in digest met hexadecimale tekens); c Neem de rechter 10 posities van de hexdigest uit b). 3 Voor ieder ander onderdeel: gebruik de procedure in 1) ID2 Het algoritme ID1 neemt de tekst van een onderdeel mee en het in het onderdeel aanwezige of geërfde werkingsgebied mee in de overweging, maar niet eventuele metadata uitspraken. De definitie wat precies de tekst van een onderdeel is, kan verschillen. Het algoritme werkt als volgt: 1 Voor ieder artikel geldt dat de tekst bestaat uit alle tekst binnen artikel start- en sluittags. Vervolgens wordt de volgende procedure uitgevoerd: a Indien het artikel geen werkingsgebied heeft (via een kindelement werkingsgebied), dan wordt het eerste werkingsgebied element gekopieerd van de ancestor van het artikel element; b Bereken een versie id voor inhoud van werkingsgebied; Hiervoor moet bekeken worden of dit canoniek te maken is of dat het via een toegekende versie-uitspraak kan (zonder naar de inhoud te kijken). c Maak een UTF-8 Unicode string door concatenatie van alle XML tekst nodes uit (.//text()); d Bereken SHA1 hexdigest voor de concetanatie van work-id, een underscore, de string uit c), een underscore, en het versie-id uit b) (resulterend in digest met hexadecimale tekens); Pagina 36 van 53

37 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 e Neem de rechter 10 posities van de hexdigest uit d). 2 Voor ieder hoofdstuk, paragraaf, deel, titel, afdeling, regeling-tekst (lichaam): a Indien het artikel geen werkingsgebied heeft (via een kindelement werkingsgebied), dan wordt het eerste werkingsgebied element gekopieerd van de ancestor van het artikel element; b Bereken een versie id voor inhoud van werkingsgebied Hiervoor moet bekeken worden of dit canoniek te maken is of dat het via een toegekende versie-uitspraak kan (zonder naar de inhoud te kijken). c Maak een UTF-8 Unicode string door concatenatie van alle XML tekst nodes uit de eigen kop (./kop//text()) en de kop van de niet-kop kinderen./[localname()!='kop']/*/kop//text() d Bereken SHA1 hexdigest voor de concetanatie van work-id, een underscore, de string uit c), een underscore, en het versie-id uit b) (resulterend in digest met hexadecimale tekens); e Neem de rechter 10 posities van de hexdigest uit d). 3 Voor ieder ander onderdeel: a Maak een UTF-8 Unicode string door concatenatie van alle XML tekst nodes uit (.//text()); b Bereken SHA1 hexdigest voor de concetanatie van work-id, een underscore, en c de string uit a) (resulterend in digest met hexadecimale tekens); Neem de rechter 10 posities van de hexdigest uit b) ID3 Deze tekst wordt nog verder uitgewerkt. 6.7 Het proces van toekenning van identifiers Het toekennen van identifiers is een belangrijke processtap. Op het moment van uitgifte moet de identifier uniek zijn in de afgesproken scope. En een eenmaal uitgegeven identifier kan niet nog een keer uitgegeven worden. Ook ontstaan er vragen wat er gebeurt wanneer een uitgegeven identifier niet wordt gebruikt. In principe zijn er twee modellen: centrale uitgifte en decentrale uitgifte. Het eerste model is het makkelijkst te implementeren. Er is 1 plaats waar identifiers worden uitgegeven. Hierdoor kan eenvoudig worden gecontroleerd dat een identifier nieuw en uniek is. In een decentraal model kunnen identifiers op meerdere plaatsen uitgegeven worden. Dit kan bijvoorbeeld door iedere uitgever een eigen bereik te geven waarbinnen de uitgever vrij is. Het is ook mogelijk om een mengvorm te implementeren. Het inrichten van het proces van toekenning van identifiers en de keuzes die in dat kader gemaakt moeten worden, valt buiten de scope van dit verhaal. Hieronder worden enkele systemen genoemd die een rol zullen spelen bij de toekenning van identifiers De LVBB De Landelijke Voorziening Bekendmaken en Beschikbaar stellen (LVBB) is uitgever van de officiële publicatiebladen en van de geconsolideerde regelingen. De LVBB is ook het Pagina 37 van 53

38 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER 2017 register voor officiële publicaties dat op het moment van publiceren de identifiers toekent aan de publicaties (bekendmakingen en consolidaties) en hun onderdelen. Voorzien wordt dat de LVBB de bladen voor officiële bekendmaking zal publiceren op het adres De bladen zijn: Het Tractatenblad; Het Staatsblad; De Staatscourant; De gemeentebladen; De provinciale bladen; De waterschapsbladen; De bladen gemeenschappelijke regeling. Ook publiceert de LVBB collecties met geconsolideerde regelgeving, waaronder: Het BasisWettenBestand (BWB) op De Centrale Voorziening voor Decentrale Regelgeving (CVDR) op Deze collecties munten een http-uri voor elke publicatie. 6.8 Relatie met andere standaarden voor identificatie Er zijn meerdere bestaande standaarden voor identificatie waar rekening mee gehouden wordt bij het opstellen van de specificaties van imop. Net als bij het kiezen van termen in de imop vocabulaire, wordt ook voor de identifiers voor imop een eigen specificatie opgesteld. Door rekening te houden met standaarden voor alternatieve identifiers blijft omzetting naar andere manieren van identificatie mogelijk. Er lopen nog discussies over de mate waarin internationale standaarden gevolgd worden en waar voor nationale optimalisaties gekozen wordt Akoma Ntoso/LegalDocMl Akoma Ntoso 13, ook wel LegalDocMl genoemd, en afgekort tot AKN, is een standaard van OASIS voor het gebruik van XML in juridische documenten. IMOP neem veel principes over uit AKN, met name het belangrijke principe dat het model gebaseerd is op het FRBR-framework 14. Verder wordt AKN gevolgd waar mogelijk en uitgebreid waar nodig. Identifiers in imop zijn zo kort mogelijk met enige herkenbaarheid. Akoma Ntoso kent een uitgebreider URI-patroon (AKN spreekt bovendien van IRIs) dat meer informatie bevat over het document dat geïdentificeerd wordt en waarin een keur aan leestekens gebruikt wordt. De AKN-IRI van een frbr:work volgt het volgende patroon: [base URL]/akn/[country]/[type]/[subtype]/[emanating actor]/[creation date]/[disambiguating feature] Een aantal elementen wordt niet in de imop identifier opgenomen, omdat ze niet noodzakelijk zijn voor unieke identificatie: Pagina 38 van 53

39 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 akn [country] [sub-type] [language] Een AKN-IRI van een frbr:expression volgt het volgende patroon: [work identifiers];[content specification date];[content authoring information] In de imop-identifier worden niet opgenomen: [language] Om de interoperabiliteit zo goed mogelijk te houden worden de gebruikte tekens in een URI zo veel mogelijk beperkt. Imop gaat uit van URIs, niet van IRIs. En imop gebruikt geen "!", ";" en dergelijke zoals AKN dat wel doet. Deze tekens vormen allemaal potentiële struikelblokken als identifiers tussen applicaties uitgewisseld worden ELI identifiers ELI 15 staat voor European Legislation Identifier. ELI is een model om identificatie van wet- en regelgeving van nationale en lokale overheden in Europa waar mogelijk te standaardiseren. KOOP is ELI-coördinator voor Nederland en beheert ELI-nl, het Nederlandse toepassingsprofiel van ELI. Het ELI-programma ondersteunt momenteel onvoldoende het FRBR-model zoals dat is geïmplementeerd in de publicatiesystemen van KOOP en de functionaliteit van terugwerkende kracht. Bruikbare concepten uit het ELI model worden wel overgenomen zodat implementatie van ELI niet onnodig wordt gecompliceerd Juriconnect-standaarden De Juriconnect 16 -standaarden voor logische links naar wet- en regelgeving zijn gebaseerd op de huidige systematiek van identificatie van deze publicaties. Bij de keuzes die voor IMOP gemaakt moeten worden bij identificatie van officiële publicaties wordt rekening gehouden met de huidige wijze van identificeren, zodat implementatie van Juriconnect niet onnodig wordt gecompliceerd Pagina 39 van 53

40 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER Muteren en consolideren Het onderdeel muteren en consolideren betreft het geautomatiseerd samenstellen van de toestanden van geconsolideerde regelingen op basis van consolidatie informatie die in een besluit of mutatie ligt besloten. Op hoofdlijnen is bekend hoe dit mechanisme moet verlopen en welke informatie daarvoor nodig is dit is in een proof of concept geverifieerd die is uitgevoerd door het projectteam dat verantwoordelijk is voor STOP samen met het projectteam dat verantwoordelijk is voor de LVBB (Landelijke Voorziening voor Bekendmaken en Beschikbaarstellen) Er is op dit moment nog onvoldoende inzicht in een aantal aspecten van het mechanisme om een definitieve beschrijving te kunnen maken. Dit hoofdstuk geeft de stand van dit moment weer. 7.1 Inleiding Het IMOP zoals beschreven in de voorgaande hoofdstukken is opgesteld voor complete toestanden van mededelingen, besluiten en regelingen (zoals omgevingsdocumenten). In een deel van de keten de aanlevering aan LVBB wordt de toestand van een regeling niet direct aangeleverd maar wordt een mutatie gestuurd die aangeeft hoe een nieuwe toestand afgeleid kan worden uit een eerder gepubliceerde toestand. De mutatie kan een besluit beschrijven dat de regeling instelt, wijzigt of intrekt. Maar een mutatie kan ook een andere wijziging betreffen, bijvoorbeeld de beschrijving van het gevolg van een rechterlijke uitspraak. In dit hoofdstuk wordt beschreven hoe mutaties hoe mutaties worden beschreven in het model. De mutatie moeten voornamelijk ondersteunend zijn aan het volgende proces: Het bevoegd gezag stuurt een bericht met wijzigingen aan de LVBB. Het bericht is input voor de LVBB om bekendmaking te maken (als de mutatie een besluit beschrijft). Het bericht is input voor LVBB om nieuw toestanden van de geconsolideerde regeling te maken. Het is nog niet helemaal duidelijk welke mutatiescenario s er zijn en welke informatie voor een scenario door het bevoegd gezag aan LVBB aangeleverd moet worden. Dit heeft tot gevolg dat de beschrijving in dit hoofdstuk nog niet definitief is en nog zal wijzigen. Dit hoofdstuk bestaat uit de volgende onderdelen: Uitgangspunten Voor het proces en het model is een aantal uitgangspunten gehanteerd. Deze zijn voortgekomen uit ervaring, architectuur en beleid. Proces Het proces is leidend bij het modelleren van de mutaties. Voor een goed begrip van het model is allereerst een goed begrip van het te ondersteunen proces noodzakelijk. Model Beschrijving van het model. Pagina 40 van 53

41 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI Uitgangspunten Voor muteren en consolideren zijn de volgende uitgangspunten gebruikt. 1 Bevoegd gezag en LVBB a Een bevoegd gezag werkt in een eigen systeem om nieuwe regelingen op te stellen en bestaande regelingen te wijzigen. b Nieuwe regelingen en besluiten die leiden tot wijzigingen op bestaande regelingen moeten bekend gemaakt worden. Dit gebeurt door publicatie op officielebekendmakingen.nl. Daarnaast moet ook de geconsolideerde regeling beschikbaar worden gesteld. Het bevoegd gezag stuurt daartoe een mutatie naar de Landelijke Voorzieningen voor Bekendmaken en Beschikbaarstellen (LVBB), die voor de verdere verspreiding zorgt. c Het bevoegd gezag stuurt ook een mutatie aan de LVBB wanneer een wijziging in de geconsolideerde regeling aangebracht moet worden die niet het gevolg is van een besluit. Bijvoorbeeld de consequenties van een rechterlijke uitspraak. 2 Toestanden en berichten a Het bevoegd gezag werkt in het eigen systeem met toestanden van de regeling Het interne wijzigingsproces bestaat dus uit het maken van een nieuwe toestand van de regeling. b Het bericht dat het bevoegd gezag aan de LVBB stuurt bij een wijziging van een regeling bevat alleen het gewijzigde deel. Het systeem van het bevoegd gezag leidt deze wijziging af uit het verschil tussen de nieuwe en de oude toestand. c Als de mutatie een besluit beschrijft, dan maakt de LVBB op basis van de mutatie een bekendmaking en publiceert deze op officielebekendmakingen.nl d De LVBB maakt op basis van het bericht en de oude toestand die reeds aanwezig was de nieuwe toestand. Deze wordt vervolgens beschikbaar gesteld. Opmerkingen ad 1) De LVBB kan niet alleen besluiten bekendmaken, maar kan ook mededelingen en kennisgevingen publiceren. Het mechanisme van muteren en consolideren heeft is daarvoor niet relevant omdat deze geen wijzigingen op andere gepubliceerde (voor een ieder toegankelijke) documenttypen beschrijven. ad 2a) Vanuit STOP wordt niet voorgeschreven hoe een intern systeem van een bevoegd gezag moet werken. De enige eis is dat de berichten die worden aangeleverd voldoen aan de specificaties. Echter, bij het opstellen van de specificaties is uitgegaan van de beschreven situatie. ad 2b) Regelingen kunnen erg omvangrijk worden; denk bijvoorbeeld aan een omgevingsplan. Daarom worden alleen de wijzigingen doorgegeven. ad 2c) De verbeelding van bekendmakingen, besluiten en regelingen is beschreven in het Presentatiemodel (VSOP) 17 van de STOP standaard. In dit hoofdstuk is nog geen rekening gehouden met informatie die voor het verbeelden van de mutaties noodzakelijk is. ad 2b / 2c) Voor het opstellen van het besluit is meer nodig dan alleen de wijzigingen in de regeling. Onder andere de motivering bij het besluit, maar ook 17 Het presentatiemodel heette in het PID nog Verbeeldingsstandaard Officiële Publicaties, vandaar de afkorting VSOP. Pagina 41 van 53

42 Visies & plannen Juridische / Awb procedure INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER 2017 zaken als de intitule, considerans, ondertekening etc. Deze worden uiteraard niet allen bepaald door het systeem. Deze moeten aangevuld worden door het bevoegd gezag. ad 2c / 2d) De LVBB zal bij het valideren van het besluit ook nagaan dat alle resulterende toestanden van de geconsolideerde regeling samengesteld kunnen worden. Als dat laatste niet mogelijk is, zal de LVBB het besluit niet accepteren voor bekendmaking. 7.3 Proces Referentie procesmodel wijzigingsbesluiten In het proces rondom muteren en consolideren zijn zowel het bevoegd gezag als de landelijke voorziening betrokken. Globaal ziet dat er als volgt uit. Overheden Berichtenverkeer LVBB ROD DSO Overheid.nl etc Verbeelding van besluit 3 Besluit Besluit 4 Besluitproces- & consolidatie informatie Validatie / Registratie Besluit Verbeelding van besluit / bekendmaking Bekendmakingen & DSO 6 Onveranderlijke weergave Verbeelding van regeling Toestand (oud) Toestand (nieuw) Toestand (nieuw) Verbeelding van regeling Wetten- en regelingenbank & DSO 1 Synchronisatie Blauw = opgesteld door gebruiker Geel = afgeleid door software (evt met hulp van gebruiker) Groen = toepassing van standaard 1. Ophalen geldende versie. Als het een wijziging betreft en de software van het bevoegd gezag beschikt nog niet over de meest recente versie/toestand van de regeling, dan haalt de software die op bij de LVBB. NNTB hiervoor kan het mutatiemechanisme of een vergelijkbaar gebruikt worden. 2. Opstellen/aanpassen van de regeling Medewerkers maken op basis van een eerder bekendgemaakte versie een nieuwe versie waarin de beoogde wijzigingen zijn aangebracht. Betreft het een nieuwe regeling, dan maken medewerkers de initiële versie. 3. Opstellen en goedkeuren besluit Het bevoegd gezag moet een formeel besluit nemen over de wijziging. De beschrijving van de wijzigingen wordt door software bepaald; de medewerkers Pagina 42 van 53

43 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 vullen dat aan met bijvoorbeeld een motivatie voor het wijzigen van de regeling. 4. Valideren/registreren van het besluit Na goedkeuring zal het besluit ter bekendmaking aan de LVBB worden verstuurd. Onderdeel van het bericht is de mutatie zoals door IMOP wordt beschreven. 5. Samenstellen geconsolideerde regeling Als onderdeel van de validatie van een besluit zal de LVBB de geconsolideerde regeling samenstellen. De LVBB voert geen consolidatie uit maar gebruikt de informatie uit de mutatie om de versie van de regeling samen te stellen. Als dit niet mogelijk is, of als de geconsolideerde regeling niet aan de gestelde eisen voldoet (zoals vermeld in de STOP standaard en in het toepassingsprofiel voor de regeling), dan wordt het besluit als niet valide beschouwd en kan het niet bekendgemaakt worden. 6. Bekendmaken van het besluit De LVBB zorgt ervoor dat het besluit bekendgemaakt wordt. Pas na bekendmaking van het besluit kan de inhoud ervan (en de nieuwe toestand van de geconsolideerde regeling) in werking treden. De LVBB zorgt er ook voor dat zowel het besluit als de regeling verder verspreid worden. Zo zijn de omgevingsdocumenten na de bekendmaking beschikbaar voor het DSO. 7. Synchronisatie door andere systemen Na validatie en registratie van het besluit (dus nog voor de bekendmaking) zal via het aanleverkoppelvlak een notificatie verstuurd worden aan bevoegd gezagen die (mede-)bronhouder zijn van het besluit en/of de resulterende regelingen dat nieuwe versies beschikbaar zijn. De besluiten en regelingen zijn ook op te halen. Een gedetailleerde beschrijving van dit proces is opgenomen in de documentatie van het Aanleverkoppelvlak van de LVBB Toestanden en berichten In uitgangspunt 2a wordt gesteld dat het bevoegd gezag in het interne systeem werkt met toestanden en dat het bericht met de mutaties door het systeem wordt afgeleid. In deze paragraaf wordt aan de hand van voorbeelden toegelicht hoe dat proces globaal verloopt. Los van het informatiemodel (dit document) worden richtlijnen opgesteld die exact beschrijven hoe het model gebruikt kan worden in elke situatie Achtereenvolgende wijzigingen In dit voorbeeld gaan we ervan uit dat het wijzigingsproces van een bevoegd gezag bestaat uit een lineaire opeenvolging van wijzigingen. Dat wil zeggen dat er pas aan een nieuwe wijziging wordt gewerkt als de vorige volledig is afgerond en in werking is getreden. Verder gaan we er vanuit dat wijzigingen niet met terugwerkende kracht in werking treden en dat besluiten van het bevoegd gezag nooit worden aangepast (gedeeltelijke / volledige vernietiging) door een rechter. Kortom, de meest ideale situatie. In latere voorbeelden zullen we zien dat het in de praktijk niet altijd zo werkt. Pagina 43 van 53

44 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER 2017 In onderstaande figuur staan de toestanden die het bevoegd gezag in haar interne systeem heeft gemaakt. De figuur toont 4 toestanden. De opeenvolging van de toestanden is aangegeven met de pijlen. De gestippelde pijlen aan het begin en het eind geven aan dat dit slechts een gedeelte is van de alle toestanden van de regeling. Binnen de figuur heeft het bevoegd gezag 3 maal besloten de regeling te wijzigen (van A naar B, van B naar C, van C naar D). Dat betekent dus ook dat het bevoegd gezag 3 maal een bericht heeft verstuurd aan de LVBB. Om het voorbeeld wat sprekender te maken gaan we het invullen met echte wijzigingen. Uitgangspunt in toestand A is, dat de regeling bestaat uit 3 artikelen: Artikel 1, Artikel 2 en Artikel 3. In onderstaande figuur zijn de verschillende toestanden ingevuld. Het bevoegd gezag heeft de volgende aanpassingen doorgevoerd: Van A naar B: Artikel 2 is gewijzigd. Van B naar C: Artikel 4 is toegevoegd. Van C naar D: Artikel 3 is verwijderd. Pagina 44 van 53

45 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 Het bevoegd gezag heeft steeds de regeling aangepast om een nieuwe toestand te maken. Vervolgens moet het systeem de mutaties door gaan geven aan de LVBB. Let op: dat gaat normaal om en om. Dat wil zeggen: het bevoegd gezag maakt een nieuwe toestand, vervolgens maakt het systeem een bericht, dan maakt het bevoegd gezag weer een nieuwe toestand, etc. In onderstaande figuur zijn ook de berichten ingevuld die het systeem maakt en aan de LVBB verstuurt. Het exacte formaat waarin de wijzigingen worden doorgegeven wordt verderop gespecificeerd Inwerkingtreding In het bovenstaande voorbeeld zijn we ervan uitgegaan dat wijziging met hetzelfde besluit in werking treden. Het komt echter ook voor dat er een apart besluit volgt over de inwerkingtreding van een wijziging. Aan de hand van een voorbeeld lichten we deze situatie verder toe. Het bevoegd gezag besluit een regeling te wijzigen. Onderstaande figuur toont de bijbehorende toestanden en berichten. Pagina 45 van 53

46 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.8 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 1 OKTOBER 2017 Omdat het besluit waarin toestand B is beschreven nog niet in werking is getreden wordt deze in de figuur nog met ronde hoeken afgebeeld. Vervolgens besluit het bevoegd gezag toestand B in werking te laten treden. Juridisch is de vorige zin niet correct: het bevoegd gezag besluit (het deel van) het besluit dat de toestand B beschrijft, in werking te laten treden Hiervoor stuurt het systeem een nieuw bericht aan de LVBB. De figuur toont bericht 2. De mutatie in het bericht beschrijft geen overgang van de ene naar de andere toestand, maar geeft aan dat toestand B die al eerder is doorgegeven in werking treedt. In dit geval is de informatiekundige modellering van het besluit dus anders dan de manier waarop een jurist het besluit zou verwoorden. In de weergave van het besluit (zie de presentatiestandaard) zal het informatiekundige model naar de correcte juridische formulering vertaald worden Terugwerkende kracht Soms moet een wijziging met terugwerkende kracht geldig worden. De wijziging wordt dan niet geldig op het moment dat het besluit in werking treedt, maar wordt per datum inwerkingtreding te gelden vanaf een eerder moment Afhankelijk van hoe ver in het verleden dat moment ligt kunnen er meerdere toestanden nodig zijn in deze situatie. Wanneer de terugwerkende kracht op of na het begin van de huidige toestand ligt is 1 toestand voldoende. Indien deze ervoor ligt zijn meerdere toestanden nodig. Onderstaande voorbeelden illustreren dit. Uitgangspunt zijn onderstaande toestanden A en B. Toestand A is geldt vanaf 1 januari 2017 en toestand B vanaf 1 januari Pagina 46 van 53

47 INFORMATIEMODEL OFFICIËLE PUBLICATIES (IMOP) VERSIE 0.85 STANDAARD OFFICIËLE PUBLICATIES MET SPECIFIEKE TOEPASSING VOOR OMGEVINGSDOCUMENTEN 11 JANUARI 2018 Voorbeeld 1: Het bevoegd gezag bedenkt in mei 2018 dat ze een wijziging willen doorvoeren. Deze had echter al doorgevoerd moeten worden in februari. Het besluit wordt genomen en treedt in werking op 1 juli 2018 met terugwerkende kracht tot en met 1 februari. Op 1 februari was dezelfde toestand geldig als op het moment van inwerkingtreding. De nieuwe toestand volgt daarom op toestand B. Dit is niet anders dan in de eerdere voorbeelden. Voorbeeld 2: Stel dat de wijziging moet terugwerken tot 1 juli van het vorige jaar. Op dat moment was toestand A geldig. Een nieuwe toestand (toestand C1) moet dan ook ontstaan vanuit een wijziging op toestand A. Vanaf 1 januari 2018 is echter toestand B de geldige toestand. Daarom moet er ook een extra toestand (toestand C2) worden gemaakt die ontstaat vanuit een wijziging op toestand B. Het bevoegd gezag geeft deze wijziging waarbij 2 nieuwe toestanden ontstaan door in één mutatie. Pagina 47 van 53