7LHGRVWRWGRNXPHQWLWWLHWR KPHGLD Tietokoneet käsittelevät tietoa WLHGRVWRMHQmuodossa Tietokoneiden yhteydessä GRNXPHQWLOODWDUNRLWHWDDQWLHGRVWRMHQDYXOOD HVLWHWWlYllDVLDNRNRQDLVXXWWD, joka jäsennetään kokonaisuudeksi joko käyttäjän tai tietoa käsittelevät ohjelmiston näkökulmasta Jokaiseen dokumenttiin liittyy - VLVlOW, UDNHQQHja HVLW\VWDSD (enemmän tai väh. toisiinsa sekoittuneina) Tietokoneiden tapauksessa nämä voidaan teknisesti erottaa (ainakin osittain) toisistaan, esim. seuraavasti 1) dokumentin sisältö kirjoitetaan suomen kielellä ja esitetään tekstimuotoisena 2) dokumentin looginen rakenne (otsikot, kappaleet, lainaukset, ) koodataan HTML-elementeiksi HTML-koodauksen avulla 3) dokumentin ulkoasu (esitystapa) valitaan määrittelemällä em.elementeille ulkoasu esim. CSS-sääntöjen muodossa, WYSIWYG-tyyliin formatointiohjeina tai jätetään kokonaan dokumenttia esittävän ohjelman huoleksi
(VLPHUNNL+70/GRNXPHQWWL Seuraava dokumentti koostuu kolmesta tiedostosta esim.html (sisältö & rakenne), kuva.gif (dokumenttiin upotettu kuva) ja esim.css (ulkoasun määrittely): tiedosto esim.css BODY { background: white; } H1 { color: black; font-size: 20px; font-weight: bold; } P { color: blue; font-size: 12px; } tiedosto esim.html: <HTML> <HEAD> <TITLE>Moi maailma</title> </HEAD> <BODY> <H1>Esimerkki</H1> <P><IMG SRC="kuva.gif">Dokumenttien kirjoittaminen on oikeastaan aika helppoa.</p> </BODY> </HTML>
'RNXPHQWLWWLHGRQPDOOLQWDPLQHQMDHVLWWlPLQHQ Karkeasti sanottuna: GRNXPHQWWLRQYlOLQHWLHGRQHVLWWlPLVHOOH"Dokumentti" ("käsitteellinen kokonaisuus") voi "teknisesti" tosin olla esitettynä useassa tiedostossa, tietokannassa tai jopa tietokoneohjelman "sisällä" tulostusohjeina "Tieto"-käsitteen hankaluuteen ei tässä yhteydessä ole syytä syvällisemmin puuttua - WLHGRQDNVHOL: tietämys - tieto - informaatio - data - kohina - NODVVLQHQQlNHP\V~ tieto on tosi perusteltu uskomus (tämä näkemys on yleisesti liian rajoittava [mitkä asiat "oikeasti" ovat tosia?]) - Nl\WlQQ OOLQHQQlNHP\V~ tieto on tavalla tai toisella merkityksellistä informaatiota (tässä taas ei oteta kantaa "totuuteen", vaan yhteys käyttöön) Tiedon esittäminen perustuu johonkin tiedon esitysmuotoon ollen sidoksissa tietyn NXYDXVPHQHWHOPlQkäyttöön Tiedon kuvausmenetelmiä on olemassa lukuisia erilaisia ja eritasoisia, esim. - käsitekartat, semanttiset verkot, predikaattilogiikka, formaalit teoriat, ERdiagrammit, UML-kaaviot, HTML, XML, CSS, XSL, MathML, SMIL,
Kuvausmenetelmä valitaan sen perusteella, mistä tiedon piirteistä ollaan kiinnostuneita ja mitä tiedolla halutaan tehdä Erilaisten kuvausmenetelmien välillä voidaan löytää seuraavat ääripäät: - tiedon kuvaaminen tai "jäsentäminen" DVLDVLVlOO QLWVHQVl näkökulmasta ~ WLHGRQNlVLWWHHOOLQHQUDNHQQH ([content]) - tiedon kuvaaminen tai "koodaaminen" DVLDVLVlOO QHVLWWlPLVHQnäkökulmasta ~ WLHGRQHVLW\VUDNHQQH([presentation]) (VLPHUNNLkakkureseptin rakenteen kuvailu - taso 1: NlVLWHUDNHQWHHQWHUPHLKLQMDUHODDWLRLKLQOLLWW\YLHQVRSLPXVWHQ HVLWWlPLQHQ - taso 2: WLHGRQWLHGRVWRNVLNRRGDDPLVHHQHOHPHQWWLHQUDNHQQHMDVLVlOW OLLWW\YLHQVRSLPXVWHQHVLWWlPLQHQ - tämän lisäksi sama "asia" voidaan vielä "kertoa välillisesti" jonkin yleisen tekstin esitysrakenteen puitteissa (esim. muunnoksen tuloksena) Sisällön ymmärtävän lukijan näkökulmasta em. kolme tapaa voivat hyvinkin välittää "saman tiedon", mutta esim. tietokoneiden näkökulmasta tiedon eri esitysrakenteet ovat hyvinkin erilaisia
(VLPHUNNLNDNNXUHVHSWLQHULW\\SSLVLVWlHVLW\VPXRGRLVWD LGHD WLHGRQMlVHQWlPLQHQ Kakkuresepti? kakkuresepti on resepti osa ainekset 7,(72,+0,6(10,(/(66b osa valmistusohje WLHGRQPDOOLQWDPLQHQ WLHGRQHVLWWlPLQHQWDLWLHGRVWDNHUWRPLQHQ resepti ainesosa työvaihe #PCDATA #PCDATA resepti otsikko luku #PCDATA kplotsikko #PCDATA kpl #PCDATA 7,(727,(72 21((66$ OXHWWDYLVVDROHYDGRNXPHQWWL
(VLPHUNNL matemaattisen kaavan x + a / b kuvailu MathML-merkkauskielellä: tapa 1: käsitteellinen merkkaus ([content]): <apply><plus/> <ci> x </ci> <apply><times/> <ci> a </ci> <apply><power/> <ci> b </ci> <cn> -1 </cn> </apply> </apply> </apply> tapa 2: esittämiseen liittyvä merkkaus ([presentation]): <mrow> <mi> x </mi> <mo> + </mo> <mrow> <mi> a </mi> <mo> / </mo> <mi> b </mi> </mrow> </mrow>
7LHWRMDPHWDWLHWR Tieto-käsitteeseen liittyy läheisesti PHWDWLHGRQ käsite. Metatiedolla tarkoitetaan tietoa tiedosta Tieto ja metatieto ovat suhteellisia, informaation käytöstä riippuvia käsitteitä Tietojenkäsittelyssä metatiedolla tarkoitetaan annetun tieto-objektin tietyn kiinteän mallin mukaista kuvausta (vrt. kirjastokortti) kirja lomake kirjastokortti Metatietoa on kärjistetysti kahdenlaista: tiedon semanttiseen kuvailuun & luokitteluun liittyvää metatietoa (esim. "tämä on kirje") ja tiedon esitysrakenteeseen liittyvää rakenteellista metatietoa (tämän dokumentin rakenneosia ovat "otsikko, leipäteksti ja kuva")
'RNXPHQWWHLKLQVLVlOW\\XVHDQW\\SSLVWlWLHWRD Dokumentteihin liittyy oikeastaan siis aina XVHLWDeritasoisia ja -tyyppisiä koodauksia, esim. - sisällön koodaus (suomen kielen sanojen kirjoittaminen ASCII-merkkeinä, kuvien esittäminen bittikarttoina tai vektorigrafiikkana) - rakenteen koodaus (elementtien alku- ja lopputagit HTML:n mukaisesti) - ulkoasun koodaus (esim. elementtien ulkoasun määrittäminen CSSformatointiominaisuuksien mukaisesti) - toiminnallisuuden koodaus (esim. linkin seuraaminen, skriptit, ) joihin puolestaan saattaa sisältyä omia koodauksia, rakenteita & yms. sopimuksia, joista ei "dokumentin yhteydessä" välttämättä erikseen mainita (esim. suomen kielen kielioppi & dokumenttiin sisältyvien objektien koodaus, HTML-kielioppi, kuvien pakkaus, skriptien syntaksi, jne.) Tietokoneiden myötä dokumentteihin voi siis liittyä myös WRLPLQQDOOLVXXWWD (esim. linkin seuraaminen, animaatiot & dokumenttiin upotettavat ohjelmat)
7LHGRQNXYDDPLQHQWHNVWLPXRGRVVDWLHWRNRQHHW Erityyppiset tiedon esitystavat voidaan yleensä palauttaa tekstimuotoon (VLPHUNNL kakkureseptin NlVLWWHHOOLVHQUDNHQWHHQpalauttaminen logiikkaan part-of(ainekset,resepti) part-of(valmistusohje,resepti) is-a(kakkuresepti,resepti) (VLPHUNNL reseptin WLHGRQHVLW\VUDNHQWHHQpalauttaminen XML-säännöiksi: <!ELEMENT resepti (aineosa+, työvaihe+)> <!ATTLIST resepti nimi CDATA #IMPLIED> <!ELEMENT aineosa (#PCDATA)> <!ELEMENT työvaihe (#PCDATA)> Sääntöjä noudattava dokumentti voisi olla esim. seuraavanlainen <resepti nimi="suklaakakku"> <aineosa>jauhoja 3 desiä</aineosa> <aineosa>loput aineet</aineosa> <työvaihe>sekoita osat keskenään</työvaihe> <työvaihe>paista uunissa 200 asteen lämmössä</työvaihe> </resepti>
Käytännön suunnittelussa eri näkökulmien tulisi tukea toisiaan - aluksi tietoa analysoidaan & jäsennetään, jotta tiedettäisiin "mistä on kyse" - tämän jälkeen tieto mallinnetaan käytännöllisten tietorakenteiden muodossa, jotta tiedettäisiin "mitä tietoa sovelluksessa esitetään ja miten?" - lopuksi näistä tietorakenteista voidaan sitten rakentaa erilaisia esityksiä ("minkälainen hyperdokumentti asiasta kertomiseen tai asian näyttämiseen tarvitaan?") Eli aluksi mietitään mitä halutaan esittää, sitten suunnitellaan minkälaisten tietorakenteiden varaan tieto rakentuu ja lopuksi valitaan missä muodossa asiat (lukijalle) esitetään +XRP jos tiedon X esitysrakenne valitaan sen perusteella, miten asiasisältö esitettäisiin esim. HTML-sivuna, esitysvaiheessa "hukataan" (abstraktia) tietoa: - kirjoittaja saattaa (ainakin kirjoitusvaiheessa) "ymmärtää" tai "muistaa" mistä oli kyse, mutta myöhemmin dokumenttia lukiessa "idea" on rivien välissä; konkreettisena pulmana tiedon koneellisen käsittelyn hankaloituminen - ratkaisu: tiedon esittämiseen käytetään "riittävän rikkaita" kuvausmenetelmiä (esim. XML-pohjaisia sanastoja joista tieto kuvataan HTML-muotoon tarvittaessa)
$XWRPDDWWLVHQWLHWRMHQNlVLWWHO\QLGHD Koska tietokoneet eivät ymmärrä koodatun datan merkitystä, SLWllWLHGRQ HVLW\VWDSDYDOLWDNl\W VVlROHYLHQNlVLWWHO\PHQHWHOPLHQHKGRLOOD Keskeinen idea on ATK:n tuominen osaksi informaation NlVLWWHO\prosessia pelkän informaation WDOOHWWDPLVHQVLMDDQ(tästä on puhuttu ennenkin ) RKMHOPDOOLQHQ NlVLWWHO\ VLLUUHWWlY\\V keskitetty ylläpito VRYHOOXNVHWMD Nl\WW informaatio, tieto ja näkemykset HVLWWlPLQHQ tiedon sähköinen esitystapa salaus varmennettavuus pakkaus 7DYRLWH tietokone = (10 4 FIM maksava) muistilehtiö & lipasto tietokone = tiedon hallintajärjestelmä Keskeinen virhe on luulla, että tieto on (yleisesti) käyttökelpoisessa muodossa "kunhan se vain jotenkin saadaan tietokoneelle koodattua" (tavoitteet?!)
7LHGRQHVLW\VUDNHQWHLVWDKLHUDUNNLVHWUDNHQWHHW Tiedon intuitiivisista esitysrakenteista tärkeimpiä ovat kurssilla jo aikaisemmin esitellyiksi tulleet graafit ja puut Juurelliset puut ovat havainnollisuutensa ansiosta erityisen käyttökelpoisia pienten KLHUDUNNLVWHQGRNXPHQWWLUDNHQWHLGHQesittämisessä (esim. HTML) (VLPHUNNLYksinkertaisen HTML-dokumentin eri osat voidaan kätevästi jäsentää dokumentin UDNHQQHSXXQ(eli MlVHQQ\VSXXQ) avulla seuraavasti: +70/ +($' %2'< 7,7/( Esimerkki %*&2/25="white" + Johdanto 3 Tämä on tyypillinen HTML-dokumentti
Sama dokumentti näyttää HTML-koodattuna esim. seuraavalta: <HTML> <HEAD> <TITLE>Esimerkki</TITLE> </HEAD> <BODY BGCOLOR="white"> <H1>Johdanto</H1> <P>Tämä on tyypillinen HTML-dokumentti</P> </BODY> </HTML> Paitsi analysoida ja jäsentää annettuja dokumentteja, merkattujen puurakenteiden avulla voidaan intuitiivisesti myös PllULWHOOldokumenttiluokkia (VLPHUNNLSeuraava ELM-puudiagrammi määrittelee yksinkertaisen dokumenttiluokan geneerisen elementtirakenteen (XML DTD yhteensopivasti) 5(6(37, $,1(6 2+-( 3&'$7$ 3&'$7$
Vastaava (vaikeampilukuinen?) XML dokumentin tyyppimääritys olisi muotoa <!ELEMENT RESEPTI (AINES+, OHJE*)> <!ELEMENT AINES (#PCDATA)> <!ELEMENT OHJE (#PCDATA)> On syytä huomata, että "sama asiasisältö" voidaan esittää useita erilaisia dokumenttirakenteita käyttämällä (VLPHUNNL Kotisivuilta löytyvä asia voidaan kertoa HTML-dokumenttina siten, että käytetään monipuolisesti eri HTML-elementtejä (esim. H1, H2, P & ADDRESS) tai siten, että sama asia kuvataan sanallisesti yhden ainoan P- elementin sisällä Dokumentin rakenteisuuden mitta on dokumenttiin koodattujen rakenneelementtien runsaus eli JUDQXODULWHHWWL - suuri granulariteetti eli "pienet rakeet" ~ rikas rakenne - pieni granulariteetti eli "suuret rakeet" ~ yksinkertainen (köyhä) rakenne Jos dokumentin rakenne on valittu systemaattisesti, sisällön merkitystä kuvaillen, parantuvat mahdollisuudet tiedonkäsittelyn automatisointiin tiedon "arvo" kasvaa (suurta tietomäärää voidaan "hallita pienellä käsityön määrällä")
+LHUDUNLDWMDYLUUDW Kaikki tiedon "luontevat" esitysmuodot eivät aina ole luonteeltaan hierarkkisia (joskin kaikki tieto voidaan ilmeisesti kuvata myös hierarkkisina rakenteina) 9LUWDon jono tietoalkioita (merkkejä) ja kontrollialkioita (kontrollimerkkejä, ohjausmerkkejä tai tapahtumia) Virrassa tieto esitetään siis "pötkössä", jonka seassa on ohjaustietoa (VLPHUNNL Tyypillisiä virtoja ovat esim. ääninäytteet ja videoleikkeet Virtojen kontrollimerkkejä ei siis tulkita elementtien lohko tms. -merkeiksi, koska koko elementin käsitettä ei (välttämättä) ole (VLPHUNNL Myös ohjelmointikielestä C tuttu merkkijonojen käsittely tapahtuu virtojen muodossa printf("tulosta minut\r\nkahdelle riville!"); Tietoa käsitellään virtojen muodossa lähinnä silloin kun - rakenne "ei kiinnosta", ts. tiedolla ei (sovelluksen näkökulmasta) ole tarpeellista rakennetta
- tietoa saadaan haltuun vähän kerrallaan, mutta se on käsiteltävä heti - tiedon rakenteen merkitseminen on kohtuuttoman hankalaa Kun hierarkkiset ja virtamaiset tietorakenteet yhdistetään, puhutaan ns. NRPSRVLLWWLUDNHQWHLVWD - hierarkkiset rakenteet "virran vietävänä" ja päinvastoin Käytännössä useat dokumenttirakenteet ovat itse asiassa komposiittirakenteita, vaikka niistä puhutaankin hierarkkisina - "rakenteisissa dokumenteissa" toimitaan tyypillisesti siten, että dokumentin elementtien perusrakenne on puumainen (hierarkkinen) ja lehtielementtien sisältötekstin rakenne on tulkinnaltaan virtamainen (esim. HTMLstandardissa elementin BR käyttö) - vrt. CSS-tyylin display-ominaisuudet EORFN and LQOLQH
+\SHUWHNVWLQUDNHQQH Hypertekstin idea on erittäin yleinen (yksinkertainen); hyperteksti on solmuista rakentuva suunnattu graafi, jonka sisällä käyttäjä navigoi linkkejä seuraamalla Hypertekstin "teorian" kehittäminen (ja sovellusten systemaattinen rikastaminen) edellyttää ilmeisesti hypertekstin määrittelemistä tätä täsmällisempänä rakennelmana - luonnollinen (moderni) kehityssuunta on hypertekstin solmujen tarkastelu rakenteisina dokumentteina (á la HTML) Hypertekstin (teknisenä) perustana ovat tällöin QLPHW\WWDLYLLWDWWDYLVVDROHYDW GRNXPHQWWLUDNHQWHHW(eksplisiittisesti tai implisiittisesti nimetyt elementit) - viitattavissa olevat dokumentit muodostavat K\SHUDYDUXXGHQ, jossa hyperdokumentin solmurakenne voidaan valita; viittaaminen solmuihin tapahtuu näiden resurssinimien perusteella (esim. URI) - solmujen (dokumenttien) VLVlLVHWviittaukset perustuvat taas johonkin dokumentin osien nimeämis- ja viittauskäytäntöön (esim. nimetty elementti HTML-kielessä tai sijainti DOM-puussa)
:::K\SHUWHNVWL Perusrakenne on dokumentti- ja elementtirakenteiden varaan rakentuva (esim. assosiatiivinen) linkitysrakenne jonka ytimenä ovat WWW-resurssit Linkkien kohteina ovat :::UHVXUVVLW(dokumentit tai dokumenttien osat)
Seuraavassa hypertekstin perusominaisuuksia peilataan seuraavassa kolmen "erilaisen" hypertekstijärjestelmän näkökulmasta: HTML:n, Dexterin ja XLinkin. Vain HTML-linkitys käsitellään (on käsitelty) kurssilla täsmällisesti - on kuitenkin hyvä tietää "muustakin". Kiinnostuneille löytyy verkosta lisätietoa, ks. - HTML (ks. http://www.w3.org/tr/html4/ ) - Dexter Hypertext Reference Model (ks. http://www.acm.org/pubs/citations/journals/cacm/1994-37-2/p30-halasz/ ) - XLink (ks. http://www.w3.org/tr/xlink/ ) Hypertekstin verkkomainen rakenne toteutetaan K\SHUOLQNNLHQavulla ( ) - yksisuuntaiset linkit (esim. HTML A-elementti) - kaksisuuntaiset linkit (Dexter & XLink) - monensuuntaiset linkit (Dexter & XLink) Linkin alkupistettä kutsutaan linkin OlKGHDQNNXULNVLja loppupistettä linkin NRKGHDQNNXULNVL(joskus molempia kutsutaan lyhyesti vain ankkureiksi tai lähteiksi ja kohteiksi, vastaavasti)
+\SHUOLQNNLHQPHNDQLVPHLVWD Toteutuksesta riippuen hypertekstin linkit esitetään eri tavoin ( ) - Dexter mallintaa linkin omana komponentteinaan joihin viittaukset koodataan lähde- ja kohdedokumentteihin (monensuuntaisia linkkejä) - HTML-koodaa linkit kiinteästi lähdedokumenttiin (vain yhdensuuntaisia linkkejä) kaksisuuntaiset linkit - XML-standardiperheen linkitys tarjoaa em. mahdollisuudet, sekä lisäksi mahdollisuuden assosioida dokumenttiin linkkejä (sekä lähde- että kohdeankkureita) LOPDQHWWlOLQNLWQlN\YlWNRGRNXPHQWWLHQNRRGDXNVHVVD PLOOllQWDYDOOD(!) Hyperlinkin avulla voidaan (rakenteisessa dokumentissa) periaatteessa viitata ( ) - dokumenttiin kokonaisuudessaan, - dokumentissa löytyvään elementtiin - dokumentista löytyvään pistemäiseen tunnisteeseen (esim. nimettyyn ankkuriin tai tekstisolmuun)
Viittaaminen elementtiin voidaan suorittaa - elementin nimen perusteella 10 Tiedostot, dokumentit, tieto (&h-media) - elementin sijainnin perusteella (asema dokumentin jäsennyspuussa) - elementin attribuuttien perusteella - elementin sisältämän merkkidatan (tekstin) perusteella - elementin muun sisällön perusteella (esim. lapsielementtien) Hyperlinkkiviittausten keskeisiä ongelmia ovat: - resurssien löytyminen ja saatavuus (miten kohdesolmut nimetään & miten saadaan tieto näiden olemassaolosta) - viittaamiskäytännön raskaus (esim. viittaukset tekstisisällön perusteella saattavat olla laskennallisesti raskaita) - linkkien ylläpito (ULNNRXWXYDWNR linkit jos resursseja liikutellaan tai uudelleenjärjestellään?)
Linkkien VDDWDYXXWHHQliittyvien pulmien ratkaisumenetelmä vaihtelee vastaavasti: - HTML- ja XML-linkkien kohdeankkurit pitää "jostain vain" tietää (esim. arvata & kokeilla) - Dexter-sovelluksen kaikki mahdolliset linkit voidaan täsmällisesti etsiä & luetteloida universaalin hakufunktion avulla (koska linkit ovat komponentteja) /LQNNLYLLWWDXVWHQUDVNDXWHHQliittyviä ratkaisuja: - HTML-linkit eivät sisällä hakumahdollisuutta, joten HTML-linkit ovat teknisesti kevyt toteuttaa (hakujen teknisiä toteutusmahdollisuuksia käsitellään tuonnempana formaalien kielten esittelyn yhteydessä) - Dexter-linkit voivat sisältää koko hyperavaruuden kaikkien komponenttien sisäisiä hakuja, mikä saattaa tarkoittaa HULWWlLQraskasta prosessointia linkin kohteen selvittämiseksi - XML-linkit sisältävät hakumahdollisuuden, mutta vain yhden (XML-) resurssin sisällä; linkin kohteen selvittämisen raskaus riippuu dokumenttien koosta
Linkkien HKH\WHHQliittyviin ongelmiin eri järjestelmät ottavat kantaa eri tavoin: - HTML-linkit voivat mennä reilusti rikki, kun taas Dexter-linkit ovat aina ehjiä - XML-linkit voivat mennä rikki (samaan tapaan kuin HTML-linkitkin), mutta linkkien eheyden ylläpitoa voidaan helpottaa ns. XONRLVWHQlinkkien ylläpidon suunnittelulla (näin toimivat erityisesti ns. linkkikannat ([linkbase])) - WWW:hen tosin puuhataan mekanismia, joka nimeäisi linkkejä (vähän Dexterin tapaan, ks. URN / http://www.ietf.org/rfc/rfc2141.txt ) WWW-hypertekstissä on hyvä huomata esim. linkkien eheyteen liittyvä VXKWHHOOLVXXVWWW:n mekanismien ja yksittäisten selainohjelmien toiminnan välillä; voitaisiinhan hyvin esim. PllULWHOOl (!), että kaikki A-elementillä merkatut WWW-linkit ovat DLQDehjiä ja että VHODLQWHQWRLPLQWDDQkuulu olla näyttämättä rikkoutuneita linkkejä (tällöin selaimen esim. validoisi kaikki dokumentin linkit juuri ennen niiden näyttämistä - tavallaan kuvat käsitellään juuri näin!) Oletuksen mukaisesti hypertekstin linkit ovat DVVRVLDWLLYLVLD. Linkkejä voidaan kuitenkin tarkastella yleisinä (muinakin kuin binäärisinä) relaatioina ja tarkastella sen mukaisesti (tällöin ongelman saattaa muodostaa "sopivan" käyttöliittymämetaforan suunnittelu & toteuttaminen) - esitieto, osa-, ryhmä-, jne. relaatiot
+\SHUOLQNNLHQWRLPLQQDOOLVXXV On syytä huomata, että hyperlinkeille voidaan periaatteessa asettaa myös toiminnalliseen semantiikkaan liittyviä "epästandardeja" määrityksiä (VLPHUNNL XLink-spesifikaation hyperlinkeiltä löytyy attribuutti DFWXDWH, arvot: - RQ/RDG(linkki ladataan YlOLWW PlVWL - toiminnan järkevyys selviää kohta) - RQ5HTXHVW(perinteinen "odotetaan kunnes käyttäjä klikkaa, tms.") - RWKHU(selain päättää käyttäytymisen) Linkin seuraamistapahtuma voidaan periaatteessa valita mielivaltaisesti (VLPHUNNL XLink-spesifikaation määrittelemillä hyperlinkeillä voi olla attribuutti VKRZ, joka voi saada arvot - QHZ(linkin kohde-elementti(!) avataan uudessa käyttöliittymätason ikkunassa) - UHSODFH(selain korvaa koko nykyisen dokumentin linkin osoittamalla kohdeelementillä)
- HPEHG(se elementti, johon linkki viittaa, upotetaan linkkiviittauksen kohtaan siten, että se elementti, joka toimii linkkinä(!), korvataan linkin kohdeelementillä) - RWKHU(selain päättää käyttäytymisen) Huomaa, että osa edellisistä voidaan osin toteuttaa HTML-linkkien avulla (ainakin skriptikielellä terästettynä). Edelleen on syytä huomata, että selain voisi periaatteessa tehdä PLWlWDKDQVDmuutakin (tosin "mikä tahansa" ei käyttäjän odotuksien näkökulmasta ole sovelluksissa järkevää) Vastaavasti voidaan luokitella myös solmuja (luokittelusta voi edelleen seurata esim. "perittävyyteen" liittyviä piirteitä hypertekstin tulkintaan, vrt. hypertekstin visualisointia käsittelevä prujun osa) Rakenteisiin dokumentteihin liittyvälle ("modernille") hypertekstille voidaan siis esittää (jo edellä esitelty) luonnehdinta - rakenteisen hypermedian perustan muodostaa nimetyistä dokumenteista koostuva hyperavaruus; jokaisen hyperavaruuden dokumentin sisäinen rakenne on hierarkkinen, mikä tarjoaa perustan elementteihin viittaamiseen - hyperlinkit ovat tämän dokumenttiperheen ja dokumenttien elementtienvälisiä relaatioita (teknisesti itsekin dokumentteja tai näiden elementtejä)
'RNXPHQWWLUDNHQWHLGHQPllULWWHO\ (Rakenteisten) dokumenttien ja tietorakenteiden käytön yhteydessä (hypermediaan liittyviä) keskeisiä kysymyksiä ovat: - miten tietorakenne se-ja-se on määritelty? Ts., millaisia "kaikki" sovelluksen oikeantyyppiset tietorakenteen ovat? - kuinka dokumentista voidaan valita ankkurin kohteita dokumentin rakenneelementtien nimiä tai (yksityiskohtaisia rakenteitakaan) tuntematta? Rakenteisten dokumenttien, esim. HTML-merkkauksella merkityn tekstitiedoston tapauksessa samantyyppinen kysymys on: miten WRGHOOD tiedämme, että esim. dokumentti <title>esimerkki</title> <h1>kappaleotsikko</h1> <p>tämä kappale on oikein muodostettu</p> on "oikein muodostettu", mutta seuraava dokumentti ei ole? <title>esimerkki</title> <h1>kappaleotsikko<p></h1> Tämä kappale on oikein muodostettu</p>
Vastaus piilee tavassa, jolla tietorakenne (dokumenttirakenne) määritellään; määrittelyn on oltava luonteeltaan sellainen, että se tarjoaa täsmällisen kuvauksen (tai mallin) kaikista "sallitunmuotoisista" tietorakenteista Edellä eräs tällainen kuvaustapa on edellä esitetty elm-puudiagrammi, joka täsmällisesti luonnehti NDLNNLDRESEPTI-tyyppisiä rakenteisia dokumentteja: '2 80(17,1 7<<33,0bb5,77(/< '2 80(177,/82 $1 b6,7( 5(6(37, $,1(6 2+-( 3&'$7$ 3&'$7$ Tietokoneet eivät kuitenkaan operoi kuvilla, vaan merkkijonoilla (eikä em. puudiagrammien avulla ole mahdollista määritellä kaikkia tietorakenteita) Yleisessä tapauksessa, kun halutaan WlVPlOOLVHVWLOXRQQHKWLD WDLSRLPLD WLHWRUDNHQWHLWDYLLWWDXVWHQDYXOOD, tietorakenteet assosioidaan merkkijonoiksi joiden rakenteen käsittely tietokoneilla on tehokasta (ja johon löytyy valmiiksi määritelmiä ja tuloksia) Tällöin viime kädessä päädytään (formaalisten) kielten käsitteisiin; idea on, että määriteltävän tietorakenteen "malli" vastaa kielen määrittelyä ja mallin mukaiset tietorakenteet vastaavat kielen yksittäisiä sanoja.
)RUPDDOLVLVWDNLHOLVWl Pyrittäessä syntaktisesti yksikäsitteisiin kieliin päädytään ns. IRUPDDOLVWHQ NLHOWHQ (formaalien kielten) käsitteisiin; tavoitteena on tällöin lähinnä (objektikieleen liittyvän) kielenkäytön ja päättelyn täsmentäminen Koska kielet ovat sanojen joukkoja, käytetään kielille tuttuja joukko-opin merkintöjä ja operaatioita (sisältyminen, yhdiste, leikkaus, komplementti jne.) Kieliin liittyviä peruskäsitteitä: aakkosto (merkistö), sana, tyhjä sana λ, kielioppi Äärellisen kielen ilmoittaminen onnistuu aina periaatteessa kielen sanat luettelemalla - äärettömille kielille tämä ei ilmeisestikään onnistu (VLPHUNNL eräs kieli aakkostossa Σ={a,b,c} on joukko L={a, ab, aaab, bab, ba} Äärettömän formaalisen kielen L ilmoittaminen voidaan tehdä usein eri tavoin (oleellisesti ominaisuusmääreiden tai tuottolausekkeiden avulla): - esim. säännöllisen lausekkeen avulla (jos L säännöllinen) - yleisessä tapauksessa kielen ilmoittaminen on usein tarkoituksenmukaista tehdä kielen sanat tuottavan NLHOLRSLQavulla
6llQQ OOLVHWNLHOHWMDVllQQ OOLVHWODXVHNNHHW Tärkeä formaalisten kielten erikoistapaus ovat ns. VllQQ OOLVHWNLHOHW Säännöllisen kielen määrittely tehdään ns. VllQQ OOLVHQODXVHNNHHQavulla (voidaan toki tehdä myös muuten, esim. NLHOLRSLQtai DXWRPDDWLQavulla) Säännöllisiä lausekkeita rakennetaan seuraavasti: 1. λ on Σ :n säännöllinen lauseke. 2. Jokainen merkki σ Σ on Σ :n säännöllinen lauseke. 3. Jos R ja S ovat Σ :n säännöllisiä lausekkeita, niin niitä ovat myös 5 6, 56 ja 5. (VLPHUNNL Säännöllisiä lausekkeita merkistössä {1,2,3,4,5} ovat esim. λ, 1, 4, 123, 112344431, 1*, (123)*, (12 34), (4* (12 34)) Merkintöjä sievennetään (kuten edellisessä esimerkissä tehtiin) sopimalla operaattoreiden sitovuus: *, katenaatio ja, ellei suluilla "()" toisin määrätä
Säännöllisten lausekkeiden avulla määritellään säännöllisiä kieliä. Tyydytään seuraavassa luonnehtimaan säännöllisen lausekkeiden R i määräämiä kieliä L(R i ) esimerkkien varassa (voitaisiin tehdä myös täsmällisesti) (VLPHUNNL Valitaan merkistö Σ={a,b,c}. Olkoon R 0 = a, tällöin L(R 0 ) = {a} Olkoon R 1 = ba*, tällöin L(R 1 ) = {b,ba,baa,baaa, } = {ba n n=0,1,2,3, } Olkoon R 2 = (ba)*, tällöin L(R 2 ) = {λ,ba,baba,baba,bababa, } = {(ab) n n=0,1,2,3, } Olkoon R 3 = (a b), tällöin L(R 3 ) = {a,b} Olkoon R 4 = (a b c)*c, tällöin L(R 4 ) = {kaikki merkeistä Σ muodostettavissa olevat sanat, joiden viimeinen merkki on c}
Olkoon R 5 = (a b c)*, tällöin L(R 5 ) = {kaikki merkeistä Σ muodostettavissa olevat sanat (myös tyhjä sana)} merkitään merkistön Σ NDLNNLHQVDQRMHQMRXNNRD symbolilla W(Σ) On olemassa myös kieliä, jotka HLYlWROHVllQQ OOLVLl(esim. kieli L={ a n b n n = 0,1,2,3, } ei ole säännöllinen - se voidaan tosin varsin helposti määritellä yleisen kieliopin avulla) Säännölliset lausekkeet ovat keskeisiä tietojenkäsittelyssä, koska niiden avulla voidaan helposti paitsi määrittää, myös SRLPLDjoukosta merkkijonoja annetun säännön mukaisia merkkijonoja (tai "sovittaa" [match])). Säännöllisten lausekkeiden syntaksi tosin vaihtelee järjestelmissä (Perl-regexp yleistymässä) (VLPHUNNL Komentokieleen perustuvassa käyttöliittymässä halutaan listata aktiivisen hakemiston kaikki tiedostot, jotka alkavat merkkijonolla "com" DOS: UNIX: dir com* ls com* Edellä esitettyjen säännöllisten lausekkeiden syntaksin mukaan com* vastaa säännöllistä lauseketta com(ndlnnlvdoolwxwphunlw\kglvwhww\ql OOD)*, missä "sallitut" merkit on valittu sopivasti tiedostojärjestelmän mukaisesti
(VLPHUNNL Määritellään päivämäärämerkinnän (suurin piirtein) oikea rakenne merkistössä {1,2,3,4,5,6,7,8,9,0,-} Valitaan A = {1,2,3}, N = (1 2 3 4 5 6 7 8 9 0) ja asetetaan R = (N AN)-(N (10) (11) (12))-NNNN Tällöin kieli L(R) sisältää kaikki "suurin piirtein" oikean muotoiset päivämääriä kuvaavat merkkijonot esim. 1-1-0001, 15-11-2000, 24-12-2000 mukana on tosin myös (semanttisesti) ilmeisen virheellisiä ("mielettömiä") merkkijonoja, esim. 39-12-0000, 0-0-0000, jne. (Miten määritystä voisi parantaa?) Edellinen esimerkki esittelee luontevan tavan merkintöjen sieventämiseen PHUNNLOXRNNLHQkäsitteen avulla - käytännölliset säännöllisiä lausekkeita hyödyntävät järjestelmät esittelevät useita hyödyllisiä merkkiluokkia (esim. Perlissä "numerot" \d, "sana-merkit" \w, "tyhjämerkit" \s, jne.) Säänn.lausekk. syntaksia on eri sovelluksissa standardoitu (ohjelmointikielistä löytyy omat notaationsa, suurin "globaali" standardi [Perlin ohella] lienee POSIXin sisältä löytyvä säännöllisten lausekkeiden syntaksimäärittely)
(VLPHUNNLPerl-esimerkkejä säännöllisten lausekkeiden käytöstä etsi/korvaa - tehtävissä KUN $a = "kissa kalasti kissakalan"; TULOSTUS print "$a\n"; $a =~ s/kissa/koira/; KOIRA kalasti kissakalan $a =~ s/kissa/koira/g; KOIRA kalasti KOIRAkalan $a =~ s/[^ks\s]/_/g; k_ss_ k s k_ss_k (VLPHUNNLPerl-esimerkkejä säännöllisten lausekkeiden käytöstä osamerkkijonojen etsimisessä KUN $a = "kissa kalasti kissakalan"; if ($a =~ /(kissa)/) { print "$1\n"; } if ($a =~ /(k...a)/) { print "$1\n"; } if ($a =~ /(k.*a)/) { print "$1\n"; } if ($a =~ /(k[^\s]*a)/) { print "$1\n"; } if ($a =~ /\s(.*)\s/) { print "$1\n"; } if ($a =~ /\s(\w*)/) { print "$1\n"; } TULOSTUS kissa kissa kissa kalasti kissakala kissa kalasti kalasti Yleisemmällä tasolla säännöllisillä lausekkeilla voidaan viitata tai valita myös kokonaisten dokumenttien osia (esim. linkkiviittauksissa)
Säännöllisten lausekkeiden hyödyt tietojenkäsittelyssä perustuvat siis kykyyn määrittää viittauksia säännöllisen lausekkeen "mallin mukaisiin" objekteihin Rakenteisten (hyper)dokumenttien yhteydessä säännöllisillä lausekkeilla on lisäksi oma erityinen merkityksensä: säännöllisten lausekkeiden avulla (yhdessä rakenteisen dokumentin käsitteistön kanssa) voidaan viitata esim. dokumentin rakenne-elementteihin ja elementtijoukkoihin ja luoda näin hyperlinkkejä ilman viitattavien solmujen nimiä tms. (VLPHUNNL XML-hyperlinkkien taustalla oleva XLink-spesifikaatio tarjoaa XPathspesifikaation (huh?) avulla keinon rakenteisen dokumentin osiin viittamiseen esim. seuraavasti (mainittakoon, että Xlink otettaneen käyttöön tulevaisuudessa myös XHTML-kielen yhteydessä jo nyt käytössä esim. XSLT:ssä) Notaatio child::* valitsee kaikki kontekstisolmun lapsielementit Notaatio child::text() attribute::* valitsee kaikki kontekstisolmun lapsitekstisolmut tai attribuutit Notaatio descendant::para valitsee kaikki kontekstisolmun para-tyyppiset jälkeläiset (elementit) XML-linkkien olemusta ei tässä yhteydessä kannata syvällisemmin murehtia; oleellista on ymmärtää, että säänn. lausekkeilla voidaan rakentaa myös hyperlinkkien osumakohtia (ts. valita rakenteisen dokumentin osia)