Framework van standaarden

Transcriptie

1 Framework van standaarden Geonovum datum 10 december 2007 versie 2.0 Definitief

2 Versiebeschrijving Versienummer Jaar Versienummer Versiebeschrijving Eerste versie voor discussie gemaakt door Marcel Reuvers en Paul Smits en in kleine kring gereviewd. Deze versie was vooral gebaseerd op de Nederlandse standaarden en het WD CEN/TC 287 Geographic information Standards, specifications, technical reports and guidelines, required to implement Spatial Data Infrastructures Deze versie is veel meer toegeschreven naar de Nederlandse GII door een bredere groep van auteurs en reviewers. Deze versie is geschikt toepassing binnen deze Nederlandse GII en verzorgt ook de aansluiting op regionale, Europese en internationale standaardisatie ontwikkelingen Versie 2.0 is een directe uitwerking geworden op NORA 2.0 voor de Geostandaarden. In deze uitwerking zijn ook verwijzingen gemaakt naar NORA om dit framework klein en hanteerbaar te houden. Daarnaast zijn updates en wijzigingen uitgevoerd op basis van gebruikersbehoeften en laatste informatie INSPIRE. Versiebeheer Het framework van standaarden voor de Nederlandse GII is niet statisch. Dit document wordt daarom onder beheer gebracht om wijzigingen naar behoefte en op basis van voorstellen gestructureerd door te voeren. Geonovum, als beherende instantie, zal de wijzigingen registreren. Framework van standaarden 2.0 2

3 Inhoudsopgave 0 Management samenvatting Inleiding Standaarden en interoperabiliteit Doelgroep Doel van het framework van standaarden Hiërarchie standaarden Status van het framework van standaarden GI-beraad GBO.Overheid RGI programma Opgenomen in basislijst open standaarden INSPIRE NORA Opbouw van het framework Standaarden in INSPIRE en NORA INSPIRE Principes Architectuur Infrastructuur Consequenties voor het geo-domein NORA Principes Architectuur Infrastructuur Consequenties voor het geo-domein Vergelijking NORA en INSPIRE Doelstellingen en principes Architectuur Infrastructuur Consequenties voor het geo-domein Metadata Wat is metadata? Metadata mechanismen Internationale / Europese context Referentie model Overview Abstracte standaarden Implementatie specificaties Te gebruiken standaarden voor Nederland Toekomstig werk Informatiemodellen Wat is een informatiemodel? Wat is semantiek? Behoefte aan semantiek Afstemming van begrippen en kenmerken: harmoniseren Basismodel en sectormodellen Objectgericht Model beschrijving Relatie met sectormodellen Uitwisselingsformaat GML Internationale / Europese context Referentie model Objectklassen (Features) Rasterdata (Coverages ) Ruimtelijke geo-referentie systemen Te gebruiken standaarden voor Nederland Geo-objecten (features) Rasterdata Toekomstig werk Services Grondplaat servicelagen Gegevens Dataservices Framework van standaarden 2.0 3

4 5.1.3 Businessservices Presentatie Procesbesturing Servicemanagement Dataservices Portrayal services Data access services Gazetteer services Sensor web services Location Based Service (LBS) Te gebruiken standaarden Toekomstig werk Business services Introductie business services Het belang van informatiemodellen bij businessservices Query taal Te gebruiken standaarden Procesbesturing BPEL als standaard voor procesbesturing BPEL, WSDL en XML BPEL en OGC-webservices Een voorbeeld: koppelen WFS aan internet zoekservices BPEL en domeinspecifieke standaarden voor geo-ict Te gebruiken standaarden Toekomstig werk Service registry Type registries De UDDI en ebxml -discussie UDDI/ebXML versus ISO TC211, OGC en INSPIRE Discovery service Publishing service Registry service Te gebruiken standaarden Toekomstig werk Servicemanagement Transparantie in dienstverlening Beheertaken ketenverantwoordelijke SOA-organisatie Toekomstig werk Bijlage A: Afkortingen Bijlage B: Beschrijving van ISO normen, OGC specificaties en CEN normen B.1 Overzicht van standaarden ontwikkeld door ISO TC/ B.2 OGC specificaties B.3 Beschrijving van Europese normen en rapporten (CEN/TC 287) Bijlage C: Europese en internationale normalisatie- en standaardisatie-organisaties Bijlage D: OGC-services met WSDL en SOAP Bijlage E: Framework principes in strijd met de NORA principes Framework van standaarden 2.0 4

5 0 Management samenvatting Inleiding De opzet en ontwikkeling van geo-informatie infrastructuren (GII) is in de afgelopen 10 jaar een wereldwijde activiteit geworden. Een zeer groot aantal landen is met de ontwikkeling ervan bezig en ook vanuit Europa wordt er gewerkt aan de Europese geo-informatie infrastructuur (INSPIRE). Bij de realisatie van deze infrastructuur spelen standaarden een onmisbare rol. De grote uitdaging is om uit de grote verscheidenheid aan standaarden de juiste set te kiezen. In dit framework van standaarden voor GII is een keus gemaakt. Internationale aansluiting, volwassen standaarden, breed gebruikt zijn belangrijke selectie criteria geweest. Met de in het framework genoemde standaarden is het mogelijk een solide NGII te bouwen, die compatible is met de ontwikkelingen in Europa. Draagvlak Dit framework is op een open en transparante wijze ontwikkeld. Door de standaardisatie experts uit het werkveld is het framework geformuleerd en vervolgens in bredere kring bediscussieerd. Dit betekent echter niet dat het framework klaar is. Dit framework zal continu afgestemd moeten blijven met overheid, bedrijfsleven in het algemeen en (Geo-)ICT leveranciers in het bijzonder. Door deze afstemming zal dit framework zich verder ontwikkelen. Om het framework met alle bijbehorende standaarden systematisch uit te dragen en commentaar/discussies goed op gang te krijgen is een website ontwikkeld voor de geo-standaarden. Deze website is ingedeeld conform de indeling van het framework en zal de (her)kenbaarheid verhogen ( diensten standaarden). Beheer Dit dynamische framework valt onder het beheer bij Geonovum. Voor dit framework zijn 2 typen van beheer te onderscheiden. Als eerste het reguliere beheer en ten tweede het projectmatig beheer. Een belangrijk voorbeeld van dit projectmatig beheer is het toekennen van subsidie binnen Ruimte voor Geo-informatie voor het project innovaties van geo-standaarden (RGI-116). Op basis van dit project worden grotere projectmatige veranderingen aan het framework aangebracht. Bij het reguliere beheer behoort onder andere de verwerking van gebruikerseisen en wensen en afstemming met andere standaardisatieorganisaties zoals GBO Overheid, IDsW, ICTU, etc. Samenhang In het framework is de samenhang in standaarden gekozen die de Geonovum al een aantal jaren voert en die ook binnen INSPIRE wordt gehanteerd. Deze onderverdeling bestaat uit de driedeling in metadata, informatiemodellen en netwerk services. Metadata voor het kunnen vinden van geo-informatie, informatiemodellen voor de beschrijving ervan en services voor de toegang tot de geo-informatie. Door deze driedeling wordt bereikt dat de standaarden gecategoriseerd worden en ontstaat binnen het framework een maximale mogelijkheid om de INSPIRE standaarden te toe te passen. Een goede aansluiting tussen Nederland en Europa is hiermee verzekerd. Om een globale indruk te geven van de in Nederland toegepaste standaarden voor deze driedeling volgt onderstaande tabel. Metadata In NL gehanteerde standaard Nederlandse metadatastandaard voor geografie Nederlandse metadatastandaard voor services Gebaseerd op Relevante ISO serie, OGC en W3C standaarden. Aangesloten op INSPIRE set, Advies overheid, gebruikersbehoeften, et cetera Framework van standaarden 2.0 5

6 In NL gehanteerde standaard Informatiemodellen NEN 3610 Basismodel Geo-informatie als generiek semantisch model voor o.a. IMRO, IMWA, TOP10NL, IMKICH, IMKL, IMBOD, et cetera Netwerk services Profielen voor WMS, WMS-SLD en WFS. Aansluiting op architectuur NORA en INSPIRE, internationale standaarden. Deze driedeling is in dit framework gedetailleerd uitgewerkt. Gebaseerd op Relevante ISO serie, OGC en W3C standaarden. Informatiemodellen ontstaan door harmonisatie. Relevante ISO serie, OGC en W3C standaarden, INSPIRE en NORA architectuur. Het SOA principe is hier leidend. Verplichtend/aanbevelend Het GI-beraad is onder voorzitterschap van VROM een strategisch overlegorgaan ter bevordering van de Nationale GII. Hier worden vraagstukken besproken zoals Basisregistraties, subinfrastructuur voor Rampen en Crisismanagement, verstrekkingsbeleid, ketenanalyses, etc. Het GI-beraad heeft in juni 2006 het framework van standaarden vastgesteld als verplichtend voor de GI-beraad deelnemers. Hierbij is wel de kanttekening gemaakt dat de huidige de facto standaarden gebruikt mogen worden omdat anders de overgang te groot is. De infrastructurele voorzieningen voor de e-overheid moeten ook beheerd worden door een gemeenschappelijke beheerorganisatie. Veel programma s/projecten worden daarom overgedragen aan GBO.Overheid (Gemeenschappelijke Beheerorganisatie Overheid). Denk hierbij aan DigiD, PKIOverheid, Overheidstransactiepoort, GOVCERT.NL en Bureau Forum Standaardisatie. Deze laatste bereidt de sessies voor van het College Standaardisatie. Het college standaardisatie dat haar eerste vergadering op 4 april 2007 heeft gehad heeft als onderwerp interoperabiliteit en standaardisatie op de agenda te krijgen. Het forum standaardisatie doet daarbij het voorwerk, het college kan dat voorwerk afronden en vaststellen. Op 4 april 2007 is het framework van standaarden door het college standaardisatie vastgesteld 1. Leeswijzer Hoofdstuk 1 geeft de context van dit framework gerelateerd aan SDIs en onze Nationale GII. Hoofdstuk 2 belicht INSPIRE en NORA en de gevolgen van beide op het geo-domein / dit framework. De hoofdstukken 3, 4 en 5 beschrijven de drie aandachtsgebieden van standaarden: metadata, informatiemodellen en services. Per hoofdstuk vindt een algemene uitleg plaats, positionering in de Europese/internationale context, referentiemodel met standaarden en de te gebruiken standaarden in Nederland. 1 Framework van standaarden 2.0 6

7 1 Inleiding 1.1 Standaarden en interoperabiliteit Interoperabiliteit is het vermogen van een bepaald systeem effectief of correct te functioneren als deel van een ander systeem. [Systeem wordt hier in algemene, brede zin gebruikt]. Denk bijvoorbeeld aan het gebruik van Frans of Russisch spoorwegmaterieel op het Nederlandse spoor, het gebruik van een kunstnier in het menselijk lichaam, of het gebruiken van gegevens afkomstig uit een ander software pakket. Bij interoperabiliteit gaat het om uitwisselbaarheid. Uitwisselbaarheid heeft alles te maken met de toepassing van standaarden. Het bevorderen van interoperabiliteit binnen en tussen overheidsinstellingen en met bedrijven en burgers, kan alleen bereikt worden door gebruik te maken van (open) standaarden 2. Een standaard is een procedure of een maat waarvan een groep mensen met elkaar heeft afgesproken dat ze hem zullen gebruiken. De groep mensen (organisaties) in de context van dit framework zijn degenen die werken in het geo-domein. Dit framework van standaarden beschrijft dé standaarden die nodig zijn om interoperabiliteit te verzorgen binnen het geo-domein en de aansluiting van het geo-domein op de elektronische overheid. Uitgangspunt voor het opstellen van de geo-standaarden is dat NORA en INSPIRE worden gevolgd. 1.2 Doelgroep De doelgroep van dit framework bestaat uit: Functionarissen die verantwoordelijk zijn voor het creëren van kaders voor een SDI Experts in ICT en e-government die vertrouwd zijn met geografische informatie en SDI concepten Ontwikkelaars en schrijvers van standaarden En vooral voor mensen die standaarden en specificaties implementeren in hun organisatie en willen kunnen integreren met andere organisaties in Nederland en Europa (lees INSPIRE) 1.3 Doel van het framework van standaarden Het doel van dit framework is om standaarden en specificaties vast te stellen die nodig zijn om: een NGII in Nederland te implementeren; de NGII en de elektronische overheid te integreren als NGII in Nederland aan te kunnen sluiten op de Europese SDI 1.4 Hiërarchie standaarden Voor nationale standaarden geldt dat deze ontwikkeld zijn op basis van Europese en internationale standaarden met de voor Nederland geldende specifieke eisen. Op het moment dat een nationale standaard is ontwikkeld geldt dat een nationale standaard of specificatie leidend is. Is er geen nationale standaard, dan geldt de Europese standaard en bij gebrek daaraan of omdat de internationale standaard de Europese of nationale behoefte afdekt geldt een internationale, wereldwijde standaard. 2 gebruiken is. Een open standaard houdt in dat deze volledig beschreven, gepubliceerd en zonder beperkingen te Framework van standaarden 2.0 7

8 1.5 Status van het framework van standaarden GI-beraad Het GI-beraad is onder voorzitterschap van VROM een strategisch overlegorgaan ter bevordering van de Nationale GII. Hier worden vraagstukken besproken zoals Basisregistraties, subinfrastructuur voor Rampen en Crisismanagement, verstrekkingsbeleid, ketenanalyses, etc. Het GI-beraad heeft in juni 2006 het framework van standaarden vastgesteld als verplichtend voor de GI-beraad deelnemers. Hierbij is wel de kanttekening gemaakt dat dit niet mag betekenen dat de huidige de facto standaarden niet zomaar niet meer gebruikt mogen worden. Op 20 december 2007 is versie 2.0 door het GI-beraad goedgekeurd onder hetzelfde stramien als eerdere versies GBO.Overheid De infrastructurele voorzieningen voor de e-overheid moeten ook beheerd worden door een gemeenschappelijke beheerorganisatie. Veel programma s/projecten worden daarom overgedragen aan GBO.Overheid (Gemeenschappelijke Beheerorganisatie Overheid). Denk hierbij aan DigiD, PKIOverheid, Overheidstransactiepoort, GOVCERT.NL en Bureau Forum Standaardisatie. Deze laatste bereidt de sessies voor van het College Standaardisatie. Het college standaardisatie dat haar eerste vergadering op 4 april 2007 heeft gehad heeft als onderwerp interoperabiliteit en standaardisatie op de agenda te krijgen. Het forum standaardisatie doet daarbij het voorwerk, het college kan dat voorwerk afronden en vaststellen. Op 4 april 2007 is het framework van standaarden door het college standaardisatie vastgesteld RGI programma Voor nieuwe projecten binnen RGI (sinds de tweede tender) is dit framework door het RGI-bestuur bindend verklaard. Lopende projecten wordt met klem aangeraden van het Framework gebruik te maken Opgenomen in basislijst open standaarden Het Ministerie van Economische Zaken en het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties hebben een actieplan opgesteld 4 voor het versnellen van het gebruik van open standaarden en open source software in de (semi-) publieke sector. Dit actieplan 5, dat de titel Nederland open in Verbinding heeft meegekregen, is gestart in het algemeen overleg van 21 maart 2007 over open standaarden en open source software (Tweede Kamer, , , Nr. 90.). De doelstellingen van dit actieplan zijn van toepassing op de rijksoverheid, de medeoverheden en de (semi-) publieke sector: 1. vergroten van de interoperabiliteit tussen en met de verschillende bouwstenen en vormen van dienstverlening van de eoverheid door versnelling aan te brengen in het gebruik van open standaarden; 2. verminderen van de afhankelijkheid van leveranciers bij het gebruik van ICT door versnelde inzet van open standaarden en open source software; 3. bevorderen van een gelijk speelveld op de softwaremarkt en voorts bevorderen van de innovatie en de economie door het gebruik van open source software krachtig te stimuleren en bij opdrachten de voorkeur te geven aan open source software bij gelijke geschiktheid. Voor standaarden wordt hierbij actief ingezet om een brede toepassing van open standaarden door het complyor-explain and commit principe in te voeren bij opdrachten van Rijksdiensten vanaf april 2008 en voor de overige overheden en instellingen vanaf december Om de overheid hierbij te ondersteunen wordt een basislijst open standaarden (januari 2008) en een framework voor interoperabiliteit opgesteld (basisversie in juni 2008) met richtinggevende keuzes voor de ontwikkeling en het gebruik van standaarden De kamerbrief en actieplan zijn van 17 september 2007 Dit actieplan heeft een budget van 8.5 M vanaf 2008 voor een periode van 4 jaar Framework van standaarden 2.0 8

9 Het GI-beraad is akkoord gegaan met het opvoeren van het framework van standaarden voor de basislijst open standaarden. De periode tot maart 2008 zal uitwijzen of het framework van standaarden op de basislijst open standaarden wordt geplaatst. De Geonovum website zal u hierover informeren. 1.6 INSPIRE Het voorstel van de Europese Commissie voor een Richtlijn voor de inrichting van een geo-informatie infrastructuur voor Europa (INSPIRE) (Europese Commissie 2004) definieert een SDI als the metadata, spatial data sets and spatial data services; network services and technologies; agreements on sharing, access and use; and coordination and monitoring mechanisms, processes and procedures, established, operated or made available in an interoperable manner. Deze definitie van een SDI, waarvan er vele zijn, is gehanteerd in dit framework. Dit framework concentreert zich op de technische aspecten van een SDI en beperkt daardoor de term SDI tot een platform- en implementatie-neutraal technische infrastructuur voor geo-informatie gegevens en services, gebaseerd op standaarden en specificaties. Het framework beschouwt een NGII niet als een centraal ontworpen en toegewijd informatiesysteem. Het is bekeken als een gezamenlijke verzameling van ongelijksoortige informatiesystemen die resources bevatten die stakeholders wensen te delen. Onder de noemer van SDI resources vallen die gegevens of services die aan een locatie gebonden zijn. Om dit geheel van informatiesystemen platform en implementatie-neutraal te kunnen realiseren is dit framework bedoeld. Het framework geeft daarmee de inkadering om binnen de bedoelde context interoperabiliteit tot stand te brengen. Framework van standaarden 2.0 9

10 Figuur 1 Overeenkomst standaarden van het framework van standaarden en INSPIRE De af te spreken standaarden binnen INSPIRE worden in drie Drafting Teams (DT) gemaakt: Metadata, Dataspecificaties en Netwerkdiensten (Figuur 1). Deze afspraken die binnen INSPIRE implementing rules worden genoemd worden straks als uitvoeringsbepalingen bij de richtlijn vastgesteld. Het in dit document beschreven framework verzorgt de vertaling van INSPIRE naar Nederland en vult de specifieke eisen voor Nederland aan. Het framework volgt deze drie-deling van INSPIRE: Metadata Informatiemodellen Services De standaarden waarnaar verwezen wordt in dit framework, bijvoorbeeld metadata, bevatten in ieder geval de eisen vanuit INSPIRE. Dit framework is in voortdurende ontwikkeling omdat de vereisten voor standaarden en specificaties die voor de implementatie van een SDI nodig zijn zich continue ontwikkelen. 1.7 NORA NORA heeft als doel de dienstverlening van de overheid aan haar klanten te verbeteren door overheidsorganisaties te laten samenwerken en gebruik te maken van een gezamenlijke informatieinfrastructuur. Dit wordt bereikt door overheidsarchitecturen beter op elkaar aan te laten sluiten door gezamenlijke spelregels (principes) te volgen bij het opstellen van deze architecturen. Als de uitwisseling van geo-informatie mogelijk moet zijn binnen NORA dan moeten ook voor het geo-domein de spelregels van NORA worden gevolgd. Framework van standaarden

11 Figuur 2 NORA en de indeling van INSPIRE NORA onderscheidt een semantische en service gerichte architectuur. De semantische architectuur van NORA beslaat de onderwerpen metadata en informatiemodellen van INSPIRE. De service gerichte architectuur komt overeen met services uit INSPIRE, zie Figuur 2. Merk op dat de indeling in semantische en service gerichte architectuur (SGA) niet betekent dat beide niets met elkaar te maken hebben. Integendeel, binnen de SGA dienen gegevens zo veel mogelijk ontsloten te worden, gebruik makend van de semantische architectuur. 1.8 Opbouw van het framework De volgende documenten liggen ten grondslag aan dit framework: Documenten geproduceerd door ISO/TC 211 Documenten geproduceerd door het Open Geospatial Consortium (OGC), inclusief het OpenGIS Reference Model (ORM) INSPIRE Architecture and Standards Position Paper (Smits, 2002), en alle andere beschikbare INSPIRE documenten European Interoperability framework for pan-european egovernment services, versie 1.0 Bestaande nationale richtlijnen gebaseerd op de ISO serie van normen prtr Geographic information Standards, specifications, technical reports and guidelines, required to implement Spatial Data Infrastructures (CEN/TC 287) Nederlandse standaarden gemaakt op de internationale/europese standaarden en ingericht op de Nederlandse behoeften Nederlandse Overheidsreferentie Architectuur (NORA) 2.0 Framework van standaarden

12 Hoofdstuk 1 geeft de context van dit framework gerelateerd aan SDIs en onze Nationale GII. Hoofdstuk 2 belicht INPSIRE en NORA en de gevolgen van beide op het geo-domein / dit framework. De hoofdstukken 3, 4 en 5 beschrijven de drie aandachtsgebieden van standaarden: metadata, informatiemodellen en services. Per hoofdstuk vindt een algemene uitleg plaats, positionering in de Europese/internationale context, referentiemodel met standaarden en de te gebruiken standaarden in Nederland. Framework van standaarden

13 2 Standaarden in INSPIRE en NORA Uitgangspunt voor het opstellen van de geo-standaarden voor een servicegerichte architectuur of SOA is dat NORA en INSPIRE worden gevolgd. Op hoofdlijnen streven deze richtlijnen dezelfde doelstellingen na en gaan uit van het SOA-concept. Beide zijn onafhankelijk van elkaar ontwikkeld. Bij de uitwerking zijn daarbij soms verschillende keuzes gemaakt. Eén van de doelstellingen van dit framework is om aan te geven waar de overeenkomsten en verschillen zitten. Waar verschillen worden geconstateerd, worden maatregelen voorgesteld om de beide standaarden met elkaar in lijn te brengen. Dit hoofdstuk geeft een korte beschrijving van respectievelijk NORA en INSPIRE. Aan bod komen de principes, eisen aan de architectuur en infrastructuur en de consequenties voor het geo-domein. Vervolgens wordt een vergelijking gemaakt tussen de beide richtlijnen ten aanzien van deze aspecten. 2.1 INSPIRE INSPIRE is een kaderrichtlijn 6 met wetgeving die voor alle Europese lidstaten geldt. Oorspronkelijk opgezet vanuit milieu toepassingen zal INSPIRE dankzij zijn brede toepassing leiden tot een algemene Europese geoinformatie infrastructuur. INSPIRE gaat voor een belangrijk deel voorschrijven hoe de Nationale GII dient te worden ingevuld. De manier van werken die Geonovum bij standaardisatie heeft gekozen komt 1 op 1 overeen met de indeling van INSPIRE. Dit komt deels door de aard van standaardisatie, maar ook door betrokkenheid bij het werkprogramma van INSPIRE. De infrastructuur die INSPIRE voorschrijft stelt geïntegreerde geo-informatie en diensten aan gebruikers beschikbaar. Deze diensten stellen gebruikers in staat om geo-informatie uit verschillende bronnen te vinden en op een interoperabele wijze te combineren (zowel technisch als semantisch), van lokaal tot globaal niveau en voor een brede scala van toepassingen. De gebruikers van INSPIRE zijn beleidsmakers, planontwikkelaars en managers op Europees, nationaal, regionaal en lokaal niveau en de burgers en hun organisaties. Mogelijke diensten zijn visualisatie, combinatie, integratie en analyse van geo-informatie. De invoeringsregels van INSPIRE adresseren zowel technische als niet technische aspecten. Denk hierbij aan technische standaarden en protocollen, organisatieproblemen, gegevensbeleid (toegankelijkheid) en het inwinnen en beheren van geo-informatie voor verschillende thema s Principes INSPIRE hanteert de volgende basisprincipes: geo-informatie wordt op één passend niveau opgeslagen, beheerd en beschikbaar gesteld; geo-informatie uit verschillende bronnen in de EU kan consistent worden gecombineerd en uitgewisseld tussen verschillende gebruikers en toepassingen; geo-informatie die op een bepaald overheidsniveau is vergaard kan worden uitgewisseld met andere overheidsniveaus; geo-informatie wordt onder zodanige voorwaarden beschikbaar gesteld dat grootschalig gebruik ervan niet onnodig wordt belemmerd; beschikbare geo-informatie kan gemakkelijk worden opgezocht en de geschiktheid en voorwaarden voor gebruik kunnen gemakkelijk worden nagegaan. 6 Zie voor Engelstalige versie: Zie voor de Nederlandstalige versie: Framework van standaarden

14 2.1.2 Architectuur INSPIRE gaat uit van een servicegerichte architectuur (SGA) en kiest daarbij voor de ISO-standaarden uit de serie en OGC-standaarden die gericht zijn op het ontsluiten van geo-informatie (gegevens) Infrastructuur INSPIRE kijkt naar de infrastructuur met een databenadering. De data (content) wordt met een servicegerichte benadering aangeboden aan de gebruikers. De technische georiënteerde architectuur van INSPIRE bestaat uit verschillende lagen die een rol spelen in de informatievoorziening binnen het geo-domein. Figuur 3 toont een eenvoudig overzicht van de belangrijkste technische onderdelen van deze architectuur. Daarna volgt een korte beschrijving van de componenten en hun onderlinge relaties en de verschillende services. Figuur 3 Architectuur INSPIRE Content Layer Service Layer (Content Access) Service Layer (Business Processes) Service Layer (User Interaction) Spatial Spatial Dataset Dataset GI Datasets Portrayal Service Data Access Service Gazetteer Service Applications Dataset Metadata Service Descriptions Registries Data Content Specifications Discovery Service Publishing Service... Registry Service service bus Geoportal Processing Services Business Services In de bovenstaande architectuur (Figuur 3) vinden alle toegang en bewerking van data plaats via services. Vrijwel alle aandacht van INSPIRE gaat uit naar de semantiek, het beschrijven van de data. De dataspecificatie maakt het mogelijk om geo-informatie te interpreteren voor allerlei beleidsvraagstukken. De dataspecificatie ligt ten grondslag aan de geografische datasets 7. Naast de geografische datasets moeten ook andere bronnen (centraal) onderhouden en beschikbaar gesteld worden voor een correcte behandeling en interpretatie van de data. Deze bronnen bevinden zich in registers met een goed beschreven beheermodel. De serviceslaag (services layer) in de architectuur van INSPIRE verzorgt een aantal typen services die de basisfunctionaliteit en koppeling met de geografische datasets verzorgen. Een zestal servicetypen is benoemd die de basisfunctionaliteit invullen. Dit zijn: 7 INSPIRE bestaat uit 34 geografische datasets verdeeld over 3 bijlagen. Aan de geografische datasets uit bijlage I en II (13 in totaal) ligt een dataspecificatie zoals in hoofdstuk 4 ten grondslag. Framework van standaarden

15 Publishing service: publiceren van de servicebeschrijving; Discovery service: zoeken naar gegevens; Portrayal service: visualiseren van gegevens; Data access service: toegang tot gegevens; Gazetteer service: zoeken op adressen, plaatsnamen e.d.; Registry service: zoeken naar gegevens in registers. Naast deze zes basisservices zijn nog twee servicetypen benoemd, die dichter bij een praktische toepassing komen. De beschrijving van deze twee services is abstract. De praktische invulling ervan tot concrete toepassingen wordt overgelaten aan de business gebruikers. De twee typen business services zijn: Processing service: een samenstelling van meerdere services tot een proces; Business service: Een praktisch toepasbare service die een implementatie is van een van de basisservices Consequenties voor het geo-domein Omdat INSPIRE grotendeels is geïnitieerd vanuit het Europese geo-domein loopt een groot deel van de technische eisen en uitgangspunten in de pas met de recente ontwikkelingen binnen het gehele geo-domein. INSPIRE schrijft ISO/OGC standaarden voor. De spanning en uitdaging zit hem vooral in de organisatorische, bestuurlijke en juridische consequenties. 2.2 NORA NORA heeft als doel de dienstverlening van de Nederlandse overheid aan haar klanten te verbeteren door overheidsorganisaties te laten samenwerken en gebruik te maken van een gezamenlijke informatieinfrastructuur. Dit wordt bereikt door overheidsarchitecturen beter op elkaar aan te laten sluiten door gezamenlijke spelregels (principes) te volgen bij het opstellen van deze architecturen. Als de uitwisseling van geo-informatie mogelijk moet zijn binnen NORA dan moeten ook voor het geo-domein de spelregels van NORA worden gevolgd. De belangrijkste NORA spelregels zijn: Hanteren van fundamentele principes NORA formuleert doelstellingen die met name aangeven welke eisen worden gesteld aan de dienstverlening. Deze eisen zijn vastgelegd in de fundamentele principes van NORA (zie paragraaf 2.2.1). Overheidsorganisatie wordt gevraagd om deze fundamentele principes als uitgangspunt te hanteren bij de inrichting van hun dienstverlening. Hanteren afgeleide principes Bij elke fundamenteel principe zijn afgeleide principes gedefinieerd die aangeven op welke wijze de doelstellingen bereikt kunnen worden. Deze afgeleide principes geven weer hoe overheidsorganisaties hun architectuur zodanig kunnen inrichten, dat voldaan wordt aan de fundamentele principes. Deze afgeleide principes worden in dit document niet nader behandeld. Hiervoor wordt verwezen naar NORA. Gebruiken SOA NORA gaat uit van een servicegerichte architectuur als middel om de beoogde samenwerking tussen overheidsorganisaties te creëren (zie paragraaf 2.2.2). Het is dusdanig belangrijk dat het richting geeft aan veel NORA-principes. NORA volgen betekent dus dat een organisatie haar architectuur servicegericht moet inrichten. Om de gewenste dienstverlening te bereiken adviseert NORA om waar mogelijk gebruik te maken van generieke bouwstenen. Dit is niet alleen efficiënter, maar maakt het vaak ook mogelijk een betere dienstverlening te bieden. Samen vormen deze generieke bouwstenen een gemeenschappelijke informatieinfrastructuur. De communicatie over deze infrastructuur is erg belangrijk, omdat alle overheidsorganisaties hetzelfde beeld moeten hebben over deze infrastructuur. NORA gebruikt overzichtsplaten om de informatie- Framework van standaarden

16 infrastructuur te beschrijven. Met de overzichtsplaten wordt de rol van overheidsorganisaties en generieke bouwstenen beschreven. In hoofdstuk 5 worden de overzichtsplaten toegelicht Principes De NORA definieert 20 fundamentele principes voor de inrichting en werking van de elektronische overheid (eoverheid). Hieronder worden zij kort toegelicht. Hogere kwaliteit dienstverlening P1 P2 P3 P4 P5 P6 P7 Diensten via Internet: organisaties in het publieke domein verlenen hun diensten aan burgers, bedrijven en maatschappelijke instellingen via het internet (elektronisch loket) en stimuleren het gebruik van dit kanaal. De bestaande kanalen zoals post, telefoon en balie blijven beschikbaar, zodat burgers, bedrijven en maatschappelijke instellingen gebruik kunnen maken van het kanaal van hun keuze. Organisaties in het publieke domein geven een helder, vindbaar beeld van de diensten en producten die burgers, bedrijven en maatschappelijke organisaties van hen kunnen afnemen. Daartoe zijn hun elektronische loketten benaderbaar via landelijke ingangen zoals de website (één loketgedachte, no wrong door ). Organisaties in het publieke domein bieden hun diensten (producten) bij voorkeur aan in voor de klant logische bundels per (soort) gebeurtenis aan de kant van de klant (geboorte, huwelijk, starten bedrijf) en werken daartoe samen met andere organisaties in het publieke domein ( one stop shopping ). Burgers, bedrijven en maatschappelijke instellingen beschikken over één identiteit die bruikbaar is voor alle contacten met organisaties in het publieke domein en die afhankelijk van de soort dienstverlening ook nodig is en gevraagd moet worden. Dit ongeacht de keuze voor een kanaal. Een en ander komt neer op één administratieve identiteit (één identificatienummer). Deze administratieve identiteit dient afgebeeld te worden op een (ook digitaal toepasbaar) identiteitsbewijs. Om een vlotte dienstverlening mogelijk te maken implementeren organisaties in het publieke domein routinematig uit te voeren controles binnen het primaire dienstverleningsproces. De noodzakelijke controles worden zo uitgevoerd dat een snelle en soepele dienstverlening plaatsvindt. Meer specifieke controles vinden in beginsel via afzonderlijke processen, parallel of achteraf plaats (eerst mensen, dan regels). Organisaties in het publieke domein kennen een transparante en toegankelijke klachten- en bezwarenprocedure. Administratieve lastenverlichting P8 P9 P10 Eenmaal uitvragen van gegevens, meermalen gebruiken: de organisaties in het publieke domein zullen burgers en bedrijven niet opnieuw om gegevens vragen die bij de overheid al bekend zijn. Organisaties in het publieke domein streven naar zo laag mogelijke administratieve lasten en een zo laag mogelijke regellast voor burgers, bedrijven en maatschappelijke organisaties. Organisaties in het publieke domein zorgen voor een eenvoudige regelgeving, in omvang beperkt, onderling consistent en goed controleerbaar en handhaafbaar. Transparantie P11 P12 Organisaties in het publieke domein geven aan op welke momenten welke stadia in het dienstverleningsproces doorlopen dienen te zijn en streven daarbij naar zo kort mogelijke doorlooptijden. Organisaties in het publieke domein geven burgers, bedrijven en maatschappelijke Framework van standaarden

17 P13 P14 P15 instellingen inzicht in de status van voor hen lopende dienstverleningsprocessen (transparante, traceerbare dienstverleningsprocessen). Organisaties in het publieke domein zorgen dat zij naar burgers, bedrijven en maatschappelijke instellingen periodiek verantwoording afleggen over de kwaliteit van de gerealiseerde dienstverlening. Organisaties in het publieke domein ontsluiten algemene overheidsinformatie, waaronder wet- en regelgeving. Organisaties in het publieke domein maken zichtbaar wat zij doen, welke besluiten zij nemen, welke gegevens zij hebben en gebruiken en wat hun werkwijze is. Proactieve dienstverlening P16 Organisaties in het publieke domein attenderen burgers en bedrijven op voor hen relevante diensten (proactieve dienstverlening), maar bieden ruimte voor eigen regie en verantwoordelijkheid door burgers en bedrijven op de feitelijke afname van diensten (zelfwerkzaamheid). Daarbij verstrekken organisaties begrijpelijke informatie, bij voorkeur geïndividualiseerd, over rechten, plichten en mogelijkheden voor burgers en bedrijven. Integrale en betrouwbare overheid P17 P18 Organisaties in het publieke domein organiseren zich als een onderdeel van een integraal opererende en als eenheid optredende overheid, die in haar handelen naar burgers, bedrijven en maatschappelijke instellingen consistent en betrouwbaar is. Organisaties in het publieke domein gebruiken gegevens die accuraat, actueel en volgens wettelijke normen beveiligd zijn. Verbeteren doelmatigheid overheid P19 P20 Gebruik waar mogelijk generieke bouwstenen. Organisaties in het publieke domein streven er naar om beschikbare gemeenschappelijke voorzieningen te gebruiken, als deze op de punten functionaliteit, beveiliging en kosten gelijkwaardig zijn aan individuele voorzieningen. Standaardiseer en optimaliseer interne bedrijfsvoering Architectuur Een van de leidende uitgangspunten van NORA is het gebruik van een servicegerichte architectuur om overheidsorganisaties als één geheel diensten te laten leveren aan burgers en bedrijven (e-overheid). NORA besteedt veel aandacht aan de organisatorische consequenties van een servicegerichte benadering. Overheidsorganisaties werken samen door services aan elkaar te leveren. Belangrijke eisen die een servicegerichte architectuur stellen zijn: Definiëren services en diensten; Bepalen granulariteit van de services Definiëren services en diensten In een servicegerichte architectuur is de relatie tussen een architectuuronderdeel en zijn omgeving er een van dienstverlening. Dat wil zeggen dat het onderdeel services levert aan zijn omgeving en daar services van afneemt. De belangrijkste eigenschap van een service is daarmee de prestatie of het effect dat wordt geleverd. Om de dienstverlening uit te voeren gaan de leverancier en afnemer een dialoog aan, die uit een of meerdere stappen bestaat. In die stappen worden gegevens (berichten) uitgewisseld. Als de beoogde afnemers van een service de eindklanten van de e-overheid zijn (burgers en bedrijven), spreken wij van diensten. Framework van standaarden

18 Bepalen granulariteit van services Een service kan zijn opgebouwd uit kleinere (fijnmaziger) services. De fijnmazigheid van een service wordt granulariteit genoemd. Eén van de belangrijkste ontwerpbeslissingen bij een servicegerichte architectuur is het kiezen van de juiste granulariteit. De granulariteit bepaalt in sterke mate de herbruikbaarheid van services. In principe kan elke servicegerichte architectuur uiteengerafeld worden tot zeer fijnmazige services, die stuk voor stuk opnieuw bruikbaar kunnen zijn. Echter, architecturen hoeven niet altijd en op alle punten maximaal ontkoppeld te worden. Sterke integratie tussen componenten heeft soms ook voordelen. Een organisatie die services aanbiedt moet zelf bepalen welke granulariteit wordt gekozen. Vanuit NORA worden de volgende criteria aangereikt om deze afweging te kunnen maken: Organisatiegrenzen en wetgeving Daar waar architectuuronderdelen rechtspersonen representeren, die (al dan niet van rechtswege) een eigen verantwoordelijkheid dragen, is het verstandig deze uiteen te plaatsen en er een servicerelatie tussen aan te brengen; Hergebruik Als een kleiner deel van een architectuuronderdeel ook ergens anders opnieuw te gebruiken is, kan het verstandig zijn deze af te zonderen als aparte service; Ontkoppeling van dynamiek Als verschillende architectuuronderdelen naar verwachting in verschillend tempo zullen veranderen, kunnen deze tempoverschillen worden opgevangen door hen uiteen te halen en er een servicerelatie tussen aan te brengen; Beschikbaarheid van bestaande onderdelen Als bepaalde deelservices (zoals softwarecomponenten of dienstverlenende organisaties) al klaarliggen, kan het verstandig zijn deze als een service af te zonderen. Aan deze 4 punten moet ook de beheersbaarheid worden toegevoegd. De keus voor een fijne of grovere granulariteit bepaalt ook de beheersbaarheid van de services waarbij niet op voorhand gezegd kan worden dat een fijnere granulariteit meer beheer vraagt. Dit is voor een belangrijk deel afhankelijk van de organisatorische inrichting Infrastructuur De infrastructuur moet het mogelijk maken dat overheidsorganisaties gezamenlijk, als één virtuele organisatie, de e-overheid, diensten leveren aan burgers en bedrijven. NORA biedt een gestructureerde aanpak voor de beschrijving van de infrastructuur en biedt de mogelijkheid om vanuit verschillende invalshoeken naar de infrastructuur te kijken. De invalshoek bepaalt de diepgang waarmee bepaalde aspecten worden getoond. Het gaat hierbij om de volgende invalshoeken: Basisstructuur vanuit één overheidsorganisatie; Architectuur van e-overheid; Positionering van bouwstenen e-overheid Basisstructuur vanuit één overheidsorganisatie Figuur 4 geeft een vereenvoudigd model van de wijze waarop overheidsorganisaties diensten leveren aan burgers en bedrijven. Deze diensten kunnen via meerdere kanalen worden geleverd (blauwe veld). Diensten zijn het resultaat van bedrijfs- en werkprocessen die binnen overheidsorganisaties worden uitgevoerd (oranje veld). Bij de dienstverlening en het uitvoeren van werkprocessen spelen tal van gegevens een cruciale rol. Daarom kennen alle overheidsorganisaties voorzieningen voor het vastleggen van gegevens (grijze veld). Framework van standaarden

19 Figuur 4 Dienstenmodel NORA Architectuur van e-overheid Figuur 5 geeft de architectuur van een overheidsorganisatie. Deze ogenschijnlijk eenvoudige architectuur is de basis van de elektronische overheid. Op deze basis worden voorzieningen gebouwd die uniform van opzet zijn: de bouwstenen van de e-overheid. Zij moeten volgens dezelfde principes ontwikkeld zijn, zodat zij met elkaar het stelsel vormen dat de e-overheid genoemd kan worden. Figuur 5 Architectuur e-overheid Positionering van bouwstenen e-overheid Figuur 6 geeft een overzicht van de bouwstenen van de e-overheid. Samen vormen zij de ICT-infrastructuur van de overheid. Overheidsorganisaties kunnen deze infrastructuur gebruiken om informatie uit te wisselen. Framework van standaarden

20 Bouwstenen die al volledig of gedeeltelijk in gebruik zijn, zijn aangeduid met witte rechthoeken. Bouwstenen die nog niet in ontwikkeling zijn, maar wel nodig zullen zijn om de hele e-overheid soepel te laten functioneren, zijn aangeduid met gele rechthoeken. Figuur 6 Bouwstenen e-overheid Tabel 1 geeft per bouwblok het doel aan en de relevantie voor het geo-domein. Tabel 1 Architectuur e-overheid Bouwblok Doel Relevant voor geo-domein Basisregistraties Centrale beschikbaarstelling gegevens Ja BSN, BIN Identificatie Ja Catalogi Dienstencatalogus Ja CCO Centrale telefonische ingang N.v.t. DIGID Authenticatie Ja e-dossiers Elektronische dossiers Ja e-formulieren Beschikbaarstelling elektronische formulieren N.v.t. ENIK Beveiliging Ja Metadata Gegevens nodig voor ontsluiting en beheer Ja OTP Ontvangen van bestanden van bedrijven Ja PIP Persoonlijke internetpagina Ja Servicebus Ondersteunen berichtenverkeer Ja Serviceregister Vindbaar maken services Ja Uitvraag Gemeenschappelijke voorziening voor uitvragen Ja basisregistraties Zoekmachine Centraal zoeken naar decentrale informatie Ja Framework van standaarden

21 2.2.4 Consequenties voor het geo-domein Het volgen van de NORA-principes heeft de volgende consequenties voor het geo-domein: Het geo-domein moet de fundamentele principes van NORA onverkort toepassen op het geo-domein Dit document neemt daarom de fundamentele principes van NORA op het gebied van dienstverlening over. Het geo-domein moet ook de afgeleide principes van de NORA volgen De toegepaste geo-standaarden moeten zich conformeren aan de afgeleide principes van NORA. Het geo-domein maakt gebruik van een servicegerichte benadering De NORA-definitie is hierin breder dan die van INSPIRE, die zich beperkt tot technische aspecten. Dit document geeft aan op welke wijze voldaan kan worden aan zowel benadering van NORA als van INSPIRE. Het geo-domein richt de nationale geo-informatie infrastructuur (NGII) zoveel mogelijk in op basis van generieke bouwstenen die in NORA staan beschreven Het eindbeeld is een gemeenschappelijke infrastructuur voor geografische en niet-geografische informatie. Voor de beschrijving van de geo-informatie infrastructuur wordt uitgegaan van de NORAoverzichtsplaten. Hierin wordt aangegeven welke eisen worden gesteld door het gebruik en delen van geo-informatie. NORA geeft aan dat de granulariteit van de geboden services een beslissing is voor de aanbieder. Dit betekent dat het geo-domein moet nadenken over de granulariteit van de geo-services die worden aangeboden in een generieke SGA. De combinatiemogelijkheden van de services met een fijne granulariteit zijn vele malen groter dan die van services met een grove granulariteit. Daar staat tegenover dat services met grove granulariteit sneller in een (eind-)toepassing ingezet kunnen worden, omdat ze meer functionaliteit bevatten. Het meest populaire servicetype uit het geo-domein, de web mapping service (WMS) heeft een grove granulariteit. Dat maakt een dergelijke service minder breed toepasbaar in combinatie met andere services, maar juist wel weer snel inzetbaar voor specifieke doeleinden (namelijk: kaarten serveren via een netwerk). In de regel zullen services met een grove granulariteit vooral gebruikt worden naar buiten toe en services met een fijne granulariteit meer intern, danwel andere services dienen Voorbeeld granulariteit binnen het geo-domein: opvragen bestemmingsplannen Opvragen bestemmingsplan via service met grove granulariteit Stel dat er wordt gekozen voor een service met één operatie, die in één keer alle beschikbare informatie (toelichting, plankaart en voorschriften) van een bestemmingsplan voor een adres teruggeeft. De gebruiker moet als invoer van deze operatie een adres en de datum opgeven, waarvoor het bestemmingsplan wordt gezocht. Onder de motorkap gaat deze service eerst uit een database halen voor welk bestemmingsplan alle documenten opgehaald moeten worden. Daarna worden de toelichting, de voorschriften en een kaart opgevraagd uit een ander systeem. Dit wordt samengevoegd tot één PDF-bestand en dat wordt teruggestuurd aan de gebruiker. De service biedt hiermee vrij veel functionaliteit (waarschijnlijk voldoende voor een aantal toepassingen), maar is weinig flexibel. Wat als de gebruiker alleen geïnteresseerd is in de plankaart omdat daar andere gegevens overheen gelegd moeten worden? Of het gaat juist alleen om de voorschriften? Of de gebruiker wil alle plannen voor een groter gebied opvragen? De service met grove granulariteit biedt dus wel veel functionaliteit in één keer, maar is waarschijnlijk niet (goed) herbruikbaar voor veel toepassingen. Opvragen bestemmingsplan via services met fijne granulariteit Bij services met fijne granulariteit kan het opvragen van alle documenten van een bestaand bestemmingsplan in onderdelen, via verscheidene services, plaats vinden. Zo kan bijvoorbeeld een service om één of meerdere plankaarten op te halen in een bepaald gebied ontwikkeld worden, een geocodeerservice om van adressen een coördinaat in RD op te vragen, een service om te zoeken in de teksten van een bestemmingsplan volgens flexibele zoekopdrachten (bijvoorbeeld geef mij alleen de voorschiften van bestemmingsplannen die bebouwing Framework van standaarden

22 hoger dan 15 meter toestaan ) en een service om documenten samen te voegen in één PDF-bestand. Met deze services kunnen gegevens over/van bestemmingsplannen flexibeler worden opgehaald, maar ook andere taken worden uitgevoerd. Deze losse services zijn daarmee geschikter voor hergebruik, maar voor gebruik in een toepassing om (snel) een bestemmingsplan op te halen, moet nog werk verricht worden. De losse services moeten daarvoor aangeroepen worden. 2.3 Vergelijking NORA en INSPIRE Doelstellingen en principes Op hoofdlijnen streven NORA en INSPIRE dezelfde doelstellingen na. Hun doelstellingen zijn niet strijdig met elkaar. Hetzelfde geldt voor de principes die zij hanteren. Wel hanteert NORA beduidend meer principes. Veel NORA-principes komen niet expliciet terug in die van INSPIRE. Dit komt omdat NORA breder van opzet is, namelijk het realiseren van een goede dienstverlening. INSPIRE redeneert vooral vanuit de gegevens. Op het punt van dienstverlening vult de NORA dus duidelijk INSPIRE aan. De NORA-principes zijn onverkort van toepassing op dit framework. Andersom geldt dat INSPIRE zich vooral richt op de invulling van de semantiek van de gegevens. De thema s uit Annex I en II worden Europees geharmoniseerd en uitgedrukt in informatiemodellen. Dit punt wordt door NORA wel genoemd maar wordt gezien als een verantwoordelijkheid van de organisaties. Op dit punt vult INSPIRE NORA dus duidelijk aan. In NORA wordt een sleutelrol neergelegd voor de basisregistraties maar wordt niet verder ingegaan op de harmonisatie of informatiemodellen Architectuur Zowel NORA als INSPIRE gaan uit van een servicegerichte architectuur. NORA stelt eisen aan bedrijfsarchitectuur, informatiearchitectuur en in geringe mate aan de technische architectuur. NORA beschrijft geen informatiemodellen. NORA geeft wel aan dat informatiemodellen een essentieel onderdeel vormen van een architectuur. INSPIRE stelt vooral eisen aan de informatiearchitectuur. Hierbij worden eisen gedefinieerd op drie niveaus, te weten metadata, informatiemodellen en services. Figuur 7 geeft de relatie tussen INSPIRE en de architectuur van de e-overheid van NORA weer. INSPIRE richt zich vooral op infrastructurele services en NORA op de bouwstenen. Op dit niveau doen zich geen conflicten voor en kan geconstateerd worden dat beide goed op elkaar aansluiten. Figuur 7 Relatie architectuur INSPIRE en NORA Framework van standaarden

23 Service Layer (User Interaction) Service Layer (Content Access) Service Layer (Business Processes) Service Layer (Content Access) Content Layer Portrayal Service Data Access Service Burgerloket Gazetteer Service Discovery Service Publishing Service Registry Service Bedrijvenloket Gemeenschappelijk frontoffice overheid Burgers- & Bedrijven Processing Services Business Services Infrastructuur INSPIRE geeft aan dat de nationale infrastructuur gebruikt moet worden. De infrastructuur zoals in NORA beschreven kan deze rol vervullen Consequenties voor het geo-domein Zoals reeds geconstateerd streven NORA en INSPIRE op hoofdlijnen dezelfde doelstellingen na, met vergelijkbare principes. INSPIRE en NORA vullen elkaar grotendeels aan. Zo laat NORA open welke domeinspecifieke standaarden gebruikt dienen te worden, waar INSPIRE die juist invult voor het geo-domein. Dit is logisch omdat INSPIRE een initiatief is voor het geo-domein terwijl NORA niet domein gebonden is en juist domein overstijgende afspraken opstelt. Conflicten tussen INSPIRE en NORA zijn daardoor beperkt aanwezig. Deze zijn benoemd in bijlage E en zijn aandachtspunt voor betere afstemming. Op een (belangrijk) punt maken NORA en INSPIRE echter wel een verschillende keuze. Vooral de keuzes van INSPIRE voor metadata en standaarden voor services beïnvloeden de interoperabiliteit met NORA. Waar NORA kiest voor reguliere ICT-standaarden, zoals W3C en OASIS, kiest INSPIRE voor ISO TC/211 en OGC. De standaarden van ISO/OGC en W3C/OASIS sluiten op bepaalde punten echter nog niet goed aan. Dit betreft vooral de ondersteuning voor WSDL en SOAP in OGC services (zie bijlage D). Hoewel het lijkt dat vooral het OGC kiest voor adoptie van SOAP en WSDL voor WMS, WFS en WCS op langere termijn, is er nog geen harmonisatie te verwachten op het vlak van registers. Waar OGC lijkt te gaan kiezen voor ebrim, heeft de IT wereld vooralsnog meer voor UDDI gekozen. Het ziet er naar uit dat INSPIRE SOAP-bindings, ook voor OGC services, gaat voorschrijven. Er zal waarschijnlijk en studie uitgevoerd worden hoe dit precies ingevuld wordt. Wil het geo-domein standaarden van zowel NORA als INSPIRE toepassen dan moeten op korte termijn meer standaarden geïmplementeerd worden dan strikt noodzakelijk voor het bereiken van de doelen van een verbeterde dienstverlening en een betere uitwisseling van informatie. Het betreft hier vooral de manier van verpakken van berichten. Framework van standaarden

24 3 Metadata 3.1 Wat is metadata? De groeiende informatiebehoefte heeft geleid tot veel geografische datasets, series en services met een grote diversiteit aan onderwerpen, thema s en benaderingen. Gevolg van dit groeiende aanbod van geografische datasets (schatting voor Nederland ongeveer ) is dat het voor gebruikers van geografische datasets steeds moeilijker wordt de juiste informatie te vinden. Met metadata wordt de geografische dataset op zo n manier beschreven dat zoekopdrachten gericht kunnen worden op vragen als wie, wat, waar, wanneer, waarom en hoe. De metadata bevat details over de eigenaar van de geografische data, kwaliteit, geldigheid, etc., en hoe het kan worden benaderd en gebruikt. Het gaat hier niet over de beschrijving van de geografische dataset zelf, dit wordt in hoofdstuk 5 verwoord. In een Geo-informatie infrastructuur wordt deze metadata naar een catalogus gepubliceerd. Een catalogus biedt de mogelijkheid om gedistribueerde geografische resources zoals datasets, dataset series en services te kunnen vinden, managen en beheren. De catalogus wordt beschreven in hoofdstuk Metadata mechanismen Gebruik van metadata kan verschillende doelen dienen. Om duidelijkheid te krijgen in het doel waarvoor metadata gebruikt wordt zijn mechanismen gekoppeld aan doelstellingen. De volgende mechanismen van metadata worden internationaal onderkend: Discover Resources De eerste stap in het discovery van resources is het zoeken van geografische data en services. Dit zoeken gebeurt in catalogues waarin resources met behulp van metadata zijn beschreven. Exploration Resources Zodra een gebruiker een resource heeft gevonden is de volgende stap om deze resource te evalueren en te kijken of de resource de behoefte invult. Dit gebeurt door de aanvullende metadata te onderzoeken. Exploitation Resources Zodra gebruikers de gewenste resource hebben gevonden en geëvalueerd zijn er verschillende manieren om de resource te benaderen en gebruiken. Denk hierbij aan downloading, bestellen via , telefonische bestelling, etc. Wanneer deze resource via een SDI benaderd wordt zal voor de exploitation fase gebruik moeten worden gemaakt van informatiemodellen en services zoals beschreven in hoofdstuk 4 en 5 van dit framework. Iedere doelstelling heeft haar eigen mechanisme en maakt gebruik van een ander meta informatie niveau. Discovery metadata is de minimale hoeveelheid van informatie die verstrekt moet worden om tijdens verzoek de aard en inhoud van de databron te kunnen beoordelen. Synoniemen: voor exploration wordt vaak de term evaluatie (evaluation) gebruikt voor exploitation worden vaak de termen gebruik (use) en toegang (access) gebruikt In een NGII is een discovery mechanisme een online service die providers en gebruikers samenbrengt. Discovery mechanismen bieden gebruikers de mogelijkheid om geografische informatie, in de vorm van datasets, dataset series and services te vinden (discovery), te beoordelen (exploration) en te verkrijgen (exploitation). Gebruikers stellen een vraag waarbij het discovery mechanisme de resource(s) vindt. De gebruiker kan de resource benaderen op de manier die de provider aanbiedt voor dit product. Framework van standaarden

25 Figuur 8 Gradaties in metadata Discovery resource Exploiration resource Exploitation resource 3.3 Internationale / Europese context Internationaal gelden de ISO metadata normen en waar relevant de OGC specificaties. Binnen Europa wordt door CEN/TC 287 sinds januari 2005 gewerkt aan een Europees profiel op de ISO standaarden voor discovery. Het INSPIRE DT metadata is sinds oktober 2005 gestart met het maken van een Implementing Rule die met het van kracht worden van INSPIRE gaat gelden. Deze Implementing Rule voor metadata bevat een Europese set voor discovery, evaluation en use. In de praktijk houdt INSPIRE zich voornamelijk bezig met metadata voor discovery. Doordat twee Europese organisaties bezig zijn met metadata voor discovery bestaat de kans dat binnen Europa een standaard en Implementing Rule met elkaar conflicteren. Dit is door INSPIRE en CEN/TC 287 onderkend en heeft ertoe geleid dat het CEN/TC 287 werk is ingebracht binnen INSPIRE. Vervolgens heeft CEN/TC 287 het metadata werk tijdelijk stilgelegd. Nadat de Implementing Rule gereed is wordt dit aangeboden aan CEN/TC 287 en zal in overleg worden bepaald welke delen van de Implementing Rule verwerkt wordt in een Europese norm (CEN/TC 287) of zelfs moet worden teruggebracht naar ISO/TC 211. De Nederlandse metadata standaarden die in paragraaf 3.5 worden aangeduid zijn in een continu proces met de internationale en Europese context tot stand gekomen. Geonovum is voorzitter van de CEN/TC 287 subgroep Metadata en het Drafting Team Metadata van INSPIRE. Door dit voorzitterschap en actieve deelname weet Geonovum welke metadata elementen van belang zijn/worden voor Nederland vanuit de Europese context. Figuur 9 plaatst de Nederlandse metadatastandaarden in zijn internationale, Europese en sectorale context. De ISO-kernset is de kleinste eenheid, een selectie uit ISO 19115:2003, die de verplichte internationale metadata elementen aangeeft. Binnen Nederland is de Europese kernset uitgebreid met de specifieke behoeften van de gebruikers in Nederland en is de aansluiting op verzorgd en wordt geparticipeerd in Sectoren in Nederland kunnen een eigen uitbreiding op het Nederlandse profiel ontwikkelen. Voorwaarde is dat de Nederlandse kernset metadata onderdeel is van het sectorale metadata profiel. Deze sectorale uitbreidingen kunnen onderdeel zijn van ISO 19115:2003. Ook is het mogelijk eigen abstracte klassen met metadata elementen te creëren. Framework van standaarden

26 Figuur 9 Hiërarchie in metadata ISO 19115/19119 ISO kernset bodem Europese kernset (INSPIRE) Nederlandse kernset metadata water geologie Profiel voor specifieke sectoren 3.4 Referentie model Overview Het gebruik van standaarden kenmerkt zich door gebruik van abstracte (semantische) standaarden en implementatie specificaties. De beschreven standaarden en specificaties worden internationaal gebruikt. Om deze standaarden regionaal en nationaal toepasbaar te maken, wordt vaak een profiel ontwikkeld. Dit profiel kan bestaan uit een extensie (aanvulling) en/of een restrictie (beperking) op de standaard Abstracte standaarden De metadatanorm NEN-EN-ISO Metadata is gericht op de semantische beschrijving van geografische datasets door middel van metadata. Deze standaard voorziet in een kleine selectie van verplichte en vele optionele metadata elementen (> 400). De metadatanorm ISO Services is gericht op de semantische beschrijving van metadata voor (geografische) services. Deze services kunnen gekoppeld worden aan geografische datasets Implementatie specificaties Het ISO 19115/19119 Application Profile voor CSW 2.0 is een door OGC ontwikkelde implementatie (XMLschema) voor ISO op de OGC's Catalogue Service Implementation Specification. Voor de beschrijving van datasets en dataset series wordt gebruik gemaakt van ISO TS om de interoperabiliteit te garanderen. ISO TS is de implementatie (XML-schema) van de metadatanorm NEN-EN-ISO Alle wijzigingen in NEN-EN-ISO worden tevens doorgevoerd in ISO TS Te gebruiken standaarden voor Nederland Deze paragraaf beschrijft de te gebruiken (geografische) metadatastandaarden aan voor Nederland. Framework van standaarden

27 Binnen Nederland zijn momenteel twee nationale profielen en één regionaal profiel ontwikkeld. De Nederlandse metadata standaard voor geografie is een profiel op NEN-EN-ISO Deze nationale metadatastandaard richt zich op de semantische beschrijving van metadata elementen om geografische datasets en dataset series te beschrijven. De gebruikte standaarden hiervoor zijn in deze Nederlandse metadata standaard vastgelegd. De Nederlandse metadata standaard voor services richt zich op de semantische beschrijving van metadata elementen om geografische services te beschrijven. De gebruikte standaarden hiervoor zijn in deze Nederlandse metadatastandaard vastgelegd. Deze standaard dient samen gebruikt te worden met de Nederlandse metadatastandaard voor geografie. Binnen het X-GDI programma is een regionale metadatastandaard ontwikkeld: X-GDI metadata profile v1.1. Dit metadata profiel is geldig binnen de Euregio Maas-Rijn. Bij de ontwikkeling van deze metadatastandaard is afstemming geweest tussen Nord-Rhein Westfalen en Nederland. Dit profiel is een doorsnede van de Nederlandse metadatastandaard voor geografie en de Nederlandse metadatastandaard voor services. Dit betekent dat indien beide nationale profielen worden toegepast, er wordt voldaan aan het X-GDI metadata profile v1.0. Het X-GDI metadata profiel is hiermee een subset van de Nederlandse metadata standaarden. Bovenstaande profielen maken gebruik van de internationale standaarden en de INSPIRE Implementing Rule voor metadata (D1.3). Daarnaast heeft Advies Overheid.nl een nationale metadatastandaard ontwikkeld op basis van Dublin Core. Deze metadatastandaard wordt beschreven in Overheid.nl webmetadata. De metadatastandaarden in dit framework voldoen aan de richtlijnen van Advies Overheid. Hierdoor is bij toepassing van de Nederlandse metadata standaarden de Europese en internationale aansluiting afgedekt. Tabel 2 Standaarden en specificaties met betrekking tot metadata standaarden Internationale standaarden/specificaties Europese profielen Nederlandse profielen ISO 19115:2003 Geographic information - Metadata ISO 19115/Cor.1:2006, Geographic information Metadata, Technical Corrigendum 1 Draft Implementing Rule INSPIRE Metadata: D1.3 IR Metadata (uiterlijk beschikbaar op , zie voor de laatste versie) Nederlandse metadatastandaard voor geografie v1.1 standaarden/nederlandsemetadata-standaard-voorgeografie/download.html?itemid=58 ISO/CD , Geographic information Metadata Part 2: Metadata for imagery and gridded data, ISO/TC 211 N 1931 dated Nederlandse metadatastandaard yoor services v1.0 standaarden/nederlandsemetastandaard-voorservices/download.html?itemid=58 ISO 19119:2005 Geographic information Services ISO 19119:2005 PDAM 1, Geographic information Services ISO v0.9 Geographic information Metadata Implementation specification Voor de aansluiting op Duitsland is een regionaal profiel (X-GDI metadata profile v1.1) Framework van standaarden

28 Internationale standaarden/specificaties Europese profielen Nederlandse profielen OGC, 2005, OpenGIS Catalogue Services Specification 2.0, ISO 19115/19119: Application Profile for CSW 2.0, version ISO 15836: 2004, Information and documentation The Dublin Core metadata element set 3.6 Toekomstig werk Naast het reguliere beheer zijn de volgende toekomstige activiteiten benodigd: Toevoegen van de metadata elementen voor raster (ISO ) in de Nederlandse metadata standaard voor geografie Integreren van beide Nederlandse metadatastandaarden in één standaard Gebruik van thesauri Framework van standaarden

29 4 Informatiemodellen 4.1 Wat is een informatiemodel? ISO hanteert de volgende definitie voor een informatiemodel (conceptual model): een formele definitie van objecten, attributen, regels in een bepaald domein. De kern van een informatiemodel is dat het een abstractie (het model) vormt van de werkelijkheid zoals beschreven binnen een bepaald domein. Semantiek, of betekenis van data in het model vormt de link met de werkelijkheid. In een informatie-infrastructuur gaat het primair om het betekenisvol uitwisselen van data. Om dit gestructureerd te kunnen doen is het aanbrengen van semantiek vereist. Er zal hierbij een proces van harmonisatie in Nederland en over de grenzen ontstaan Wat is semantiek? Semantiek is niets anders dan betekenis vastleggen van de in een model onderscheiden elementen of objecten. Het is duidelijk dat als gegevens van organisatie A naar organisatie B gestuurd worden, deze gegevens alleen goed geïnterpreteerd kunnen worden als definities van elementen bekend zijn. Neem een informatie-element weg met een attribuut wegbreedte. Als organisatie A een weg definieert inclusief fiets- en voetpaden en organisatie B alleen de rijstroken tot de weg rekent, ontstaat er een verkeerd beeld bij uitwisseling als deze betekenis informatie, de semantiek, niet bekend is. De semantiek moet daarom mee uitgewisseld worden, of bekend zijn. Semantiek omvat niet alleen de definitie van objecten maar ook het gedrag, eigenschappen en relaties tussen objecten dragen bij aan de betekenis. Semantiek is daarmee ook een onderdeel van een informatiemodel. Dat een pand altijd een adres hoort te hebben, dat een kruispunt van wegen gevormd wordt door minsten twee wegen, water bergaf stroomt, etc. zijn hier voorbeelden van Behoefte aan semantiek Voor eenduidige uitwisselingen van geo-informatie, organisatie A begrijpt wat organisatie B bedoelt, moet de semantiek van de gegevens bekend zijn. Wordt op dit moment nog de meeste geo-informatie vrij direct gebruikt door de mens, in de toekomst zal ook een groot deel van de data (eerst) door machines geïnterpreteerd en gebruikt worden alvorens met de mens te communiceren. De mens is (meestal) nog in staat om de verschillende begrippen juist te interpreteren door impliciet gebruik te maken van enige context informatie (welk domein betreft het, welke leveranciers). Voor de machine is het noodzakelijk deze kennis expliciet te maken. Zeker onze netwerk (informatie)-maatschappij, met Internet als belangrijk communicatiemedium, zorgt ervoor dat in toenemende mate zelfverklarende informatie noodzakelijk is. Semantiek is daarom niet alleen van belang voor het begrijpen van informatie door mensen maar ook steeds meer voor machines Afstemming van begrippen en kenmerken: harmoniseren Voor efficiënte bedrijfsvoering en kwaliteitsverbetering hecht de overheid en het bedrijfsleven een groot belang aan het delen en gebruiken van elkanders informatie. De uit te wisselen informatie betreft informatie over het domein waar de organisaties gemeenschappelijk op interacteren. Dit gemeenschappelijke interactiedomein is het domein waarvoor afstemming van begrippen en kenmerken van belang is. Binnen een domein of sector is het al niet eenvoudig om overeenstemming te krijgen over de begrippen en definities, laat staan tussen de verschillende domeinen. In Nederland kennen we verschillende domeinstandaarden (IMRO/ruimtelijke ordening, IMWA/water, IMKICH/cultuurhistorie, TOP10NL/topografie, Framework van standaarden

30 IMKAD/kadastraal, IMKL/kabels en leidingen, IMGeo/geografie, bodem, etc.), waarbij vele partijen binnen een domein na overleg op een begrippenstandaard zijn uitgekomen. Veel van de meer recente domeinmodellen zijn al in UML klasse diagrammen beschreven. Dit is al een eerste stap richting het formaliseren. Overigens is het in internationale context ook belangrijk om dergelijke domeinmodellen internationaal op elkaar af te stemmen (bijvoorbeeld INSPIRE). Dit kan in sommige gevallen tot nog grotere discussies leiden dan welke plaatsvinden op nationaal niveau (omdat daar bijvoorbeeld wet- en regelgeving tenminste voor partijen gelijk is). In de internationale context speelt ook het gebruik van meerdere talen en zal dus voor elk begrip een vertaling gegeven moeten worden. Het zal duidelijk zijn dat in onze netwerk (informatie)-maatschappij in toenemende mate eisen zal stellen aan geformaliseerde betekenis van data. Hoe moeilijk het ook zal zijn, er zal toch getracht moeten worden om tot harmonisatie tussen domeinen te komen Basismodel en sectormodellen Een model is een abstractie van de werkelijkheid voor zover die van belang is voor een bepaald domein. Voor het Basismodel Geo-informatie (NEN 3610) wordt deze werkelijkheid gevormd door alle objecten met een geografische dimensie. Niet al deze objecten hebben voor een sector of een bepaald toepassingsdomein dezelfde relevantie. Binnen het totale geo-informatie werkveld is daarom een onderverdeling ontstaan naar sectoren die elk op hun eigen wijze het model verder invullen. Het Basismodel omvat dan die informatie die voor alle onderliggende sectoren relevant is en waar overeenstemming over bestaat. Als beeld gebruiken we hiervoor het piramidemodel (Figuur 10 Relatie Basismodel en sectormodellen). Figuur 10 Relatie Basismodel en sectormodellen ISO NEN3610 Basismodel Geo-informatie uitwisseling IMRO IMWA IMTOP IMKICH IMWE IMKL IMKAD IMGBR IMGeo IMBOD IMOOV IMGR organisatie modellen In de piramide is er een gelaagdheid van generiek naar sectorspecifiek naar organisatiespecifiek, terwijl dwars daarop de sectoren zijn onderscheiden. Het Basismodel is feitelijk de overlap tussen meerdere of alle sectoren Framework van standaarden

31 en vormt daarmee de gemeenschappelijke basis. Met het Basismodel is het detailniveau te modelleren dat voor alle sectoren van belang is. Dit is ook het detailniveau waarop uitwisseling tussen sectoren plaatsvindt. Binnen de sectormodellen is het detail uitgewerkt dat voor uitwisseling van informatie binnen een sector van belang is. In het onderste deel van piramide, het hoogste detailniveau, is er alleen nog maar sprake van uitwisseling binnen een organisatie. Standaardisatie is in dat geval de verantwoordelijkheid van een organisatie zelf. Tussen de niveaus wordt ook informatie overgedragen. Ook in deze uitwisseling is het van belang dat informatie eenduidig wordt overgebracht. Het domein van het Basismodel Geo-informatie wordt gevormd door het gemeenschappelijke begrippenkader van de sectormodellen. Dit gemeenschappelijke gebied is dynamisch en verandert onder invloed van maatschappelijke processen. Dit is van invloed op de inhoud van de sectormodellen en op de inhoud van het gezamenlijke Basismodel Geo-informatie. Sector- en Basismodel zullen daarom in een voortdurend harmonisatieproces op elkaar afgestemd moeten worden. Een actief beheer van het stelsel van informatiemodellen is daarom noodzakelijk. Harmonisatieprocessen vinden ook plaats op regionaal (FIG), Europees (INSPIRE, Eurogeographics) en mondiaal niveau. Het Basismodel Geo-informatie zorgt voor de aansluiting van nationale modellen op deze internationale ontwikkelingen. De piramide steekt als het ware met de punt in de wolk van internationale geostandaarden Objectgericht Het Basismodel Geo-informatie is objectgericht, dat wil zeggen dat het informatie geeft over individueel te onderscheiden objecten binnen de beschreven werkelijkheid. Het object is de eenheid van informatie. In het Basismodel wordt hiervoor het begrip geo-object geïntroduceerd. De definitie hiervan is: Een geo-object is een abstractie van een fenomeen in de werkelijkheid, dat direct of indirect geassocieerd is met een locatie relatief ten opzichte van het aardoppervlak. De volgende drie termen zijn hierin belangrijk: Fenomeen: Een beschrijfbaar verschijnsel. Object: Een object is een abstractie van een fenomeen in de werkelijkheid. Geo-object: Is een object dat direct of indirect geassocieerd is met een locatie relatief ten opzichte van het aardoppervlak. Een geo-object heeft een directe associatie met een locatie door middel van coördinaten en of een indirecte associatie door middel van een verwijzing naar een adres, een postcode etc Model beschrijving Het Basismodel beschrijft de werkelijkheid aan de hand van een vijftiental geo-object klassen. De hoofdklasse is de objectklasse GeoObject. In deze klasse zijn de basiseigenschappen van een object met geo-informatie vastgelegd. Alle andere objectklassen zijn hiervan afgeleid en erven deze basiseigenschappen. De onderscheiden objectklassen zijn: Geo-Object Terrein Water Weg Spoorbaan Gebouw Kunstwerk Waterkering Leiding Inrichtingselement Registratief Gebied Framework van standaarden

32 Geografisch Gebied Functioneel Gebied Planologische Gebied Meting Relatie met sectormodellen Waar het Basismodel alleen de basisinformatie beschrijft, het intersectorale interactiedomein, gaan sectormodellen het detail uitwerken dat voor een sector van belang is. Waar het Basismodel ophoudt gaan de sectormodellen verder. Dit lijkt een eenvoudige constatering maar is de basis voor de afstemming tussen de modellen Uitwisselingsformaat GML GML in relatie tot NEN 3610 Geography Markup Language (GML) is het bij het Basismodel behorende formaat voor uitwisseling van geoinformatie bestanden. GML is een op XML gebaseerde codering om geografische informatie te modelleren, transporteren en op te slaan. Met GML kunnen zowel de ruimtelijke als de niet-ruimtelijke eigenschappen van geografische objecten beschreven worden. GML is ook een internettaal met als voordeel dat zowel uitwisseling door overdracht als uitwisseling door interactie (web services) worden ondersteund. GML is door zijn structuur zeer geschikt om semantiek uit te wisselen. Daarnaast is GML goed leesbaar voor mensen en computersystemen en laat de structuur zich eenvoudig controleren door het gebruik van generieke open tools. GML is daarom gekozen als het uitwisselingsformaat van het Basismodel. Sinds enkele jaren werken de twee belangrijkste organisaties voor standaarden van geo-informatie ISO/TC 211 en het Open Geospatial Consortium (OGC) samen en hebben ze hun bestaande standaarden geharmoniseerd; GML3.1 is het uitwisselformaat. Ter ondersteuning van de uitwisseling is er een op GML gebaseerd NEN 3610 GML applicatie schema gemaakt. Elke sector die aansluit bij het Basismodel zal GML gaan gebruiken bij de uitwisseling Coderingen Voor veel attributen wordt binnen sectormodellen, bijvoorbeeld TOP10NL, gebruik gemaakt van lijsten met mogelijke waardes. Voor een groot deel zijn deze lijsten gebaseerd op de lijsten zoals gepubliceerd in de NEN 3610:2005. In deze nationale norm zijn alleen waardes opgenomen die algemeen geldend zijn. Binnen het sectormodel (TOP10NL) kunnen deze lijsten uitgebreid worden met de voor die sector specifieke waardes. Deze mogen echter niet in tegenspraak zijn met al bestaande waardes. Zie bijvoorbeeld de lijsten voor TypeLandgebruik van NEN 3610:2005 en TOP10NL in Figuur 11. In een GML document bestaat de mogelijkheid bij iedere waarde te vertellen wie verantwoordelijk is voor de definitie van die waarde. Dit gebeurt door aan een attribuut een CodeSpace toe te voegen. Zo zal het typelandgebruik van een terrein er zo uitzien in GML: <top10nl:typelandgebruik codespace=" Framework van standaarden

33 Figuur 11 Uitbreiding codelijst sectormodel ten opzichte van het Basismodel Aan de nen3610 codespace is nu meteen te zien dat hier heide zoals gedefinieerd door NEN 3610:2005 wordt bedoeld, terwijl een als volgt gecodeerde fruitkwekerij van TOP10NL is: <top10nl:typelandgebruik codespace=" 4.2 Internationale / Europese context Naast de algemene internationale normen en andere standaarden wordt binnen twee Europese projecten hard gewerkt om te komen tot semantische afspraken. RISE RISE staat voor Reference Information Specifications for Europe. Het is een project dat valt onder EuroSpec. Dit project maakt een methodologie en bijbehorende templates voor het harmoniseren van geografische data. Het richt zich vooral op GMES gerelateerde thema s en heeft een sterke link met INSPIRE. Het DT data specifications and harmonisation is direct gekoppeld met RISE. INSPIRE INSPIRE legt een Europese SDI neer waarbij de aandacht vooral ligt op harmonisatie. Het DT data specifications and harmonisation stelt hier standaarden/guidelines/specificaties voor vast. Binnen Nederland wordt door participatie van Nederland (TU-Delft en Geonovum) geborgd dat deze initiatieven naar de Nederlandse situatie vertaald worden (en andersom). De NEN 3610 aanpak die in Nederland al wordt gevolgd is in lijn van INSPIRE en biedt de semantische invulling die van toepassing is op Nederland. 4.3 Referentie model Deze informatie is overgenomen uit het WD (working draft) CEN/TC 287 Geographic information Standards, specifications, technical reports and guidelines, required to implement Spatial Data Infrastructures en beperkt aangepast op de Nederlandse situatie voor een aantal te hanteren standaarden. De namen van de paragraafnamen en standaarden in deze paragraaf zijn in het Engels gehandhaafd om de relatie te laten zien naar het CEN/TC287 document. Framework van standaarden

34 Merk op dat het hier standaarden betreft voor de beschrijving van objectklassen. De standaarden voor ontsluiting van deze gegevens (met behulp van services) worden beschreven in hoofdstuk Objectklassen (Features) ISO geeft de volgende definitie van een geografische objectklasse een abstractie van een fenomeen in de werkelijkheid met een positie relatief ten opzichte van het aardoppervlak. In de praktijk worden hiermee vaak alleen discrete gegevens bedoeld waarvan de positie in de ruimte beschreven worden met behulp van topologische primitieven zoals punten lijnen of vlakken. In het Basismodel Geo-informatie wordt hiervoor de objectklasse GeoObject gebruikt. Tabel 3 Standaarden en specificaties met betrekking tot geo-objecten Objectklassen (features) Internationale standaarden/specificaties Europese profielen 1 Nederlandse profielen informatiemodellen ISO 19101:2002 Geographic Information Reference model ISO/TS Geographic Information - Conceptual schema language. ISO Geographic information - Spatial Schema EN ISO Geographic information -Temporal Schema ISO Geographic information - Rules for application schema ISO Geographic information - Methodology for feature cataloguing ISO Geographic Information Services (in particular the taxonomy of services) ISO Geographic information - Simple features access: Part 1 - Common Architecture ISO Geographic Information - Data product specification INSPIRE: D2.5 Generic conceptual model (zie voor de laatste versie) INSPIRE: D2.6 Methodology for specification development (zie voor de laatste versie) INSPIRE Implementing Rule: D2.7 IR for data exchange (uiterlijk beschikbaar per , zie voor de laatste versie) De norm NEN 3610:2005 Basismodel Geo-informatie Termen, definities, relaties en algemene regels voor de uitwisseling van informatie over aan het aardoppervlak gerelateerde ruimtelijke objecten. NEN3610 is een toepassing van de set aan conceptuele standaarden uit de ISO serie. (zie Profielen op NEN 3610:2005 zijn: IMRO (planologie) IMWA / (UM) Aquo (water) IMKICH (cultuurhistorie) IMKL (kabels en leidingen) IMGeo (grootschalige topografie) IMTOP (topografie: TOP10NL, TOP50NL, TOP100NL, TOP250NL en TOP1000NL) IMGBXXX (grootschalige topografie RWS), in ontwikkeling IMBRON (ondergrond), in ontwikkeling IMWE (welstand), in ontwikkeling IMKAD (kadastrale percelen), in ontwikkeling IMOOV (Openbare Orde en Veiligheid), in ontwikkeling Framework van standaarden

35 Het GML profiel voor Nederland op ISO wordt in januari 2008 vastgesteld en is beschikbaar op 1 Europees profiel of Europese standaard Informatiemodellen ISO/TC 211 heeft verschillende standaarden met betrekking tot conceptuele modellen voor het beschrijven van geografische objectklassen. Conceptual schema language (ISO/TS 19103) geeft de regels en richtlijnen voor het gebruik van een formele taal voor beschrijving van conceptuele modellen binnen de ISO geografische informatie standaarden. Tevens wordt er een profiel gegeven van UML (Unified Modelling Language) voor geo-informatie modellen. UML is gekozen als taal (modelleertaal) voor conceptuele informatiemodellen 8. Spatial Schema (Ruimtelijk Model) (EN ISO 19107) beschrijft een model voor 2- en 3 dimensionale topologie and gerelateerde operaties zoals buffer of intersect (overlap). Rules for application schema (ISO 19109), beschrijft het algemene objectklasse model (general feature model) voor ISO/TC211. Het gebruik van objectklassen, relaties, interfaces en eigenschappen wordt gestructureerd met behulp van klassediagrammen voor data uitwisseling en ontsluiting. Feature cataloguing methodology (ISO 19110), Methode voor opstellen van objectcatalogi, geeft een basis voor het beschrijven van objectklassen in een objectcatalogus. (OGC s Abstract Specification beschrijft hetzelfde onderwerp in de delen Feature and Feature Relationships. De meeste implementaties zijn echter afgestemd op het ISO model). Services (ISO 19119) identificeert en definieert de architecture voor service interfaces zoals gebruikt geoinformatie and definieert de relaties met de Open Systems omgeving. Tevens bevat het een taxenomie voor geografische services en een hierin geplaatste lijst met voorbeelden. Simple Features Common Architecture (ISO ) beschrijft in detail de subset van objectklassen die in de OGC Simple Feature Access Implementation Specification, inclusief de bekende coderingen en een start set voor Ruimtelijke Referentie Systemen. Temporal Schema (EN ISO 19108), beschrijft de representatie van objectklassen in tijd en ruimte. Data product specification (ISO 19131), geeft de basiseisen voor de specificatie van geografische data producten. Hieronder vallen het informatiemodel, ruimtelijke en temporele referentiesystemen, kwaliteit en data inwinning en onderhoudprocessen Implementatie specificaties coderingen De Web Feature Service (WFS) en de Filter Encoding specificaties, specificeren ontsluiting via het web van Simple Features (invoeging, update, delete, query en zoeken). WFS servers dienen in ieder geval GML te kunnen aanbieden als format voor uitgaande berichten. In paragraaf 5.2 is hier meer aandacht voor. 8 Enterprise Architect is door INSPIRE aangewezen als de standaard tool om modellen mee te maken in UML. Deze wordt ook gehanteerd in Nederland. Framework van standaarden

36 ISO Encoding beschrijft de richtlijn voor het afleiden van XML schemas uit UML schemas. ISO en GML zijn niet op elkaar afgestemd; ISO en OGC zijn wel bezig om dat in ISO Geography Markup Language op elkaar af te stemmen. ISO Geography Markup Language geeft de XML codering voor het transport of opslag van geografische informatie gemodelleerd conform het conceptuele framework zoals gebruikt in de ISO serie en omvat ruimtelijke en niet ruimtelijke eigenschappen van geografische objecten Rasterdata (Coverages ) Rasterdata zijn naast vectordata de andere brede groep van ruimtelijke gegevens. Ze beschrijven de eigenschappen van een set van ruimtelijke locaties binnen een bepaald thema. Voorbeelden zijn een rasterkaart met bodemgegevens, vegetatiegegevens, satellietbeelden of een digitaal hoogte model. Door het wijdverspreide gebruik van tele-detectie (remote sensing) beelden, rasterbeelden (beelden conform een rechthoekige matrix van punten, cellen of pixels (picture elements) is dit een belangrijke speciale groep. Tabel 4 Standaarden en specificaties met betrekking tot rasterdata Rasterdata (Coverages) Internationale standaarden/specificaties Europese profielen 1 Nederlandse profielen Informatiemodellen OpenGIS Abstract Specification - Topic 6: The Coverage Type ISO Geographic Information Services INSPIRE: D2.5 Generic conceptual model (zie voor de laatste versie) ISO Geographic Information Schema for coverage geometry and functions ISO Geographic information - Reference Model - Part 2: Imagery INSPIRE: D2.6 Methodology for specification development (zie voor de laatste versie) INSPIRE Implementing Rule: D2.7 IR for data exchange (uiterlijk beschikbaar per , zie voor de laatste versie) 1 Europees profiel of Europese standaard Informatiemodellen Voor het afstemmen van toekomstige ontwikkeling hebben OGC en ISO een zelfde algemene definitie van rasterdata (coverages): De ISO Schema for Coverage Geometry en Functies (ISO 19123) beschrijft de verschillende typen rasterdata. OGC s Abstract Specificaties, Topic 6 (The Coverage Type) omvat en breidt uit op ISO ISO Geographic Information- Reference Model Part 2: Imagery breidt het Reference Model uit naar rasterdata (rasterbeelden). Framework van standaarden

37 Implementatie specificaties Er bestaan verschillende technische formaten voor rasterdata: GeoTIFF (Geo Tagged Image File Format) waarbij georeferentie als tags in de file is opgenomen; SDTS definieert een Raster Profiel en Extensies voor het vastleggen van 2-dimensionale beelden en rasterdata; ISO Basic Image Interchange Format, BIIF, gebruikt door de Amerikaanse Nationale Imagery en Mapping Agency; ISO Geography Markup Language geeft een mechanisme voor het vastleggen van rasterdata; JPEG2000 is de Joint Photographic Experts Group. OGC beschrijft twee specificaties voor ontsluiting van rasterdata: Het Grid Coverages Service Implementation for OLE/COM en CORBA geeft een gedetailleerde interface definitie conform de Abstract Specificaties (binnnen de context van rasterdata) De Web Coverage Service Implementatie Specificatie definieert een web taal voor toegang tot rasterdata. CEN/TC 287 werkt aan een Europees WMS (Web Map Service) profiel van ISO Geographic information Web Map Server Interface. De standaarden voor ontsluiting van rasterdata in een SGA worden beschreven in hoofdstuk Ruimtelijke geo-referentie systemen Ruimtelijke geo-referentie systemen (geospatial reference systems) identificeren locaties met een relatieve positie ten opzichte van de aarde. Dit kan op een directe manier door coördinaten of een indirecte door bijvoorbeeld een adres. De ruimtelijke geo-referentie systemen ondersteunen de meeste geografische data uitwisseling en services. Tabel 5 Standaarden en specificaties met betrekking geo-referentie systemen Ruimtelijke geo-referentie systemen Internationale standaarden/specificaties Europese profielen 1 Nederlandse profielen Informatiemodellen ISO Geographic Information Spatial Referencing by Coordinates ISO/TS Geographic Information Geodetic codes and parameters OpenGIS Abstract Specification - Topic 2: Spatial Reference Systems ISO Geographic Information Spatial Referencing by Geographic Identifiers UN/LOCODE NUTS codes (Nomenclature of territorial units for statistics) Framework van standaarden

38 Ruimtelijke geo-referentie systemen Internationale standaarden/specificaties Europese profielen 1 Nederlandse profielen Implementatie specificaties EPSG database & CRS IDs EUREF (EuroGeographics) De in Nederland gebruikte EPSG codes worden benoemd in de diverse nationale standaarden zelf. ISO 6709 Lat-Lon encoding ISO/TS Geographic Information Geodetic codes and parameters ISO 3166 Countries and subdivisions UN/LOCODE Europees profiel of Europese standaard NUTS codes (Nomenclature of territorial units for statistics) Informatiemodellen NUTS codes (Nomenclature of territorial units for statistics) zijn vervaardigd onder regelgeving (EC) No 1059/2003 van het Europese Parlament. De Code voor Handel en Transport Locaties van de Verenigde Naties (Code for Trade and Transport Locations UN/LOCODE) worden gebruikt om bijvoorbeeld een haven in land uniek te identificeren. Bijvoorbeeld IT_SRE als code voor San Remo in Italië. Coördinaten (numeriek) EN ISO Spatial referencing by coordinates definieert geodetische concepten en parameters, vooral datums en ellipsoids, voor aan de aarde refererende coördinaten systemen en de transformaties tussen verschillende systemen. OGC s Abstract Specification, Topic 2 (Spatial Referencing by Coordinates) is een uitbreiding en een correctie op EN ISO Plaatsnamen en locatieaanduidingen EN ISO Spatial referencing by geographic identifiers beschrijft de relatie tussen geografische posities en geografische aanduidingen (plaatsnamen, adressen die uniek een locatie aanduiden). Vertaling van adres naar geografische coördinaten (gazetteer functionaliteit) kan hiermee ondersteund worden Implementatie specificatie Coördinaten (numeriek) Veel organisaties hanteren specifieke ruimtelijke geo-referentie systemen en systemen voor het vastleggen van coördinaten: De OGC Surveying en Positioning Committee, de vroegere European Petroleum Survey Group, beheert de database van coordinate referentie systemen parameters (datums, ellipsoids, meridianen, eenheden, etc) en relateert deze aan algemeen gebruikte coördinaat referentie systemen (bijv WGS84 UTM Zone 18N meters ). De huidige versie omvat ook gebruikers richtlijnen. Framework van standaarden

39 De Web Map Service en GML specificaties van OGC gebruikt de EPSG parameters en hun identificatie om geo-datasets te bevragen en geo-objecten te beschrijven. De Web Map Service breidt EPSG uit met orthogonale projecties. De Simple Features Access specificaties van OGC voor OLE/COM en SQL geeft een set van datums en ellipsoids, eenheden, projectiles en projectie parameters. OGC s Coordinate Transformation Services specificatie geeft details van Well-Known Tekst (WKT) omschrijvingen van coordinaat referentie systemen (gebaseerd op EPSG) en beschrijft een XML codering. OGC beveelt een specifieke XML codering aan voor coordinate referentie parameters. ISO 6709 specificeert een syntax voor vastlegging van latitude, longitude en hoogte. ISO/TS Geodetic codes and parameters definieert regels voor het invullen van tabellen van geodetische parameters en geeft aanbevelingen voor het gebruik van deze tabellen. Plaatsnamen en locatie-aanduidingen Plaatsnamen en andere indirecte locatie-aanduidingen zijn het onderwerp van verschillende internationale standaarden. ISO 3166 definieert bijvoorbeeld landencodes. 4.4 Te gebruiken standaarden voor Nederland Geo-objecten (features) De te gebruiken standaarden zijn: Basismodel Geo-informatie NEN 3610:2005 Bijbehorende profiel op GML 3.1 schema voor NEN 3610 Profielen op NEN 3610:2005, sommige in ontwikkeling: o IMRO (Ruimtelijke Ordening) o IMWA / (UM) Aquo (Water) o IMKICH (Cultuurhistorie) o IMKL (kabels en leidingen) o IMGeo (grootschalige topografie) o IMTOP (topografie) o IMGBR (RWS) o IMBRON (ondergrond) o IMWE (welstand) o IMKAD (kadastrale percelen) o IMOOV (openbare orde en veiligheid) o Het 0101 uitwisselingsformaat voor digitale uitwisseling van bodemgegevens ( is gestart met het onderzoek naar aansluiting op NEN Rasterdata De standaarden uit het referentiemodel: Toekomstig werk Naast het reguliere beheer zijn de volgende toekomstige activiteiten benodigd: Onderzoek naar bewegende geo-objecten (gestart project ISO moving features) als uitbreiding op NEN XML/GML-validatie breed toepasbaar maken. Mogelijkheid bieden om GML documenten te valideren aan GML schema s. Implementatie van het Basismodel en sectormodellen wordt hiermee ondersteund. Oplevering begin GML was/wordt (benoemd bij RGI-voorstel 116: Verkenning van innovaties bij geo-standaarden voor NGII). Framework van standaarden

40 Visualisatiemodel (benoemd bij RGI-voorstel 116: Verkenning van innovaties bij geo-standaarden voor NGII). Translatie concepten en procedures voor vertaling van informatiemodel naar informatiemodel. De geoinformatie infrastructuur is gebaseerd op uitwisseling conform gemeenschappelijke informatiemodellen. Belangrijk aspect van de implementatie van een dergelijke infrastructuur is vertaling van organisatie specifieke - naar generieke modellen, vertaling tussen sectormodellen en van nationale modellen naar internationale. Ontologische regels voor het vastleggen van de semantiek van geo-objecten dienen verkend en ontwikkeld te worden. Framework van standaarden

41 5 Services Dit hoofdstuk zal nader ingaan op de services. Paragraaf 5.1 geeft een algemene beschrijving over services en de belangrijkste principes, grotendeels gebaseerd op NORA. Paragraaf 5.2 presenteert het referentie model betreffende de beschikbare (OGC) services. Met behulp van een structuur gebaseerd op INSPIRE worden de verschillende van belang zijnde services ingedeeld en gepresenteerd. Per type services wordt vervolgens aangegeven of er Europese of nationale ontwikkelingen zijn. In de paragrafen 5.3 en 5.4 worden de servicelagen business services en procesbesturing behandeld. In het geo-domein is veel discussie over service registers en metadata. Dit is onderwerp van paragraaf 5.5. Binnen een SGA spelen de communicatieprotocollen en formaat en inhoud van berichten uiteraard een grote rol. Paragraaf 5.6 behandelt de uitwisseling van berichten. 5.1 Grondplaat servicelagen Een organisatie die een servicegerichte architectuur wil inrichten moet haar applicatiearchitectuur hiervoor inrichten. Figuur 12 beschrijft de (voorgestelde) applicatiearchitectuur voor een individuele organisatie. Figuur 12 Grondplaat servicelagen Presentatie Service Management Service Register Proces Besturing burger Business services Data services bedrijf Business Service 1 Business Service 2 Data Service 1 Data Service 2 Gegevens Business Service x Data Service x Enterprise service bus ICTU / Kenniscentrum / Architectuur e-overheid 2007 Een applicatiearchitectuur brengt de functionaliteit van een applicatie onder in logische lagen, met gestandaardiseerde interfaces tussen deze lagen. Dit bevordert de flexibiliteit en onderhoudbaarheid doordat wijzigingen die in een laag worden aangebracht geen consequenties hebben voor de overige lagen, zolang de interfaces niet wijzigen. Dit sluit nauw aan bij de servicegerichte benadering. Binnen NORA worden de volgende lagen onderscheiden: Presentatie; Procesbesturing; Businessservices; Framework van standaarden

42 Dataservices. Hieraan is de laag servicemanagement toegevoegd. In dit hoofdstuk worden de lagen en enkele bijkomende componenten kort toegelicht. In de paragrafen 5.2 tot en met 5.6 wordt elke laag verder uitgewerkt, waarbij de geo-standaarden worden benoemd die betrekking hebben op deze laag. Uitwisseling van data loopt via een servicebus. Dit kan worden beschouwd als een elektronische postbode die er voor zorgt dat berichten op een veilige wijze worden uitgewisseld. Fysiek kan een servicebus bestaan uit een stelsel van servicebussen. Binnen een organisatie kan worden gewerkt met een enterprise servicebus, die er voor zorgt dat de verschillende applicaties met elkaar kunnen communiceren. Verschillende organisaties kunnen met elkaar kunnen communiceren via een sectorale of een landelijke servicebus. De laag service bus wordt hier niet verder uitgewerkt maar verzorgt dus in hoofdzaak de logistiek (wijze van afleveren, envelop). GBO maakt hierbij onderscheid in een basis bus die zich richt op het verzorgen van koppelvlakken, beveiliging, betrouwbaarheid en directories en de bus die rijkere diensten ondersteund zoals abonnementen, berichttransformatie en orchestratie. De verwachting is dat de basis bus steeds meer rijkere diensten gaat bevatten op basis van behoefte. Met een register kunnen services kenbaar gemaakt worden. Zo hoeft de aanbieder slechts eenmalig de service te beschrijven en kan de gemeenschap makkelijk kennis nemen van het aanbod. Bovendien zijn deze servicebeschrijvingen een terugkerend element in serviceafspraken. Dit element hoeft daarmee niet in alle afspraken gekopieerd te worden; er kan worden volstaan met een verwijzing naar een serviceregister. Voorbeelden van serviceregisters zijn UDDI, ebrim en CSW. Applicatieservices die ook aangeboden worden aan andere organisaties moeten extern te raadplegen zijn (via een servicebus) Gegevens De gegevenslaag omvat alle gegevens die binnen een organisatie in digitale vorm worden beheerd (databases, filesystemen, documentmanagementsystemen, geo-informatie, metadata etc.) Dataservices De dataservices geven toegang tot de gegevens, al dan niet gemodelleerd volgens de informatiemodellen. Hiermee kunnen gegevens gecreëerd, gemuteerd, verwijderd en geraadpleegd worden. Dataservices kunnen platformspecifiek zijn. Vaak zijn dataservices aanbod gestuurd. Een gebruiker kan een mens zijn of een andere applicatie. De gebruiker moet zich aanpassen aan de dataservices die worden geboden. In de geo-wereld zijn dit bijvoorbeeld web mapping services (WMS) of web feature services (WFS) of dataservices voor metadata (registries) Businessservices Businessservices leveren diensten aan gebruikers (mens of applicatie). Kenmerkend voor een businessservice is dat de gebruiker alleen weet welke prestatie wordt geleverd en niet hoe deze wordt geleverd. Een businessservice hoort zo veel mogelijk platformonafhankelijk te werken door gebruik van open standaarden. Een businessservice hoort vraag gestuurd te zijn: de informatie die wordt geleverd moet toegespitst kunnen worden op het proces waarvoor het gebruikt wordt. De essentie van een service is dat deze gebruikt kan worden door meerdere partijen en eenvoudig gekoppeld en indien nodig ontkoppeld kan worden. Informatiemodellen spelen hierbij een belangrijke rol, omdat daarmee eenzelfde definitie van begrippen tussen de partijen kan worden bereikt. Het is van belang dat de businessservice kan inhaken op een dataservice of gegevensbron via de servicebus. De service is vanuit de SOA-zienswijze dus loosely coupled. In Figuur 12 kunnen de businessservices worden aangesproken, die vervolgens data consumeren uit één of meerdere dataservices. Framework van standaarden

43 5.1.4 Presentatie De presentatielaag zorgt voor de interactie met de gebruiker. Informatie die wordt geleverd door de applicatieservices wordt gepresenteerd op een wijze die is aangepast aan het gebruikte kanaal. Mogelijke kanalen zijn bijvoorbeeld PC, mobiel of palmtop. Belangrijk is dat de presentatie op een eenduidige wijze plaatsvindt door beschikbare standaarden te volgen Procesbesturing Diensten die worden geleverd aan gebruikers maken gebruik van meerdere services. Bij elke dienst die wordt geleverd horen afspraken over de wijze waarop de interactie met de gebruiker moet plaatsvinden. Binnen de eigen organisatie heeft dit consequenties voor het proces dat moet worden gevolg. De procesbesturing zorgt ervoor dat de benodigde services in de juiste volgorde worden aangeroepen. Figuur 13 geeft de relatie tussen diensten, processen en services weer. Figuur 13 Relatie diensten, processen en services In het voorbeeld levert organisatie A een dienst aan burger (of bedrijf). Om deze dienst te leveren zijn meerdere services nodig. In het voorbeeld zijn dit zowel services die door organisatie A worden geleverd als services die door andere organisaties (organisatie B en C) worden geleverd. Elke organisatie richt een proces in om de gevraagde service te leveren. Een proces bestaat uit een aantal processtappen, dat in een vastgestelde volgorde moet worden doorlopen. Organisatie A moet niet alleen een proces inrichten om een service te leveren, maar is ook verantwoordelijk voor het klantproces, waarbij de services van organisaties B en C op het juiste moment worden aangeroepen. Het is dus mogelijk om processen op verschillende niveaus te onderkennen (klantproces, bedrijfsproces, werkproces). Een processtap in een hoog niveau proces (bijvoorbeeld klantproces) kan bestaan uit een laag niveau proces (bijvoorbeeld bedrijfsproces). Organisatie A zorgt er voor dat binnen het klantproces verschillende bedrijfsprocessen op het juiste moment worden gestart. Organisaties B en C zijn zelf verantwoordelijk voor de besturing van de eigen bedrijfsprocessen (namelijk dat de benodigde processtappen in de juiste volgorde worden doorlopen). Framework van standaarden

44 NORA maakt binnen de procesbesturing onderscheid tussen: Besturing van de keten 9 Bij de besturing van de werkprocessen wordt gesproken over orkestratie en choreografie; Besturing van bedrijfsprocessen Hierbij wordt onderscheid gemaakt tussen: - Businessprocesmanagement (BPM): omvat de besturing van volledig geautomatiseerde processen; - Workflow management: besturing van handmatige taken in werkprocessen; WS-BPEL is een schemataal die gebruikt kan worden voor de procesbesturing van bedrijfsprocessen Servicemanagement Een organisatie moet ervoor zorgen dat de diensten en services die worden gebruikt afgestemd blijven op de eisen die de omgeving stelt. Het kan dus voorkomen dat nieuwe services worden gecreëerd en bestaande services worden gewijzigd of verwijderd. Als de organisatie gebruik maakt van een serviceregister heeft servicemanagement publicatiefunctionaliteit nodig. Bij het definiëren van services is semantiek een belangrijk onderdeel. De leverancier en de afnemer van de service moeten dezelfde begrippen gebruiken. Daarnaast moet er continu aandacht aan worden besteed dat services de gevraagde prestaties zo efficiënt mogelijk leveren. Hiervoor is de volgende monitoring nodig: Omgeving Het kan zijn dat de klant andere diensten wenst of dat taakverdeling met ketenpartners wijzigt. Dit kan leiden tot andere eisen aan diensten en/of services; Prestaties en efficiency van geleverde services Bij elke service is vastgelegd welke prestaties geleverd moeten worden. Er moet worden gemonitord of dit het geval is. Bij afwijkingen moet de interne werking van de betreffende service worden aangepast. Daarnaast kan het voorkomen dat het mogelijk wordt de beheerkosten van services terug te brengen, bijvoorbeeld door standaardisatie of nieuwe technologische ontwikkelingen. Hierdoor kan het voordelig worden om een service opnieuw te ontwikkelen, met gelijkblijvende functionaliteit. 5.2 Dataservices In deze paragraaf worden de dataservices voor geo-informatie beschreven zoals benoemd in paragraaf 5.1. De indeling van de dataservices is gelijk aan die van INSPIRE (zie paragraaf 2.1.3). Voor de services wordt een overzicht gegeven van de te gebruiken standaarden voor GI-dataservices. Binnen de geo-wereld worden specificaties voor dataservices ontwikkeld door het OGC. Een aantal daarvan is in de ISO-procedure voor de serie of inmiddels vastgesteld. De interfaces (met operaties als GetCapabilities, GetMap, GetFeatureInfo) met vaste namen worden door het OGC vastgelegd. Door gebruik van deze Open Specificaties wordt de interoperabiliteit gegarandeerd. Deze specifieke operatie kan door alle OGC services van het betreffende type worden uitgevoerd. Dit zijn generieke GI service types die typische GI functionaliteit bieden. Deze service types zijn niet sector specifiek en vallen bij OGC onder de categorie OGC Web Services (OWS) (OGC Web Services Common Specification, Version 1.1.0, OGC , ) Portrayal services Naast Web Mapping Service (WMS) en WMS Styled Layer Description (WMS-SLD) heeft het OGC ook andere portrayal services gedefinieerd, zoals Feature Portrayal Service op basis van de WFS. Omdat deze specificaties nog in discussie zijn en het de vraag is wat met deze specificaties gebeurt, wordt deze (en andere) buiten beschouwing gelaten Een aantal stappen in een vast ingericht proces over 2 of meer organisaties. Zie Framework van standaarden

45 Web Mapping Services Een WMS produceert kaarten of gegeorefereerde data. Een kaart wordt hier gedefinieerd als een visuele representatie van geografische data; een kaart is niet de data zelf. Deze kaarten worden over het algemeen gerenderd naar bitmaps zoals PNG, GIF of JPEG of soms als vector georiënteerde grafische elementen in Scalable Vector Graphics (SVG) of Web Computer Graphics Metafile (WebCGM) formaat. WMS bestaat uit twee componenten, een server en een cliënt. De server ontvangt een request van de cliënt. De response van de server naar de cliënt is een raster image of een XML document. De raster image is gedefinieerd als een Map Layer. Dit is een grafische representatie van de data (bijvoorbeeld in een png of jpeg formaat), en niet de primaire onderliggende data. Figuur 14 Compilatie van map layers in map view op cliënt Een WMS request bevat een of meerdere thema s, geografische parameters en image parameters. Wanneer een WMS request naar meerdere WMS servers wordt verstuurd kunnen verschillende image layers op de cliënt worden gecompileerd. Transparantie van lagen kan in het request worden aangegeven. In de WMS-specificatie worden de operaties (met daarbij: welke input is nodig en welke output moet er komen) gedefinieerd die een WMS moet en optioneel mag aanbieden. Zo moet een WMS de operatie GetMap ondersteunen, waarbij een aantal parameters, bijvoorbeeld over welke kaartlaag, welk gebied, welke weergavestijl en de afmetingen van de kaart, verplicht zijn. Een aantal parameters is optioneel, zoals de tijdsparameter. Er worden daarnaast operaties gedefinieerd voor het beschrijven van de service (GetCapabilities) of het verkrijgen van informatie over een punt op de kaart (GetFeatureInfo). Het OGC heeft momenteel een aantal implementatiespecificaties van de WMS geschreven (versies 1.0 t/m 1.3). Vanuit ISO wordt de abstracte standaard voor WMS beschreven. Omdat er een aantal vrijheidsgraden en een aantal specifiek landelijke zaken zijn voor gebruik van de WMS-specificatie, is er een Nederlands profiel ontwikkeld voor WMS. Hierin zijn zaken beschreven als: het bestandsformaat (in ieder geval PNG) en het coördinaatstelsel (RijksDriehoeksnet). In Nederland is bewust nog niet gekozen voor WMS omdat hier nog vrijwel geen implementaties van zijn. Zie paragraaf voor de te gebruiken standaarden. Voorbeeld Organisatie X (een gemeente bijvoorbeeld) wil data van wegen (bijvoorbeeld de ligging, het type weg en data over de ondergrond) beschikbaar maken als kaartmateriaal middels een webservice. Deze gegevens kunnen dan gebruikt worden als kaartondergrond voor allerlei mappingapplicaties. Men wil in verband met het beheer van de data namelijk voorkomen dat updates verstuurd moeten worden en dat meerdere versies ontstaan (redundantie). De organisatie kan dan besluiten om een WMS in te richten op die data. Door het gebruik van de WMS-standaard kunnen de luchtfoto s in verschillende applicaties (zowel web als desktop) worden opgevraagd en gebruikt. Het beheer en de opslag van de data vind nog steeds op één plek plaats. Overigens, de organisatie Framework van standaarden

46 kan ook nog besluiten de luchtfoto s landelijk te publiceren, zodat ook andere organisaties er gebruik van kunnen maken (al dan niet tegen een vergoeding). Binnen de omgeving van de organisatie, is dan de portrayal service voor de topografische data van wegen deze WMS. Deze service kan hergebruikt worden, in verscheidene applicaties, voor verscheidene doelen (visuele analyses, rapportage, e.d.) Styled Layer Descriptor Styled Layer Descriptor (SLD) is een extensie op de WMS-standaard. SLD verzorgt gecontroleerde cartografie in een WMS requests. Het bevat ook mechanisme voor legenda s en symbolen. De standaard is vrij generiek en daardoor deels afhankelijk van de software/provider. Om deze reden is voor het gebruik van WMS-SLD een Nederlands profiel ontwikkeld. Figuur 15 Door SLD gecontroleerde cartografie De layer en style kunnen van te voren gedefinieerd zijn (respectievelijk NamedLayer en NamedStyle) of zijn door de gebruiker te definiëren (respectievelijk UserLayer of UserStyle). Hierdoor kan de map vanaf de server bestuurd worden of heeft de gebruiker cartografische mogelijkheden. De FeatureTypeStyle geeft de mogelijkheid om de style te definiëren (bijvoorbeeld stippellijn). Met rules kunnen objecten gegroepeerd worden of zijn bijvoorbeeld meerdere presentaties van een object(groep) mogelijk. De filter bevat een query. Met symbolizer wordt de cartografische presentatie van een object(groep) gedefinieerd. Vijf typen symbolisers worden onderscheiden, namelijk: PointSymbolizer, LineSymbolizer, PolygonSymbolizer, TextSymbolizer en RasterSymbolizer Data access services De Data Access Service of toegangsservice is de typering van services die het mogelijk maken lees- of schrijffunctionaliteit te verrichten op geografische datasets, of delen daarvan. Deze toegang is meestal gericht op of beperkt tot individuele objecten. Voorbeeld Organisatie X wil haar data niet alleen als kaarten beschikbaar stellen, maar juist ook de ruwe data. Dit is van belang om twee hoofdredenen. Ten eerste is voor een aantal mapping applicaties functionaliteit gewenst om de attribuutgegevens te bevragen. Ten tweede moeten er gegevens uit een administratief systeem over het Framework van standaarden

47 onderhoud van de wegen gekoppeld worden. Dit administratieve systeem kan niet omgaan met geografische data, maar andersom wil men wel de gegevens van de wegen kunnen raadplegen. Echter, er wordt naar gestreefd om de data maar op één plek op te slaan. De data dient vervolgens toegankelijk te worden gemaakt voor meerdere systemen. Concreet moet de vectordata binnen de SOA-omgeving van de organisatie beschikbaar worden gesteld via een web service, die zowel gebruikt kan worden voor ruimtelijke bevragingen, als voor koppeling aan administratieve gegevens Web Feature Service Web Feature Service (WFS) is een interface voor het opvragen, aanleveren en bewerken van geografische vector data, afkomstig uit databases/files. Het maakt gebruik van de op Extensible Markup Language (XML) gebaseerde Geography Markup Language (GML) voor dataoverdracht. Het OGC heeft momenteel een tweetal implementatie specificaties van de Web Feature Service geschreven (1.0 en 1.1). WFS 1.1 ondersteunt GML die door NEN3610 en de informatiemodellen in Nederland wordt gebruikt. Deze WFS 1.1 specificatie 11 met corrigendum 12 is aangeboden aan ISO TC/211 en wordt uitgewerkt in ISO Deze standaard is in 2009 klaar. Omdat er een aantal vrijheidsgraden en een aantal specifiek landelijke zaken zijn voor gebruik van de WFS specificatie, is er een Nederlands profiel ontwikkeld voor de basis WFS. Een WFS heeft als voordeel in een servicegerichte architectuur dat op XML gebaseerde berichten in GML mogelijk zijn. Met een WFS kunnen de objecten met de attributen uit de data benaderd en bewerkt worden. Het resultaat van een request zijn de objecten die aan de vraagstelling voldoen in GML, dit in tegenstelling tot WMS waarbij een image (plaatje) wordt teruggestuurd. De Web Coverage Service en Web Coordinate Transformation Service zijn beknopt uitgewerkt omdat deze services weinig tot niet geïmplementeerd zijn. Deze beide services worden, vooral vanuit de Nederlandse en INSPIRE context, steeds belangrijker en zullen op het moment dat dit nodig is nader uitgewerkt worden Web Coverage Service De Web Coverage 13 Service is het protocol voor de open uitwisseling van geografische rasterdata, dit in tegenstelling tot de Web Feature Service die functies beschrijft op vectordata. Het verschil is dat rasterdata direct weer te geven is als een kaart via het WCS-protocol. De Web Coverage is vooral geschikt voor grote images. Voorbeelden zijn satellietbeelden, digitale hoogte modellen (DEM) en TIN s. Een WCS geeft toegang tot potentieel gedetailleerde en rijke databronnen, in een formaat wat bruikbaar is voor rendering, coverages met meerdere waarden (multi-valued) en kan dienen als input in wetenschappelijk modellen en andere cliënts. Een WCS kan vergeleken worden met een WMS en een WFS aangezien de cliënt, net als bij de WMS en WFS, in staat is om gedeelten server data op te vragen op basis van geografische en overige criteria Web Coordinate Transformatie service Gezien de variëteit aan coördinaat referentie systemen die in gebruik zijn, is de coördinaat transformatie (herdefiniëring van geografische posities in een nieuw coördinaat referentie system) één van de meest algemeen gewenste geo-processing operaties. Deze transformaties kunnen exact (iteratieve berekening) of een benadering zijn (gebruik van fouten minimalisatie, bij bijvoorbeeld datum verandering). Binnen Europa en de OGC standaarden wordt vaak de EPSG database gevolgd Zie Zie Coverage: feature that acts as a function to return one or more feature attribute values for any direct position within its spatiotemporal domain [19123]. Framework van standaarden

48 5.2.3 Gazetteer services De gazetteer 14 services bieden snelle methodes voor de lokalisering van geografische namen en gebieden zoals bijvoorbeeld adressen of woonplaatsen te vinden binnen gebieden als bijvoorbeeld postcodegebied of administratieve grenzen. Services van het type Gazetteer Service zijn feitelijk een speciaal geval van data access services. Denk hierbij aan de locaties in een gazetteer. Een gazetteer associeert locaties met geografische identificaties met een referentie naar het ruimtelijke object dat de locatie representeert. De gazetteer standaard is een verbijzondering van de WFS. De Gazetteer service is verbijzonderd omdat deze een speciale taak heeft en om compliant te zijn met de INSPIRE architectuur Sensor web services OGC heeft het initiatief genomen voor de ontwikkeling van standaarden voor het zoeken, uitwisselen en verwerken van sensor waarnemingen. De functionaliteiten die binnen dit Sensor Web Enablement (SWE) initiatief bevatten: Het zoeken naar sensor systemen, waarnemingen en waarnemingsprocessen die voorzien in directe informatiebehoefte; Vaststelling van de capaciteiten van de sensoren en de kwaliteit van de waarnemingen; Toegang tot sensor parameters die software toestaan om automatisch gegeorefeerde waarnemingen te verwerken; Verkrijgen van realtime of tijdsinterval observaties en coverages in standaard encodings; Geven van opdrachten en sensoren voor het verkrijgen van de gewenste waarnemingen; Abonneren op en het publiceren van meldingen door de sensoren gebaseerd op zekere criteria. Deze standaarden zijn opgenomen maar worden gezien de huidige status hiervan nog niet nader uitgewerkt Observaties & Metingen (O&M) De algemene modellen en XML encodings voor observaties en metingen door de sensoren Sensor Model Language (SensorML) Standaard modellen en XML Schema voor het beschrijven van de processen in de sensor- and verwerkingssystemen; voorziet in informatie betreffende het zoeken, georefereren en verwerken van observaties. Daarnaast kunnen opdrachten worden gegeven aan sensoren en simulaties Transducer Model Language (TML) Conceptueel model en XML Schema voor het beschrijven van transducers and het ondersteunen van een realtime datastroom van en naar sensorsystemen [OGC ]. Deze standaard is nog niet gepubliceerd op de OGC website Sensor Observation Service (SOS) Dit is geen officiële OGC standaard. An open interface for a service by which a client can obtain observations and sensor and platform descriptions from one or more sensors [OGC ] Sensor Planning Service (SPS) Een open interface van een service waarbij een cliënt (1) de operationaliteit van één of meer sensoren of modellen kan vaststellen en (2) een verzoek van doen aan de sensoren om processen te configureren. 14 A gazetteer is a directory of instances of location types in a spatial reference system [19112]. Framework van standaarden

49 Sensor Alert Service (SAS) Een open interface van een webservice voor het publiceren en abonneren op meldingen van sensoren of simulatiesystemen [OGC ]. Deze standaard is nog niet gepubliceerd op de OGC website Web Notification Service (WNS) Een open interface van een service, waarmee een cliënt asynchroon berichtenverkeer kan voeren met één of meer services Location Based Service (LBS) Op het gebied van LBS zijn de OGC specificaties ingebed in de zogeheten OpenLS standaard. De OpenLS Core Specifications omvatten een pakket van vijf services, die tezamen de GeoMobility Server (GMS) vormen. Deze services zijn: Directory Service Gateway Service Location Utility Service Presentation Service Route Service De Directory Service levert Points Of Interest (POI's) uit. Deze dienst kan gezien worden als een soort Gouden Gids of telefoongids. Bezien vanaf een mobieltje kan deze dienst objecten vinden die zich in de buurt van de gebruiker bevinden, bijvoorbeeld een Pizza Restaurant binnen een straal van 200 meter van de huidige positie of vanaf een andere opgegeven positie, zoals de aankomsthal van het station. Technisch gesproken ontvangt de Directory Service een XML document met de eigenschappen van de (soorten) POI waarnaar moet worden gezocht, en waarin wordt aangegeven of zij zich binnen een zekere afstand van de gebruiker of een ander punt moeten bevinden. De Gateway Service levert posities uit. De interface is gevormd naar de MLP specificatie in OMA (voorheen het LIF, of Location Interoperability Forum). De Gateway Service ondersteunt drie soorten aanvragen: de zogeheten "immediate location request", de "triggered location request" en de "periodic location request". De Gateway Service kan worden bezien als de meest fundamentele en belangrijkste onderliggende service binnen OpenLS. Het levert positiedata, terwijl de andere diensten deze positiedata gebruiken. Een "immediate location request" levert onmiddellijk de positie van een gebruiker of object zodra deze wordt aangevraagd. De enige tijdsvertraging is die welke nodig is om de positiebepaling uit te voeren (in het geval van Cell-ID gemiddeld ongeveer 6 tot 10 seconden). De "triggered location request" is een verzoek om bij te houden wanneer gebruikers of objecten zich in of uit een afgebakend gebied bewegen, of binnen een zekere straal van een ander object of gebruiker. Het betreden en verlaten van zulke zones zorgt dat op dat moment door de Gateway Service een signaal wordt gegeven. Dit concept is ook bekend als "Fencing" ofwel "Geofencing". Volgens de LIF kan een fencing signaal ook gegeven worden door overschrijding van een bepaald tijdstip, maar in OpenLS is hiervoor het "periodic location request" gedefinieerd. De Location Utility Service is eigenlijk een Geocoding Service. Deze service levert, in het geval van 'forward geocoding', coördinaten op die corresponderen met de naam van een naar locatie te vertalen object (bijvoorbeeld een adres). In het geval van 'reverse geocoding' levert het juist de naam op die samenhangt met gegeven coördinaten. In de context van LBS is dit nuttig om voor de gebruiker meer betekenisvolle plaatsbeschrijvingen te genereren. Zo kan het bijvoorbeeld opleveren "Tom bevindt zich op Damrak, Amsterdam" in plaats van "Tom bevindt zich op E, N". De Presentation Service produceert kaarten geschikt voor weergave op het scherm van de gebruiker (mobiele telefoon, PDA, enz.). Op deze kaarten kunnen de posities worden weergegeven van locaties, routes en POI's gevonden door de andere services van OpenLS. Hoewel ditzelfde ook kan worden geïmplementeerd op basis Framework van standaarden

50 van OGC's Web Map Server, heeft de Presentation Service een andere interface die meer geschikt is voor applicaties die op mobiele apparaten draaien. De Route Service produceert routes vanaf een beginpunt (vaak de huidige locatie van de gebruiker) naar een gewenst eindpunt, met de mogelijkheid om onderweg nog een of meerdere andere gekozen punten aan te doen. Hiernaast kan het ook kaarten leveren van deze routes Te gebruiken standaarden Service Internationale standaarden/specificaties Europese profielen Nederlandse profielen Portrayal ISO Geographic Information Portrayal OGC , Proposed OpenGIS OGC Implementation Specification Styled Layer Descriptor Implementation Specification INSPIRE Implementing Rule: D3.7 IR Discovery and view services (uiterlijk beschikbaar per , zie voor de laatste versie) Nederlands WMS SLD profiel 1.0 ( services/standaarden/nede rlands-wms-sld-profiel- 1.0/download.html?Itemid =58) OGC , OGC Implementation Specification, Web Map Context Documents v Encoding: Tag Image File Format for georeferenced raster imagery (GeoTIFF), Scalable Vector Graphics (SVG), Portable Network Graphics (PNG), Joint Photographic Experts Group (JPEG), Computer Graphics Metafile (CGM, WebCGM) OpenGIS Styled Layer Descriptor (SLD) Implementation Specification Web Map Service ISO Geographic Information Web Map Service (WMS) European profile of ISO Geographic Information Web Map Nederlands WMS profile Web Map Context Documents definiëren een XML syntax om kaartafbeeldingen te kunnen creëren, op te slaan en uit te kunnen wisselen vanuit een Web Map Service. Bijvoorbeeld in een service wordt de afspraak over een combinatie van verschillende WMS services en (subset van een) legenda geserveerd volgens Web Map Context Documents. Framework van standaarden

51 Service Internationale standaarden/specificaties Europese profielen Nederlandse profielen OGC r3, OpenGIS Implementation Specification, Web Map Service Implementation Specification OGC , OpenGIS Implementation Specification, OpenGIS Web Map Server Implementation Specification Service (WMS) INSPIRE Implementing Rule: D3.7 IR Discovery and view services (uiterlijk beschikbaar per , zie voor de laatste versie) ( services/standaarden/nede rlands-wms-profiel- 1.0/download.html?Itemid =58) Regionale profiel NL-NRW t/wms_profile.pdf Web Feature Service OGC , OpenGIS Implementation Specification, Web Feature Service Implementation Specification OGC , OpenGIS Implementation Specification, Web Feature Service Implementation Specification INSPIRE Implementing Rule: D3.9 IR Download services (uiterlijk beschikbaar per , zie voor de laatste versie) Nederlands WFS Profiel 1.0 ( services/standaarden/nede rlands-wfs-profiel- 1.0/download.html?Itemid =58) Web Coverage Service , OpenGIS Web Coverage Service (WCS) Implementation Specification (Corrigendum), c1, OpenGIS Web Service Common Implementation Specification, r6, OpenGIS Web Coverage Service (WCS) Implementation Specification, 1.0 Web Coordinate Transformation Service OGC , OGC Discussion Paper, Web Coordinate transformation services draft implementation specification INSPIRE Implementing Rule: D3.10 IR Coordinate transformation services (uiterlijk beschikbaar per , zie voor de Framework van standaarden

52 Service Internationale standaarden/specificaties Europese profielen Nederlandse profielen EN ISO Geographic information - Spatial Referencing by Coordinates laatste versie) Gazetteer EN ISO Spatial referencing by geographic identifiers , Gazetteer service specification, r1, OGC Implementation specification, Gazetteer service - profile of the Web Feature Implementation Specification INSPIRE Implementing Rule: D3.9 IR Download services (uiterlijk beschikbaar per , zie voor de laatste versie) Sensoren OGC r1, OpenGIS Sensor Web Enablement Architecture Document 1.0 OGC r3, Observations and Measurements, OGC , OpenGIS Sensor Model Language (SensorML) Implementation Specification, 1.0 OGC r1, Sensor Observation Service, OGC r1, Sensor Planning Service, OGC r2, Web Notification Service LBS OpenGIS Location Service (OpenLS) Implementation Specification: Core Services (OLS Core), versie 1.1 (05-016) Toekomstig werk Naast het reguliere beheer is het nodig om in de toekomst voor de GI dataservices te werken aan: integratie met WSDL / SOAP webservices (zie ook over de binding in paragraaf 5.6 en bijlage D) 5.3 Business services In deze paragraaf worden de business services beschreven zoals benoemd in paragraaf 5.1. Framework van standaarden

53 5.3.1 Introductie business services Een business service voert (al of niet domein specifieke) bewerkingen uit op de gegevens die worden aangeboden aan de service en levert vervolgens de resultaten weer door. Dus waar de data services alleen in staat zijn om ruwe gegevens op te vragen en door te leveren is een business service in staat om deze gegevens ook te bewerken. Vaak zal een business service een dataservice gebruiken om de invoergegevens op te vragen. Een voorbeeld: Hoeveel personen in Nederland wonen binnen een afstand van 300 meter van een Rijksweg? Een business service die deze vraag kan beantwoorden 16 voert de volgende processtappen uit: 1. Vraag aan een dataservice die gegevens uit het Nationaal Wegen Bestand (NWB) levert om alle Rijkswegen in Nederland; 2. Creëer een buffer van 300 meter om Rijkswegen in Nederland 3. Vraag aan een data service die CBS wijk en buurtstatistieken levert het aantal inwoners per wijk of buurt voor heel Nederland 4. Maak een overlay van de buffer om de Rijkswegen en de CBS buurten. 5. Bepaal in het resultaat van de overlay welk percentage van het oppervlak van iedere wijk binnen de buffer ligt 6. Vermenigvuldig het percentage uit stap 5 met het aantal inwoners per wijk 7. Selecteer de delen van wijken die binnen de buffer liggen 8. Tel alle inwoners voor de selectie uit stap 7 bij elkaar op geef deze door als uitvoer De gegevens kunnen op verschillende manieren worden opgevraagd: Op de W3C manier: Als de dataservice een SOAP service is, zoek dan in de WDSL van die data service op welke functie moet worden aangeroepen 17 om de gegevens op te vragen. De gegevens worden door de dataservice geleverd in een SOAP envelope. Op de OGC manier. Als de dataservice een Web Feature Service is, vraag dan de Features op gebruik makend van Filters o.b.v. de Filter Encoding specificatie. Merk op dat voor WFS ook een SOAP-binding is gedefinieerd, dus dit kan ook via SOAP opgevraagd worden. De bovenstaande service is een service met een grove granulariteit. Dat wil zeggen, de service voert een hele reeks processtappen (buffer, overlay, selectie, vermenigvuldigen, optellen) binnen de service uit die ook als aparte services zouden kunnen bestaan. Als de business service het laatste zou hebben gedaan, dan spreken we van een fijne granulariteit. Een van de krachten van een servicegerichte architectuur zit in het opzetten van (business) services als herbruikbare componenten. De service uit het voorbeeld moet ook in staat zijn hetzelfde proces uit te voeren op provinciale wegen door aan de NWB service de provinciale wegen op te vragen in plaats van de Rijkswegen. Een generieke business service is dus in staat om dezelfde taak uit te voeren met andere parameters. De functies die een business service aanbiedt kunnen op een flexibele manier worden beschreven in een WSDL document. De WSDL standaard definieert hoe de service interface beschreven moet worden, met de bindings en endpoints (waar de service te vinden is). Als een business service wordt uitgebreid met nieuwe functies, worden die nieuwe functies ook beschreven in het WSDL document en kunnen vervolgens worden gebruikt, ervan uitgaand dat men weet wat de betekenis van de functies is. 16 Dit voorbeeld laat meteen zien wat de praktische beperkingen zijn van deze oplossing. Hij genereert een enorme hoeveel datatransport en er moet flink worden gerekend. Een test met lokale data op schijf laat zien dat deze berekening ongeveer anderhalf uur duurt. Om dit soort services ook in de praktijk werkbaar te maken is dus nog meer nodig dan alleen het hanteren van standaarden. 17 (run-time). In de praktijk hoeft dat maar een keer te gebeuren (design time) en niet voor ieder gegevensverzoek Framework van standaarden

54 Merk op dat het aanpassen van WSDL's ook nadelige gevolgen kan hebben voor de gebruikers (machines, applicaties) van de betreffende service. Men dient er namelijk voor te waken dat de bestaande functies niet dusdanig worden aangepast dat gebruikers van de service niet meer goed kunnen functioneren. Een service interface veranderen zal daarom met zorg moeten worden gedaan. Ontwerp van een goede service interface is dus essentieel. De GI services die gebaseerd zijn op OGC standaarden hebben die flexibiliteit momenteel niet, omdat de service interface al (grotendeels) vastligt. Dit is immers onderdeel van de standaard. Dat de service interface vastligt bevordert de interoperabiliteit; er kunnen bijvoorbeeld gemakkelijk kaartlagen van verschillende WMS'en over elkaar worden gelegd, omdat de interface om die kaartlagen op te halen is gedefinieerd in de WMS specificatie. Voor business services is het wenselijk dat de functies (die de service interface vormen) aangepast kunnen worden aan de wensen en eisen vanuit de business. Als business service zijn OGC services meestal dus niet geschikt, maar de OGC services zouden wel als dataservices voor business services kunnen dienen. De business service bevat dan de benodigde logica en maakt gebruik van een of meerdere dataservices. Voor sommige toepassingen kan het gewenst zijn om juist alle functionaliteit (data toegang en logica) in één service in te bouwen. Er is niet eenduidig vast te leggen wat de beste keuze is. Worden generieke data services gebruikt als bouwstenen voor business services, dan kan er (afhankelijk van de logica en de mate van flexibiliteit daarin) ook voor gekozen worden om de logica vast te leggen in bedrijfsprocessen. De koppeling van de services, samen met de logica om gegevens uit de services te verwerken, wordt ook wel aangeduid met web services orchestration. Paragraaf 5.4 over proces besturing behandelt dit onderwerp Het belang van informatiemodellen bij businessservices Voor business services is het essentieel dat een informatiemodel (conform de systematiek van NEN ) aanwezig is dat de semantiek beschrijft. Vanuit dit informatiemodel kunnen afgeleide services betekenisvol gedefinieerd worden (zie Figuur 16). 18 Gezien het belang van de basisregistraties is geconstateerd dat verdere afstemming tussen NEN3610 en STUF-BG noodzakelijk is. Framework van standaarden

55 Figuur 16 Samenhang informatiemodel en services vindbestemmingsfunctieopadres Een ander essentieel voordeel is dat met de Model Driven Approach (MDA) vanuit UML tools zoals Enterprise Architect services direct gedefinieerd kunnen worden waarna vervolgens XML, GML of WSDL automatisch gegenereerd wordt. Door deze aanpak is de samenhang geborgd in het model en met de afgeleide services op basis van het informatiemodel Query taal Binnen OGC kan een OWS service instance domein specifiek gemaakt worden door het gebruik van service beschrijvingen die klasses, attribuutnamen, etc uit het domein zelf gebruikt. Deze beschrijving moet gebeuren op een manier dat de generieke data services deze domein specieke beschrijving kunnen verwerken. Met andere woorden: op een generieke OWS service kan (business) logica toegepast worden, zodat een domein specifieke service wordt gemaakt. Hier kan de OWS Filter Encoding een rol spelen om selecties te maken op data. De domein specifieke functie VindBestemmingsfunctieOpAdres kan bijvoorbeeld worden gemaakt door een soort sjabloon voor een WFS-request te maken, waarbij een Filter wordt opgesteld om alleen dat bestemmingsplan op te halen waar het in te voeren adres in ligt. Dit request wordt, na invulling van het adres, naar een WFS met bestemmingsplannen (een generieke data service) verstuurd en uit het antwoord wordt de Bestemmingsfunctie gehaald. Merk op dat dit een mogelijke implementatie van een business service is, maar dat ook een andere benadering kan worden gekozen. Framework van standaarden