12 Pari sanaa sovelluskehityksestä

Transkriptio

1 12 Pari sanaa sovelluskehityksestä Kurssin lopuksi pohdimme yksinkertaisia tietointensiivisiä sovelluksia. Pyrkimyksenä on valottaa eri tekniikoiden merkitystä ja hajautettuihin sovelluksiin tyypillisesti liittyvien toimijoiden rooleja (nyt löyhä Semantic Web Services -yleisjäsennys). Esityksen tarkoituksena on yksinkertaisesti miettiä tekniikoiden, sovellussuunnittelun ja käytäntöjen välistä vuoropuhelua sekä yrittää nähdä metsä puilta. 254

2 12.1 Välisoitto Monimutkaisia palvelukokonaisuuksia voidaan jäsentää esim. kilpailun, palvelu(liike)- toiminnan ja erikoistumisen käsitteiden varassa (vrt. service-oriented systems) Palvelusovelluksissa voidaan yleensä tunnistaa roolit Provider, Requestor (tai Consumer) ja Broker Käytännön syistä, osa palveluntarjoajista tyypillisesti "erikoistuu" tietointensiivisissä sovelluksissa tietoa välittävän asiantuntijan rooliin (tiedon rajaaminen ja mielekäs kontekstuaalinen esittäminen [vrt. DSS & Understanding]) 255

3 12.2 Esimerkki #1: TTY:n kalenteri Näkökulmia lukukauden tapahtumatiedon hyödyntämiseen: I: Henkilökohtainen käyttö: esim. "Ossin periodi 2" - Henkilökohtaisen aikajanan kokoaminen (päällekkäisyydet, ennakointi, suunnittelu) G: Ryhmätason käyttö: esim. "RDJ-kurssin näkökulma periodiin 2 " - Kurssitason aikajanan kokoaminen (suhde muihin opintojaksoihin, koordinointi) O: Organisaatiotason käyttö: esim. "Seuranta ja tukitoimet" - TTY:n tason aikajanan kokoaminen (tilankäytön ja resurssien optimointi, työkuorman seuranta) Tarpeet ja motivaatio tiedon tuottamiseen ja hyödyntämiseen saattavat suurestikin vaihdella eri toiminnan tasoilla (!) 256

4 12.3 Esimerkki #2: kauppapaikka Yksinkertaisen kauppapaikan käyttötapauksia: K1: "Myynti-ilmoituksia hyvin monentyyppisistä myyntiartikkeleista" - artikkeleiden perustiedot (rdf:type, rdfs:label, dc:description, rdj:thumblink, rdj:imagelink) - luokitteluun YSA-asiasanasto taksonomiana - luokitellaan kaikki myytävät artikkelit (dc:subject) K2: "Artikkelin ja ilmoituksen hinta- ja voimassaolotiedot" - rdj:priceineuros, rdj:expires K3: "Yhteydenotot ja varaukset" - myyjän tiedot, myyntistatus (dc:creator, rdj:onsale) Kaikki ei suju kuin tanssi

5 12.4 Palvelun perusjäsennys Vrt. esim. Myyjä ja Ostaja Tarvitaan myös Välittäjä (!); tehtäviä: - näkyvyys/löydettävyys, hakemistot, taksonomiat,..., lisäarvopalvelut Provider Broker Requestor (Meta) Provider (Auxiliary / Added Value Services) - tietojen eheyden ja luotettavuuden tarkistukset, tietoturva, käyttöehdot,.. - tietojen elinkaaren hallinta (päivitykset, poistot, tarkistuspyynnöt,...) - liiketoiminnan prosesseihin liittyvät palvelut ja tarkistukset (saako esim. myyjä P 1 sanoa jotain myyjän P 2 tuotteista?, jne.) - laskutus (huomaa että osa yo. tehtävistä siirrettävissä lisäarvopalveluihin) Oheis- tai lisäarvopalvelun tarjoaja, tehtäviä - lisätietoja (esim. hintavertailuja), arviointeja ja testejä, markkinointi,..."periaatteessa kuten myyjä, mutta erilainen prosessi ja liikeidea" 258

6 12.5 Tietointensiivisten (SW-)sovellusten haasteita 1. Ei tiedetä, minkälainen tieto olisi käyttökelpoista käsillä olevan tehtävän ratkaisemiseksi 2. Ei tiedetä mitä tietoa olisi periaatteessa saatavilla tai mistä se löytyisi 3. Halutut tiedot eivät ole saatavilla 4. Viitatuista dokumenteista löytyy kielioppivirheitä XML-syntaksin tasolla, RDF-tietomallin tasolla, OWLontologian tasolla jne. 5. Saatavilla olevaa tietoa ei osata tulkita (esim. dokumentoinnin puutteen tai esitietovaatimusten takia) 6. Tietolähde ei ole luotettava tai tiedot eivät ole ajan tasalla (tai tätä ei tiedetä) 7. Saatavilla olevan tiedon olemassa oleva mallinnus ei sovi tehtävän ratkaisuun sellaisenaan 8. Tietoa on luokiteltu väärin tai mallinnus ei ole systemaattista (olettaen että asia ymmärretään!) 9. Tieto on epätäydellistä tai se on näkökulmaltaan ei-toivotusti värittynyttä (vrt. uutiset) 10. Tietoa on potentiaalisesti saatavilla liikaa tietokannan fyysisen koon näkökulmasta 11. Tietoa on potentiaalisesti saatavilla liikaa tietokannan loogisen koon näkökulmasta 12. Tiedon käyttöä on rajoitettu esim. tekijänoikeuksien/lisensoinnin näkökulmasta 13. Tietoa on syötetty harhauttamistarkoituksessa väärin 14. Yksilöobjekteja käsittelevä lausumatieto muuttuu, terminologinen tieto muuttuu (odottamatta) 259

7 12.6 Sovelluskehittäjän johtopäätöksiä RDF/OWL soveltuvat melko hyvin tiedon julkaisuun (vrt. HTML), mutta tietointensiivisen ("Semanttisen Webin") sovelluksen toteutus tarvitsee muutakin, erityisesti: 1. RDF/XML-"raakadata" vaatii yleensä teknistä esikäsittelyä (käyttöoikeuksien hallinta, kielioppivirheiden perkaaminen, tiedon normalisointi/kuvaaminen sopivaan semanttiseen sanastoon, yms.) 2. Tietolähteen järkevyyden arviointi saattaa edellyttää myös semanttista arviointia ja harkintaa tiedon "hyväksymisessä" (vrt. sabotaasi!) 3. SPARQL-kyselijä tms. soveltuu käsiteltävän RDF-osajoukon rajaamiseen, mutta ei oletuksena sovellu monimutkaisten sovellusten "varsinaiseksi kyselykieleksi". Tarvitaan myös erillistä sovelluslogiikkaa. 4. Päättelyä, sääntöjä tms. sisältävien sovellusten suurin (käytännön) haaste piilee monimutkaisen (hyödyllisen) tietämyskannan tuotannon ja ylläpidon vaikeudessa, niinpä "hyvät" mekaanista päättelyä suorittavat sovellukset ovat melko yksinkertaisia (tai rajatun käyttäjäkunnan "erikoissovelluksia") 5. Sovelluskehityksen suurimmat haasteet liittyvät sovellusosaamiseen, prosessien tuntemiseen ja esim. käytäntöjen haasteisiin 6. Ts. RDF/XML/OWL/SPARQL/RIF/XSLT/... -tekniikoiden rooli sovelluksessa kutistuu prosessien ja käytäntöjen haasteiden edessä ("Enabling Technologies") 260

8 12.7 Lopuksi (1/2) RDF-tietomalli soveltuu kuvailu- ja metatiedon esittämiseen ja yhdistämiseen, sekä OWL-laajennuksen myötä myös käsitemallien esittelyyn Rakenteisen tiedonkäsittelyn filosofia puolustaa paikkaansa useissa sovelluksissa, myös ns. semanttisissa sovelluksissa Realististen sovellusten taustalta tulee poikkeuksetta löytyä tietojenkäsittelyprosessin tarkoituksenmukainen kuvaus (sisältäen organisaation tavoitteisiin, ihmisiin & työkulttuuriin liittyviä asioita) Mitä tarkemmin prosesseja yritetään mekanisoida, sitä tarkempia määrittelyjä tarvitaan (...tiedon määrän optimointi) Motto: turha käsityö on katoavaa kansanperinnettä onneksi! 261

9 12.8 Kiitos! 262