Notitie

naar
aanleiding van
Ontwerp en implementatie
“Aquo-catalogus”
Auteur: H-J. Lekkerkerk

Datum: 30-03-2010

Versie: 0.2

Kenmerk: Regiegroep
RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

Documentbeheer

Wijzigingshistorie

Datum Versie Auteur Wijziging

12-03-2010 0.1 H-J. Lekkerkerk Opgesteld obv verzoek Regiegroep IDsW
30-03-2010 0.2 H-J. Lekkerkerk Aanpassingen nav opmerkingen H. Steegeman
& R. Marseille

Review

Datum Versie Reviewer Functie

Controle en vrijgave

Datum Versie Controleur Functie

Literatuurbronnen

 Concept eindrapport Objectencatalogus, Alterra, December 2009

 Richtlijn voor het opstellen van een wijzigingsvoorstel op de uitwisselmodellen, IDsW,
maart 2006
 Aquo standaard dd juli 2009
 NTA 8611:2003
 Ontwerp BRON thesaurus
 Plan van eisen Domeintabellen services
 RfC Objectencatalogus, 2010, IDsW

pagina 2 van 26 Documentbeheer

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

Inhoudsopgave

1. Inleiding 5

1.1 Aanleiding..................................................................................5
1.1.1 Achtergrond...........................................................................5
1.1.2 LM Aquo discussie....................................................................6
1.2 Uitwerking.................................................................................8
1.2.1 Onderzoek door Alterra..............................................................8
1.2.2 Conclusies en aanbevelingen Alterra / IDsW obv onderzoek...................9
1.3 Business Case............................................................................10
1.3.1 Voordelen............................................................................10
1.3.2 Impact en afbakening..............................................................10
1.3.3 Beheer................................................................................11
1.3.4 Eenmalige kosten...................................................................12
1.3.5 Stand van zaken en voorstel verdere uitwerking...............................13

2. Huidige Aquo standaard in relatie tot een ‘Objecten catalogus’ 14

2.1 Relaties tussen de huidige onderdelen van de standaard......................14

3. Voorbeeld en werking Objectencatalogus 17

3.1 Introductie...............................................................................17
3.2 Voorbeeld op hoofdlijnen.............................................................17
3.3 Detailvoorbeelden......................................................................19
3.3.1 Entiteit versus Concept en subklassen...........................................19
3.4 Van objectencatalogus naar een informatiemodel..............................22
3.4.1 Voorbeeld: Kunstwerk – afsluitmiddel / wijze..................................22
3.4.2 Aanzet tot afleidingsregels voor de objecten catalogus......................25

Inhoudsopgave pagina 3 van 26

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

1. Inleiding
Deze notitie is opgesteld op verzoek van de regiegroep IDsW. De notitie baseert zich enerzijds
op het wijzigingsvoorstel Objectencatalogus zoals in januari 2010 door het programmabureau
gepubliceerd en anderzijds op het rapport ‘Objectencatalogus’ zoals opgesteld door Alterra.

Ten opzichte van beide documenten zijn de specifieke acties, voordelen en een inschatting van
de baten en lasten van de Objectencatalogus ten opzichte van de huidige situatie toegevoegd.

1.1 Aanleiding

1.1.1 Achtergrond

De Aquo-standaard bestaat uit aan elkaar gerelateerde onderdelen die gericht zijn op
definities van gegevens, het uitwisselen van gegevens, de opslag van gegevens en de
inwinning, presentatie en verwerking van gegevens.

Voor elke standaard zijn er - naast sec de standaard - aanvullende documenten beschikbaar
om de toepassing van de standaard te ondersteunen (praktijkrichtlijnen, voorbeeldbestanden
etc.). In het kader van de objecten catalogus zijn de volgende onderdelen van de Aquo-
standaard relevant.

Functie Onderdelen Aquo-standaard: Komt voort uit ‘bruidsschat’

Definitie van gegevens Aquo-lex;
Aquo domeintabellen.
Uitwisseling van InformatieModel Water - IMWA;
gegevens UitwisselModel Aquo - UM Aquo;
Opslag van gegevens Logisch Model Aquo – LM Aquo.
Adventus gegevenswoordenboek, CIW
gegevenswoordenboek, Omega
woordenboek
IMWA
Logisch Model Adventus

Eén van de belangrijkste opdrachten die IDsW bij zijn oprichting meekreeg was het integreren
van de ‘bruidschat’, bestaande uit de CIW gegevensstandaard, het Adventus stelsel, IMWA en
Omega Woordenboek tot een enkele, integrale standaard.

Aan de zijde van de gegevensdefinitie is dit traject inmiddels nagenoeg afgerond met de
opschoning van de domeintabellen en de publicatie van een enkel, geïntegreerd Aquo-lex
woordenboek.

Qua standaard zijn zowel de domeintabellen en Aquo-lex inmiddels zo goed als af, maar op de
beschikbaarstelling en het gebruiksgemak valt nog wel wat af te dingen. De ontsluiting als
‘klassiek’ woordenboek / termenlijst van Aquo-lex of de domeintabellen is redelijk tot goed
geregeld. De metadata (waarom, door wie, wanneer etc.) zijn aanzienlijk minder goed
geregeld. Het wordt problematisch als het gaat om verbanden tussen domeinwaarden en
definities onderling en tussen elkaar. Deze relaties zijn momenteel niet of nauwelijks voor de
gebruiker terug te vinden.

Inhoudsopgave pagina 5 van 26

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

1.1.2 LM Aquo discussie

Waar het gaat om de informatiemodellen is de integratie van een ander niveau. Het nadeel
van informatie modellen, of het nu gaat om modellen voor de procesmatige opslag (LM Aquo)
of de uitwisseling (IMWA / UM Aquo), is dat deze voor een specifiek doel en/of organisatie
worden ontwikkeld. Afhankelijk van het proces waarvoor de informatie nodig is zal voor een
bepaalde modellering worden gekozen. Indien een model voor meerdere processen tegelijk
wordt ontwikkeld zullen er ofwel dubbelingen ontstaan (vergelijkbare objecten / relaties)
ofwel zullen er concessies aan het model gedaan moeten worden.

Doordat een model voor een specifiek soort proces (of organisatie) wordt ontwikkeld ontstaan
er verschillende manieren van modelleren. Een belangrijk uitgangspunt wat tot het ontwerp
van de Objectencatalogus heeft geleid is de vraag die door de regiegroep IDsW in 2008 is
gesteld:

“Wat moet er gebeuren met het LM Aquo? LM Aquo wordt vooral gebruikt door de
waterschappen en heeft grote overlap met het uitwisselmodel UM-Aquo. We verwachten een
tweedeling te kunnen maken: een deel van het LM Aquo is nuttig voor de hele sector
waterbeheer en andere delen zijn specifiek voor de waterschappen. Heeft deze tweedeling ook
consequenties voor het beheer? Kunnen we verschillende soorten van beheer onderscheiden?”

Belangrijkste aanleiding voor ontwikkeling van de Objectencatalogus is dan ook de vraag

geweest hoe verder met het beheer van het LM Aquo. Een aantal zaken speelt een rol in deze
discussie;
 IDsW streeft naar een consistente standaard, dat wil zeggen dat alle onderdelen van de
standaard in overeenstemming zijn met elkaar.
 In het LMA zitten relaties die samenhangen met bedrijfsprocessen. Bedrijfsprocessen zijn
organisatiespecifiek en IDsW wil zich bij het standaardiseren zo min mogelijk mengen in
de invulling van bedrijfsprocessen.
 Het LMA is ontwikkeld door en voor de waterschappen. Toen het LMA in beheer kwam bij
IDsW is getracht het ook bruikbaar te maken voor de andere partners. Daartoe is een
aantal clusters aan het model toegevoegd en zijn clusters aangepast. Zo heeft het
kunnen gebeuren dat er per thema meerdere clusters zijn. Hier is dus sprake van
organisatiespecifieke onderdelen van de standaard. Is het niet logischer, nu we UM-Aquo
hebben, om LMA weer van de waterschappen te laten zijn? Dan is het ook niet nodig om
overeenstemming te bereiken over het LMA met de andere partners.
Het is van belang om duidelijk af te spreken wat we onder het LMA verstaan. Uit de discussies
in het verleden bleek dat er verschillende opvattingen zijn: (1) LMA is alleen het model (dus
de entiteit-relatie-diagrammen (ERD’s)) of (2) LMA is het geheel van definities, domeinlijsten,
entiteiten en relaties. We stellen vast dat het LMA bestaat uit:
1. Definities, vastgelegd in een woordenboek dat tegenwoordig is ondergebracht in Aquo-
lex
2. Domeinlijsten, die zijn geïntegreerd in de Aquo-domeinlijsten
3. Het model, bestaande uit:
 Entiteiten
 Relaties, die veelal samenhangen met bedrijfsprocessen
Als we kijken naar het gebruik van het LMA dan concluderen we dat met name de definities en
domeinlijsten veelvuldig en redelijk consequent worden gebruikt door waterschappen en
andere waterbeheerders. De ERD’s, die vaak een beschrijving zijn van bedrijfsprocessen zitten
vaak in de weg en waterbeheerders, óók de waterschappen, kiezen voor het omzeilen hiervan.
We zien dat de definities al onderdeel uitmaken van Aquo-lex en dat de domeinlijsten in de
opschoonactie van de Aquo-domeinlijsten worden geïntegreerd met de overige domeinlijsten.
De objecten en eigenschappen uit zowel UM-Aquo als LMA zijn uitwisselbaar, maar op een
verschillende wijze gemodelleerd.

pagina 6 van 26 Inleiding

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

Het ligt voor de hand om het LMA op te delen in een “definitie”-deel en een “relatie”-deel.
Het definitiedeel, bestaande uit de woordenlijst, domeinlijsten en beschrijvingen van
entiteiten, zou een algemene standaard moeten zijn. Het relatiedeel, dus de ERD’s is meer
organisatiespecifiek en zou alleen voor de waterschappen van toepassing kunnen zijn.
Bij standaardisatie kun je twee richtingen onderscheiden:
4. gegevensgedreven standaardisatie: basisgegevens op een gestandaardiseerde manier
beschrijven zodat deze los komt van toepassing, leverancier en/of ontvanger en voor
alles en door iedereen gebruikt kan worden.
5. informatiebehoeftegedreven standaardisatie: een reeks van handelingen van
gegevensverwerking zodanig vaststellen dat deze bewerkingen voor iedereen altijd
reproduceerbaar worden. Voorbeeld: voor de verplichte rapportage voor de KRW is het
noodzakelijk dat iedereen op dezelfde wijze de monitoring doet en daarna de
gegevens bewerkt, toetst en rapporteert. Deze reeks van handelingen leg je vast.
Onze inschatting is dat IDsW beide zaken moet doen en ook nu al beide zaken doet. Het is wel
van belang dat we deze zaken beter gaan scheiden van elkaar zodat helder is met welk type
standaardisatie we bezig zijn. Het idee is dat IDsW een generieke min of meer onveranderlijke
objectencatalogus gaat beheren waarin we alle objecten en eigenschappen van objecten gaan
definiëren. Als partners deze generieke beschrijving volgen en altijd in staat zijn hun
informatie in deze definitie aan te bieden, dan zijn ze in staat om zich begrijpelijk te maken
voor anderen.

Daarnaast is er de behoefte om verdergaand met elkaar samen te werken, bijvoorbeeld voor

het produceren van een rapportage of voor het doen van een analyse / modelstudie. Op dat
moment is het niet alleen nodig dat je elkaar begrijpt, maar ook dat de informatie die je
gebruikt vergelijkbaar is. In dat geval zijn verdergaande afspraken nodig. Dit zijn de
toepassingsspecifieke modellen of subsets van objecten. Ons UM-Aquo KRW-model is
bijvoorbeeld zo’n model. Dit model geldt dus niet meer altijd overal als standaard, maar als je
informatie aanlevert voor een KRW-rapportage, doen doe je het op die manier.

Hieronder de kenmerken van beide typen:

drijfveer gegevensgedreven informatiebehoeftegedreven

productnaam Objectencatalogus (definities, Toepassingsspecifieke subsets
domeinlijsten, entiteiten) (modellen / domeinlijsten)
toepassingsgebied generiek toepassingsspecifiek
wanneer altijd tijdelijk
veranderlijkheid statisch Veranderlijk, verandert met
informatiebehoefte
“Verplicht” onder convenant 2 mogelijkheden:
1. verplicht (bijvoorbeeld KRW-
rapport)
2. facultatief, gezamenlijke wens om
verdergaande afspraken te maken over
toepassing van informatie
Waarvoor doe je “Elkaar begrijpen” “Hetzelfde zeggen”
het?

Hoewel beide typen in eerste instantie los lijken te staan van elkaar is dit niet het geval. De
informatiebehoefte gedreven standaarden zijn expliciet afhankelijk van de gegevensgedreven
standaarden; immers in de gegevensgedreven standaarden wordt het fundament gelegd voor
de specifieke informatiebehoefte. Door het creëren van een stabiele basis middels de
gegevensgedreven standaardisatie wordt het ook eenvoudiger om op elk gewenst moment met
behulp van de gegevens een specifieke rapportage conform het informatiebehoefte gedreven
model op te stellen.

De objectencatalogus geldt daarmee dus voor iedereen en zou een verplichtend karakter
moeten hebben. De toepassingsspecifieke modellen of subsets zijn selecties uit de

Inhoudsopgave pagina 7 van 26

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

objectencatalogus. Je gebruikt nog steeds dezelfde taal, maar je verkleint het aantal
mogelijkheden (meestal) tot 1 mogelijkheid. Enkele voordelen van deze tweedeling zijn:
 de “verplichting” van de standaard wordt beter gekoppeld aan de noodzaak om te
standaardiseren.
 Het is voor gebruikers heel helder aan welk deel niet getornd kan worden en wel deel
meer ter discussie staat.
 Implementatie van de standaard is meer gekoppeld aan het toepassingsgebied van een
systeem. Ervan uitgaande dat iedereen de objectencatalogus implementeert, kan een
leverancier vervolgens zelf kiezen of zijn applicatie KRW-rapportages moet kunnen
maken of niet. De opdrachtgever kan ook helder zijn wensen op dit vlak definieren.
 Als de informatiebehoefte wijzigt, kan ook een model wijzigen of afgevoerd worden. Dit
heeft voor de basis van de standaard (de objectencatalogus) geen gevolgen.

pagina 8 van 26 Inleiding

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

1.2 Uitwerking

1.2.1 Onderzoek door Alterra

Doel van het onderzoek door Alterra en het daarop volgende wijzigingsvoorstel van IDsW is, om
met bovenstaande uitgangspunten in het achterhoofd, te onderzoeken op welke manier de
scheiding van de twee delen van de standaard gerealiseerd kan worden. Op basis van de
huidige onderdelen van de standaard was door IDsW een datamodel opgesteld voor opname
van de relevante gegevens op basis van het ‘gegevensgedreven’ deel van de standaard

Het onderzoek is daartoe opgesplitst in de volgende delen:

1. Opstellen geschikt datamodel etc conform de in het document gestelde eisen. Dit is
inclusief (maar wellicht niet beperkt tot):
i. kort onderzoek naar geschikte modellen in het (inter)nationale domein.
ii. onderzoek of een object (database structuur?) of relatie georienteerd
datamodel (ontologie) het meest geschikt is op basis van de toekomstige
toepassing van de Objecten catalogus.
iii. vaststellen hoe het datamodel er uit moet zien met inachtneming van alle
genoemde velden (dus inclusief klassen en eigenschappen)
2. Onderzoeken of en hoe de huidige onderdelen van de standaard
(inhoud) getransformeerd kunnen worden naar het nieuwe datamodel
i. automatische omzetting (matching op term / synoniem voor bv klassen /
entiteiten)
ii. automatische omzetting met menselijke interventie (attributen, bv inhoud
'type' / 'soort' domeintabel is identiek en is een subset van; maar ook termen
relaties (bv pontonbrug is subtype van brug etc))
iii. handmatige omzetting (slimme aanpak, wat en inschatting noodzakelijke tijd
obv gekozen datamodel)
3.  Onderzoek geschikte tools voor beheer etc
i. obv huidige beheersystematiek / procedures IDsW
ii. conform document / eisen
iii. met historie / audittrail
iv. passend in huidig applicatie landschap
4. Ontwikkeling publicatie applicatie (proof of concept) obv ontwikkelde datamodel en
initiele vulling obv 2
i. obv bodemdata
ii. met uitbreiding naar attributen / eigenschappen en evt aanvullende relaties
(zie ook ontwerp / datamodel)
iii. inclusief service

De uitkomsten van het onderzoek zijn enerzijds verwoord in het door Alterra opgestelde
onderzoeksrapport; de gebruikte scripts en software en anderzijds (voor punt 4i en ii)
beschikbaar als proof of concept op het internet. De website met de ‘proof of concept’ is te
vinden op (openen met Internet Explorer):

Inhoudsopgave pagina 9 van 26

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

http://137.224.11.5/IdswObjCat/main.html (Java versie met opmaak)

en

http://137.224.11.5/xslt/IDSW.owl (xslt versie met automatische OWL conversie)

De service (punt 4iii) is te vinden op (openen met Internet Explorer):

http://137.224.11.5/idswservice/aquaontows.xql

1.2.2 Conclusies en aanbevelingen Alterra / IDsW obv onderzoek

Op basis van het onderzoeksrapport is er door IDsW en Alterra samen gekeken naar de
uitkomsten hieruit kwam het volgende:

 Het is goed mogelijk om de huidige produkten om te zetten naar een

‘gegevensgedreven’ architectuur

 Op basis van de inventarisatie van geschikte modelleertechnieken en bestaande

‘objectencatalogi’ bied SKOS (een specifiek datamodel op basis van OWL / RDF) de
meeste kansen.

 Het omzetten van de huidige IDsW produkten naar een objectencatalogus kan voor
een groot deel automatisch gebeuren. Hogere en lagere orde relaties (afgeleidde
begrippen) zijn niet altijd zo gemodelleerd in de huidige produkten; het omzetten /
toevoegen hiervan is handwerk.

 De keuze van SKOS voor het verstrekken van de catalogus zorgt voor een ontsluiting
van de catalogus die aansluit bij internationale standaarden en zorgt er ook voor dat
de catalogus met standaard ICT tools gebruikt kan worden. Deze tools zijn minder
geschikt voor het dagelijks beheer binnen een organisatie zoals IDsW. In eerste
instantie lijkt beheer via een database en van daaruit conversie naar OWL meer
geschikt.

 De proof of concept is op twee manieren gerealiseerd op basis van het OWL bestand.
Hiermee is zichtbaar dat ontsluiting van de gekozen modelstructuur op het internet
zeer goed mogelijk is en aansluit bij de behoefte van IDsW voor geïntegreerde
ontsluiting van met name Aquo-lex definities.

Alterra heeft geen onderzoek gedaan naar de toegevoegde waarde van een objectencatalogus
bij het oplossen van de LM Aquo / UM Aquo problematiek. Dit viel nadrukkelijk buiten de
scope van het onderzoek wat zich richtte op de vraag of en op welke manier eea technisch
gerealiseerd zou kunnen worden.

pagina 10 van 26 Inleiding

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

Business Case

Het onderzoek van Alterra heeft zich niet gericht op de voordelen en kosten / baten van de
Objectencatalogus voor het beheer van de Aquo standaard en het oplossen van de mogelijke
problemen rondom het LM Aquo. Deze business case is door IDsW toegevoegd in het
wijzigingsvoorstel Objectencatalogus.

1.2.3 Voordelen

Toepassing Aquo standaard door ontwikkelaars

Door de ontwikkeling van de objecten catalogus ontstaat in feite een ingrediënten lijst voor de
systeemontwikkelaar / gegevensbeheerder. Immers, de kern van de Aquo-standaard zal zich
hiermee gaan beperken tot de objecten catalogus. Deze legt vast welke objecten met welke
definitie en eigenschappen binnen het waterbeheer worden onderscheiden zonder de manier
van modelleren van deze zaken vast te leggen.

Applicaties en informatie modellen die in de toekomst ‘Aquo-proof’ willen zijn zullen daarmee
volledig conform moeten zijn met de Aquo-catalogus én de Aquo-domeintabellen (identieke
naam, definitie en eigenschappen uit de lijst), máár ze hoeven niet meer volledig conform een
informatie model opgebouwd te zijn.

Natuurlijk zullen de informatie modellen wel een belangrijke rol blijven spelen in de
interoperabiliteit tussen software producten. Het staat (een groep van) leveranciers echter
vrij om, op basis van de Aquo catalogus, een eigen uitwisselformaat of database te
ontwikkelen. Voor bepaalde trajecten die een enkele applicatie of (groep) waterbeheerder(s)
overstijgen (bv KRW uitwisseling, Waterwet etc) neemt IDsW de rol in van leverancier in en zal
daarvoor specifieke uitwisselmodellen beschikbaar stellen.

Ontsluiting definities voor gebruikers

Het voordeel van de ontwikkeling van de objectencatalogus voor de ‘eindgebruiker’ van de

Aquo standaard (de beleidsmedewerker, beheerder etc) is het voordeel van de catalogus dat
begrippen in hun onderlinge relaties ontsloten kunnen worden op een uniforme wijze.
Informatie zal duidelijker te vinden zijn en het wordt makkelijker om verbanden tussen
begrippen te leggen. Bij implementatie van de voorgestelde functionaliteit wordt het
mogelijk voor waterbeheerders om begrippen op eigen (interne) websites direct te koppelen
aan definities uit Aquo-lex. Hierdoor hoeft geen eigen beheer meer te worden gevoerd en is
ook zo’n website direct Aquo-conform.

Daarnaast bied de gekozen methode ook verdere integratie in het World Wide Web aan (Web
3.0) door de keuze van internationale standaarden bij de ontwikkeling. Een mogelijke
toepassing hiervan is de ontwikkeling van services die het de gebruiker mogelijk maken termen
en definities op ‘afstand’ op te vragen en toe te passen in publicaties. Ook het vertalen van
termen via een geautomatiseerde service kan op basis van deze objectencatalogus eenvoudig
bereikt worden.

Inhoudsopgave pagina 11 van 26

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

1.2.4 Impact en afbakening

Enerzijds is de impact van de ‘Aquo-catalogus’ groot; het huidige Aquo-lex wordt vervangen
door een nieuw, overkoepelend product waaraan iedere ‘Aquo gebruiker’ zal moeten voldoen
om ‘Aquo-proof’ te zijn. Anderzijds zullen bestaande modellen en onderdelen qua inhoud
volledig in stand blijven (maar in vorm veranderen).

Het voorstel beperkt zich tot de volgende onderdelen van de standaard (en integreert deze tot
de objectencatalogus):

 Aquo-lex: volledig
 IMWA: klassen / attributen en definities
 UM Aquo: klassen / attributen en definities
 LM Aquo: entiteiten / attributen, definities en visualisatie (beschrijving hoe een entiteit
gevisualiseerd wordt).
In de objectencatalogus worden geen relaties / associaties overgenomen uit de diverse modellen
anders dan generalisatie / specialisatie (sub / superklasse). De afbakening in de modellering is
weergegeven tabel 2 van hoofdstuk “4.1.4 Datamodel totaal”, waarin staat vermeld wat mogelijk
is en daarmee toegestaan. De objecten catalogus is gedefinieerd vanuit het objecten catalogus
oogpunt en niet vanuit de bestaande standaarden.
Naast de objectencatalogus zullen specifieke informatiemodellen blijven bestaan voor specifieke
doelen (daar waar gemeenschappelijke relaties ook van belang zijn).

Aquo-domeinen

In dit voorstel worden de Aquo-domeinen verder buiten beschouwing gelaten. Wel kunnen de
waarden in Aquo-domeinen verwijzen naar onderdelen van de Aquo-catalogus waardoor
waarden uit de Aquo-domeinen van een eenduidige definitie voorzien kunnen worden.

LM Aquo

Aquo - domeinen

UM Aquo / IMWA

Aquo-lex

Figuur: Huidige overlap tussen de diverse onderdelen van de standaard qua begrippen /
definities

In bovenstaande figuur is te zien dat er een klein deel van het LM Aquo niet is opgenomen in
Aquo-lex. Dit is het gevolg van het ontbreken van ‘fatsoenlijke’ definitie zoals bij soort gemaal.
Vaak gaat het daarbij om attributen met algemene eigenschappen (lengte / breedte etc.) of
classificaties. Een belangrijk punt voor de objectencatalogus is dan ook de koppeling tussen
domeintabellen en attributen. In veel gevallen vervangt een domeintabel met daarin ‘typeringen’
in feite een hiërarchie.

pagina 12 van 26 Inleiding

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

1.2.5 Beheer

Het ontwikkelen van de Objectencatalogus heeft een impact op het beheer van de Aquo
standaard. Het is de inschatting van het programma bureau dat, na een eerste investering om
de Objectencatalogus te doen ontwikkelen en initieel te vullen de kosten voor het beheer
gemiddeld gelijk zullen blijven of licht zullen dalen bij een toenemende kwaliteit en
gebruiksgemak van de standaard.

Het gelijk blijven of licht dalen van het beheer is als volgt opgebouwd:

 Het huidige LM Aquo, IMWA en UM Aquo blijft volledig beheerd. De definities van
entiteiten en attributen worden echter opgenomen in de Objectencatalogus en daar
eenmalig beheerd. De specifieke beheerkosten van het LM Aquo in Oracle Designer
vervallen. Bijkomend voordeel is dat de Designer versie die gebruikt maar niet meer
ondersteund wordt (6i) verlaten kan worden wat een toekomstige omzetting voorkomt.
Dit leidt naar verwachting tot een aanzienlijke daling van de beheerslast.

 De diagrammen van de verschillende modellen blijven volledig beheerd omdat ze

relaties bevatten die niet in de Objectencatalogus worden overgenomen
(processpecifieke informatie). De LM Aquo plaatjes kunnen als ‘interactieve’ bitmaps
worden beheerd; UM Aquo en IMWA blijven volledig als UML in beheer in verband met
de conversie naar XSD uitwisselschema’s. Dit leidt naar verwachting tot een lichte
daling van de beheerslast.

 Het huidige Aquo-lex beheer wordt gestopt en vervangen door het beheer van
definities en toelichtingen in de Objectencatalogus. Het huidige beheer is op basis van
een grote spreadsheet. Publicatie van Aquo-lex vergt momenteel veel handmatige
handelingen en blijft daardoor beperkt tot twee updates per jaar. Ontsluiting via de
objectencatalogus leidt tot een hogere frequentie van bijwerken. Dit leidt naar
verwachting tot een gemiddelde daling van de beheerslast

 In de objectencatalogus worden alle begrippen / objecten voorzien van metadata en

historie. Deze is in veel gevallen nu niet aanwezig in de onderliggende producten of
wordt op verschillende wijze ingevuld. Het bijhouden van deze informatie zal leiden
tot een stijging van de beheerslasten. De stijging wordt als beperkt geschat omdat
veel informatie automatisch gegenereerd kan worden indien het beheerssysteem
hiervoor goed wordt ingericht (zie ook verder).

 De zogenaamde hogere / lagere orde relaties worden nu alleen in de diverse

informatiemodellen (LM Aquo / IMWA / UM Aquo) onderhouden; het opnemen van deze
relaties in de objectencatalogus betekend dat toevoegen van nieuwe begrippen ook
het toevoegen van deze relaties noodzakelijk maakt. Dit zal de beheerslast bij
toevoegen van begrippen verhogen. De stijging van de beheerslast zal afhankelijk zijn
van de hoeveelheid nieuwe begrippen die toegevoegd gaat worden in de toekomst.
Voordeel van het toevoegen van de relaties is dat een rijker model ontstaat wat
toekomstige ontwikkeling van informatiemodellen aanzienlijk eenvoudiger maakt
doordat veel relaties al zijn gedefinieerd waardoor de kosten hier af zullen nemen. Op
basis hiervan zal de netto beheerslast vermoedelijk gelijk blijven of licht toenemen
afhankelijk van de te verwachtte hoeveelheid mutaties. Naar verwachting zal deze
beperkt blijven tot enkele tientallen op jaarbasis.

1.2.6 Eenmalige kosten

Tegenover de verwachte lichte beperking van het beheer en de stijging van de kwaliteit van de
Aquo standaard staan eenmalige kosten om de catalogus te ontwikkelen en in te richtten. Deze
kosten zijn niet financieel begroot; hiervoor is nader onderzoek en de specifieke keuze van de
beheertool noodzakelijk. Tot de te maken kosten behoren:

Inhoudsopgave pagina 13 van 26

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

 Ontwikkelen / aanpassen datamodel. Deze kosten zijn reeds gemaakt in het onderzoek
van Alterra; het model in kwestie is opgeleverd maar zal nog kleine aanpassingen
behoeven. Geschatte kostten: EUR 5.000
 Onderzoek naar een geschikte beheertool en het opstellen van het functioneel ontwerp /
programma van eisen daarvan. Geschatte kosten EUR 25.000.
 Ontwikkelen van een beheertool. Kosten hangen af van de te kiezen techniek en
daarmee van de in te toekomst te verwachten beheerkosten. Bij keuze ‘of the shelve’
techniek zoals in de pilot gebruikt zijn de kosten van de tooling verwaarloosbaar maar
die van beheer hoog; bij ontwikkeling van maatkwerk zijn de ontwikkelkosten zeer hoog
maar de beheerkosten relatief laag. Los van het te kiezen scenario is het van belang dat
gekozen wordt voor een ‘open oplossing’ die later eenvoudig aan verandering van
(werk)processen aangepast kan worden.
 Omzetten van de huidige onderdelen van de standaard naar de objectencatalogus. Een
groot deel van de scripting hiervoor is in de pilot ontwikkeld; deze scripting moet
aangepast worden voor een definitieve omzetting. Geschatte kosten EUR 25.000
 Invoeren van hogere orde / lagere orde begrippen voorzover niet automatisch omgezet.
Hier zal het zwaartepunt liggen van de kosten; het gaat om een eenmalige opwaardering
van de standaard door het toevoegen van informatie die nu impliciet (bijvoorbeeld in
domeintabellen) aanwezig is. Het aanmaken van deze relaties dient door een iemand
met waterbeheer kennis te gebeuren. Verwachtte tijd nodig is ca 100 - 200 manuren
indien een geschikte beheertool gekozen is.

1.2.7 Stand van zaken en voorstel verdere uitwerking

In het werkplan van IDsW voor 2010 zijn tav de Objectencatalogus de volgende posten
opgenomen:
 50 uur werkzaamheden projectleider standaarden
 120 uur werkzaamheden specialist standaarden
 Euro 50.000 voor ontwikkeling services
Er zijn tot op heden nog geen uren besteed.

De volgende zaken moeten (analoog aan de aanbevelingen uit de pilot) nog uitgezocht worden
voordat kan worden begonnen met de feitelijke ontwikkeling / omzetting:
 Onderzoek naar de wijze van beheer van de catalogus. Hiervoor zijn de volgende opties
geschetst in het Alterra onderzoek:
o Beheer, onderhoud en publicatie als xml / owl bestand met custom scripts op
basis van standaard tools.
o Beheer en onderhoud in een database met custom tooling en export als owl
bestand.
 Opstellen van een definitieve mapping van velden obv het uiteindelijke datamodel

Aangezien met name de uitkomst naar de wijze van beheer van grote invloed is op de verdere
ontwikkelroute wordt voorgesteld eerst deze stap uit te voeren voordat de conversie en overige
stappen in werking worden gezet.

Uitgangspunten in de verdere uitwerking kunnen zijn:

 Beheersbaarheid op lange termijn van de beheeromgeving
 Geen verarming van de standaard
 Flexibele oplossing naar de toekomst
 Ontvlechten ‘definitie’ en ‘proces’

pagina 14 van 26 Inleiding

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

2. Huidige Aquo standaard in relatie tot een ‘Objecten catalogus’

Relaties tussen de huidige onderdelen van de standaard

De diverse onderdelen van de Aquo-standaard staan niet op zichzelf; begrippen uit Aquo-lex
vormen de basis voor entiteiten in het LM Aquo en klassen in UM Aquo / IMWA. Tussen LM Aquo
en IMWA / UM Aquo is er afstemming van klassen en entiteiten en worden dezelfde of
vergelijkbare domeintabellen gebruikt.

IMWA / UM Aquo
Klasse 1 Klasse 2

Klasse 3

Attribuut X
Attribuut Y
Attribuut Z

Kan gelijk(soortig) zijn aan

Attribuut X
Attribuut Y
Attribuut Z

Entiteit 3
Entiteit 1 Entiteit 2

LM Aquo

Figuur: relaties tussen IMWA / UM Aquo en het LM Aquo.

Inhoudsopgave pagina 15 van 26

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

Synoniem
IMWA / UM Aquo
Afkorting Klasse 1 Klasse 2

Begrip Klasse 3
Vlaams
- definitie Attribuut X
- toelichting
Duits of Attribuut Y
- Bron
Attribuut Z
Heeft definitie
Engels

Aquo-lex
Heeft definitie

Attribuut X
Attribuut Y
Attribuut Z

Entiteit 3
Entiteit 1 Entiteit 2
Relatie altijd aanwezig

Relatie kan aanwezig zijn

LM Aquo

Figuur: Relatie tussen de verschillende onderdelen via attributen /klassen / entiteiten

Alle klassen en entiteiten hebben een definitie die is vastgelegd in Aquo-lex. Dit kan via het ‘voorkeursbegrip’ zijn, maar ook via een synoniem. De meeste
attributen hebben ook een definitie; uitzondering hier zijn de ‘classificaties’ (soort x, type y etc) en algemene begrippen (lengte, breedte etc). Attributen
uit zowel het LM Aquo als IMWA / UM Aquo kunnen verwijzen naar een specifieke domeintabel. De – ontsluiting van - de domeintabellen vallen buiten de
scope van de objectencatalogus behalve voor wat betreft de definitie van de domeintabel en de definities van domeinwaarden. Deze definities zijn nu ofwel
in Aquo-lex ofwel in een ‘externe bron’ (bv CAS nummers, literatuur bij TWN etc) vastgelegd. De te ontwikkelen domeintabellen service zal daarvoor

pagina 16 van 26 Huidige Aquo standaard in relatie tot een ‘Objecten catalogus’
RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

verwijzen naar de objectencatalogus. In de meeste gevallen verwijst een domeinwaarde / tabel naar een ‘voorkeursbegrip’, maar in sommige gevallen ook
naar een synoniem.

Synoniem

Afkorting
IMWA / UM Aquo
Klasse 1

Begrip
Vlaams Klasse 3
- definitie
- toelichting Attribuut X
Duits of Attribuut Y
- Bron
Attribuut Z

Engels

Heeft definitie
Kan verwijzen naar
Aquo-lex
Domeintabel 1
Heeft
definitie in

Waarde i
of Aquo Waarde ii Kan verwijzen naar
Domeinen Waarde iii

Attribuut X
Attribuut Y
Heeft definitie uit Attribuut Z

‘Externe bron’

Entiteit 1

Relatie altijd aanwezig

Relatie kan aanwezig zijn

Figuur: Relatie tussen definitie / begrippen via domeinwaarden en domeintabellen

Huidige Aquo standaard in relatie tot een ‘Objecten catalogus’ pagina 17 van 26
RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

3. Voorbeeld en werking Objectencatalogus

3.1 Introductie

In dit hoofdstuk zijn een aantal concrete uitwerkingen van het voorstel van de objectencatalogus
opgenomen. In deze voorbeelden wordt gebruik gemaakt van een datamodel pas later wordt
toegelicht. Voor meer detail informatie omtrent het gebruikt datamodel, zie hoofdstuk 4.

3.2 Voorbeeld op hoofdlijnen

Op hoofdlijnen kan de werking / vertaling vanuit de verschillende (bestaande) modellen en

onderdelen van de Aquo-standaard naar de Objectencatalogus volgens onderstaand voorbeeld
plaats vinden.

In IMWA en in het LM Aquo is de klasse ‘Kunstwerk’ gedefinieerd. In IMWA is er, door het doel
van het model, voor gekozen om via een domeintabel ‘type kunstwerk’ aan te geven om welke
type kunstwerk het precies gaat. Daarin zijn waarden als ‘gemaal’; ‘brug’ en ‘sluis’
opgenomen. Sommige kunstwerken kennen, in de domeintabel, weer een onderverdeling naar
een nader kunstwerktype.

Dit soort modellering is prima als men niet verder wil gaan dan het classificeren van
verschillende soorten kunstwerken zonder daar aanvullende informatie bij vast te leggen per
(sub)type kunstwerk (bijvoorbeeld voor het afbeelden op een kaart).

In het LM Aquo is de entiteit ‘kunstwerk’ de superentiteit (generalisatie) van o.a. de entiteiten

‘gemaal’, ‘brug’ en ‘sluis’. De entiteit ‘brug’ heeft een eigen, specifieke, set eigenschappen
(attributen) waaronder een attribuut ‘soort beweegbare brug’ waarin de diverse typen
beweegbare bruggen verder zijn gedetailleerd.

Dit soort modellering is prima als het gaat om het vastleggen van specifieke eigenschappen per
(sub)type voor bijvoorbeeld beheerprocessen.

Lexicaal (voor bijvoorbeeld een objectencatalogus) zijn beide opties gelijkwaardig; de manier
van modelleren (subentiteiten / klassen vs domeintabel) wordt in dit verband alleen bepaald
door het verdere gebruik van het model (wel attributen per subtype = subklasse of niet =
domeintabel).

In een lexicaal model maakt het niet meer uit welke modelleer optie gekozen wordt; ieder
begrip is hier een eigen object met een eigen definitie (en mogelijk ook eigen eigenschappen).
Door deze manier van vastleggen worden ‘kromme’ situaties die het gevolg zijn van een
modelleertaal zoveel mogelijk voorkomen. Als voorbeeld de domeinwaarde ‘pontondraaibrug –
“Brug bestaande uit op het water drijvende pontons, welke bij opening om een verticale as
worden verplaatst.” die nu als specifieke waarde is opgenomen, maar feitelijk een combinatie
is van een pontonbrug – “Brug bestaande uit op het water drijvende pontons”. en draaibrug –
“Brug draaibaar om één verticale as.”

pagina 18 van 26 Voorbeeld en werking Objectencatalogus

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

Bouwwerk

- functieKunstwerk
- typeKunst-werk
Kunstwerk - …

Overkluizing Aquaduct

Brug
Brug:
- Soort ‘materiaal’
- Soort ‘beweegbare brug’
- … basculebrug klapbrug

pontonbrug draaibrug

Dubbele basculebrug pontondraaibrug Dubbele draaibrug

LM Aquo Objecten catalogus UM Aquo / IMWA

figuur: Modellering van brug in het LM Aquo (links) en in IMWA / UM Aquo (rechts). Daartussen een (mogelijk) lexicaal model (iedere pijl stelt een
lagere orde begrip voor).

Voorbeeld en werking Objectencatalogus pagina 19 van 26

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

3.3 Detailvoorbeelden

De in deze paragraaf beschreven voorbeelden (en afbeeldingen) geven enkele uitwerkingen

van hoe objecten van de domeintabellen en LM Aquo en IMWA / UM Aquo worden gekoppeld
aan Aquo-lex begrippen in de objectencatalogus.

Bij deze voorbeelden is uitgegaan van het ontwerp uit het vorige hoofdstuk.

3.3.1 Entiteit versus Concept en subklassen

In dit voorbeeld wordt getoond hoe een (deel) van de huidige modellering omgezet kan worden
van de huidige modellen en onderdelen van de standaard naar een geïntegreerde
objectencatalogus.

Het gaat hierbij om de volgende onderdelen van de standaard:

LM Aquo: Kunstwerk
IMWA:
- definitie …
KUNSTWERK - type: Vispassage
KWK [code] (domeintabel)
definitie… Aquo-lex:
VISPASSAGE
KVP [code] Begrip Definitie
Kunstwerk …
definitie…
Vispassage …

In het LM Aquo is Vispassage gedefinieerd als sub-entiteit van de entiteit Kunstwerk. Beide
hebben een eigen code, definitie (en attributen).

In IMWA is de vispassage een type kunstwerk (via een domeintabel – typeKunstwerk) en heeft
de klasse kunstwerk waar deze onder valt een eigen definitie (en attributen).

Tot slot zijn in Aquo-lex zowel de begrippen ‘Vispassage’ als ‘Kunstwerk’ opgenomen met
ieder een eigen definitie, toelichting etc.

In onderstaande figuren zijn de verschillende stappen en het eindresultaat van de modellering

in de (toekomstige) objectencatalogus geïllustreerd waarbij ook hier een formele koppeling
wordt gelegd tussen de verschillende onderdelen.

Koppeling entiteit – concept

In deze stap wordt een object VISPASSAGE van het type ‘EntiteitKlasse’ (ENT001) gekoppeld
aan een object Vispassage van het type ‘concept’ (CON0001). De bron voor de entiteit is het
LM Aquo (ABR002). Het concept ‘Vispassage’ is weer een narrower term (subklasse) van het
concept ‘Kunstwerk’ (CON0005).

Sub-superklasse relaties worden in de objectencatalogus dus niet vastgelegd op entiteit niveau

maar op concept niveau. De objectencatalogus wordt daarmee niet afgeleid van de
informatiemodellen, maar omgekeerd!

pagina 20 van 26 Voorbeeld en werking Objectencatalogus

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

Verder is uit het voorbeeld te zien dat het concept weer een eigen bron, kennisgebied en
werkproces kan hebben.

Figuur 1 De koppeling van LM Aquo entiteit Vispassage aan begrip Vispassage in Aquo-lex

Meerdere bronnen

Van het object ‘Kunstwerk’ bestaat een entiteit in LM Aquo en een klasse in IMWA / UM Aquo.
Dit kan in de objectencatalogus worden aangegeven door het toekennen van twee ‘Aquo-
bronnen’.

Figuur 2: 'Kunstwerk' komt voor in IMWA / UMAquo en LMAquo

Sub / superklasse

De klasse / entiteit Kunstwerk uit het LM Aquo en IMWA / UM Aquo wordt ook weer gekoppeld
aan het concept ‘Kunstwerk’ zodat de definitie etc eenduidig vastligt. ‘Concept’ is namelijk
het centrale punt in het semantische model. Op deze manier kan ‘Kunstwerk’ via een
‘broader’ concept gekoppeld worden aan ‘Vispassage’. Dit is weergegeven in Figuur 3.

Voorbeeld en werking Objectencatalogus pagina 21 van 26

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

Figuur 3: De entiteit ‘Kunstwerk’ uit LM Aquo met de gekoppelde gegevens uit Aquo-lex (inclusief narrower
relatie ‘Vispassage’)

pagina 22 van 26 Voorbeeld en werking Objectencatalogus

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

3.4 Van objectencatalogus naar een informatiemodel

Naast de hiervoor geschetste voordelen van de integratie van de diverse onderdelen binnen de
Aquo-standaard is het ook mogelijk om (nieuwe) informatie modellen af te leiden uit de
objecten catalogus. Het voordeel van gebruik van de objecten catalogus is dat de
gegevensblokken (objecten) eenduidig gedefinieerd worden terwijl de manier van modelleren
vrij is en wordt overgelaten aan de informatiearchitect.

Wel gelden er zekere modelleerregels waar een architect zich aan zal moeten houden om de
informatie uitwisselbaar en vergelijkbaar te houden. Door de ontwikkeling en gebruik van de
objecten catalogus zal de noodzaak blijven om specifieke, gezamenlijke en
gestandaardiseerde, informatie modellen zoals IMWA en UM Aquo te ontwikkelen voor
specifieke processen. Dit omdat in de objecten catalogus geen relaties tussen objecten
worden beschreven.
Vaak zijn het de relaties (en de keuze van uit te wisselen kenmerken) die van gegevens
informatie maken binnen een specifieke context.

3.4.1 Voorbeeld: Kunstwerk – afsluitmiddel / wijze

In het huidige LM Aquo is de volgende modellering terug te vinden:

KUNSTWERK
KWK [code]
definitie…
attributen:
afsluitwijze 1
afsluitwijze 2
afsluitwijze 3
type kunstwerk
…

Afsluitmiddel Klein
KVP [code]
definitie…
attributen
afsluitwijze
…

In Aquo-lex zijn daarnaast nog definities voor afsluitmiddel klein en kunstwerk opgenomen.
Daarnaast verwijzen zowel de afsluitwijze 1,2 en 3 (Kunstwerk) als de afsluitwijze
(Afsluitmiddel klein) naar dezelfde domeintabel met daarin een aantal mogelijke waarden. Het
attribuut ‘type kunstwerk’ verwijst naar een domeintabel waarin onder andere de waarde
‘afsluitmiddel klein’ is opgenomen.

Modelleer keuzen

Ten aanzien van de huidige modellering kunnen een aantal opmerkingen gemaakt worden. Ten
eerste is het drie keer voorkomen van de afsluitwijze bij Kunstwerk een ‘workaround’ om in
ERD / databases een attribuut meer dan één keer te laten voorkomen. In UML / XML kan dit
eenvoudig weg voorkomen worden door het attribuut ‘afsluitwijze’ een cardinaliteit van
0/1..3 te geven en daarmee het attribuut tot drie maal in de uitwisseling te laten terugkomen.

Voorbeeld en werking Objectencatalogus pagina 23 van 26

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

Wat verder opvalt aan de modelleerwijze is dat een afsluitmiddel klein op twee manieren
gemodelleerd is; één maal als generiek kunstwerk van het type ‘afsluitmiddel klein’ met als
attribuut de afsluitwijze, en één maal als subtype van kunstwerk met als attribuut de
afsluitwijze (maar ook andere, aanvullende attributen).

Een andere vraag is natuurlijk wat een kunstwerk nu precies is; is een afsluitmiddel een
kunstwerk op zich of een deel daarvan? Vaak zal het beide zijn; ook weer afhankelijk van wie
het vraagt. Geredeneerd vanuit asset management is het wellicht een eigen object met een
eigen beheer en bijbehorende eigenschappen. Voor het maken van een kaartbeeld is een
andere keuze wellicht relevanter (er is alleen een ander symbool nodig en verder geen
informatie). Een asset management systeem zal dan ook wellicht voor een meer gedetailleerde
modellering kiezen dan een geografisch informatie systeem in deze situatie.

Aquo-catalogus

Bovenstaand voorbeeld is in de Aquo-catalogus op de volgende manier gemodelleerd (zonder

bronnen, historie, kennisgebieden en werkprocessen):

- ‘Kunstwerk’ is als concept én EntiteitKlasse gemodelleerd (zie ook eerdere

voorbeelden).
- ‘Afsluitmiddel klein’ is als concept gemodelleerd én als entiteit.
- ‘Afsluitmiddel groot’ is in dit voorbeeld als concept gemodelleerd (is ook een entiteit
in het LM Aquo).
- Tussen ‘kunstwerk’ en ‘afsluitmiddel klein’ / ‘afsluitmiddel groot’ is een nieuw
concept opgenomen: ‘afsluitmiddel’ (dus niet specifiek groot of klein). Deze laag is
nieuw; er is geen overeenkomstige entiteit in het LM Aquo.
- ‘Afsluitwijze’ is als kenmerk gemodelleerd met een verwijzing naar het concept
‘afsluitmiddel klein’.
- Alle subtypen die nu in de domeintabel ‘afsluitwijze’ zijn opgenomen komen terug als
individuele concepten die subtypen zijn van het concept ‘afsluitmiddel klein’

pagina 24 van 26 Voorbeeld en werking Objectencatalogus

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

‘Concept’ ‘EntiteitKlasse’
Kunstwerk Kunstwerk
‘heeftConcept’

‘narrower’ ‘heeftKenmerk’

‘Concept’ ‘Kenmerk’ ‘heeftHttpLink’ ‘HttpLink’

Afsluitmiddel Afsluitwijze Domein Afsluitwijze
‘heeftConcept’
‘narrower’ ‘heeftKenmerk’

Externe Aquo-
‘Concept’ ‘EntiteitKlasse’ Domeintabel
‘Concept’
Afsluitmiddel groot Afsluitmiddel klein ‘Afsluitwijze’:
Afsluitmiddel klein ‘heeftConcept’
- schotbalk
- deur
- schuif
‘narrower’
Via HttpLink /
domeintabellen
‘Concept’ ‘Concept’ ‘Concept’ service
Schotbalk Deur Schuif

Figuur: Voorbeeld modellering kunstwerk - afsluitwijze in objecten catalogus

Voorbeeld en werking Objectencatalogus pagina 25 van 26

RfC: NOT - Aquo catalogus
Datum: 30-03-2010
Versie: 0.2

Als we nu zouden redeneren vanuit het oorspronkelijke model dan zijn we informatie kwijt
geraakt; het is nl. niet meer direct te zien in de objectencatalogus (anders dan via de externe
httpLink) dat er bij het attribuut afsluitwijze een domeintabel hoort; dit had evengoed een
tekstveld kunnen zijn oid. Dit is ook niet de opzet van de objectencatalogus.

Omgekeerd kunnen we de bestaande modellering wel afleidden uit het voorbeeld van de
objectencatalogus. Stel we hebben een applicatie die ‘alleen’ kunstwerken op de kaart wil
zetten; in dat geval zal de applicatie kiezen voor het implementeren van het concept
‘Kunstwerk’. Als leidraad kan daarbij gekeken worden naar de entiteitKlasse ‘Kunstwerk’ om
daar te zien welke kenmerken mogelijk zijn voor die entiteit.
Als het relevant is voor die applicatie om onderscheid te maken tussen de verschillende type
kunstwerken dan kunnen deze ófwel als subentiteiten gemodelleerd worden, ofwel kunnen
deze middels een domeintabel ‘typekunstwerk’ gemodelleerd worden.

Hebben we een applicatie die zich ‘alleen’ bezig houdt met asset management voor ‘kleine
afsluitmiddelen’, dan zal deze applicatie niet geïnteresseerd zijn in kunstwerken in het
algemeen en deze ook niet modelleren. Dat is ook geen probleem. Als de applicatie wel
onderscheid wil maken tussen de verschillende typen kleine afsluitmiddelen dan zijn ook hier
weer twee mogelijkheden, namelijk als domeintabel of als subentiteiten.

De situatie met subentiteiten is (nog) niet gemodelleerd in het LM Aquo, maar kan wel worden
toegepast in een eigen informatiemodel / database. Het enige wat dan nog door de informatie
architect gedaan zal moeten worden is het toekennen van kenmerken aan die verschillende
entiteiten.

3.4.2 Aanzet tot afleidingsregels voor de objecten catalogus

Bij het maken van een ‘eigen’, Aquo-conform informatie model op basis van de
objectencatalogus zal de informatie architect zich aan een aantal ‘spelregels’ moeten houden.
Gebeurt dit niet dan is uitwisseling van informatie met andere partijen niet meer mogelijk.
Deze spelregels moeten nog worden opgesteld, maar er kan aan het volgende gedacht worden:

- Een datamodel / informatie model begint met een specifiek concept XXX uit de
objectencatalogus en neemt deze qua eigenschappen van het concept volledig over.
Wijzigingen zijn niet toegestaan; bij voorkeur wordt verwezen naar de url van het
concept wat is overgenomen.
- Indien er onder het gekozen concept een ‘narrower’ laag aanwezig is dan kan deze
ófwel als domeintabel (typeXXX) worden gemodelleerd, ofwel als individuele
entiteiten. De waarden uit de domeintabel of de nieuwe entiteiten nemen deze qua
eigenschappen van het concept volledig over. Wijzigingen zijn niet toegestaan; bij
voorkeur wordt verwezen naar de url van het concept wat is overgenomen.
- Samenvoegingen van bestaande concepten zijn niet toegestaan. Ook het samenvoegen
van concepten met een andere ‘narrower’ relatie (andere super/subklasse) tot één
domeintabel is niet toegestaan.
- Kenmerken die aangemaakt worden met een eenheid en/of hoedanigheid hebben
altijd een eenheid en/of hoedanigheid uit de Aquo-domeintabel met de bijbehorende
definitie etc.
- Het toepassen van synoniemen (of andere talen) van concepten is toegestaan zolang
de verdere eigenschappen van het concept niet aangepast worden.

pagina 26 van 26