Constructieprincipes voor de informatiekundige: (3) Eenduidige en consistente taal

In deze serie van blogs sta ik stil bij de nog steeds geldige informatiekundige constructieprincipes die garant staan voor betere “informatiebouwwerken”. Ze zijn soms, in de vaart van de voortschrijdende technologie, een beetje vergeten. In deze blog sta ik stil bij de noodzaak van eenduidigheid en consistentie van taal binnen een “systeem” of “domein”. Want aspecten als privacybescherming, informatiebeveiliging en informatiehuishouding zijn er sterk van afhankelijk.

Principes van informatiemanagement, Decentralisatie van besluitvorming binnen de organisatie, Impact van besluitvormingsbevoegdheid

Eenduidig betekent dat iets maar voor één uitleg vatbaar is. Het is dus duidelijk en niet anders op te vatten. Een ander woord voor eenduidig is ondubbelzinnig. Consistentie is het vrij zijn van innerlijke tegenspraak. Taal is dus eenduidig en consistent als betekenis van woorden ondubbelzinnig is en er geen tegenstrijdigheden in zitten. De taal binnen een informatiekundige afbeelding van de werkelijkheid moet hieraan voldoen. Het begrip ‘aanvraag’ wordt bijvoorbeeld in de algemene wet bestuursrecht middels het begrip ‘verzoek’ gedefinieerd. Nu eenduidig vastgelegd is dat elke aanvraag een verzoek is (om een besluit te nemen), wordt duidelijk dat wetsregels waarin over verzoek wordt gesproken dus ook van toepassing zijn op een aanvraag.

Betekenis of semantiek van woorden is een lastig fenomeen. Omdat er mensen bij betrokken zijn. En ieder mens associeert nieuwe dingen met wat hij of zij al weet of heeft ervaren. Het kost dus tijd om nieuwe betekenis te geven aan iets dat in iemands ogen een andere betekenis heeft.

Eenduidigheid en consistentie van taal vinden mensen lastig

Eenduidigheid en consistentie van taal is één van de moeilijkste aspecten van communicatie en informatiekunde. En het wordt vaak onderschat. “Dat hoef ik niet uit te leggen, dat snapt iedereen” is vaak gehoord. Maar zelfs in de dikke van Dale staat vaak meer dan één betekenis bij een woord. Laat staan als het over jargon gaat, of technisch lexicon, dat staat er niet eens in. Informatie is een afbeelding van de werkelijkheid door middel van taal. Taal is beperkt in zijn uitdrukkingskracht en finesse. Dus gebruiken we veel woorden om de werkelijkheid te benaderen. Maar in een informatiesysteem hebben we die ruimte vaak niet en dus gebruiken we verschillende kernbegrippen of objecten. Hetzelfde “ding” kan in de informatiekunde verschillende betekenissen of rollen hebben en dat vinden mensen lastig te scheiden. Die “dingen” zijn informatiekundig gezien verschillend als ze verschillende geboorte- en sterftecriteria hebben. Dat wil zeggen dat ze als object op verschillende momenten relevant worden voor de organisatie of eindigen te bestaan en iemand bepaalt dat.

Voor de in eerdere blogs genoemde Jaap van Rees[1] betekende consistentie dat van verschillende kernbegrippen de unieke gegevens apart worden vastgelegd (dus de gemeenschappelijke gegevens kun je combineren), ook al gaan die gegevens over hetzelfde ding in de werkelijkheid!  Als de persoon Wim de Graaf (kernbegrip1: persoon) in een ziekenhuis zowel behandelend arts is (kernbegrip2: arts) als patiënt (kernbegrip3; patiënt) dan worden de unieke gegevens van Wim die betrekking hebben op die rol (een kernbegrip) aan dat object gekoppeld en niet op één hoop geveegd met Wim als persoon. Maar het adres van Wim kun je wel aan de persoon koppelen want dat is voor patiënt en behandelend arts hetzelfde. Deze regel is heel lang noodzakelijk geweest bij het bouwen van relationele gegevensverzamelingen. Inmiddels is er technologie om dit via semantische modellen flexibeler in te richten maar de essentie blijft dat een object eenduidig is benoemd en informatiekundig een levenscyclus heeft.

Een verandering is een kans om het goed te doen

Een belangrijke eerste stap bij een nieuwe ontwikkeling of verandering, die moet worden ondersteund met een informatiesysteem, is daarom om de kernbegrippen of objecten in het betreffende domein direct helder te maken en te bepalen wat de geboorte- en sterftecriteria zijn (lifecycle) en wie daarover besluit (eigenaarschap). Je moet streven naar semantische interoperabiliteit; het vermogen van systemen of organisaties om aan de kant van zender en ontvanger gegevens op dezelfde manier te interpreteren. Ook in relatie tot elkaar! Vaak gaat het om een hiërarchie van klassen en subklassen van begrippen. Een auto is een voertuig. Een fiets is een voertuig. Maar is een boot ook een voertuig? Of is dat een vaartuig? Dat hangt af van de definitie zal men zeggen. En dus moet je die expliciet maken. Doe je dat niet dan ontstaat een semantisch conflict, de twee kanten begrijpen elkaar niet en het systeem is niet consistent.

Een vaak gebruikte weergave van de belangrijke kernbegrippen en hun relaties is een domeinmodel of objectmodel. Een begrippenlijst van de objecten helpt om dezelfde taal te spreken. Een goede begrippenlijst benoemt per begrip de definitie, uit welke bron deze afkomstig is en of het begrip is vastgesteld of nog een concept is. Maar ook of er synoniemen of homoniemen zijn.

Hoe groter het is, hoe eerder je een eenduidig ontwerp moet maken.

Ik heb eerder aangegeven dat dezelfde “taal” spreken vaak een grote inspanning vraagt en dus zijn “vertalingen” tussen domeinen onvermijdelijk of kan linked data (semantisch web) dit overbodig maken. Maar binnen één domein (bijvoorbeeld de gezondheidszorg of de strafrechtketen) is het noodzakelijk om consistent te zijn in taal als je de informatievoorziening binnen het domein goed wil inrichten. Een goed voorbeeld van een consistente taal over meerdere domeinen (of het hele overheidsdomein) is het stelsel van basisregistraties. Maar dit heeft wel wat voeten in de aarde gehad!

Ons systeem van wetgeving kent veel verschillende domeinen en is een voorbeeld van slechte consistentie over de domeinen heen, zelfs als het over hetzelfde begrip gaat. Het begrip verzamelinkomen bijvoorbeeld heeft voor veel organisaties dezelfde (wettelijke) definitie en berekenwijze maar wordt steeds anders benoemd (toetsinkomen, belastbaar inkomen) omdat de context anders is. Zo ontstaan synoniemen die ieder een andere betekenis lijken te hebben. De wetgever slaagt er maar moeilijk in om de consistentie te handhaven.

Wat gaat er mis als men dit principe niet toepast? Als het taalgebruik in een systeem niet consistent is, lijdt de begrijpelijkheid van het systeem daaronder en zal het moeilijker onderhoudbaar zijn (zie onze wetgeving). Vaak worden de rollen van een object niet goed gescheiden. Met als gevolg dat van een object dat eigenlijk niet langer relevant is voor de registratie (de patiënt die is ontslagen) toch gegevens worden vastgehouden omdat het meerdere betekenissen heeft. In het voorbeeld van de arts en de patiënt worden dan mogelijk de patiëntgegevens te lang bewaard omdat de persoon als arts nog steeds in dienst is.

De architect die dit constructieprincipe kent moet in een vroeg stadium de “taal” informatiekundig eenduidig en consistent maken. Doe je dit niet of te laat dan heeft bij een groot project iedereen al eigen betekenissen gegeven aan alle te registreren objecten zonder zich de samenhang te realiseren. En ga dat nog maar eens terugdraaien!

Lees hier de andere informatiekundige principes:

  1. Betekenisloze identiteitsaanduiding, lees hier.
  2. Ontkoppelpunten voor complexiteitsreductie en flexibiliteit, maximale onafhankelijkheid van delen, lees hier.
  3. Consistentie van taal, lees hier.
  4. Duidelijke verantwoordelijkheidsverdeling en functiescheiding voor de administratie, lees hier.
  5. Beslissingsbevoegdheid voor de uitvoering zo laag mogelijk beleggen, lees hier.
  6. Autorisatie loskoppelen van identificatie/authenticatie, lees hier.
  7. Enkelvoudige vastlegging van stamdata, lees hier.
  8. Data en metadata scheiden in opslag en verwerking, lees hier.
  9. Standaardpatronen toepassen zonder afwijkingen, lees hier.
  10. Applicatiefunctie en dataopslag scheiden, lees hier.
  11. Apparaat onafhankelijk ontwikkelen, lees hier.
  12. Kies een opslagstructuur op basis van de eisen, lees hier.

Referentie:

[1] De informatie-architect, van Rees / Wisse, 1995

Gerelateerde insights

divider