tiistai 22. heinäkuuta 2008

Mikä on lojbanin juju?

Edellisen kirjoituksen kommentista:

"Niin no tarkemmin sanoen en ymmärrä miten lojban-kieli oikein soveltuu agentin ohjaamiseen. Ison tavallisen tietokannan käyttämisessä on riittävästi työtä. Siihen voidaan luoda lukemattomia matemaattisia sääntöjä jotka eivät ole mitenkään triviaaleja. Ehkä Bayesin laskennat ovat joillekin huippukoodaajille. Minulle nekin kaaviot ovat outoja."

"Harvalla on aikaa määritellä sääntöjä jotka muistuttaa kovakoodausta. Visioisin että suuret tietokannat tulevat viestittämään toisilleen ja Semanttinen web pysyy käyttäjältä piilossa."

"..miten lojban-kieli oikein soveltuu agentin ohjaamiseen."
Ei, ei agenttia, ainakaan aluksi, ohjata lojbanilla. Ollakseen oikeasti älykäs, agentin on joustavasti sopeuduttava vieraaseen ympäristöön, esim vieralle nettisivulle tai langattomaan lähiyhteyteen tuntemattoman laitteen kanssa. Semantic-Web-ajattelu lähtee siitä, että agentit, sivut ja laitteet vaihtavat semanttista tietoa keskenään ja kognitiivisen neuvottelun tuloksena löytävät yhteisen sävelen: ymmärtävät toisiaan: tietävät mihin viitekehykseen toisen tahon sisältö ja palvelut liittyvät ja miten niitä käytetään.

Suuri ongelma on se, miten tätä semanttista tietoa tuotetaan. Ilmeisesti tästä oli tässä kysymys: "Harvalla on aikaa määritellä sääntöjä jotka muistuttaa kovakoodausta..", vaikka kovakoodaukseen ei tietenkään pitäisi mennä. Tässä lojban tulee mukaan kuvioihin. Lojbanin ensimmäinen ja arvokas mahdollisuus on toimia tuottavana työkaluna semanttisen tietämyskannan (tekisin jyrkän eron semantisten tietämyskantojen ja perinteisten tietokantojen välillä) laatimisessa. Lojban mahdollistaa kaksi tärkeää toiminnallisuutta:
  1. Interaktiivisuuden, vuorovaiheisen keskustelun, kuin ihminen toiselle, työkalun kanssa. Lojban on ensikädessä ihmiskieli.
  2. Lojbankielisen sisällön yksiselitteisen mäppäämisen semanttiseksi datarakenteeksi ja edelleen muiden "trippelistandardien" mukaisiksi esitystavoiksi.
Jotta nämä kaksi lupausta voitaisiin pitää, tarvitaan vielä paljon työtä, mutta suurin työ, eli lojbanin 50v kestänyt tuotekehitys on jo tehty. Nyt tarvitaan kaksi-kolme puuttuvaa lenkkiä:
  1. Interaktiivinen työkalu, joka keskustelee sovellusasiantuntemusta edustavan ihmisen kanssa sujuvasti lojbaniksi.
  2. Koulutusjärjestelmä, jolla voidaan kohtuullisin ajallisin investoinnein kouluttaa tällainen lojbania sujuvasti osaava "losbonomi". Kuvittelisin itse lojbania parhaillaan opiskelevana, että n. kuusi viikkoa intensiivikoulutusta sirotettuna puolen vuoden ajalle ja tehoviikkojen välillä omatoimista työharjoittelua työkalun kanssa mm. sanastoa opiskellen ja oman alan erikois-lujvoja ja ontologioita kehitellen, voisi olla riittävää, kunhan homma on optimoitu.
  3. Kolmas tarve on tavallista SW-projektia vastaava muunnostyökalun kehittely: lojban-kannasta esim. OWL-kielelle.
Minä työskentelen harrastuspohjalta 1. ja 2. hankkeiden kanssa. Olisin valmis vaihtamaan homman täyspäiväiseksikin. Mutta olen varma, että vastaavaa roadmäppiä noudattaa moni muukin näkymätön projekti maailmassa. Viittaan tuolla aikaisemmin esittämiini linkkeihin ja lojban-yhteisön keskusteluihin sekä siihen, että ongelma tiedostetaan laajalti.

2 kommenttia:

Anonyymi kirjoitti...

"(tekisin jyrkän eron semantisten tietämyskantojen ja perinteisten tietokantojen välillä)"

Hmm... Levytietokanta on kyllä kankea, mutta pidin pakon sanelemana sitä että tietämyskannan voi tallentaa kokonaisuudessaan siististi yhteen tietokantaan. Ei ole tästä käytännön kokemusta mutta nopeasti ajatellen tietokanta tuntuisi helpommalta ja turvallisemmalta kätköpaikalta vaikka ohjelmiston huollon aikana persistenssin aikaan saamiseksi.

Mutta ehkä onkin fiksumpaa toteuttaa pysyvyys erillisillä datantoimittajilla. Toimittajat käyttäisivät tietämyksen varastointiin niitä tietovarastoja kun parhaaksi näkevät. Ja ylin osa, varsinainen "tietoisuussuoritin", on olemassa vaan ollessaan käynnissä.

Anonyymi kirjoitti...

"Datantoimittajilla" tarkoitan siis erillisiä ohjelmia jotka toimivat sulautetun tietotekniikan periaatteen mukaisesti, riippumatta siitä ovatko ne fyysisesti keskuskoneella vai langattoman yhteyden päässä. Ilmeisesti muisti pitää olla hajautettu niin että pysyvyys ei ole muista ohjelmista kiinni. Tämä taas on htm-periaatteen mukaista. 15 vuotta "keskuskoneohjelmointia" harrastaneen mielestä tämä on resurssien tuhlausta mutta asioita ei ehkä voi tehdä muulla tavalla.

-Knowledge$-