Vaikka eri osapuolet työstävät samaa rakennuksen suunnitelmaa, on kaikilla osapuolilla asiaan oma näkökulmansa. Tämä on luontevaa, koska kaikki tuovat kokonaisuuteen oman erityisen panoksensa. Tietomallipohjaisessa tiedonsiirrossa tämä tosiasia on vain ymmärretty huonosti ja yleinen trendi on yrittää ratkaista tiedonsiirron ongelmia pakottamalla kaikki osapuolet näkemään ja jäsentämään asiat samalla tavalla. Parempi ratkaisu löytyy datakubismista, jossa siirrettävä tieto nähdään erillisinä tiedon murusina, joita vastaanottava osapuoli hyödyntää tiedon jäsentämiseen omasta näkökulmastaan. Aivan kuten kubistiset maalarit aikanaan ’räjäyttivät’ maalaustensa aiheet ja kokosivat ne uudelleen toisesta näkökulmasta, datakubismissa tietomallien tietosisältö räjäytetään ja kootaan uudelleen. Tämä saattaa kuulostaa erikoiselta, mutta se on ratkaisumalli, joka hyödyntää täysimääräisesti tietotekniikan sisintä olemusta ilman historian painolastia.
Tietokoneet ovat erittäin tehokkaita ja toimintavarmoja hyödyntäessään logiikkaa tiedonkäsittelyssä. Perusohjelmointi noudattaa seuraavaa kaavaa: jos tämä ehto toteutuu, tee tämä toimenpide. Esimerkiksi objekti, joka esittää seinää ja on lisäksi osa rakennuksen ulkovaippaa, on ulkoseinä. IF seinä AND osa ulkovaippaa THEN ulkoseinä. Tässä yksinkertaisessa esimerkissä kahdesta tiedon murusesta päätellään säännön avulla yksi näkökulma asiaan. Mutta tämä valittu näkökulma ei suinkaan ole universaali. Energia-analyysin näkökulmasta ’läpinäkyvä seinä’ on ikkuna ja määrälaskijalle ulkoseinä ei ole riittävän tarkka jaottelu, vaan tarvitaan rakennetyyppi. Kun tiedonsiirrossa siirretään tarkkaan valittuja tiedon murusia, ilman etukäteen määrättyä näkökulmaa, pystyvät tietokoneet tehokkaasti muodostamaan niistä vastaanottajan tarvitseman näkökulman.
Nykyinen tietomalleihin perustuva tiedonsiirto hyödyntää vahvasti hierarkioita, kuten luokittelujärjestelmiä ja IFC objektiluokkia. Tässä on se ongelma, että hierarkiaa ei pysty muodostamaan, ilman että valitsee näkökulman. Esimerkiksi itsestään selvältä tuntuva eläinten luokittelu kaloihin, matelijoihin, nisäkkäisiin jne. toimii vain yhdestä, eläinten fyysisten ominaisuuksien näkökulmasta. Mahdollisia hierarkioita on kuitenkin useita, kuten jako päätasolla villi-, koti- ja tuotantoeläimiin. Genetiikan näkökulmasta voitaisiin tehdä vielä kokonaan toisenlaisia jakoja. Lisäksi kaikissa hierarkioissa se heikkous, että todellisuudessa on aina asioita, joita voitaisiin luokitella eri tavalla saman hierarkian sisällä. Vesinokkaeläin lienee tästä tunnetuin esimerkki.
Yksi objektiorientoituneen ohjelmoinnin perusesimerkeistä on luoda pääluokka ’eläin’, jolla on metodi ’päästä ääni’. Tällä luokalla on kaksi alaluokkaa; ’kissa’ ja ’koira’. Kissan toteutus ’päästä ääni’ metodille on ’miau’ ja koiran ’hau’. Tämä on kuitenkin vanhanaikainen lähestymistapa, ja rajapinnat ovat parempi ratkaisu. Kaikki eläimet, kuten kalat, eivät päästä ääniä, jolloin vain ääntä pitävät eläinluokat toteuttavat ’ääntelevä’ rajapinnan, kukin omalla tavallaan. Näin kissa-, koira- ja kalaobjektit voivat olla ongelmitta, ilman hierarkiaa, samalla tasolla ja toteuttaa eri rajapintoja tarpeen mukaan. Rajapinta-ajatus vapauttaa siis meidät kankeista hierakioista ja mahdollistaa todellisuuden tarkemman ja joustavamman kuvaamisen. Rakennuksessa monen eri rakennusosan materiaali voi olla betoni, jolloin betonista tehdyt rakennusosat toteuttavat ’tehty betonista’ rajapinnan, joka määrittelee, että tämän rajapinnan toteuttavilla objekteilla pitää olla ominaisuutena betoniluokka. Jos sama yritettäisiin kuvata hierarkkisesti periyttämällä, pitäisi betonimateriaali nostaa hierarkian ylätasolle ja sen alle esim. rakennusosan tyyppi, kuten betoniseinä, betonipilari tai betonipalkki. Entä jos rakennusosalla on useampi materiaali, samalla tavalla kuin vesinokkaeläimellä on sekä nisäkkään että matelijan ominaisuuksia? On paljon parempi pitää materiaali ja rakennusosan tyyppi tiedonsiirrossa erillisinä tiedon murusina, joiden avulla voidaan muodostaa vastaanottavassa päässä juuri sellainen hierarkia tai muu tiedon jäsennys kuin tarvitaan. Tietokoneet suoriutuvat tästä tehtävästä mainiosti.
Luokittelujärjestelmien, kuten Talo2000, käyttö tiedonsiirrossa rikkoo räikeästi tätä periaatetta. Se esimerkiksi jakaa rakennuksen ulkoseinät, väliseinät, väestönsuojan seinät ja piharakennusten seinät eri nippuihin. On parempi siirtää erikseen tieto siitä, mitä objekti esittää ja tieto objektin sijainnista tai roolista. Luokittelujärjestelmän sijaan pitää siis siirtää tiedon murusia, joiden perusteella objektit voidaan luokitella. Tämä paljastaa myös, jos luokittelu vaatii tietoa, jota mallin tekijä ei tuota. Silloin tarvittava tiedon murunen puuttuu ja mallia pitää rikastaa vastaanottavassa päässä, jotta se saadaan luokiteltua halutulla tavalla. Jos tässä tapauksessa vaadittaisiin luokittelun siirtämistä, menisi luokittelu kuitenkin väärin, mikä korruptoisi myös mallissa olevan oikean tiedon.
IFC mallin objektiluokat taas perustuvat objektiorientoituneen ohjelmoinnin ajatukseen hierarkkisesta periytymisestä. Tässä valossa IFC objektiluokkien tai alaluokkien (predefined type) käyttäminen tiedonsiirrossa on väärä ratkaisu. Niihinkin on näet rakennettuna sisään ajatus rakennuksen universaalista hierarkiasta, joka on todellisuudessa kuitenkin lähinnä mallinnusohjelmien työkalujen mukaan tehty. Mallintamiseen on esimerkiksi laattatyökalu, jota vastaa IfcSlab. Todellisuudessa rakennuksessa on ala-, väli- ja yläpohjia, alakattoja, parvekelaattoja jne. IFC mallin rakenteessa on siis kaksi virhettä. Ensin ajatus siitä, että on olemassa universaali hierarkia ja toiseksi vielä tapa, jolla tuo hierarkia on tehty. IFC objektiluokkia ja alaluokkia perustellaan usein ohjelmistoteknisillä syillä, mutta tämä perustelu ei kestä päivänvaloa. Tiedonsiirto voidaan aivan yhtä hyvin toteuttaa myös ilman objektiluokkia. Nykyisin siirretyn objektiluokan avulla valitaan vastaanottavassa ohjelmassa se objektiluokka, jolla objekti esitetään tuossa vastaanottavassa ohjelmassa. Tämä valinta voitaisiin tietoteknisesti kuitenkin aivan yhtä tehdä minkä tahansa muun ominaisuuden tai ominaisuuksien yhdistelmän perusteella. Lähettävässä ohjelmassa käytetty objektiluokka voi tosin aivan hyvin olla yksi siirrettävä ominaisuus muiden ominaisuuksien joukossa.
Datakubismilla on ylivoimaisen perusideansa lisäksi monia hyviä kerrannaisvaikutuksia. Se auttaa esimerkiksi vähentämään ja yksinkertaistamaan tietomallivaatimuksia. Enää ei tarvitse toimittaa malleja, jotka on jäsennetty valmiiksi vastaanottajan tarpeiden mukaan, vaan malleja, joissa on tuon jäsentämisen mahdollistava tieto siltä osin kun sen tuottaminen kuuluu tiedon tuottajalle. Tällöin tiedon tuottaja on selkeästi vastuussa toimittamistaan tiedon murusista, mutta ei lainkaan niistä päätelmistä, joita joku toinen näiden murusten perusteella tekee.
Koska nykyiset ohjelmistot, niiden välinen tiedonsiirto ja tietomallivaatimukset on viritetty hierarkioiden varaan, olisi nykyinen ratkaisumalli helppo nähdä välttämättömyytenä. Mutta kun selkeästi parempi idea, eli datakubismi, on kerran keksitty, ei pullon henkeä saa enää takaisin pulloon. Nyt tarvitaan vain ohjelmistoja, jotka toteuttavat datakubisimin idean. Tällaisella ohjelmistolla on kaksi pääfunktiota; mallin räjäyttäminen tiedon murusiin ja mallin jäsentäminen uudella tavalla näiden tiedon murusten perusteella. Onneksi IFC muokattavana tiedonsiirtoratkaisuna, kaikista puutteistaan huolimatta, antaa tähän hyvät mahdollisuudet. Paras idea voittakoon! Siis datakubismi.
7.5.2022
Jiri Hietanen