12 Case: "hajautettu kauppapaikka"

Transkriptio

1 12 Case: "hajautettu kauppapaikka" Kurssin lopuksi tarkastelemme yksinkertaista sovellusesimerkkiä joka pyrkii valottamaan eri tekniikoiden suhdetta ja hajautettuihin sovelluksiin tyypillisesti liittyvien toimijoiden rooleja (nyt löyhä Semantic Web Services - yleisjäsennys). Esityksen tarkoituksena on yksinkertaisesti miettiä suunnittelun ja käytäntöjen välistä vuoropuhelua sekä yrittää nähdä metsä puilta. 252

2 12.1 Välisoitto Monimutkaiset palvelukokonaisuudet toimivat kilpailun, verkostoitumisen ja erikoistumisen periaatteiden mukaan Kaikki eivät ehdi/ halua/ osaa/ voi tehdä kaikkea sama pätee tekniikkaan ja tietoteknisiin palveluihin (vrt. liiketoimintaympäristöt) 253

3 12.2 Esimerkki #1: TTY:n periodi 2 (v2006) 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 (!) 254

4 12.3 Esimerkki #2: kauppapaikka (v200[57]) 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 RDF/SPARQL/XSLT-esimerkki Kokeillaan

6 12.5 Palvelun perusjäsennys Myyjä ja Ostaja Välittäjä, tehtäviä - löydettävyys, hakemistot, taksonomiat,..., lisäarvopalvelut - tietojen eheyden ja luotettavuuden tarkistukset, tietoturva Provider Broker Requestor (Meta) Provider (Auxiliary / Added Value Services) - tietojen elinkaaren hallinta (päivitykset, poistot, tarkistuspyynnöt,...) - liiketoiminnan prosesseihin liittyvät palvelut ja tarkistukset (esim. LKVpalvelut, 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" 257

7 12.6 Taksonomiaan perustuva luokittelu, huomioita Sovitaan nimet taksonomian käsitteille... (mekaaniset muunnokset) Taksonomia voidaan kuvata RDF-mallissa esim. seuraavasti... ysa:autot rdf:type rdfs:class. ysa:henkilöautot rdf:type rdfs:class. ysa:henkilöautot rdfs:subclassof ysa:autot.... Nyt esim. kategorioita hyödyntävä haku onnistuu siis transitiivisen päättelijän (Transitive Reasoner) varassa (vrt. Jena2) - vaihtoehtoisesti, voimme kuvata transitiivisuuden myös OWL:lla Jos luokittelussa on sallittua käyttää myös taksonomian sisäsolmuja voi käytännössä olla suotavaa koodata luokittelu kahteen kertaan (miksi?): - joko luokitellaan kaikki myytävät artikkelit ei-transitiivisesti (dc:subject) ja kopioidaan transitiiviseksi määrittelyksi (esim. rdf:type tai rdj:category) - tai transitiivisuusominaisuus pitää voida kytkeä hauissa pois päältä 258

8 12.7 Luokittelu? (vrt. etuovi.com, autotalli.fi) Asiasanaston käyttöön liittyy pulmia jotka hankaloittavat sen käyttöä taksonomiana! Esimerkkejä: - tarjotaan myytäväksi omakotitaloa luokitellaanko kategorian asunnot vai rakennukset mukaan? - tarjotaan myytäväksi luhtitaloasuntoa tätä luokittelua ei löydy YSA:sta (...lisätään? mutta onko luhtitalo asunnot-tyyppisen artikkelin lisäominaisuus, asuntojen aliluokka vai jotain muuta?) - tarjotaan myytäväksi kokonaista rivitaloa (eikä yksittäistä rivitaloasuntoa)... Eräänä ratkaisuna voidaan tarjoa useita rinnakkaisia luokituksia (oletus?) Luokituksen sisään/rinnalle voidaan esim. sopia kategoriakohtaisia lisätietoja (jotka siis myös luokituksia huomaa rekursio määritelmässä!) - esim. moottoriajoneuvot-kategoriaan moottorin tiedot - esim. asunnot-kategoriaan osoite- ja tontin tiedot, huoneistopinta-ala yms. 259

9 12.8 Tiedot sisällöllisesti ok? Ovatko artikkeleiden myynti-ilmoitukset kunnossa? - kieli? alue? linkki sähköiseen tuotteeseen? luokittelu oikein? hintatieto oikein? tiedot ajan tasalla? saatavilla? - todellisia ilmoituksia (rdj:serious)? hyvän maun mukaisia? Miten oikeellisuus varmistetaan käytännössä? ts....tarvitaanko käytännössä kuitenkin (ihmis)päätoimittajaa? Eräs ratkaisumalli: ilmoitusten hyväksyminen - roskan mekaaninen suodatus (vrt. Spam Filters), - uusien/muuttuneiden tietojen hyväksyminen (käsin), vanhentuneiden tietojen automaattisuodatus, - "luotettavien yhteistyökumppanien" tunnistaminen automatisointi, jne. Tietojen kopiointi repository-tyyppiseen "väli"varastoon? (saatavuus ja muutokset) 260

10 12.9 Tiedot teknisesti ok? Ilmeisesti suora SPARQL-kysely ei yksin sellaisenaan ole riittävä ratkaisu Tyypillisiä murheita: - yksittäiset (tilapäisesti) RDF/XML-tiedostot rikki - tietoa ei (tilapäisesti) ole saatavilla,... Mallinnus kunnossa? - luokat vs. ominaisuudet, resurssit vs. literaalit,... - onko esim. dc:subject-predikaatin arvo mallinnettu resurssina? Huomaa että tyypillinen lisäarvopalvelu kytkeytyisi todennäköisesti juuri esim. luokitukseen (...siispä arvon on oltava resurssi) - "luento-tyyppisistä tapahtumista halutaan sanoa jotain yleistä" - "asuntoa ostaville tarjotaan myös lainatarjouksia ja käytettyjä autoja ostaville autotohtorien palveluita" 261

11 12.10 Välittäjä, lisäarvopalvelut ja liiketoiminta? Tyypillisiä oheis- ja lisäarvopalveluita - markkinointi - tietopalvelut (esim. hintatilastot, vrt. Tuulilasin käytettyjen autojen hinnat) - asiantuntijapalvelut (esim. autotohtori) Pulmia: - myyjät ja asiakkaat arvostavat erilaisia lisäarvopalveluja! - suostuisivatko esim. vähittäiskaupat, puhelinoperaattorit, vakuutusyhtiöt, rakennusliikkeet,..., julkaisemaan tietonsa vertailtavassa muodossa? - poliisina toimiminen! Tarvitaanko keskitettyä kauppapaikkaa? - löydettävyys, luotettavuus, lisäarvopalvelut,... (?) 262

12 12.11 Ohje tiedon tuottamiselle ja käyttöliittymä, kiitos Tietenkin ohjeistettava tarkemmin! (Mieti yo. näkökohtia & rämettymistä) - esittely, käyttötapaukset - esimerkki(!), predikaattien kuvaukset ja skeema (tai ontologia tms.) - validointipalvelu(!) - sovellusesimerkki Käyttöliittymät! - harva loppukäyttäjä hakisi tietoa suoraan SPARQL-kielellä - RDF-tietomalli piiloutuu todennäköisesti vaiheistetun lomakkeen alle - kysymyksiä: nimet? validointi? semanttinen verkko?... Ts. RDF/XML/SPARQL/XSLT/... -tekniikan rooli sovelluksessa kutistuu prosessien ja käytäntöjen haasteiden edessä ("Enabling Technologies") 263

13 12.12 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) 264

14 12.13 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 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") 265

15 12.14 Lopuksi RDF-tietomalli soveltuu kuvailu- ja metatiedon esittämiseen ja yhdistämiseen, sekä OWL-laajennuksen myötä myös käsitemallien esittelyyn XML-tietojenkäsittelyn suoraviivaisuus puolustaa paikkaansa myös tietointensiivisissä sovelluksissa (työnjako) Realististen sovellusten taustalta tulee poikkeuksetta löytyä tietojenkäsittelyprosessin tarkoituksenmukainen kuvaus (sisältäen organisaation tavoitteisiin, ihmisiin & työkulttuuriin liittyviä asioita) Mutta: Mitä tarkemmin prosesseja yritetään mekanisoida, sitä tarkempia määrittelyjä tarvitaan (tarkemmat määrittelyt taas tuovat lisätyötä) Motto: turha (tai epämiellyttävä) käsityö on katoavaa kansanperinnettä onneksi! 266

16 12.15 Kiitos! 267