Gegevensbeschrijvingen/Metagegevensmodel

Uit NORA Online
Ga naar: navigatie, zoeken


De metagegevens in de handreiking beschrijving informatieobjecten zijn ondergebracht in een gegevensmodel met verschillende objecttypen. Al naar gelang de informatiebehoefte kan een keuze gemaakt worden die relevant is in een specifieke situatie. Als het alleen om de betekenis van begrippen te doen is, zonder verdere details over de bron, registratie en de syntax van voorkomens daarvan, dan volstaan de groepen 'Termtype en 'Concepttype'.

Afbeelding 1: Referentie metamodel gegevenscatalogus

Begrip = Concept + term

De metagegevens in het onderdeel 'Concepttype' betreffen de betekenis van opgenomen begrippen en indien gewenst, verwijzingen naar de verantwoordelijke autoriteit voor de definitie, naar de wetgeving en de authentieke catalogus waarin het begrip is opgenomen. Voor het benoemen van een concept is een aparte entiteit 'Term' opgenomen, die tezamen met het concept het begrip vormt. Hiermee wordt de mogelijkheid geboden om naast de catalogusterm ook synoniemen (andere namen voor hetzelfde concept) op te nemen. Homoniemen (termen die twee of meer verschillende concepten aanduiden) dienen te worden voorkomen om verwarring te vermijden, door toevoeging van een onderscheidend achtervoegsel in de term, dat kenmerkend is voor het bedoelde concept.

De eigenlijke betekenis van het concept wordt in de definitie door middel van tekst beschreven. Dit kan onder andere door de naast hogere generalisatie te benoemen plus het kenmerkende verschil met andere specialisaties daarvan (intensionele definitie volgens Aristoteles[1]).

DefinitieIngezetene.png
Zo zou een ingezetene (van Nederland) kunnen worden gedefinieerd als een natuurlijk persoon (generalisatie) met een woonadres in een gemeente in Nederland (verschil met natuurlijke personen die geen ingezetene zijn).

Deze definitie kan worden gemodelleerd door twee relaties naar andere begrippen:

  1. een relatie 'Specialisatie van' naar 'natuurlijk persoon'.
  2. een relatie 'heeft woonadres in' (Gerelateerd aan) naar 'Gemeente'.

Deze twee relaties naar andere begrippen verschijnen op metaniveau als relaties van het concepttype naar zichzelf en zijn in het model zichtbaar als 'oortjes' (head scratchers) op de entiteit 'Concepttype'. Naast 'Specialisatie van' zijn ook twee andere hiërarchische relaties gemodelleerd: 'Onderdeel van' en 'Instantie van'. De omgekeerde relaties van 'Specialisatie van', 'Onderdeel van' en 'Instantie van', te weten 'Generalisatie van', 'Compositie van' en 'Classificatie van' zijn impliciet gemodelleerd door de pijl in omgekeerde richting te lezen.

Naast de definitie is ook een veld 'Toelichting' opgenomen, waarin bijvoorbeeld de reden voor deze vorm van definitie of de intentie van de definitiegever kan worden toegelicht. Extentionele definities (definitie door opsomming van de mogelijke waarden ervan) kunnen worden gemodelleerd door de voorkomende waarden als begrip op te nemen in de catalogus met een relatie 'Instantie van' of 'Specialisatie van' naar het desbetreffende concept. Als het concept als attribuuttype is opgenomen in de catalogus kunnen de voorkomende waarden in een referentielijst verwijzen naar deze concepten voor bijvoorbeeld de definitie.

Gegevenstype

Worden van het concepttype voorkomens (instanties) geregistreerd, dan zijn diverse metagegevens relevant. Ze zijn gemodelleerd bij de entiteit 'Gegevenstype' in de catalogus, hier als specialisatie van het concepttype. Het betreft metagegevens over het al dan niet authentiek zijn van de gegevensWeergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat. Het betreft hier alle vormen van gegevens, zowel data uit informatiesystemen als records en documenten, in alle vormen zoals gestructureerd als ongestructureerd, ontvankelijkheid voor terugmelden, in onderzoekstelling, temporele metagegevens (sinds wanneer wordt dit gegevenstype geregistreerd en sinds wanneer historie daarvan), aanduidingen en versiehistorie. Er is een uitgaande relatie naar een Betrokkenetype, de instantie die het gegevenstype registreert. Daarnaast is er een uitgaande relatie naar een gegevensregeltype, waarmee gegevensregels kunnen worden gemodelleerd.

Gebeurtenistype en mutatietype

Er is ook een inkomende relatie vanuit Mutatietype, dat aangeeft door welke gebeurtenissen mutaties kunnen worden doorgevoerd op het gegevenstype. Mutatietype is een n:m relatieobjecttype tussen gebeurtenistype en gegevenstype. Een gebeurtenistype kan verschillende gegevenstypen muteren en een gegevenstype kan door meerdere gebeurtenistypen worden gemuteerd. Er is voorlopig van afgezien om hierbij nog een aparte entiteit 'handelingstype' te modelleren conform het 'Whitepaper Gebeurtenissen'[2], als bundeling van een serie als één transactie uit te voeren mutaties. Deze keuze is enerzijds gemaakt om een potentiële overlap met proces- of zaakbeschrijvingen te vermijden, en anderzijds omdat met dergelijke beschrijvingen nog weinig ervaring is opgedaan.

Het doel van deze entiteiten in dit model is vooral om aan te geven door welke gebeurtenissen gegevensWeergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat. Het betreft hier alle vormen van gegevens, zowel data uit informatiesystemen als records en documenten, in alle vormen zoals gestructureerd als ongestructureerd kunnen worden gemuteerd, hetgeen iets zegt over de kwaliteit en actualiteit van de gegevensWeergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat. Het betreft hier alle vormen van gegevens, zowel data uit informatiesystemen als records en documenten, in alle vormen zoals gestructureerd als ongestructureerd. De metagegevens betreffen het document- dan wel zaaktype, pré- en postconditie en de tijdsaanduiding.

Gebeurtenistype is zelf een specialisatie van Concepttype, met alle attributen en relaties van dien. Rollen en betrokkenen bij het gebeurtenistype zijn gemodelleerd zoals in het zakenmodel Gemeenten. Een gebeurtenistype kan onderdeel zijn van een ander gebeurtenistype en kan een ander gebeurtenistype als aanleiding hebben. Beide relaties zijn hier als 'oortjes' (head scratchers) gemodelleerd.

Object-, gegevensgroeps- en attribuuttypen

Gegevenstypen kunnen gemodelleerd zijn als object-, gegevensgroeps- en attribuuttypen. In de VN-standaard CCTS worden object- en attribuuttypen aangeduid met respectievelijk 'Aggregate Core Components' en 'Basic Core Component'. Ze zijn hier als specialisaties van het gegevenstype gemodelleerd. Een object- en een gegevensgroepstype is daarbij samengesteld uit attribuut- en eventueel gegevensgroeptypen. Bij objecttype zijn de aanduidingen van het id, de populatie en kwaliteit als metagegeven opgenomen.

In navolging van het Relationeel Model en CCTS zijn relaties (associaties, Association Core Components) als attribuuttypen (foreign keys) van een objecttype gemodelleerd, die verwijzen naar een identificatieHet bekend maken van de identiteit van personen, organisaties of IT-voorzieningen. van het andere objecttype. N:m-relaties worden gemodelleerd als objecttypen met minstens twee associatieve attribuuttypen. Er is afgezien van het gebruik van relatiesoorten uit het UML klassenmodel[3].

Bij Attribuuttype is aangegeven bij welk object- of groepstype het hoort, de kardinaliteit en de kwaliteit. Met 'Identificatiesleutels' wordt aangegeven met welke (combinatie van andere) attribuuttypen een object uniek kan worden geïdentificeerd als het id. van het object niet bekend is. Zo kan een huisadres in Nederland uniek worden geïdentificeerd met de combinatie van woonplaats, straatnaam, huisnummer en eventueel -letter en -nummertoevoeging. In plaats van woonplaats en straatnaam kan ook de postcode worden gebruikt. De sleutels kunnen worden aangegeven met een nummer. Zo kunnen woonplaats en straatnaam een '1' krijgen, postcode een '2', terwijl huisnummer, -letter en -nummertoevoeging zowel een '1' als een '2' krijgen. De leesbaarheid van de catalogus is erbij gebaat als de applicatie de beide alternatieve identificatiesleutels als combinaties van de desbetreffende attribuuttypen zelf afleidt, dan wel dat deze redundant worden weergegeven in een papieren versie.

Bij opsommingen kan een enumeratie (opsomming van door puntkomma's gescheiden waarden) worden opgenomen. Er kan ook voor worden gekozen om te verwijzen naar een aparte referentielijst. Dat gebeurt altijd indien die beheerd wordt door een andere partij. In dat geval wordt ook naar de beheerder verwezen. In de referentielijst kunnen een code en bijbehorende waarde worden opgenomen. De waarde kan verwijzen naar een Concept zodat nadere metagegevens, zoals de definitie kunnen worden opgenomen. Begin- en einddatum zijn opgenomen als sprake is van historie van waarden in de lijst (Bijvoorbeeld geboorteland = Joegoslavië. Ten tijde van de geboorte was dat een geldige waarde. Voor een aanduiding van het land waarnaar een persoon nu is verhuisd inmiddels niet meer).

Bij een attribuuttype met een getal als waarde kan gebruik gemaakt worden van de metagegevens datatype, maximum, minimum en eenheid om de mogelijke waarden aan te duiden. Voor details van het datatype kan verwezen worden naar een aparte entiteit Datatype. Dat bespaart ruimte en typewerk, voor datatypes die vaker bij verschillende attribuuttypen worden gebruikt. Datatype kan echter ook als een attribuuttype worden opgevoerd dat is samengesteld uit het datatype sec, aangevuld met veldlengte, decimalen en eenheid (bijvoorbeeld reëel getal, 10.3, €). Bij enumeraties of referentielijsten kan een datatype 'tekst' worden aangevuld met (min-max) lengte, codering en repertoirebeperking, bijvoorbeeld, 4-40, UTF-8, MES-1. Zie voor een syntaxspecificatie bij het Datatype (samengesteld) in de Bijlage waardenlijsten.

Tenslotte zijn 'Registratiecatalogustype' en 'Distributietype' toegevoegd conform ADMS, voor metagegevens over de catalogus waarin de begrippen zijn opgenomen en de mogelijke distributie en publicatie van de inhoud ervan. In dit model is voorzien dat ook metagegevens van afzonderlijke begrippen en gegevensWeergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat. Het betreft hier alle vormen van gegevens, zowel data uit informatiesystemen als records en documenten, in alle vormen zoals gestructureerd als ongestructureerd apart gedistribueerd kunnen worden, bijvoorbeeld voor RDF/Linked Open Data toepassingen. Waardelijsten van de metagegevens zijn beperkt gehouden.

Vaker gebruikte metagegevens zijn in de lijst met referentienamen en -definities (PDF, 63 kB) vet afgedrukt. Omdat metagegevens onder verschillende benamingen en met verschillende definities voorkomen zijn ze aangeduid met referentienamen en -definities, indien het naar de geest om een overeenkomstig metagegeven handelt. Bij de metagegevens zijn in deze bijlage verwijzingen opgenomen naar mogelijk van toepassing zijnde standaarden. Aanbevolen wordt om aan te sluiten bij de voor het beoogde doel meest relevante standaard en de namen en definities daarvan over te nemen.

Bijlage waardelijsten

De aangereikte waardenlijsten geven de meest gebruikte waarden weer, zonder pretentie van volledigheidBetekent dat alle procesgebonden informatie is vastgelegd en wordt beheerd die aanwezig zou moeten zijn conform het beheerregime dat voor dat proces is vastgesteld.. Indien waarden in de praktijk worden gemist, geef dit s.v.p. door aan architectuurEen beschrijving van een complex geheel, en van de principes die van toepassing zijn op de ontwikkeling van het geheel en zijn onderdelen.@ictu.nl

Conditietype

  • preconditie
  • postconditie
  • invariant

Datatype

  • tekst (string)
  • Id
  • URI
  • booleaans getal (boolean)
  • duur (duration)
  • datum (date)
  • datum_tijd (dateTime)
  • jaar (gYear)
  • jaar_maand (gYearMonth)
  • geheel getal (integer)
  • natuurlijk getal (nonNegativeInteger)
  • reëel getal (decimal)
  • reëel getal (float)
  • reëel getal (double)
  • punt (GM_Point)
  • lijn (GM_Curve)
  • vlak (GM_Surface)
  • multivlak (GM_Multisurface)
  • volume (GM_Solid)
  • getal hexadecimaal (hexBinary)
  • getal 64 binair (base64Binary)
  • keuze (choice)
  • samengesteld (union)

Datatype (samengesteld)

  • (tekst|ID|URI) (<lengte>|<minimale lengte>..<maximale lengte) <codering>? <beperking>? <taal>?
  • getal <lengte><.decimalen>? <eenheid>?
  • (hex|binair 64) (<lengte>|<minimale lengte>..<maximale lengte) <eenheid>?
  • (datum|datumTijd|jaar|jaarMaand|duur|float|double|punt|lijn|vlak|multivlak|volume)
  • booleaans getal
  • lijst (list) (<lengte>|<minimale lengte>..<maximale lengte) <formaat>
  • samengesteld (union) <datatype> …
  • keuze (choice) <datatype> …

Legenda:

(a|b): keuze tussen a of b
<element>?: facultatief element
.decimalen: aantal decimalen inclusief komma

Formaat (Distribution)

  • RDF/XML
  • XSD/XMI
  • HTML
  • ODF
  • PDF
  • ZIP van één of meer bovenstaande

Lengte

  • (<lengte>|<minimale lengte>..<maximale lengte)
  • <lengte><.decimalen>?

Minimum: (<minInclusiv>waarde|<minExclusiv>waarde)

Maximum: (<maxInclusiv>waarde|<maxExclusiv>waarde)

Licentietype

  • openbaar: zonder restricties
  • openbaar: met restricties
  • creative commons
  • autorisatieHet proces van het toekennen van rechten voor de toegang tot geautomatiseerde functies en/of gegevens in ICT voorzieningen: doelbindingHet principe dat iemand (persoon of organisatie) alleen informatie mag vragen, opslaan, gebruiken, delen ten behoeve van welbepaalde, uitdrukkelijk omschreven en gerechtvaardigde doeleinden. wettelijk
  • autorisatieHet proces van het toekennen van rechten voor de toegang tot geautomatiseerde functies en/of gegevens in ICT voorzieningen: doelbindingHet principe dat iemand (persoon of organisatie) alleen informatie mag vragen, opslaan, gebruiken, delen ten behoeve van welbepaalde, uitdrukkelijk omschreven en gerechtvaardigde doeleinden. autorisatiebesluit of certificaat

Mutatietype

  • opvoeren
  • wijzigen
  • beëindigen

Rol

Referenties

  1. Aristoteles (384 – 322 v. Chr.): Definitio fit per genus proximum et differentiam specificam)
  2. Whitepaper Gebeurtenissen V1.0 final, Rob Onink , 27-05-2013
  3. Over de modellering van relaties volgens het UML klassenmodel bestaat geen consensus binnen de kring van basisregistraties


⇠ Vorige pagina: Handreiking
Persoonlijke instellingen
Naamruimten

Varianten
Handelingen
Hulpmiddelen