Reviewcommentaar Daniëlle verwerkt

docs/kader/h/hulpmiddelen.md

@@ -10,9 +10,9 @@ digiGO heeft een draaiboek laten opstellen waarin stapsgewijs wordt beschreven h
 
 Link: <a href="https://docs.crow.nl/imbor/handleiding-otl/">Handleiding OTL | IMBOR-LD</a>.
 
-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 <a href="https://docs.geostandaarden.nl/nl-sbb/nl-sbb/">SBB</a>. 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,30 +39,32 @@ 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.
 
 Het gebruik van begrippen en begrippenkaders is verplicht en redelijk evident. Elk begrip behoort tot minimaal één begrippenkader. Begrippen kunnen worden gebruikt in meerdere begrippenkaders. Als een begrip in een document wordt beschreven (wetgeving, standaarden, etc.) dan is het goed daar naar te verwijzen via een brondocument (maar dit is niet verplicht). Merk op dat een brondocument hier een beschrijving is van (incl. verwijzing naar) het eigenlijke brondocument. Een collectie bevat nul of meer begrippen. Het gebruik van collecties is optioneel. Collecties zijn geen onderdeel van een begrippenlijst, taxonomie of thesaurus. We besteden hier weinig aandacht aan het gebruik van collecties.
 
 ### 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. 
 
 <figure id="figure">
   <img src="figures/skos-ap-nl.png"/>
   <figcaption>Toepassingsprofiel van het SBB in SKOS.</figcaption>
 </figure>
 
-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,21 +75,21 @@ 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
 
 Een brondocument (`foaf:Document`) moet minimaal een naam (`dct:title`) hebben. Het gebruik van bronnen is niet verplicht. Het is goed om bronnen te gebruiken en deze van een bronverwijzing (`dct:bibliographicCitation`) of url (`foaf:page`) te voorzien als begrippen gebaseerd zijn op externe bronnen. 
 
 #### 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: <http://www.w3.org/2000/01/rdf-schema#> .

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 <a href="https://www.go-fair.org/fair-principles/">FAIR</a>Q-principes (Findability, Accessibility, Interoperability, Reusability en Quality);
 - de <a href="https://www.nen.nl/modellering-integratie-en-interoperabiliteit-van-informatie-in-de-gebouwde-omgeving-en-procesindustrie">NEN-2660 serie</a>, "Modelleringsregels voor informatie in de gebouwde omgeving";
-- Geonovums <a href="https://profielstelselcatalogus.pldn.nl/">Standaard voor het beschrijven van begrippen (SBB)</a>;
-- CROWs <a href="https://docs.crow.nl/ontology-alignment/whitepaper/">Ontology Matching trough alignment and extension: a Best Practice</a>;
+- de <a href="https://profielstelselcatalogus.pldn.nl/">Standaard voor het beschrijven van begrippen (SBB)</a> van Geonovum;
+- de <a href="https://docs.crow.nl/ontology-alignment/whitepaper/">Ontology Matching trough alignment and extension: a Best Practice</a> van CROW;
 - <a href="https://www.digigo.nu/digitaal-stelsel/waarom-dsgo">federatief data delen</a>.
 
-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, <a href="https://urldefense.com/v3/__https://connect.nen.nl/Home/Detail__;!!NFFV0PM8bbqw!M5JuU5t0-AzxNzYr1PWA33tQIbT0IAFveLFdgD24P66VGyfZjurAmpzO2mWRs4Rc_B1BtfGe_fAWwVKIUU-TlKVXS0RZtntAGvtxKpM$">NEN Connect - Home</a>. 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, <a href="https://urldefense.com/v3/__https://connect.nen.nl/Home/Detail__;!!NFFV0PM8bbqw!M5JuU5t0-AzxNzYr1PWA33tQIbT0IAFveLFdgD24P66VGyfZjurAmpzO2mWRs4Rc_B1BtfGe_fAWwVKIUU-TlKVXS0RZtntAGvtxKpM$">NEN Connect - Home</a>. 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.
 
 <!-- GitHub Issues wordt gebruikt voor de discussie van dit document. Eén issue per onderwerp vereenvoudigt de verwerking. -->