10 Tieto ja metatieto (dokumenttien hallinnassa)

Transkriptio

1 10 Tieto ja metatieto (dokumenttien hallinnassa) 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 198

2 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 199

3 10.2 Tiedon taksonomia Sovelluksissa esiintyy poikkeuksetta useantyyppistä tietoa jota voidaan yrittää ymmärtää tai jaotella esim. akseleilla - informaali - formaali (ks. ao. kuva) - implisiittinen (tai hiljainen/piilevä) - eksplisiittinen (ks. seuraava sivu) Data Informal data ( in the people and in the non-modeled environment ) Data in paper (Semi-)formal data Data in computers Some data Modeled data MATHM RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 200

4 10.3 Huomioita "Organisaatiomuistin" idea (vrt. standardi muistimalli) - Työmuisti + konteksti vs. Pitkäkestoinen muisti - Hakutehtävä? Vrt. Data Sharing Systems (DSS) - Keskeiset roolit: Provider, Consumer - Keskeiset aktiviteetit: Discovery, Access, Understanding, Policy MATHM RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 201

5 10.4 Tietämys ja sen käsittely: the SECI model Suosittu tietämyksen hallinnan pelkistys on Nonakan ja Takeuchin SECImalli (Socialization, Externalization, Combination, Internalization) Mallin perusteella voidaan esim. pohtia yksilön (I), ryhmän (G) ja organisaation (O) välisiä tietoon ja tietämykseen liittyviä vuorovaikutusprosesseja Ideoiden jalkauttaminen käytäntöjen ja välineiden tasolle on tietenkin haasteellista (Kuva: Rice&Rice 2005) MATHM RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 202

6 10.5 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 203

7 10.6 (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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 204

8 10.7 "Ei ole metatietoa, on vain tietoa" Huomaa että tieto/metatieto -erottelu ei ole teknisesti välttämätön, vrt.: - (rakenteiseen) 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: Se päivämäärä jolloin tietosisältö viimeksi muuttui, tyyppi: xsd:date kauppapaikan tuotetieto Viestinnän ja mallinnuksen tekniset menetelmät ovat (osin historiallisiakin) 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 205

9 10.8 Esimerkki (1/5): 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 206

10 10.9 Esimerkki (2/5): 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=" 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 207

11 10.10 Esimerkki (3/5): 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 208

12 10.11 Esimerkki (4/5): mallinnuksen tavoitteista Mallinnusta voidaankin yleisesti ottaen harjoittaa useasta eri suunnitteluperspektiivistä käsin, esim.: - käsitteellinen (conceptual) - määritys (specification) - toteutus (implementation) Erityisesti, sovelluksen (käsite)mallinnuksen ei tarvitse aina tähdätä implementointiperspektiiviin Erityisesti, esim. prosessien mallinnuksen avulla voidaan yksinkertaisesti tavoitella prosessien parempaa ymmärtämistä, joka edesauttaa niiden kehittämistä ja esim. (informaalia) ohjeistusta, vrt. JHS 152 Prosessien kuvaaminen (ks. esim. Kuva 2) - MATHM RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 209

13 10.12 Esimerkki (5/5): 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, validointi & 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 MATHM RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 210

14 10.13 (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 ">...</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, " ", jne.). Termin arvo voi yleisesti olla myös esim. identifiointitunnus (esim. ISBN tai DOI) MATHM RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 211

15 10.14 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 212

16 10.15 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 213

17 10.16 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 214

18 10.17 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ää huomattavaa sovellusosaamista, esimerkiksi - yleinen suomalainen asiasanasto (YSA, ks. sisältää 62 asiasanaryhmää; yhdessä ryhmässä voi olla satoja asiasanoja; ks. myös ONKI-palvelu ja YSO - eduskunnan kirjaston asiasanasto (EKS, ks. sisältää 39 päätason asiasanaryhmää; luokittelu voi edellyttää esim. juridista osaamista - Nasan asiasanasto (ks. 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 215

19 10.18 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 216

20 10.19 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 217

21 10.20 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. 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. - esim. RDF/XML, ks. MATHM RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 218

22 10.21 JHS 143 Suositus JHS 143 Asiakirjojen kuvailun ja hallinnan metatiedot määrittelee julkisen hallinnon asiakirjojen hallinnassa ja julkaisemisessa tarvittavia metatietoja (Suomessa), ks. 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 219

23 10.22 Skeemojen ja käsitemallien soveltaminen Kun tavoitteena on tiedon semanttinen yhdistely eri lähteistä, on omassa mallinnuksessa keskeistä tunnettujen kuvailusanastojen hyödyntäminen Käytännöllinen strategia on sama kuin rakenteisten dokumenttien (tyyppien) suunnittelun yhteydessä: - mallinnetaan sovelluksen tieto suhteessa käyttötapauksiin ja tekniikkaan - selvitetään olemassa olevat vastaavat sovellukset - sovelletaan (vapaasti) saatavilla olevia sanastoja (yms.) mahdollisimman laajasti tai selvitetään eri sanastojen kuvailu toisikseen (esim. ns. kommunikaatiosanastojen/-ontologioiden kautta) Esimerkkejä (hae kiinnostavia otsikoita esim. Googlella) MATHM RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 220

24 10.23 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 "osioista" Rämettyminen yms. on usein seurausta versiointikäytännön puutteista MATHM RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 221

25 10.24 Pari sanaa versioinnista (2/4): versiopuu Versioita merkitään yleensä numeroin, tuloksena on ns. versio"puu" (revisiopuu) (tai: juokseva numero) - 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 julkaisunumeroa (tai versionumeroa) ja numero 3 revisionumeroa (tai tasonumeroa) - julkaisunumeron vaihtuminen ("uusi revisio") on merkki "suuresta muutoksesta" (yhteensopivuus?) - revisionumeron vaihtuminen on merkki "pienestä muutoksesta" Versiointi voi siis haarautua: esim ja MATHM RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 222

26 10.25 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 RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 223

27 10.26 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) Suosittuja ilmaisia versionhallintajärjestelmiä ovat SVN (Subversion) ja CVS (Concurrent Versions System) - ja Ks. myös esim. WebDAV (Web-based Distributed Authoring and Versioning) - mukana siis myös hajautetun ylläpidon teema - ks. ja MATHM RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 224

28 10.27 Lopuksi (jäitä hattuun) Tekninen termistö vaihtelee hieman metatiedoista puhuttaessa (esim. "elementti", "merkintäjärjestelmä", jne.) Tervehenkinen minimalismi on (taas kerran) arvossaan (meta)tiedoista puhuttaessa ja prosesseja suunnitelatessa: konkreettiset käyttötapaukset ja hallittu laajentaminen (muista keräämisen hinta, oikeellisuus ja ylläpidon kustannukset)..."ennakoimattomat sovellukset" ("kaikenlainen lisätieto varmuuden vuoksi" saattaa olla ok mutta vain jos ilmaista tai jos tietokone kirjaa) Onnistunut suunnittelu on tyypillisesti seurausta esitutkimuksesta joka tarkastelee koko tiedon hallintaprosessia realistisella otteella (ml. ihmiset ) Myös versiointia kannattaa miettiä ajoissa vaikka tulos olisikin vain attribuuttipari (!) (versioitavan-resurssin-tunnistenimi, versio) dokumenteissa MATHM RAKENTEISTEN DOKUMENTTIEN JATKOKURSSI (syksy 2009) - ON 225