10 Tieto ja metatieto Tiedon mallinnus tähtää tietyn sovelluksen sisäisen tiedon lokerointiin ja rakenneosien tarkoituksenmukaiseen nimeämiseen, tietojenkäsittelyn tarpeet huomioiden. Pelkkä "lopputuotteen" tietomalli ei kuitenkaan yleensä kirjaa kaikkea työssä tarvittavaa tietoa. Erityisesti, itse tuotantoprosessiin ja esim. erityyppisten sovellusten tiedonhakuun ja yhdistelyyn tarvittava tieto pitää esittää jotenkin. Tämä tarkoittaa sitä, että tietoa pitää kuvata myös sovelluksen oman (rajatun) vaatimusmäärittelyn "ulkopuolisesta näkökulmasta" käsin. Seuraavaksi tarkastelemme kuvailu- ja metatiedon roolia lyhyesti sovelluksissa, erityisesti dokumenttienhallinnan (DH) näkökulmaan nojautuen (konkreettisena aasinsiltana tiedonhallintaan...). MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 191
10.1 Välisoitto Tieto hukkuu ellei siitä pidetä kiinni (vrt. työmuisti vs. tietokanta) Tietotyö on tyhjäkäyntiä mikäli (ihmisten) kaikki aika menee selaamiseen Tavoite: tiedon tarpeellisuus ja tarvitsija selvillä eri tilanteissa MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 192
10.2 Tieto ja metatieto (lue: data ja metadata) Tietoa jaotellaan perinteisesti tiedon ja metatiedon välillä - "metatieto on rakenteista tietoa, joka kuvaa muuta tietoa sekä ohjaa ja dokumentoi sen käsittelyä ja hallintaa" - "tiedon sisältöä kuvaavaa, luokittelevaa ja sen merkitystä kuvaavaa tietoa" Jako "metatiedon ja tiedon välillä" on sopimuksenvarainen ja liittyy sovellusalaan ja tietojen hallintaprosessiin (tarpeellista kirjaten tietoa) - vrt. esim. oma kovalevy - kirjasto - kansallisarkisto - vakuutusyhtiö Metatiedon tuottamisen kärjistetty työjako: - tietokoneohjelma kirjaa mekaanisesti tunnistettavan metatiedon (esim. paikka, kirjoittaja, työväline, kellonaika, versio) - ihminen tuottaa harkintaa vaativan metatiedon (esim. tehtävä, luokittelu, käyttöoikeudet, version päähaara, status) Metatiedon tyypillinen käyttötarkoitus on "tukea varsinaisen tiedon käyttöä" MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 193
10.3 (Meta)tieto ja dokumenttien elinkaari Dokumenttienhallinnan sovelluksissa pelkkä tietosisällön kuvailu ei siis riitä; yleisemmin tarvitaan metatietoa tiedon (tai dokumenttien) koko elinkaaren hallintaan; vrt. pelkistys: Tarvittavia metatietokenttiä Luonti ei tietenkään "vedetä Tarkastus hihasta", vaan määritellään suhteessa käsit- Muokkaus Hyväksyntä telyprosessiin kokonaisuutena (esim. kirjaamalla prosessikaavioon näkyville vaatimuksina siitä mitä (meta)tietoa tarvitaan missäkin käsittelyvaiheessa) Kuva: Anttila, 2001 Julkaisu Haku Katselu Arkistointi - vaikea optimointitehtävä: metatiedon keräämisen (ja ylläpidon) hinta vs. metatiedoista saatava lisäarvo (on helppo määritellä "liikaa" metatietoa) Poisto MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 194
10.4 "Ei ole metatietoa, on vain tietoa" Huomaa että tieto/metatieto -erottelu ei ole teknisesti välttämätön, vrt.: - dokumenttiin merkattu tieto - valitun tekstiformaatin tyyppi- tai skeemamäärittely (tietomalli & sanasto) - kuvaileva "metatieto" (jommastakummasta!) - "metatiedon" käyttöä ohjaava skeema - kuvaileva "(...meta)metatieto" jne. -...sovellusalueen ontologia (käytännöllinen rajaus) tyyppi käsikirjoitus Mediaobjektit viimeksi muokattu: 2003-11-26 Se päivämäärä jolloin tietosisältö viimeksi muuttui, tyyppi: xsd:date kauppapaikan tuotetieto Viestinnässä ja mallinnuksessa käytetyt tekniset menetelmät ovat kompromisseja joilla pyritään esim. tehokkuuteen ja yhteensopivuuteen Huom. Termeillä "asiakirja", "metatieto" yms. kuitenkin voi sovellusalueella olla tietty lainsäädöksellinen tms. sitova status (vrt. JHS 143) MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 195
10.5 Esimerkki (1/4): XML ja RDF Kaikenlainen skeematieto voidaan siis tulkita metatiedoksi käsiteanalyysin sijaan kannattaa kuitenkin miettiä jo käyttötapauksia Esimerkki (tai toisin päin tai muilla tekniikoilla!): - XML soveltuu esim. asiakirjojen tietosisällön esittämiseen (mutta muuhunkin) - RDF soveltuu esim. metatietojen esittämiseen (mutta muuhunkin) Mutta mitkä XML:n ja RDF:n piirteistä ovat luonnollisia tai oikeasti olennaisia esim. asiakirjojen hallinnassa? Vaikea kysymys?! Tarkastellaan case-esimerkkiä: - kuvataan organisaation asiakirjojen status: luokitellaan ne asteikolla internal_draft, public_draft, last_call_draft, camera_ready_doc ja note MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 196
10.6 Esimerkki (2/4): asiakirjojen tietosisältö (XML Schema) Ilmeisestikin XML soveltuu hyvin asiakirjojen esittämiseen (tyyppi esim. advertisement, guideline tai specification ja tila [status] esim. last_call_draft) <document id="http://my.org/names/2005/docs/item457" version="1.1" type="&myvoc;guideline" status="&myvoc;last_call_draft"> <title>...</title>... </document> Ko. attribuutin määrittelevä skeema sallii rajoitteena nyt vain luetellut arvot:... <xsd:restriction base="xsd:string"> <xsd:enumeration value="&myvoc;internal-draft"/> <xsd:enumeration value="&myvoc;public-draft"/> <!-- jne. --> </xsd:restriction>... Luetellut arvot voidaan ilmeisestikin rakentaa myös URI-niminä, so. resursseina (määrittele prefiksi &myvoc; sopivasti) MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 197
10.7 Esimerkki (3/4): kuvailutieto (RDF Schema) internal_draft (ID) public_draft (PD) last_call_draft (LC) note (N) camera_ready_doc (CR) Luokittelu tarjoaa nyt keinon liittää dokumentteihin elinkaaren liittyvää kuvailevaa tietoa (filosofit pohtikoot onko tämä "metatietoa"...), esim.: - kaikki ko. tyypin dokumentit (ID, PD, LC, N, CR) ovat asiakirjoja (joiden käsittelyyn asetetaan vaatimuksia) - dokumentit tyyppiä PD, LC, N ja CR ovat julkisia - dokumentit tyyppiä N ja CR ovat valmiita ja pysyviä - julkisilla asiakirjoilla vastaava (ihmis)editori, jne. Tuloksena syntyy sovelluksen (eräs) käsitemalli joka nyt ilmeisestikin voi parantaa DH:n laatua (vaikkei edes formalisoitaisi tietokoneohjelmana!) MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 198
10.8 Esimerkki (4/4): mitä tietoa kerätään ja miksi? Kysymys: Mitä kuvailutietoa (metatietoja) sovelluksessa tulisi sitten kerätä? Vastaus: Selvitetään (prosesseihin ja) käyttötapauksiin vedoten, esim. - dokumenttien/tiedon (semanttinen) luokittelu & integrointi (tuotanto/käyttöprosessit) - dokumenttien/tiedon hakeminen (käsitemallin semantiikka) - dokumenttien/tiedon (ja prosessien) seuranta - dokumenttien/tiedon muokkaaminen, virkistäminen ja poistaminen Esimerkki: Jos dokumentit voidaan semanttisesti liittää projekteihin ja henkilöstöön, voidaan hakuja tehdä paitsi dokumenttien tietosisällön, myös esim. asiayhteyden perusteella (vrt. XQuery/SPARQL) MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 199
10.9 (Meta)tieto luokittelun välineenä Keskeinen (meta)tiedon sovellus on siis luokittelu <tuotetiedot id="e1" luokitus="kodinkoneet" julkaisija="netanttila.com"> <artikkeli tyyppi="leivänpaahtimet" merkki="kenwood" malli="eon Tt 900" hinta="eur 139.00">...</artikkeli> </tuotetiedot> Metatietojen tulkinta edellyttää luokittelussa käytetyistä termeistä ja merkintäjärjestelmästä sopimista (so. skeemasta sopimista): - termistö määrittelee mitä predikaatteja (ns. elementtejä/kenttiä tai tarkentimia) käytetään resurssien kuvailussa (esim. luokitus, malli, hinta) - termeihin voi liittyä merkintäjärjestelmä (Encoding Scheme) joka määrittelee termien ymmärrettävät arvot käytännössä tulisi viitata joko kontrolloituun asiasanastoon tai hyvin määriteltyyn datatyyppiin (esim. kodinkoneet, Kenwood, " 139.00", jne.). Termin arvo voi yleisesti olla myös esim. identifiointitunnus (esim. ISBN tai DOI) MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 200
10.10 Luokitusrakenne eli taksonomia Käytännön syistä sovelluksen termien käyttö määritellään usein sopivan hierarkkisen luokitusrakenteen eli taksonomian mukaan - vrt. "sukupuu" - esim. kone kodinkone leivänpaahdin Tiedon tuottajan näkökulmasta taksonomioiden käyttö mahdollistaa kuvailun sopivalla tarkkuudella (kohde voidaan tunnistaa leivänpaahtimeksi vaikka tarkka mallitieto ei olisikaan selvillä) toisaalta syötettävää tietoa on näin vähemmän Tiedon hyödyntäjän näkökulmasta taksonomiat paitsi helpottavat tiedonhakua, suhteuttamista sekä tarjoavat perustan päättelyyn, tarjoavat ne myös perustan aihepiirin "yleisjäsennykselle" ja esim. informaaleille ohjeille MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 201
10.11 Asiasanasto eli tesaurus Aihe- tai asiasanasto eli tesaurus kuvaa termien synonyymi-, hierarkia- ja assosiaatiosuhteita yhteisesti sovittujen kenttien avulla (sis. taksonomian) - esim. "leivänpaahdin on eräänlainen ruuanlaittoväline" Tesaurusten määrittelemät kentät vaihtelevat hieman sovelluksen mukaan, vrt. esim. UK Archival Thesaurus (UKAT): Term: Economic cooperation Used For: Economic co-operation Broader terms: Economic policy Narrower terms: Economic integration European economic cooperation European industrial cooperation Industrial cooperation Related terms: Interdependence Scope Note: Includes cooperative measures in banking, trade, industry etc., between and among countries. MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 202
10.12 Asiasanastoesimerkki, leivänpaahdin Käytettävä asiasana: kodinkoneet Huomautus: Sanasto sisältää joidenkin kodinkoneitten nimiä; myös kaikkia muita voi käyttää asiasanoina Suppeammat termit: astianpesukoneet, jääkaapit,..., leivänpaahtimet,..., kotitaloussähkölaitteet Kuuluu ryhmiin: [24] Ravitsemus. Ravitsemisala. Elintarvikeala. Majoitusala. Kotitalous Ruotsinkielinen asiasana: hushållsmaskiner Käytettävä asiasana: leivänpaahtimet Laajemmat termit: kodinkoneet Kuuluu ryhmiin: [24] Ravitsemus. Ravitsemisala. Elintarvikeala. Majoitusala. Kotitalous Ruotsinkielinen asiasana: brödrostar MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 203
10.13 Metatiedon soveltaminen (1/2) Kysymys: Miten esim. asiasanojen kodinkoneet ja leivänpaahtimet (eikä paahdin!) valintaan sitten päädytään? Vastaus: Opiskelemalla monimutkaisen luokittelujärjestelmän järkevä käyttö edellyttää yleensä huomattavaa sovellusosaamista, esimerkiksi - yleinen suomalainen asiasanasto (YSA, ks. http://vesa.lib.helsinki.fi/) sisältää 62 asiasanaryhmää; yhdessä ryhmässä voi olla satoja asiasanoja - eduskunnan kirjaston asiasanasto (EKS, ks. http://www.eduskunta.fi/kirjasto/eks/) sisältää 39 päätason asiasanaryhmää; luokittelu voi edellyttää esim. juridista osaamista - Nasan asiasanasto (ks. http://www.sti.nasa.gov/products.html#pubtools) edellyttää esim. luonnontieteiden osaamista, jne. Ison asiasanaston syvällinen haaste piilee juuri (kuvailtavan) tiedon suhteuttamisessa (vrt. kirjastot ja hylly "jätä selaamasi kirja tähän"...) MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 204
10.14 Metatiedon soveltaminen (2/2) Mikäli soveltamisessa on puutteita, (meta)tiedot rämettyvät - vrt. rakenteiset dokumentit & Tag Abyse Syndrome Rämettynyt tieto heikentää tiedon sovellettavuutta merkittävästi! Opetuksia: - metatieto pyrkii välittämään mahdollisimman paljon informaatiota (vrt. päätöspuut ja tiedon "haarukoiminen") - "liian vähän" metatietoa ei tietenkään riitä sovelluksiin ("ei tuottanut lisäarvoa mutta eipä juuri maksanutkaan") -...mutta "liian paljon" metatietoa voi kuitenkin käytännössä johtaa lipsumiseen ja rämettymiseen ("maksoi paljon muttei tuottanut lisäarvoa") Kyse on aidosti vaikeasta ongelmasta, "virheellisillä" (meta)tiedoilla voidaan pyrkiä tietoisesti myös manipuloimaan hakuja (sabotaasi) MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 205
10.15 Metatiedon julkaiseminen Metatiedon julkaiseminen ulkopuolisille edellyttää yhteisesti sovitun tietomallin yms. noudattamista - käytännössä esim. XML- tai RDF-sanasto tai vastaava sovellus (keskeistä yksilöivien tunnistenimien käyttö) - metatieto voidaan kirjata dokumenttien sisään (vrt. XHTML) tai omiksi dokumenteikseen (esim. XML/RDF) Koska metatietoja tyypillisesti kerätään eri organisaatioiden historiallisen ohjeistuksen mukaisesti, tarvitaan yleensä (tietosisällön järkevästi säilyttäviä) muunnoksia eri formaattien ja tietomallien välillä Keskeisiä "yleiskäyttöisiä" metatietomäärityksiä Suomessa ovat esim. JHS 143 (Asiakirjojen kuvailun ja hallinnan metatiedot) ja "Dublin Core" (tarkemmin: Dublin Core Metadata Initiative (DCMI) Metadata Terms) MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 206
10.16 Dublin Core (DC) 101 "The Dublin Core metadata element set is a standard for cross-domain information resource description ["anything that has identity" [i.e. URI]]... There are no fundamental restrictions to the types of resources to which Dublin Core metadata can be assigned." DC määrittelee seuraavat (metadata)elementit (tai -kentät): - Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Rights - ks. http://dublincore.org/documents/2004/12/20/dces/ Huomaa että kaikkien kenttien tulkinta ei ole helposti mekanisoitavissa(!) Soveltaminen edellyttää käytännössä valittuun esitystapaan ja sen merkintäjärjestelmään perehtymistä - esim. HTML, ks. http://www.ietf.org/rfc/rfc2731.txt - esim. RDF/XML, ks. http://dublincore.org/documents/dcmes-xml/ MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 207
10.17 JHS 143 Suositus JHS 143 Asiakirjojen kuvailun ja hallinnan metatiedot määrittelee julkisen hallinnon asiakirjojen hallinnassa ja julkaisemisessa tarvittavia metatietoja (Suomessa), ks. http://www.jhs-suositukset.fi/suomi/jhs143 Suositus ohjeistaa tarjoamaan tietoa erityisesti seuraaviin tehtäviin liittyen: - paikallistaminen (identifiointitunnus, sijaintipaikka) - sisällönkuvailu (nimike, aihe, kuvaus, kieli, kohdeyleisö, kattavuus, lähde, laji) - käyttöedellytykset (oikeudet, julkisuus, säilytysaika, formaatti, suojeluluokka) - konteksti (toimija, tehtävä, asiakirjan tyyppi, suhde, valtuutus) - elinkaari (aikamääre, tila, käsittelyhistoria, säilytyshistoria) JHS 143:n yhtenä tavoitteena on mahdollistaa asiakirjojen kuvailu tietoverkoissa juuri Dublin Core -yhteensopivassa muodossa MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 208
10.18 Pari sanaa versioinnista (1/4): perusidea Dokumenttien (ja tiedon!) versionhallinta on tärkeää kun tietoa tai tekijöitä on paljon, tai tietoa käsitellään pitkän ajan kuluessa: - versiointi, versioiden merkitseminen, versioiden välisten erojen tunnistaminen, versioiden tallentaminen, tuotteen tilan kirjaaminen, täydellisyyden ja yhtenäisyyden varmistaminen Versiointi voidaan jakaa komponenttien ja konfiguraatioiden hallintaan: - komponentit (esim. aliohjelma, dokumentin elementti) versioidaan niiden tietosisällön kehittyessä - konfiguraatiot koostavat loogisia kokonaisuuksia versioiduista komponenteista; kofiguraatiota voidaan siten versioida komponenteista erillään - esim. olio-ohjelma koostuu luokista ja rakenteinen kirja luvuista Rämettyminen yms. on usein seurausta versiointikäytännön puutteista MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 209
10.19 Pari sanaa versioinnista (2/4): versiopuu Versioita merkitään yleensä numeroin, tuloksena on ns. versio"puu" (revisiopuu) - juuriversio ja (syrjäyttävät) peräkkäiset versiot (Revision) - rinnakkaiset versiot (Branch) ja eri versiohaarojen yhdistäminen (Merge) Esim. numeroinnissa 2.3 numero 2 tarkoittaa versionumeroa ja numero 3 revisionumeroa - versionumeron vaihtuminen ("uusi revisio") on merkki "suuresta muutoksesta" (yhteensopivuus?) - revisionumeron vaihtuminen on merkki "pienestä muutoksesta" Versiointi voi siis haarautua: esim. 2.3 2.3.1.1 ja 2.3.2.1 MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 210
10.20 Pari sanaa versioinnista (3/4): yhteensopivuus Tiedonhallinnan yhteydessä versioinnin keskeisiä pulmia ovat versionhallinta ja yhteensopivuus - sotkeeko uusi versio tai päivitys vanhaa työtä? - onko versio taaksepäin/eteenpäin yhteensopiva (ja mihin versioon)? - voidaanko vanha versio palauttaa? Tai oppia siitä, jne. Kukaties suurin haaste on uusien versioiden suunnitteluun liittyvä tasapainoilu uusien piirteiden lisäarvon ja (menetetyn) yhteensopivuuden kanssa - käyttöönotettujen legacy-sovellusten huomiointi ja aidot laajennukset - vanhentuneiden (tietointensiivisten) sovellusten virkistäminen Tietomallien suhteen hankalimpia ovat yleensä skeematason muutokset - esim. asiasanaston sovellukset menevät pahimmillaan "kokonaan" uusiksi (!) jos itse asiasanastoon tehdään merkittäviä muutoksia ("YSA 2.0"...) MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 211
10.21 Pari sanaa versioinnista (4/4): välineistä Versiointi edellyttää yleensä ohjelmistotukea ja erillisen tietovaraston (Repository) käyttöä - keskeistä toki ovat hyvä suunnittelu ja systemaattiset käytännöt - kirjanpidon automatisointi, - hajautettu tai usean käyttäjän versionhallinta (esim. lukitseminen tai Check out-edit-commit) Suosittu ilmainen versionhallintajärjestelmä on esim. CVS (Concurrent Versions System), - ks. http://www.nongnu.org/cvs/ Ks. myös esim. WebDAV (Web-based Distributed Authoring and Versioning) - mukana siis myös hajautetun ylläpidon teema - ks. http://www.webdav.org/ ja http://www.webdav.org/specs/rfc3253.html MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 212
10.22 Lopuksi Tekninen termistö vaihtelee hieman metatiedoista puhuttaessa (esim. "elementti", "merkintäjärjestelmä", jne.) Tervehenkinen minimalismi on (taas kerran) arvossaan (meta)tiedoista puhuttaessa: konkreettiset käyttötapaukset (muista myös keräämisen hinta, oikeellisuus ja ylläpidon kustannukset!)...ennakoimattomat sovellukset ("lisätieto" on ok jos tietokone kirjaa) Onnistunut suunnittelu on tyypillisesti seurausta esitutkimuksesta joka tarkastelee koko tiedon hallintaprosessia realistisella otteella Myös versiointia kannattaa miettiä ajoissa vaikka tulos olisi vain attribuuttipari (!) (versioitavan-resurssin-id, versio) dokumenteissa MATHM-57200 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2005) - ON 213