Rakenteisten dokumenttien jatkokurssi, syksy 2006 MATHM-57200 Rakenteisten dokumenttien jatkokurssi, 5 op opetetaan syksyn 1-2 periodeilla Kotisivu: http://matriisi.ee.tut.fi/hmopetus/rdj/index.html Luennot: TI 10-12 ja TO 10-12, TB216 (Huom! muutoksia luvassa) Harjoitukset: KE 8:30-10, TO 8:30-10, salissa Sb204 (1. harj viikolla 36!) Suoritustapa: Luennot, harjoitukset ja tentti. Pieni harjoitustyö (P2). Porkkanapisteitä jaossa. (ilmoittaudu kurssille oinfossa!) Opettaja: Ossi Nykänen, TD303, vastaanotto to 13-14 Assistentti: ossi.nykanen@tut.fi Jaakko Salonen, jaakko.t.salonen@tut.fi 1
1 Johdanto Rakenteinen dokumentaatio tarjoaa puitteet tiedon käyttökelpoiselle esitystavalle (vrt. ). Tiedon määrällinen kasvu edellyttää lisäpanostusta tiedon tarkoituksenmukaiseen mallintamiseen ja kuvailuun. Näillä pyritään tyypillisesti tukemaan tiedonhakua, eri tietolähteiden lähteistä peräisin olevan tiedon pätevää semanttista yhdistämistä ja siten esim. tietämyksen (knowledge) tasolla operoivien sovellusten toimintaa (läh. päättely yms. tietomallissa välttämättä päteviin ominaisuuksiin vedoten). Pyrkimys tiedonhallinnan automatisointiin johtaa järjestelmien tarkasteluun näitä kuvaavien tieto- ja käsitemallien tasolla (vrt. viestiformaatti vs. käsitemalli). Tietomallien voidaan tulkita joko "vain" ohjaavan suunnittelijan työtä, tai vaihtoehtoisesti ne pyritään myös osin (loogisesti) formalisoimaan sopivan kuvailujärjestelmän suhteen. Teknisten menetelmien kirjo toisinaan hämärtää tietorakenteiden ja tiedon mallinnukseen tähtäävien menetelmien eroja sovelluksissa. Käytännössä erot näkyvät yleensä sovellusten rajauksessa ja mallintamisen primitiiveissä sekä teknisen toteutuksen laadussa. Sovelluskenttää voidaan lähestyä useista näkökulmista, eri menetelmiin nojautuen. Nyt tarkastelemme lähinnä yleisesti tunnettuja menetelmiä ja välineitä joilla on konkreettista merkitystä tietoteknisten sovellusten näkökulmasta (-perhe, Semanttinen Web). 2
1.1 Opintojakson suoritustapa Arvosanan määrää lopputentti (4 * 6 pts = 24 pts). Hyvää kurssiarvosanaa voi varmistella keräämällä porkkanapisteitä kurssin aikana. arvosana 0 pistemäärä 0-10 1 2 3 4 5 11-13 14-16 17-19 20-21 22-24 Mikäli tenttipistemäärä on riittävän suuri ja porkkanapisteitä on kertynyt edullisesti, huonoimman tenttitehtävän pistesaalis korvataan maksimissaan kuudella porkkanapisteellä. Porkkanapisteitä saa tekemällä erikseen merkittyjä harjoitustehtäviä yms. Porkkanapisteiden jakoperuste on opiskelijan oma aktiivisuus ja asioiden opiskelu silloin kun niitä opetetaan. Kurssiin liittyvä pieni harjoitustyö arvostellaan asteikolla hylätty/hyväksytty. (Toteutus periodilla 2.) Huom. Porkkanapisteiden lähtökohta on läsnäolo: suorituksia ei saa delegoida toisen merkittäväksi, eikä lähettää sähköpostitse tms. 3
1.2 Välisoitto Tekniikka = välineitä ja mahdollisuuksia Tavoite on tehostaa ja rajata ihmisten käsityötä...mutta kaikkiin pulmiin ei löydy "teknistä ratkaisua" (käytännöt & ns. vaikeat ongelmat) 4
1.3 Opintojakson sisältö Tällä opintojaksolla "Rakenteisten dokumenttien jatkokurssi" puhutaan mm. seuraavista asioista: - Tiedon mallinnus sen käsittelyn näkökulmasta - Schema - -kyselykielet (XQuery) - Tieto ja metatieto - Semanttinen Web (SW) ja kuvailutiedon idea - RDF-tekniikoista ja -sovelluksista - RDF-kyselykielistä (RDQL yms.) - Käsitemalleista/ontologioista ja säännöistä (OWL) - Sovelluksia ja esimerkkejä, erityiskysymyksiä (tieto ja tietämys, päättely) 5
1.4 Lyhenteitä ensi hätään... lisää luvassa ASCII (American Standard Code for Information Interchange) DTD (Document Type Definition) OWL (Web Ontology Language) RDF (Resource Description Framework) RDQL (RDF Query Language) SW (Semantic Web) (Extensible Markup Language) XQuery ( Query Language) 6
1.5 Miksi rakenteisesta dokumentaatiosta puhutaan (taas)? Tieto-/käsitemalli (?) Tiedon ulkoistaminen Tietorakenteen kuvailutieto 7
1.6 Everywhere? (Lue: mihin tämä tarjoaa ratkaisun?)...pelkkä yhteensopiva tietorakenne (ASCII, Unicode,,...) ei siis oikeasti riitä sovellusten semantiikka ja taustaprosessit pitää myös saada järkevästi sovitettua yhteen (yhteensopivien pelisääntöjen ja kuvailun keinoin) 8
1.7 Tekniikkaa sovellusintegraation näkökulmasta: 2 tasoa & database systems legacy systems scientific data & measurements project and working group management systems adapter adapter adapter adapter RDF storage queries description rules... modelling, interpreting, and processing data 9
1.8 Kertaus, rakenteiset dokumentit & 101 -dokumentti, merkkauskielioppi ja dokumentin jäsennyspuu <?xml version="1.0" encoding="iso-8859-1"?> <purchaseorder orderdate="1999-10-20"> <shipto country="us" VAT="yes"> <name>alice Smith</name> <address>123 Maple Street, Mill Valley, CA 90952</address> </shipto> <item>kenwood Eon Tt 900</item> </purchaseorder> Dokumentin tyyppi, tyypin määritys ja DTD-kieli Nimiavaruudet -perhe & -sovellusohjelmointi 10
1.9 Kertaus, tiedon saavutettavuus 101 Lippmann's Switch Tietojenkäsittelyn vaikeita ongelmia - puheentunnistus - hakutehtävien/algoritmien kompleksisuus (kombinatorinen räjähdys) - tekoäly, arkipäättely -... Content Description Kun pyritään harjoittamaan tietojenkäsittelyä tiedon tasolla, törmätään nopeasti tietojenkäsittelyn vaikeisiin ongelmiin - erityisesti: mallinnuksen ja epätäydellisen tiedon esittämisen ja yhdistelyn haasteet vs. pätevän päättelyn haasteet Time 11
1.10 Tiedonsiirto, dokumentin tyyppi ja tietomalli (1/2) Dokumentin tyyppi toimii rajoitteena...joka rajaa tarkasteltavan tietorakenteen joksikin tietyksi ja tarjoaa osin myös selityksen dokumentin eri osille -...näin on erityisesti mahdollista ohjelmoida käsittelijä tai muuten tulkita tietoa Vain yhteinen sopimus tyyppimäärittelykielestä ja sen käsitteistä (esim. DTD) mahdollistaa käsittelijöiden rakentamisen ko. rajapintaan vedoten typedef Provider instance Requestor 12
1.11 Tiedonsiirto, dokumentin tyyppi ja tietomalli (2/2) Tyyppimäärittelyn taustalta löytyy käytännössä myös sovelluksen toiminnallisuutta, rakennetta ja käyttöä koskevaa suunnittelua ja tietoa -...joka ohjaa tyyppimäärittelyn toteutusta ja käyttöä -...mutta ei kokonaisuudessaan käy ilmi tyyppimäärittelystä itsestään (joka ilmenee "vain" rajapintana) Esimerkki, dokumenttienhallinnan (DH) "lisätietoja": - paikallistaminen, sisällönkuvailu, käyttöedellytykset, konteksti, elinkaari Tietomallia, käsittelyprosessia yms. voidaan toki myös kuvata dokumentteina; tällöin tarvitaan sopimus mallinnuskielestä ja sen käsitteistä (esim. RDF) - huomaa kuitenkin että sekä "tyyppimäärittelykieli" että "mallinnuskieli" tuottavat lopulta vain dataa tietokoneiden käsiteltäväksi 13
1.12 Esimerkki, "tieto ja metatieto" Kohdesovelluksen tietyn osan käsitemalli (esim. dokumenttienhallinnan metatiedot löydettävyyteen ja tilaan liittyen): "(Reaali)sovellus":... Tietyntyyppisen yksittäisen dokumentin käsittelyä ohjaava tietorakenne: typedef Provider instance Requestor 14
1.13 Huomioita: rajoitteet vs. kuvailu Huomaa tiedon mallintamisen kaksi toisiaan täydentävää näkökulmaa: Tiedon mallinnus ("proseduraalisten") rajoitteiden keinoin - "elementin luokitus arvo voi vain olla jokin seuraavista: lasku, muistio, lähete" - tavoite: validointi ("arvoa saate ei hyväksytä") Tiedon mallinnus ("loogisen") kuvailun keinoin - "lasku on kirjanpidon asiakirja" - tavoite: luokittelu ja päättely ("Kirjanpidon asiakirjat pitää arkistoida yrityksessä. Lasku on kirjanpidon asiakirja joten myös se pitää arkistoida") Käytännössä yo. näkökulmat saattavat mennä hyvin helposti sekaisin jo hyvin yksinkertaisten metatietojen tapauksessa -...koska kaikki syötetty tieto pitää toki aina "validoida", jotta sitä voisi järkevästi soveltaa (ja esim. harjoittaa päättelyä ko. tiedon varassa) 15