Veelgestelde vragen - STOP/TPOD

1. Ik gebruik wel schemalocaties in de namespace declaraties. Is dat een probleem?

Dat is geen probleem, zolang je hiervoor xsi:schemaLocation op de correcte wijze (spatie-gescheiden "paren" van namespace en schemalocatie) gebruikt. Deze worden dan door de LVBB genegeerd.

2. Element <tekst:Redactioneel> heeft alle tekstmogelijkheden, maar is <tekst:Al> niet al genoeg?

In STOP is “redactioneel” de tekst die niet onderdeel van formele tekst is. Zie ook de definitie van element <tekst:Redactioneel>: "biedt plaats aan notities of opmerkingen die geen onderdeel van de (formele) tekst of structuur uitmaken". Gebruik van dit element is voornamelijk binnen <tekst:RegelingVersie> of <tekst:Toestand>, waarin beschrijvende tekst wordt opgenomen voor een <tekst:Artikel> wanneer deze is vervallen of een wijzigingsbepaling bevat. Als je verder kijkt heeft <tekst:Redactioneel> alle tekstmogelijkheden, dus ook tabel, begrippenlijst etc. Is <Al> niet al genoeg? En eigenlijk daar binnen zelfs alleen maar kale tekst?

STOP heeft met opzet ruime content modellen. De requirements van alle Bevoegd Gezagen moeten met STOP kunnen worden uitgevoerd.

Uit de oorspronkelijke vraag komt de betrokken context niet helemaal goed naar voren. Het zou zo maar kunnen dat <tekst:Redactioneel> voor Omgevingsplannen van de gemeenten inderdaad alleen aan <tekst:Al> voldoende heeft, maar dat voor een ander OW-instrument wel andere mogelijkheden binnen <tekst:Redactioneel> gewenst zijn. Het is daarom zeer de vraag of een voorgestelde beperking van <tekst:Redactioneel> in STOP moet worden opgenomen. Een alternatief zou zijn om een regel hieromtrent in de relevante TPOD's op te nemen.

Het verder beperken van element <tekst:Al> binnen alleen <tekst:Redactioneel> is niet aan te raden. Element <tekst:Al> heeft vanwege consistentie in de gehele broodtekst hetzelfde content model.

3. Zijn er restricties aan de naam van een begrip of bij een locatie (noemer), zoals case sensitief of exacte tekst?

Nee, de letterlijke tekst bij deze elementen is niet van belang.

Herkenbaarheid voor software gaat namelijk op basis van XML-tags en niet op basis van tekstanalyse. Voor een locatie geldt dat de 'noemer' in de lopende tekst binnen een <tekst:IntIoRef> geplaatst moet worden. Zo is er bijvoorbeeld ook geen hoofdletter gevoeligheid voor de tekst zelf, maar wel voor de XML-tags en id's. Het daadwerkelijk linken gebeurt op basis van de id's (attributen @wId en @eId), niet via de tekst.

4. Kunnen we elke begripsbepaling annoteren als begrip met bijbehorende definitie?

In artikel 1.1 van een Omgevingsplan vermelden we begripsbepalingen: een begrip met de uitleg (definitie) daarvan. Kunnen we elke begripsbepaling annoteren als begrip met bijbehorende definitie?

Een begrip kan in de tekst als zodanig worden opgenomen via het element <tekst:Begrip>, maar nog niet via een speciale identificatie, zodat de link met de Stelselcatalogus gelegd kan worden.

  • In "STOP voor Release B" is een manier geïntroduceerd om een <tekst:Begrip> te relateren aan een resource (als annotatie in een aparte STOP-module). Hiermee kan er een relatie gelegd worden tussen begrippen in de Stelselcatalogus en begrippen in de tekst.
  • Begrippen die nog niet elders staan (in de Stelselcatalogus of in een andere catalogus) zullen als Linked Data (de "taal" achter de Stelselcatalogus) gepubliceerd worden via een "LVBB catalogus". KOOP heeft de technologie daarvoor in huis, maar het aan elkaar knopen van de LVBB met de LVBB catalogus wacht nog op verdere specificaties.

5. Kunnen we een begrip zodanig annoteren dat deze verwijst naar het overeenkomstige begrip in een ander artikel?

In sommige artikelen worden begripsbepaling (begrip met uitleg/definitie) in de tekst van het artikel gebruikt. Kunnen we in een artikel het deel van tekst waarin het begrip genoemd wordt (begripsbenaming) zodanig annoteren dat dat verwijst naar het overeenkomstige begrip in een ander artikel?

We interpreteren dit als een manier om in de tekst aan te geven dat een deel van de tekst overeenkomt met een in deze (of in een andere) juridische tekst gedefinieerd begrip. Het is dan gebruikelijk om naar de plaats in de tekst te verwijzen waar het begrip staat. Het is hierbij de intentie om bij het volgen van de verwijzing uit te komen bij de juridische tekst. Binnen de tekst wordt van de ene naar de andere plaats verwezen via de eId. En een begrip heeft een eId, dus dat kan.

6. Is het mogelijk om van een deel van de tekst aan te geven dat het met een begrip overeenkomt?

Is het mogelijk om van een deel van de tekst aan te geven dat het met een begrip overeenkomt, dus een soort hyperlink te maken van de tekst naar het begrip?

Hier gaat het niet zozeer om een verwijzing te maken van een tekst naar de juridische definitie van het begrip, maar om aan te geven dat er elders meer informatie over het begrip te vinden is. Het is hierbij de intentie om bij het verwijzen uit te komen bij de informatie over een begrip, en niet noodzakelijk de plaats waar die in een juridische tekst te vinden is. We hebben binnen STOP hiervoor nog geen keuze gemaakt en zullen dat waarschijnlijk oppakken als we de speciale identificatie** uitwerken. Het ligt voor de hand dat we voor dit soort verwijzingen ofwel <tekst:ExtRef> hanteren, ofwel een gespecialiseerde vorm daarvan (zoals er ook <tekst:ExtIoRef> is voor verwijzing naar een informatieobject).

In "STOP voor Release B" is een manier geïntroduceerd om een <tekst:Begrip> te relateren aan een resource (als annotatie in een aparte STOP-module). Hiermee kan er een relatie gelegd worden tussen begrippen in de Stelselcatalogus en begrippen in de tekst.

7. Als een begrip voorkomt in de Stelselcatalogus, kan daar dan naar verwezen worden?

In artikel 1.1 van een Omgevingsplan vermelden we begripsbepalingen: een begrip met de uitleg (definitie) daarvan. Als een begrip hierin voor komt in de stelselcatalogus, kan daar dan naar verwezen worden? Is het dan niet meer nodig om de uitleg (definitie) op te nemen in dat artikel? Wordt die uitleg dan correct getoond indien iemand in de LVBB het Omgevingsplan raadpleegt? Of moet die definitie expliciet opgenomen worden in het Omgevingsplan?

Het verbinden van een begrip in de tekst met een begrip uit de Stelselcatalogus vereist een manier om een <tekst:Begrip> te relateren aan een resource (als een annotatie) en dat is nu alleen mogelijk in STOP voor release B. In "STOP voor Release B" (STOP 1.4.0) is een manier geïntroduceerd om een <tekst:Begrip> te relateren aan een resource (als annotatie in een aparte STOP-module): de zgn Externe link: Begripsrelatie. Hiermee kan er een relatie gelegd worden tussen begrippen in de Stelselcatalogus en begrippen in de tekst.

Hoe dan ook moet de tekst ook in de OW-besluiten opgenomen worden, omdat de (juridische) formulering anders kan zijn dan de formulering die voor de uitleg van het begrip in de Stelselcatalogus is gebruikt. De LVBB zal zich (als systeem dat de juridische invalshoek van OW-besluiten afdekt) baseren op de teksten in het OW-besluit.

8. Geldt voor STOP/IMOW ook 3 decimalen?

In IMRO mochten de coördinaten tot maximaal 3 posities achter de komma. Bij STOP/IMOW staat daar echter niets over. In voorbeelden wordt zowel 3 als 9 posities achter de komma gebruikt. Geldt voor STOP/IMOW ook 3 decimalen?

Een richtlijn voor het Bevoegd Gezag geeft aan dat coördinaten moeten worden opgegeven tot 3 decimalen. Er is ooit eens vastgesteld dat alles na de vierde decimaal als ruis kan worden bestempeld en niet meegenomen moet worden in de GML bestanden. Afronden van langcijferige coördinaten kan problemen geven met de uniciteit. Opeenvolgende coördinaten mogen niet hetzelfde zijn, anders wordt het een invalide GML-document, en kan het de verwerkende software problemen geven. De kans hierop is niet groot, maar niet nul. Coördinaten met 9 decimalen kunnen gevoeglijk worden afgerond tot 4 significante cijfers achter de komma, om de bestandsgrootte te reduceren.

Die afronding is uiteraard wel een belangrijk punt voor een werkend stelsel. Echter is de STOP standaard niet alleen voor het DSO, maar bijvoorbeeld ook voor internationale zee-verdragen waarin andere regels kunnen gelden. De regel wordt dus niet rechtstreeks door STOP afgedwongen maar is wel vastgelegd in een toepassingsprofiel (TPOD) voor het DSO.

Zie ook Geonovum validatie-en conformiteitsregels.

9. Hoe moeten onderbouwde bijlagen en toelichtingen via de STOP standaard worden meegegeven?

Hoe moet onderbouwde bijlagen en toelichtingen via de STOP standaard worden meegegeven bij Omgevingsplannen? Is dit soortgelijk als bij de waterschapsverordening?

Met de komst van de Omgevingswet worden de bekendmaking van het besluit tot vaststelling of wijziging van een omgevingsplan (nu via DROP) en de publicatie van het omgevingsplan (via IMRO) gebundeld. Dat leidt ook tot een andere verdeling van wat waar gepubliceerd wordt. Onderbouwende bijlagen en toelichtingen gaan in veel gevallen over het besluit (waarom een vaststelling c.q. wijziging gerechtvaardigd is). Dat zal straks via de LVBB op de website officielebekendmakingen.nl terecht komen en worden niet naar DSO-LV doorgestuurd.

Bijlagen en toelichtingen zijn bij voorkeur in een STOP tekstmodel beschreven, maar bijvoorbeeld rapporten van derden kunnen als PDF bestand toegevoegd worden. Het omgevingsplan zoals dat uit het besluit volgt gaat wel naar DSO-LV. Ook toelichtingen op het plan (die dus bij een volgende versie van omgevingsplan aangepast worden, zodat ze blijven aansluiten op de inhoud van het plan) worden doorgestuurd naar DSO-LV.

10. Geldt renvooi ook voor teksten in een lijst of in een tabel?

Ja.

11. Wordt er een formeel ID gegenereerd voor onze omgevingsverordening bij aanbieden aan de LVBB?

Bij IMRO hadden we bij publicatie te maken met een IDN dat we moest vermelden in de bekendmaking/kennisgeving, deze bedachten we zelf (conform IMRO standaard). Voor de publicatie van de Omgevingsverordening via STOP/TP in KOOP zal er ook een formeel identificatienummer voor onze omgevingsverordening zijn. Wordt deze automatisch gegenereerd wanneer we onze omgevingsverordening aanbieden aan de LVBB of is dat iets dat we vooraf ergens moeten meegeven?

Alle identificaties die nodig zijn moeten bij het Bevoegd Gezag (de provincie) aangemaakt worden. Hoe dat exact gebeurt, dient men bij de (software) leverancier na te vragen.

12| Zijn er beperkingen aan het aantal bijlagen m.b.t. structuur en AKN naamgeving?

Nee, er is geen technische limiet aan de diepte van de structuur. Het is mogelijk om meerdere bijlagen op te nemen, ook hier zit geen technische limiet aan.

Bijlagen zijn nu mogelijk bij de Regelingversie en bij de Besluitversie (niet bij een Toelichting), waarbij opgemerkt dient te worden dat:

  • Bijlagen die bij een Regelingversie horen - en die geconsolideerd worden (met later eventuele mutaties als dat nodig is) - worden doorgenummerd (cmp1, cmp2 voor @eId, met prefix voor @wId).
  • Bijlagen die bij een Besluitversie horen worden doorgenummerd (cmp1, cmp2 voor @eId en @wId).

De nummering in het Besluit staat los van die van de Regeling. Een Regelingversie kan dus een (te consolideren) bijlage hebben met een cmp1_*. Als deze Regelingversie onderdeel is van een Besluit kan het Besluit ook een bijlage met cmp1_* hebben.

Opmerking: De @eId en @wId dienen wel uniek te zijn in een Besluit - de combinatie Besluit/Bijlage en Regeling/Bijlage komt voor bij nieuwe regelingen. Een Regeling in dat geval is een "AKN-component" en moet een @componentnaam als attribuut hebben.

13. Wat is de meerwaarde van eId en wId in een sublijst?

Bij het genereren van een sublijst in een lijst ontstaat een lijst-element op "sub-niveau". Dit (sub)lijst-element heeft een eigen eId en wId. Wat is hier de inhoudelijke meerwaarde van? Je kunt immers verwijzen naar het bovenliggende Li. Is die meerwaarde er wel? Of is dit gewoon het gevolg van het feit dat "lijst" als een genest element is opgenomen en op alle niveaus dezelfde attributen kent? En zou het dan denkbaar zijn dat wId en eId op subniveau weggelaten mogen (of moeten) worden?

Dit is een gevolg van de adoptie van de AKN-standaard; dan krijg je ook zaken mee die je misschien niet had willen hebben. Maar we hebben al gezegd dat de eId/wId van elementen binnen een artikel/lid/divisietekst niet behouden hoeven te blijven tussen twee versies, dus generatie van eId/wId bij de export ervan naar STOP is goed genoeg.

14. Hoe moet je omgaan met verwijzingen naar ID's?

Als je wId en eId steeds opnieuw genereert bij publicatie:

  • kun je alleen naar die elementen verwijzen als je zelf een intern ID-systeem aanhoudt, wat bij publicatie wordt omgezet?
  • kun je niet naar die elementen verwijzen als die zijn opgenomen in een ander document of een andere versie van hetzelfde document?

Dat hangt ervan af wat met verwijzen bedoeld wordt. AKN en dus STOP maakt twee manieren van verwijzen mogelijk:

1: Verwijzen naar tekst aan de hand van structuurkenmerken van de tekst.

Bijvoorbeeld naar “Artikel 5” of “Item 3 van de tweede lijst”. Dit is de AKN-ondersteunde manier om vanuit tekst naar andere tekst te verwijzen. Hiervoor wordt de eId van het doel-element gebruikt. Het idee daarachter is dat “item 3” altijd moet verwijzen naar het derde item, ook al is de volgorde van de lijst inmiddels gewijzigd of heeft de inhoud van het lijstitem helemaal niets meer gemeen met het originele item. Dit soort verwijzingen blijven goed gaan, omdat de (steeds opnieuw gegenereerde) eId bij gelijkblijvende tekststructuur steeds hetzelfde zal zijn.

2: Verwijzen naar de inhoud van een tekstelement op een manier die onafhankelijk is van de exacte indeling van de tekst.

Bijvoorbeeld omdat in een tekstelement de definitie staat van “Verwijzing”. Als dat tekstelement ergens anders in de tekst komt te staan bij een volgende versie, dan zou de verwijzing nog steeds naar die definitie moeten wijzen. Dat kan door een verwijzing op basis van wId te maken. Dit wordt door AKN niet als een “van tekst naar tekst”-verwijzing gezien. In STOP (en IMOW en STTR) gebruiken we dit soort verwijzingen meestal om vanuit annotaties/serviceinformatie/… te verwijzen naar tekst. Deze verwijzingen zijn niet mogelijk als de wId steeds opnieuw wordt gegenereerd.

We hebben al een tijd geleden afgesproken dat we accepteren dat verwijzingen van de tweede soort alleen mogelijk hoeven te zijn naar artikelen, divisieteksten en de “grotere” tekstelementen, en dat we accepteren dat dat niet mogelijk is voor lijstitems en andere elementen binnen een artikel/ divisietekst. Het zit in de aard van de AKN-systematiek dat verwijzingen van de eerste soort niet goed gaan als de tekststructuur ingrijpend verandert, dat wordt in de (juridische) wereld niet als een bezwaar gezien (“dan had je de verwijzingen maar moeten bijwerken”).

15. Is InleidendeTekst ook een Divisie in de zin van IMOW?

Is InleidendeTekst ook een Divisie in de zin van IMOW? Dit is belangrijk, omdat het daarmee bijvoorbeeld annoteerbaar is. Ik denk namelijk dat er wel inhoud in inleidende tekst kan zitten. Bijvoorbeeld een inleidend tekstje over stiltegebieden en daaronder paragrafen per stiltegebied met specifieke teksten/kenmerken. Ook de inleidende tekst moet annoteerbaar zijn.

Nee, aan InleidendeTekst kunnen geen IMOW-annotaties gehangen worden.

InleidendeTekst is voor ’navigatie’, aangeven wat er in de nakomende tekst volgt. Niet voor substantiële inhoud. Vanuit STOP adviseren we om dat net iets anders op te schrijven en neem die tekst ook op in een divisie. Overigens wordt het gebruik van InleidendeTekst inmiddels ontraden volgens bedrijfsregels STOP0083 STOP0084.

16. Is de hiërarchie tussen 'Boek', 'Deel', 'Hoofdstuk', 'Afdeling', 'Titel' wel goed in het schema gezet?

Is de hiërarchie tussen 'Boek', 'Deel', 'Hoofdstuk', 'Afdeling', 'Titel' wel goed in het schema gezet? Nu kan een 'Afdeling' een kind 'Boek' hebben. Vanaf 'Paragraaf' is de hierachie wel ingeperkt.

Deze vrijheid zit al sinds lange tijd in STOP (sinds versie 0.98). De bedoeling is dat TPOD's de volgorde en nesting kunnen beperken. STOP is met opzet zo vrij gelaten; dat is nodig voor bijvoorbeeld het Rijk.

17. Wat heeft het voor nut om schemaversie op te nemen als attribuut in verschillende tekst- en data-structuren?

Wat heeft het voor nut om schemaversie op te nemen als attribuut in verschillende tekst- en data-structuren? Dat speelt toch alleen maar een rol bij de aanlevering? Zou er dan een andere schemaversie in kunnen staan als die van de aanlevering?

Attribuut @schemaversie is ook relevant voor losse STOP-modules. De verwachting is dat bij het BG losse modules zullen worden beheerd. In dat geval moet van elke module zijn STOP-versie worden vastgelegd. Zie ook versionering van STOP-modules

We hebben mede naar aanleiding van feedback op een eerdere STOP-versie beschreven hoe de LVBB met schemaversie omgaat.

18. Behoort de directory 'service' ook bij de officiële uitlevering?

Behoort de directory 'service' ook bij de officiële uitlevering? Daarin staan nogmaals de schematrons.

In de map "service" staan de schematrons als XSLT voor gebruik in implementaties die geen schematron (kunnen of willen) ondersteunen.

Voor een uitgebreidere uitleg, zie de index.md

Staat uw vraag niet vermeld?

Mail dan naar stopstandaard@koop.overheid.nl

Zie ook