From 833bc73b6cdc3b7d9d2c2e4d98db30925ff3767d Mon Sep 17 00:00:00 2001 From: wouterkw <164887573+wouterkw@users.noreply.github.com> Date: Thu, 16 May 2024 08:47:56 +0200 Subject: [PATCH] =?UTF-8?q?Reviewcommentaar=20Dani=C3=ABlle=20verwerkt?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/kader/h/hulpmiddelen.md | 26 ++++++++++++----------- docs/kader/h/inleiding.md | 40 +++++++++++++++--------------------- docs/kader/h/richtlijnen.md | 30 +++++++++++++-------------- 3 files changed, 46 insertions(+), 50 deletions(-) diff --git a/docs/kader/h/hulpmiddelen.md b/docs/kader/h/hulpmiddelen.md index 8b1e12c..8d79bc2 100644 --- a/docs/kader/h/hulpmiddelen.md +++ b/docs/kader/h/hulpmiddelen.md @@ -10,9 +10,9 @@ digiGO heeft een draaiboek laten opstellen waarin stapsgewijs wordt beschreven h Link: Handleiding OTL | IMBOR-LD. -Deze handleiding van CROW beschrijft hoe er op basis van IMBOR-LD een eigen ontologie gemaakt kan worden ten behoeve van uitwisseling tussen opdrachtnemer en opdrachtgever. Hoewel de handleiding dus gericht is op hergebruik van de IMBOR OTL, zijn een aantal van de stappen in deze handleiding zodanig generiek dat ze ook van toepassing zijn bij het opzetten van een algemene OTL. +Deze handleiding van CROW beschrijft hoe op basis van IMBOR-LD een eigen ontologie gemaakt kan worden ten behoeve van uitwisseling tussen opdrachtnemer en opdrachtgever. Hoewel de handleiding gericht is op hergebruik van de IMBOR OTL, zijn een aantal van de stappen in deze handleiding zodanig generiek dat ze ook van toepassing zijn bij het opzetten van een algemene OTL. -De originele vraag voor deze handleiding komt voor uit het BIM Pro-programma van de Provincies. Men wil een OTL kunnen samenstellen die aan de opdrachtgever gegeven kan worden, die deze vervolgens 'invult' en teruglevert. Waarop de Provincie de gegevens kan valideren en inlezen in hun systemen. Het doel (en daarmee de scope) van deze handleiding is dat hiermee een Provincie in staat moet zijn om een OTL op te zetten in een spreadsheet (conventioneel) of LinkedData (duurzaam) formaat. +De originele vraag voor deze handleiding komt voor uit het BIM Pro-programma van de Provincies. Men wil een OTL kunnen samenstellen die aan de opdrachtgever gegeven kan worden, die deze vervolgens 'invult' en teruglevert. Waarop de Provincie de gegevens kan valideren en inlezen in hun systemen. Het doel (en daarmee de scope) van deze handleiding om een Provincie in staat te stellen moet zijn om een OTL op te zetten in een spreadsheet (conventioneel) of LinkedData (duurzaam) formaat. ## Ontwerpnotitie OTL, Provincie Gelderland @@ -30,7 +30,7 @@ Dit document is opgezet ter verduidelijking van de totstandkoming van de Object ## Samenvatting van de Standaard voor het beschrijven van begrippen (SBB) Voor het opstellen van een woordenboek volgen we de SBB. In dit hoofdstuk geven we een korte samenvatting van de SBB. -Merk op dat de SBB voldoet aan de NEN 2660. Een woordenboek opgezet volgens de SBB is dus comform hoe woordenboeken volgens de NEN 2660 moeten worden opgezet. +Merk op dat de SBB voldoet aan de NEN 2660. Een woordenboek opgezet volgens de SBB is dus conform hoe woordenboeken volgens de NEN 2660 moeten worden opgezet. ### Inleiding @@ -39,7 +39,7 @@ De SBB onderscheidt verschillende vormen van woordenboeken: - een taxonomie is een begrippenlijst met hiërarchische relaties. Dit geeft structuur aan het woordenboek en maakt het makkelijker begrippen te vinden; - een thesaurus is een taxonomie met relaties tussen begrippen. Hiermee wordt duidelijk hoe begrippen met elkaar samenhangen. Daarnaast vergroot het de vindbaarheid van begrippen omdat op gerelateerde begrippen kan worden gezocht. -Er zijn geen verplichtingen aan de vorm van een woordenboek. Over het algemeen geldt dat een "rijkere" vorm (dus met meer informatie) meer begrip geeft aan lezers en beter doorzoekbaar is. Het geeft echter ook mogelijk een grotere beheerlast. +Er zijn geen verplichtingen aan de vorm van een woordenboek. Over het algemeen geldt dat een "rijkere" vorm (dus met meer informatie) meer begrip geeft aan lezers en beter doorzoekbaar is. Het geeft echter mogelijk ook een grotere beheerlast. Een woordenboek wordt in de SBB een begrippenkader genoemd. Een begrippenkader is een verzameling van begrippen die in een bepaalde context relevant zijn. Een begrip is een eenheid van denken -- een idee, betekenis of categorisering. Begrippen hebben eigenschappen en onderlinge relaties, o.a. naar brondocumenten. Een brondocument is een resource op het web of een fysiek document dat relevant is voor een begrip. Tot slot zijn er collecties. Een collectie is een verzameling van begrippen die voor een bepaalde situatie betekenisvol bij elkaar passen. @@ -47,22 +47,24 @@ Het gebruik van begrippen en begrippenkaders is verplicht en redelijk evident. E ### Specificatie -De concepten begrip, begrippenkader, brondocument en collectie hebben elk eigenschappen en relaties tot elkaar. Een begrippenkader heeft bijvoorbeeld een naam, een uitleg en een of meer topbegrippen. Deze eigenschappen en relaties zijn uitgebreid beschreven in de SBB. Het model is daarnaast uitgewerkt in RDF, zie onderstaande figuur. +De concepten begrip, begrippenkader, brondocument en collectie hebben elk eigenschappen en relaties tot elkaar. Een begrippenkader heeft bijvoorbeeld een naam en uitleg, en optioneel één of meer topbegrippen. Deze eigenschappen en relaties zijn uitgebreid beschreven in de SBB. Het model is daarnaast uitgewerkt in RDF, zie onderstaande figuur.
Toepassingsprofiel van het SBB in SKOS.
-Zoals kan worden gezien wordt gebruik gemaakt van de volgende taalbinding: +Hierbij wordt gebruik gemaakt van de volgende taalbinding: | SBB-entiteit | Taalbinding in RDF | |--------------|--------------------| | begrippenkader | `skos:ConceptScheme` | | begrip | `skos:Concept`| -| brondocument | `foaf:Document` | +| brondocument | `foaf:Document`** | | collectie | `skos:Collection` | +** Dit ontbreekt in het figuur. + Het figuur laat ook zien welke eigenschappen of relaties verplicht zijn via de cardinaliteit `[1..*]`. Dit lichten we nog eens toe in de volgende subsecties. #### Begrippenkader @@ -73,13 +75,13 @@ Het aangeven van topbegrippen via de relatie "heeft topbegrip" (`skos:HasTopConc #### Begrip -Een begrip (`skos:Concept`) moet minimaal een Nederlandse (`@nl`) voorkeursterm (`skos:prefLabel`) en een definitie (`skos:definition`) hebben. Een begrip moet tot een of meer begrippenkaders behoren via de relatie "in kader" (`skos:inScheme`). Het wordt afgeraden om een naam (`rdfs:label`) te specificeren omdat deze te algemeen is. +Een begrip (`skos:Concept`) moet minimaal een Nederlandse (`@nl`) voorkeursterm (`skos:prefLabel`) en een definitie (`skos:definition`) hebben. Een begrip moet tot één of meer begrippenkaders behoren via de relatie "in kader" (`skos:inScheme`). Het wordt afgeraden om een naam (`rdfs:label`) te specificeren omdat deze te algemeen is. Voor hiërarchische relaties geldt dat deze minimaal vanuit het onderliggende begrip naar het bovenliggende begrip moeten worden aangegeven via de relatie "heeft bovenliggend begrip" (`skos:broader`). -Het aangeven van topbegrippen via de realtie "is topbegrip van" (`skos:topConceptOf`) is niet verplicht omdat deze automatisch kunnen worden afgeleid. +Het aangeven van topbegrippen via de relatie "is topbegrip van" (`skos:topConceptOf`) is niet verplicht omdat deze automatisch kunnen worden afgeleid. -In een thesaurus moeten begrippen een elkaar worden gerelateerd via "is gerelateerd aan" (`skos:related`), "is specialisatie van" (`isothes:broaderGeneric`), "is generalisatie van" (`isothes:narrowerGeneric`), "is onderdeel van" (`isothes:broaderPartitive`), "omvat" (`isothes:narrowerPartitive`), "is exemplaar van" (`isothes:broaderInstantial`) en "is categorie van" (`isothes:narrowerInstantial`). Relatie "is gerelateerd aan" is een generieke vorm van deze relaties, de overige zijn specialisaties van deze relatie. De specialisaties kunnen als "is gerelateerd aan" worden geïnterpreteerd; omgekeerd is dit niet het geval. Het is aan de ontwikkelaar van een woordenboek om de keuze te maken welke relaties hij wil gebruiken: generieke of gespecialiseerde. Het zou goed zijn als de ontwikkelaar deze keuze consequent doorvoert, en niet generieke en gespecialiseerde door elkaar heen gebruikt. +In een thesaurus moeten begrippen aan elkaar worden gerelateerd via "is gerelateerd aan" (`skos:related`), "is specialisatie van" (`isothes:broaderGeneric`), "is generalisatie van" (`isothes:narrowerGeneric`), "is onderdeel van" (`isothes:broaderPartitive`), "omvat" (`isothes:narrowerPartitive`), "is exemplaar van" (`isothes:broaderInstantial`) en "is categorie van" (`isothes:narrowerInstantial`). Relatie "is gerelateerd aan" is een generieke vorm van deze relaties, de overige zijn specialisaties van deze relatie. De specialisaties kunnen als "is gerelateerd aan" worden geïnterpreteerd; omgekeerd is dit niet het geval. Het is aan de ontwikkelaar van een woordenboek om de keuze te maken welke relaties hij wil gebruiken: generieke of gespecialiseerde. Het zou goed zijn als de ontwikkelaar deze keuze consequent doorvoert, en niet generieke en gespecialiseerde door elkaar heen gebruikt. #### Brondocument @@ -87,7 +89,7 @@ Een brondocument (`foaf:Document`) moet minimaal een naam (`dct:title`) hebben. #### Collectie -Een collectie (`skos:Collection`) moet een voorkeursterm (`skos:prefLabel`) hebben. Het gebruik van collecties is volledig optioneel. Een collectie bevat nul of meer begrippen via de relatie "bevat" (`skos:member`). Merk op dat een collectie bepaalt of een begrip lid is van de collectie of niet. Er is geen omgekeerde relatie, d.w.z., een begrip kan zichzelf geen lid maken van een collectie. +Een collectie (`skos:Collection`) moet een voorkeursterm (`skos:prefLabel`) hebben. Het gebruik van collecties is volledig optioneel. Een collectie bevat nul of meer begrippen via de relatie "bevat" (`skos:member`). Merk op dat een collectie bepaalt of een begrip lid is van de collectie of niet. Er is geen omgekeerde relatie, d.w.z. een begrip kan zichzelf geen lid maken van een collectie. ### Voorbeelden @@ -126,7 +128,7 @@ digigo:Bron1 a foaf:Document ; #### Taxonomie -In dit voorbeeld wordt hierarchie gedefinieerd met behulp van `skos:broader`. De topbegrippen zijn aangegeven met `skos:topConceptOf`. +In dit voorbeeld wordt hiërarchie gedefinieerd met behulp van `skos:broader`. De topbegrippen zijn aangegeven met `skos:topConceptOf`, hoewel dit niet verplicht is. ``` @prefix rdfs: . diff --git a/docs/kader/h/inleiding.md b/docs/kader/h/inleiding.md index 26b7539..c473649 100644 --- a/docs/kader/h/inleiding.md +++ b/docs/kader/h/inleiding.md @@ -1,51 +1,45 @@ # Inleiding -Interoperabiliteit in de Ontwerp,- Bouw,- en Technieksector (OBT) is noodzakelijk zodat ICT-opdrachtgevers en -opdrachtnemers eenduidig informatie vastleggen en digitaal kunnen uitwisselen. En daarom is het ook van belang dat Object Type Libraries (OTL) op een eenduidige manier worden opgezet zodat gegevensuitwisseling mogelijk wordt. Voor het ontwikkelen en beheren van OTLlen is het wenselijk om, met alle partijen die een OTL hebben opgezet of gaan ontwikkelen, dezelfde richtlijnen te hanteren. +Interoperabiliteit in de Ontwerp,- Bouw,- en Technieksector (OBT) is noodzakelijk zodat ICT-opdrachtgevers en -opdrachtnemers eenduidig informatie vastleggen en digitaal kunnen uitwisselen. Daarom is het van belang dat Object Type Libraries (OTL) op een eenduidige manier worden opgezet zodat gegevensuitwisseling mogelijk wordt. Voor het ontwikkelen en beheren van OTL'en is het wenselijk om, met alle partijen die een OTL hebben opgezet of gaan ontwikkelen, dezelfde richtlijnen te hanteren. -In de afgelopen jaren is er een grote diversiteit aan OTLlen ontstaan. De diversiteit heeft te maken met het gebruik van definities, de structuur waarmee de OTLlen worden opgezet, de techniek die gebruikt wordt en de manier waarop OTLlen worden ingezet. Om meer eenheid te krijgen in de OTLlen worden er richtlijnen opgezet die helpen bij de beheer en ontwikkeling van de OTLlen. +In de afgelopen jaren is een grote diversiteit aan OTL'en ontstaan. De diversiteit heeft te maken met het gebruik van definities, de structuur waarmee de OTL'en worden opgezet, de techniek die gebruikt wordt en de manier waarop OTL'en worden ingezet. Om meer eenheid te krijgen in de OTL'en worden richtlijnen opgezet die helpen bij het beheer en de ontwikkeling van de OTL'en. ## Waarom richtlijnen Richtlijnen helpen bij knelpunten waar jij in jouw werk mee te maken krijgt. Ze zijn gebaseerd op normen en praktijkervaringen. Richtlijnen helpen jou om keuzes te maken voor de juiste informatiemodellering. Ze zijn, kortom, bedoeld om de kwaliteit van gegevensuitwisseling in de bouw te verbeteren. -De vraag naar richtlijnen komt vanuit zowel opdrachtgevers als opdrachtnemers omdat deze organisaties 'vastlopen' om OTLlen in de praktijk toe te passen. Knelpunten die zijn aangedragen zijn: -- verschil in opvattingen van ‘wat is een OTL’; -- verschillende manieren van informatiemodellering waardoor software telkens opnieuw aangepast moet worden; -- verschil in structuur en opbouw van OTLlen waardoor gegevensuitwisseling niet gestandaardiseerd kan worden; +De vraag naar richtlijnen komt vanuit zowel opdrachtgevers als opdrachtnemers, omdat deze organisaties 'vastlopen' op toepassing van OTL'en in de praktijk. De volgende knelpunten zijn aangedragen: +- verschil in opvattingen over ‘wat is een OTL’; +- verschillende manieren van informatiemodellering waardoor software telkens opnieuw moet worden aangepast; +- verschil in structuur en opbouw van OTL'en waardoor gegevensuitwisseling niet gestandaardiseerd kan worden; - een diversiteit van gebruik van bestandsformaten; - een veelheid van definities van dezelfde objecten; -- geen inzicht en overzicht van bestaande OTLlen. +- geen inzicht en overzicht van bestaande OTL'en. ## Doel en doelgroep -De doelgroep van dit document zijn organisaties binnen de gebouwde omgeving die hun eigen semantische informatiemodellen ontwikkelen en beheren, met name als het gaat om publieke informatiemodellen en organisaties die landelijk actief zijn. Het doel van dit document is om: -1. tot een uniform landschap van informatiemodellen te komen die met elkaar zijn uitgelijnd en aansluiten bij (inter)nationale standaarden, -2. informatiemodellen die volgens een afgesproken kwaliteitsstandaard worden ontwikkeld en beheerd. +Dit document is geschreven voor organisaties binnen de gebouwde omgeving die hun eigen semantische informatiemodellen ontwikkelen en beheren, met name als het gaat om publieke informatiemodellen en organisaties die landelijk actief zijn. + +Het doel van dit document is om (i) tot een uniform landschap van informatiemodellen te komen die met elkaar zijn uitgelijnd en aansluiten bij (inter)nationale standaarden, (ii) informatiemodellen volgens een afgesproken kwaliteitsstandaard te ontwikkelen en beheren. ## Waarop worden richtlijnen gebaseerd? De richtlijnen worden gebaseerd op bestaande standaarden, normen en praktijkervaringen. Dit zijn onder andere: - het Beheer- en OntwikkelModel voor Open Standaarden (BOMOS); - de FAIRQ-principes (Findability, Accessibility, Interoperability, Reusability en Quality); - de NEN-2660 serie, "Modelleringsregels voor informatie in de gebouwde omgeving"; -- Geonovums Standaard voor het beschrijven van begrippen (SBB); -- CROWs Ontology Matching trough alignment and extension: a Best Practice; +- de Standaard voor het beschrijven van begrippen (SBB) van Geonovum; +- de Ontology Matching trough alignment and extension: a Best Practice van CROW; - federatief data delen. -Rijkswaterstaat, Provincie Gelderland en digiGO hebben de NEN 2660 afgekocht en deze NEN norm is tot eind 2025 gratis te downloaden. Dit kan gedaan worden op de website van de NEN, NEN Connect - Home. Op deze website dient u wel eerst een account aan te maken. +Rijkswaterstaat, Provincie Gelderland en digiGO hebben de NEN 2660 afgekocht en deze NEN norm is tot eind 2025 gratis te downloaden op de website van de NEN, NEN Connect - Home. Op deze website dien je wel eerst een account aan te maken. ## Status van dit document Deze richtlijnen worden opgesteld omdat organisatie in Ontwerp,- Bouw,- en Technieksector (OBT) bij digiGO hebben aangegeven dat er veel discussie is -over de ontwikkeling en toepassing van Object Type Libraries (OTLlen). Meerdere organisaties hebben aangegeven 'vast te lopen' bij het gebruik van OTLlen. +over de ontwikkeling en toepassing van Object Type Libraries (OTL'en). Ook hebben meerdere organisaties aangegeven 'vast te lopen' bij het gebruik van OTL'en. -De vorm en inhoud van OTLlen zijn nog niet in een standaard vastgelegd en er is niet een landelijke organisatie die de verantwoordelijkheid neemt voor -het juist en eenduidig ontwikkelen van OTLlen. Vanuit digiGO vinden we het belangrijk om, samen andere met organisaties, gegevensuitwisseling in de -bouwsector te realiseren. Daarom wil digiGO het proces faciliteren om te komen tot eenduidige OTLlen in de bouwsector. +De vorm en inhoud van OTL’en zijn nog niet in een standaard vastgelegd, ook is er geen landelijke organisatie die de verantwoordelijkheid neemt voor het juist en eenduidig ontwikkelen van OTL’en. Vanuit digiGO vinden we het belangrijk om, samen andere met organisaties, gegevensuitwisseling in de bouwsector te realiseren. Daarom wil digiGO het proces faciliteren om te komen tot eenduidige OTL’en in de bouwsector. -De inhoud en inrichting van dit document zal in de loop van de tijd gewijzigd en aangepast worden naar gelang van de ervaringen en praktijktoepassingen in -de OBT. Op het moment dat deze richtlijnen stabiel, gedragen en algemeen geaccepteerd zijn, dan zullen deze richtlijnen aangeboden worden aan het -afsprakenstelsel DSGO. +De inhoud en inrichting van dit document wordt in de loop van de tijd gewijzigd en aangepast naargelang de ervaringen en praktijktoepassingen in de OBT. Op het moment dat deze richtlijnen stabiel, gedragen en algemeen geaccepteerd zijn, dan zullen deze richtlijnen aangeboden worden aan het afsprakenstelsel DSGO. -Bij de opzet van deze richtlijnen wordt uitgegaan van 'collectieve intelligentie' ('wisdom of the crowd'). Dit betekent dat expertise uit de sector gewenst -is om tot betere resultaten te komen. Met een relatief kleine, losse bijdrage kan je al meedoen en zijn we 'samen slimmer'. Je kan meedoen door voorstellen -in te dienen om de richtlijnen te verbeteren. +Bij de opzet van deze richtlijnen gaan we uit van 'collectieve intelligentie' ('wisdom of the crowd'). Dit betekent dat expertise uit de sector gewenst is om tot betere resultaten te komen. Met een relatief kleine, losse bijdrage kun je al meedoen en zijn we 'samen slimmer'. Je doet mee door voorstellen in te dienen om de richtlijnen te verbeteren. \ No newline at end of file diff --git a/docs/kader/h/richtlijnen.md b/docs/kader/h/richtlijnen.md index 0d51ee6..a15b0c9 100644 --- a/docs/kader/h/richtlijnen.md +++ b/docs/kader/h/richtlijnen.md @@ -1,30 +1,30 @@ # Richtlijnen -Dit hoofstuk beschrijft de richtlijnen, verdeeld naar onderwerp. Per richtlijn is aangegeven welke van de FAIRQ-eigenschappen het invult. De F en A gaan voornamelijk over toegang tot en beschikbaarheid van het informatiemodel, de I en R over technische operabiliteit en de Q voornamelijk over de kwaliteit van de beheerorganisatie. +Dit hoofdstuk beschrijft de richtlijnen, verdeeld naar onderwerp. Per richtlijn is aangegeven welke van de FAIRQ-eigenschappen het invult. De F en A gaan voornamelijk over toegang tot en beschikbaarheid van het informatiemodel, de I en R over technische operabiliteit en de Q voornamelijk over de kwaliteit van de beheerorganisatie. -## Richtlijnen om een OTL te ontwikkelen +## Richtlijnen voor het ontwikkelen van een OTL **Waarom** -Het ontwikkelen van een OTL is meer dan een technisch project. Een succesvolle OTL is een OTL die het doel dient waarvoor hij ontwikkeld is, die wordt gevonden, die veel wordt toegepast en hergebruikt, die meebeweegt met de wensen van de gebruikers, waarvoor ondersteuning wordt gegeven, en die langjarig wordt beheerd. Om dit te bereiken is het van belang dat er op het niveau van organisatie en proces de juiste stappen worden gezet. +Het ontwikkelen van een OTL is meer dan een technisch project. Een succesvolle OTL dient het doel waarvoor hij ontwikkeld is, wordt gevonden, wordt veel toegepast en hergebruikt, beweegt mee met de wensen van de gebruikers, wordt ondersteund, en langjarig beheerd. Om dit te bereiken is het van belang om op organisatie- en procesniveau de juiste stappen te zetten. **Richtlijnen** | FAIRQ | Kenmerk | Beschrijving | |---------|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Q | Organisatie | Breng de juiste stakeholders bij elkaar en organiseer samenwerking. Regel mandaat en budget en stel een planning op, en neem hier de beheerfase ook in mee. Zorg dat iedereen die input wil leveren dit ook kan doen, maar regel tegelijkertijd een heldere procedure om tot beslissingen te komen. Voor meer informatie hierover lees [het hoofdstuk over de ontwikkel- en beheerorganisatie](https://gitdocumentatie.logius.nl/publicatie/bomos/verdieping/#de-ontwikkel-en-beheerorganisatie-activiteit-governance) van [BOMOS](https://www.logius.nl/domeinen/infrastructuur/bomos/documentatie). | -| Q | Doel | Formuleer een duidelijk en (liefst) meetbaar doel. Vaak zijn dit doelen als tijds- of kostenbesparing, efficiency, hergebruik van data, automatisering van handelingen, fouten voorkomen, e.d. | -| Q | Scope | Kies een realistische scope die binnen de planning en budget past. Houd de scope beperkt tot bijv. één asset of domein. Maak de scope concreet, praktisch en uitvoerbaar. Formuleer use cases. | +| Q | Organisatie | Breng de juiste stakeholders bij elkaar en organiseer samenwerking. Regel mandaat en budget en stel een planning op, en neem hier de beheerfase ook in mee. Zorg dat iedereen die input wil leveren dit ook kan doen, maar zorg tegelijkertijd voor een heldere procedure om tot beslissingen te komen. Voor meer informatie hierover lees [het hoofdstuk over het opzetten van een ontwikkel- en beheerorganisatie](https://gitdocumentatie.logius.nl/publicatie/bomos/verdieping/#de-ontwikkel-en-beheerorganisatie-activiteit-governance) van [BOMOS](https://www.logius.nl/domeinen/infrastructuur/bomos/documentatie). | +| Q | Doel | Formuleer een duidelijk en (liefst) meetbaar doel. Vaak zijn dit doelen als tijds- of kostenbesparing, efficiency, hergebruik van data, automatisering van handelingen, voorkomen van fouten, e.d. | +| Q | Scope | Kies een realistische scope die binnen de planning en het budget past. Houd de scope beperkt tot bijv. één asset of domein. Maak de scope concreet, praktisch en uitvoerbaar. Formuleer use cases. | | R | Inventariseer informatiebronnen | Inventariseer welke informatiebronnen je nodig hebt om de use case af te dekken. Denk aanbijvoorbeeld wetgeving, normen, domeinstandaarden en referentietabellen. | -| R | Inventariseer bestaande standaarden | Inventariseer welke OTLen en andere standaarden als basis kunnen dienen voor de OTL en bouw hierop voort. Probeer niet het wiel zelf uit te vinden. Zie ook de richtlijnen over eenmaklig registreren. | +| R | Inventariseer bestaande standaarden | Inventariseer welke OTLen en andere standaarden als basis kunnen dienen voor de OTL en bouw hierop voort. Probeer niet het wiel zelf uit te vinden. Zie ook de richtlijnen over eenmalig registreren. | | F/A | Publicatie | Publiceer je OTL online, voorzien van een goede beschrijving en documentatie. Voor meer details hierover zie de richtlijnen voor publicatie. | | Q | Beheer | Beheer je OTL. Maak een planning voor nieuwe versies en houd de planning van onderliggende standaarden/OTLlen in de gaten. Organiseer ondersteuning voor gebruikers. Voor meer details hierover zie de richtlijnen voor beheer. | -## Richtlijnen om een woordenboek op te zetten +## Richtlijnen voor het opzetten van een woordenboek **Waarom** -Een woordenboek is een lijst van termen voorzien een definities, waar mogelijk hierarchisch opgezet en aangevuld met relaties tussen begrippen. Een woordenboek is bedoeld voor mensen om tot overeenstemming te komen over de betekenis van termen en begrippen. Om effectief te kunnen worden gebruikt moet een woordenboek bovendien goed doorzoekbaar zijn. Het is daarom belangrijk dat (i) een woordenboek altijd op dezelfde manier is opgezet en (ii) een woordenboek zo volledig mogelijk is ingevuld, inclusief bijvoorbeeld synoniemen en (niet zichtbare) zoektermen waar op gezocht kan worden. +Een woordenboek is een lijst van termen en definities, waar mogelijk hiërarchisch opgezet en aangevuld met relaties tussen begrippen. Een woordenboek is bedoeld voor gebruikers om tot overeenstemming te komen over de betekenis van termen en begrippen. Om effectief te kunnen worden gebruikt moet een woordenboek bovendien goed doorzoekbaar zijn. Het is daarom belangrijk dat (i) een woordenboek altijd op dezelfde manier is opgezet en (ii) een woordenboek zo volledig mogelijk is ingevuld, inclusief bijvoorbeeld synoniemen en (niet zichtbare) zoektermen waar op gezocht kan worden. **Richtlijnen** @@ -32,19 +32,19 @@ Een woordenboek is een lijst van termen voorzien een definities, waar mogelijk h |-------|----------------------------|-------------------------------------------------------------------------------------------------------| | I | SBB | Het woordenboek is opgezet volgens de Standaard voor het beschrijven van begrippen (SBB) van Geonovum. | | I | Volledigheid | Het woordenboek wordt zo volledig mogelijk ingevuld waarbij bijvoorbeeld gebruikt wordt gemaakt van synoniemen, zoektermen, en wijzigingsnotities. | -| I | Taxonomie | Het woordenboek is hierarchisch opgezet, als taxonomie. | +| I | Taxonomie | Het woordenboek is hiërarchisch opgezet, als taxonomie. | | I | Bronverwijzing | Waar mogelijk wordt verwezen naar openbare bronnen waar een begrip op is gebaseerd, zoals standaarden, wetgeving, etc. | | I | Thesaurus | Begrippen zijn aan elkaar gerelateerd, zoals in een thesaurus. | -## Richtlijnen om een ontologie op te zetten +## Richtlijnen voor het opzetten van een ontologie -Op dit moment ontbreken er nog richtlijnen om een ontologie op te zetten. Er wordt door de NEN-normcommissie Modellering, integratie en interoperabiliteit van informatie in de gebouwde omgeving en procesindustrie gewerkt aan een praktijkrichtlijn voor de NEN 2660. De verwachting is dat deze in 2024 wordt gepubliceerd. +Op dit moment ontbreken nog richtlijnen om een ontologie op te zetten. De NEN-normcommissie Modellering, integratie en interoperabiliteit van informatie in de gebouwde omgeving en procesindustrie werkt aan een praktijkrichtlijn voor de NEN 2660. De verwachting is dat deze in 2024 wordt gepubliceerd. ## Richtlijnen voor eenmalig registeren, meervoudig gebruik. **Waarom** -Dubbele registraties, overtypen van gegevens en dubbele softwareontwikkelingen zijn een bekend probleem. Daarom is het van belang om gezamenlijk te werken met dezelfde gegevens en definities. Daarmee wordt het mogelijk om eenmalig te registreren en meervoudig gebruik mogelijk te maken. +Dubbele registraties, overtypen van gegevens en dubbele softwareontwikkelingen zijn een bekend probleem. Daarom is het van belang om gezamenlijk te werken met dezelfde gegevens en definities. Daarmee wordt het mogelijk om eenmalig te registreren en meervoudig te gebruiken. Het opstellen van een goede OTL heeft als randvoorwaarde dat de opgenomen concepten/objecttypes, definities en kenmerken herkenbaar zijn, binnen en buiten de eigen organisatie. Om dit te bewerkstelligen is het belangrijk om zoveel mogelijk gebruik te maken van marktconforme standaarden. Het wiel is vaak voor een groot deel al uitgevonden. @@ -125,7 +125,7 @@ Bij harmonisatie wordt er een mapping gemaakt tussen twee woordenboeken of tusse **Waarom** -Om een OTL te kunnen gebruiken moet allereerst: +Om een OTL te kunnen gebruiken, moet: - de OTL makkelijk te vinden zijn; - de OTL makkelijk te begrijpen zijn; er moet zijn beschreven voor wie en voor wat deze bedoeld is; - de OTL makkelijk beschikbaar zijn; d.w.z. te bekijken en te downloaden; @@ -153,7 +153,7 @@ Dit is gevat in onderstaande richtlijnen. **Waarom** -Gebruikers van een OTL stemmen hun processen en systemen af op de OTL en zijn daarmee op een hele directe manier afhankelijk van hoe de OTL beheerd wordt. Goed beheer is daarom er belangrijk. Versiebeheer moet op orde zijn; er moet bewust worden omgegaan met de impact die wijzigingen kunnen hebben voor gebruiker; (grote) wijzigingen moeten worden aangekondigd; en wijzigingen tussen versies moeten goed zijn gedocumenteerd. +Gebruikers van een OTL stemmen hun processen en systemen af op de OTL en zijn daarmee op een hele directe manier afhankelijk van hoe de OTL beheerd wordt. Goed beheer is daarom er belangrijk. Versiebeheer moet op orde zijn; er moet bewust worden omgegaan met de impact die wijzigingen kunnen hebben voor gebruikers; (grote) wijzigingen moeten worden aangekondigd; en wijzigingen tussen versies moeten goed zijn gedocumenteerd. Dit is gevat in onderstaande richtlijnen.