Het EcoGRID Logisch Datamodel voor Release 1

Het EcoGRID Logisch Datamodel voor Release 1
Lourens Veen (L.E.Veen@uva.nl)
Guido van Reenen (G.B.A.vanReenen@uva.nl)
Institute for Biodiversity and Ecosystem Dynamics
Universiteit van Amsterdam
Nieuwe Achtergracht 166
1018 WV, Amsterdam, The Netherlands
Amsterdam
November 2008

Inleiding
Het doel van dit document is het vaststellen van een logisch datamodel dat als basis kan dienen voor
de uitwisselingsstandaarden die gebruikt gaan worden voor EcoGRID Release 1. Het is niet
ontworpen voor een specifieke technologie, maar is een algemene beschrijving van de resultaten
van veldwaarnemingen van soorten. Technische datamodellen voor databases, webservices etcetera
kunnen van dit logisch datamodel afgeleid worden.
Ten opzichte van het EcoGRID datamodel versie 1 zijn er enkele veranderingen en verbeteringen
doorgevoerd die in het afgelopen jaar naar voren gekomen zijn. Deze zijn in juni verzameld, en in
de afgelopen weken verder uitgewerkt en in dit document opgenomen.
Dit document is inhoudelijk compleet, maar vanwege de grote haast die er op dit moment is
ontbreken er nog wat voorbeelden en uitleg die voor optimale communicatie toegevoegd moeten
worden. Dit document is dus een prerelease die gevolgd gaat worden door een definitieve versie.
Natuurlijk staat NDFF/EcoGRID niet stil. Dit document is dan ook geen einde maar een begin, van
waaruit we verder gaan bouwen aan een uitgebreider systeem voor de volgende releases. Ideeën,
op- en aanmerkingen en constructieve kritiek blijven dan ook welkom.
Lourens Veen en Guido van Reenen
17 november 2008

Overzicht
Afbeelding 1: Het EcoGRID Datamodel voor Release 1

Codes
Afbeelding 2: Module Codes
Een groot deel van de in dit logisch datamodel bij een waarneming gebruikte attributen zijn
gedefinieerd op een nominale, hiërarchische schaal. Dit betekent dat er verschillende
voorgedefinieerde waarden kunnen worden ingevuld. Deze waarden, ofwel codes, worden centraal
geregistreerd, maar niet altijd centraal gedefinieerd. Naast de standaardcodes bestaat er de
mogelijkheid om eigen codes toe te voegen.
Bovendien ontwikkelen codesystemen zich in de loop der tijd, waarbij nieuwe codes kunnen
worden toegevoegd, bestaande codes kunnen worden vervangen of codes kunnen worden
verschoven in de hiërarchie.
Codes kunnen op verschillende manieren worden weergegeven. In de taxonomie hebben we
bijvoorbeeld Latijnse en wetenschappelijke namen (Latijnse naam met auteursaanduiding), maar
ook Nederlandse namen. Daarom kunnen er per code verschillende weergaven zijn.

Codedefinities
Naam Attribuut Type Definitie
identity URI De unieke identifier van de code.
name string Een korte naam van de code.
description string Een precieze omschrijving van de code.
Tabel 1: Attributen van de klasse Code
Elke code heeft een identiteit en een omschrijving. De eerste zorgt ervoor dat de code voor
computers te onderscheiden is van andere codes, de tweede is een voor mensen te begrijpen
aanduiding.
Identiteit
Om verwarring te voorkomen is het noodzakelijk dat elke code een unieke identiteit heeft. Doordat
het mogelijk is om zelf codes toe te voegen aan de centraal gedefinieerde codes ontstaat er een
situatie waarin de totale verzameling codes door verschillende partijen wordt gedefinieerd. Codes
zijn daarom gegroepeerd in namespaces, één per organisatie. Elke namespace heeft een unieke
aanduiding, en binnen een namespace zijn de codes uniek. Elke code kan zo geïdentificeerd worden
door zijn namespace en zijn eigen aanduiding, die worden samengevoegd tot een URI.
Omschrijving
Naast een (technische) identiteit heeft een code een definitie, bestaande uit een name en een
description. Deze aanduidingen fungeren als de basisdefinitie van de code. Voor weergave in
verschillende talen en notaties is er een aparte voorziening (hieronder beschreven), die meestal
gebruikt zal worden bij het weergeven van waarnemingen aan gebruikers.
Relaties met andere codes
Er zijn twee relaties tussen codes, parent en correct geheten. Parent geeft een ouder-kindrelatie
weer, zodat er een hiërarchie van codes ontstaat. Een correct-relatie van code A naar code B geeft
aan dat elke A een B is, en dat code A niet meer gebruikt behoort te worden en is vervangen door
code B.
Talen en Weergaven
Naam Attribuut Type Definitie
identity URI De unieke identifier van de taal.
name string De naam van de taal in de taal zelf.
Tabel 2: Attributen van de klasse Language
Een code kan op verschillende manieren worden weergegeven. Hiertoe kunnen verschillende talen
en weergaven worden gedefinieerd. Een taal heeft een identiteit (identity) en een naam (name, de
naam van die taal in die taal). Een taal is hier niet alleen een menselijke taal, maar kan ook een
notatiewijze zijn (bijv. de wetenschappelijke schrijfwijze).

Naam Attribuut Type Definitie
displayname string Een korte weergavenaam van de code.
description string Een precieze omschrijving van de code.
Tabel 3: Attributen van de associatieklasse Representation
Een weergave bestaat uit een korte displayname, die bijvoorbeeld geschikt is om in een tabel weer
te geven, en een langere, preciezere description van de code. Deze zijn precieze vertalingen van
respectievelijk de name en description van de code waar dit een weergave van is.
Een weergave is een relatie tussen de code die wordt weergegeven en de taal waarin dat wordt
gedaan. Voor elke combinatie van code en weergave is er maximaal één representatie.
Categorieën
Naam Attribuut Type Definitie
identity URI De unieke identificatie van de
categorie.
name string De naam van de categorie.
Tabel 4: Attributen van de klasse Category
Categorieën bieden de mogelijkheid om codes, waaronder taxa, in willekeurige groepen in te delen.
Groeperen kan op gemeenschappelijke eigenschappen, maar ook op niet-natuurlijke kenmerken
zoals het voorkomen op een beleidslijst.
Veranderingen
Ten opzichte van het EcoGRID datamodel versie 1 hebben de codes een identiteit erbij gekregen die
geschikt is om te gebruiken in de communicatie tussen verschillende systemen, en die aansluit bij
het gebruik van webservices. Er is de mogelijkheid toegevoegd om hiërarchische codesystemen te
gebruiken. Ook het kunnen weergeven van codes in verschillende talen is nieuw, hoewel deze
functionaliteit al bestond voor taxa (de common names). Dit is nu gegeneraliseerd en ook
beschikbaar voor de codes.

Taxonomie
Eén van de belangrijkste attributen bij elke waarneming is de waargenomen soort. De module
Taxonomy definieert de codes die gebruikt worden om taxa weer te geven. Een groot deel van de
functionaliteit is al in de module Codes gedefinieerd. Deze module voegt daar enkele
taxonomiespecifieke zaken aan toe.
Taxa
Naam Attribuut Type Definitie
identity URI De unieke identifier van het taxon.
name String De supraspecifieke naam van het taxon.
specificEpithet String Het specifieke epithet van het taxon.
infraspecificEpithet String Het infraspecifieke epithet van het taxon.
description String Een (eventuele) omschrijving van het taxon.
authors String De auteursaanduiding behorende bij het taxon.
Tabel 5: Attributen van de klasse Taxon, inclusief van Code geërfde attributen
In dit model is de klasse taxon afgeleid van de klasse code, omdat ze voor de techniek eenzelfde
functie vervullen. Taxa hebben dus net als codes een identiteit. Daarnaast hebben ze ook een naam
en een omschrijving.
De naam van een taxon bestaat uit één of meer elementen, die we apart modelleren. Het veld name
van de code gebruiken we voor de supraspecifieke naam van het taxon. Voor hogere taxa is dit het
enige deel van de naam. Voor taxa op soortniveau en lager wordt hier de naam van het genus
ingevuld. Het specifieke en infraspecifieke epithet komen in dit geval in de velden specificEpithet
en infraspecificEpithet terecht.
De description geeft een precieze omschrijving van de soort, ondersoort, het hogere taxon, etc. dat
met deze naam wordt aangeduid. De auteursaanduiding tot slot staat in het veld author.
Weergaven
Afbeelding 3: Module Taxonomy
Ook in de taxonomie kunnen er meerdere weergaven zijn van een taxon. Hieronder vallen de

Latijnse naam, de wetenschappelijke naam (Latijnse naam inclusief auteursaanduiding), en lokale
(bijv. Nederlandse) namen. Synoniemen, die bijvoorbeeld ontstaan door naamswijzigingen, worden
niet via het weergavemechanisme verwerkt maar via de correct-relatie.
Deze weergaven kunnen deels gegenereerd worden uit de attributen van het taxonobject en de
daarbij aangegeven rangen. Voor zover mogelijk moet dit ook automatisch gebeuren om uit de pas
lopen te voorkomen. De vertalingen zijn nuttig bij het weergeven van individuele taxa en het
zoeken op naam, de meer structurele representatie komt van pas bij het afhandelen van
ingewikkelder vragen en het weergeven van taxa in de context van de taxonomie.
Rangen
Taxa onderscheiden zich ook van de (overige) codes doordat ze een rang met een naam hebben.
Rangen zijn codes, echter de correct-relatie en de description worden niet gebruikt 1 . Het name
attribuut bevat de Latijnse naam van de rang. De parent-relatie geeft de hiërarchie in de rangen
weer. Net als bij de overige codes kunnen verschillende lokale weergaven worden toegevoegd.
Veranderingen
De functionaliteit van de taxonomie is gelijk gebleven, maar de manier waarop taxa worden
opgeslagen is verbeterd. Een enkel taxonobject bevat nu alle informatie die nodig is om de naam
van dat taxon af te leiden, en het is eenvoudiger geworden om codes te zoeken. Rangen kunnen nu
in verschillende talen worden weergegeven, en hun identiteit is gescheiden van hun hiërarchische
relatie. Door taxa te modelleren als uitgebreide codes is de beschrijving eenvoudiger geworden.
1 Merk op dat dit beter anders gemodelleerd kan worden, met een TranslatableEntity klasse waar de representationrelatie
aan hangt, en waar zowel Code als Rank die relatie en het identity-attribuut van overerven. Rank krijgt dan
zelf nog een parent-relatie toegevoegd. Dit is in de diagrammen in dit document niet gedaan om de interdisciplinaire
communicatie te vereenvoudigen, maar kan in afgeleide technische datamodellen beter wel doorgevoerd worden.

Waarnemingen
Afbeelding 4: Module Survey
De module Survey is het hart van dit datamodel. In deze module worden de resultaten van gedane
waarnemingen opgeslagen. Deze module gebruikt alle drie de andere modules als referentie om
waarnemingen tegen te definiëren.
Een soortwaarneming is een gebeurtenis, waarbij een waarnemer de abundantie 2 van een bepaald
object in een bepaalde omgeving vaststelt. Afhankelijk van de onderzoeksmethode wordt een deel
van de aanwezige objecten ook waargenomen. Bij het vastleggen van het resultaat van een
soortwaarneming worden de eigenschappen van de omgeving en het object opgeslagen, en de
vastgestelde hoeveelheid en de manier waarop die is vastgesteld.
Een waarneming wordt altijd gedaan op een bepaalde (geografische) locatie, en tijdens of in een
bepaalde periode. De biotoop waarin de objecten zijn geobserveerd kan ook worden vastgelegd.
Een waarneming wordt gedaan aan een soort, waarvan iets (individuen, kolonies, resten, sporen,
etc.) wordt geteld (dit levert de eenheid behorende bij de telwaarde). Het waargenomen object kan
een bepaald geslacht hebben, zich in een bepaald levensstadium bevinden, en gedrag vertonen.
De locatie wordt onderzocht volgens een bepaalde onderzoeksmethode, volgens welke een bepaald
2 Van Dale: mate waarin iets in een bepaald gebied of systeem voorkomt, bijv. het aantal individuen van een bepaalde
diersoort of het percentage van een element in de natuur.

deel van de aanwezige objecten wordt waargenomen. Deze worden vervolgens gedetermineerd
volgens een determinatiemethode.
De hoeveelheid (aantal, bedekking) objecten wordt vervolgens vastgesteld, en het resultaat geeft de
waargenomen abundantie van het object in de omgeving.
Naam
attribuut
Schaal/Type Definitie
Identiteit identity URI De unieke identifier van de waarneming.
Waar /
Wanneer
Wat
Hoe
location Cartesisch /
Interval
De geografische locatie van de onderzochte omgeving.
period Interval De tijd op of gedurende welke het onderzoek plaatsvond.
biotope Nominaal,
Hiërarchisch
species Nominaal,
Hiërarchisch
unit Nominaal,
Hiërarchisch
sex Nominaal,
Hiërarchisch
lifeStage Nominaal,
Hiërarchisch
activity Nominaal,
Hiërarchisch
surveyMethod Nominaal,
Hiërarchisch
determination
Method
Nominaal,
Hiërarchisch
De biologische omgeving waarin de objecten zich
bevonden.
De taxonomische soort waaraan de waarneming gedaan is
of waarop de waarneming betrekking heeft.
De teleenheid; ofwel wát van de soort er is geteld.
Het geslacht van de waargenomen objecten.
Het levensstadium waarin het object zich bevindt, zich
bevond toen het doodging, of waarvan een spoor is
gevonden.
Het gedrag dat door het object vertoond wordt.
Hoe de omgeving onderzocht is.
Het zintuig dat gebruikt is voor het waarnemen en
determineren, en eventuele hulpapparatuur.
Hoeveel abundance Absoluut De waargenomen hoeveelheid objecten.
Tabel 6: Een waarneming in EcoGRID
Voor de attributen die op een nominale, hiërarchische schaal zijn gedefinieerd, zijn in de modules
Codes en Taxonomy overeenkomstige klassen gedefinieerd. Deze attributen worden dus als relaties
gemodelleerd. De attributen location, period en abundance zijn deelklassen, waarin de waarde en
de onzekerheid daarin vastgelegd kunnen worden.
Onzekerheid
Bij het doen van waarnemingen speelt onzekerheid een rol. Soms is een soort in het veld niet
precies te determineren, zijn er teveel individuen om ze precies te tellen, of is niet exact vastgelegd
waar en wanneer de waarneming gedaan is.
Voor alle attributen (met uitzondering van identity, uiteraard) van een waarneming wordt de
onzekerheid in de meting impliciet vastgelegd. Voor de nominale schalen wordt dit gedaan door
codes op diverse detailniveaus te definiëren; door deze onderling in een hiërarchie te verbinden
wordt het zoeken vereenvoudigd.

Voor de attributen period en location wordt er een bereik (minimum en maximum) gegeven, en een
aanduiding van of de gemeten abundantie ergens binnen het bereik is waargenomen (dan is er
sprake van onzekerheid), of dat de werkelijke waarde het hele bereik is (dan is er een heel gebied
afgezocht of heeft men gedurende de hele periode staan tellen).
Naam Attribuut Type Definitie
start datetime Het tijdstip waarop de periode begint.
stop datetime Het tijdstip waarop de periode eindigt.
fullySampled boolean Geeft aan of de gemeten abundantie over de hele periode gemeten is
(true), of dat het een momentopname ergens gedurende de periode
betreft (false).
Tabel 7: De klasse Period
Naam Attribuut Type Definitie
geometry geometry De geografische locatie waarop of waarbinnen de
waargenomen objecten zich bevonden.
fullySampled boolean Geeft aan of de gemeten abundantie over het hele
gebied gemeten is (true), of dat het ergens binnen het
gebied gemeten is (false).
Tabel 8: De klasse Location
De abundantie wordt weergegeven op een absolute schaal, wederom met een minimum en een
maximum. Die geven hier altijd een onzekerheid aan.
Naam Attribuut Type Definitie
min real De ondergrens van het interval.
max real De bovengrens van het interval.
Tabel 9: De klasse Abundance
In de praktijk is het bij het doen van veldwaarnemingen niet altijd eenvoudig om een precieze
hoeveelheid of bedekkingspercentage vast te stellen. Vooral bij het inventariseren van begroeiing
worden daarom andere, nominale schalen gebruikt, en de daarmee gedane waarnemingen moeten
ook kunnen worden opgeslagen.
Hoewel deze schalen goed aansluiten bij wat men in het veld aantreft, zijn ze niet erg bruikbaar
voor kwantitatieve analyse. Omdat we wel kwantitatieve analyses willen maken, moet er een
vertaalslag plaatsvinden. Omdat de waarden op deze ordinale schalen vaak meer bevatten dan alleen
de hoeveelheid van voorkomen moet ook de oorspronkelijke code bewaard blijven.
Voor elke schaal wordt een Unit-code (object) gedefinieerd waarin de eenheid wordt weergegeven
waarin de kwantitatieve representatie wordt uitgedrukt. De numerieke abundantieattributen worden
gevuld met de numerieke vertaling van de hoeveelheidscode. Omdat deze ordinale schalen niet
algemeen toepasbaar zijn wordt het attribuut voor de hoeveelheidscode niet aan het algemene
datamodel toegevoegd, maar als setspecifiek attribuut opgenomen.
Gebiedsonderzoeken
De klasse Survey geeft een gebiedsonderzoek weer. Het attribuut area bevat het onderzochte gebied,
Via de relatie results is de DataSet waarin de resultaten van het onderzoek zijn samengebracht te
vinden.

Naam Attribuut Type Definitie
identity URI De unieke identiteit van het onderzoek.
area geometry Het onderzochte gebied.
Tabel 10: De klasse Survey
Datasets
Naam Attribuut Type Definitie
identity URI De unieke identifier van de dataset.
name string Een korte naam van de dataset.
description string Een precieze omschrijving van de dataset.
Tabel 11: De klasse DataSet
Waarnemingen worden bij opslag over het algemeen gegroepeerd, zodat er een goed geordende
gegevensverzameling ontstaat. Afhankelijk van hoe de inwinning georganiseerd was kunnen
verschillende manieren van groeperen zinvol zijn.
Waarnemingen worden in EcoGRID verzameld in datasets. Een dataset heeft een naam en een
beschrijving. Daarnaast is er een parent-relatie tussen datasets, die het mogelijk maakt datasets
hiërarchisch te groeperen. Verder heeft een dataset een owner- en een maintainer-relatie met een
Contact, waarmee eigenaar en beheerder van de dataset worden vastgelegd.
Kwaliteitsaanduiding
Naam
Attribuut
Type/Schaal Definitie
validatorVersion string Het versienummer van de gebruikte validatiedienst.
validationDate datetime De datum waarop de waarneming gevalideerd is.
reliability Nominaal,
Hiërarchisch
probability Nominaal,
Hiërarchisch
In hoeverre de waarnemer volgens de instructies heeft gehandeld,
de determinatie goed gedaan is en de waarneming goed is
ingevoerd.
De a priori kans dat deze waarneming gedaan zou zijn, gegeven
dat een waarnemer in de aangegeven periode de aangegeven
locatie op de aangegeven manier zou onderzoeken.
byExpert boolean Geeft aan of dit validatieresultaat door een expert opgesteld is (in
tegenstelling tot een geautomatiseerd systeem).
Tabel 12: De klasse ValidationResult
De kwaliteitsaanduiding geeft een indicatie van de kwaliteit van een waarneming. Dit is niet
hetzelfde als de geschiktheid voor een bepaald doel: die is afhankelijk van het doel en dus geen
eigenschap van de waarneming alleen. Ook is dit geen indicatie van de voortgang in een
validatieproces 3 .
Wel is er een indicatie van de betrouwbaarheid en de waarschijnlijkheid van een waarneming.
Omdat deze waarden nooit exact uitgerekend kunnen worden en we willen voorkomen dat de
nauwkeurigheid groter is dan ze lijkt, worden deze waarden op een nominale schaal weergegeven.
3 Dit beschouwen we als een interne aangelegenheid van de component(en) die de validatie uitvoeren. De
procesvoortgang wordt niet uitgeleverd aan afnemers en is dus niet in dit model opgenomen.

Deze attributen worden hier dus als relaties met de klassen Reliability en Probability gemodelleerd.
Het versienummer van de gebruikte validatiedienst wordt opgeslagen om bij versies waarin fouten
zijn ontdekt te kunnen achterhalen wat er opnieuw gevalideerd moet worden. Ook het tijdstip van
validatie wordt vastgelegd.
Het attribuut byExpert geeft aan of de validatie door een expert gedaan is. Deze informatie is van
belang om te kunnen voorkomen dat een waarneming meer dan één keer bij een expert langs komt.
Veranderingen
Ten opzichte van het EcoGRID datamodel versie 1 zijn er een aantal verbeteringen en wijzigingen
doorgevoerd. Het attribuut sex is afgesplitst van het attribuut life stage. Het count type attribuut is
gegeneraliseerd naar het attribuut unit, waardoor waarnemingen van sporen en resten beter
gemodelleerd kunnen worden. Een deel van de functionaliteit van het observation type attribuut is
hierin terecht gekomen. De overige functionaliteit is verdeeld over de nieuwe attributen survey
method en determination method. Hiermee is ook aan een belangrijke informatiebron voor de
validatie, namelijk de manier waarop de inventarisatie gedaan is, eenduidig beschikbaar gekomen.
Relaties tussen waarnemingen zijn geheel nieuw, en geven invulling aan een aantal in het afgelopen
jaar naar voren gekomen wensen.
In het datamodel versie 1 worden waarnemingen gegroepeerd in sessies en projecten. Met het
afsplitsen van de administratieve gegevens is de focus van het datamodel volledig komen te liggen
op het modelleren van de resultaten van projecten en sessies. Bovendien bleek dat in sommige
meetnetten een diepere hiërarchie beter zou passen, terwijl voor losse waarnemingen met een enkele
groepering kon worden volstaan. Waarnemingen worden hier dus gegroepeerd in datasets, die op
zich weer gegroepeerd kunnen worden in hogere datasets. Het beheer van gegevenscollecties met
behulp van een van dit logisch datamodel afgeleid databasemodel wordt zo verbeterd, en de
resultaten van diverse soorten meetmethoden kunnen netjes worden ingepast. Bovendien is het
model eenvoudiger geworden.
Het is nu mogelijk om expliciet aan te geven wie de eigenaar en wie de beheerder is van een
dataset. Daarmee komen we tegemoet aan organisaties die waarnemingen van anderen beheren
en/of gegevens willen delen.
Tot slot is er aan de waarneming een kwaliteitsaanduiding toegevoegd. Deze bevat alle gegevens
die nodig zijn om, samen met de overige attributen, afnemers en productontwerpers een beeld te
geven van de bruikbaarheid van een waarneming voor hun specifieke probleem.

Contactinformatie
Van de eigenaar en beheerder van een dataset, en de validator van een waarneming worden de
contactgegevens vastgelegd. Hoe dit gebeurt is vastgelegd in de module Contacts. Het doel is hier
niet om alle waarnemers te gaan registreren 4 , maar om van enkele organisaties en eventueel
individuen (vooral eigenaars van datasets waarschijnlijk) vast te kunnen leggen hoe men contact
met ze kan opnemen.
Naam Attribuut Type Definitie
identity URI De unieke identifier van deze
contactgegevens.
name string De naam van de organisatie.
address string Straat en huisnummer van het postadres.
postalCode string Postcode van het postadres.
town string Plaatsnaam van het postadres.
country string Landnaam van het postadres.
telephone string Telefoonnummer van de organisatie.
email string Emailadres van de organisatie.
worldWideWeb URI Webadres van de organisatie.
Tabel 13: De klasse Contact
Veranderingen
Omdat persoonlijke gegevens van waarnemers niet zomaar uitgewisseld mogen worden, en er
bovendien geen reden is om deze aan een afnemer van gegevens ter beschikking te stellen, zijn deze
uit het model verdwenen. Aanbieders kunnen deze gegevens uiteraard bijhouden als ze dat willen,
maar doen dat in een eigen systeem en zijn geheel vrij in de inrichting daarvan.
In plaats van de observers- en van de organisations-tabel is er een object contact, dat
contactinformatie bevat. Hierdoor kunnen nu ook de contactgegevens van organisaties worden
opgeslagen. Deze constructie is precies genoeg om eigenaar, beheerder en validator vast te kunnen
leggen.
4 Informatie over de waarnemer en andere betrokkenen is nog niet in dit datamodel opgenomen omdat we nog te
weinig inzicht hebben in wat er precies nodig is en hoe we dat het beste kunnen aanpakken. Dit zal dus in de
toekomst worden toegevoegd.

Appendix: Relaties tussen Waarnemingen
Deze appendix beschrijft een geplande uitbreiding die evenwel nog niet in het datamodel voor
Release 1 is opgenomen. De reden om het nog even weg te laten is dat we nog niet weten wat
precies de implicaties zijn van deze constructie. Het is de bedoeling om dit in de context van het
project dataconversie verder uit te zoeken, en dan zodra het kan deze uitbreiding toe te voegen.
Complexe Waarnemingen
Soms worden er waarnemingen gedaan die niet eenvoudig in een reeks attributen zijn vast te
leggen. Vooral meetnetten leveren vaak wat complexere waarnemingsscenario's op. In dit model
wordt hierin voorzien door ze te splitsen in enkelvoudige waarnemingen, die elk individueel correct
maar onvolledig zijn, en deze enkelvoudige waarnemingen vervolgens te koppelen zodat de
complete informatie af te leiden is.
Zo kan een waarneming van de vorm “gebied X is onderzocht en op de punten p, q en r binnen X
bevond zich een individu” worden gesplitst in een waarneming van drie individuen in gebied X, en
drie waarnemingen van een enkel individu op punten p, q en r. Deze waarnemingen worden
vervolgens gekoppeld via een “is een precisering van”-relatie. De waarneming wordt dan
opgeslagen als “In gebied X bevonden zich drie individuen, en wel op punten p, q en r”. Bovendien
is elk van de vier enkelvoudige waarnemingen op zich correct.
Dubbelingen
Er zijn soms bijzondere situaties waarin door verschillende personen een groot aantal
waarnemingen wordt gedaan van hetzelfde individu. Ook gebeurt het dat er van een enkele
waarneming meerdere records bestaan in een gegevensverzameling. Zeker in het eerste geval (waar
het duplicaat niet zomaar gewist kan worden) is het om misinterpretatie te voorkomen belangrijk
dat er aangegeven kan worden dat het om een dubbeling gaat.
Ook dit kan worden opgelost door een relatie aan te brengen tussen de observaties, in dit geval een
“zelfde individu(en)”-relatie.
Afgeleide Gegevens
Naast directe waarnemingen worden er door bijvoorbeeld de PGO's ook van waarnemingen
afgeleide gegevens over het voorkomen van soorten uitgewisseld. Als de primaire gegevens ook
beschikbaar zijn dan kan er een “afgeleid van”-relatie worden gelegd, zodat bijvoorbeeld bij een
correctie van de brongegevens de verwerking opnieuw gedaan kan worden. In dit geval geeft het
survey type attribuut de gebruikte verwerkingsmethode weer.
Observation Relation
De drie bovengenoemde scenario's, en potentieel andere, worden opgelost door het Observation
Relation object. Dit object legt een gerichte relatie van een bepaald relatietype tussen twee
waarnemingen. Voor elk relatietype wordt een code gedefinieerd.
Dit is een flexibele constructie, die geen wijziging van het datamodel vereist als er een nieuw soort
relatie nodig is. Het is daarmee ook een risicovolle constructie, omdat het nog niet duidelijk is wat
voor soorten relaties er allemaal kunnen zijn, en een grote hoeveelheid relatietypen het correct
interpreteren van gegevens flink bemoeilijkt. Het lijkt daarom verstandig om het toevoegen en
wijzigen van relatietypen vooraf te laten gaan door een breed overleg, waarbij niet alleen de
codecommissie maar ook de datamodelbeheerders, architectuurcommissie en aanbieders van
gegevens betrokken zijn.