Informatiemodel voor Toepassingsprofielen (IMTP)

Transcriptie

1 Informatiemodel voor Toepassingsprofielen (IMTP) Versie 0.85 Geonovum - KOOP Datum 11 januari 2018

2 Colofon Documentnaam Projectnaam Projectnummer Versienummer 0.85 Locatie Amersfoort Informatiemodel voor Toepassingsprofiel (IMTP) Standaard Officiële Publicaties met specifieke toepassing voor omgevingsdocumenten PR04 Contactpersoon Eric van Capelleveen Auteurs Paul Janssen (Geonovum) Matthijs Breebaart (KOOP) Gerard Wolbers (Geonovum) Wilko Quak (Geonovum) Hans Overbeek (KOOP) Versie Datum Door Sectie Omschrijving PR04 alles Nieuw document start PR04 alles Oplevering 0.75 (intern) PR04 alles Oplevering versie PR04 alles UML model en IMTP.XSD in sync gebracht Pagina 2 van 36

3 Inhoud Colofon 2 1 Inleiding Toepassingsdomein Normatieve referentie Gerelateerde documenten Omschrijving IMTP Uitgangspunten 7 2 Modelbeschrijving UML model - overzicht Toepassingsprofiel Metadata Conceptueelmodel Implementatiemodel Visualisatiemodel UML model detail Toepassingsprofiel Metadata ConceptueelModel Implementatiemodel Visualisatiemodel 16 3 Objectcatalogus IMTP Objectcatalogus metadata Objecttypes 17 4 Implementatie-encoding Format: Encoding, tekenset, van het TP.XML bestand : Codegeneratie Technische formaten voor implementatie Inleiding Mens-leesbare documentatie voor communicatie TP.pdf TP.html Waardelijsten Machine-leesbare documentatie voor validatie Validatie op tekst Validatie op semantiek Validatie op geo Relaties tussen tekst-semantiek-geo Extra business rules. 21 Bijlage 1: Procesplaat: Van Toepassingsprofiel naar Toepassing 22 Bijlage 2: Handleiding IMTP 23 Pagina 3 van 36

4 1 Inleiding 1.1 Toepassingsdomein Het informatiemodel toepassingsprofiel (IMTP) beschrijft de technische inhoud en structuur van toepassingsprofielen als onderdeel van de Standaard Officiële Publicaties (STOP). Het omvat de elementen die nodig zijn om alle aspecten van de specificaties van de toepassingen van STOP te kunnen genereren en of te refereren. Het is de conceptuele beschrijving van het toepassingsprofielmechanisme. Het IMTP is generiek voor alle STOP toepassingen. Alle toepassingsprofielen hebben daarmee een gelijke structuur. Een conform IMTP opgesteld toepassingsprofiel is een standaard voor een type officiële publicatie met daarin alle binnen het Informatiemodel Officiële Publicaties (IMOP) gedefinieerde eigenschappen over structuur, semantiek en digitale aspecten daarvan. De standaard wordt gebruikt voor het opstellen van een digitale officiële publicatie, definitie van berichtenverkeer en publicatie van een digitale officiële publicatie en daaraan gekoppelde validaties. 1.2 Normatieve referentie Standaard Officiële Publicaties (STOP). Informatiemodel Officiële Publicaties (IMOP). 1.3 Gerelateerde documenten 1.4 Omschrijving IMTP Er is een grote variatie aan documenttypen die aan de Standaard Officiële Publicaties moeten gaan voldoen. Door STOP op te splitsen in een statisch gedeelte (IMOP) en een dynamisch gedeelte (IMTP) ontstaat er een modulair systeem dat de set aan standaarden beheersbaar maakt. Het statische gedeelte legt de structuur van alle officiële publicaties vast, het dynamische gedeelte geeft, binnen de algemene regels van IMOP, specifieke beperkingen en nadere specificering van semantiek die gelden voor een specifiek type officiële publicatie. Het dynamische gedeelte omvat de configuratie waarmee het statische gedeelte geconfigureerd wordt voor een specifieke toepassing. IMTP beschrijft de specificaties voor dit toepassingsprofielmechanisme. Pagina 4 van 36

5 IMOP algemeen statisch restricties en semantiek conform IMTP dynamisch Toepassingsprofiel specifiek per type officiële publicatie Figuur 1: IMOP wordt middels restricties en toegevoegde semantiek verbijzonderd in een Toepassingsprofiel. De algemene use case voor IMTP is een toepassingsprofiel specificeren voor opstellen, uitwisselen en valideren van digitale officiële publicaties. De verschillende onderdelen van dat proces en de relevante producten uit een toepassingsprofiel worden in onderstaand figuur weergegeven Pagina 5 van 36

6 Figuur 2: algemene use case van IMTP en toepassingsprofiel. Het IMOP (1) is de algemene standaard voor digitale officiële publicaties. Het biedt een ontologie waarin de concepten (tekstobjecten, geo-objecten en semantiek) zijn gedefinieerd die als bouwstenen kunnen worden gebruikt in toepassingen voor verschillende typen officiële publicaties. Een dergelijke toepassing van IMOP heet een toepassingsprofiel 1 (2). Een toepassingsprofiel is daarmee de standaard voor een specifiek type officiële publicatie. Elke beschrijving van een toepassingsprofiel van IMOP moet aan de structuur van IMTP voldoen (3). Een toepassingsprofiel heeft drie doelgroepen: Het bevoegd gezag dat officiële publicaties wil doen (BG); De landelijke voorziening die de bekendmaking en consolidatie van de officiële publicatie verricht (LVBB); Afnemers van officiële publicaties (gebruikerstoepassingen). Het bevoegd gezag moet middels de specificaties in een toepassingsprofiel een officiële publicatie kunnen opstellen. De LVBB moet zo'n officiële publicatie kunnen valideren tegen validatiespecificaties op basis van een toepassingsprofiel alvorens bekend te kunnen maken en te consolideren. De gebruikerstoepassingen moeten de semantiek uit de officiële publicaties kunnen interpreteren en vertalen naar functionaliteit. Voor software-ontwikkelaars is een toepassingsprofiel de basis voor ontwikkeling van applicaties, o.a. voor ondersteuning van bovenstaande processen. Generatie van artefacten. Een toepassingsprofiel is een xml document gestructureerd conform IMTP. Dat document zelf bevat nog niet de concrete producten of artefacten die operationeel ingezet worden, maar wel alle informatie op basis waarvan deze gegenereerd kunnen worden. Deze te genereren artefacten zijn onder te verdelen in vier groepen: de metadata van een specifiek profiel, een mens-leesbare versie van het profiel (4) genaamd conceptuele beschrijving, een machine-leesbare versie: het implementatiemodel; en de visualisatie-specificaties voor verbeelding van tekst en geometrie. Metadata: Omvat alle gegevens voor de context en interpretatie van het toepassingsprofiel. Conceptuele beschrijving (4): Alle gegevens om een conceptuele en mens-leesbare versie (in pdf of html) van het toepassingsprofiel te genereren. Implementatiemodel: Alle gegevens voor het genereren van machine-leesbare specificaties voor opstellen (5) en valideren (6) van een officiële publicatie. Visualisatie-specificaties: Alle gegevens voor het genereren van afspraken over verbeelding van een officiële publicatie. Het toepassingsprofiel en de onderdelen daarvan bevatten de gegevens waarmee afgeleide producten gegenereerd kunnen worden. Er is dus nog een bewerking nodig 1 Het eerste Toepassingsprofiel van IMOP is TPOD, het ToepassingsProfiel voor OmgevingsDocumenten. TPOD geeft specificaties voor officiële publicaties die door de Omgevingswet als omgevingsdocument zijn gesteld. Pagina 6 van 36

7 om van een toepassingsprofiel bruikbare specificaties te maken voor bijvoorbeeld leesbare documentatie, visualisatie-afspraken, validatie. In bijlage 1 is in een procesplaat weergegeven hoe het proces verloopt van een toepassingsprofiel opgesteld in tekst en uml naar een toepassing daarvan in een officiële publicatie. 1.5 Uitgangspunten Voor het ontwikkelen van het IMTP gelden de volgende algemene uitgangspunten: - IMTP bevat alle modelspecificaties voor het opstellen van een toepassingsprofiel op IMOP; - Een toepassingsprofiel bevat alle specificaties voor het opstellen en valideren van een officiële publicatie; - IMTP ondersteunt zowel mens- als machineleesbaarheid. Het machine leesbare gedeelte is leidend in de normatieve beschrijving; - IMTP ondersteunt de modulaire opbouw van de STOP standaard. Dit is gebaseerd op een statisch deel IMOP en een dynamisch deel dat als restrictie op IMOP is geformuleerd; - IMTP ondersteunt middels de modulaire opbouw een flexibele toepassing van de STOP standaard in applicaties conform IMOP en middels een toepassingsprofiel daaraan toegevoegde configuratie van restricties en semantiek; - Een toepassingsprofiel hoeft niet alle concepten uit het IMOP te gebruiken; Een toepassingsprofiel kan alleen nadere beperkingen, en dus geen uitzonderingen, maken op de manier waarop concepten uit het IMOP worden gebruikt. Bijvoorbeeld nadere beperkingen aan kardinaliteit of waardebereik; - Met een toepassingsprofiel kunnen de artefacten worden gegenereerd die de implementatie- en validatiespecificaties van een officiële publicatie omvatten; - Implementatie van IMTP is gebaseerd op open standaarden; - Artefacten die uit een toepassingsprofiel gegenereerd worden zijn gebaseerd op open standaarden. Pagina 7 van 36

8 2 Modelbeschrijving Dit hoofdstuk beschrijft het informatiemodel IMTP als een gestructureerde verzameling van alle informatieobjecten en de relaties daartussen op conceptueel niveau. Dit wordt gedaan middels een UML-klassediagram. Dit diagram zal in eerste instantie een overzicht tonen van de hoofdindeling. In de volgende hoofdstukken zullen de onderdelen apart worden toegelicht. Op basis van deze conceptuele beschrijving wordt er op implementatie niveau een xml schema gerealiseerd, zie hoofdstuk UML model - overzicht In deze paragraaf is het UML klassediagram van IMTP opgenomen op hoofdlijn. 1 Metadata::Metadata 1 bevat Toepassingsprofiel bevat 1 Conceptueelmodel:: Conceptueelmodel 0..1 bevat bevat 1 Implementatiemodel:: Implementatiemodel 1 bevat importeert 1 Visualisatiemodel:: Visualisatiemodel 0..1 bevat bevat bevat 0..* Module::Module Figuur 3: Basisonderdelen van een Toepassingsprofiel Toepassingsprofiel Het toepassingsprofiel omvat alle informatie en is opgebouwd uit vier onderdelen: metadata, conceptueelmodel, implementatiemodel en het visualisatiemodel. Een Toepassingsprofiel kan een module importeren. Modules worden gebruikt om standaardfunctionaliteit te groeperen en beschikbaar te stellen voor hergebruik. Een module heeft dezelfde structuur als een toepassingsprofiel. Pagina 8 van 36

9 2.1.2 Metadata Het metadata-element legt informatie over het toepassingsprofiel vast. Het bevat de informatie over het type officiële publicatie, de versie, opsteller, eigenaar, status e.d Conceptueelmodel Het conceptueelmodel bevat de gegevens voor generatie van een mens-leesbaar document met de conceptuele beschrijving van het toepassingsprofiel. Hierin wordt in tekst en UML-klassediagrammen de structuur en semantiek van een specifiek toepassingsprofiel beschreven. Hierin bevindt zich ook een objectcatalogus. Deze laatste wordt gegenereerd vanuit het implementatiemodel Implementatiemodel In dit deel is de informatie opgenomen voor het genereren van implementatiespecificaties voor toepassing van het profiel voor het opstellen, valideren en uitwisselen van officiële publicaties. De volgende functionaliteit is in het implementatiemodel opgenomen. Het legt van alle gebruikte objecttypen vast: met welk element in het IMOP ze overeenkomen; hoe ze geïmplementeerd worden; of er extra eigenschappen aan toegekend worden; of er restricties op het IMOP element zijn. Het implementatiemodel en het conceptueelmodel beschrijven beide het model maar elk met een ander doel: machine-leesbaarheid versus mens-leesbaarheid. Het implementatiemodel is daarbij leidend in de normatieve beschrijving Visualisatiemodel Het visualisatiemodel legt vast hoe tekstuele en geometrische elementen weergegeven worden. Verbeelding geometrie: In een toepassingsprofiel worden verbeeldingsregels van geometrie vastgelegd in een SLD. Dit zijn de verbeeldingsregels die gebruikt worden voor de Officiële Bekendmaking van een besluit. <in ontwikkeling> Deze verbeeldingsregels worden in mens-leesbare tekst en ook in machine-leesbare vorm vastgelegd. Het is de bedoeling dit in te richten op een manier die vergelijkbaar is met de huidige wijze van bestemmingsplannen. Punten van aandacht hierbij: SLD is niet ontwikkeld voor duurzame verbeelding. Om er zeker van te zijn dat de verbeelding duurzaam is zijn extra waarborgen nodig. Zoals bij PDF een speciale PDF-a standaard is ontwikkeld voor tekst richten we ons op het verduurzamen van SLD. Omdat deze route ook bij ruimtelijke plannen is gevolgd verwachten we veel werk te kunnen hergebruiken. Een SLD beschrijft verbeelding in termen van geo-objecten. Deze zijn wel gecodeerd in de digitale versie van een besluit maar moeten er nog wel uitgehaald worden om bruikbaar te zijn. De uiteindelijke oplossing bevat dus een transformatie van digitale versie van een besluit naar een tussenformaat waarop het SLD wordt toegepast. Pagina 9 van 36

10 Het integreren van de achtergrondkaart in een besluit is een resulteert in zeer grote bestanden en ook bijvoorbeeld verbeeldingsregels moeten dan worden vastgelegd voor de achtergrondkaart. Oplossing: in de bekendmaking van een besluit wordt altijd een topografische basisregistratie als achtergrond gebruikt en alleen de naam en datum van de kaart maken onderdeel uit van het besluit. Deze basisregistraties bieden voldoende waarborg om ervoor te zorgen dat de kaart weer gereproduceerd kan worden. Achtergrond wordt voor een deel ook gebruikt om nauwkeurigheid van de getekende gebieden aan te duiden Als een werkingsgebied is getekend op een achtergrond van schaal 1: dan heeft het geen zin om in te zoomen tot een schaal van 1:500 om te kijken of een bepaalde boerderij nu wel of niet binnen ene profiel past. Door in de verbeeldingsregels maximale zoomlevels vast te leggen is de intentie van het bevoegd gezag goed vast te leggen. </in ontwikkeling> 2.2 UML model detail In de volgende paragrafen is per deelonderwerp van het IMTP het UMLklassediagram met alle informatie-elementen opgenomen Toepassingsprofiel Basis::Toepassingsprofiel bevat 1 Metadata:: Metadata 1 importeert bevat 0..* Module::Module Het element Toepassingsprofiel wordt beschreven door metadata en heeft optioneel een referentie naar een module die geïmporteerd wordt. Een module heeft dezelfde structuur als een toepassingsprofiel en bevat een bundeling van algemene specificaties die hergebruikt kunnen worden. Pagina 10 van 36

11 2.2.2 Metadata Metadata +container bevat +data Uitspraak + eigenschap: CharacterString + waarde: CharacterString UitsprakenVoorstel + id: URI + titel: CharacterString + specificeertdocumenttype: CharacterString [1..*] + versie: CharacterString + conformimtpversie: CharacterString + heeftstatus: CharacterString + datumlaatstewijziging: Date + eindverantwoordelijk: CharacterString [0..1] + doctype: CharacterString + taal: CharacterString = NL-nl + toegepastgmlprofiel: CharacterString De metadata die van toepassing zijn op een specifiek toepassingsprofiel zijn opgenomen in een metadatacontainer. Middels uitspraken worden de metadata beschreven. Elke uitspraak bevat een meta-eigenschap en een daarbij behorende waarde. Als een meta-eigenschap meerdere keren voorkomt resulteert dat in meerdere uitspraken van deze zelfde eigenschap. Het model bevat hier alleen de structuur. De klasse UitsprakenVoorstel geeft een lijst met mogelijk standaard op te nemen meta-eigenschappen ConceptueelModel 0..1 Label 0..1 Nr 1 Kop 1 Titel Conceptueelmodel bevat 0..* Div isie 0..* 0..* al «invariant» {Xor} 0..1 Inhoud 0..* lijst 0..* table Het model voor het beschrijven van de conceptuele informatie van een toepassingsprofiel maakt hergebruik van het gedeelte van het IMOP tekstmodel voor het coderen van vrijetekst: de divisiestructuur Implementatiemodel Pagina 11 van 36

12 Verbinding tussen conceptueel en implementatie Het implementatiemodel vormt de verbinding tussen de conceptuele beschrijving van een officiële publicatie en de realisatie daarvan in een concrete officiële publicatie. Het implementatiemodel is daarom via transformaties vertaalbaar naar concrete implementatiespecificaties. Onderstaand figuur geeft de verschillende stappen weer en de rol van het implementatiemodel daarin. Figuur 4: Van conceptuele beschrijving van een type publicatie naar een concrete officiële publicatie in XML. Het implementatiemodel (IMTP.XSD) vertaalt het conceptuele UML model (TP-UML) van een specifiek toepassingsprofiel in een technisch implementatiemodel in xml (TP-XML). Op basis daarvan worden implementatiespecificaties gegenereerd die gelden als specificaties voor opstellen en valideren van een publicatie: waardelijsten, businessrules en de referentie naar IMOP. De regels voor een technisch implementatiemodel zijn op conceptueel niveau beschreven in het IMTP-UML. IMTP als metamodel. Voor het kiezen van een modelleringsmethode van IMTP is het in paragraaf 1.5 genoemde uitgangspunt over modulaire opbouw en flexibiliteit van belang: IMTP ondersteunt middels de modulaire opbouw een flexibele toepassing van de STOP standaard in applicaties conform IMOP en daaraan toegevoegde restricties en semantiek. Door IMOP als abstract model te modelleren dat alleen in een toepassing concreet wordt en IMTP als een model voor restricties en toegevoegde semantiek ontstaat er een algemeen model dat voor alle toepassingen geschikt is. IMTP is daarin een informatiemodel voor die restricties en semantiek en fungeert als metamodel voor de beschrijving van een specifiek toepassingsprofiel. Pagina 12 van 36

13 Figuur 5: De verschillende abstractieniveaus en de daarvoor benoemde producten en hun toepassing Een model van restricties en semantiek. Het toepassingsprofiel in implementatie-laag 1 biedt de informatie waarop de technische, machine-leesbare specificaties voor opstellen, valideren en versturen van een digitale officiële publicatie zijn gebaseerd. Het beschrijft daarmee de implementatie-specificaties voor een toepassingsprofiel. De specificaties worden uitgedrukt in termen van restricties op IMOP elementen en nadere specificering van semantiek gekoppeld aan IMOP elementen. Restricties en semantische specificaties zijn op de volgende onderwerpen: - Tekststructuur: restrictie op toestaan en kardinaliteit IMOP objecttypen. - Nadere invulling tekststructuur: restricties op volgorde IMOP objecttypen en verplichte invulling van naamgeving in titel of betekenis van objecttypen. Zaken als een afgesproken opbouw van tekststructuur wordt hier in opgenomen. - Machine leesbare semantiek: definitie en toekennen van attributen aan IMOP objecttypen. - Geometrietypen: definieren van waardetypen binnen het geometriemodel. - Relaties tekst/semantiek/geo: definieren van relaties en referenties tussen tekst, semantiek en geo-objecten. - Extra business rules: Regels voor het specificeren van afhankelijkheden die nog niet in bovenstaande regels zijn opgenomen. Al deze onderwerpen kunnen uitgedrukt worden in informatiemodel-termen conform een metamodel met een object-attribuut-associatie structuur en toegevoegde business rules: - Specialisatie van IMOP objecttypen specifiek voor een toepassingsprofiel; - Benoemen attributen (semantiek) die voor een toepassingsprofiel gelden; - Koppelen van attributen aan klassen; Pagina 13 van 36

14 - Definiëren van associaties tussen objecttypen; - Benoemen kardinaliteit van attributen en associaties in relatie tot objecttypen; - Benoemen waardetype van attributen in relatie tot objecttypen; - Business rules op objecttypen. Specificaties voor validatie. Een belangrijke eis voor de informatiemodel-termen is dat ze valideerbaar zijn in hun toepassing. Dit gebeurt in implementatie-laag 2 aan de hand van de gegenereerde artefacten. De artefacten moeten geschikt zijn voor uitvoering van geautomatiseerde validaties op de volgende onderwerpen: - Validaties op tekststructuur: Validatie tegen IMOP.xsd; - Validaties op geo: Validatie van geometrien tegen definitie (ISO 19107: Spatial Schema) en tegen GML implementatie (OGC GML 3.x); - Validaties op semantiek: Validatie tegen vastgesteld vocabulaire gedefinieerd in waardelijsten; - Validaties op de relatie tussen tekst, semantiek en geo; - Validaties op business rules: Implementatie van business rules in een technische validatie-omgeving. Deze validatie-mechanismen en daarbij behorende technische formaten zijn voor een deel bepalend voor de structuur van IMTP. In hoofdstuk 5 worden de technische formaten voor validatie nader beschreven. UML-model. Het UML-klassediagram voor het implementatiemodel bevat een klasse Implementatiemodel die fungeert als root van het model. Een implementatiemodel bevat drie klassen die als container fungeren: Algemeen voor het specificeren van de relatie naar het IMOP.xsd en versie en optioneel het importeren van een module; Eigenschappen groepeert alle in het toepassingsprofiel toegevoegde attributen; Klassen groepeert alle toegevoegde klassen. Bij elke klasse is opgenomen van welke IMOP-klasse het een uitbreiding is. Hiermee wordt de relatie met het IMOP beschreven. Een klasse heeft eigenschappen die in de container Eigenschappen opgenomen zijn. Elke eigenschap wordt benoemd en beschreven in de klasse Eigenschap. Documentatie in tekst over een eigenschap is optioneel mogelijk. Voor elke eigenschap is een bereik gedefinieerd. Indien de eigenschap een relatie naar een ander object is dan omvat het bereik de doelklasse. Indien het bereik een waarde betreft dan is het waardetype opgenomen. Eigenschappen en klassen hebben optioneel een onderdeel serialisatie waarin het geval van een afwijkende serialisatie deze beschreven wordt. Indien het implemenatiemodel onderdeel is van een module dan kunnen eigenschappen zelfstandig gedefinieerd worden en is bij de eigenschap opgenomen op welke klassen ze van toepassing zijn Pagina 14 van 36

15 bevat 1 refereert XSD src: CharacterString [0..1] = IMOP Algemeen Import importeert module + src: CharacterString = module 0..* heeft Documentatie 0..* heeft 0..1 Bereik «invariant» {Xor} omvat 0..* «object» Object + type: CharacterString + maxoccurs: Integer [0..1] + minoccurs: Integer [0..1] 0..1 is Datatype «invariant» {Xor} Implementatiemodel bevat 0..1 Eigenschappen 0..1 bevat 0..* Eigenschap + naam: CharacterString [0..1] + actie: CharacterString [0..1] + wijzig: CharacterString [0..1] + maxoccurs: Integer [0..1] + minoccurs: Integer [0..1] omvat 0..* «invariant» {Xor} Waarde is is 0..1 is VasteWaarde Waardelijst naam: CharacterString [0..1] bevat 1..* Lijstitem heeft «invariant» {Alleen indien geen module} afwijkende serialisatie omvat Keuze + maxoccurs: Integer [0..1] + minoccurs: Integer [0..1] 0..1 Regexp «invariant» {Alleen voor module} 0..1 toepasbaarop Serialisatie * any afwijkende serialisatie 0..* is uitbreiding van IMOPklasse 0..1 UitbreidingVan + naam: CharacterString [0..1] + soort: doorwerking = impliciet «enumerati... doorwerking impliciet expliciet bevat 1 Klassen bevat Klasse 0..* + naam: CharacterString [0..1] keuze van 0..* Onderdeel + naam: CharacterString + maxoccurs: Integer + minoccurs: Integer inperking op IMOPklasse 0..1 Tekstconstraint Pagina 15 van 36

16 In bijlage 2 is een handleiding opgenomen hoe de toepassing van dit model in het IMTP.xsd is opgenomen en hoe de serialisatie in een XML document van een officiële publicatie wordt toegepast Visualisatiemodel <TODO> Visualisatiemodel Voor het visualisatiemodel is nog geen UML klassediagram opgenomen. Pagina 16 van 36

17 3 Objectcatalogus IMTP Dit hoofdstuk bevat de integrale normatieve specificatie van alle bouwstenen (objecttypen) van het model. <TODO> Voor deze 0.85 versie is er nog geen catalogus met benoeming van objecttypen, attributen en relaties en bijbehorende definities 3.1 Objectcatalogus metadata Tabel 1 - Objectcatalogus metadata Naam van objectcatalogus IMTP Scope IMTP Versienummer 0.85 Versiedatum TODO Herkomst Definities Dataspecificatie IMTP Tabel 2 - Types gedefinieerd in de objectcatalogus Type Package Stereotypes Objecttypes Pagina 17 van 36

18 4 Implementatie-encoding. In dit hoofdstuk zijn de implementatie-specificaties opgenomen. 4.1 Format: IMTP wordt geïmplementeerd in XML. Hiervoor is een XML schema beschikbaar: IMTP_0.85.xsd. Url voor publicatie: <voor deze versie als bestand bijgeleverd> 4.2 Encoding, tekenset, van het TP.XML bestand : OPMERKING: nog bepalen, nader specificeren. Wat er nu staat is een suggestie die bij IMRO wordt gebruikt IMTP.xsd wordt geïmplementeerd in TP.xml bestanden. Voor de encoding van het XML bestand wordt UTF-8 voorgeschreven. Van UTF-8 wordt de tekenset ISO ondersteunt en binnen deze tekenset wordt gebruikt: unicode [32 128] en [ ]. 4.3 Codegeneratie. <in ontwikkeling> De code voor de onderdelen van een TP.xml worden op verschillende manieren gegenereerd. Daar waar het mogelijk is om dat automatisch te doen is er een transformatiemodule beschikbaar. Transformaties zijn er voor de volgende onderdelen. Conceptuelemodel: Transformatie van een Word document naar een TP.xml. Transformatie software conform Word2TPxml. Het Word document wordt 1 op 1 omgezet naar TP.XML. Het PDF-bestand dat daar uit gegenereerd kan worden komt volledig overeen met het input Word document. Implementatiemodel: Verschillende transformaties vanuit het TP-UML leiden tot verschillende onderdelen van het implementatiemodel gedeelte van het TP.xml. Transformatie UML2TPxml. </in ontwikkeling> Pagina 18 van 36

19 5 Technische formaten voor implementatie In dit hoofdstuk worden de uit het toepassingsprofiel te genereren artefacten beschreven. Hun functie en mogelijk toe te passen formaat is opgenomen. Voor het genereren van de artefacten zijn transformatieregels op te stellen. Dat is in deze fase nog niet gebeurd. TODO: transformatieregels om op basis van IMTP en IMOP implementatie artefacten te genereren. 5.1 Inleiding. In het proces van de toepassing van een toepassingsprofiel, een TP.xml document, zijn er een aantal artefacten die gegenereerd moet worden. Dit gebeurt in de implementatie laag 2 zoals in figuur 5 van hoofdstuk 2 is vermeld. De artefacten zijn een versie van het toepassingsprofiel in geschikt formaat voor de mens-leesbare variant en een versie voor de machine-leesbare variant. In de volgende paragrafen zijn de formaten van die artefacten opgenomen. Er wordt daarbij de opdeling in mens-leesbare en machine-leesbare documentatie gevolgd. TODO: Al deze artefacten worden gegenereerd uit een TP.xml. Voor de transformaties uit een TP.xml zijn er transformatieregels beschreven en/of is er software beschikbaar. Deze zijn opgenomen in appendix X. TODO: appendix over transformatieregels en/of software Voor het bepalen van het format van de artefacten is het format van een instantie van een toepassingsprofiel, een digitale officiële publicatie, van belang. Dat format is XML met als onderdeel RDFa en met GML als foreign object. Meer informatie in document IMOP 5.2 Mens-leesbare documentatie voor communicatie TP.pdf Een pdf bestand wordt gegenereerd met een XSLT-transformatie conform TP2PDF.xsl TP.html Een html bestand wordt gegenereerd met een XSLT-transformatie conform TP2HTML.xsl Waardelijsten De waardelijsten zijn in veel gevallen niet opgenomen in het toepassingsprofiel maar worden met een URI gerefereerd. Het format is bepaald door de omgeving waarnaar wordt verwezen. Pagina 19 van 36

20 5.3 Machine-leesbare documentatie voor validatie. Om te valideren of officiële publicaties voldoen aan het IMOP schema en de in het toepassingsprofiel opgestelde regels en toegevoegde semantiek zijn er validatiespecificaties nodig. Deze specificaties moeten uit een toepassingsprofiel zijn te genereren. Op basis van de uit te voeren validaties zijn de technische formaten te bepalen waarin de specificaties worden beschreven. De uit te voeren validaties zijn: - Validaties op tekst (structuur en inhoud) - Validaties op geo - Validaties op semantiek - Validaties op de relatie tussen de verschillende onderdelen - Validaties op extra business rules Validatie op tekst. Tekst wordt gevalideerd op de structuur, bijvoorbeeld de opdeling in hoofdstukken en artikelen en op tekstinhoud, bijvoorbeeld de naamgeving van de titel van een artikel. Beide delen worden op een verschillende manier gevalideerd. Tekststructuur: 1) Validatie op IMOP.xsd. 2) IMTP specialisaties worden via schematron gevalideerd. 3) Kardinaliteit en bereik van eigenschappen: schematron 4) Tekstvolgorde en structuur: schematron Tekstinhoud: 1) Validatie via schematron Er komen geen TP.xsd s die als toepassing van IMOP en IMTP.xml worden gegenereerd Validatie op semantiek. Validatie op de semantiek is op twee manieren. Op het niveau van het IMOP objecttype en de verzameling uitspraken met attributen die daar aan is gekoppeld. Op het niveau van attributen hun syntax en de gekoppelde domeinwaarden. Structuur: Koppeling van attributen aan IMOP objecttypen middels uitspraken: 1) Validatie via schematron. Inhoud: Syntax van attribuut en domeinwaarde 1) Validatie via schematron. Opmerking: RDF triples zouden als foreign object in XML data kunnen zitten. Dit is echter complex in de validatierapportage. We bevelen dit niet aan. Pagina 20 van 36

21 5.3.3 Validatie op geo Geometrie zit in GML onderdelen van een XML document. Het is wat dat betreft een foreign object. Het wordt daarom apart gevalideerd. Syntax: Benaming van geometrietypen en onderdelen daarvan. 1) GML schema Structuur: Koppeling van geometrie-attributen aan IMTPobjecttypen. 1) Schematron. Dit is niet anders de validatie van semantiek. Kwaliteit: Validatie op geometrische kwaliteit conform ISO Spatial Schema. 1) Voorstel om dat middels open source tool Java Topology Suite te doen Topologie tussen geometrien. Overlap, binnen, buiten: 1) De topologieregels kunnen uitgedrukt worden in IMTP middels constraints. 2) Validatie en toepassing van deze constraints is via GI-software Relaties tussen tekst-semantiek-geo. Tekst en semantiek en geo-informatie zijn gekoppeld via relaties en attributen. Dit heeft een overlap met de validaties die bij semantiek opgenomen zijn. Structuur: 1) Schematron Extra business rules. De in een TP.xml opgenomen extra business rules zijn regels om specifiek gedrag van en tussen IMTPklassen en van en tussen attributen te beschrijven. De business rules moeten toepasbaar zijn op de implementatie format van een officiële publicatie. Voor XML implementatie is het format: 1) Schematron Voor het correct formuleren van schematron regels moet de implementatie omgeving en structuur van het te valideren bestand bekend zijn. Pagina 21 van 36

22 Bijlage 1: Procesplaat: Van Toepassingsprofiel naar Toepassing Onderstaand figuur beschrijft het proces van het opstellen van een toepassingsprofiel in xml en het toepassen daarvan voor realisatie en validatie van een officiële publicatie. Er worden de volgende stappen onderscheiden: 1) Opstellen van een toepassingsprofiel in tekst en UML. Dit is het resultaat van de informatie-analyse van de structuur en semantiek van een type officiële publicatie. 2) Transformatie van de tekst en het UML naar het format en structuur van het toepassingsprofiel. Het Toepassingsprofiel.xml is de officiële standaard voor een type officiële publicatie. 3) Uit het toepassingsprofiel kunnen de implementatie-artefacten gegenereerd worden: een mens-leesbaar gedeelte met de beschrijving van de standaard in tekst en uml; een machine-leesbare specificaties bestaande uit waardelijsten voor het beschrijven van semantiek, structuur door koppeling aan het IMOP schema en business rules voor het beschrijven van de koppeling naar IMOP in combinatie met de toepassing van waardelijsten; 4) De artefacten uit 3) worden toegepast voor het realiseren van de informatiestructuur van een officiële publicatie in xml en de validatie daarvan conform het toepassingsprofiel. Bij de transformaties staan de namen van transformatiescripts. Pagina 22 van 36

23 Bijlage 2: Handleiding IMTP (niet normatief) Inleiding IMOP is gericht op het coderen van lopende tekst van een besluit, regeling of ander document. De lopende tekst bepaalt welke XML elementen worden gebruikt. Hierdoor ontstaat een - hiërarchische - verzameling van objecten die de betekenis van de tekst aanduiden. De IMOP standaard bevat een verzameling klassen en relatietypen die gebruikt kunnen worden om een document met lopende tekst te coderen. Een voorbeeld van een klasse is imop:artikel. Hiermee wordt artikeltekst gemarkeerd. Andere voorbeelden zijn imop:aanhef, imop:bijlage, etc. Bij het opstellen van de IMOP standaard is geprobeerd om een balans te vinden tussen mate van detail van de op te nemen klassen versus de bruikbaarheid en onderhoudbaarheid van de standaard als geheel. Vanuit bepaalde doelstellingen kan het bijvoorbeeld nuttig zijn om naast Artikel ook EnigArtikel te onderscheiden. Iedere extra klasse voegt echter weer complexiteit toe, die misschien maar in enkele situaties relevant is. Voor die situaties waarin IMOP te weinig detail biedt, is een additioneel mechanisme ontwikkeld: het toepassingsprofiel. Een toepassingsprofiel is een XML document dat een documenttype beschrijft, inclusief afgeleide klassen en relatietypen. Deze nieuwe klassen worden vervolgens geserialiseerd via de beschikbare IMOP "basis"klassen. Hierdoor blijft de IMOP XSD onveranderd maar kan er toch additionele semantiek worden gedefinieerd op die plaatsen waar het nodig is. In dit document wordt toegelicht hoe dit idee van nieuwe klassen en relatietypen in een XML toepassingsprofiel werkt, hoe ze kunnen worden gedefinieerd en hoe ze vervolgens vertaald kunnen worden naar concrete XML IMOP instanties. Overzicht Ieder IMOP documenttype heeft verplicht een toepassingsprofiel XML document waarin de volgende zaken zijn opgenomen: Algemene beschrijving van het documenttype; Formele beschrijving voor restricties op IMOP klassen; Informatie over de verbeelding van het documenttype Een XML instantie van het documenttype moet altijd geldig zijn ten opzichte van de IMOP XSD. In aanvulling daarop zal het toepassingsprofiel van het documenttype nadere restricties bevatten. De IMTP standaard specificeert hoe deze aanvullende restricties beschreven kunnen worden in een XML document Pagina 23 van 36

24 een toepassingsprofiel. Dit XML toepassingsprofiel document moet geldig zijn ten opzichte van de IMTP.xsd. IMTP is in essentie dus een XML vocabulaire voor het vastleggen van nadere restricties op IMOP klassen en relatietypen. IMTP stelt geen eisen aan de manier waarop deze restricties daadwerkelijk worden toegepast. Dit kan Schematron zijn of iets anders. Een reden om voor een eigen XML vocabulaire te kiezen, is dat hiermee zowel structurele als inhoudelijke (tekstuele) restricties kunnen worden uitgedrukt. Het is denkbaar dat er in de toekomst een geschikte open standaard wordt gevonden. Er zal dan een migratie van bestaande toepassingsprofiel XML documenten nodig zijn. Een andere reden om voor een XML vocabulaire te kiezen, is dat XML bij uitstek geschikt is voor machinale verwerking. Het is bijvoorbeeld relatief eenvoudig om Schematron te genereren uit een toepassingsprofiel. Ook kan leesbare PDF documentatie gegenereerd worden uit de toepassingsprofiel XML. Definitie van klassen De IMOP standaard bevat klassen die gebruikt worden om lopende tekst te coderen. Via IMTP kunnen nieuwe klassen worden gedefinieerd. Het gaat dan om "tekstuele" klassen en "aanvullende" klassen. Een tekstuele klasse geeft nadere betekenis of extra informatie aan een stukje lopende tekst ten opzichte van de IMOP klasse waarop deze is gebaseerd. Een voorbeeld is het eerder genoemde "EnigArtikel", dat een specifiekere vorm van een "Artikel" is. Een ander voorbeeld is de toekenning van metadata aan het document. In IMTP wordt iedere metadata uitspraak gezien als een eigenschap waarde combinatie. De waarde kan een string zijn maar ook een complex datatype. In het laatste geval wordt in het toepassingsprofiel een zogeheten aanvullende klasse gedefinieerd. Een voorbeeld van een aanvullende klasse is "Omgevingswaarde" die niet letterlijk in de tekst staat, maar via een eigenschap wel betrekking heeft op (een) tekst(ueel) object. Tekstuele objecten Tekstuele klassen zijn altijd een uitbreiding van een IMOP klasse (behalve imop:object). Een nieuwe tekstuele klasse wordt op minimaal 1 van de volgende aspecten aangepast: 1. Extra regels voor de lopende tekst, bijvoorbeeld een vaste titel; 2. Extra regels voor de structuur, bijvoorbeeld het verbieden van bijlagen; 3. Aanscherpingen van optionele of verplichte eigenschappen en de toegestane waarden per eigenschap. In de volgende paragrafen worden de aspecten nader beschreven. Bij aspect 1 en 2 wordt als voorbeeld het eerder genoemde Enig Artikel gebruikt. Dit is een specifieke vorm van een Artikel, met de volgende extra restricties: Pagina 24 van 36

25 Het opschrift van het enig artikel is "Enig artikel". Dit wijkt af van de gangbare vorm van het opschrift van Artikel (namelijk "Artikel {nummer} {opschrift}"); Er mag nooit meer dan 1 enig artikel zijn (de cardinaliteit van Artikel binnen Lichaam is dus maximaal 1); Er wordt bij enig artikel geen gebruik gemaakt van structuurelementen zoals hoofdstuk en paragraaf. Bij de beschrijving van aspect 3 wordt een aantal metadata velden gebruikt als voorbeeld. Aspect 1: regels voor de lopende tekst Een voorbeeld van een regel voor de lopende tekst is de verplichting om de tekst "Enig artikel" te gebruiken als opschrift indien de auteur een enig artikel wil gebruiken. Hiertoe wordt in het toepassingsprofiel XML document een klasse "EnigArtikel" aangemaakt: <Klasse naam="imop:enigartikel"> <UitbreidingVan naam="imop:artikel" soort="expliciet" /> <Onderdelen/> <Eigenschappen/> <Tekstconstraints> <XmlFilter match="volledig"> <Kop> <Opschrift>Enig artikel</opschrift> </Kop> <Inhoud> <tp:insertschemavalidcontent/> </Inhoud> </XmlFilter> </Tekstconstraints> </Klasse> Bovenstaand XML fragment is valide ten opzichte van IMTP.xsd. Alle elementen zonder prefix zijn in de namespace Tot op zekere hoogte is de XML leesbaar. Klasse imop:enigartikel is een uitbreiding van imop:artikel. Ook is af te leiden dat de tekst van het element Kop/Opschrift gelijk moet zijn aan de string "Enig artikel". Via het element Onderdelen kunnen restricties op de samenstelling (deel-geheel relatie) worden gesteld. Via het element Eigenschappen kunnen een of meer eigenschappen van de klasse worden gedefinieerd, inclusief cardinaliteit en toegestane waarden. De elementen Onderdelen en Eigenschappen komen in de loop van dit verhaal nader aan bod. Het is essentieel om het verschil tussen een instantie van IMTP.xsd en een instantie van IMOP.xsd scherp te houden. Bovenstaand XML fragment is onderdeel van een toepassingsprofiel XML document, dus een instantie van IMTP.xsd. Een concreet besluit of regeling van een bevoegd gezag dat over de lijn gaat Pagina 25 van 36

26 naar de LVBB is een instantie van de IMOP XSD. Een fragment ziet er dan als volgt uit: <Artikel id="a12345" type="imop:enigartikel"> <Kop> <Opschrift>Enig Artikel</Opschrift> </Kop> <Inhoud> <al>lorem ipsum dolor sit amet, consectetur adipiscing elit, do eiusmod tempor incididunt </al> </Inhoud> </Artikel> Kenmerkend voor dit fragment is dat het nog steeds valideert tegen de IMOP XSD maar dat de extra regels uit het bijbehorende toepassingsprofiel ook worden gehonoreerd. Deze kunnen niet met de IMOP XSD gevalideerd worden; hiertoe zal een andere technologie gebruikt moeten worden zoals Schematron: <sch:rule context="//stop:lichaam/stop:artikel[1]/stop:kop[1]/stop:opschrift[1]"> <sch:assert test="matches(text(), '^Enig artikel$')">er is een onjuiste tekst ('<sch:valueof select="text()"/>') gebruikt in positie stop:artikel[1]/stop:kop[1]/opschrift. De vereiste tekst is 'Enig artikel'</sch:assert> </sch:rule> Het Schematron voorbeeld is illustratief omdat hiermee duidelijk wordt dat validatie van een tekstfragment uiteindelijk ook kennis van de XML documentstructuur vereist en dat ook duidelijk wordt dat deze informatie in het toepassingsprofiel aanwezig is. Aspect 2: regels voor de structuur De betekenis van het IMTP element UitbreidingVan is dat de nieuwe klasse imop:enigartikel overal mag worden gebruikt waar een imop:artikel is toegestaan. In dit geval is dat te ruim omdat artikelen ook binnen structuurelementen mogen voorkomen, en er ook standaard meer dan 1 artikel voor mag komen. Het is daarom nodig om in het toepassingsprofiel te specificeren op welke plaats de nieuwe EnigArtikel klasse toegepast mag worden. Dit kan door een nieuwe klasse te maken die een uitbreiding is van imop:lichaam. De standaard imop:lichaam klasse mag artikelen bevatten maar ook hoofdstukken of paragrafen. Bij de definitie van een nieuwe Lichaam klasse is er daarom een keuzemogelijkheid nodig: of 1x enig artikel of het "gewone" contentmodel van Lichaam. Dit ziet er in de toepassingsprofiel XML als volgt uit: Pagina 26 van 36

27 <Klasse naam="stod:_mijnlichaam"> <UitbreidingVan naam="imop:lichaam" /> <Onderdelen> <Keuze> <Onderdeel maxoccurs="1" minoccurs="1" naam="imop:enigartikel"/> </Keuze> </Onderdelen> <Eigenschappen/> </Klasse> Element Keuze geeft hier aan dat de nieuwe klasse _MijnLichaam of 1 EnigArtikel bevat of de objecten die toegestaan zijn voor superklasse Lichaam. Keuze moet worden gelezen als het toevoegen van een keuzemogelijkheid ten opzichte van de bestaande situatie. Een gerelateerde vraag is hoe te voorkomen dat de nieuwe klasse imop:enigartikel op een andere plaats wordt gebruikt dan binnen imop:lichaam. Neem bijvoorbeeld de klasse Paragraaf. Hier mag een "gewoon" Artikel voorkomen, en dat moet ook zo blijven. Het is echter niet de bedoeling dat binnen Paragraaf een EnigArtikel wordt gebruikt. Om dit probleem op te lossen, biedt de toepassingsprofiel XML het attribuut soort op het element UitbreidingVan met de default waarde "impliciet" en de alternatieve waarde "expliciet". De betekenis is als volgt: 1. "impliciet": de nieuwe klasse vervangt de klasse waarop deze gebaseerd is; de nieuwe klasse mag overal gebruikt worden waar basisklasse gebruikt mag worden; 2. "expliciet": de nieuwe klasse wordt alleen gebruikt wanneer dit expliciet gedefinieerd is in het contentmodel van een andere klasse (dus via het Onderdelen element in de toepassingsprofiel XML). Ook kan dit dan alleen maar in plaats van een klasse waarop de nieuwe klasse is gebaseerd. Bij definitie van imop:enigartikel hierboven is gebruik gemaakt expliciet; bij definitie van imop:_mijnlichaam impliciet gebruikt. Het voordeel van impliciet in deze situatie is dat er geen nieuwe klasse _MijnRegeling hoeft te worden gemaakt om _MijnLichaam toe te passen, terwijl aan de andere kant door expliciet bij EnigArtikel te gebruiken wordt voorkomen dat Paragraaf of Hoofdstuk gebruik kunnen maken van de nieuwe klasse. <!-- TODO: kunnen definiëren van plaats waar nieuwe klasse inzetbaar is, bijvoorbeeld eerst altijd een bijlage genaamd "tabellen" met alleen tabellen, dan eventuele andere tabellen. Dit moet dan een nieuwe klasse "TabelBijlage" worden die altijd als 1 e moet komen --> Aspect 3: regels ten aanzien van extra informatie Pagina 27 van 36

28 Het is gebruikelijk om bijvoorbeeld op documentniveau - metadata toe te kennen. Binnen IMTP wordt dit gezien als het toevoegen van informatie aan lopende tekst objecten via eigenschappen. Er wordt dan een nieuwe klasse gedefinieerd met de benodigde eigenschappen en de daarbij toegestane waarden. Dit ziet er in de toepassingsprofiel XML als volgt uit: <Klasse naam="stod:_officielepublicatie"> <UitbreidingVan naam="stop:officielepublicatie"/> <Onderdelen/> <Eigenschappen> <Eigenschap maxoccurs="1" minoccurs="1" naam="dcterms:identifier"> <Bereik> <Waarde> <Regexp>^od-\d\d\d\d-\d*$</Regexp> </Waarde> </Bereik> </Eigenschap> In dit voorbeeld wordt een eigenschap met de naam "dcterms:identifier" gekoppeld aan het documentelement OfficielePublicatie. Niet alleen wordt de cardinaliteit vastgesteld, maar ook wordt de toegestane waarde via een reguliere expressie gespecificeerd. Logisch gezien ontstaat er een nieuw document object met een aantal eigenschappen. In IMOP XML wordt deze informatie door middel van Uitspraak elementen in een Metadata container geserialiseerd. <OfficielePublicatie xmlns=" xmlns:xs=" xmlns:xsi=" xsi:schemalocation=" imop_0.85.xsd"> <Metadata> <Uitspraak eigenschap="dcterms:identifier"> <Waarde>ob </Waarde> </Uitspraak> </Metadata> Ook hiervoor geldt dat dit via een Schematron gevalideerd kan worden: <sch:rule context="stop:uitspraak[@eigenschap='dcterms:identifier']"> <sch:assert test="matches(stop:waarde,'^od-\d\d\d\d-\d*$')">de toegestane waarde van de Eigenschap dcterms:identifier is de regular expression: ^od-\d\d\d\d- \d*$</sch:assert> </sch:rule> In bovenstaand voorbeeld is de waarde van de eigenschap een string. Een voorbeeld van een ander binnen IMOP ondersteund datatype is: <Eigenschap actie="definieer" naam="dcterms:modified"> <ToepasbaarOp> <Klasse ref="stop:document"/> Pagina 28 van 36

29 </ToepasbaarOp> <Bereik> <Waarde> <Datatype>xs:date</Datatype> </Waarde> </Bereik> </Eigenschap> Dit leidt dan tot de volgende Uitspraak in de IMOP XML: <Uitspraak eigenschap=" dcterms:modified "> <Waarde type="xs:date"> </Waarde> </Uitspraak> Bovenstaande voorbeelden bevatten eenvoudige waarden. Het is ook mogelijk om complexere datastructuren te gebruiken. Deze waarde wordt dan een nieuwe klasse in het toepassingsprofiel. Het verschil met de eerder genoemde nieuwe tekstuele klassen is dat dit een uitbreiding moet zijn van imop:object. Stel bijvoorbeeld dat de tekst van een artikel over een omgevingsnorm gaat, maar dat niet alle informatie in de tekst aanwezig is. Het is dan mogelijk om een klasse Omgevingswaarde in het toepassingsprofiel te definiëren: <Klasse naam="stod:omgevingswaarde"> <UitbreidingVan naam="stop:object"/> <Onderdelen/> <Eigenschappen> <Eigenschap maxoccurs="1" minoccurs="1" naam="stod:soortomgevingswaarde"> <Bereik> <Waarde> <Waardenlijst naam="omgevingsnormen"> <Lijstitem>bouwhoogte</Lijstitem> <Lijstitem>cumulatieve geurbelasting</lijstitem> <Lijstitem>lage tonen cumulatie</lijstitem> </Waardenlijst> </Waarde> </Bereik> </Eigenschap> </Eigenschappen> </Klasse> In dit geval is een object gecreëerd met 1 verplichte eigenschap soortomgevingswaarde met als waarde een keuze uit een waardenlijst. Deze klasse "doet" nog verder niets: alle additionele informatie moet via een eigenschap gekoppeld worden aan een lopende tekst object. In dit geval is de voor de hand liggende kandidaat een uitbreiding van imop:artikel. Dit ziet er in toepassingsprofiel XML als volgt uit: <Klasse naam="stod:_artikel1"> <UitbreidingVan naam="stop:artikel"/> <Onderdelen/> <Eigenschappen> <Eigenschap maxoccurs="1" minoccurs="0" Pagina 29 van 36

30 naam="stod:heeftomgevingswaarde"> <Bereik> <Object type="stod:omgevingswaarde"/> </Bereik> </Eigenschap> </Eigenschappen> </Klasse> Een artikel heeft nu optioneel een eigenschap stod:heeftomgevingswaarde die gevuld wordt met een object van type Omgevingswaarde. Dit object moet in hetzelfde toepassingsprofiel (of geïmporteerde module) gedefinieerd zijn, want anders is het toepassingsprofiel inhoudelijk incorrect. Een ten opzichte van dit toepassingsprofiel geldig IMOP XML fragment ziet er als volgt uit: <Artikel> <Metadata> <Uitspraak eigenschap="stod:heeftomgevingswaarde"> <Object type="stod:omgevingswaarde"> <Eigenschap naam="stod:soortomgevingswaarde"> <Waarde>bouwhoogte</Waarde> </Eigenschap> </Object> </Uitspraak> </Metadata> <Kop> <Label>Artikel</Label><Nummer>11</Nummer><Opschrift>Bouwhoogte</Opschri ft> </Kop> <Inhoud> <al>de bouwhoogte is maximaal <Inline id="id3">10</inline> meter. </al> </Inhoud> </Artikel> In de praktijk zal de afbakening tussen lopende tekst en niet-lopende tekst niet absoluut zijn. Een object kan bijvoorbeeld twee eigenschappen hebben, waarbij de waarde van de ene eigenschap in de lopende tekst staat en de andere niet. Om redundante opslag te voorkomen, is het dan wenselijk om een verwijzing te kunnen maken vanuit het object naar een waarde in de tekst. In het voorbeeld staat de waarde 10 in de lopende tekst als maximum bouwhoogte. Stel dat deze waarde meegenomen moet worden met het Omgevingswaarde object. Dat kan door vanuit het object Omgevingswaarde te verwijzen naar de bewuste waarde in de tekst. Voor dergelijke verwijzingen zijn in IMOP twee voorzieningen opgenomen. Voor verwijzingen naar letterlijke tekst is er in IMOP het waardetype "literalref" beschikbaar. Stel bijvoorbeeld dat het Omgevingswaarde object ook een eigenschap met de naam "maximalewaarde" heeft, dan kan in de XML als volgt uitgedrukt worden dat de waarde hiervan een fragment lopende tekst is: Pagina 30 van 36

31 <Uitspraak eigenschap="stod:heeftomgevingswaarde"> <Object type="stod:omgevingswaarde"> <Eigenschap naam="stod:maximalewaarde"> <Waarde type="stop:literalref">id3</waarde> </Eigenschap> </Object> </Uitspraak> In dit geval is id3 de waarde van het id attribuut dat gebruikt is bij het Inline element dat om de tekst "10" is geplaatst (zie hierboven). Het inline element is nodig om het tekstfragment "verwijsbaarbaar" te maken; alhoewel dit theoretisch anders kan, is op dit moment de eis dat koppelingen op basis van id attributen gaan. In een aantal gevallen is de verwijzing niet naar de tekst zelf maar naar het XML element als geheel. In deze gevallen is een waarde type "objectref" beschikbaar. Dit kan bijvoorbeeld gebruikt worden bij een eigenschap "werkingsgebied" die gevuld mag worden met een geometrie (GML) object. Er vanuit gaande dat er in het document een GML fragment is met id waarde idgml1, dan ziet dit er als volgt uit: <Uitspraak eigenschap="stod:heeftomgevingswaarde"> <Object type="stod:omgevingswaarde"> <Eigenschap naam="imop:werkingsgebied"> <Waarde type="stop:objectref">idgml1</waarde> </Eigenschap> </Object> </Uitspraak> <! uitwerken hoe objectref en literalref doorwerken in toepassingsprofiel -- > Modules Ieder IMOP documenttype heeft verplicht een bijbehorend toepassingsprofiel. Gedeelde functionaliteit kan via modules worden beheerd. Een toepassingsprofiel kan dan 1 of meer modules importeren om van deze gedeelde functionaliteit gebruik te kunnen maken. Een module is een XML document met het root element Module. Dit element heeft een beperkter contentmodel dan het root element Toepassingsprofiel dat voor een toepassingsprofiel XML document wordt gebruikt, maar ze moeten geldig zijn ten opzichte van de IMTP.xsd. Toepassingsprofiel en module hebben beiden de mogelijkheid om 1 of meer modules te importeren via het Import element. Het is niet toegestaan om een toepassingsprofiel te importeren; import moet een XML document zijn met root element Module. Toepassingsprofielen worden geacht om de module imop_algemeen te importeren. Bij afwezigheid van een expliciete import wordt deze module Pagina 31 van 36