Brontekst bekijken van Manifest voor het belang van De Kunde van Kennisrepresentatie voor Informatiediensten

<i>Dit document wordt begeleid door een document met een uitwerking van de [[Beschouwingsniveaus]], inclusief de benamingen die voor deze beschouwingsniveaus vaak worden gebruikt.</i>

Wij, professionals actief bij het ontwerpen, ontwikkelen en </span><span>leveren </span><span>van informatiediensten, zijn van mening dat de <i>Kunde van Kennisrepresentatie</i> een noodzakelijke voorwaarde is om te komen tot goede informatiediensten. 

Zij die deze kunde beheersen, herkennen zich in de volgende stellingen en zijn betrokken bij het maken van de hieronder beschreven modellen voor elk beschouwingsniveau.

Wij zien een informatiedienst daarbij als een dienst die wordt geleverd door (of namens) een organisatie, waarbij de dienst die daarbij wordt geleverd primair uit de verwerking van gegevens bestaat (in tegenstelling tot bijvoorbeeld een dienst voor fysieke producten, zoals een koerier of een detailhandel). Onder dergelijke informatiedienst verstaan wij ook de consequentie die daaruit volgt. Ook kan sprake zijn van een dienst waarbij aangeleverde gegevens worden verrijkt of verwerkt. De Engelse term is &ldquo;information service&rdquo; en het ontwerpen daarvan &ldquo;information service engineering&rdquo;. 

<b>STELLING 1: Ontwerpen van een informatiedienst vereist een expliciet begrip van het domein</b>

Informatiediensten worden tegenwoordig vaak geleverd met behulp van IT systemen. Deze systemen worden gemaakt door mensen en deze systemen verwerken gegevens. De gegevens representeren concepten</span><span>&nbsp;</span><span>die een specifieke betekenis hebben in het domein waarin de informatiedienst wordt gebruikt. Een expliciet begrip van </span><span>de context</span><span class="c1">&nbsp;waarbinnen de informatiedienst wordt gebruikt, is hiervoor nodig. De informatiedienst vervult een behoefte in het domein, het lost een probleem op. Door dit probleem te begrijpen, kun je er ook een oplossing voor ontwerpen. We zien dan ook dit expliciete begrip als randvoorwaarde voor het kunnen starten met het ontwerpen van een informatiedienst.

<b>STELLING 2: De sleutel tot het begrijpen van een domein is het begrijpen van de gebruikte taal</b>

Wij mensen gebruiken taal bewust om elkaar te begrijpen en te be&iuml;nvloeden. Succesvolle samenwerking vereist dat we communiceren met elkaar. Dat doen niet alleen mensen, maar feitelijk alle dingen die samenwerken: ook andere levende wezens en ook machines. Communicatie tussen mensen kan rechtstreeks, maar ook via de informatiedienst. Wij kunnen taal ook gebruiken om elkaar te </span><span class="c8">leren</span><span>&nbsp;begrijpen: we zijn ons bewust van het gebruik van taal. We zijn daarmee in staat om te begrijpen waarover we communiceren, dat wil zeggen: waarover we communiceren, of anders gezegd: </span><span>wat er zich zoal </span><span>afspeelt</span><span>&nbsp;in het domein.</span><span>&nbsp;</span><span>Door de taal te begrijpen die in een domein wordt gebruikt, </span><span>ontstaat </span><span>begrip van het domein</span><span>.</span><span class="c1">&nbsp;Je begrijpt een taal, als je weet waarover gesproken wordt, wat er mee bedoeld wordt. Hoe datgene waar over gesproken wordt in elkaar zit. Dit begrip van het domein is de noodzakelijke randvoorwaarde, om de dialoog te kunnen starten.

<b>STELLING 3: Alleen via een gestructureerde dialoog kan gezamenlijk begrip van het domein ontstaan</b>

Om de taal van een domein te kunnen begrijpen zul je vragen moeten stellen over de betekenis van de woorden en van de combinaties waarin deze woorden te gebruiken zijn. Het is een dialoog met de intentie om de verschillende betekenissen en patronen te harmoniseren tot een gezamenlijk begrip over het domein. </span><span>Bestaande documentatie kan versnelling opleveren: de documentatie is als het ware de vastlegging van eerdere dialogen.</span><span>&nbsp;Doordat zowel de taal als het domein evolueert, zal een dialoog nodig blijven: h</span><span>et is een steeds terugkerende interactie tussen mensen om te komen tot een gemeenschappelijke taal</span><span>. Merk op dat IT</span><span>&nbsp;systemen</span><span>&nbsp;op dit moment nog vrij slecht zijn in het voeren van een dergelijke dialoog. </span><span>Begrijpen van een domein is een menselijke kunde. Niet alleen zijn IT systemen slecht in het voeren van een dergelijke dialoog, je mens als mens ook actor in het domein.

<b>STELLING 4: Een formeel model is nodig om de betekenis van de domeintaal voldoende expliciet vast te leggen</b>

De betekenis van een domeintaal blijft altijd in beweging: het gebruik van de taal bepaalt in belangrijke mate de betekenis van die taal. Toch zal bij de verwerking van gegevens aannames gedaan worden over die betekenis. Van belang voor informatiediensten is dan ook dat expliciet wordt gemaakt welke betekenis van een begrip vaststaat, en welk deel van de betekenis in het gebruik nog kan schuiven (waarbij dan stelling 5 om de hoek komt kijken!). Om deze expliciete betekenis vast te leggen is een formeel model bruikbaar.</span><span>&nbsp;IT systemen kunnen niet met elkaar in dialoog gaan om </span><span>elkaar</span><span>&nbsp;te begrijpen. IT systemen hebben een formeel model van de taal in een domein nodig om de woorden en combinaties van woorden uit de domeintaal op de juiste wijze te verwerken.

<b>STELLING 5: De context bepaalt wat (een) gegeven betekent.</b>

Gegevens zijn vastgelegde beweringen over eigenschappen van objecten. Dit vastleggen gebeurt met symbolen: woorden, getallen, codes, afkortingen en nummers. De betekenis die een schrijver of lezer van de symbolen van die beweringen aan toekent, is afhankelijk van de context, zoals andere gegevens, maar ook de situatie waarin de schrijver en lezer zich bevinden (zonder dat hierover gegevens bekend hoeven te zijn). Gesprekspartners begrijpen elkaars </span><span>gegevens </span><span>als ze van elkaar weten welke betekenis ze aan de symbolen toekennen. De ontvanger van gegevens kan pas de juiste betekenis toekennen aan gegevens als de context van de verstrekker bekend is. Gegevens worden </span><span>pas </span><span class="c1">betekenisvol binnen de context en interpretatie van de schrijver en lezer. Om misverstanden te voorkomen, begrip te vergroten en foutloze automatische verwerking mogelijk te maken moet context van gegevens zo veel mogelijk expliciet gemaakt worden.

<b>STELLING 6: Duurzaam behouden van de beoogde betekenis van gegevens vergt zorg</b>

De betekenis van woorden in een taal kan evolueren door de tijd heen. Ook is de betekenis van taal afhankelijk van het domein. Gegevens die ooit zijn ontstaan, verwijzen naar de betekenis op dat moment in de tijd, door degene die er een betekenis mee beoogde op dat moment. Deze stelling impliceert daarmee niet alleen dat onze modellen kunnen veranderen door de tijd heen, maar ook dat een juiste verwerking van de gegevens alleen mogelijk is als de</span><span>&nbsp;oorspronkelijke modellen nog beschikbaar zijn</span><span>. Deze gegevens-over-de-gegevens (ook wel </span><span class="c8">metadata</span><span class="c1">&nbsp;genoemd) zijn cruciaal voor de juiste duiding. Dit gaat niet vanzelf: zonder expliciete zorg hiervoor, gaat de beoogde betekenis (de oorspronkelijke context en interpretatie van de observant) van gegevens verloren en worden deze gegevens waardeloos.

<b>STELLING 7: Het beoogd gebruik bepaalt welke gegevens nodig zijn en in welke vorm</b>

De betekenis die met de gegevens </span><span class="c1">wordt beoogd kan volledig beschreven zijn in het formele model. Maar welke gegevens daadwerkelijk uitgewisseld worden in de interactie van het IT systeem en zijn omgeving, of welke gegevens daarbij gebruikt worden of geadministreerd worden: dat hangt af van de behoefte van de gebruiker en het proces waarin deze gebruiker een rol speelt. Een bepaalde combinatie van gegevens leidt tot relevante informatie in een bepaalde context. Ook de benodigde kwaliteit van deze gegevens is afhankelijk van het gebruik.

<b>STELLING 8: Gegevens blijven hetzelfde, ongeacht het technisch formaat</b>

In welk technisch formaat de gegevens nu worden uitgewisseld, getoond of opgeslagen: het blijven dezelfde gegevens. De technische eisen bepalen in hoofdzaak wat de meest voor de hand liggende vorm is. <span>Zolang in deze vorm de relatie met het formele model gehandhaafd blijft, blijft de bedoelde betekenis ook behouden.</span><span class="c1">&nbsp;Deze stelling kan ook omgekeerd worden gelezen: als het technische formaat feitelijk leidt tot andere inhoud, dan is geen sprake meer van dezelfde gegevens, maar van andere.

<h2>BESCHOUWINGSNIVEAUS</h2>
Vanuit de implicaties die bovenstaande stellingen hebben, zien wij vier beschouwingsniveaus waarbij het van belang is om deze niveaus uit elkaar te houden:</span></p><p class="c0"><span class="c1"></span></p><p class="c6"><span>Het eerste onderscheid dat we van belang vinden is het onderscheid tussen de beschouwing van het </span><b>(probleem)domein</b> en de beschouwing van <b>(het ontwerp van) de oplossing</b><span class="c1">&nbsp;voor dat probleem.</span></p><p class="c0"><span class="c1"></span></p>
<ul class="c22 lst-kix_tu02gibk3190-0 start"><li class="c6 c12 li-bullet-0">
<span>Modellen voor het probleemdomein zijn primair </span><i>analysemodellen</i><span class="c1">: het zijn modellen die een representatie zijn van het domein zelf, zonder dat de modelleur hier een ontwerp-afweging (engineering) bij maakt. Deze modellen hebben tot doel om inzicht te krijgen in het domein.</span></li>
<li class="c6 c12 li-bullet-0"><span>Modellen voor de oplossingsruimte zijn primair </span><i>ontwerpmodellen</i><span>: het zijn modellen die een representatie zijn van het ontwerp (engineering) van de informatiedienst. Deze modellen hebben tot doel om helder te maken hoe we </span><span>de</span><span class="c1">&nbsp;informatiedienst gaan ontwikkelen.</span></li></ul>

<span class="c1">Bij alle beschouwingsniveaus geldt dat de modelleur modelleringsafwegingen maakt. In ieder geval zal een afweging gemaakt moeten worden over de scope van het model: welk deel van het domein relevant is om te modelleren, of wat de scope is van de informatiedienst zelf. Zo ontstaan op elk beschouwingsniveau meerdere modellen.</span></p><p class="c6"><span class="c1">Binnen de beschouwing van het probleemdomein is vervolgens onderscheid nodig tussen:</span></p><p class="c0"><span class="c1"></span></p>

<ul class="c22 lst-kix_e3cem2iuchhr-0 start"><li class="c6 c12 li-bullet-0"><span class="c1">Modellen die primair bedoeld zijn om de dialoog te voeren tussen mensen over de betekenis van de taal die in het domein wordt gevoerd.</span></li>
<li class="c6 c12 li-bullet-0"><span>Modellen die interpreteerbaar zijn voor IT</span><span>&nbsp;systemen</span><span class="c1">, die volledig formeel en precies het domein beschrijven. Zodat deze systemen het gedrag kunnen vertonen dat past bij het domein, en zodat met behulp van deze systemen een beter gefundeerd inzicht wordt verkregen van het domein.</span></li></ul>

Binnen de beschouwing van de oplossingsruimte is vervolgens onderscheid nodig tussen:

<ul class="c22 lst-kix_oc1qjiw42g7u-0 start"><li class="c6 c12 li-bullet-0"><b>Logische </b><span>ontwerpmodellen</span><span>&nbsp;die een vorm bezitten waarmee beschreven kan worden welke gegevens verwerkt </span><span>worden </span><span>binnen het IT systeem, zonder daarbij ook al keuzes te maken voor de technische oplossing: het zijn </span><span class="c8">technologie</span><span class="c8">&nbsp;</span><span class="c8">onafhankelijke</span><span class="c1">&nbsp;modellen.</span></li>

<li class="c6 c12 li-bullet-0"><b>Technische</b><span>&nbsp;ontwerpmodellen die een vorm bezitten waarmee beschreven kan worden welke </span><span>gegevens</span><span>&nbsp;verwerkt worden binnen het IT</span><span>&nbsp;systeem</span><span>&nbsp;op een manier die past bij de technische oplossing: het zijn </span><i>technologiespecifieke modellen</i>.</li></ul>

<p class="c0"><span class="c1"></span></p><p class="c6"><span>Door deze vier beschouwingsniveaus met elkaar te verbinden ontstaat verticale samenhang (</span><span class="c8">lineage</span><span class="c1">): vanuit een beschouwing van het probleemdomein wordt een oplossing ontworpen, waarbij de betrokken gegevens herleidbaar zijn tot de betekenis die zij hebben voor mensen.</span></p><p class="c0"><span class="c1"></span></p><p class="c6"><span>Deze beschouwingsniveaus gaan niet in op de verbinding die kan bestaan tussen modellen op hetzelfde beschouwingsniveau: horizontale samenhang (</span><i>lineage)</i><span>. Zoals bijvoorbeeld de samenhang tussen een interfacemodel en</span><span>&nbsp;een (intern) model van een informatiesysteem dat deze interface levert.</span><span class="c1">&nbsp;Een dergelijke indeling is buiten de scope van dit manifest.</span></p><p class="c0"><span class="c2"></span></p>

<table border=1 style="border-collapse: collapse;" ><tr class="c10"><td class="c11" colspan="1" rowspan="1"><p class="c3"><b>Niveau</b></p></td><td class="c7" colspan="1" rowspan="1"><p class="c3"><b>Werkwijze</b></p></td><td class="c9" colspan="1" rowspan="1"><p class="c3"><b>Ontstaat door*</b></p></td><td class="c5" colspan="1" rowspan="1"><p class="c3"><b>Object van beschouwing</b></p></td></tr><tr class="c10"><td class="c11" colspan="1" rowspan="1"><p class="c3"><span class="c2">I</span></p></td><td class="c7" colspan="1" rowspan="1"><p class="c3"><span class="c2">Analyseren</span></p></td><td class="c9" colspan="1" rowspan="1"><p class="c3"><span class="c2">Dialoog</span></p></td><td class="c5" colspan="1" rowspan="1"><p class="c3"><span class="c18 c8">(de taal in)</span></p><p class="c3"><span class="c2">Het probleemdomein</span></p></td></tr><tr class="c10"><td class="c11" colspan="1" rowspan="1"><p class="c3"><span class="c2">II</span></p></td><td class="c7" colspan="1" rowspan="1"><p class="c3"><span class="c2">Analyseren</span></p></td><td class="c9" colspan="1" rowspan="1"><p class="c3"><span class="c2">Systematisch</span></p></td><td class="c5" colspan="1" rowspan="1"><p class="c3"><span class="c8">(de formalisatie van)</span><span class="c2"><br>Het probleemdomein</span></p></td></tr><tr class="c10"><td class="c11" colspan="1" rowspan="1"><p class="c3"><span class="c2">III</span></p></td><td class="c7" colspan="1" rowspan="1"><p class="c3"><span class="c4">Ontwerpen</span></p></td><td class="c9" colspan="1" rowspan="1"><p class="c3"><span class="c2">Dialoog</span></p></td><td class="c5" colspan="1" rowspan="1"><p class="c3"><span>(</span><span class="c8">de invulling, specificatie van</span><span class="c1">)</span></p><p class="c3"><span class="c4">De </span><span class="c4">oplossingruimte, de informatiedienst</span></p></td></tr><tr class="c10"><td class="c11" colspan="1" rowspan="1"><p class="c3"><span class="c2">IV</span></p></td><td class="c7" colspan="1" rowspan="1"><p class="c3"><span class="c2">Ontwerpen</span></p></td><td class="c9" colspan="1" rowspan="1"><p class="c3"><span class="c2">Systematisch</span></p></td><td class="c5" colspan="1" rowspan="1"><p class="c3"><span class="c18 c8">(de technisch implementeerbare invulling van</span></p><p class="c3"><span class="c4">De oplossingruimte, d</span><span class="c4">e informatiedienst</span></p></td></tr></table><p class="c0"><span class="c1"></span></p><p class="c6 c15"><span>*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&ldquo;ontstaat door&rdquo; richt zich op de wijze waarop we het model primair inzetten. Bij &ldquo;dialoog&rdquo; gaat het om de mensgerichte communicatie die nodig is om helder te krijgen waarover we het hebben c.q. wat we nodig hebben in het ontwerp van de oplossing. Bij &ldquo;systematisch&rdquo; gaat het om een model dat interpreteerbaar is door een systeem, waarmee een </span><span>precies</span><span>&nbsp;model ontstaat van het domein c.q. de oplossing.</span></p><p class="c0 c15"><span class="c1"></span></p><p class="c0"><span class="c1"></span></p>