Voor modelleerprincipes verwijzen naar versies 1.n

gwsw ontologie 2.0.md

@@ -203,236 +203,7 @@ Voor de concepten en relaties uit de GWSW-Ontologie hanteren we in de voorbeelde
 
 # Modelleerprincipes - Algemeen
 
-Een groot deel van de gehanteerde modelleerprincipes stammen uit de oorspronkelijke opzet (gestart in 2006) van het datamodel in Gellish-vorm. Deze principes zijn natuurlijk taalonafhankelijk, ook in de RDF-vorm blijven ze van groot belang. Veel dank gaat naar Andries van Renssen, geestelijk vader van Gellish en Matthé van Koetsveld, intensief betrokken bij de modellering in Gellish van het GWSW en zijn voorlopers.
-
-## Reikwijdte datamodel
-
-Het GWSW Datamodel volgt de ontwikkelingen in het vakgebied. Het bevat concepten die actief worden toegepast (in uitwisseling en applicaties) of die in ontwerpen voor toepassing (bijvoorbeeld nieuwe uitwisselvormen) zijn opgenomen. Dat geldt ook (en vooral) voor kenmerken van objecten.  
-Terminologie waarbij het uitsluitend gaat om vastleggen van definities wordt met terughoudendheid opgenomen, maar het GWSW heeft zeker ook een woordenboek-functie.
-
-Bij het ontwerp van het GWSW Datamodel spelen altijd de volgende **invalshoeken** mee:
-* Wordt het concept algemeen gebruikt in - native - databases, wordt het (straks) uitgewisseld via GWSW Datasets
-* Welke gevolgen heeft de aanpassing voor de toepassingen:
-  * Externe applicaties die GWSW Datasets gebruiken
-  * De geografische presentaties (en onderliggende queries)
-  * De uitwisselformaten HydX, RibX
-  * De kwaliteitsmetingen van datasets: dataverificatie met Nulmeting, SHACL
-* Zijn de aanpassingen relevant voor het GWSW als naslagwerk en woordenboek
-
-**"As is", de momentopname**  
-Het datamodel beschrijft de "as is" situatie, het bevat een momentopname van systemen en processen binnen de discipline stedelijk water. Het beschrijft dus geen historische gegevens of de levenscyclus van objecten zoals bij bitemporeel datamanagement of binnen de context van system engineering.
-
-<div class="box"><strong>Versioning objecten in IMBOR</strong>
-
-IMBOR bevat vanaf 2024 een kader voor versionering van objecten (implementatie NEN 3610: temporele aspecten). Het moet tussen IMBOR en GWSW duidelijk zijn of deze tijdlijngegevens wel of niet tot de alignment gaan behoren.
-</div>
-
-## Structureren
-
-Zoals genoemd is de datastructuur object-georiënteerd waarbij objecten in een aantal hoofdstructuren zijn ondergebracht:
-
-* Soortenboom: de taxonomie of klasse-indeling
-* Samenstelling: de meronomie of (typische) deel-geheel indeling
-* Proces: de activiteiten-schema's
-* Groeperingen: collecties van concepten (individuen en klassen)
-
-Bij het ontwerp spelen deze structuren de hoofdrol, ze vormen het ontwerpkader. Met het principe van object-oriëntatie hanteert het datamodel overerving-principes en maakt zo expliciet mogelijk onderscheid in (relaties tussen) subtypes.
-
-<div class="box"><strong>Voorbeelden:</strong>
-
-Afgeleide gegevens komen niet voor in de definitie van fysieke objecten, bijvoorbeeld het kenmerk "aantal pompen". Zo'n gegeven wordt (in presentaties) afgeleid uit het aantal voorkomens van de relatie <span class="blue">heeft deel</span> tussen Gemaal en Pomp. De objecten Gemaal en Pomp worden expliciet beschreven.  
-
-Afgeleide gegevens zoals rekenresultaten en data-analyses komen in het GWSW wel voor in de vorm van gemodelleerde rapportages, bijvoorbeeld in GWSW Kengetallen. 
-
-Eigenschappen van de bovengrond en ondergrond (maaiveldhoogte, grondsoort) komen niet voor als aspecten van de fysieke objecten die zich daarin bevinden. Een leiding heeft niet als kenmerk "Grondsoort", wel wordt er een relatie <span class="blue">is deel van</span> met de ondergrond - en dus met bijbehorende kenmerken - gedefinieerd.
-
-<strong>Consistentie met topmodel IMBOR</strong>
-
-Met het GWSW als onderdeel van IMBOR is hier meer integratie binnen het topmodel nodig. In IMBOR is bijvoorbeeld Beheerder een kenmerk van de top-level-klasse FysiekObject terwijl in het GWSW de klasse Beheerder een subtype van Levensvorm is met <span class="blue">heeft invoer</span> het FysiekObject.  
-Het streven is om de concepten op topniveau op gelijke wijze te modelleren, als die integratie niet volledig lukt moet de afstemming minstens via alignment worden bereikt. Op discipline-niveau (de specialisaties van de top-level-klassen) is er natuurlijk meer modelleervrijheid.
-</div>
-
-## Concepten en annotaties
-
-1. Elk GWSW-concept is van het generieke type owl:Class (en dus van het type rdfs:Class).
-2. Een concept en elke CE wordt altijd voorzien van de annotaties zoals opgenomen in hst [Details annotaties](#details-annotatie-attributen)
-3. Voeg zoveel mogelijk extra informatie toe zoals afbeeldingen (verwijs via <span class="blue">rdfs:seeAlso</span>)
-
-## Naamgeving
-
-_Terminologie_
-
-Zie hst [Identificatie van concepten](#identificatie-van-concepten)
-
-1. Een concept wordt geïdentificeerd door een URI (namespace + naam)
-2. Volg de gebruikelijke termen binnen het vakgebied, bedenk geen nieuwe conceptnamen die misschien de lading beter dekken of neutraler zijn. Dat geldt ook - waar mogelijk - voor abstracte concepten.
-3. Voorkom zoveel mogelijk het gebruik van handels- of merknamen in de conceptnamen.
-4. Geef alle gebruikelijke vakgebied-termen die gelden voor het te modelleren systeem of proces een plek, als apart concept of als synoniem van een concept. De zoekfunctie wordt daarmee volledig.
-5. Laat algemene termen die niet specifiek bij de discipline horen zoveel mogelijk buiten beschouwing. Modelleer bijvoorbeeld het concept "calamiteit" alleen als het als supertype nodig is.
-6. Verwijs voor algemene termen waar mogelijk naar andere databronnen (<span class="blue">rdfs:seeAlso</span>).
-
-## Data-afleiding en -verificatie
-
-Bij de definitie van klassen ligt de focus op data-afleiding (determinatie). Definieer klassen zo uitgebreid mogelijk op basis van hun eigenschappen. Daarmee worden datasets op basis van het datamodel ruimer interpreteerbaar en beter verifieerbaar. Hier volgt een opsomming van de mogelijke afleidingen (inferences) en uit de CE's afgeleide validaties. In enkele gevallen is reasoning op basis van het UNA principe nodig. De controle op kardinaliteit is beperkt vanwege het OWA principe in RDF.
-
-* Controle op referentie-waarden binnen domein van collecties / keuzelijsten (CWA/UNA)
-* Controle op correcte typering binnen samenstellingen via "heeft deel" relatie.
-  - Ruimte heeft deel “object” => object is van de klasse Ruimte of FysiekObject
-  - FysiekObject heeft deel “object” => object is van de klasse Ruimte of FysiekObject
-* Inferencing: Individu-klasse wordt afgeleid uit intrinsiek kenmerk.
-  - individu heeft kenmerk "breedte leiding" => individu is van de klasse Leiding
-* Inferencing: Individu-klasse wordt afgeleid uit onderscheidend kenmerk.
-  - individu heeft uitvoering "klein" => individu is van de klasse KleinObject
-* Controle op correct gebruik datatype bij "heeft waarde" (datatypes decimal, string, integer, double, date, time, year).
-* Controle op numerieke waarden binnen minimum en maximum grenzen
-* Kardinaliteit, aantal voorkomens van de relatie of attribuut boven het voor het subject gedefinieerde maximum (CWA/UNA).
-  - ook “inverse”-kardinaliteit wordt in de reasoning meegenomen
-  - minimum kardinaliteit en shall-relatie wel gemodelleerd, controle op strijdigheid met typering niet mogelijk (OWA)
-
-## Soortenboom
-
-<br/><img src="media/taxonomie.png" style="width:50%;" />
-
-<div class="box"><strong>Tips bij opbouw taxonomie (bron: Bart Bink)</strong>
-
-- basis is overerving, ook meervoudig (multiple inheritance)
-- start met de class die je kent
-- plaats ze in een hiërarchie door subtypering (taxonomie)
-- geef aan in definitie waarin de class zich onderscheidt van de bovenliggende class
-- geef aan in eigenschappen waarin de class zich onderscheidt van de bovenliggende class en omliggende classes
-- let op orthogonaliteit (speelt in het GWSW minder een rol, zie <a href="#orthogonaliteit">Orthogonaliteit</a>)
-- plaats een eigenschap (kenmerk) zo hoog mogelijk
-</div>
-
-### Definiëren klassen
-
-Definieer zo min mogelijk supertypes, neem ze alleen opgenomen indien noodzakelijk voor de indeling (ervingsprincipe) of als de klasse voorkomt als gebruikelijke term (woordenboek-functie).
-
-Bouw de soortenboom op basis van onderscheidende kenmerken, zie hst [Details onderscheidende kenmerken](#details-onderscheidende-kenmerken).
-
-1. Voor het classificeren van een concept uitgaan van onderscheidende kenmerken in de (abstracte) soortenboom. Denk aan determineren van planten volgens Linnaeus: na het maken van een aantal keuzes wordt de soort gevonden
-2. Streef ernaar om met de onderscheidende kenmerken de (in je hoofd) uitgeschreven definitie te vervangen
-3. Gebruik de beschreven onderscheidende kenmerken bij fysieke objecten en activiteiten
-4. Kwalificeer het onderscheidende kenmerk impliciet (gwsw:uitvoering "groot"). Expliciete kwalificaties (in de vorm van subtypes van generieke kenmerken) worden dus (nog) niet gebruikt
-
-### Abstracte klassen
-
-*Hier verstaan we onder "abstract" de klassen (en collecties) die niet voor classificatie worden gebruikt / niet instantieerbaar zijn*
-
-1. Hou ze beperkt, hou de soortenboom zo veel mogelijk concreet. Supertypes zijn vaak alleen verdichtingen, geen soort dus abstract.
-2. Concepten zijn herkenbaar als abstract wanneer ze bijvoorbeeld niet in de deel-geheel relaties (bijvoorbeeld als deel van een rioleringsgebied) voorkomen.
-3. Abstracte concepten bij voorkeur als groep/collectie (en niet als supertype) definiëren. Bijvoorbeeld groepering naar thema's, denk aan infiltratievoorzieningen.
-4. Subtypes op hetzelfde niveau dienen in grote lijn hetzelfde samenstellingsniveau te hebben.
-
-<div class="box"><strong>Oormerken met behulp van conformiteitsklassen</strong><br/>
-In deelmodellen met conformiteitsklassen (CFK) worden abstracte klassen gemarkeerd en daarop gevalideerd. In CFK-presentaties blijven ze verborgen. <a href="#validity-context">Zie validity context</a>
-</div>
-
-<div class="box"><strong>Abstracte klassen in SHACL</strong><br/>
-De DASH Data Shapes Vocabulary definieert een abstracte klasse als "A class is called abstract if it cannot have direct instances - only non-abstract subclasses of an abstract class can be instantiated directly". DASH bevat de property <span class="blue">dash:abstract</span> met domein <span class="blue">rdfs:Class</span> en range <span class="blue">true</span> voor het markeren van abstracte klassen.
-De SHACL validatie hanteert de dash:abstact definitie niet, valideren op (foutief) gebruik van abstracte klassen wordt met SHACL-statements opgelost.
-<a href="#details-specialsatie-en-classificatie">Zie Details specialsatie en classificatie</a>
-</div>
-
-### Bladerobjecten
-
-1. Specialiseer de klassen zoveel als mogelijk, tot aan de "bladerobjecten", het ultieme subtype, de klasse zonder subtype.
-2. Introduceer geen subtype als het geen onderscheidend kenmerk heeft. Bijvoorbeeld geen extra subtype "standaard hemelwaterstelsel" naast "verbeterd hemelwaterstelsel".
-3. Hou er rekening mee dat de individuen in de dataset zo specifiek mogelijk geclassificeerd worden. Classificatie gebeurt op bladerobject-niveau tenzij dat bladerobject niet van toepassing is (denk aan het eerdere voorbeeld "hemelwaterstelsel") of als het type onbekend is. Bijvoorbeeld wordt het supertype "kolk" gebruikt als het subtype (straatkolk, trottoirkolk) onbekend is.
-
-In IMBOR heten deze bladerobjecten "Concrete klassen", de subtypes van nen2650:Object heten "Objecttypen". 
-
-### Orthogonaliteit
-
-Binnen de GWSW taxonomie kunnen begrippen haaks (orthogonaal) op elkaar staan, de orthogonaliteit is dus niet bepalend voor de opbouw van de soortenboom. Bijoorbeeld kun je de in het GWSW opgenomen concepten Blinde Put en Overstortput als orthogonaal beschouwen: de één wordt onderscheiden vanwege de constructie, de ander wordt onderscheiden vanwege de functie.  
-Dat vraagt extra aandacht bij de toepassing ervan. Zo kan een individu zowel van het type Blinde Put als van het type Overstortput maar dat geldt niet voor de combinatie van de typen Overstortput als Stuwput. Die laatste combinatie conflicteert vanwege de scheiding in functie. In het datamodel kun je dat expliciteren door conflicterende typeringen met <span class="blue">owl:disjointWith</span> te beschrijven. In het GWSW datamodel is dat niet uitgewerkt, via de onderscheidende kenmerken is de orthogonaliteit wel herkenbaar.
-
-## Kenmerken (attributen, aspecten)
-
-**Beschrijf alleen relevante - toegepaste - kenmerken bij een concept.**
-
-1. Kenmerken horen altijd bij een entiteit en kunnen niet bestaan zonder de entiteit
-2. Beschrijf met CE's de kardinaliteit op de kenmerken, ook als ze niet definiërend zijn. Hanteer de kardinaliteit "minimum=0" en "maximum=1" voor globale uitdrukkingen.
-
-<div class="box">**Kenmerken in CE's ondersteunen de data-afleiding**<br/>
-Als een individu kenmerk X heeft is het mogelijk van type Y ("sufficient")
-</div>  
-
-3. Hou kenmerken en entiteiten gescheiden en blijf object-georiënteerd. Bijvoorbeeld Dekselmateriaal en Beheerdernaam kunnen geen kenmerken van een Put zijn, dat zijn kenmerken van het concept Deksel en Beheerder. Die entiteiten kunnen vervolgens een relatie (heeft deel, is invoer) hebben met de put.
-4. Voorkom het opnemen van optionele kenmerken bij een supertype (kenmerken die niet voor alle subtypes gelden), definieer de kenmerken dus niet op een te hoog niveau.
-5. Gebruik het multi-parent principe. Als alleen kunststof leidingen het gebruikte kenmerk "kleur" hebben, introduceer dan het concept "kunststof leiding" met het kenmerk "kleur". Een individu is dan zowel een "vrijverval rioolleiding" als een "kunststof leiding" en heeft daarmee dat extra kenmerk.
-
-**Geen typelijsten**  
-Kenmerken die verwijzen naar een typelijst (bijvoorbeeld het kenmerk Soort Deksel van het concept Deksel) komen niet voor. Een typelijst wordt uitgedrukt in de taxonomie (bijvoorbeeld als subtypes van Deksel).
-
-### Intrinsieke kenmerken
-
-1. Specialiseer waar nodig de kenmerken, zodat restricties op de kenmerk-waarde zo specifiek mogelijk zijn. Bijvoorbeeld:
-    * Definieer het kenmerk "materiaal put" als subtype van "materiaal" met bijbehorende - beperkte - domeinwaarden
-    * Definieer het kenmerk "diameter leiding" als subtype van "diameter" met specifieke restricties (min/max) op de afmetingen.
-2. Intrinsieke kenmerken zijn niet altijd noodzakelijk maar de combinatie met restricties (bijvoorbeeld minimum/maximum waarde) maakt ze waardevol en daarnaast wordt het datamodel robuuster: als een individu het kenmerk heeft, dan hoort het van een bepaald type te zijn.
-3. Intrinsieke kenmerken zijn waardevol/noodzakelijk als ze een toegevoegde definitie hebben. Bijvoorbeeld de beschrijving of de "diameter leiding" de inwendige of uitwendige maat is. 
-
-### Kwaliteitseisen
-
-Beschrijf in het datamodel de eisen voor de gegevenskwaliteit, met name die voor nauwkeurigheid via restricties aan waardetype en waardebereik.
-
-1. Specificeer altijd de waardetypes bij de aspectwaarden
-2. Specificeer waar nodig ook het waardebereik (in combinatie met het waardetype)
-3. Start de URI van een gemodelleerd datatype altijd met "Dt_"
-4. Modelleer waar nodig het metagegeven <span class="blue">heeft inwinning</span> voor beschrijving van de actualiteit en betrouwbaarheid.
-
-## Relaties - Samenstelling en proces
-
-<br/><img src="media/meronomie.png" style="width:40%;" />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<img src="media/proces.png" style="width:35%;" />
-
-Definieer de samenstelling, de topologie en het proces op basis van de relaties bij een concept, zie hst [Details relaties](#details-relaties)
-
-1. Beschrijf met CE's de kardinaliteit van de relaties bij concepten, ook als ze niet definiërend zijn. Hanteer de kardinaliteit "minimum=0" en "maximum=1" voor globale uitdrukkingen.
-    * Met de kardinaliteit beschrijven we ook dat een fysiek object bijvoorbeeld per definitie andere fysieke objecten als onderdeel heeft.
-2. Beschrijf op dezelfde wijze ook altijd de inverse relatie. Voor de dataverificatie is die inverse vaak waardevol. Een constructie kan bijvoorbeeld meerdere delen bevatten (<span class="blue">heeft als deel</span>) maar het deel hoort bij één constructie (<span class="blue">is deel van</span>).
-
-<div class="box">
-De meronomie speelt in IMBOR geen grote rol maar voor het GWSW is die heel belangrijk voor het structureren van datasets en data-afleiding.
-</div>
-
-### Erven van samenstellingen
-
-1. Voorkom redundantie van deel-geheel relaties, die relatie mag niet dubbel voorkomen voor een subtype en het bijbehorende supertype.
-2. Definieer de samenstelling - hoewel verleidelijk - dus niet op een te hoog niveau
-
-### Proces en activiteit
-
-Het GWSW volgt de Gellish-aanpak (bron Matthé van Koetsveld): Bij het modelleren van een activiteit/project (als bij IDEF0) onderscheid maken naar invoer (die verwerkt wordt), uitvoer (resultaat van de verwerking/activiteit), control (ook soort invoer van de activiteit die project controleert, aanstuurt) en mechanisme (soort uitvoer, die de activiteit uitvoert, kan een organisatie, systeem, enzovoort zijn). Dan zou het semantisch netjes zijn: 
-
-* Project **heeft als control** Opdrachtgever
-* Project **heeft als mechanisme** Opdrachtnemer
-* Inspectieproject **heeft als invoer** Put, Leiding
-* Inspectieproject **heeft als uitvoer** Waarneming
-
-In het GWSW simplificeren we het enigszins (met alleen hasInput, hasOutput):
-
-* Project **is een** Activiteit
-* Project **heeft als invoer** Opdrachtgever (aansturing project)
-* Project **heeft als uitvoer** Opdrachtnemer (uitvoering project)
-* Project **heeft als deel** Inspecteren Leiding (ook een activiteit)
-* Inspecteren Leiding **heeft als invoer** Leiding
-* Inspecteren Leiding **heeft als uitvoer** Waarneming
-
-## Deelmodellen
-
-Zie hst [Details deelmodellen](#details-deelmodellen).
-
-Vanaf GWSW versie 1.5.2 (na afscheid van het Gellish bronmodel) is de **Collection of Facts** (CoF) op conceptniveau in de RDF-bron opgenomen. De CoF speelt nog steeds een belangrijke rol in de RDF-versie van het GWSW. Het wordt beschreven met het annotatie-attribuut <span class="blue">skos:scopeNote</span>, de annotatie-waarde (de URI van een CollectionOfFacts-subtype) verwijst naar een deelmodel (GWSW-Basis, GWSW-Kengetallen, enz.) horen.
-
-Op basis van de CoF worden dus de GWSW deelmodellen samengesteld. Zo'n deelmodel is een filter op het datamodel waarbij de klassen, de CE's en de individuen worden geselecteerd op de gekoppelde CoF. De deelmodellen hebben meerdere functies:
-
-* het overzichtelijk presenteren van specifieke GWSW onderdelen
-* het overzichtelijk onderhouden van het datamodel. Veel deelmodellen hebben een heel specifieke functie, anderen worden met een lage frequentie onderhouden. Denk bijvoorbeeld aan uitwisselformaten.
-* het samenstellen van conformiteitsklassen, data-verificatie voor bepaalde processen
-* het koppelen van alleen de relevante modelonderdelen aan datasets, afgestemd op de praktijk van uitwisselen
-
-Hou rekening met de onderverdeling van de context-specifieke deelmodellen. Combineren van deelmodellen met behoud van overzicht is in RDF-editors mogelijk. Handhaaf een logisch onderverdeling door modelaanpassingen in het juiste bronbestand (geïmporteerde turtle-bestand) te doen en consequent de annotatie skos:scopeNote te vullen.
+Zie de principes van [eerdere GWSW-versies](https://stichtingrioned.github.io/GWSW_Ontologie_RDF/#modelleerprincipes)
 
 # Modelleerprincipes - Specifiek GWSW 2.0