IMBOR, LinkedData en een stukje ‘Sharing is caring’

07-08-2020
Hoi! Hierbij een blogpost over IMBOR en de LinkedData versie ervan. Voor mezelf had ik wat achtergrond en voorbeelden op een rij gezet, en onder het motto ‘sharing is caring’ sturen we hem de wereld in! Wellicht dat er wat onbekende terminologie gebruikt wordt. Voor het begrip daarvan verwijs ik graag naar een aantal andere blogposts: … een dag niet geblogd is een dag niet geleefd zullen we maar zeggen!
 
IMBOR = kennis. Er is met een grote community kennis gemaakt. Die staat inmiddels aardig vast (maar wordt uiteraard doorontwikkeld) en dat noem ik de ‘content’. Daarnaast is de Access database opgezet, dat is wat mij betreft het distributiemechanisme. Maar om het iets ingewikkelder te maken wordt de content ook in die Acces database beheerd. Dus is het tevens de beheeromgeving. IMBOR wordt beheert in die beheeromgeving en gedistribueerd met verschillende distributiemechanismen (momenteel de Access database, IMBOR-LD en een viewer in de CROW Kennisbank).
 
Nu werd er vanuit het BIM Pro programma een OTL gewenst (content) in LinkedData (distributiemechanisme). In de loop van de tijd is duidelijk geworden dat de omzetting van IMBOR content naar ‘een OTL’, meer neer kwam op maken van een LinkedData versie van IMBOR, volgens de nieuwste versie van de NTA8035. Die spreekwoordelijke handschoen hebben we opgepakt. Er is dus momenteel een LinkedData versie van de IMBOR content (IMBOR-LD), maarrrrr met een aantal shortcuts in de vorm van ‘design descions’. We hebben dus een aantal beslissingen genomen bij de vertaling van IMBOR content naar LinkedData (met de NTA8035 als topmodel), die herzien kunnen worden in volgende versies. Die beslissingen zijn bijna allemaal genomen omdat wij niets aan de content wilden veranderen. Wij zijn namelijk van mening dat de IMBOR community daar over gaat en wij niet. We willen geen verschil tussen de content in de diverse distributiemechanismen krijgen en dat daarmee eigen content ontstaat.
 
Om de zojuist genoemde beslissingen die we hebben genomen toe te lichten geef ik een aantal voorbeelden. Ik doe dit in de vorm van de optimalisaties die we kunnen, en wellicht in volgende versies dus ook, gaan doen!
 
Er zijn twee soorten optimalisaties die we kunnen doen:
  1. Optimalisatie aan de content van IMBOR in overleg met community, die worden geconstateerd bij de omzetting naar LinkedData;
  2. Optimalisatie in de LinkedData versie op basis van design decisions die genomen zijn.
 
Allereerst de optimalisaties aan de content van IMBOR.
 
 
 

Punt 1: momenteel kunnen bijvoorbeeld de eigenschap ‘Bedienaar’ en ‘Bedieningstijden’ worden ingevuld bij ‘Brug’, terwijl dit logischerwijs alleen maar bij een beweegbare brug zou moeten. 
Het zit zo in IMBOR omdat alles op het niveau van ObjectType wordt vastgelegd. Maar omdat IMBOR-LD geen onderscheidt maakt in objecten, is ‘Vaste brug’ dus een klasse die in het beheersysteem aangemaakt kan worden. En hier kunnen dus nu ook die twee eigenschappen op vastgelegd worden. Dit wil je niet persé.
 
 
 
 

Punt 2: er liggen in IMBOR relaties tussen objecten. Er is echter niet meteen expliciet duidelijk wat de semantiek (betekenis) hiervan is. Momenteel is daarom de beslissing genomen om alles te interpreteren als ‘hasPart’. Dit is niet correct. Deze zouden we dus in detail stuk voor stuk moeten kijken om daar een betere relatie voor te vinden. 
Een samenhangend punt is dat er in IMBOR gebruik gemaakt wordt van zogenaamde “GUID” verwijzingen. Dit betekent dat er bij een object een eigenschap is, waar het nummer van een ander object moet worden ingevuld. Dit is dus impliciet een relatie tussen twee objecten. Die zou je dan eigenlijk ook als echte relatie willen vastleggen.
 
 
 

 
 
Dan punt van aandacht nummer 3: In IMBOR komen heel veel dubbele waarden voor. Dit komt omdat het nu in een traditionele tabellen vorm beheerd wordt. Zodoende komt er bijvoorbeeld  heleboel keer de keuzewaarde ‘Ja’ voor. Dit is nu ook in IMBOR-LD het geval. LinkedData gaat uit van verwijzen, dus ‘eenmalig opslaan meervoudig gebruiken’. Je definieert één keer een ‘Ja’ en verwijst er dan altijd naar. Als dit soort optimalisaties doorgevoerd kunnen worden scheelt dit heel veel in beheer, opslag, maar vooral expliciteit naar de computer toe.
 
 
 

 
En last, but surely not least: door de IMBOR content in LD te zetten kun je je beter laten ondersteunen door een computer om consistentie te checken. In IMBOR-LD geven we SHACL bestanden mee om de inhoud te valideren. Dit is in de Access database niet zo en een stuk lastiger te implementeren. Maar als IMBOR-LD dus volwassener is en we die checks hebben gedefinieerd kun je deze teruggeven aan beheerders. Dit is zorgt voor meer optimalisatie en minder verwarring bij de gebruikers.
 
Dan vervolgens door naar de optimalisaties aan de LinkedData versie
 
Even tussendoor: Met IMBOR-LD doen we pilots. Onder andere met de Gemeente Amsterdam. Door de samenwerking met Amsterdam hebben we al review commentaar gekregen die we meteen konden verwerken en daardoor een meer bruikbaar product konden maken. Zo hadden wij bijvoorbeeld niet voorzien dat een partij die IMBOR consumeert graag zou willen dat ze wel de fysieke objecten en de eigenschappen willen overnemen, maar niet de waardenlijsten achter die eigenschappen. Door dat commentaar hebben we nu IMBOR-LD gesplitst in meerdere ontologieën. Een mooi voorbeeld van het z.s.m. testen met producten.
 
 
 
 

Optimalisatie LinkedData versie, punt 1: momenteel is alles een subklasse van NTA8035:PhysicalObject in IMBOR-LD, maar in IMBOR worden ook Gebruiksfuncties (b.v. Cultuurlijk groen, Erosiebeperking)  en Functionele gebieden onderscheiden. Deze worden ook onderscheiden ook in de NTA8035. Om meer naar een OTL vorm te gaan, moet je explicieter zijn (zodat de computer je beter begrijpt). Deze optimalisatie moet je dus willen. 
 
Ook zo’n ding: IMBOR is een overkoepelend informatiemodel, dit betekent dat er concepten in zitten die geleend zijn uit IMGEO, GWSW, NEN3610, SUFKOR, BGT, etc. Deze zijn er nu uitgelaten omdat we nu naar zuivere IMBOR gekeken hebben. Deze zitten er echter niet voor niets in en moeten een plek krijgen in de LinkedData versie. Objecten als Plaatsbepalingspunt, Waterinrichtingselement en Weginrichtingselement zitten er nu niet in en zouden op een juiste wijze moeten worden gemodelleerd om de LD versie van IMBOR 1-op-1 te krijgen met de Access versie qua conent. Ook omdat deze misschien wel gebruikt worden in de praktijk (voorbeeld: Beeldmeetlatten (KOR2018 – IMBOR2020)
 
Dan het grootste punt. Het voordeel van LinkedData is het ‘Linked’ stuk. Zodra IMBOR-LD gelinkt is heeft het ook echt meerwaarde. Momenteel staat het nog op zichzelf, maar als we het publiceren als LD dan kunnen we ernaar refereren. Een logische eerste bestemming zou de koppeling aan bijvoorbeeld CB-NL zijn. Op deze manier kunnen er meer ‘is hetzelfde als’ conclusies getrokken worden. Bijvoorbeeld als we ‘Beweegbare brug’ uit IMBOR linken aan ‘Beweegbare brug’ in CB-nl,
 
 

kan er geconcludeerd worden dat het ook hetzelfde is als NEN2767 Bruggen Beweegbaar: 
 
Nou, best wat toch? Ik realiseer me dat bovenstaande incompleet is en soms context/perspectief afhankelijk. Maar toch wilde ik het even delen. Het illustreert voor mij ook de transitie in denken waar we momenteel inzitten met z’n allen. We gaan van documentbased, naar data based en tegelijkertijd ontdekken we allerlei beren op de weg. De enige goede manier om hier naar mijn bescheiden mening mee om te gaan is: 1) documenteren, schrijf je beslissingen op want alleen dan kun je er op terugkomen. 2) transparant, ontwikkel het met elkaar en publiceer er open over. 3) Luister naar elkaars ideeën en wees niet bang om te erkennen dat je het soms niet weet. Dit is onbekend terrein en pas achteraf kunnen we zien of we de juiste stappen hebben genomen.
 
En met deze wijze woorden laat ik jullie in totale verwarring achter. Liefs Gandalf the Grey.
 

Reacties

Er zijn nog geen reacties op dit bericht
Abonneer
 Security code
Scroll naar boven