De Verschijningsvormenkwestie

[wjtmollema]

De verschijningsvormen van IMBOR-objecttypes (type, type gedetailleerd en type extra gedetailleerd) zijn een waardevol onderdeel van IMBOR. Exclusief het verkeersbord zijn er hier nu zo'n 2400 van. Ze verschaffen een gedetailleerde taxonomie van de objecten in de openbare ruimte en helpen gebruikers als zodanig hun objecten met de juiste attributenprofielen (objecttypes) te modelleren in beheersystemen.

Een discussie die al langere tijd wordt gevoerd, is (a) of die verschijningsvormen niet ook als subklassen geïnstantieerd mogen worden, bijvoorbeeld Duikerbrug apart van een Liggerbrug (beiden types van Vaste brug). Hetzelfde geldt voor (b) bepaalde superklassen: Het instantiëren van Viaduct, Vaste brug en Beweegbare brug als hun gemeenschappelijke superklasse Overbrugging. Op dit moment kunnen alleen objecttypes geïnstantieerd worden, omdat dit 'concrete' klassen zijn, terwijl klassen zoals Overbrugging gelabeld zijn met 'abstract'.

De kwesties die uitgezocht moeten worden zijn de volgende:

1. Kan de registratie van type, type gedetailleerd en type extra gedetailleerd niet makkelijker door er 1 attribuut voor te gebruiken (verschijningsvorm), waarbij de taxonomische kennis die IMBOR nu bevat wel bewaard blijft d.m.v. de constructie BovenliggendeWaarde die nu ook binnen de Enumeratietypen wordt gebruikt? Hierbij is het dan wel belangrijk dat de waarden die nu op meerdere niveaus staan (type, type gedetailleerd en type extra gedetailleerd) naast elkaar gebruikt kunnen worden in 1 attribuut. Neem het voorbeeld van een Asfaltverharding. Van sommige objecten weet je misschien veel, bijvoorbeeld dat het Penetratieasfalt (type gedetailleerd) is, terwijl je van andere objecten slechts weet dat het een Dichte deklaag (type) betreft.
2. Betreffende (b) zou aangetoond moeten worden dat de aggregatie tot een superklasse niet weer tot het toekennen van attributen aan objecten zou leiden die eigenlijk onzinnig zijn (denk aan de drukklasse bij Leiding: niet elke subklasse van Leiding heeft er een. IMBOR 2022 heeft op basis van het attributenprofiel het objecttypeniveau bepaald en het zou haaks staan op dat uitgangspunt om (b) toe te staan zonder daar een goede oplossing voor te hebben. In termen van relationele databases wordt het een grotere vergaarbak.
3. Betreffende (a) is het probleem van (b) niet van toepassing, omdat er vanaf het objecttypeniveau geen attributen meer aan het attributenprofiel worden toegevoegd. Alleen is het wel zo dat mits men voor (a) kiest, een optie zoals die van (1) hierboven niet gewenst is en vice versa. Er dient voor een duidelijke oplossing gekozen te worden, niet twee mogelijkheden om hetzelfde te doen. Daarnaast moeten ook bevragingen van instanties in data onderscheiden worden. Of 'subclassing' nou wel of niet toegestaan wordt, bevragen op de verschijningsvorm is nu al mogelijk. De waarde van de optie om verschijningsvormen als subklassen te behandelen moet nog beter worden onderbouwd voordat een dergelijke ingrijpende wijziging verantwoord is.

Voor optie (2) hierboven zou het onderscheid tussen wat 'concreet' en wat 'abstract' is moeten worden opgeheven of slechts tot informatief gegeven gemaakt worden. Voor optie (3) zou de collectie 'objecttype' verwijderd moeten worden en de objecttypes en domeinwaarden van type, type gedetailleerd en type extra gedetailleerd aan de collectie Klasse toegevoegd moete worden.

[RiX012]

Kwestie 1 heeft betrekking op #1202. De optie voorgesteld in: #1202 (comment) moet dan ook worden meegenomen. #1202 vervalt zodoende.

Voorstel voor poldermodel:

We laten de attributen type, typeGedetailleerd en typeExtraGedetailleerd vervallen. En introduceren één nieuw attribuut: verschijningsvorm.

Tegelijkertijd vereenvoudigen we dan ook de waardenlijsten. De getrapte structuur die nu in de waardelijsten van type, typeGedetailleerd en typeExtraGedetailleerd wordt vereenvoudigd en komt daar praktisch gezien mee te vervallen. Onder het attribuut verschijningsvorm komt dus maar één laag met enumeraties.

Hiermee wordt deze passage ook herzien (en vereenvoudigt), maar blijft deze modelleerregel nog steeds gelden.

Wanneer we deze gaan doorvoeren zullen er een aantal specifieke gevallen uit komen die apart bekeken (en wellicht apart gemodelleerd) moeten worden. Dit zal bijvoorbeeld het geval zijn voor alle 'bord typen'. Het streven is om deze als externe waardelijst te beheren.

[RiX012]

Doel van dit issue moet zijn om duidelijk te maken hoe we omgaan met type, typeGedetailleerd en typeExtraGedetailleerd.

Voor nu lijkt de oplossing om deze samen te voegen tot één attribuut. Per attribuut zal dan gekeken moeten worden of er meer objecttypen moeten komen, of de lijst vereenvoudigd zou kunnen worden, of nog iets anders. Dit is maatwerk. @JochemMollema heeft een eerste verkenning gedaan.

[wjtmollema]

De door het IMBOR-team voorgestelde verwerkingswijze is als volgt:

1. type wijzigt in verschijningsvorm
2. Alle …Type enumeratietypes wijzigen naar …Verschijningsvorm
3. Voor Verkeersbord en Scheepvaartbord stel ik een uitzonderingssituatie voor: (a) bordcode als attribuut om type gedetailleerd te vervangen (Referentie); (b) VerkeersbordType en ScheepvaartbordType worden VerkeersbordVerschijningsvorm
4. Alle resterende gevallen van type gedetailleerd en type extra gedetailleerd worden handmatig weggewerkt
5. In ‘BovenliggendeWaarde’ in imborKern_EnumeratiesDomeinwaarden wordt de 'tussenlaag' van de verschijningsvormen opgenomen, maar deze wordt niet gebruikt in de enumeraties zelf.

[wjtmollema]

De wijziging is uitgevoerd.