Levensfasen - uitwerking 6 - Representatie-in-InformatieObject

[RiX012]

Ik zou graag nog een alternatief willen aandragen, al is het alleen maar om deze uit te sluiten van mijn redenering.

Als ik even 'atomair' redeneer kom je naar mijn mening bijvoorbeeld op de volgende fasen.
Waarbij het eerste niveau de AM-fases zijn die doorgaans onderscheiden worden (ISO55000) en het twee niveau de Enumeraties uit EMSOR(?) zijn.

• Ontwerp / Plan
  • Ontwerp
  • Verbouw gepland
  • Sloop gepland
• Bouw
  • Bouw gepland
  • In aanbouw
• Operatie / Onderhoud
  • Bestaand
• Sloop
  • Gesloopt
  • Afgevoerd

Wat mij betreft kan een object gepresenteerd worden in de verschillende levensfasen en kan het daarbinnen verschillende statussen hebben. Hiermee vind ik het logisch om het FysiekObject (NEN2660 def) te onderscheiden van het InformatieObject (NEN2660 def).

Hiermee zou ik dus een alternatief zien waarin je de relatie isBeschrevenDoor (NEN2660 def) o.i.d. gebruikt om een FysiekObject te representeren door een InformatieObject. De InformatieObjecten in deze zouden dan de specialisaties Ontwerp/Plan, Bouw, Operatie/Onderhoud, Sloop o.i.d. zijn. Inclusief het attribuut Status met de waarden zoals hierboven.

De InformatieObjecten laat je dan elkaar 'opvolgen'. Expliciet door een relatie, impliciet door geldigheid te registreren of beiden. Ik ben niet zo zeker over de semantiek van de relatie 'opvolgen'. maar volgens mij zou het er ongeveer zo uit kunnen zien.

Beetje grof gemodelleerd nog, maar hoop you-catch-my-drift

[RiX012]

Ik ben nu de modeleer regels aan het doorlezen en ik zie dat ik misschien geo-informatieobject of 'geometrische representaties' had moeten gebruiken? ... niet helemaal zeker, daarom even aan de NEN2660 def gerefereerd.

[pmaria]

De splitsing tussen informatieobject om het plan te duiden lijkt op alternatief a bij #33. Het idee daar is ook om als eigenschap van het informatieobject aan te duiden of het wel of niet om geplande gegevens gaat.

Het lastige van deze uitwerking vind ik dat een informatieobject eigenschappen krijgt die normaal gesproken niet bij een informatieobject horen: een object-levensloop-status en een geometrie. Daarom zou dit mijn voorkeur niet hebben.

[RiX012]

Het lijkt er op, maar volgens mij bedoel ik niet hetzelfde. In #33 gaat het echt om een plan. Wat ik hier probeer te zeggen is dat ik het daadwerkelijke 'gerepresenteerde' wil scheiden van de 'representatie'. Misschien is InformatieObject dan niet de juiste keuze, maar moet het dan inderdaad GeoInformatieObject of toch fysiek object zijn. Maar de essentie zit hem in dat het gerepresenteerde uniek te identificeren blijft en dat de representaties de mutaties en daarmee levensloop ondergaan.

[pmaria]

Ah ok, zo had ik het idd niet geïnterpreteerd.

Is het dan niet vergelijkbaar met GeplandeVerarding in #29? Ofwel, zou je in jouw plaat InformatieObject kunnen vervangen met GeplandFysiekObject (en de bijbehorende subtypes ook in die trant), en de relatie isBeschrevenDoor met isGerepresenteerdDoor?

Alleen, dan moet je nog wat met opgevolgdDoor. Dat is een provenance relatie en lijkt wel meer bij een informatieobject te horen. De combinatie van beide heb ik geprobeerd in #31 alt b uit te werken. Daar zou je m.i. wel op het niveau van het VerhardingsPlan dit soort provenance relaties kunnen uitdrukken.

[RiX012]

Is het dan niet vergelijkbaar met GeplandeVerarding in #29? Ofwel, zou je in jouw plaat InformatieObject kunnen vervangen met GeplandFysiekObject (en de bijbehorende subtypes ook in die trant), en de relatie isBeschrevenDoor met isGerepresenteerdDoor?

Zou kunnen, maar het grootste onderscheidt zit in waar je de geometrie vastlegt. Dit doe je imo alleen op de representatie. Daarnaast is uiteraard de semantiek van GeplandFysiekObject niet gelijk aan InformatieObject.

[RiX012]

Alleen, dan moet je nog wat met opgevolgdDoor. Dat is een provenance relatie en lijkt wel meer bij een informatieobject te horen. De combinatie van beide heb ik geprobeerd in #31 alt b uit te werken. Daar zou je m.i. wel op het niveau van het VerhardingsPlan dit soort provenance relaties kunnen uitdrukken.

Ja zoiets inderdaad. Maar zie wederom mijn interpretatie van 'representatie' t.o.v. FysiekObject & 'Plan'

[RuudKathmann]

Ons is niet duidelijk waarom ik niet de genoemde statussen en de geometrie allemaal aan het fysieke object zou kunnen hangen.
Dat maakt het model veel eenvoudiger en volgens ons meer in lijn met hetgeen nu beschreven is in het conceptueel model.

[RiX012]

Omdat de geometrie maar een representatie van het object is. Het is niet het object. Op deze manier zie je de registratie van geometrie (en de bijbehorende status daarvan) los van de identificatie van het object. Dit is mijns inziens 'zuiverder' of 'meer atomair' gemodelleerd.

Dat maakt het model veel eenvoudiger

Dat is zeker zo, maar dus minder flexibel en misschien niet geschikt voor elke usecase.

[lennartvanbergen]

Ik begrijp dat het dan 3 objecten worden (of als geometrie apart, nog meer). Dat lijkt mij niet handig voor een logisch model, en ook niet voor een uitlevermodel.

[RiX012]

k begrijp dat het dan 3 objecten worden (of als geometrie apart, nog meer).

Dat is correct.

Dat lijkt mij niet handig voor een logisch model, en ook niet voor een uitlevermodel.

Daar heb ik minder verstand van denk ik. Maar ik vind het juist heel logisch vanuit 'zuiver modelleren' gedacht. Mijn uitgangspunt was: zo zuiver mogelijk modelleren en vanuit daar kan je bij een implementatie model wel 'opbossen'. Dan weet je in ieder geval zeker dat je alle aspecten behandeld hebt.

[lennartvanbergen]

Kan 2x765 in de naam van klasse, en de naam van het objecttype nog aangescherpt worden? Alsmede, wat is de identificatie van de 3 objecten? Dit leidt me nog een beetje af.

[lvdbrink]

Aanvullingen uit overleg 15 april:

• De gedachtegang bij deze uitwerking is om het object van zijn representatie te scheiden, omdat het object buiten nog niet is veranderd, je wil alleen een nieuwe representatie alvast weergeven. Het duurt even voordat het de groep duidelijk wordt, ook deze is wat lastig uit te leggen. Het is semantisch zuiverder, meer atomair gemodelleerd, maar niet gebruikelijk om dit zo te modelleren.
• Het fysiek object heeft geen status (dit is een foutje in het diagram), status zit bij het representatie object.
• Paul: de vraag is of het wat oplost
• Michel vindt het wel een goed idee, wel afstemmen met NEN 2660
• Rik: essentie is het onderscheid tussen operatie/onderhoud representaties en ontwerp representaties.
• Paul: deze scheiding zou wellicht wel op veel plekken impact hebben
• Pano: nadeel: moeilijker te bevragen; er zit weinig informatie bij het object zelf, de Verharding, je moet dus altijd door gaan zoeken bij de gerelateerde objecten.
• Paul: iets te veel meta
• Niels: vindt dat juist fijn
• Michel: Misschien is het geen 'informatieobject' of 'representatie' maar NEN 2660 Toestand.
• Rik: legt zich erbij neer dat deze uitwerking niet favoriet is.

[RiX012]

Kan 2x765 in de naam van klasse, en de naam van het objecttype nog aangescherpt worden? Alsmede, wat is de identificatie van de 3 objecten? Dit leidt me nog een beetje af.

Zeker. Aangepast in onderstaande nieuwe diagram. Ik stel dat de relaties zorgen voor een vastlegging van de juiste objecten aan elkaar. De IDs zeggen dus niet zoveel. Alleen 'Verharding' heeft een identificatie ('123') want dat is het nummer dat gebruikt wordt in een basisregistratie. Voor de rest zijn het 'random' nummers die alleen een GUID representeren en niet een identificatienummer.

Het fysiek object heeft geen status (dit is een foutje in het diagram), status zit bij het representatie object.

Aangepast in onderstaand nieuwe diagram.

Het is semantisch zuiverder, meer atomair gemodelleerd, maar niet gebruikelijk om dit zo te modelleren.

Dit ligt denk ik aan de context. In de 'geo' wereld is het wellicht niet gebruikelijk. Maar de semantic web (of "OTL") wereld zie ik dit als heel gebruikelijk.

Michel vindt het wel een goed idee, wel afstemmen met NEN 2660

Dat heb ik nog niet gedaan. Wanneer we deze uitwerking verder willen verkennen is dit essentieel inderdaad.

Michel: Misschien is het geen 'informatieobject' of 'representatie' maar NEN 2660 Toestand.

Dat is veel beter inderdaad. Aangepast in onderstaand diagram.