nyuuzyou/wikis huggingface dataset:
Samenwerking GEMMA en GGM

category:Data
==Samenwerking VNG Realisatie (GEMMA) - Gemeente Delft (GGM)==
* GGM neemt het beheer van de logische datamodellen (conform MIM) op zich 
* GGM en VNG ontwikkelen gezamenlijk een koppelvlak voor de GEMMA bedrijfsobjectmodellen (in Archi).
** eerst de CSV-koppeling (gereed)
** vervolgens de UML(MIM) - AMEFF (inclusief de views, nog ter besluitvorming)
* VNG zet een ontologie op die wordt gerelateerd aan de bedrijfsobjectmodellen (nog ter besluitvorming)
* VNG wordt beheerder van GEMMA bedrijfsobjectenmodel
* VNG bepaalt ook de indeling van Bedrijfs- en Dataobjecten van de aangeleverde modellen
* VNG neemt deel aan de expertgroep GGM
Disclaimer: De groep van samenwerkende gemeenten die GGM beheert, blijft verantwoordelijk voor de inhoud van het GGM-model. VNG neem dit model over zoals het wordt aangeleverd en doet daar geen wijzigingen op. Wel zal VNG in overleg gaan om suggesties voor verbeteringen te doen, via de GGM-expertgroep.
Sitemap

Category:Layout Elements
__TOC__
Dit is de inhoudsopgave van GEMMA online. De boomstructuur kun je uitklappen om te zien welke onderwerpen er zijn en uit welke pagina's deze bestaan. 
== GEMMA online ==
: Basisarchitectuur
: Thema-architecturen
: Standaarden paginas
: Projecten
: Over GEMMA
Softwarecatalogus AMEFF export

Category:ArchiMate modelleren
Deze view documenteert de ArchiMate export die de Softwarecatalogus genereert. Alle elementen en relaties die het exportbestand bevat worden in deze view getoond. 
Onder de view vind u tabellen met de definitie en eigenschappen van de objecten en de definitie en eigenschappen van de relaties.
 
==Definitie en eigenschappen van de objecten ==
==Definitie en eigenschappen van de relaties ==
Softwarecatalogus en GIBIT

Categorie:Werken met GEMMA
De GEMMA is een referentiearchitectuur die via de verschillende oplossingen gemeenten helpt om hun ICT landschap op orde te houden of te krijgen. Oplossingen die de GEMMA gebruiken zijn de Softwarecatalogus en de GIBIT. 
== Softwarecatalogus ==
Het doel van de softwarecatalogus is om gemeenten kennis en informatie uit laten wisselen en de gebruikte software te laten vergelijken met andere gemeenten. Daarnaast geeft de softwarecatalogus inzicht in het huidige en toekomstige softwareaanbod van de aangemelde ICT-leveranciers. 
Gemeenten gebruiken de GEMMA Softwarecatalogus bij ICT-vervangings- of investeringsvraagstukken. Zij vergelijken hun ingevoerde applicatielandschap en koppelingen met anderen en zoeken contact met vergelijkbare gemeenten.
 
* Naar de Softwarecatalogus
* Lees de softwarecatalogus export in een architectuurtool
* GGU project de GEMMA Softwarecatalogus
== GIBIT ==
GIBIT staat voor Gemeentelijke Inkoop bij IT Toolbox. Deze uniforme voorwaarden helpen gemeenten bij het professionaliseren van de inkoop van ICT-diensten en –producten. Gemeentelijke diensten digitaliseren steeds verder. Dat maakt professionalisering van inkoop van ICT essentieel. De GIBIT-Toolbox levert hiervoor de basis. Op 14 mei 2021 zijn gemeenten via de ledenbrief Vernieuwde Gemeentelijke inkoopvoorwaarden bij IT Toolbox (GIBIT) geïnformeerd over het belang en de inhoud van de GIBIT.
* Stappenplan gebruik van de GIBIT
* GIBIT Overeenkomstengenerator
* GGU Project GIBIT
Soorten gegevens bij ZGW

Categorie: Zaakgericht werken
__NOTOC__
Bij zaakgericht werken zijn verschillende soorten gegevens te onderscheiden. Per soort gegevens wordt vaak gebruik gemaakt van verschillende referentiecomponenten. Onderstaand diagram toont de verschillende soorten gegevens en de belangrijkste referentiecomponenten die een rol spelen bij het beheer daarvan. 
*Procesgegevens beschrijven hoe een afhandelproces moet verlopen. Voor het beheren van de benodigde (meta)gegevens wordt gebruik gemaakt van een Zaakafhandelcomponent. Bij gebruik van een Generieke Zaakafhandelcomponent zal bij veel processen van een vergelijkbare gegevensset sprake zijn. Bij een Specifieke Zaakafhandelcomponent is vaak sprake van aanvullende procesgegevens, specifiek voor de betrokken zaaktypes.
*Zaakgegevens beschrijven de gegevens die over zaken moeten worden vastgelegd tijdens het afhandelen daarvan. Bijvoorbeeld zaaktype, begin en einddatum, betrokkenen, besluiten, documenten en de doorlopen zaakstatussen. Voor het beheren van deze gegevens gebruiken medewerkers een Generieke of Specifieke Zaakafhandelcomponent. De zaakgegevens worden vastgelegd via de Zakenregistratiecomponent. De zaakgegevens, en hun onderlinge relaties die gemeenten, daarmee samenwerkende organisaties en klanten minimaal nodig hebben zijn beschreven in het informatiemodel RGBZ.
*Zaaktypegegevens zijn gegevens die een groep gelijksoortige zaken beschrijven. Welke gegevens moeten er worden vastgelegd, hoe ziet het afhandelproces er uit, welke regels gelden voor archivering, etcetera. Zaaktypen worden vastgelegd via een Zaaktypenregistratiecomponent in een zaaktyperegister. Applicaties (bijvoorbeeld een Zaakafhandelcomponent) kunnen actuele (en historische) zaaktypegegevens ophalen via de Zaaktyperegistratiecomponent.
*(Zaak)documenten worden tijdens de afhandeling van een zaak binnen de gemeente geproduceerd of van buiten ontvangen. Ze worden als verzameling bij de zaak behorende documenten opgeslagen via de Documentregistratiecomponent. De zaakgegevens die via de Zakenregistratiecomponent zijn vastgelegd en de documenten die via de Documentregistratiecomponent zijn vastgelegd vormen samen het "zaakdossier".
StUF-standaarden

De StUF-standaarden worden gebruik voor het elektronisch uitwisselen van data tussen applicaties van overheidsorganisaties. Bijvoorbeeld voor het uitwisselen van zaakgegevens en data uit basisregistraties. StUf-standaarden zijn gebaseerd op het Standaard Uitwisseling Formaat (StUF). StUF bevat zelf geen berichten maar de bouwstenen en richtlijnen waarmee berichtstandaarden zijn te maken. StUF is beschreven in XML en gebaseerd op geaccepteerde internetstandaarden. 
Verschillende ontwikkelingen maken het vernieuwen van standaarden noodzakelijk om invulling te (blijven) geven aan de behoefte en wensen van gemeenten. De doorontwikkeling van de StUF standaard, de StUF sectormodellen en de StUF koppelvlakken is daarom stopgezet. Alleen wetswijzigingen, wijzigingen in de Logische Ontwerpen van Basisregistraties en gevonden fouten kunnen aanleiding zijn voor een nieuwe versie van deze standaarden. Zo wordt er voor gezorgd dat gemeenten hun werk kunnen blijven doen. De StUF-standaarden worden de komende jaren gefaseerd vervangen door API-standaarden.
Category:Standaarden paginas
StUF familie

Category:Standaarden paginas
In deze plaat wordt de StUF-standaardfamilie in onderlinge samenhang getoond. De gebruikte onderverdeling wordt toegelicht op de pagina gradaties van interoperabiliteit. Onder de naam van de standaard staat welke partij de standaard beheerd. 
Scroll naar beneden voor een tabel met de getoonde standaarden.
Statistieken GEMMA en GGM

category:Data
Een overzicht van de aantallen dataobjecten in GGM en de aantallen bedrijfsobjecten in de GEMMA
* GEMMA (gebaseerd op GGM) kent objecten, waarvan met definitie: 
* De bedrijfsobjecten zijn verdeeld over beleidsdomeinen 
** indeling conform DCAT-DONL, het Nederlands profiel op DCAT (Data Catalog Vocabulary). Door met DCAT datasets te beschrijven in data catalogi, wordt de vindbaarheid vergroot en wordt het eenvoudiger voor applicaties om metadata van meerdere catalogi te gebruiken. DCAT beschrijft dus waar data gevonden kan worden. Doordat DCAT is gebaseerd op het veel gebruikte standaardmodel voor gegevensuitwisseling RDF onderschrijft deze relatie de toegevoegde waarde van de standaard aan interoperabiliteit.
* Voorstel is om het beheer van begrippen in een gemeentelijke ontologie conform SKOS in GEMMA onder te brengen
** en verder conform MIM te gebruiken voor een Model van Begrippen, met de belangrijkste begrippen en hun onderlinge relaties.
** daar waar mogelijk gebruik maken van reeds bestaande definities en deze direct bij de bron te bevragen (op termijn obv Linked Data).
* Uiteraard bestaan er nog tal van andere informatiemodellen die interessant zijn om eventueel mee te nemen. Hiervan is met GGM overeengekomen dat zij de samenwerking met die andere domeinen op zich nemen en al dan niet integreren in het GGM. Voorbeelden hiervan zijn:
** Begrippen Totaal 3D (SOR-begrippen): 
** Ontologie van het inkomensdomein: 
* Verder kennen we nog het GEMMA Begrippenkader, deze telt begrippen, die gaan over de architectuurbegrippen van GEMMA zelf.
Strategie en motivatie

__NOTOC__
Category:Basisarchitectuur
'Strategie en motivatie' beschrijft de strategische richting en keuzes van gemeenten om in lijn daarmee architectuur te kunnen ontwikkelen. De GEMMA volgt hierbij NORA's bindende architectuurafspraken en voegt daar, vanuit gemeentelijk perspectief noodzakelijke, elementen aan toe. In 2023 is door VNG- en gemeentelijke architecten meegewerkt aan het opstellen van de NORA architectuurafspraken en heeft verdere uitwerking daarvan binnen de GEMMA plaatsgevonden. 
Onderstaande afbeelding toont de belangrijkste elementen en hun relaties. Hierbij geldt dat kernwaarden leiden tot een aantal kwaliteitsdoelen. Realisatie van kwaliteitsdoelen wordt ondersteund door gebruik van een set architectuurprincipes. Ieder principe kent een aantal GEMMA implicaties die beschrijven wat het hanteren van een principe in de praktijk betekent.
Technische architectuur

__NOTOC__
De GEMMA technische architectuur beschrijft technologieservices en technologiecomponenten die belangrijk zijn binnen de GEMMA-context. Daarbij gaat het met name om technologieservices die de applicaties en data uit de GEMMA informatie-architectuur ondersteunen. Zij vormen de systeemomgeving waarbinnen gemeentelijke applicaties kunnen werken en data kan worden opgeslagen. 
De GEMMA kende eerder geen aparte technische architectuur. Een beperkt aantal technologiecomponenten werd beschreven in de GEMMA Informatiearchitectuur. Er zijn meerdere redenen waarom technische architectuur nu als apart architectuurproduct binnen de GEMMA is opgenomen: 
* Gemeenten willen (ook) meer standaardiseren qua gebruikte technologie. Bijvoorbeeld door van dezelfde technologieservices gebruik te maken of door technologiestandaarden af te spreken (bijvoorbeeld de Haven-standaard). 
* Gemeenten maken voor technologieservices steeds vaker gebruik van Cloud-voorzieningen in plaats van lokale technologiecomponenten. Bijvoorbeeld voor het uitvoeren van applicaties en het vastleggen van data. Eenduidig beschrijven van technologieservices helpt hierbij. 
* Binnen GEMMA-themarachitecturen speelt technologie regelmatig een rol. Bijvoorbeeld als het gaat over autorisatie of gebruik van API's. Thema-architectuuren kunnen nu verwijzen naar de GEMMA technische architectuur.
De GEMMA technische architectuur is vanaf 2023 onderdeel van de GEMMA Basisarchitectuur. Ontwikkelingen zoals virtualisatie en het gebruik van cloud voorzieningen zorgen ervoor dat de relatie tussen technologieservices en gebruikte hardware minder duidelijk wordt. Bij gebruik van public cloud voorzieningen weten afnemers bijvoorbeeld niet welke hardwarecomponenten daarbij worden gebruikt. Technische architectuur wordt daarom steeds meer in termen van technologieservices beschreven. 
Net als bij de GEMMA Bedrijfsarchitectuur en de GEMMA Informatie-architectuur kent de GEMMA technische architectuur een Achimate-architectuurmodel met als belangrijkste elementen: 
* Technologieservices die technische functionaliteit leveren aan applicaties. Bijvoorbeeld voor verwerking, opslag, netwerk en beveiliging.
* Technologiecomponenten: die de technologieservices realiseren. Bijvoorbeeld een webserver, databasemanagementsysteem, firewall en Intrusion Detection component.
Als binnen projecten de wens bestaat om te beschrijven waar services of componenten zich bevinden, kan gebruik worden gemaakt van andere Archimate- elementen, zoals 'node' of 'device'. .Zie daarvoor het uitgebreide GEMMA kennismodel. 
 
Categorie:Basisarchitectuur
Technologiecomponenten en -services

category:Technische architectuur
De GEMMA technische architectuur beschrijft de technologieservices en technologiecomponenten die worden gebruikt door gemeentelijke applicaties (beschreven in de GEMMA Informatiearchitectuur). Zij vormen de systeemomgeving waarbinnen gemeentelijke applicaties kunnen werken en data kan worden opgeslagen. 
Voor onderstaand architectuurmodel geldt: 
* Er zijn 2 types architectuurelementen uitgewerkt. Technologieservices die technische functionaliteit leveren aan applicaties. Bijvoorbeeld voor verwerking, opslag, netwerk en beveiliging. Technologiecomponenten die de technologieservices realiseren. Bijvoorbeeld een webserver, databasemanagementsysteem, firewall en een Intrusion Detection component.
* Bij het groeperen en benoemen van technologieservices is aangesloten bij wat op dit gebied gebruikelijk is. Bijvoorbeeld door rekening te houden met hoe Cloud-providers door hen aangeboden services indelen en noemen.
* Het model beschrijft de technologieservices en -componenten die binnen de context van de huidige GEMMA het belangrijkst zijn. Om die reden zijn bijvoorbeeld niet opgenomen: op eindgebruikers gerichte services (bijvoorbeeld mail, print, telefonie en samenwerking) en op softwareontwikkelaars gerichte services (bijvoorbeeld voor ontwerp, bouw, test, deployment en versiebeheer).
* Vanwege het ontbreken van een technische architectuur zijn eerder een aantal technologiecomponenten in de GEMMA gemodelleerd als referentiecomponent. De pagina GEMMA mapping op technologiecomponenten toont hoe die worden/zijn omgezet naar technologiecomponenten.
 
 Element 
 Beschrijving
Thema-architectuur

De aanleiding voor het ontwikkelen van een thema-architectuur is verschillend. Er is bijvoorbeeld een grote vraag vanuit gemeenten of nieuwe wetgeving maakt het nodig om bepaalde functionaliteit verder uit te werken. Thema-architecturen zijn onderdeel van de GEMMA. Een thema-architectuur werkt een onderwerp uit vanuit een specifiek perspectief ('viewpoint'). 
De GEMMA basisarchitectuur en bestaande thema-architecturen zijn het vertrekpunt voor een nieuwe thema-architectuur. Er wordt bijvoorbeeld gebruik gemaakt van bedrijfsfuncties of referentiecomponenten, zoals die in de basisarchitectuur zijn opgenomen. Mocht blijken dat binnen de thema-architectuur nieuwe functies of componenten nodig zijn, dan kunnen die later eventueel worden overgenomen binnen GEMMA basisarchitectuur producten.
Thema-architectuur Common Ground

category:Thema-architecturenCategory:Common Ground
__NOTOC__
== Aanleiding ==
Digitalisering heeft gemeenten in staat gesteld om betere dienstverlening aan burgers en bedrijven te leveren. In de loop der jaren is echter een complex informatielandschap ontstaan met 'silo-systemen' waarin functionaliteit en data zijn opgesloten. Samenwerking verloopt daardoor moeizaam is vergt vaak hoge kosten. Gemeenten kunnen hierdoor niet meer goed voldoen aan steeds strengere wordende wet- en regelgeving en worden belemmerd in het bieden van hedendaagse dienstverlening zoals burgers en bedrijven die gewend zijn bij commerciële partijen. 
== Doel ==
Onder de noemer 'Common Ground' werken gemeenten samen met partners aan het realiseren van een fundamenteel andere inrichting van de gemeentelijke informatievoorziening. Doel daarvan is om gemeenten in staat te stellen hun bedrijfsvoering en dienstverlening op een flexibele en verantwoorde manier te kunnen verbeteren. Gemeenten willen zo meer regie krijgen op hun eigen informatievoorziening en de afhankelijkheid van softwareleveranciers te verminderen. Common Ground is onderdeel van de Samen Organiseren-beweging waar gemeenten samenwerken, van elkaar leren en elkaar versterken. 
==Architectuur==
Voor Common Ground is een informatiearchitectuur ontwikkeld waarin functioneel afgebakende applicatiecomponenten gestandaardiseerd samenwerken. Gegevens worden, binnen- en buitengemeentelijk, eenmalig vastgelegd en gebruikt binnen verschillende processen. De informatiekundige visie Common Ground beschrijft de belangrijkste informatiekundige uitgangspunten. Om de benodigde informatiearchitectuur te verduidelijken is het Common Ground vijflaagsmodel ontwikkeld. Dit model toont hoe dienstafnemers en dienstaanbieders samenwerken en welke soorten functionaliteit daarbij nodig zijn. De thema-architectuur beschrijft hoe invulling kan worden gegeven aan benoemde functies.
Om de Common Ground doelen te kunnen realiseren is vergaande standaardisatie nodig. Hergebruik van data vereist afspraken over syntax, semantiek en samenhang van data en voor het effectief hergebruik van data moeten gestandaardiseerde API's beschikbaar zijn. Het liefst met een overheidsbreed karakter maar waar dit (nog) niet kan geldend voor alle gemeenten. Zo wordt het mogelijk om effectief, efficiënt en veilig data uit te wisselen en stapsgewijs samen toe te werken naar optimaal ingerichte gemeentelijke informatievoorziening. Realisatie van de gewenste informatievoorziening is ambitieus en uitdagend en vereist langdurige inzet van alle betrokken partijen. De GEMMA als referentiearchitectuur schrijft niet voor via welke aanpak realisatie moet plaatsvinden maar gezamenlijke kaders en uitgangspunten kunnen daarbij uiteraard wel nuttig zijn. Gemeenten hebben daarom in de vorm van realisatieprincipes beschreven via welke aanpak en werkwijze zij te werk willen gaan.
Thema-architectuur Data

category:Thema-architecturen‎
__NOTOC__
== Aanleiding ==
De rol van data is van cruciaal belang in de moderne samenleving. Data wordt verzameld, opgeslagen, geanalyseerd en gebruikt om inzichten te verkrijgen en verbeteringen te kunnen realiseren. Data neemt zowel toe in omvang als in complexiteit. Van gemeenten wordt verwacht dat ze effectief gebruik maken van betrouwbare data. Ze moeten daarbij op een verantwoorde manier te werk gaan en rekening houden met privacy, beveiliging en ethische aspecten om het vertrouwen van de samenleving te behouden. Data vormt een essentieel onderdeel van de gemeentelijke informatievoorziening en stelt nieuwe eisen aan de gemeentelijke architectuur.
==Doel==
De thema-architectuur Data heeft als doel om gemeenten en leveranciers te helpen bij het inrichten van de gemeentelijke informatievoorziening zodat data optimaal kan worden gebruikt. Bijvoorbeeld voor betere dienstverlening, besluitvorming, innovatie en verbeteren van efficiency.
Het begrip 'data' staat binnen de GEMMA voor het meervoud van 'gegeven': "de weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat". Bij het optimaliseren van datagebruik spelen veel soorten overwegingen en stappen een rol. Deze thema-architectuur werkt een aantal van die aspecten uit en verwijst verder naar plaatsen binnen de overheid waar data-gerelateerde onderwerpen zijn uitgewerkt. 
== Architectuur ==
De GEMMA maakt onderscheid in 'bedrijfsarchitectuur', 'informatiearchitectuur' en 'technische architectuur' (zie Architectuurvisie). De bedrijfsarchitectuur beschrijft onder andere de betekenis van data en de eisen die aan data worden gesteld (bijvoorbeeld binnen bedrijfsfuncties, bedrijfsobjecten en bedrijfsprocessen). De informatiearchitectuur beschrijft hoe data goed is vast te leggen en gebruiken (bijvoorbeeld via standaardisatie van dataontsluiting). Technische architectuur moet borgen dat datagebruik veilig en verantwoord plaats kan vinden (bijvoorbeeld door gebruik van beveiligde verbindingen). 
Deze thema-architectuur wordt stapsgewijs uitgebreid met onderwerpen die generiek van aard zijn. Waar van toepassing wordt daar vanuit de GEMMA-basisarchitectuur en de GEMMA thema-architecturen naar verwezen. 
Hieronder staan bij 'Producten' een aantal binnen de GEMMA uitgewerkte data-gerelateerde onderwerpen. Onder 'Meer informatie' staan verwijzingen naar (ook) voor gemeenten bruikbare uitwerkingen.
Thema-architectuur Duurzame toegankelijkheid

__NOTOC__
==Aanleiding==
Duurzaam toegankelijke overheidsinformatie is bestand is tegen veranderingen van elke aard, en vindbaar, beschikbaar, leesbaar, interpreteerbaar en betrouwbaar voor degenen die er recht op hebben, vanaf het moment van ontstaan en voor zolang als noodzakelijk. Met duurzaam toegankelijke informatie kan de overheid waarde creëren. Voor anderen en voor zichzelf. In het heden en in de toekomst. Het NORA-thema 'Duurzame toegankelijkheid' legt verder uit waarom en voor wie we overheidsinformatie duurzaam toegankelijk bewaren en beheren.
==Doel==
Er zijn drie perspectieven van waaruit duurzame toegankelijkheid belangrijk is.
* Publieke waarde. Vanuit het perspectief van de samenleving, kan overheidsinformatie bepaalde waarde vertegenwoordigen. Door deze informatie duurzaam toegankelijk te maken, stelt de overheid de maatschappij in staat om deze waarde te benutten.
* Legitimiteit. Welke producten en diensten de overheid levert en de voorwaarden waaraan deze moeten voldoen, is vastgelegd in wet- en regelgeving. De principes/ uitgangspunten van duurzame toegankelijkheid van overheidsinformatie dragen eraan bij dat overheidsorganisaties rekening houdend met wet- en regelgeving, op een rechtmatige manier hun taken kunnen uitvoeren en verantwoording hierover kunnen afleggen.
*Organisatie. Duurzame toegankelijke informatie is een belangrijke grondstof voor de overheid. Het is de grondstof voor het leveren van producten en diensten, waarmee de overheid publieke waarde creëert binnen de geldende wettelijke kaders.
==Architectuur==
In deze thema-architectuur is beschreven hoe gemeenten door hen bewaarde en beheerde informatie duurzaam toegankelijk kunnen houden, en hoe deze informatie kan bijdragen aan een meer open overheid. 
Het Actieplan Open Overheid bevat de ambities en acties van het kabinet en haar partners ter bevordering van een open overheid. Het actieplan richt zich op verbetering van de toegang tot overheidsinformatie, het afleggen van verantwoording aan de samenleving en het bevorderen dat de overheid actief en met een open houding de samenwerking met de samenleving opzoekt. Eén van de middelen die hierbij hoort is de Wet open overheid, die overheden (onder andere) verplicht een aantal categorieën overheidsinformatie actief openbaar te maken.
 
Categorie:Thema-architecturen
Thema Locatie en GEO

Categorie:Verouderde thema-architecturen
De plek op aarde waar zich iets of iemand bevindt of waar activiteiten worden gepland of uitgevoerd, speelt een grote rol in de dienstverlening en bedrijfsvoering van een gemeente. Ruimtelijke inrichting, gebiedsgericht beleid, vergunningverlening, toezicht en handhaving zijn immers onderwerpen die een wezenlijk deel uitmaken van de kerntaken van de gemeente. Ook voor niet ruimtelijk gerichte taken kan de ‘aardse locatie’ van belang zijn. Denk bijvoorbeeld aan de beschikbaarheid van voorzieningen als gymzalen, dagbesteding dichtbij degenen die dit nodig hebben of het verdelen van stembureaus over de gemeente. Voor een goede uitvoering van al deze taken is locatie-informatie onontbeerlijk.
Om hieraan invulling te geven heeft KING de handreiking opgesteld. Het verschaft een referentiekader voor een gemeentelijke bedrijfs- en informatiearchitectuur waar ‘locatie’ integraal deel van uitmaakt. Dit is van belang voor degenen die binnen een gemeente betrokken zijn bij het adviseren of beslissen over het ontwerpen en inrichten van organisatie, processen en informatievoorziening waar locatie een rol speelt. 
Dit document is één van de architectuurproducten van de GEMMA-familie. Het verschaft de architectuurkaders voor het omgaan met het locatieaspect binnen GEMMA. 
==Meer informatie==
Genoemde handreiking verschaft u informatie over het benutten van locatie-informatie en de aanpak daarvan. Locatie-informatie speelt her en der in de gemeentelijke taakuitoefening en informatievoorziening een rol. Het is dan ook verwerkt in diverse GEMMA-architectuurproducten. U treft het aan in bijvoorbeeld de Informatie-architectuur en in de diverse standaarden. Zo is de locatie van een zaak een expliciet onderdeel van het RGBZ (informatiemodel zaken) en de Zaak-Document-Services.