Dokumenttien tietosisällön hallinta

Transkriptio

1 Dokumenttien hallinta & Tietojohtaminen 3. rinnakkaisteema: Dokumenttien tietosisällön hallinta Ossi Nykänen Tampereen teknillinen yliopisto (TTY), Digitaalisen median instituutti (DMI), W3C Suomen toimisto

2 Konf. 3. teema: Dokumenttien tietosisällön hallinta Dokumenttien tietosisällön hallinta perustuu kykyyn ennakoida ja hallinta tietosisältöjä tuottavia ja niitä hyödyntäviä (osin tietoteknisiä) prosesseja Hyvä kysymys on tietenkin se, miten tämä tapahtuu Konferenssi: keskiviikko Rakenteiset dokumentit ja sisällönhallinta Mediasisällön hallinta Alma Mediassa Dokumenttienhallintajärjestelmän tekninen toteutus Konferenssi: torstai Metatieto asiakirjojen hallinnan välineenä Arkistolaitos ja case SÄHKE Väestörekisterikeskus ja case henkilökortti ja allekirjoitus Dokumenttien hallinnan juridiikkaa 2

3 Rakenteiset dokumentit ja sisällönhallinta

4 Esitelmä Hyvin lyhyt versio: Rakenteinen dokumentaatio on yleispätevä menetelmä tietosisällön hallintaan tietoteknisiä välineitä käyttäen. World Wide Web Consortium kehittää universaaleja teknologioita joille löytyy runsaasti sovelluksia myös rakenteisessa sisällönhallinnassa Pidempi versio, otsikoita: Konteksti: World Wide Web Consortium Lähtökohta: rakenteinen dokumentaatio osana sisällönhallintaa Miten: rakenteiset dokumentit, peruskäsitteet Isommat ideat: tuotantoprosessit ja metatieto Lopuksi: W3C-suositukset dokumenttienhallinnassa Esityksen tavoite: Esittää rakenteisen dokumentaation perusidea, luonnehtia dokumentaatioprosessia ja sijoittaa aihepiirin tekniset W3Csuositukset kontekstiinsa 4

5 Osa 1/6: Konteksti World Wide Web Consortium...ja sen toiminta W3C-suositukset = yleisesti käyttökelpoisia (Web-) teknologioita 5

6 World Wide Web Consortium (W3C) W3C kehittää yhteensopivia (Web-)teknologioita (spesifikaatioita, ohjeita ja ohjelmistoja) ja siten ohjaa Webin kehittymistä täyteen mittaansa 3 päätstoa, 14 aluetstoa, n. 400 jäsenorganisaatiota Jäseneksi? ks. 6

7 W3C:n olemus ja tuotteet Vaikutusvaltainen foorumi Suositukset XML-perhe, XHTML-perhe, SVG, RDF, Semanttinen Web, Webpalvelut... Ohjelmistot Validaattorit, testiaineistot, open source,... Ohjeet ja yhteydet WAI, aluetoimistot,... Jäsenorganisaatiot 5 Is : Information, Image, Involvement, Influence, and Impact A B 7

8 W3C:n (nykyiset) toimialueet ja aktiviteetit (Ks. 8

9 Aasinsilta dokumenttien hallintaan W3C:n työllä ja dokumenttien hallinnalla on selviä yhtymäkohtia rakenteiset dokumenttien käsittely (XML-perhe, sis. erit. XML 1.0, CSS, XSL/FO, XSLT, XLink, XHTML,...), grafiikka (PNG, SVG, SMIL), infrastruktuuri (ohjelmointi, jakelu, julkaiseminen, metatiedot, autentikointi,...)... XML 5v W3C:llä ei kuitenkaan ole Content Management - aktiviteettiä; monet W3C-suositukset kuitenkin käytännössä pohjustavat tähän liittyvää työtä W3C luo yhteistä perustaa jonka varassa yhteensopivia ja (teknisesti) järkeviä sovelluksia voidaan toteuttaa 9

10 Osa 2/6: Lähtökohta Miksi (tavoitteet) Teknologia vai prosessi (lue: prosessi) 10

11 Tyypillisiä tavoitteita: tehokkuus ja joustavuus Dokumenttien hallinnan tehostaminen automatisointi ja integrointi Monta sovellusta samalle sisällölle: prosessorit, tyyli, alustat,...? Sovellus #1 Sovellus #2?? (rakenteinen sisältö)? Sovellus #3 11

12 Näkökulma: sisällönhallinta = prosessien hallintaa sisällön tuotantoprosessi sisällön (tekninen) käsittelyprosessi sisällön hyödyntämisprosessi sisällönhallinta sisällön tuotantoprosessi sisällön (tekninen) käsittelyprosessi sisällön hyödyntämisprosessi sisällönhallinta 12

13 Osa 3/6: Muistisääntöjä Dokumenttituotannosta sisällönhallintaan 13

14 Sisällöntuotannon yleisiä totuuksia Sisällöntuotanto on hidasta ja kallista Ohjelmistot vaihtuvat nopeammin kuin niillä tuotetut sisällöt Tekijät vaihtuvat nopeammin kuin sisällöt uudistuvat 14

15 ...ja niiden ilmeisiä seuraamuksia Sisällöntuotanto on hidasta ja kallista tuotantotyö pitää suunnitella huolella kerran tuotettu sisältö tulee tallettaa helposti hallittavassa ja ylläpidettävässä muodossa ( yhteensopivuus, rakenteisuus, muokattavuus) Ohjelmistot vaihtuvat nopeammin kuin niillä tuotetut sisällöt tiedon talletusmuoto ei saa vanhentua sitoutuminen yhden valmistajan tuotteisiin/tiedostotyyppiin on riskialtista Tekijät vaihtuvat nopeammin kuin sisällöt uudistuvat tekijänoikeuksista yms. pelisäännöistä on sovittava alusta asti työn dokumentoinnista on huolehdittava ajoissa...koskee myös prosessien dokumentointia 15

16 Suunnittelu = prosessien ennakointia Sisällönhallinnan suurimmat ongelmat syntyvät tuotannon vääristä odotuksista ( lyhytnäköisyys ) kunhan vain saadaan tietokoneelle -ajattelu ei toimi! Hyvä tuotantoprosessi on huolellisen suunnittelun tulos suunnittelun lähtökohta on työn lopputuloksena syntyvien tuotteiden määrittely...suunnittelun perusedellytys on tuotantoprosessin eri vaiheiden tuntemus (ja suhteuttaminen organisaatioon) tekninen kirjoittaminen (menetelmät ja välineet) formatointi, taitto, print yms. (menetelmät ja välineet) jakelu, ylläpito ja päivitykset (menetelmät ja välineet) Reunaehdot, rajoitteet ja rajapinnat profilointi? on-line koostaminen? hajautus? (tuotanto/hyödyntäminen) arkistointi? numeerinen laskenta? 16

17 ...johtopäätöksiä ja teknisiä (?) ratkaisuja <_XML /> to the Rescue? (...mutta miksi?...ja miten?) 17

18 Osa 4/6: Miten? Rakenteiset dokumentit Conceptualisation Problem-solving Realisation Problem Solution Inception Elaboration Construction Transition Development Cycle Product Generation 18

19 Rakenteinen dokumentti = tietorakenne Lähtökohta tiedon ja sen sovellusten erottelu merkkaus, sanasto, sanaston kielioppi ja sovellus Hyödytön sellaisenaan -- prosessointi sovelluksessa Kaikki data ei rakenteellista -- mukana mediaobjekteja tyyppi käsikirjoitus Sovellus / prosessointi Mediaobjektit 19

20 Esimerkki rakenteisesta dokumentista <doc><title>xml 5 vuotta </title> <body> Paljon onnea XML! </body></doc> Sovellus / prosessointi <?xml version= 1.0?> <xsl:stylesheet... XML 5 vuotta Paljon onnea XML! esitys rakenteinen lähdedokumentti (käsikirjoitus) tyyli (formatointi) kuva (mediaobjekti) 20

21 Rakenteisuuden suunnittelun lähtökohta Rakenteisten dokumenttien (tiedon) käsittelyyn liittyy aina kaksi toisiaan täydentävää näkökulmaa tiedon mallintaminen ja sen esittäminen sovelluksessa (yleisemmin: tulkinta) prosessointi Sää jatkuu

22 Tiedon mallintaminen vs. esittäminen Tiedon mallintamisen perustehtävä on tiedon kuvailurakenteen (skeeman) määrittäminen sen prosessoinnin näkökulmasta haaste: mallin rikkaus vs. käytön taloudellisuus Tiedon esittämisen perustehtävä on sovelluksen sisällöllisen tavoitteen toteuttaminen haaste: ylläpito ja versiointi Rakenteinen dokumentaatio erottelee näkökulmat sekä teknisesti että työvaiheiden tasolla: molemmat on otettava suunnittelussa huomioon 22

23 Sisällönhallinta = (teknisten) prosessien ohjaamista Ensimmäinen tehtävä: hyvän lopputuotteen määrittely sisällöllisesti tyydyttävä (tehtävä ja tavoitteet) teknisesti toteuttamiskelpoinen (reunaehdot) Puhtaasti teknologiavetoinen lähestymistapa johtaa väärään ratkaisuun ( tehdäänpäs XHTML 1.0:lla ) mitä spesifimpiä sisällölliset tavoitteet ovat, sen parempi... Sovellus / prosessointi Sovellus / prosessointi Mitä halutaan JA osataan JA on varaa tehdä 23

24 Rakenteisuuden suunnittelun eväitä Yleistäminen kuvaa tieto luonnollisten käsitteiden avulla (mallinnus) irrota sovelluskohtainen tieto käsikirjoituksista (vrt. tyylit) tunnista eri prosessien väliset rajapinnat (abstrahointi) Jako komponentteihin tunnista dokumenttihierarkia ja nimeä sen osat (organisointi) kuvaa kaikki mediaobjektit käsikirjoituksen osaksi (kääreet) Kartoitukset ja kokeilut määrittele lopputuote tarkasti (tuotannon tavoite) testaa kaikki prosessien rajapinnat (tuotantojärjestelmä) kerää kokemuksia ja kehitä (kehitys & sitouttaminen) mukauta organisaatiolle sopivaan muotoon (käyttöönotto) 24

25 Riskienhallinta Määrittelytekniset riskit kuultiinko kaikkien prosessien edustajia? unohtuiko oleellisia tavoitteita (ylläpito, arkistointi, oikeudet, muutokset, versiointi, jatkokehitys, yhteensopivuus(!),...)? Poliittiset riskit ovatko esitetyt tavoitteet ja resurssit todellisia? Tiedolliset ja taidolliset riskit onko tietotaitoa, entä kun Erkki Ekspertti vaihtaa työpaikkaa? kuka kouluttaa soveltajat muuttuuko työkulttuuri? Teknologiaan liittyvät riskit onko tekniikka kypsää? toteuttavat työvälineet halutut kaikki aiotut skenaariot? sopivatko ratkaisut tuotantokäyttöön (ilmaisohjelmat...)? 25

26 Osa 5/6: Isommat ideat Tuotantoprosessit Conceptualisation Problem-solving Realisation Problem Solution Inception Elaboration Construction Transition Development Cycle Product Generation 26

27 Monikanavajulkaiseminen, esimerkki Sovellus #1 PDF XML 1.0 SVG PNG... XSL/FO käsikirjoitus XSLT Sovellus #2 CSS Mediaobjektit XLink XSLT CSS Sovellus #3 27

28 Web Content Management = arkkitehtuuri Sama perusidea, prosessi ja käyttäjät mukaan kuvaan Kanavat kuvaukset Prosessi Mediapalvelu Produktio Koostaminen mediaobjektit Dokumenttipalvelu Sisällöntuotantoprosessit Sisällöntuotantoprosessit Monimedia Laskutus Metatiedot Esittäminen Palvelualusta näkymät Käyttäjien seuranta Oikeuksien hallinta Personointi, media Välineet ja palvelut (työkalujen tasolla) 28

29 Metatieto sisällönhallinnan osana Dokumenttistandardit eivät automaattisesti koodaa/tue niiden tuotamisen prosesseja -- tarvitaan lisätietoja prosessien ja työvaiheiden dokumentointi tuotantoprosessin, sovelluksen ja lähdeaineiston metatiedot prosessin dokumentointi Käsikirjoitukseen liittyvä metatieto käsikirjoitus Tuotantoprosessiin liittyvä metatieto Mediaobjekteihin liittyvä metatieto Mediaobjektit Sovellukseen liittyvä metatieto 29

30 Metatieto ja sen sovellukset Yksinkertaiset sovellukset haut, näkymät (profilointi) ja tiedon ulkoistaminen Edistyneemmät sovellukset integrointi, päättely, analysointi, business-äly yms. Kaksi lähestymistapaa attribuuttipohjainen metatieto tiettyihin sovelluksiin kohdennetut ontologiat Tavoite: lisätä tiedonhallinnan automatisointia Mallinnuksen rooli tietorakenne vs. tieto: <html> <head> <body>... persons:ossi hobbies:favourite-movie movies:cast-away 30

31 Mikä on metatietoa? Metatieto on tietoa jota ei löydy tai jota ei voida helposti poimia käsikirjoituksista tms. Metatieto ja tieto -erottelua ei ole pakko lainkaan tehdä dokumenttien tyyppitiedot tekstiformaatti ja ko. formaatin kontrolloitu sanasto lisätty, kuvaileva (meta)tieto metatiedon käyttöä ohjaava skeema (tms.) sovellusalueen ontologia jne. tyyppi käsikirjoitus Mediaobjektit viimeksi muokattu: Se päivämäärä jolloin tietosisältö viimeksi muuttui, tyyppi: xsd:date paperikoneen käyttöohjeen tuotantoprosessi 31

32 Yksinkertaistus: sisällöntuotantoprosessi General processing based on the declarative domain concepts Specific processing based on the publishing media Authoring [guides] Manuscript schema [produces] 0..n [produces] Retouch Media object Manuscript Select media for deliverables [media X] Publishing pre-processing [produces] Formatting objects [used for] Formatting [generates] [enhanced with expicit] [guided by] metadata domain ontology Product Postprocessing Authoring deliverables in format X 32

33 ...sarjallistaaksesi jäsennetyn entiteetin, paina F3 Tuote löytää käyttäjänsä osuvan mielikuvan perusteella sähköposti toimii käsitteellisesti posti -metaforan varassa, mutta käyttöliittymän takana toteutus on hyvin erilainen Sama pätee tuotannon organisointiin ja ohjeistukseen esim. teknisen kirjoittamisen ja ylläpidon työtehtävät Tuotantoprosessin ohjeistuksen käsitteiden ei tarvitse noudattaa prosessin teknistä suunnittelua! XML, XSLT,... optimiratkaisu on peilata käsitteet ja työvaiheet oman organisaation työkulttuuriin kautta Ekstraspektio inkrementoi adekvaattia ekspertiisiä +([:-) 33

34 Osa 6/6: Lopuksi W3C-suositukset Standardien hyötynäkökohtia Liitteet 34

35 W3C-suositukset ja dokumenttien hallinta Sisällönhallinta & W3C-aktiviteetit, yhtymäkohtia: I18N, URI, XML, XLink, Device Independece, Graphics, XHTML, Math, Multimodal Interaction, Style, Synchronized multimedia, Voice Browser, XForms, Semantic Web, Web Services, XML Encryption, XML Signature, WAI Technical Activity,... Suuntaa-antava piirre: standardinomaisuus W3C-suositukset eivät (suoraan) osoita prosesseja jotka esim. tuottavat hyviä sovelluksia, vaan määrittelevät prosessien lopputuotteen tai kahden prosessin rajapinnan SVG 1.1 -dokumentti julkaisuskenaario SVG Mobile 35

36 Yhteensopivuus syntyy kokonaisuudesta 36

37 W3C-suositusten hyötynäkökohtia Valmiiksi mietittyjä rajapintoja ja geneerisiä ratkaisuja Standardeihin nojautuminen yhteensopivuus, pysyvyys ja hallittavuus, käyttöehdot laajempia markkinoita, vaihtoehtoisia toimittajia Rakenteisuuden etuja tuotantoprosessin hallinta (sisältö-esitystapa-sovellus) monikanavajulkaiseminen, profiloitavuus, haut, yms. XML-rajapinnan kautta uusia sovelluksia esim. metatiedot, salaus ja allekirjoitukset Välineitä ja 3. osapuolten caseja (joista ottaa oppia)... 37

38 Kiitos! Jäikö joku W3C-asia mietityttämään? Allekirjoittaneen tavoittaa helposti: The bane of my existence is doing things that I know the computer could do for me." Dan Connolly, The XML Revolution 38

39 Liite 1: lisätietoja ja osoitteita eteenpäin W3C (kotisivu) (W3C Suomen toimiston kotisivu) W3C-aktiviteetit (yleiskuva) W3C:n suositukset ja raportit sekä teknistä tietoa (specs) (spec-tietoa jäsennettynä) Jäseneksi!

40 Liite 2: uusia ja tulevia(?) suosituksia Recent RECS MathML Version 2.0 (2nd Edition) XML Events XForms 1.0 Soap 1.2 XPointer SVG 1.1 SVG Tiny, SVG Basic XML Encryption/Decryption XML Signature... Proposed RECS: CC/PP Structs & Vocab 1.0 PNG (2nd Edition) Candidate RECS XForms 1.0 Basic Profile OWL (various) DOM Level 3 Validation, XPath CSS3: TV 1.0, Color, Ruby, Text, Mobile 1.0, Media Queries, Selectors VoiceXML 2.0 XML 1.1, XML Namespaces 1.1 XInclude 1.0 Speech Recognition Grammar 1.0 XML Fragment Interchange Muuta mielenkiintoista WSDL 1.2, XQuery 1.0, XKMS, DOM Level 3, RDF (various),... Lisää, ks. 40

41 Liite 3: Uusinta XML:ää, esimerkki: XForms XML-pohjaiset lomakkeet: XForms (REC ) Ks. HTML:ää monipuolisempi logiikan, esitystavan & datan erottelu XML Schema -tietotyypit & tarkistukset jo paljon toteutuksia, Basic-profiili tulossa täysin XML-pohjainen laiteriippumattomuus, saavutettavuus otettavissa heti käyttöön