Modelleren van metagegevens en historie op attribuutniveau

[lvdbrink]

DisGeo Eisen aan model samenhangende objectenregistratie bevat de eis dat metagegevens en historie op attribuutniveau worden bijgehouden. Dit is nodig voor (schatting) 10% van de use cases, waaronder WOZ, waar men per gegeven de historie en andere metagegevens wil kunnen zien.

Maar het zorgt voor een complexer semantisch model en datastructuur – hoe hou je dit weg bij de andere 90% van het gebruik? (i.e. hoe zorg je ervoor dat het, wanneer het niet nodig is, ook niet in de weg zit).

Hoe kunnen we dit, zoveel mogelijk aansluitend op MIM+NEN3610+NTA8035/ISO2660, het beste modelleren?

[gabswiersma]

Achtergrond:

In de SOR wordt niet meer gesproken over formele en materiële historie. Reden hiervoor is dat de betekenis van deze eigenschappen momenteel op verschillende manieren wordt geïnterpreteerd in de registraties. Daarom wordt in de context van het SOR gesproken over tijdslijn ‘registratie’ en ‘geldigheid’. Het gaat hierbij om het moment dat een gegeven wordt opgenomen in de registratie, en het moment dat het is geconstateerd in de werkelijkheid. Deze constatatie komt dus niet altijd overeen met wanneer veranderingen in de werkelijkheid zijn opgetreden (dit lijkt nog wel het geval te zijn voor materiële historie zoals beschreven in de MIM/NEN 3610 2011).

Definities terzijde, in de MIM wordt op het metaniveau een mechanisme hiervoor gebruikt - indicatie formele historie / indicatie materiële historie. Hiermee kan in het model worden aangegeven of historie aspecten voor een bepaalde attribuutsoort/relatiesoort geraadpleegd kunnen worden. Historie op logisch niveau wordt niet uitgewerkt in de MIM. Wel wordt dit nodig geacht in de SOR, voor een klein aantal use cases (vaak gerelateerd aan het verlenen van vergunningen/juridische processen). Echter is historie niet het enige wat op attribuutniveau moet kunnen worden vastgelegd, andere metagegevens zijn voor deze use cases ook gewenst. Welke dit precies zijn is nog niet concreet besloten, het gaat voornamelijk om kwaliteitsaspecten: wijze van inwinning van een gegeven, de uitvoerder van de inwinning, status van een gegeven (bv of de waarde van een attribuut inOnderzoek is).

Voor deze use cases, waarbij historie/metagegevens op attribuutniveau moeten worden bijgehouden, is een gestandaardiseerde oplossing nodig. Het model voor de SOR moet beheersbaar en begrijpelijk blijven, terwijl het registreren van deze gegevens dus ook mogelijk moet zijn. Oplossingsrichtingen: modelconstruct introduceren voor het registreren van ‘gegevens over gegevens’ (mogelijke metamodel extensie voor MIM)*, complexiteit vermijden door verschillende modellen te creëren, richtlijnen opzetten voor het omgaan met historie tijdens uitwisseling van gegevens.

*Het MIM vocabulaire kan ook uitgedrukt worden in Linked Data. In de NTA-8035 worden mogelijkheden behandeld voor het verwerken van metagegevens op attribuutniveau in de modellering (Bekend RDF-issue: triple level data). Het is nu nog onduidelijk of, met de gesuggereerde workarounds, nog kan worden voldaan aan de minimale eisen die worden gesteld aan MIM vocabulaires.

[pmaria]

Relevante passages uit het DiS Geo eisen document (Werkversie 05 oktober 2020):

Bijvoorbeeld geometrie die volledig wordt ontleend aan een opname (bijvoorbeeld luchtfoto) zal als beginGeldigheid (tijdlijn geldigheid) de datum van de luchtfoto krijgen, omdat de feitelijke ingangsdatum niet nauwkeuriger kan worden ingeschat.

Wanneer iemand een bouwvergunning krijgt, kan voorzien worden dat dit object in de toekomst ook geregistreerd zal worden. De datum vanaf wanneer daadwerkelijk sprake zal zijn van een "bestaand object" kan echter niet exact voorzien worden. Een inschatting van deze datum zal de basis vormen voor de tijdlijn geldigheid in de toekomst.

Afnemers kunnen daarbij per attribuut informatie krijgen over beide tijdlijnen.

Er zou bijvoorbeeld afgezien kunnen worden van het vastleggen van deze tijdlijnen, wanneer geen enkele gebruiker nu of in de toekomst behoefte heeft aan deze tijdlijnen voor het desbetreffende attribuut.

Aan de andere kant kan ook de principiële keuze gemaakt worden dat gegevens in een basisregistratie "niet weggegooid worden". Dat uitgangspunt zou betekenen dat voor alle attributen in de SOR zowel de tijdlijn geldigheid als de tijdlijn registratie verplicht zouden zijn.

Tijdlijnen per attribuut gelden daarbij op semantisch niveau en moeten beschikbaar zijn in de informatieproducten voor gebruikers. Dit model geeft geen richtlijnen over de wijze waarop dit uiteindelijk in de registratie geïmplementeerd gaat worden.

[pmaria]

Relevante passages uit DiS Geo: Architectuurbeschrijving Voorzieningen Samenhangende Objectenregistratie (Consultatieversie 15 november 2020):

Van ieder gegeven dat wijzigt wordt vastgelegd: de organisatie die de wijziging heeft gedaan, de voor de wijziging gebruikte dienst, het tijdstip waarop de wijziging heeft plaatsgevonden.

Voor deze component gaan we uit van de volgende werking. Een afnemer doet een terugmelding bij een gegeven (vanuit een eigen applicatie of via een terugmeldloket). Deze component zorgt ervoor dat deze terugmelding wordt geregistreerd en beschikbaar is voor bronhouders. Bronhouders zijn geabonneerd op terugmeldingen op de gegevens waar ze bronhouder voor zijn, zodat de juiste bronhouders worden genotificeerd. De bronhouders onderzoeken de terugmelding, wijzigen indien nodig de objectgegevens en werken de status van de terugmelding bij.

Een terugmelding op een gegeven is zowel een aanduiding bij een gegeven dat er twijfel over bestaat als een aanleiding voor de bronhouder van het gegeven om de terugmelding te onderzoeken. Vanuit de objectenregistratie vinden we dat de terugmelding niks anders is dan een aspect van het gegeven zelf waaruit blijkt dat er twijfel is over de juistheid ervan en dat het in onderzoek is. Hierdoor weten gebruikers dat bij dit specifieke gegeven iets aan de hand is. Dit is met name van belang indien dit gegeven wordt gebruikt in primaire werkprocessen, data-analyse, e.d.

De terugmelding wordt gerelateerd aan het gegeven waar het betrekking op heeft.

Een terugmelding kan betrekking hebben op 1 of meerdere bronhouders.

Er zijn services om terug te melden. De services maakt het mogelijk om een terugmelding te registeren met een verwijzing naar het gegeven.

[pmaria]

Relevante passages/stellingen uit Notitie uitwerking historiemodel voor SOR versie 0.6:

Tijdlijn geldigheid geeft aan gedurende welke periode het desbetreffende kenmerk geldig was of met andere woorden wanneer een verandering is opgetreden in de werkelijkheid (kan ook zijn een besluit) die heeft geleid tot verandering van de desbetreffende attribuutwaarde.

Tijdlijn registratie geeft aan wanneer een bepaald gegeven of een bepaalde wijziging in de administratie is verwerkt. Daarmee kan de tijdlijn registratie met behulp van de computerklok "op de milliseconde precies" worden geregistreerd. Dit tijdstip markeert tegelijkertijd het moment vanaf wanneer degenen die deze informatie raadplegen deze informatie ook daadwerkelijk kunnen gebruiken.

De levensduur van een object kan worden afgeleid uit de volledige historie (tijdlijn geldigheid) van een object. Het opnemen van de (in principe redundante) levensduur (ingangsdatum object en einddatum object) van een object in diverse informatieproducten maakt het mogelijk om analyses over het ontstaan van het object te doen zonder dat de hele historie hoeft te worden achterhaald

Om reden van eenvoud in analyses en performance bij bevraging hebben we in het hier gepresenteerde informatiemodel ingangsdatum object en einddatum wel opgenomen. Bij personen duiden we ingangsdatum en einddatum aan als geboortedatum en overlijdensdatum. Deze vergelijking maken de begrippen en het belang van het registreren van deze metagegeven "ingangsdatum object" en "einddatum object" vaak gemakkelijker te begrijpen.

SOR werkt met één historiemodel

Verder is gekozen voor het uitgangspunt dat de gebruiker de (meta-)informatie over de tijdlijnen per attribuut moet kunnen krijgen.

Toekomstmutaties uitsluitend mogelijk in de tijdlijn geldigheid

afnemers moeten per attribuut informatie kunnen krijgen over de tijdlijnen geldigheid en de tijdlijn registratie.

• Wanneer een afnemer bijvoorbeeld vraagt wanneer de geometrie van een object is geregistreerd, dan ontvangt men tijdstipRegistratie van de geometrie en niet een recenter tijdstipRegistratie waarop een ander attribuut van hetzelfde object is gewijzigd.
• De wijze waarop deze historie op attribuutniveau in de database wordt vastgelegd is geen onderwerp voor het semantisch modelleren van het historiemodel.

Tijdslijn registratie wordt met 1 attribuut vastgelegd: tijdstipRegistratie.

• Vanuit het perspectief dat de tijdlijn registratie daarop aanvullend is, is een implementatie met alleen tijdstipRegistratie (en dus zonder eindRegistratie) de meer logische keuze.
  Immers in deze werkwijze kan je vastleggen op welk tijdstipRegistratie is vastgelegd dat de geometrie van een object (en ook het gehele object) een eindGeldigheid heeft gekregen.

Tijdlijnen per attribuut geldt daarbij op semantisch niveau en moet beschikbaar zijn in de informatieproducten voor gebruikers.

[pmaria]

Relevante passages/stellingen uit Notitie uitwerking metainformatie voor SOR versie 0.7:

De behoefte aan metagegevens kan vanuit de volgende perspectieven worden bekeken:

• metagegevens zijn essentieel voor de gebruiker van gegevens om te beoordelen of het gegeven geschikt is voor het doel waarvoor de gegevens gebruikt worden. Een oppervlakte van een woning die 25 jaar geleden voor het laatst gecontroleerd is, kan geschikt zijn voor het bepalen van een algemeen kengetal over de totale omvang van de woningvoorraad in een gemeente, maar is ongeschikt voor het opleggen van een belastingaanslag aan de eigenaar van die woning;
• metagegevens zijn essentieel voor de bronhouders van de gegevens, omdat ze de noodzakelijke stuurinformatie bieden over de wijze waarop invulling wordt gegeven aan die verantwoordelijkheid en over de werkzaamheden die de komende periode gedaan moeten worden.
• uniformering van metagegeven binnen de samenhangende objectenregistratie zodat op een uniforme wijze inzicht gekregen kan worden in de kwaliteit en de herkomst van de gegevens.

Per objecttype moet bepaald worden of een attribuutsoort wel of niet een bronverwijzing moet hebben.
Het systeem voor meta-informatie moet hier in voorzien. De verplichting per element wordt niet door deze werkgroep vastgelegd maar wordt uiteindelijk in het informatiemodel gespecificeerd. Wij adviseren om het flexibel op te stellen zodat sturing hier op mogelijk is.

De reden van wijziging van een attribuut moet altijd ingevuld worden. We willen veranderingen in geregistreerde attributen zonder duidelijke verwijzing naar de reden van wijziging voorkomen. Dit is ook makkelijker voor het afhandelen van terugmeldingen. Je weet waarom je het gegeven geregistreerd hebt.

Het is aan te bevelen om "reden van wijziging" vast te leggen aan de hand van een waardelijst

precisie en betrouwbaarheid worden breed gezien als de belangrijkste metagegevens.
verwachte en bereikte verschillen in nauwkeurigheid eventueel vastleggen in klasse per attribuuttype

Het vastleggen van de controledatum als datum waarop een object/attribuut voor het laatst is gecontroleerd, is een belangrijk metagegeven dat de betrouwbaarheid voor de gebruiker maar ook voor andere bronhouders in hetzelfde gebied, verhoogt.

Vastleggen wanneer, hoe en door wie bewust een gegeven (object.attribuut) gecontroleerd is, is wenselijk. Maar de haalbaarheid hiervan is een duidelijk issue.
Je wilt deze gegevens over een uitgevoerde controle graag zo gedetailleerd mogelijk vastleggen maar de bijhoudingsoftware moet het dan wel op een adequate wijze kunnen ondersteunen, zodat bijvoorbeeld in één keer voor alle objecten in een gecontroleerd gebied deze metagegevens kunnen worden geregistreerd.

inOnderzoek is een waarde waar nu mee wordt gewerkt
naast inOnderzoek kan gedacht worden aan een extra waarde: InBewerking, Bijvoorbeeld wanneer de gemeente met een project van afbakenen van objecten of inventarisatie of inmeting bezig is.
mogelijke een extra waarde: inDiscussie (bij meningsverschil dan wel metingsverschil) tussen twee aangrenzende bronhouders, Wel binnen kaders. Iedere meting is anders, maar daarmee hoeft de oude of de meting van een andere bronhouder niet fout te zijn.

In het kader van "Regie op gegevens" kunnen mogelijk ook door betrokkenen aangedragen gegevens (suggesties voor aanpassingen) worden geregistreerd met een duidelijke aparte status als metagegeven.

Wellicht is het ook nuttig om apart vast te leggen dat een terugmelding is onderzocht en afgewezen. Het kan handig zijn (voor zowel een eventuele terugmelder als de bronhouder die moet onderzoeken) te weten dat er een melding is geweest, maar dat onderzoek heeft opgeleverd dat die melding onterecht was.

De Werkgroep stelt voor om nadrukkelijk de eis te formuleren, dat deze metagegevens per objecttype en per attribuuttype net zo toegankelijk zijn als de gegevensverzameling zelf en er virtueel één geheel mee vormen, zodat bijvoorbeeld de kwaliteit van de data soepel en geautomatiseerd zonder extra handelingen met de normkwaliteit kan worden vergeleken.

We willen het opstellen van een brondocument, uitsluitend als metagegeven voor de registratie, zo veel mogelijk vermijden. Brondocumenten die om andere reden bestaan, worden gebruikt als metagegeven. Verdere aspecten van bronverwijzing worden direct in de registratie als metagegeven opgeslagen zonder de formalisering als "brondocument".

Metagegevens hebben indien mogelijk een defaultwaarde, die vanuit de applicatie automatisch gevuld, zodat alleen door de bronhouder expliciet een gegeven hoeft te worden geregistreerd als wordt afgeweken van deze defaultwaarde

Voorstel meta-informatie per attribuut van een object:

• Bronverwijzing - verwijzing naar bron
• Autorisatie - vastleggen bronhouder ; vastleggen autorisatie gebruik
• Kwaliteit - beschrijven wijzen van inwinning ; beschrijving wijze (gebruikte bronnen) meest recente controle, moment controle en uitvoerder
• Status - inOnderzoek, InBewerking ; aantekenveld

[lvdbrink]

We hebben de werkgroep inhoud gevraagd om voorbeelden van use cases waarvoor metadata op attribuutniveau nodig is. Deze drie ontvangen:

1.

Iemand maakt bezwaar tegen de WOZ-waarde van een object in het buitengebied. Dit object is getaxeerd als agrarisch object. De belanghebbende geeft in zijn bezwaarschrift op 24 april 2020 aan dat dit niet klopt, want het verblijfsobject heeft uitsluitend als gebruiksdoel woondoeleinden.

De WOZ-medewerker bevraagt de BAG/SOR en vraagt naar het gebruiksdoel van dit object. Het antwoord is inderdaad woondoeleinden met als beginGeldigheid 1 maart 2020.
Deze WOZ-medewerker denkt dan dat hij de verwarring begrijpt en meldt dat de belanghebbende niet moet kijken naar het actuele gebruiksdoel, maar naar het gebruiksdoel op 1 januari 2020.
Nader onderzoek zou echter opleveren dat deze beginGeldigheid niet samenhangt met een wijziging van het gebruiksdoel, maar met een wijziging van de gebruiksoppervlakte per 1 maart 2020. Ook voor 1 maart 2020 was het gebruiksdoel al woondoeleinden.
Bij tijdlijnGeldigheid op objectniveau krijgt de WOZ-medewerker in dit geval de verwarrende beginGeldigheid 1 maart 2020 bij zijn vraag naar het gebruiksdoel. Bij tijdlijnGeldigheid op attribuutniveau had hij op de eerste vraag direct gezien woondoeleinden met bijvoorbeeld beginGeldigheid 1 oktober 2019 en had hij gelijk gezien dat deze belanghebbende gelijk heeft.

2.

Een gebouw in de SOR heeft de kenmerken geometrie (3D) en typering. Het pand is geregistreerd met ingangsdatumObject (beginGeldigheid alle kenmerken) 1 maart 2018. Per 1 oktober 2019 verandert de typering van het pand.
Bij tijdlijnGeldigheid op het objectniveau betekent dit dat ik bij tijdreizen door de geometrie bij de tijdsovergang 1 oktober 2019 voor dit object andere geometrie moet tonen. Immers ook de actuele geometrie heeft beginGeldigheid 1 oktober 2019. Voor dit gebouw bouw ik dan nieuwe geometrie op, terwijl deze uiteindelijk volledig identiek blijkt te zijn.
Wanneer ik de tijdlijnGeldigheid op attribuutniveau vastleg/bevraagbaar maak, had ik direct gezien dat voor de geometrie hier geen sprake is van wijzigingen in de geometrie want de actuele geometrie houdt dan beginGeldigheid 1 maart 2018.

3.

Een gemeente is verantwoordelijk voor het bijhouden van d gegevens van een gebouw. In de landelijke SOR heeft dit gebouw attributen geometrie, bouwjaar en type. In de eigen registratie legt de gemeente ook kwaliteit van het gebouw vast.
Wanneer sprake is van een tijdlijnGeldigheid op attribuutniveau dan kan de gemeente zowel een wijziging van de typering als een wijziging eenvoudig verwerken. Wanneer op 1 maart 2019 de typering een andere waarde krijgt, dan kan bij dit attribuut de beginGeldigheid 1 maart 2019 worden vastgelegd ((ook in de SOR), Wanneer op 1 oktober 2019 de indicatie voor de kwaliteit wijzigt kan dit ook met beginGeldigheid 1 oktober 2019 worden geregistreerd (komt niet in de landelijke SOR.
Bij tijdlijnGeldigheid op objectniveau leidt dit tot problemen. Wanneer de wijziging van de typering wordt geregistreerd krijgt het object een nieuwe beginGeldigheid van 1 maart 2019. Maar wanneer de wijziging van de kwaliteit wordt geregistreerd betekent dit dat in de gemeentelijke registratie het object een nieuwe beginGeldigheid krijgt van 1 oktober 2019, maar in de landelijke SOE moet de beginGeldigheid onveranderd blijven. Met een groot risico op fouten.

[lennartvanbergen]

Er is een belangrijk verschil tussen:

• het informatiemodel van een registratie / deel van een registratie - een logisch informatiemodel met historie erin
• het kunnen beantwoorden van een vraag 'wat was de waarde van een attribuut via een tijdreis' in een koppelvlak - wat je typisch tegen kan komen in een API specificatie

Er zijn immers zeker koppelvlakken denkbaar waarin je deze functionele vraag gewoon kan beantwoorden, ook al kent de registratie alleen historie op het niveau van voorkomens.

Tot nu toe is mijn ervaring ook dat vrijwel niemand historie op attribuut niveau vraagt. Ik krijg dus de indruk dat de 10% van de gevallen minder dan 10% is, en dat de voorziening die de functionele vraag beantwoord gewoon dat antwoord hoort te geven. Dus de waarde van het attribuut leveren, bij een tijdreis. Bij dit antwoord hoeft dan niet eens historie informatie te worden geleverd, dat wil de afnemer vermoedelijk ook niet, die wil vrijwel altijd gewoon de waarde op het tijdreis moment.

Deze behoefte lijkt dus meer te zijn: hoe modelleer je historie op attribuutniveau in hele specifieke use cases in concrete koppelvlakken, die ervoor kiezen om niet de vraag van de afnemer te beantwoorden, maar die ervoor kiezen om data leveren zodat de gebruiker dit zelf kan.

Mijn standpunt hierin: prima om daar een modellering voor te bedenken, maar dat hoort niet bij het informatiemodel van een informatiedomein en dus niet in de SOR.

[PalmJanssen]

Ik kwam deze historie van het van Gogh huis in Drenthe tegen. Moest aan de use case voor historie van gegevens denken: Geschiedenis van het Van Gogh Huis * Rond 1870 liet Mr J.A. Willinge Gratama, procureur te Assen, het logement/tapperij op de hoek van de Schooldijk bouwen. Wat dit logement zo bijzonder maakte was dat het uit twee verdiepingen bestond en ook nog over een balkon beschikte. * In 1876 werd het pand verkocht aan Hendrik Scholte, logementhouder tijdens het verblijf van Vincent van Gogh (1883) * In 1880 kreeg het pand tevens de bestemming veerhuis * In 1904 verkoopt Scholte het pand aan zijn schoonzoon Andries Mol. Het pand wordt voorzien van een witte pleisterlaag. * In 1926 koopt Kruimink het pand en deze heeft het pand zo’n 40 jaar in bezit. De heer Wams is korte tijd eigenaar en vanaf 1965 tot aan de afgifte van de sloopvergunning is de heer Valke eigenaar. * In 1997 is de Stichting Van Gogh & Drenthe opgericht en begonnen met de restauratieplannen * In 1998 werd het achterste deel gesloopt ten behoeve van een nieuw appartementencomplex * Maandag 27 maart 2000 beginnen de restauratiewerkzaamheden * Donderdag 30 maart stort een deel van het pand in. Er ontstond grote vertraging bij de bouw door het instorten van een deel van de oostelijke zijgevel. * De officiële opening van het Van Gogh Huis was 30 maart 2003. Extern ziet het gebouw er uit zoals in het begin van de 20e eeuw.

[lvdbrink]

Een ander voorbeeld is de eis dat verschillende bronhouders verschillende attributen van hetzelfde object beheren.

[lvdbrink]

Pano werkt een use case uit tot scenario.

@dkrijtenburg-GNM kun jij ons helpen aan nog meer use cases?

Alternatief is om fictieve use cases te bedenken. Het gaat erom dat we een paar voorbeeld cases hebben om uit te werken.

[lennartvanbergen]

Tot nu toe zie ik hele goede terechte wensen, die een informatievoorziening in moet en ook kan vullen, maar die niks (of maximaal heel weinig) met een informatiemodel te maken hebben.

[lvdbrink]

Via Dick:

We hebben de behoefte aan het vastleggen van de attribuutbeheerder vanuit de gedachte dat er één bronhouder is voor een object, maar dat de toegewezen beheerder per attribuut kan verschillen.

Daarnaast kan het zo zijn dat er afspraken gemaakt kunnen worden dat de attribuutbeheerder van de geometrie toestemming geeft dat de attribuutbeheerder van de geometrie van een naastliggend object ook zijn geometrie mag wijzigen.

Ten aanzien van meta-informatie is het ook de bronhouder zelf die de mogelijkheid moet hebben om bij attributen informatie te kunnen vastleggen. Denk bij oppervlakte aan zaken als “voor de laatste keer gemeten op”, “meetmethode” etc. Bij geometrie wil je juist graag informatie vastleggen over de metingen die er aan ten grondslag liggen (meetmethode) en de kwaliteit van de meting. Verder is verschillende malen aangegeven dat bronhouders graag de mogelijkheid hebben om “aantekeningen” kwijt te kunnen.

[lvdbrink]

In de laatste meeting hebben we verschillende uitwerkingen van de fictieve IM Boom casus besproken.

Dit is nu verder uitgewerkt op https://geonovum.github.io/disgeo-imsor/casus/imboom/

In deze uitwerking zijn een aantal aanpassingen gedaan aan de verschillende uitwerkingen om ze zo vergelijkbaar mogelijk te maken:

• Naamgevingen zoveel mogelijk gelijkgetrokken
• Modelstructuren die niet specifiek anders zijn in de uitwerkingen gelijkgetrokken.

[PalmJanssen]

Ik merk dat dit respec doc beperkingen heeft in google chrome, maar niet in FireFox. De (handige) tabs werken niet in chrome (bij mij).

[pmaria]

@PalmJanssen inderdaad. Dit merkte Niels ook al op. Als je een ctrl+F5 doet werkt het wel. Het ligt aan het stukje javascript wat ik snel in elkaar had gehackt om de tabjes werkend te krijgen. Ik moet nog even kijken hoe ik het netjes op kan lossen zodat het overal goed werkt.

[NielsHoffmann]

naar aanleiding van de discussie ben ik het MIM document nog nader gaan lezen en ik denk dat ik het eens ben met de suggestie van Paul dat je scenario B inderdaad van LD naar MIM terug kunt vertalen met behulp van GegevensgroepType. Daarmee komt het model volgens mij heel dicht tegen de andere twee modellen aan te liggen.

[pmaria]

@NielsHoffmann hoe zou een uitgewerkt instantiedata voorbeeld obv een modellering met GegevensgroepType eruit zien in bijv. Turtle volgens jou?

[NielsHoffmann]

poeh.. Volgens mij als je het MIM document leest vertaald een Gegevensgroeptype zich naar een Class die via een blank node aan het object gekoppeld is. In het 'metamodel' wordt dit dan extra getypeerd met een sh:nodekind 'GegevensgroepType', maar in een vertaling naar 'gewone' instantiedata verlies je die duiding en komt er een 'standaard' blanknode constructie uit? (die je met rdf* compacter zou kunnen maken) maar dat is dan toch iets zoals:

 data:Boom_1
  rdf:type disgeo-sor:Boom ;
  disgeo-sor:beginGeldigheid "1835-01-01"^^xsd:date ;
  disgeo-sor:beginGeldigheid "1998-11-09"^^xsd:date ;
  disgeo-sor:boom_aantalBladeren [
      rdf:type rdfs:Resource ;
      disgeo-gem:moment "2019-09-19"^^xsd:date ;
      disgeo-gem:onzekerheid 0.09 ;
      disgeo-gem:uitvoerder_telling waardenlijsten1:Opbladeren_BV ;
      disgeo-sor:boom_aantalBladeren 350000 ;
      prov:generatedAtTime "2019-09-19T11:39:00Z"^^xsd:dateTime ;
    ] ;
.

in het simpele model zou je dat 'plat' kunnen slaan naar:

data:Boom_1
  rdf:type disgeo-sor:Boom ;
  disgeo-sor:beginGeldigheid "1835-01-01"^^xsd:date ;
  disgeo-sor:beginGeldigheid "1998-11-09"^^xsd:date ;
  disgeo-sor:boom_aantalBladeren 350000 ;
.

[pmaria]

Dit is inderdaad de uitwerking die ik ook verwacht bij een GegevensgroepType. Daarmee is er in mijn optiek weinig tot geen verschil met uitwerking B. Misschien is deze er wel (subtiel) op MIM niveau, maar zodra je dit vertaalt naar bijv. linked data, of software objecten, raak je dat kwijt.

Je geeft aan dat je de rdfs:Resource kunt platslaan. Hoe kan ik zien dat dat kan? Of bedoel je dat we twee modellen nodig hebben? Een met metadata op gegevens en een zonder ("het simpele model").

[lennartvanbergen]

Ter info.

Een gegevensgroep in MIM is een groepje van kenmerken (attributen, relaties) van een object.

Een object heeft bv. 5 kenmerken en kenmerk 3, 4 en 5 horen bij elkaar. Daarom heb je ze gegroepeerd . Meer is het niet. Zoals adresgegevens, of geboortegegevens.

In feite zijn alle kenmerken in de groep geen kenmerken van de groep (class), het zijn en blijven kenmerken van het object. Ze zijn alleen gemodelleerd in een groepje met een naam. Soms is dat enkel en alleen om de groep als geheel een kardinaliteit * te kunnen geven (zonder semantiek). Soms is dat omdat het groepje semantisch betekenis heeft. Dit groepje mag kan je dan aanvullend ook semantiek geven, dit is overigens ook de bedoeling is als je er als zodanig over praat.

Belangrijk om te constateren is dus dat de gegevensgroep nooit zelf kan bestaan, de gegevensgroep hoort altijd bij een objecttype. Een modelleur kan dus ook best los, zonder groepen te gebruiken, modelleren. Dat is dan prima, het object verliest daarmee geen attributen en relaties, en dus geen data.

Dit zal de reden zijn dat het een blank node is geworden.

[NielsHoffmann]

@pmaria @lennartvanbergen-kadaster Ik denk dat we inderdaad misschien wel toe moeten naar een 'generiek' logisch model wat 'alle' complexiteit bevat (omdat je ander niet kan generaliseren) en een of meerdere 'aspect' modellen die de typische use cases afdekken. Anders blijf je 'hinken op twee gedachten' zoals in A dan toch een beetje het geval is. Daarmee zou je dan ook expliciet kunnen maken hoe je van complex => simpel gaat. Anders zou je daar weer allerlei 'custom logica' voor moeten bedenken en uitleggen hoe men dat moet interpreteren...

[pmaria]

In RDF is een ding die geduid wordt met een blank node niet anders dan een ding die geduid wordt met een URI. Het verschil tussen de twee is alleen maar dat je naar de ene (blank node) niet kunt verwijzen buiten de context van een document en de andere wel. Op informatiemodelniveau kun je niet zien of iets wel of niet een blank node krijgt.

[pmaria]

@pmaria @lennartvanbergen-kadaster Ik denk dat we inderdaad misschien wel toe moeten naar een 'generiek' logisch model wat 'alle' complexiteit bevat (omdat je ander niet kan generaliseren) en een of meerdere 'aspect' modellen die de typische use cases afdekken. Anders blijf je 'hinken op twee gedachten' zoals in A dan toch een beetje het geval is. Daarmee zou je dan ook expliciet kunnen maken hoe je van complex => simpel gaat. Anders zou je daar weer allerlei 'custom logica' voor moeten bedenken en uitleggen hoe men dat moet interpreteren...

Ik denk ook dat dit nodig is. Maar ik zou dit willen bereiken zonder het simpele / conceptuele model aan te passen. Het add-on principe wat Lennart ook noemt vind ik cruciaal voor interoperabiliteit over datasets heen.

[pmaria]

De uitleg van @lennartvanbergen-kadaster over gegevensgroeptype nog eens goed lezend en de beschrijving in https://docs.geostandaarden.nl/mim/mim/#gegevensgroep ook weer goed lezend, denk ik niet dat een gegevensgroep de uitkomst is.

In feite zijn alle kenmerken in de groep geen kenmerken van de groep (class), het zijn en blijven kenmerken van het object.

attribuutsoorten van het gegevensgroeptype zijn semantisch gezien eigenschappen van het objecttype. Echter, vanwege samenhangend gedrag (ze horen semantisch bij elkaar, ze wijzigen bijvoorbeeld gelijktijdig e.d.) zijn deze ondergebracht in een apart modelelement.

Als de eigenschappen in een gegevengsroeptype nog steeds eigenschappen van het object zijn dan past metadata over gegevens over dat object daar niet in.

Daarnaast is dan de vertaling naar LD in https://docs.geostandaarden.nl/mim/mim/#transformatie-gegevensgroeptype dan in mijn optiek toch niet correct. Er zou in dat geval geen owl:Class gemaakt moeten worden. Hoogstens een aparte sh:NodeShape.

[NielsHoffmann]

Maar wat is dan nu de gangbare manier om dat in MIM uit te drukken? Het is op zich geen nieuwe requirement, dus ik zou verwachten dat er dan al wel een constructie voor bestaat in MIM?

[pmaria]

Die is er nog niet. Vandaar ook dit issue / deze discussie. In RDF heb je RDF reification en straks RDF*. Property Graphs kunnen dit van nature al. In een relationeel / object georienteerd paradigma zou je het verschillende manieren kunnen oplossen.
De vraag is volgens mij. Hoe kunnen we dit in MIM introduceren zodat het past op deze paradigma's en rekening houdt met de besproken criteria.