Yhteentoimivuusvälineistön yleisenä tietomallinnusperiaatteena on tietosisältöjen linkittäminen ja uudelleenkäyttö. Käytännössä tämä tarkoittaa eri tahoilla määriteltävien, uudelleenkäytettävien tietokomponenttikirjastojen hyödyntämistä tietojärjestelmien tietomallinnuksessa. Tietomalleja, jotka uudelleenkäyttävät aikaisemmin määriteltyjä tietomalleja ja kansainvälisiä standardeja, kutsutaan soveltamisprofiileiksi.

Soveltamisprofiilin tietomallinnus eroaa perinteisestä tietomallinnuksesta siten, että kaikki määriteltävät tietosisällöt saavat pysyvän URI-tunnisteen, jonka avulla tietomääritys voidaan löytää, linkittää ja uudelleenkäyttää. Perinteinen tietomalli määritellään itsenäisenä kokonaisuutena, jossa tietorakenteet saavat pelkästään paikalliset tunnisteet ja tietomallien välinen uudelleenkäyttö tarkoittaa käytännössä tietomääritysten kopiointia ja uudelleenmäärittelyä. Soveltamisprofiilin määrittelyssä tarkoituksena on uudelleenkäyttää samalla tietoalueella määriteltäviä uudelleenkäytettäviä luokkia (Tietokomponentteja), sekä linkittää tietomalli tietoalueen sanastoihin ja koodistoihin.

Yleisiä mallinnusperiaatteita

  1. Määrittele soveltamisprofiilille ja mallinnettavalle tietosisällölle selkeä käyttötarkoitus. Selitä käyttötarkoitus tietomallin kuvauksessa.
  2. Lisää tietomalliin tietoalueella käytössä olevat olennaiset sanastot ja koodistot
  3. Kun määrittelet uuden tietosisällön, uudelleenkäytä tietoalueen sanastoa
    1. Ehdota uusia käsitteitä, jos tietosisältöä kuvaavaa käsitettä ei ole määritelty sanastossa
    2. Kirjoita tietosisällölle tarkempi kuvaus tapauskohtaisesti. Kirjoita, miksi tietosisältö on olemassa ja miten sitä vastaavaa tietosisältöä tulee käsitellä.
  4. Uudelleenkäytä luokkia, attribuutteja ja assosiaatioita julkisen hallinnon tietokomponenttikirjastosta
    1. Ennen uuden tietosisällön määrittelyä tutki, onko vastaava tietosisältö määritelty aiheeseen liittyvillä tietoalueilla
    2. Jos luokkaan joudutaan tekemään usein tietoaluekohtaisia lisäyksiä, määrittele luokasta alaluokka tietoalueelle
    3. Kirjoita tarkennettu kuvaus tapauskohtaisesti. Jos tietomallissa on useita samantyyppisiä tietosisältöjä, kerro miten tietosisällöt eroavat toisistaan.

Soveltamisprofiilin mallintaminen

Soveltamisprofiilin tarkoituksena on kuvata yksittäisen tietojärjestelmän (tai sen osan) tietosisältö ja tietoon liittyviä vaatimuksia ja rajoituksia. Tarkoituksena on vähentää tietojärjestelmän kehitys- ja ylläpitokustannuksia hyvällä suunnittelulla ja dokumentoinnilla. Tietosisällön dokumentointi tukee tietojärjestelmän ymmärrettävyyttä, tiedon uudelleenkäyttöä ja vähentää uudelleenmäärittelyn tarvetta. 

Tietorakenteet kuvataan soveltamisprofiilissa siten, että niiden perusteella voidaan muodostaa fyysinen tietomalli eri tekniikoilla tai syntakseilla. Tietomallit.suomi.fi-sovelluksella toteutetun soveltamisprofiilin tietorakenteet ovat määritelty rakenteisesti linkitettynä datana siten, että tietorakenteet ovat yhteensopivia XML- tai JSON-skeemojen rakenteiden kanssa. Työkalusta voi ladata tietomallia vastaavan XML-, JSON- tai SHACL (RDF) -skeeman, jonka avulla määriteltyä tietosisältöä voidaan hyödyntää tiedon validoinnissa tai rajapinnan tietosisältömäärityksen pohjana.

Soveltamisprofiili voi kuvata tietojärjestelmän tietosisältöjä eri tarkkuustasoilla. Sisällöllisesti soveltamisprofiili on sopimus siitä, miten yhteisesti sovittua kieltä ja tietorakenteita käytetään tietyssä käyttötarkoituksessa.

Soveltamisprofiilin käyttötarkoitukset

Soveltamisprofiilin tietosisältö kuvataan aina tietojärjestelmän kannalta olennaisella tarkkuudella, joka määrittyy käyttötarkoituksen mukaan.  Käyttötarkoitus voidaan jakaa karkealla tasolla neljään eri ryhmään:

  1. Tiedonsiirtorajapinnan tietosisältö - Mitä tietoa siirretään?
  2. Sovellusrajapinnan tai tietojärjestelmän tietosisältö - Mitä tietoa käsitellään?
  3. Tietovarannon tietosisältö - Mitä tietoa säilytetään?
  4. Yleinen tietosisällön kuvaus - Mitä tietoja tarvitaan?

Tiedonsiirtorajapinnan tietosisällön kuvaaminen

Tiedonsiirtomääritys tehdään tietojärjestelmien välisen tiedonsiirron toteuttamiseksi. Määritys kuvaa tietosisällön rakenteisena asiakirjana, jonka avulla tietosisältö voidaan validoida ja siirtää tietojärjestelmien välillä. Tiedonsiirron kohteena on yleensä pienempi tietokokonaisuus suuremmasta tietojoukosta. Tiedonsiirtomäärityksissä suositaan yleensä yksiselitteistä tietomallia, joka kuvaa siirrettävän tietosisällön tietorakenteet siten, ettei siirrettävän tiedon tulkitsemiseen tarvita erillisiä tietolähteitä. Tietosisällön validoinnissa voidaan käyttää myös koodistoja, jotka toteutetaan yleensä enumeraatioina osana tiedonsiirtomääritystä.

Tiedonsiirtorajapinta (REST tai WSDL) tukee yleensä JSON- tai XML-formaattia. Soveltamisprofiilin avulla voidaan määritellä ja dokumentoida siirrettävät tietosisällöt ja tuottaa XML- tai JSON-skeema, jota voidaan hyödyntää rajapinnan toteutuksessa. Soveltamisprofiilissa rakenteisen asiakirjan voi kuvata määrittelemällä tietomallille juurisolmun. Juurisolmu (Root element) on rakenteisen asiakirjan ensimmäinen elementti, jonka alle tietosisältö kuvataan hierarkkisena tietorakenteena. Luokkamäärityksissä kuvattavilla luokan attribuuttien ominaisuuksilla, kuten kentän toistuvuus tai vähimmäispituus, voidaan määritellä sääntöjä tiedon eheydelle.

Jotkin tiedonsiirtorajapinnat käyttävät toimialakohtaisia teknisiä standardeja tiedonsiirtoon, kuten esimerkiksi taloushallinnossa käytössä oleva XBRL tai paikkatiedossa käytetty INSPIRE -suositus. Soveltamisprofiilin avulla voidaan suomentaa ja dokumentoida, mitä standardeja elementtejä kansallisessa toteutuksessa on käytössä. Varsinaisen tietosisällön kuvaaminen soveltamisprofiilin avulla on kuitenkin mahdotonta tapauksissa, joissa standardin mukainen tietorakenne ei määrittele tietosisältöä. Esimerkiksi XBRL-tietomääritysten tapauksessa varsinainen tietosisältö kuvataan erilaisissa koodistoissa, esimerkiksi Kirjanpidon koodistot 2019. Kaikissa tapauksissa teknisen standardin käytön dokumentointi soveltamisprofiilina ei ole mielekästä. Soveltamisprofiili kannattaa kuitenkin tehdä aina tapauksissa, joissa määritellään uusia tietorakenteita tai kansainvälisistä standardeista halutaan poiketa (soveltaa).

Esimerkkejä tiedonsiirtomäärityksistä:

Sovellusrajapinnan tai tietojärjestelmän kuvaaminen

Rajapinnan tai tietojärjestelmän tietomallinnuksessa pyritään yleensä kuvaamaan tietosisältö yleisellä tasolla, jolloin tietomalli kuvaa kaikkia yleisiä tapauksia. Eri tyyppisten operaatioiden vaatimien tarkempien tietosisältöjen kuvaaminen tietomallin avulla voi olla hyvin työlästä. Otetaan esimerkiksi tapaus, jossa haluttaisiin toteuttaa rajapinta, jonka avulla voidaan hakea sähköisestä kaupasta tuotteita. Mallinnetaanko erikseen kaikki parametrit, joilla tuotteita voi hakea? Entä mallinnetaanko kaikki erilaisia attribuutteja sisältävät tuotetyypit erillisinä luokkina?

Erilaisten kombinaatioiden määrä voi olla suuri. Tämän takia rajanveto yksiselitteisen ja joustavan tietomallinnuksen välillä on hyvin tapauskohtaista. Sovellusrajapinnan tietomallinnuksessa pyritään yleensä kuvaamaan tietojärjestelmän tietosisältö riittävän yleisellä tasolla, jotta voidaan useammassa operaatiossa käytettävä tietosisältö yhdellä luokalla. Yleisemmin määriteltyä tietomallia voidaan käyttää rajapintakuvauksessa lähtökohtana (Base-skeemana), jonka päälle tarkemmat kuvaukset rakentuvat. Tarpeen mukaan samasta tietojärjestelmästä voidaan tehdä useita tietomalleja, jotka kuvaavat tietojärjestelmän erilaisia rajapintoja.

Esimerkkejä sovellusrajapinnan tai tietojärjestelmää kuvaavista tietomalleista:

Tietovarannon kuvaaminen

Soveltamisprofiilin avulla voidaan dokumentoida tietovarannon tai tietokannan tietosisältö. Tietomallit-työkalu soveltuu kuitenkin huonosti relaatiokannan tekniseen tietomallintamiseen eikä se tue SQL-lauseiden generointia. Työkalussa voidaan kuitenkin tehdä ns. tietokannan käsiteanalyysi, jossa tietokannan tietosisältö kuvataan sisällöllisesti. Tietosisältöjä voidaan kuvata myös loogisella tasolla määrittelemällä attribuuteille sovellusriippumattomia tietotyyppejä ja arvoaluerajoituksia. Soveltamisprofiilia mallintaessa on hyvä huomioida, että tietosisältöjen väliset relaatiot kuvataan suunnattuina assosiaatioina (Directed / Uni-directional association), esimerkiksi. Henkilö → Yhteystiedot. Tämä eroaa perinteisestä ER-mallista, jossa assosiaatio määritellään yleensä kaksisuuntaisten assosiaatioiden (Bi-directional association) avulla. Soveltamisprofiilissa yksisuuntaiset assosiaatiot kuvataan tarvittaessa molempiin suuntiin, esimerkiksi: Henkilö -työskentelee → Organisaatio ja Organisaatio -työntekijä → Henkilö.

Tietosisältöä mallintaessa tulee ottaa huomioon suhteiden käsitteellinen merkitys. Assosiaation semantiikka kuvataan soveltamisprofiilissa aina luokkakohtaisesti, mikä on välttämätöntä eri syntaksien yhteentoimivuuden kannalta. Esimerkiksi henkilön yhteystietoja mallintaessa (Kuva 1) pitää siis määritellä, onko henkilöllä yhteystiedot vai yhteystiedoilla henkilö? Assosiaatio kuvaa luokkien välistä suhdetta yhden luokan näkökulmasta.


Kuva 1: Esimerkki henkilön yhteystiedoista.


Vakionäkymässä visualisoidaan tietosisällön ihmisluettavat nimet (Kuva 1). Lisäksi alla on esitetty kaksi vaihtoehtoista visualisointia, joissa näytetään joko paikallinen tekninen nimi tai pysyvä tunniste (Kuva 2). Eri tyyppisten visualisointien tarkoitus on viestiä tietosisällöstä erilaisille kohderyhmille. Esimerkiksi liiketoiminnan omistajaa kiinnostavat ihmisluettavat nimet, tietomallintajaa tietokannassa käytettävät tekniset nimet, ja integrointisuunnittelijaa määritysten URI-tunnisteet.


Kuva 2: Vaihtoehtoisia nimiä visualisoinnissa. 1 = Tietokannan tai skeeman tekniset nimet. 2 = Pysyvät URI-tunnisteet.


Vastaava tietosisältö voidaan kuvata ER-kaavion avulla usealla eri tavalla. Yksisuuntainen yhteystieto assosiaatio tietomallissa tarkoittaa sitä, että Yhteystiedot luokan suhdetta Henkilö luokkaan ei ole määritelty. Seuraavassa fyysisen tason ER-kaaviossa (Kuva 3.) on esitetty kolme eri toteutustapaa, jotka eroavat toisistaan tietojen toistuvuuden ja viitteiden eheyden suhteen. Jos assosiaatioita ei ole kuvattu erikseen molempiin suuntiin erikseen, voidaan siitä tehdä erilaisia tulkintoja. 


Kuva 3: Esimerkki tietosisällöstä relaatiokannassa.

Vaihtoehto 1

Henkilo_1 määrittelee pakollisen viiteavaimen Yhteystiedot_1 taulusta, joka tarkoittaa sitä että kyseiseen kantaan ei voida tallettaa henkilöä ilman yhteystietoja. Yhteen henkilöön voi kuitenkin liittyä vain yksi yhteystietoYhteystiedot_1 tauluun voi kuitenkin tallettaa useita yhteystietoja jotka eivät liity mihinkään henkilöön. Soveltamisprofiililla kuvattu tietomalli (Kuva 1) ei ota kantaa siihen onko kyseinen tilanne sallittu, ellei asia ole kuvattu tekstimuotoisena lisädokumentaationa.

Vaihtoehto 2

Yhteystiedot_2 määrittelee pakollisen viiteavaimen Henkilo2 taulusta, joka tarkoittaa että kyseiseen kantaan voidaan tallentaa henkilöitä joihin ei liity yhteystietoja. Yhdellä henkilöllä voi kuitenkin nyt olla useampi yhteystieto. 

Vaihtoehto 3

Henkilo_3 ja Yhteystiedot_3 välille määritellään välitaulu, jonka avulla voidaan kuvata, mikä yhteystieto kuuluu millekin henkilölle. Tilanteesta riippuen tämä vaihtoehto voi olla soveltuvin. Yksisuuntaisen assosiaation kardinaliteetin perusteella ei voida suoraan tietää pitääkö luokkien välille muodostaa välitaulu. Välitaulu voidaan muodostaa tapauskohtaisesti kun kardinaliteetti on 1..*. Henkilöllä voi tässä tapauksessa olla useampi yhteystieto ja kahdella eri henkilöllä voi olla sama yhteystieto.

Soveltamisprofiilissa määritelty tietosisältö voidaan toteuttaa relaatiokantana eri tavoin. On huomioitava, että tietovarastoa kuvattaessa soveltamisprofiili on ensisijaisesti tietosisällön dokumentaatio, jossa kuvataan tietosisällön semantiikkaa yksittäisten objektien näkökulmasta.  Tietokannan todellista rakennetta vastaava fyysinen ER-kaavio on hyvä tehdä erikseen. Jos soveltamisprofiilissa halutaan määritellä tarkemmin saako samaan yhteystietoon liittyä useampi henkilö, on soveltamisprofiilissa kuvattava erillinen Yhteystiedot -liittyy-(1..*)-> Henkilo -assosiaatio (Kuva 4).


Kuva 4. Assosiaatiot molempiin suuntiin

Vastaavassa loogisen tason ER-kaaviossa assosiaatiot voidaan yhdistää yhdeksi kaksisuuntaiseksi assosiaatioksi (Kuva 5).

Kuva 5. Assosiaatioiden tulkinta relaatiomallissa


Esimerkkejä tietovaraston tietosisältöä kuvaavista tietomalleista:

Käsitemallinnus ja tietosisällön yleinen kuvaaminen

Soveltamisprofiilien ensisijaisena tarkoituksena on toimia ihmisten välisinä sopimuksina käytettävistä tietosisällöstä. Tietomallinnusta voidaan siis tehdä jo ennen varsinaista tietojärjestelmäkehitystä. Tällöin puhutaan yleisesti käsitemallinnuksesta tai tietosisällön yleisestä kuvaamisesta. Tietomallien avulla voidaan hahmotella kerättävien tai siirrettävien tietojen kokonaisuutta. Soveltamisprofiilin voi tehdä esimerkiksi projektisuunnitelman yhteydessä tai kesken projektia selventämään käsitteellisiä erimielisyyksiä eri toimijoiden kanssa.

Tietomallit voivat siis olla hyvin abstraktilla tasolla määriteltyjä käsitemalleja. Käsitemallien osalta tietosisältö voi myös tarkentua ajan myötä, jolloin eroa käsitemallinnuksen ja loogisen mallinnuksen välillä ei enää käytännössä ole. Tietomallinnus voidaan esimerkiksi aloittaa hahmottelemalla soveltamisprofiiliin yleisiä käsitteitä ja päätyä lopulta kuvaamaan tiedonsiirtomääritys. Tilanne on yleinen, koska ymmärrys tietosisällöstä kasvaa vähitellen ja vaatimukset tarkentuvat projektin edetessä.

Esimerkkejä yleisistä tietosisältöä kuvaavista tietomalleista:

Yksiselitteinen vs. joustava tietomalli

Tietomalleja tehdään eri käyttötarkoituksiin, jolloin myös tietosisältöjen karkeus (abstraktiotaso) vaihtelee käyttötarpeen mukaan. Tietomallin tietorakenteita kuvataan eri tavoin kun määritellään tiedonsiirtomääritystä tai tietokannan sisältöä. Joustava tietomalli (dynaaminen) ottaa huomioon tietojärjestelmän muutostarpeen nostamalla tietomallin abstraktiotasoa tyypityksen ja roolituksen avulla. Yksiselitteinen tietomalli (staattinen) määrittelee tietorakenteet ilman tyypityksiä ja rooleja mahdollisimman tarkalla tasolla. Yleensä tietomallinnus on tasapainoilua joustavuuden ja yksiselitteisyyden välillä.

Tietokannan tietosisällön määrittelyssä suositaan yleensä joustavaa tiedon tyypitystä ja roolitusta, jolloin tietokannan rakennetta ei tarvitse muuttaa, vaikka tietokantaan haluttaisiin tallentaa uuden tyyppistä tietoa. Tiedonsiirtomäärityksissä suositaan taas usein yksiselitteisempiä tietorakenteita, jolloin tietosisällön ymmärtämiseen tarvitaan vähemmän erillisiä lisätietoja. Tietoa tyypittäviä ja roolittavia koodistoja käytetään kuitenkin tiedonsiirrossa tapauksissa, joissa tietosisällön voidaan olettaa muuttuvan tai tarkentuvan ajan kuluessa. Tiedonsiirrossa siirretään myös yleensä pienempi määrä tietoa, kun vastaavasti tietokanta rakennetaan säilyttämään kaikki sinne tallennettava tieto. 

Tiedon tyypitys

Tyypittäminen on tiedon yleistämistä ja luokittelemista tiedon ominaisuuksien avulla. Tietomallissa voidaan kuvata esimerkiksi luokka Auto, mutta sama tieto voidaan yleistää Liikenneväline-luokaksi lisäämällä luokalle liikennevälineen tyyppi -niminen attribuutti. Tyypittävälle attribuutille voidaan määritellä sallitut arvot koodiston avulla, esimerkiksi tässä tapauksessa arvot 1=Henkilöauto ja 2=Kuorma-auto. Sallitut arvot määritellään yleensä koodistona, jolloin tallennettava tietomäärä on vähäisempi ja koodien ihmisluettavat termit ja kuvaukset voivat täydentyä kehityksen edetessä ilman tietojärjestelmien muutostarpeita. Joissain tapauksissa tyypit voivat olla myös tietojärjestelmän sisäisiä referenssitietoja, jotka kertyvät sovellusta käytettäessä.

Tiedon roolitus

Roolittaminen on tiedon tyypittämistä jonkin toisen asian suhteen. Rooliin liittyy siis aina jokin assosiaatio kahden luokan välillä. Rooleja tietomalleissa voi olla esimerkiksi Henkilön rooli Projektissa tai Osoitteen rooli Henkilön yhteystiedoissa. 

Myös rooli voidaan määritellä joustavasti tai yksiselitteisesti. Joustavia roolimäärittelyjä ovat esimerkiksi Rooli-luokka tai roolikoodi-attribuutti. Yksiselitteisiä roolimäärittelyjä ovat taas rooli-assosiaatio tai rooliKytkin-attribuutti.

Rooli voi olla myös ajan suhteen muuttuva, jolloin roolitieto kertoo myös millä ajanhetkellä kyseisellä tiedolla on ollut kyseinen rooli.

Esimerkkejä tyypeistä ja rooleista

Sama tietosisältö voidaan kuvata monesta eri näkökulmasta käyttäen erilaisia tietorakenteita. Esimerkiksi Projektiin liittyvät Henkilöt voidaan kuvata Henkilön tai Projektin näkökulmasta (Esimerkki 1 ja 2). Esimerkeissä on käytetty tiedon tyypittämistä ja roolittamista eri tavoin. Projektiin liittyvien henkilöiden rooli voidaan kuvata yksiselitteisesti Projektin ja Henkilön välisenä assosiaationa (Esimerkki 1) tai Henkilön ominaisuutena (Esimerkki 2). Roolitus ja tyypitys ovat yksiselitteisiä, kun niiden arvojen esittämiseen ei tarvita koodistoja.

Esimerkki 1: Projektin henkilöt

Esimerkki 2: Henkilön projektit


Rooli voidaan kuvata myös joustavasti koodiston avulla. Tilanteesta riippuen tietomallissa voidaan määritellä Rooli-niminen attribuutti tai assosiaatio Rooli-nimiseen luokkaan (Esimerkki 3 ja 4). Erillisen tyyppi/rooli koodistojen avulla tietomallista tulee joustavampi, jolloin koodiston arvoja voidaan muuttaa myöhemmin muuttamatta itse tietomallia. 

Esimerkki 3: Henkilön rooli-attribuutti

Esimerkki 4: Henkilön rooli luokkana


Rooli voidaan kuvata tarpeen mukaan myös ajallisenä ilmiönä, jolloin tietty henkilö voidaan määritellä olevan tietyssä roolissa tiettyyn aikaan (Esimerkki 5).


Esimerkki 5: Rooli ajallisena ilmiönä


Rooliin liittyviä tehtäviä voidaan kuvata myös ilman varsinaista roolimäärittelyä assosiaatioiden avulla (Esimerkki 6). Tämä tietomalli kuvaa saman asian kuin aiempi esimerkki, mutta sen tietosisältöä ei voida laajentaa ilman tietomallin muutosta.  

Esimerkki 6: Rooli ajallisena ilmiönä kuvattuna assosiaatioilla 


Roolia ja vastuuta voidaan kuvata myös tarkemmin käyttämällä assosiaatioita ja määrittelemällä rooleille omat tarkennetut luokat (Esimerkki 7). Roolikohtaisien assosiaatioiden ja tarkennettujen luokkien avulla voidaan määritellä roolikohtaisia lisätietoja.

Esimerkki 7: Rooliluokkien määrittely


Joissain tapauksissa mallinnettava toimija halutaan määritellä abstraktina luokkana. Tällöin voidaan määritellä abstrakti "kuori"-luokka (Esimerkki 8). Tässä esimerkissä Projektitoimija voi olla joko Henkilö tai Organisaatio. Kyseinen mallinnustapa vastaa XML-skeemassa choice- tai JSON-skeemassa oneOf -määrityksiä.


Esimerkki 8: Vaihtoehtoinen luokka


Vaihtoehtoinen luokka voidaan määritellä myös yksiselitteisesti assosiaatiolla ilman roolia ja kuori-luokkaa (Esimerkki 9). Tällöin kuvataan erilliset assosiaatiot eri tyyppisille tietosisällöille.


Esimerkki 9: Vaihtoehtoinen luokka erillisinä assosiaatioina


Roolin kuvaus eri näkökulmista liittyy vahvasti käyttötarpeeseen. Eri käyttötarpeissa tarvitaan rikkaampia ja tarkempia tietoja kuvaamaan tarvittavia tietosisältöjä. Yleisesti voidaan todeta että esimerkkien 1-9 tarkkuus ja rakenteisuuden taso vaihtelee käyttötarpeen mukaan.

Rakenteisuuden taso

Rakenteisuus tietomalleissa tarkoittaa käsiteltävien tietojen esittämistä sopivalla tarkkuustasolla. Sopiva rakenteisuuden taso määrittyy tietojärjestelmien käsittelysääntöjen kautta. Tiedot tulee kerätä riittävän tarkalla tasolla, jotta tietoa voidaan käsitellä automaattisesti erilaisissa prosesseissa.

Rakenteistamattoman tiedon käsittelyyn voidaan käyttää kuvailevia metatietoja ja tiedon tyypittämistä. Esimerkiksi asianhallintaprosessissa käsiteltävän asian tila kuvataan koodiston avulla, jonka tarkoituksena on mahdollistaa asian käsittelyn seuranta.


  • No labels