-RKGDWXVUDNHQWHLVLLQGRNXPHQWWHLKLQ 5DNHQWHLQHQGRNXPHQWWL= rakenteellinen dokumentti dokumentti, jossa erotetaan toisistaan dokumentin 1)VLVlOW, 2) UDNHQQHja 3) XONRDVX(tai esitystapa) jotakin systemaattista ja yksikäsitteistä menetelmää käyttäen Perusidea: yhden ja saman "tekstinpätkän" merkitys voi vaihdella, riippuen sen "loogisesta" sijainnista dokumentissa (tai lähdetiedostoissa) Erityyppisen tiedon erottaminen toisistaan perustuu koodaus- ja syntaksikäytäntöihin ja sopimuksiin koodausten tulkinnoista - "tiedostotasolla" kaikki koodaus voidaan hyvin tehdä esim. "samannäköisinä" ascii-merkkeinä! Joissakin tapauksissa paitsi asiasisällön rakenne, myös sen ulkoasu (ilmiasu) voidaan käsitteellisesti samaistaa sen merkityksen kanssa (dokumentin parsimisen voidaan ajatella tuottavan muutakin kuin "jotakin katseltavaa")
(VLPHUNNL Oheisessa kuvassa on eritelty dokumentin sisältö, koodaus, rakenne ja ulkoasu 08,6 7,2 5$ (17((1 9$/,17$ Kerron pomolle, että uusi tietokantamme on susi $6,$6,6b//g10bb5,77b0,1(1 8/ 2,6(1 (6,7<6082 '219$/,17$ $6,$6,6b//g1 22'$86 3(1$2< MEMO 1.1.2000 To: Pentti Pomo Fr: Timo Työmies 8XVLWLHWRNDQWDPPH RQVXVL 78/,1 7$ Ilmeisestikin dokumenttien sisältö, rakenne ja ulkoasu voidaan eriyttää vain jos käytetyt välineet sen sallivat (abstraktit dokumentit tai tietokoneiden käyttö)! "työvaiheiden" (0-)1-2-3 erottaminen toisistaan on joskus hyvin vaikeaa!
0LNVLGRNXPHQWLQUDNHQQHSLWllHULNVHHQPHUNLWl" Jos "vapaamuotoista" informaatiota halutaan käsitellä automaattisesti tietokoneella, täytyy käsiteltävän datan rakenne ja merkitys erikseen kuvata, koska tietokone ei automaattisesti ymmärrä sen merkitystä - sama pätee tietenkin myös ihmisiin (joskin ihmiset osaavat tehdä luovia arvauksia) Jotta dataa osattaisiin käsitellä tietona, pitää datan "merkitys" jotenkin esittää datan jakaminen erityyppisiin elementteihin, joiden sisältö ja keskinäinen suhde on hyvin määritelty ( rakenteistaminen) Rakenteistamisen perustehtävä on merkityksellisten tietoelementtien identifiointi valitun VRYHOOXVDOXHHQQlN NXOPDVWD Käytännössä dokumentit sisältävät kuitenkin yleensä myös muitakin ORRJLVLD RVLDkuin "pelkkiä" elementtejä (esim. XML-dokumentti sisältää myös deklaraatioita, kommentteja, merkkiviittauksia ja prosessointiohjeita) "Rakenteistettu tieto" sisältää siis myös PHWDWLHWRD, jota voidaan käyttää hyväksi sekä dokumentteja kirjoittaessa (rakenteen oikeellisuuden varmistaminen) sekä luettaessa (elementtien tunnistaminen)
Tietokoneen ei voida sanoa "ymmärtävän" esim. XML-dokumentin sisällön "merkitystä", sillä dokumenttien validoiminen & parsiminen tapahtuu niiden rakennepuiden muodossa (elementtien sisältö on vain "jotain") Dokumentin rakenteen eksplisiittinen esittäminen mahdollistaa (jopa yksittäisten) dokumenttien käyttämisen tietokantojen tapaan Eksplisiittiset rakennemääritykset helpottavat myös dokumenttien parsimista Viime kädessä se, mitä rakenteistamisella ajetaan takaa, pitää kertoa luonnollisella kielellä "käytetyn merkintäkielen ulkopuolella". Yleensä tämä kerrotaan dokumentoimalla merkkauksessa käytetty skeema, eli tietorakenne - syntaksin määrittely (rakenne ~ V\QWDNVL) - merkityksen määrittely (elementtisanaston kuvaus ~VHPDQWLLNND) - käytön määrittely (sovellusalue ja käyttöesimerkit ~ SUDJPDWLLNND)
0LNVLGRNXPHQWLQXONRDVXKDOXWDDQHURWWDDVHQ UDNHQWHHVWD" Kirjoittaja haluaa keskittyä olennaiseen (tai ainakin hänen pitäisi tehdä niin!) Ulkoasumääritykset eivät yleensä ole yksikäsitteisiä - pelkkään ulkoasulliseen koodaukseen pidättäytyminen joko hukkaa metatietoa tai asettaa kohtuuttoman suuria tarkkuusvaatimuksia ulkoasun suhteen (=epäkäytännöllistä) Aineiston automaattinen käsittely on huomattavasti helpompaa (tai jopa yksin mahdollista) kun tietorakenteet on kuvattu niiden "merkityksen" kautta Toisinaan myös yhdestä ja samasta lähdedokumentista halutaan tuottaa vähällä vaivalla erilaisia esitysversioita tai "esiintymiä" (KXRPDDHULW\LVHVWL VXRPHQNLHOLVHQVDQDQHVLLQW\PlHULPHUNLW\NVHWMDWNRVVDGRFXPHQWLQVWDQFH SUHVHQWDWLRQLQVWDQFH) Ulkoasun erottaminen rakenteesta ei kuitenkaan DLQDole helppoa tai edes tarkoituksenmukaista!
<OHLVNl\WW LVHWUDNHQQHPllULWWHO\W Yleensä halutaan käsitellä useita tietyn rakenteen omaavia dokumentteja, tällöin päädytään samantyyppisten dokumenttien luokkaan Samantyyppisten dokumentin rakennemäärittelyn käytetty menetelmä (esim. merkintäkieli) voidaan edelleen standardoida (esim. HTML), minkä seurauksena esim. dokumenttien hallinta, luettavuus, laitteistoriippumattomuus ja siirrettävyys paranevat (jos standardia noudatetaan!) Myös merkintäkielten määrittelyyn käytetty menetelmä voidaan standardoida, tällöin tuloksena on standardi kuvauskielten määrittämiseen (esim. SGML tai XML) "Muiden" kehittämien & laajemmin käyttöönotettujen standardien hyödyntämisen merkittävänä puolena voidaan pitää myös - saatavilla on valmiiksi mietittyjä rakennemäärittelyjä ja ohjelmia - eri valmistajien ohjelmistokomponenttien yhteiskäyttö helpottuu
5DNHQWHHWWRPDWGRNXPHQWLW" Kannattaa huomata, että tietokoneiden näkökulmasta "rakenteettomia dokumentteja" ei ole olemassakaan - "rakenteisuudessa" on siis kyse lähinnä - kenen tai minkä QlN NXOPDVWDrakenteita koodataan & kuka koodauksen "ymmärtää" - miten yksityiskohtaisesti ja PLWHQrakenne esitetään Tietokoneen näkökulmasta rakenteisuus tarkoittaa käytännössä sitä, että tietoa lukeva järjestelmä osaa sijoittaa luetun atomaarisen tiedon tyyppiään vastaavaan kohtaan omassa tietorakenteessaan (tai osaa sivuuttaa sen tarpeettomana) Huomaa: DLNNLNRPPXQLNRLQWLHGHOO\WWllVRYLWWXMDWLHWRUDNHQWHLWD; perinteisten tietokoneohjelmien tapauksessa näiden rakenteiden on oltava yksikäsitteisiä Rakenteellisuus ei kuitenkaan ole vain staattisten dokumenttien ominaisuus; esimerkiksi yksinkertaiset sähköpostiviestit koodataan SMTP:n (Simple Mail Transfer Protocol) mukaisesti tarkkaa etikettiä (so. protokollaa) noudattaen (Jos SMTP muuten vain kiinnostaa, ks. http://www.imc.org/rfc821 )
(VLPHUNNL6073NHVNXVWHOXVWD Seuraavassa lähetetään postia SMTP-palvelun avulla: R: 250 OK R: 250 OK R: 550 No such user here R: 250 OK R: 354 Start mail input; end with <CRLF>.<CRLF> R: 250 OK Huomioita: jotta hommassa olisi järkeä, vastaanottajan pitää "tunnistaa" mitä lähettäjältä on tulossa, SMTP ei koodaa "varsinaisen asiasisällön" rakennetta lainkaan (pelkkää ascii-"tekstiä") eikä SHUXV6073YLHVWLVVlHLYRLROOD PHUNNLMRQRD&5/)!&5/)!!
<OHLVNl\WW LVHWW\\OLXONRDVXPllULWWHO\W Samalla tavoin kuin dokumenttien rakenteen määrittämiseen käytetty menetelmä voidaan standardoida, voidaan pyrkiä standardoimaan myös dokumenttien ulkoasun (esitystavan) kuvausmenetelmät Soveltajalla vaihtoehtoina ovat: - olemassaolevan "standardien" formatointi, taitto, tyyli, tms. -kielen hyödyntäminen (TeX, RTF, HTML, CSS, PDF, DSSSL, postscript,...) - kokonaan oman ulkoasu/formatointimäärityksen kehittäminen Hyödyt ja haitat ilmeisiä: - annettujen tyyli/formatointikielten opiskelu ja niiden puutteiden kanssa eläminen, mutta "valmiit" selaimet, tulostinajurit,??-komponentit,... - kokonaan oman & kaikenkattavan ulkoasumäärityksen kehittäminen, mutta aivan kaiken suunnitteleminen & toteuttaminen itse Kannattaa kuitenkin muistaa, että kaikki työ ei tähtää "julkaisutoimintaan" - dokumentteja voidaan käyttää myös datakorttien ja tietokantojen tapaan
'RNXPHQWLQORRJLQHQMDI\\VLQHQUDNHQQH Rakenteellisista dokumenteista erotetaan yleensä käsitteellisesti: /RRJLQHQUDNHQQH datan ja metadatan jäsentäminen yksikäsitteisesti luettavaan muotoon merkkauksen ([markup]) avulla. )\\VLQHQUDNHQQH dokumentin "konkreettisesti" muodostavat osat, ns. entiteetit (esim. tiedostot tms. objektit) Ulkoasun määrittely jätetään yleensä esitystapamäärityksen ja siten tavallaan prosessointijärjestelmän huoleksi (näin voi tietenkin tehdä VAIN jos esitystavan määritykseen käytettävä koodaus on riittävän vahvaa) Termien selvennyksiä: LHOLRSSLPllULWWHO\= kokoelma nimiä, symboleita ja sääntöjä, joka määrittelee ns. RLNHLQPXRGRVWHWWXMHQdokumenttien laillisen "yleisrakenteen" (vrt. läh. kielen syntaksi tai kielioppi) Dokumentin W\\SSLPllULWWHO\= valitun kieliopin puitteissa tehtävä määrittely, jolla tarkasteltavien dokumenttien looginen rakenne rajataan joksikin tietyksi (vrt. läh. erisnimien ja lauserakenteiden valinta)
'RNXPHQWWLMlUMHVWHOPLVWl Oheisessa kuvassa ovat esillä tyypillisen GRNXPHQWWLMlUMHVWHOPlQeri osat tai komponentit (kaikkia ei välttämättä aina tarvita, osa taas otetaan käyttöön vasta "tarvittaessa", mahdollisesti esim. verkon kautta): '2 80(177, 67$1'$5', '2 80(177, 3526(6625, 2+'( 629(//86 '2 80(177, 7,(72 $17$ 7<<33, 0bb5,7<6 7,(72 $17$ 2%-( 7, 7,(72 $17$ '2 80(177, (',725, 2%-( 7, (',725, 3$56(5, 9$/,'$$7725, 8/ 2,1(1 b<77g,/0,$687 7<</, 7,(72 $17$ Käytännössä tarvitaan siis 1) sopimuksia, 2) ohjelmistoja, 3) teknisiä alustoja, 4) oheisstandardeja sekä 5) sovelluksia ja käyttötapoja