samodejno povezovanje programskih …kt.ijs.si/theses/dipl_luka_bradesko.pdf · 3.2. register...
Post on 08-Feb-2018
224 Views
Preview:
TRANSCRIPT
Univerza v Ljubljani
Fakulteta za elektrotehniko
Luka Bradeško
SAMODEJNO POVEZOVANJE PROGRAMSKIH
KOMPONENT V UPORABNE TOKOVE DELA
DIPLOMSKO DELO
Mentor: doc. dr. Boštjan Murovec
Somentorica: doc. dr. Dunja Mladenić
Ljubljana, 2010
Zahvala
Za pomoč pri pripravi diplomskega dela bi se zahvalil doc. dr. Boštjanu Murovcu ter doc. dr.
Dunji Mladenić.
Vsebina
Povzetek ................................................................................................................................................ 11
Abstract ................................................................................................................................................. 13
1. Uvod .............................................................................................................................................. 15
2. Uporabljene platforme in standardi.............................................................................................. 17
2.1. Programski sistem Cyc ........................................................................................................... 17
2.1.1. Baza znanja CycKB ......................................................................................................... 17
2.1.2. Sklepalni mehanizem Cyc .............................................................................................. 23
2.2. RDF ........................................................................................................................................ 25
2.2.1. RDF besednjak ............................................................................................................... 27
2.2.2. RDF shema ..................................................................................................................... 27
2.3. SPARQL .................................................................................................................................. 28
2.3.1. Primeri SPARQL poizvedb .............................................................................................. 28
2.4. LarKC ...................................................................................................................................... 30
2.4.1. Arhitektura .................................................................................................................... 32
2.4.2. Vtičniki ........................................................................................................................... 33
2.4.3. Komponenta za sestavljanje tokov dela ........................................................................ 37
3. Predlagana rešitev ......................................................................................................................... 39
3.2. Register vtičnikov .................................................................................................................. 40
3.3. LarKC ontologija .................................................................................................................... 42
3.4. Povezovanje na nivoju vhodno-izhodnih podatkovnih tipov ................................................ 43
3.5. Iskanje primernih vtičnikov glede na vhodno poizvedbo ...................................................... 47
3.5.1. Serializacija SPARQL poizvedbe v RDF/CycL .................................................................. 48
3.5.2. Opis vhoda in izhoda vtičnikov glede na vsebino .......................................................... 52
3.5.3. Sklepanje ....................................................................................................................... 54
3.6. Iskanje primernih vtičnikov glede na vhodne zahteve .......................................................... 57
3.6.1. Razvoj logičnega pravila za povezovanje ....................................................................... 57
3.6.2. Uporaba pravila za povezovanje.................................................................................... 62
3.7. Združitev pristopov ................................................................................................................ 64
4. Zaključek in nadaljnje delo ............................................................................................................ 67
5. Reference ....................................................................................................................................... 69
Seznam slik
Slika 1: Struktura znanja v Cyc KB (preslikano iz prosojnic s predavanj M. Witbrock, ESWC
2008) ......................................................................................................................................... 18
Slika 2: Primer iz CycL KB brskalnika, ki podaja vpogled v predikat #$father znotraj baze
Cyc KB ..................................................................................................................................... 21
Slika 3: Izpis trditev za funkcijo FatherFn iz CycKB .............................................................. 22
Slika 4: primer vizualizacije RDF grafa, ki opisuje očetovsko relacijo med Matejem in Petrom
.................................................................................................................................................. 26
Slika 5: koraki pri računalniškem sklepanju z uporabo LarKC platforme ............................... 31
Slika 6: Arhitektura LarKC platforme kot je podana v LarKC_WP5_D5_3_1_V1_0.pdf ...... 33
Slika 7: LarKC Arhitektura z vidika izvajanja tokov dela (preslikano iz prosojnic LarKC
delovnega gradiva). .................................................................................................................. 38
Slika 8: Arhitektura z vrinjenim "Decider" vtičnikom, ki sam določa nove tokeve dela
(preslikano iz prosojnic LarKC delovnega gradiva)................................................................. 39
Slika 9: Arhitektura registra vtičnikov ..................................................................................... 40
Slika 10: Primer opisa vtičnika znotraj registra vtičnikov (preslikano iz CycKB brskalnika). 42
Slika 11: Osnovna LarKC ontologija ....................................................................................... 43
Slika 12:Dopolnjena LarKC ontologija s predikati za opis vhodno-izhodnih tipov RDF
podatkov ................................................................................................................................... 45
Slika 13: Množica možnih povezav med vtičniki kot rezultat sklepanja glede vhodno-izhodnih
tipov podatkov .......................................................................................................................... 47
Slika 14: Dopolnjena LarKC ontologija z razredi ter predikati namenjeni za serializacije
SPARQL poizvedb ................................................................................................................... 50
Slika 15: Odgovor sklepalnega pogona na poizvedbo o podjetjih omenjenih v članku ........... 56
Slika 16: Odgovor sklepalnega pogona na poizvedbo o dogodkih v koledarju ....................... 57
Slika 17: Rezultati poizvedbe (#larkc-pluginConnectsTo #$larkc-ArticleIdentifier
?PLUGIN2) .............................................................................................................................. 63
Slika 18: Utemeljitev za povezavo med ArticleIdentifier vtičnikom ter CycReasoner
vtičnikom .................................................................................................................................. 63
Slika 19: Potek dela ki se začne z »ArticleIdentifier« vtičnikom ter konča z vtičnikom ki vrne
»VariableBinding« ................................................................................................................... 64
Seznam tabel
Tabela 1: Preslikava iz RDF v CycL ........................................................................................ 41
Povzetek
Pričujoče diplomsko delo predstavlja metodo za samodejno povezovanje LarKC vtičnikov v
uporabne tokove dela. Na začetku predstavi programski platformi namenjeni računalniškemu
sklepanju LarKC ter Cyc, na kateri se navezuje večina predlagane rešitve. Predstavljeni so še
preostali uporabljeni standardi, kot sta RDF ter SPARQL.
V nadaljevanju so podrobno opisane metode ter postopki, ki so uporabljeni pri predlagani
rešitvi samodejnega povezovanja vtičnikov, ter predstavljena delujoča rešitev.
Rezultat diplomskega dela je osnutek LarKC komponente, ki iz dosegljivih vtičnikov
samodejno sestavlja tokove dela glede na vhodne SPARQL poizvedbe. Samodejno
povezovanje je izvedeno z uporabo semantičnih opisov vtičnikov, nad katerimi s Cyc
sklepalnim mehanizmom poteka računalniško sklepanje.
Semantični opisi vtičnikov so majhne ontologije, ki so kot dodaten rezultat te naloge
nadgrajene s predikati ki opisujejo vhodne ter izhodne zahteve vtičnikov.
V zadnjem delu pa so podani še problemi ter ugotovitve trenutnega pristopa ter smernice za
nadaljnje delo.
Ključne besede:
računalniško sklepanje, sklepalni pogon, ontologija, vtičnik, samodejno sestavljanje, tok dela,
logika prvega reda, pravilo za sklepanje, trditev, trojka
Abstract
This work presents a method to automatically construct the LarKC plug-ins into efficient and
usable workflows. It begins with the description of LarKC and Cyc projects, which are used
as deployment platforms and shows an overview of standards such as RDF and SPARQL.
The work continues with the analysis and descriptions of methods and approaches used in the
steps to automatic workflow construction. It describes in detail the ontologies, reasoning
rules, queries and other parts of the proposed solution.
The result of the thesis is a prototype »Decider« plug-in which is able to automatically
construct the workflow out of the available plug-ins and based on the input SPARQL query.
This is done by using the semantic annotations of the plug-ins, propagating the knowledge in
the Platform’s plug-in registry and using Cyc Reasoning Engine.
Data about the plug-ins are available to the software via the ontology with which the plug-ins
are annotated. Part of this thesis is focused on extending the vocabulary of the ontology with
the predicates describing the job that the plug-ins can do.
Finally, the thesis presents the problems with current approach, conclusions and guidelines for
future work.
Keywords:
reasoning, reasoning engine, ontology, plug-in, automatic construction, workflow, first order
logic, reasoning rule, assertion, triple
15
1. Uvod
S problemom povezovanja posameznih delov nekega kompozitnega sistema v delujočo
celoto, ki je na podlagi povezav sposobna opraviti določeno nalogo, se srečujemo pri vseh
večjih in kompleksnejših sistemih z večjo količino komponent. Takšni sistemi so prisotni na
vseh področjih. Najdemo jih tako v znanosti kot tudi v industriji, njihova prednost pa je, da z
različnimi kombinacijami uporabe istih komponent, lahko rešujemo različne probleme.
Kot primere navedimo dokazovanje izrekov v matematiki, kjer je za določen dokaz potrebno
uporabiti nekatere predhodne dokaze, združevanje elektronskih komponent v funkcionalno
napravo, povezovanje spletnih storitev (ang: web services) v računalništvu, itd.
V računalništvu, ki je tudi ciljno področje pričujočega diplomskega dela, so taki sistemi še
posebej pogosti, zaradi velike količine na internetu prosto dostopnih funkcij in programskih
vmesnikov (ang: API, application programming interface). Pojavljajo se tudi namenski
programski sistemi oziroma platforme, kot so Yahoo Pipes [1] ali Orange [2], ki so namenjeni
reševanju specifičnih problemov znotraj nekega področja.
V omenjenih primerih gre za manipuliranje RSS podatkov ter reševanje problemov s področja
rudarjenja teksta [3]. Takšne platforme imajo običajno definirano svojo množico komponent,
ki jih je možno povezovati v kompleksnejše tokove dela ali podatkov. Take komponente so
večinoma istega tipa, ali pa napisane na podoben način in so tako združljive med sabo, ter
prijaznejše za povezovanje in medsebojno klicanje, kot pa naključne funkcije iz interneta.
Tipi vhodnih in izhodnih podatkov ter scenariji povezovanja teh komponent so kontrolirani,
kar posledično zmanjša kompleksnost problema samodejnega povezovanja. Ena izmed takih
programskih rešitev, namenjena testiranju in praktični uporabi sklepanja nad velikimi
količinami podatkov, je tudi platforma LarKC [4] platforma, na primeru katere temelji
pričujoča naloga.
16
17
2. Uporabljene platforme in standardi
Programska rešitev predstavljena v tem diplomskem delu temelji, uporablja, oziroma je
nadgradnja nekaterih že obstoječih programskih sistemov in standardov, ki so bili razviti in
sprejeti v zadnjih petindvajsetih letih raziskav ter razvoja s področja umetne inteligence,
semantičnih tehnologij ter računalništva na splošno. Nekateri od le-teh so splošno znani in
razširjeni in kot taki niso pomembni ter relevantni za razumevanju predstavljene rešitve. Zato
se v tem poglavju posvečamo in podrobneje opisujemo le določene standarde in predhodne
rešitve, brez katerih razumevanje diplomskega dela ne bi bilo možno, oziroma bi bilo
nepopolno.
2.1. Programski sistem Cyc
Programski sistem Cyc [5] se je leta 1984 začel kot projekt v Microelectronics and Computer
Technology Corporation1, kasneje, (l. 1994) pa je se je projekt razvil v podjetje imenovano
Cycorp, Inc. [6], ki je dejavno še danes in ima tudi Evropsko podružnico, ki je stacionirana v
Ljubljani pod imenom Cycorp raziskovanje in eksperimentalni razvoj d.o.o. [7]
Cilj projekta je bil zakodiranje človeškega znanja v obliko, razumljivo in berljivo
računalnikom, kar bi služilo kot podpora in temelj pri razvoju umetne inteligence, ki bo lahko
posnemala človeško razmišljanje. Glavni del sistema Cyc je baza znanja (ang: Knowledge
Base - KB), ki trenutno obsega več kot 15.000 predikatov, 300.000 konceptov, ter 5
milijonov. trditev, ki z računalniško logiko opisujejo svet, kot ga pozna človek. Poleg baze
znanja, pa je od pomembnejših delov sistema Cyc potrebno izpostaviti še Sklepalni
mehanizem, ki sistemu omogoča sklepanje nad podatki v t.i. bazi znanja.
2.1.1. Baza znanja CycKB
Cyc se od ostalih programov za umetno inteligenco razlikuje predvsem po bazi znanja, ki je
tudi njegov najpomembnejši del in v katero je bilo do sedaj vloženih preko 900 let človeškega
dela [5]. Trenutno je večino vnesenih in medsebojno povezanih podatkov dodanih ročno in je
1 Eden izmed prvih konzorcijev za raziskovanje in razvoj računalništva v Združenih državah Amerike.
Razpuščen je bil leta 2000.
18
delo strokovnjakov iz različnih področij - od računalničarjev, do filozofov, preko
strokovnjakov za specifična področja kot so biologija, fizika in kemija, itd. Poleg ročnega
dodajanja novega znanja se v zadnjih letih, z razvojem jezikovnih tehnologij in strojnega
učenja, pojavlja vse več programskih orodij za samodejno ali polsamodejno dodajanje
podatkov v baze znanja, kot je recimo projekt Read the Web [6].
Vsebina
Podatki v bazi CycKB skušajo pokriti čim več področij človeškega življenja, še posebej
vsakdanje stvari, kot so splošne informacije o predmetih okoli nas, ter dogodki in situacije s
katerimi se ljudje srečujejo v vsakdanjem življenju. Strukturo znanja, ki je zaobjeto znotraj
baze CycKB, prikazuje Slika 1.
Slika 1: Struktura znanja v Cyc KB (preslikano iz prosojnic s predavanj M. Witbrock, ESWC 2008)
19
Baza CycKB oziroma njena ontologija2 ima piramidno strukturo, katere vrh so definicije in
znanja, ki služijo kot vezivo in podpora preostalim podatkom. Sledijo podatki o prostor-času,
fizičnih objektih, fizikalnih silah, živih bitjih, organizacijah in nad tem znanja o ljudeh in
aktivnostih, ki se jih tičejo.
Nad tem (spodnji del piramide) so splošni podatki, ki se tičejo raznih specifičnih domen, kot
so računalniška varnost, zdravstveni sistem znotraj posameznih držav itd. Pomembna lastnost
baze je, da je strukturirane v t.i. mikroteorije, ki so lahko med seboj tudi nezdružljive. Recimo
v mikroteoriji »pravljice« (ta sicer ne v CycKB ne obstaja), bi lahko živali govorile ter ljudje
leteli, kar je nekonsistentno z realnim svetom. Taka delitev omogoča uporabnikom baze
(predvsem sklepalnim modulom) določanje mikroteorij, nad katerimi poteka sklepanje, kar
jim omogoča delovanje v različnih načinih sklepanja in predvsem v različnih domenah znanja.
Osnovni gradniki baze
Zapis vsebine temelji na matematični logiki. Večinoma je to logika prvega reda (ang: first
order logic, first order predicate calculus) [7], ki zaradi potrebe po splošnosti in zapisovanju
kompleksnih dogodkov ter konceptov iz vsakdanjega sveta velikokrat preide v logiko višjih
redov. Logika prvega reda ima dovolj veliko izrazno moč, da se da v njej formalno predstaviti
celotno teorijo množic in tako rekoč skoraj celotno matematiko.
Sintakso logike prvega reda lahko razdelimo na logični in ne-logični del, pri čemer ima
logični del sintakse definiran vedno isti pomen in zaobjema naslednje simbole:
Kvantifikacijski simboli:
o (za vse )
o (obstaja )
Logični operatorji:
o (konjunkcija – logični in)
o (disjunkcija – logični ali)
o (implikacija – če, potem)
o (negacija)
2 Ontologija je formalna predstavitev znanja iz določene domene, ki je predstavljeno s koncepti ter povezavami
med njimi.
20
Enakostni simbol: =
Spremenljivke: , ...
V nasprotju z logičnimi simboli, imajo simboli ne-logičnega dela sintakse spremenljiv pomen,
ki je odvisen od interpretacije, oziroma od tega kako jih definiramo. Te simbole delimo na
naslednje.
Predikate (relacije), ki imajo določeno valenco (število argumentov). Označeni so z
velikimi tiskanimi črkami. Na primer P(x) je predikat z valenco 1, ki mu lahko
določimo interpretacijo: »x je oseba«. Kot primer predikata z valenco 2, lahko
navedemo Q(x,y), ki ga interpretiramo kot: »x je oče od y«.
Funkcije, ki imajo poljubno valenco. Ponavadi jih označujemo z malimi tiskanimi
črkami (f, g, h). Kot primer funkcije lahko navedemo f(x), ki jo lahko definiramo kot:
»oče od x«.
Konstante so po definiciji funkcije z valenco 0. Označujemo jih z malimi tiskanimi
črkami iz začetka abecede (a, b, c, ...). Primer konstante je lahko instanca razreda
oseba z imenom Peter, ki ga označimo z a.
Zapis (CycL)
Celotna baza, je zapisana v logičnem jeziku imenovanem CycL [8], ki je bil razvit znotraj
podjetja Cycorp in temelji na programskem jeziku Lisp. Njegova sintaksa omogoča izražanje
v logiki prvega reda [7] z dodatnimi razširitvami, ki omogočajo opisovanje sveta tudi v logiki
višjih redov. Osnovni gradniki jezika so, podobno kot v matematični sintaksi, konstante,
predikati, funkcije in trditve. Razlika med matematičnim zapisom ter zapisom v CycL je samo
v sintaksi.
Konstante
Konstante so označene z znakom ''#$''. Primer konstante je #$Person, ali #$SosedovPeter, ki v
našem primeru predstavljata razred oseb (vse osebe) in instanco osebe (točno določena oseba
z imenom Peter). Konstanta #$SosedovPeter je ekvivalentna konstanti »a«, kot smo jo
definirali v zgornjem odstavku. Konstante nimajo določenega nobenega pomena, dokler jih ne
povežemo z drugimi konstantami preko trditev oz. relacij - predikatov.
21
Predikati
Predikati so konstante, ki jim z določeno logično trditvijo3 definirano lastnost predikata.
Uporabljajo se za tvorjenje novih trditev in t.i. relacij med konstantami. Primer predikata,
vzetega iz opisane baze znanje je #$father, ki je CycL ekvivalent predhodno definiranega
predikata Q(x,y). Iz slike (Slika 2), vzete iz brskalnika CycL, je lepo razvidna trditev (#$isa
#$father #$DirectBinaryPredicate), ki določi konstanti funkcijo predikata. Poleg te, so na sliki
še ostale trditve, povezane s tem predikatom.
Slika 2: Primer iz CycL KB brskalnika, ki podaja vpogled v predikat #$father znotraj baze Cyc KB
3 (#$isa #$someConstant #$Predicate)
22
Funkcije
Podobno kot pri predikatih, so tudi funkcije konstante, ki jih definiramo kot le-te preko
predikata #$isa in konstante #$Function-Denotational. Za lažje razlikovanje med ostalimi
vrstami konstant, se vse funkcije v Cyc KB končajo z končnico Fn. Primer take funkcije je
#$FatherFn, ki je analogna funkciji f(x) iz primera matematične sintakse zgoraj.
Slika 3: Izpis trditev za funkcijo FatherFn iz CycKB
Pravila
Pravila so napisana kot trditve oziroma množica trditev, ki vsebujejo spremenljivke in jim
sledi nek sklep. Pravila se direktno povezujejo s sklepalnim pogonom (poglavje 2.1.2), kjer
23
preko njih Cyc s pomočjo logičnega sklepanja generira nove trditve. Za lažje razumevanje
navedimo primer:
(implies
(and
(father ?KID ?DAD)
(familyName ?DAD ?NAME))
(familyName ?KID ?NAME))
Zgornje pravilo lahko preberemo kot: »Če obstaja nek ?DAD, ki je oče od nekega otroka ?KID in se
oče piše ?NAME, potem se tudi otrok piše enako«. Predikat #$implies je CycL ekvivalent logični
implikaciji ( ), spremenljivke pa so že definirane kot univerzalno kvantificirane.
Če zapišemo trditvi: (father GiovanniBellini-TheArtist JacopoBellini-TheArtist) in
(familyName GiovanniBellini-TheArtist "Bellini"), Cyc samodejno doda trditev:
(familyName JacopoBellini-TheArtist "Bellini").
2.1.2. Sklepalni mehanizem Cyc
Sklepalni pogon Cyc (ang: Inference engine) je tesno povezan z bazo CycKB in omogoča
logično sklepanje nad vnesenimi podatki. Podpira vse vrste deduktivnega sklepanja [9],
vključno z modus ponens (forward chaining), modus tollens, univerzalno kvantifikacijo ter
eksistencialno kvantifikacijo. Poleg deduktivnega sklepanja Cyc podpira tudi sklepanje z
dedovanjem razredov (ang: inheritance) ter samodejno razvrščanje (ang: automatic
classification).
Dedukcija
Deduktivno sklepanje sestavlja ali oceni deduktivne argumente. Ti argumenti poskušajo
dokazati da nek določen sklep nujno in vedno sledi iz predhodnih predpostavk. Deduktiven
argument je veljaven, če sklep vedno sledi predpostavkam. Primer deduktivnega argumenta:
1. vsak človek ima biološkega očeta,
2. Peter je človek,
3. zatorej, Peter ima biološkega očeta.
V zgornjem primeru predpostavka 1, označuje vse objekte iz razreda »človek« z lastnostjo
»ima očeta«. Druga predpostavka (št. 2), postavi Petra kot instanco razreda »človek«, sklep
24
(št. 3) pa postavi trditev, da Peter mora imeti očeta, ker podeduje to lastnost zaradi njegove
razvrstitve v razred »človek«.
Modus ponens
Poseben primer deduktivnega sklepanja je argument tipa modus ponens. V sekvenčni notaciji
ga zapišemo kot in ima sledečo obliko:
1. če P, potem Q,
2. P,
3. zatorej, Q.
Ta argument ima dve predpostavki. Prva je pogojni stavek, ki trdi, da iz P sledi Q. Druga
predpostavka zatrjuje da P velja. Iz teh dveh predpostavk se izpelje sklep, da mora tudi Q
veljati. Primer modus ponens argumenta:
1. če je danes torek, potem grem v službo,
2. danes je torek,
3. zatorej grem v službo.
Modus tollens
Podobno kot modus ponens je tudi modus tollens poseben primer deduktivnega sklepanja. V
sekvenčni notaciji je zapisan kot in ima sledečo obliko:
1. če P, potem Q,
2. ne Q,
3. zatorej ne P.
Argument ima zopet dve predpostavki, pogojni stavek in trditev da Q ne drži, iz česar se da
razbrati logični sklep, da tudi P ne drži. Primer takega argumenta:
1. če pes vidi vsiljivca, bo lajal,
2. pes ni lajal,
3. zatorej, pes ni videl vsiljivca.
25
Univerzalna kvantifikacija
Ta tip sklepanja formalizira idejo da nekaj (nek logični predikat) drži za vse stvari določenega
tipa. Simbol za univerzalno kvantifikacijo je .
Poglejmo si trditve
Zgornji zapis zgleda kot množica konjuktivno povezanih trditev, vendar pa »itd...« ne
moremo obravnavati kot logično konjunkcijo. Zatorej zgornji zapis predelamo v obliko
in ga lahko razumemo kot: »za vsak n, velja da je 2n enako n+n.
Eksistenčna kvantifikacija
V nasprotju z univerzalno, eksistenčna kvantifikacija pove, da nek predikat drži za vsaj eno
stvar iz določene domene. Simbol eksistenčne kvantifikacije je .
Podobno kot v prejšnjem primeru, predpostavimo formulo
Takoj lahko vidimo, da je zgornji zapis množica disjunktnih trditev, razen besede »itd..«.
Trditve potem preformuliramo in dobimo
Kar lahko razumemo kot: »obstaja neko število n, za katerega velja, da je n n enako 25.
2.2. RDF
Pod kratico RDF4 [10] imenujemo leta 2004 sprejet W3C
5 standard, ki je bil zasnovan kot
meta - podatkovni model za opisovanje informacij na internetu. Razvit je bil s specifičnim
namenom, omogočiti računalnikom samodejno izmenjavo ter razumevanje nestrukturiranih
informacij. Celoten standard je osnovan okrog ideje postavljanja trditev v obliki osebek-
4 Resource Description Framework
5 World Wide Web Consorium, ki skrbi za standarde, ki pospešujejo in olajšujejo razvoj interneta
26
predikat-predmet, podobno, kot logične trditve v CycL. Ena taka trditev se v RDF besednjaku
imenuje trojka. Osebek predstavlja neko stvar definirano na internetu (ang: Resource),
predikat pa relacijo tega osebka do predmeta, ki je zopet lahko neka abstraktna internetna
stvar. Da je mogoče nek vir uporabiti v trojki, mora biti enoznačno označen s tako
imenovanim enotnim označevalnikom vira (ang: URI, Uniform Resource Identifier),
podobno, kot ima vsaka stran na internetu svoj enotni naslov vira (ang: URL, Uniform
Resource Location).
Kot ne tehnični primer v RDF trojko zapišemo stavek: »Matejev oče je Peter«.
osebku priredimo vrednost »Matej«
predikat dobi vrednost »ima očeta«,
predmet pa postane »Peter«
Večja količina RDF trditev, ki opisujejo določeno povezano celoto, predstavljajo t.i. usmerjen
RDF graf, katerega primer Kot primer prikazuje Slika 4.
Slika 4: primer vizualizacije RDF grafa, ki opisuje očetovsko relacijo med Matejem in Petrom
V praksi se RDF trojke shranjujejo v relacijskih bazah podatkov, v zadnjem času pa so se
začele pojavljati tudi t.i. RDF baze podatkov (ang: Triplestores), ki so implementirane
specifično za shranjevanje takih trojk. Primer take baze podatkov je OWLIM [13], ki je
vključena v platformo LarKC (poglavje 2.4.1).
27
2.2.1. RDF besednjak
Kot smo že omenili, ima vsak RDF osebek prirejeno enolično oznako vira - URI6, ki se
ponavadi za koncepte znotraj neke domene začne z istim URLjem. Na primer, koncepti RDF
specifikacije, našteti v nadaljevanju, se začnejo s predpono http://www.w3.org/1999/02/22-
rdf-syntax-ns#, ki je v nadaljevanju skrajšana v »rdf:«, kar je navada tudi pri večini RDF
serializacijskih formatov (naslednje podpoglavje).
Znotraj RDF specifikacije so definirani naslednji koncepti, ki služijo kot podpora definicijam
novih konceptov:
rdf:type – predikat, ki se uporablja za določanje pripadnosti instance v določen razred,
rdf:XMLLiteral – razred xml zapisov,
rdf:Property – razred relacij (predikatov),
rdf:Alt, rdf:Bag, rdf:Seq – koncepti za definiranje skupin,
rdf:List – razred RDF seznamov,
rdf:nil – instanca rdf:List razreda, ki predstavlja prazen seznam,
rdf:Statement, rdf:subject, rdf:predicate, rdf:object – koncepti, uporabljeni za
reifikacijo7.
2.2.2. RDF shema
RDF Shema (RDFS) [11] je dodatek k RDF besednjaku in definira nove koncepte, ki so
namenjeni gradnji ontologij in tako odprejo možnost pisanja le-teh v RDF formatu. Koncepte
definirane v RDFS, razdelimo na naslednje razrede:
rdfs:Resource – Glavni razred, oz. razred vsega. Vse stvari opisane v RDF, so
instance tega razreda,
rdfs:Class – Razred razredov. Če je neka konstanta instanca tega razreda, pomeni da
je tudi sama razred,
rdfs:Literal – razred vrednosti kot so besedila in številke,
6 Uniform Resource Identifier
7 Reifikacija znotraj RDF je referiranje na trditve same. Vsaka trditev dobi svoj URI naslov ter je lahko
uporabljena v drugih trditvah kot osebek ali predmet.
28
rdfs:Datatype – razred vseh podatkovnih tipov. Je hkrati instanca in po podrazred
razreda rdfs:Class. Vsaka instanca rdfs:Datatype je tudi podrazred od rdfs:Literal.
Predikati, ki so instance razreda rdf:Property:
rdfs:domain – ta predikat definira razred kateremu mora pripadati osebek pri trditvi v
kateri kot predikat nastopa predmet prve trditve,
rdfs:range – definira razred, kateremu mora pripadati predmet pri trditvi v kateri kot
predikat nastopa predmet prve trditve,
rdfs:subClassOf – omogoča opisovanje hierarhije razredov,
rdfs:subPropertyOf - instanca rdf:Property ki uporabljena v trditvi pove da so vse
stvari, ki so povezane z enim predikatom, povezane tudi z drugim,
rdfs:label – instanca razreda rdf:Property, ki se lahko uporabi za dodajanje človeku
prijaznega imena določenega RDF elementa,
rdfs:comment – instanca razreda rdf:Property, ki se uporabi za človeku prijazen opis
RDF elementa.
2.3. SPARQL
SPARQL8 [12] je povpraševalni jezik, namenjen povpraševanju in iskanju po RDF stavkih in
grafih. SPARQL poizvedba je sestavljena iz vzorcev trojk (ang: triple patterns), konjunkcij in
disjunkcij. SPARQL poizvedbe so skupaj z RDF zbirkami znanja semantična analogija SQL
poizvedbam in relacijskim podatkovnim zbirkam.
2.3.1. Primeri SPARQL poizvedb
Primer 1:
Prvi primer, vzet iz SPARQL specifikacije, je preprosta poizvedba, ki poišče naslov knjige iz
podanega podatkovnega grafa.
8 Rekurzivno definirana kratica za SPARQL Protocol and RDF Query Language
29
Podani podatki:
<http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title>
"SPARQL Tutorial"
Poizvedba:
SELECT ?title
WHERE
{
<http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title>
?title .
}
Rezultati:
title
-------------------
"SPARQL Tutorial"
Primer 2:
Kompleksnejša poizvedba, ki sprašuje po dveh spremenljivkah hkrati (ime ter e-mail naslov)
ter uporablja imenovane grafe.
Podani podatki:
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:a foaf:name "Johnny Lee Outlaw" .
_:a foaf:mbox <mailto:jlow@example.com> .
_:b foaf:name "Peter Goodguy" .
_:b foaf:mbox <mailto:peter@example.org> .
_:c foaf:mbox <mailto:carol@example.org> .
Poizvedba:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
WHERE
{ ?x foaf:name ?name .
?x foaf:mbox ?mbox }
30
Rezultati:
name mbox
---------------------------------------------------------------------------
"Johnny Lee Outlaw" <mailto:jlow@example.com>
"Peter Goodguy" <mailto:peter@example.org>
2.4. LarKC
LarKC [4] (Large Knowledge Collider), je platforma, ki nastaja kot del aktivnosti evropskega
projekta LarKC, ki je sofinanciran v 7. okvirnem programu. Osnovna ideja in cilj projekta
LarKC je izgradnja eksperimentalne računalniške platforme, namenjene logičnemu sklepanju
nad velikimi količinami podatkov. Zaradi problemov paralelizacije (sočasnega izvajanja na
več računalnikih), nedosegljivosti določenih programskih orodij in računske zahtevnosti
sklepalnih pogonov, je računalniško sklepanje nad večjimi količinami podatkov zahtevalo
veliko količino dodatnega inženiringa in dela, nepovezanega s samim problemom sklepanja.
LarKC platforma poskuša te probleme in stroške znižati ter tako približati računalniško
sklepanje širšemu krogu raziskovalcev in tudi razvijalcev programske opreme.
Pri računalniškem sklepanju imamo problem pridobivanja, prestrukturiranja in izluščenja
podatkov ki jih potrebujemo za sklepanje, na koncu pa je potrebno rezultat še oceniti, podatke
shraniti in po potrebi ponoviti katerega od korakov (Slika 5).
31
Slika 5: koraki pri računalniškem sklepanju z uporabo LarKC platforme
Ključna lastnost platforme LarKC je, da omogoča ločeno izvajanje zgoraj opisanih korakov,
ki vodijo do sklepanja in da skrbi za pretok podatkov med njimi. Na tak način postane
sočasno izvajanje sklepanja veliko lažje, poleg tega je omogočeno kombiniranje in testiranje
samega procesa sklepanja z različnimi kombinacijami vmesnih korakov.
Tukaj je potrebno poudariti, da sama platforma ne omogoča računalniškega sklepanja, ampak
samo nudi podporo le-temu. Uporabniki platforme morajo implementirati oziroma uporabiti
že obstoječe korake kot LarKC vtičnike, odvisno od problema ki ga želijo reševati.
Trenutno je kot LarKC združljivih registriranih nekaj čez 25 vtičnikov [13], obstaja pa še
kakšne 10 nedokončanih, ki so na voljo v repozitoriju. To je veliko, če upoštevamo, da razvoj
platforme LarKC še ni v celoti dokončan. Za enkrat večina vtičnikov rešuje nek specifičen
problem in ima specificiran en ali dva načina medsebojnega povezovanja (toka dela), kar
Identifikacija
•Relevantni viri podatkov
•Relevantna vsebina
•Relevanten kontekst
Transformacija
•Izluščenje informacij
•Računanje statistike
•Transformiranje v logiko
Izbira
•Relevantni problemi
•Relevantne metode
•Relevantni podatki
Sklepanje
•Verjetnostno sklepanje
•Klasifikacije
•Kontekstualno sklepanje
Odločitev
•Dovolj odgovorov?
•Dovolj natančni odgovori?
•Poteklo preveč časa? Cena?
32
potem preko »management interface« komponente pošlje platformi (Slika 7). Naštete
specifikacije tokov dela so napisane ročno, kar prinese kar nekaj dodatnega dela. Za vsak tip
vhodne poizvedbe je potrebno sestaviti nov tok dela, kar je zelo zamudno, še posebej v
primerih ko ne vemo točno, kakšna bo vhodna poizvedba.
Platforma sama je razvita na vrhu okrnjenega sistema Cyc in je v celoti napisana v
programskem jeziku Java, tako da jo je možno uporabljati na kateremkoli operacijskem
sistemu in ima Apache 2.0 licenco [16] ter je skupaj z izvorno kodo na voljo na sourceforge
[17] internet strani.
2.4.1. Arhitektura
Celotna arhitektura platforme LarKC je nastavljena tako, da čim bolj podpira korake, ki so
potrebni za uspešno uporabo računalniškega sklepanja na osnovi logike (Slika 5). Definiranih
je pet različnih tipov vtičnikov (po en tip za vsakega izmed korakov v procesu sklepanja).
Vtičniki so zaobjeti v javansko strukturo, imenovano »plug-in manager«, ki skrbi za
komunikacijo med njimi.
Taka separacija omogoča platformi, da obravnava vtičnike, ki tečejo lokalno popolnoma
enako, kot vtičnike, ki tečejo na oddaljenem sistemu. Komunikacija med njimi poteka
izključno v RDF formatu, ki je tudi standarden podatkovni format za celotno platformo.
Vsak izmed vtičnikov ima dostop do t.i. podatkovne (ang: »Data Layer«) komponente, ki je
zelo zmogljiva RDF podatkovna zbirka podatkov (ang: Triplestore - poglavje 2.2). OWLIM
zbirka podatkov je do preostale platforme izpostavljena preko podatkovnega vmesnika (ang:
»Data Layer API«), kar omogoča njeno ločitev in zamenjavo z drugo RDF podatkovno
zbirko.
Poleg zgoraj naštetih komponent sta pomembnejši še komponenta za podporo tokovom dela
oz. Poganjalec (ang: Executor), ki skrbi za povezovanje vtičnikov, njihovo instanciiranje ter
povezavo tako sestavljenih tokov dela z zunanjim svetom preko vstopnih točk (ang:
endpointov). Komponenta za registracijo vtičnikov, imenovana register vtičnikov (ang: Plug-
in Registry) pa vodi seznam vtičnikov, ki so na voljo platformi in je namenjena shranjevanju
podatkov o le-teh. Omenjeni komponenti igrata pomembno vlogo v tej diplomski nalogi in jih
33
zato podrobneje opisujemo v ločenih poglavjih. Komponenta za registracijo vtičnikov je bila
razvita v sklopu te diplomske naloge.
Slika 6: Arhitektura LarKC platforme kot je podana v LarKC_WP5_D5_3_1_V1_0.pdf
2.4.2. Vtičniki
Glede na tipične korake v procesu računalniškega sklepanja (Slika 5), ima platforma LarKC
pet tipov vtičnikov. Čeprav ima vseh pet tipov enako javansko obliko (spodnji izsek kode) in
se lahko vsak izmed njih pojavi kjerkoli v procesu sklepanja, se konceptualno razlikujejo.
Vsak tip vtičnika ustreza enemu izmed korakov sklepanja in opravlja neko ustrezno funkcijo v
sklopu reševanja določenega problema.
34
Primer skeleta LarKC vtičnika:
package eu.larkc.plugin.decide;
import org.openrdf.model.URI;
import eu.larkc.core.data.SetOfStatements;
import eu.larkc.plugin.Plugin;
public class SmartDecider extends Plugin{
public SmartDecider(URI _pluginName) {
super(_pluginName);
}
@Override
public void initialise(SetOfStatements workflowDescription) {
// TODO Auto-generated method stub
}
@Override
protected SetOfStatements invokeInternal(SetOfStatements input) {
// TODO Auto-generated method stub
return null;
}
@Override
public void shutdown() {
// TODO Auto-generated method stub
}
}
Poleg javanske kode, mora pravilno napisan vtičnik vsebovati še dve datoteki. Prvo, s
končnico .wsdl9, ki ima popolnoma enako obliko kot wsdl opisi za spletne servise in opisuje
ime vtičnika, njegovo lokacijo, ter URI njegovega semantičnega opisa. Drugo pa s končnico
.rdf, v kateri je v notaciji N3 zapisan semantični opis vtičnika.
9 Semantically annotated WSDL. Standard za semantično opisovanje spletnih servisov
35
Primer .wsdl opisa vtičnika:
<wsdl:description>
<wsdl:interface name="Decider"
sawsdl:modelReference="http://larkc.eu/plugin#Decider">
</wsdl:interface>
<wsdl:binding name="larkcbind" type="http://larkc.eu/wsdl-binding" />
<wsdl:service name="urn:SmartDecider" interface="decider"
sawsdl:modelReference="http://larkc.eu/plugin#SmartDecider" >
<wsdl:endpoint location="java:eu.larkc.plugin.decide.SmartDecider" />
</wsdl:service>
</wsdl:description>
Za to diplomsko delo je predvsem pomembna druga (.rdf) datoteka, ki vsebuje semantični
opis vtičnika, kar obravnavamo ločeno za vsak vtičnik. Pri .wsdl opisu je vredno omeniti
»<wsdl:service name="urn:SmartDecider"...«, ki določa ime vtičnika,
»sawsdl:modelReference="http://larkc.eu/plugin#SmartDecider"...«, ki kaže na
njegov semantični model (naslednje podpoglavje), ter »<wsdl:endpoint
location="java:eu.larkc.plugin.decide.SmartDecider"«, ki se ujema s prvo vrstico v
primeru javanske kode (zgornji izsek kode) in kaže na lokacijo, kjer se implementacija
vtičnika dejansko nahaja.
V nadaljevanju podrobneje opisujemo posamezne tipe vtičnikov in njihove privzete
semantične opise, ki opišejo le tip vtičnika. Za resnejšo uporabo semantičnega opisa je
potrebno le-tega dopolniti, kar je domena te diplomske naloge.
Vtičnik tipa »Decider«
Vtičniki tega tipa so namenjeni opazovanju in kontroliranju ostalih vtičnikov. Lahko jih
postavimo kamorkoli v tok dela, kjer spremljajo pretok in pravilnost podatkov ter po potrebi
kontrolirajo tok oziroma lahko vanj tudi dodajajo ter odstranjujejo vtičnike.
36
Semantični opis v RDF N3 notaciji:
@prefix larkc: <http://larkc.eu/plugin#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
larkc:SmartDecider
rdf:type rdfs:Class ;
rdfs:subClassOf larkc:Decider .
Privzeti semantični opis vtičnika vsebuje le dve trditvi in sicer da je vtičnik z imenom
SmartDecider primer (ang: instanca) razreda rdf:Class, kar pomeni da je tudi sam razred, ter
da je hkrati podrazred razreda larkc:Decider.
Vtičnik tipa »Identifier«
Vtičniki tipa »Identifier« so mišljeni kot identifikatorji virov podatkov. V tokovih dela so v
večini primerov na začetku, ter služijo kot vir podatkov za ostale vtičnike.
Semantični opis v RDF N3 notaciji:
@prefix larkc: <http://larkc.eu/plugin#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
larkc:SomeIdentifier
rdf:type rdfs:Class ;
rdfs:subClassOf larkc:Identifier.
Vtičnik tipa »Transformer«
Vtičniki tega tipa služijo kot pretvorniki podatkov. V večini primerov je to pretvorba nekih
ne-RDF podatkov, ki jih vračajo določeni vtičniki tipa »Identifier«, v naravno RDF obliko,
oziroma logiko.
Semantični opis v RDF N3 notaciji:
@prefix larkc: <http://larkc.eu/plugin#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
larkc:SomeTransformer
rdf:type rdfs:Class ;
rdfs:subClassOf larkc:InformationSetTransformer.
Vtičnik tipa »Selecter«
Vtičniki tega tipa so namenjeni izbiranju relevantnih podatkov (RDF trditev) izmed celotne
množice ki se pretaka preko njih. V večini primerov izberejo podatke glede na vhodno
poizvedbo (SPARQL poizvedba).
37
Semantični opis v RDF N3 notaciji:
@prefix larkc: <http://larkc.eu/plugin#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
larkc:SomeSelecter
rdf:type rdfs:Class ;
rdfs:subClassOf larkc:Selecter.
Vtičnik tipa »Reasoner«
Vtičniki tega tipa so po navadi na koncu delovnega toka in dobijo že prečiščene in izbrane
podatke, nad katerimi potem izvedejo sklepanje in poskusijo odgovoriti na vhodno poizvedbo.
Sama implementacija sklepanja je popolnoma odprta in je odvisna od razvijalca vtičnika.
Semantični opis v RDF N3 notaciji:
@prefix larkc: <http://larkc.eu/plugin#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
larkc:SomeReasoner
rdf:type rdfs:Class ;
rdfs:subClassOf larkc:Reasoner.
2.4.3. Komponenta za sestavljanje tokov dela
Ta komponenta platforme LarKC je namenjena sestavljanju ter izvajanju tokov dela.
Povezana je, na eni strani s komponento »Register vtičnikov« (ang: Plug-in Registry), na
drugi pa preko »Upravljalni vmesnik« (ang: nagement interface) komponente, z uporabnikom
ki v RDF obliki definira navodilo s seznamom vtičnikov in kako so povezani med sabo, kar
imenujemo tok dela.
Ko uporabnik pošlje navodilo platformi preko »Upravljalni vmesnik« storitve, se le-to pošlje
do komponente »Poganjalec«, ki preko registra vtičnikov dobi instance vtičnikov, ki jih
potem glede na RDF navodila poveže med sabo ter požene. Opisani koraki so prikazani na
sliki (Slika 7). In sicer v točkah 2, 3, 4 in 5.
38
Slika 7: LarKC Arhitektura z vidika izvajanja tokov dela (preslikano iz prosojnic LarKC delovnega gradiva).
Primer RDF opisa toka dela v XML RDF notaciji:
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:larkc="http://larkc.eu/plugin#">
<rdf:Description rdf:nodeID="id1">
<rdf:type rdf:resource="urn:NewsIdentifier"/>
<larkc:pluginConnectsTo rdf:nodeID="rs1"/>
</rdf:Description>
<rdf:Description rdf:nodeID="rs1">
<rdf:type rdf:resource="urn:TextPrismReasoner"/>
</rdf:Description>
<rdf:Description rdf:nodeID="endpoint1">
<larkc:endpointType rdf:resource="urn:eu.larkc.endpoint.push"/>
</rdf:Description>
</rdf:RDF>
Zgornji primer poveže med seboj dva vtičnika in sicer urn:NewsIdentifier z
urn:TextPrismReasoner. Skupaj tvorita tok dela, na katerega je potem dodana še vstopna
točka (ang: endpoint) z imenom urn:eu.larkc.endpoint.push.
39
3. Predlagana rešitev
Namen pričujočega diplomskega dela je avtomatizacija reševanja opisanega problema
povezovanja, kar je možno zaradi semantičnih opisov vtičnikov (semantiko le-teh je potrebno
nadgraditi) ter registra vtičnikov, ki temelji na kombinaciji baze CycKB in Cyc sklepalnega
mehanizma. Tako rešitev je potem mogoče vgraditi v platformo LarKC kot vtičnik tipa
»Decider«, ki samodejno generira RDF opise tokov dela in služi kot vmesni člen med
vhodnimi poizvedbami, ter dejanskim tokom dela, potrebnim za odgovor določene poizvedbe
(slika: Slika 8).
Slika 8: Arhitektura z vrinjenim "Decider" vtičnikom, ki sam določa nove tokeve dela (preslikano iz prosojnic
LarKC delovnega gradiva).
40
3.2. Register vtičnikov
Register vtičnikov je podkomponenta LarKC platforme, ki služi shranjevanju ter
manipuliranju podatkov o vtičnikih. Znotraj platforme je na voljo preko API vmesnika, kjer
so izpostavljene najpogostejše funkcije manipuliranja z vtičniki in pa splošna funkcija ki
sprejema poljubne poizvedbe glede vtičnikov. Register vtičnikov temelji na okrnjeni verziji
Cyc KB (brez dodanega znanja) ter okrnjeni verziji Cyc sklepalnega pogona in torej sprejema
poizvedbe podane v CycL obliki.
Slika 9: Arhitektura registra vtičnikov
Ob zagonu platforme LarKC, le-ta pregleda seznam vtičnikov, ki so na voljo, prebere njihove
semantične opise ter jih shrani v register vtičnikov. Ker so vtičniki opisani v N3 RDF obliki,
je potrebno RDF trditve najprej prevesti v CycL trditve, kar je enostavno, saj se RDF in RDFs
(poglavje 2.2.2) koncepte ter predikate preprosto preslika v pripadajoče CycL verzije.
41
RDF oblika CycL oblika
rdf:Type #$isa
rdf:Property #$BinaryPredicate
rdfs:Class #$Collection
rdfs:Resource #$Thing
rdfs:Literal #$SubLAtomicTerm
rdfs:domain #$arg1Isa
rdfs:range #$arg2Isa
rdfs:subClassOf #$genls
rdfs:subPropertyOf #$genlPreds
rdfs:label #$prettyString
rdfs:comment #$comment
Tabela 1: Preslikava iz RDF v CycL
Na primer RDF trditev
larkc:GoogleCalendarIdentifier rdf:type rdfs:Class
se pretvori v CycL trditev
(#$larkc-GoogleCalendarIdentifier #$isa #$Collection)
Za lažje razumevanje si oglejmo primer celotnega nerazširjenega RDF semantičnega opisa
vtičnika:
@prefix larkc: <http://larkc.eu/plugin#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
larkc:GoogleCalendarIdentifier
rdf:type rdfs:Class ;
rdfs:subClassOf larkc:Identifier.
42
ki potem skupaj z vnešenimi podatki is .wsdl datotek znotraj registra vtičnikov izgleda:
Slika 10: Primer opisa vtičnika znotraj registra vtičnikov (preslikano iz CycKB brskalnika)
3.3. LarKC ontologija
Poleg semantičnih opisov vtičnikov se ob zagonu platforme v register vtičnikov vključi tudi
LarKC ontologija, kjer so definirani glavni koncepti ter razredi, ki služijo kot podpora za
opise vtičnikov. Osnovna ontologija, ki jo bomo kasneje razširili, je zelo enostavna in opisuje
samo strukturo ter hierarhijo javanskih RDF razredov znotraj platforme in pa vrste vtičnikov.
Nahaja se v datoteki LarKC.rdf, za lažje razumevanje pa namesto izpiska iz datoteke
prikažemo grafično predstavitev RDF trditev:
43
ClassResource
ClassInformationSet
subClassOf
ClassKeywordQuery
subClassOf
ClassTriplePatternQuery
ClassSPARQLQuery
subClassOf
ClassPlug-in
subClassOf
subClassOf
ClassDecider
ClassSelecter
ClassQueryTransformer
ClassInfoSetTransformer
ClassIdentifier
subClassOf
subClassOfsubClassOf
subClassOf subClassOf
subClassOf
ClassReasoner
ClassBoolInfoSet
ClassNaturalLanguageDoc
ClassVariableBinding
ClassXMLDocument
subClassOf
subClassOf
subClassOf
subClassOf
ClassSetOfStatements
subClassOf
ClassDataSet
subClassOf
ClassLabelledGroupOfStatements
ClassRdfGraph
subClassOf
subClassOf
ObjectProperty
hasEndpoint
Domain-genls
Range
ObjectProperty
hasUriDomain-genls
Range
ClassQuery
ClassString
Slika 11: Osnovna LarKC ontologija
3.4. Povezovanje na nivoju vhodno-izhodnih podatkovnih tipov
Znotraj platforme se skupine RDF trditev lahko pojavljajo v različnih javanskih strukturah.
Trditve so lahko razporejene v »SetOfStatements«, ki je samo seznam vseh trditev,
»RdfGraph«, ki je skupina medsebojno povezanih trditev, »DataSet«, ki je skupina RDF
grafov, ter »LabelledGroupOfStatements«, ki je imenovana podizbira iz strukture
»SetOfStatements«.
Naštete strukture so postavljene v medsebojno hierarhijo (Slika 11). Pri povezovanju
vtičnikov je potrebno paziti da vhod naslednjega vtičnika lahko prebere strukturo naslednjega
vtičnika (hierarhična pozicija strukture mora biti v naslednjem vtičniku ista ali nižja). To je
prvi problem na katerega je potrebno biti pozoren pri samodejnem povezovanju med vtičniki.
Recimo, če nek vtičnik vrača trditve v obliki »RDFGraph«, jih lahko pošlje le vtičniku, ki
sprejema ali »RDFGraf«, ali pa »SetOfStatements«, ki je njegov nad razred.
Za reševanje tega problema vpeljemo v LarKC ontologijo dva nova predikata
(»hasInputType« ter »hasOutputType«), s katerima opišemo vhod in izhod vtičnika, ter
predikat »pluginByDataConnectsTo«, ki ga uporabimo kot rezultat sklepanja, kadar je
mogoče povezati določena vtičnika.
44
Predikat »hasInputType«
V LarKC.rdf dodamo tri trditve, ki opišejo da je »hasInputType« predikat, ki ima za povedek
podrazrede tipa »larkc:Plugin«, za predmet pa podrazrede tipa »larkc:Resource«.
larkc:hasInputType rdf:type rdf:Property ;
ocyc:arg1Genl larkc:Plugin ;
ocyc:arg2Genl larkc:DataResource .
Predikat »hasOutputType«
Podobno kot »hasInputType«, definiramo tudi »hasOutputType«.
larkc:hasOutputType rdf:type rdf:Property;
ocyc:arg1Genl larkc:Plugin ;
ocyc:arg2Genl larkc:DataResource .
Predikat »pluginByDataConnectsTo«
Tudi predikat »pluginByDataConnectsTo« definiramo znotraj Larkc.rdf.
larkc:pluginByDataConnectsTo rdf:type owl:TransitiveProperty;
ocyc:arg1Genl larkc:Plugin ;
ocyc:arg2Genl larkc:Plugin .
Vendar pa ta predikat ni mišljen za uporabo znotraj semantičnih opisov vtičnikov, ampak
znotraj registra vtičnikov kot rezultat sklepanja. Pri definiciji je pomembna prva trditev, ki
namesto »rdf:Property« predmeta, uporabi »owl:TransitiveProperty«. To priredi predikatu
tranzitivno lastnost, kar uporabimo kasneje.
Za sprožitev logičnega sklepanja v tem primeru uporabimo logično pravilo (poglavje 2.1.2),
ki se samodejno sproži vsakič ko se v register vtičnikov vnesejo podatki o novem vtičniku:
(#implies
(#$and
(#$genls ?X #$larkc-Plugin)
(#$genls ?Y #$larkc-Plugin)
(#$larkc-hasOutputType ?X ?TYPE)
(#$larkc-hasInputType ?Y ?TYPE1)
(#$genls ?TYPE ?TYPE1))
(#$larkc-pluginByDataConnectsTo ?X ?Y))
45
Zgoraj napisano pravilo preberemo kot:
Če je ?X podrazred LarKC vtičnika IN
?Y tudi podrazred LarKC vtičnika IN
?X na izhod vrača ?TYPE IN
?Y na vhod sprejema ?TYPE1 IN
je TYPE podrazred TYPE1 POTEM
se vtičnik ?X lahko poveže z vtičnikom ?Y.
Za predstavo in primerjavo z osnovno ontologijo, si na naslednji sliki (Slika 12) oglejmo
ontologijo z novo vpeljanimi predikati ter pravilom.
Slika 12:Dopolnjena LarKC ontologija s predikati za opis vhodno-izhodnih tipov RDF podatkov
46
Z novo vpeljanimi predikati, dopolnimo opise vtičnikov:
@prefix larkc: <http://larkc.eu/plugin#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
larkc:GoogleCalendarIdentifier
rdf:type rdfs:Class ;
rdfs:subClassOf larkc:Identifier;
larkc:hasInputType larkc:SPARQLQuery;
larkc:hasOutputType larkc:RDFGraph.
Ob vnosu takega opisa vtičnika, zgoraj opisano pravilo sproži Cyc sklepalni pogon, ki v
register vtičnikov med povezljive vtičnike samodejno vpelje nove trditve tipa
(#$pluginByDataConnectsTo #$plugin1 #$plugin2).
Za preizkušnjo lahko uporabimo API vmesnik registra vtičnikov ter mu pošljemo poizvedbo
za vse možne kombinacije vtičnikov, ki na vhod dobijo SPARQL poizvedbo, kot rezultat pa
vrnejo RDF objekt tipa »variableBinding«:
(#$and
(#$larkc-hasInputType ?X #$larkc-SPARQLQuery)
(#$larkc-pluginByDataConnectsTo ?X ?Y)
(#$larkc-hasOutputType ?Y #$larkc-VariableBinding)))
V tem primeru smo v registru vtičnikov imeli 10 vtičnikov, rezultat pa sta bila dve
kombinaciji in sicer:
(#$SPARQLToKeywordQueryTransformer #$larkc-pluginByDataConnectsTo
#$SPARQLQueryEvaluationReasoner)
(#$SPARQLToTriplePatternQueryTransformer
#$larkc-pluginByDataConnectsTo #$SPARQLQueryEvaluationReasoner)
V rezultatu je samo začetni ter končni vtičnik, kar se zgodi zaradi tranzitivnosti predikata
»#$larkc-pluginByDataConnectsTo«. Pri vsakem sklepanju Cyc sklepalni pogon shrani tudi
dokaz ter pot po kateri je prišel do določenega rezultata, s čimer dobimo celoten tok dela.
47
SPARQLToKeywordQueryTransformer
SindiceKeywordIdentifier
pluginByDataConnectsTo
SwoogleTermSearchIdentifier
pluginByDataConnectsTo
pluginByDataConnectsTo
pluginByDataConnectsTo
SPARQLToTripplePatterntQueryTransformer
FirstDataSetOnlySelecter
CycSelecter
SPARQLQueryEvaluationReasoner
pluginByDataConnectsTo
SwoogleOntologySearchIdentifier
pluginByDataConnectsTo
GrabEverythingSelecter
SwoogleDocumentSearchIdentifier
SindiceTripplePatternIdentifier
Slika 13: Množica možnih povezav med vtičniki kot rezultat sklepanja glede vhodno-izhodnih tipov podatkov
Zgoraj omenjeni pristop nam še ne reši celotnega problema, saj se na tak način da povezati
mnogo različnih vtičnikov ki pa ni nujno da vrnejo smiseln rezultat (Slika 13). Omenjeni
pristop je prvi korak na poti do samodejnega povezovanja vtičnikov in nam lahko zelo
zmanjša iskalni prostor pri končnem sestavljanju poteka dela.
3.5. Iskanje primernih vtičnikov glede na vhodno poizvedbo
Poleg različnih tipov vhodnih in izhodnih RDF struktur naletimo pri samodejnem
povezovanju še na dodaten problem. Kot smo omenili v prejšnjih poglavjih, v našem primeru
na vhod LarKC platforme dobimo SPARQL poizvedbo, ki je poljubna. Glede na to poljubno
poizvedbo je torej potrebno iz semantičnih opisov vtičnikov sklepati na njihovo sposobnost in
ustreznost za uporabljanje pri odgovarjanju na določeno SPARQL poizvedbo.
48
Kot rešitev vpeljemo v LarKC ontologijo nekaj novih razredov ter predikatov skupaj z
načinom, kako se poljubno SPARQL poizvedbo zapiše v obliki logičnih predikatov, nad
katerimi poteka računalniško sklepanje.
Zaradi preglednosti ter lažjega razumevanja se bomo opirali na primer dveh SPARQL
poizvedb ter šestih obstoječih vtičnikov.
3.5.1. Serializacija SPARQL poizvedbe v RDF/CycL
Za upoštevanje vhodne SPARQL poizvedbe pri sestavljanju toka dela, moramo le-to najprej
predelati v logično obliko, dodati v register vtičnikov oziroma bazo CycKB in jih vključiti ter
povezati v preostalo ontologijo. Ta proces imenujemo serializacija.
Za primer vzemimo naslednjo SPARQL poizvedbo, ki sprašuje po vseh dogodkih, ki jih ima
oseba Peter vnesene v koledar:
Select ?e WHERE
{
?p rdf:Type cyc:Person.
?p cyc:hasLoginData »Peter,peter@gmail.com,password«.
?p cyc:scheduleFor ?s.
?s cyc:scheduledEvents ?e.
}
Če pogledamo zgornjo poizvedbo, vidimo da je sestavljena iz ukaza »Select«, izhodne
spremenljivke ?e ter ukaza »WHERE«, ki mu sledijo štiri trditve (trojke).
V LarKC ontologiji imamo že definiran razred SPARQLQuery (poglavje 3.3). Le tega bomo
uporabili za osnovo, ter ga nadgradili z razredom, ki definira spremenljivke, trojke ter
predikate ki le-te vežejo na določeno instanco SPARQL poizvedbe.
Podobno kot je definiran SPARQLQuery razred, vpeljemo še razred Trojk
larkc:sparql-Triple rdf:type rdfs:Class.
Ter razred spremenljivk:
larkc:sparql-Variable rdf:type rdfs:Class.
49
Ker vemo, da ima vsaka SPARQL poizvedba izhodno spremenljivko, definirajmo še predikat,
ki bo ponazoril to relacijo:
larkc:sparql-hasOutputVariable rdf:type rdf:Property;
rdfs:domain larkc:SPARQLQuery;
rdfs:range larkc:sparql-Variable.
Podobno naredimo za kombinacijo trojke in SPARQL poizvedbe:
larkc:sparql-hasTriple rdf:type rdf:Property;
rdfs:domain larkc:SPARQLQuery;
rdfs:range larkc:sparql-Triple.
Prav tako vemo, da ima vsaka trojka osebek, predikat ter predmet (poglavje 2.2), zatorej
definiramo sledeče relacije:
larkc:sparql-hasSubject rdf:type rdf:Property;
rdfs:domain larkc:sparql-Triple;
rdfs:range rdfs:Resource.
larkc:sparql-hasPredicate rdf:type rdf:Property;
rdfs:domain larkc:sparql-Triple;
rdfs:range rdfs:Resource.
larkc:sparql-hasObject rdf:type rdf:Property;
rdfs:domain larkc:sparql-Triple;
rdfs:range rdfs:Resource.
50
Grafično ponazoritev tako dopolnjene LarKC ontologije prikazuje naslednja slika.
Slika 14: Dopolnjena LarKC ontologija z razredi ter predikati namenjeni za serializacije SPARQL poizvedb
51
Ko imamo definiran besednjak za serializacijo, lahko pretvorimo zgornjo SPARQL
poizvedbo:
larkc:v1 rdf:type larkc:sparql-Variable.
larkc:v2 rdf:type larkc:sparql-Variable.
larkc:v3 rdf:type larkc:sparql-Variable.
larkc:triple1 rdf:type larkc:sparql-Triple;
larkc:hasSubject larkc:v1;
larkc:hasPredicate rdf:type;
larkc:hasObject cyc:Person.
larkc:triple2 rdf:type larkc:sparql-Triple;
larkc:hasSubject larkc:v1;
larkc:hasPredicate cyc:hasLoginData;
larkc:hasObject "luka@gmail.com,uime,geslo".
larkc:triple3 rdf:type larkc:sparql-Triple;
larkc:hasSubject larkc:v1;
larkc:hasPredicate cyc:scheduleFor;
larkc:hasObject larkc:v2.
larkc:triple4 rdf:type larkc:sparql-Triple;
larkc:hasSubject larkc:v2;
larkc:hasPredicate cyc:scheduledEvents;
larkc:hasObject larkc:v3.
larkc:sparql1 rdf:type larkc: SPARQLQuery;
larkc: sparql-hasOutputVariable larkc:v3;
larkc:hasTriple larkc:triple1;
larkc:hasTriple larkc:triple2;
larkc:hasTriple larkc:triple3;
larkc:hasTriple larkc:triple4;
Na podoben način se lotimo še drugega primera SPARQL poizvedbe, ki poizveduje po
podjetjih, ki so bila omenjena v članku na nekih spletnih novicah:
SELECT ?company WHERE
{
?company cyc:mentionedInArticle "http://news.si/article.html".
?company rdf:type cyc:PubliclyHeldCorporation
}
52
Ker smo besednjak za serializacijo že predhodno definirali ter vgradili v LarKC ontologijo,
lahko preprosto serializiramo.
larkc:v1 rdf:type larkc:sparql-Variable.
larkc:triple1 rdf:type larkc:sparql-Triple;
larkc:hasSubject larkc:v1;
larkc:hasPredicate cyc:mentionedInArticle;
larkc:hasObject "http://shodan.ijs.si/article.txt").
larkc:triple2 rdf:type larkc:sparql-Triple;
larkc:hasSubject larkc:v1;
larkc:hasPredicate rdf:type;
larkc:hasObject cyc:PubliclyHeldCorporation.
larkc:sparql2 rdf:type larkc:SPARQLQuery;
larkc: sparql-hasOutputVariable larkc:v1;
larkc:hasTriple larkc:triple1;
larkc:hasTriple larkc:triple2;
3.5.2. Opis vhoda in izhoda vtičnikov glede na vsebino
V predhodnem podpoglavju (poglavje 3.4), smo pokazali opisovanje ter povezovanje
vtičnikov glede na tip vhodno-izhodnih podatkov, kar ni dovolj za enolično določanje
povezav med vtičniki in prav tako ne, za določitev povezave med SPARQL poizvedbo ter
vtičniki.
Za uspešno določanje povezave med SPARQL poizvedbo ter pripadajočimi vtičniki je poleg
serializacije poizvedbe potrebno pravilno opisati tudi vsebino podatkov, ki jih vtičnik
pričakuje na vhodu, ter vsebino, ki jo vrača na izhodu. To storimo na podoben način, kot smo
serializirali poizvedbe.
Vtičniki prejemajo in vračajo RDF trditve, kar nam zelo olajša delo, saj s tem sprejemajo ter
oddajajo določene vrste osebkov, predikatov ter objektov. Za primer vzemimo obstoječi
vtičnik »GoogleCalendarIdentifier«, ki je namenjen pridobivanju podatkov iz podanega
GoogleCalendar računa. Za pravilno delovanje potrebuje na vhodu podatke o uporabniških
računih, na izhod pa vrača dogodke, ki so povezani z določenim uporabniškim računom. V
analogiji s trojkami lahko torej opišemo vhodne podatke vtičnika kot:
?p rdf:Type cyc:LegalAgent
?p cyc:hasLoginData ?loginData
53
Ter izhodne podatke:
?e rdf:Type cyc:Event
?s cyc:scheduledEvents ?e
?e cyc:scheduleFor ?p
Preden zgornje trojke povežemo z opisom vtičnika, moramo v obstoječo LarKC ontologijo
dodati dva predikata, ki s trditvijo povežeta določen vtičnik ter trojko, ki opisuje vhod in/ali
izhod:
larkc:hasInput rdf:type rdf:Property ;
cyc:arg1Genl larkc:Plugin ;
rdfs:range larkc:sparql-Triple .
larkc:hasOutput rdf:type rdf:Property ;
cyc:arg1Genl larkc:Plugin ;
rdfs:range larkc:sparql-Triple .
Če sledimo primeru »GoogleCalendarIdentifier« vtičnika lahko vnesemo opis le-tega v
register:
54
larkc:v12 rdf:type larkc:sparql-Variable.
larkc:v13 rdf:type larkc:sparql-Variable.
larkc:v14 rdf:type larkc:sparql-Variable.
larkc:v15 rdf:type larkc:sparql-Variable.
larkc:triple15 rdf:type larkc:sparql-Triple;
larkc:hasSubject larkc:v12;
larkc:hasPredicate rdf:type;
larkc:hasObject cyc:LegalAgent.
larkc:triple16 rdf:type larkc:sparql-Triple;
larkc:hasSubject larkc:v12;
larkc:hasPredicate cyc:hasLoginData;
larkc:hasObject larkc:v13.
larkc:triple17 rdf:type larkc:sparql-Triple;
larkc:hasSubject larkc:v12;
larkc:hasPredicate cyc:scheduleFor;
larkc:hasObject larkc:v14.
larkc:triple18 rdf:type larkc:sparql-Triple;
larkc:hasSubject larkc:v14;
larkc:hasPredicate cyc:scheduledEvents;
larkc:hasObject larkc:v15.
larkc: GoogleCalendarIdentifier rdfs:subClassOf larkc:Identifier;
larkc:hasInput larkc:triple15;
larkc:hasInput larkc:triple16;
larkc:hasOutput larkc:triple17;
larkc:hasOutput larkc:triple18;
3.5.3. Sklepanje
Za preverjanje delovanja, smo v register vtičnikov poleg »GoolgeCalendarIdentifier«
vtičnika, ter nekaj nepopolno opisanih vtičnikov, vnesli še pet opisov vtičnikov, ki povezani v
tok dela, lahko odgovorijo na drugi primer SPARQL poizvedbe (poglavje 3.5.1). Vnešeni
vtičniki so:
»ArticleIdentifier«, ki na internetu preko vhodnega naslova poišče ter vrne pripadajoče
besedilo in ima vhodni opis podan kot:
?x cyc:mentionedInArticle ?y
Ter izhod:
?y rdf:Type larkc:NaturalLanguageDocument
55
»GateTransformer«, ki v podanem vhodnem besedilu poišče pojavitve lastnih imen in
podjetij ter vrne množico trditev, ki ta lastna imena povežejo z vhodnim besedilom. Vhod ima
opisan kot:
?x rdf:Type larkc:NaturalLanguageDocument
Ter izhod:
?y rdf:Type cyc:Name
?x rdf:Type larkc:NaturalLanguageDocument
?y cyc:mentionedInArticle ?x
»CycSelecter«, ki izmed podanih lastnih imen izbere le tiste, ki obstajajo v bazi CycKB ter so
instance obstoječih podjetij:
?x rdf:Type cyc:Name
Ter izhod:
?y rdf:Type cyc:PubliclyHeldCorporation
»CycReasoner«, ki je povezan neposredno na Cyc sklepalni pogon in zna sklepati nad vsemi
podatki znotraj CycKB:
?x rdf:Type cyc:Thing
Ter izhod:
?x rdf:Type cyc:Thing
?y cyc:BinaryPredicate ?e
Za ugotavljanje povezave med SPARQL poizvedbo ter vtičniki uporabimo sledečo CycL
poizvedbo, kjer namesto ?SPARQL_QUERY spremenljivke vnesemo instanco SPARQL
poizvedbe, ki smo jo predhodno serializirali:
56
(#$and
(#$larkc-sparql-hasTriple ?SPARQL_QUERY ?SPARQLTRIPLE)
(#$larkc-sparql-hasPredicate ?SPARQLTRIPLE ?PREDICATE)
(#$larkc-hasOutput ?PLUGIN ?OUTPUTTRIPLE)
(#$larkc-sparql-hasPredicate ?OUTPUTTRIPLE ?PREDICATE)
(#$larkc-sparql-hasObject ?SPARQLTRIPLE ?OBJECT1)
(#$or
(#$larkc-sparql-hasObject ?OUTPUTTRIPLE ?OBJECT1);ali isto
(and (#$larkc-sparql-hasObject ?OUTPUTTRIPLE ?OBJECT2) (isa ?OBJECT2
larkc-sparql-Variable))))
V prvem primeru dobimo v času 0,42s dva pripadajoča vtičnika: »CycSelecter« ker vrača
instance razreda »cyc:PubliclyHeldCorporation«, ter »GateTransformer«, ki ima med
izhodnimi podatki tudi predikat »cyc:mentionedInArticle«.
Slika 15: Odgovor sklepalnega pogona na poizvedbo o podjetjih omenjenih v članku
V drugem primeru pa dobimo kot rezultat vtičnik »GoogleCalendarIdentifier« in sicer v času
0,685 s.
57
Slika 16: Odgovor sklepalnega pogona na poizvedbo o dogodkih v koledarju
3.6. Iskanje primernih vtičnikov glede na vhodne zahteve
Na tej točki se naš sistem zaveda povezav med vtičniki glede na vhodno-izhodne tipe
podatkov ter povezave med vhodno poizvedbo ter vtičniki. Prav tako imamo izpeljan
besednjak za opisovanje vtičnikov glede na vhodno-izhodne zahteve ter dopolnjeno LarKC
ontologijo (poglavje 3.5.1 ter 3.5.2), kar je predpogoj za sklepanje nad povezavami glede na
vhodne zahteve vtičnikov.
3.6.1. Razvoj logičnega pravila za povezovanje
Zaradi vseh izpolnjenih predpogojev, nam za ugotavljanje povezav v tem primeru ni potrebno
dopolnjevati ontologije, temveč moramo samo sestaviti pravilno logično poizvedbo oziroma
pravilo, ki nam potem sproži sklepanje ter vrne povezavo med vtičniki. Zaradi preglednosti
ter vmesne razlage bomo le-to razvili po korakih.
Najprej pridobimo trditve o vhodnih in izhodnih podatkih za vtičnike:
58
(#$and
(#$larkc-hasInput ?PLUGIN2 ?INPUTPUTTRIPLE)
(#$larkc-hasOutput ?PLUGIN1 ?OUTPUTTRIPLE)
)
Iz teh trditev izluščimo še osebek, predikat ter predmet. Pri tem označujemo izhodne
spremenljivke s številko 1, vhodne pa s številko 2 (?OBJECT1, ?OBJECT2):
(#$and
(#$larkc-hasInput ?PLUGIN2 ?INPUTPUTTRIPLE)
(#$larkc-hasOutput ?PLUGIN1 ?OUTPUTTRIPLE)
(#$larkc-sparql-hasSubject ?INPUTPUTTRIPLE ?SUBJECT2)
(#$larkc-sparql-hasPredicate ?INPUTPUTTRIPLE ?PREDICATE2)
(#$larkc-sparql-hasObject ?INPUTPUTTRIPLE ?OBJECT2)
(#$larkc-sparql-hasSubject ?OUTPUTTRIPLE ?SUBJECT1)
(#$larkc-sparql-hasPredicate ?OUTPUTTRIPLE ?PREDICATE1)
(#$larkc-sparql-hasObject ?OUTPUTTRIPLE ?OBJECT1)
)
Zgornja poizvedba nam vrne vse registrirane vtičnike, vse njihove vhodne ter izhodne trojke,
ter osebke, predikate ter predmete. Na tem nivoju je poizvedba enakovredna iskanju po
relacijski podatkovni zbirki.
V naslednjem koraku poizvedbo spremenima tako, da zahtevamo da so izhodni podatki iz
prvega vtičnika enaki vhodnim podatkom drugega vtičnika. Pogoj smo postavili znotraj ukaza
#$or, zaradi kasnejše nadgradnje.
(#$and
(#$larkc-hasInput ?PLUGIN2 ?INPUTPUTTRIPLE)
(#$larkc-hasOutput ?PLUGIN1 ?OUTPUTTRIPLE)
(#$larkc-sparql-hasSubject ?INPUTPUTTRIPLE ?SUBJECT2)
(#$larkc-sparql-hasPredicate ?INPUTPUTTRIPLE ?PREDICATE2)
(#$larkc-sparql-hasObject ?INPUTPUTTRIPLE ?OBJECT2)
(#$or
(#$larkc-sparql-hasSubject ?OUTPUTTRIPLE ?SUBJECT2)
)
(#$or
(#$larkc-sparql-hasPredicate ?OUTPUTTRIPLE ?PREDICATE2)
)
(#$or
(#$larkc-sparql-hasObject ?OUTPUTTRIPLE ?OBJECT2)
)
)
Taka poizvedba nam vrne le povezavo med vtičniki, ki imajo popolnoma enak vhod ter izhod.
V našem primeru s šestimi vtičniki nam kot rezultat vrne povezavo »CycReasoner povezan z
CycReasoner«, ker ima enak vhod ter izhod. Ta rezultat je napaka, ker se vtičnik ne more
59
povezati sam s sabo, zato v našo poizvedbo dodamo še dodaten pogoj, ki take povezave
preprečuje.
(#$not(#$equals ?PLUGIN1 ?PLUGIN2))
V primerih ko imamo vhodni osebek, predikat ali predmet opisan s spremenljivko, je lahko
izhod prejšnjega vtičnika karkoli. Tako v našo poizvedbo poleg trditve da se mora vhod in
izhod dobesedno ujemati dodamo še možnost da je na vhodu spremenljivka. (Ali vhod =
izhod, ali pa vhod = spremenljivka)
(#$and
(#$larkc-hasInput ?PLUGIN2 ?INPUTPUTTRIPLE)
(#$larkc-hasOutput ?PLUGIN1 ?OUTPUTTRIPLE)
(#$larkc-sparql-hasSubject ?INPUTPUTTRIPLE ?SUBJECT2)
(#$larkc-sparql-hasPredicate ?INPUTPUTTRIPLE ?PREDICATE2)
(#$larkc-sparql-hasObject ?INPUTPUTTRIPLE ?OBJECT2)
(#$or
(#$larkc-sparql-hasSubject ?OUTPUTTRIPLE ?SUBJECT2)
(#$isa ?SUBJECT2 #$larkc-sparql-Variable)
)
(#$or
(#$larkc-sparql-hasPredicate ?OUTPUTTRIPLE ?PREDICATE2)
(#$isa ?PREDICATE2 #$larkc-sparql-Variable)
)
(#$or
(#$larkc-sparql-hasObject ?OUTPUTTRIPLE ?OBJECT2)
(#$isa ?OBJECT2 #$larkc-sparql-Variable)
)
(#$not(#$equals ?PLUGIN1 ?PLUGIN2))
)
60
Podobno velja, da so lahko spremenljivke, oziroma poljubne vrednosti na izhodih.
(#$and
(#$larkc-hasInput ?PLUGIN2 ?INPUTPUTTRIPLE)
(#$larkc-hasOutput ?PLUGIN1 ?OUTPUTTRIPLE)
(#$larkc-sparql-hasSubject ?INPUTPUTTRIPLE ?SUBJECT2)
(#$larkc-sparql-hasPredicate ?INPUTPUTTRIPLE ?PREDICATE2)
(#$larkc-sparql-hasObject ?INPUTPUTTRIPLE ?OBJECT2)
(#$or
(#$larkc-sparql-hasSubject ?OUTPUTTRIPLE ?SUBJECT2)
(#$isa ?SUBJECT2 #$larkc-sparql-Variable)
(#$and
(#$larkc-sparql-hasSubject ?OUTPUTTRIPLE ?SUBJECT1)
(#$isa ?SUBJECT1 #$larkc-sparql-Variable)
)
)
(#$or
(#$larkc-sparql-hasPredicate ?OUTPUTTRIPLE ?PREDICATE2)
(#$isa ?PREDICATE2 #$larkc-sparql-Variable)
(#$and
(#$larkc-sparql-hasPredicate ?OUTPUTTRIPLE ?PREDICATE1)
(#$isa ?PREDICATE1 #$larkc-sparql-Variable)
)
)
(#$or
(#$larkc-sparql-hasObject ?OUTPUTTRIPLE ?OBJECT2)
(#$isa ?OBJECT2 #$larkc-sparql-Variable)
(#$and
(#$larkc-sparql-hasObject ?OUTPUTTRIPLE ?OBJECT1)
(#$isa ?OBJECT1 #$larkc-sparql-Variable)
)
)
(#$not(#$equals ?PLUGIN1 ?PLUGIN2))
)
Poleg tega da upoštevamo direktno enakost opisov, ter spremenljivke, v našo poizvedbo
dodamo še hierarhične ter relacijske pogoje. Če nek vtičnik recimo vrača podatke razreda
#$Dog, drug vtičnik pa zahteva podatke razreda #$Animal, jih mora naš sistem pravilno
povezati, ker je #$Dog podrazred razreda #$Animal.
61
Podobno velja za relacije, kjer je relacija #$friends, podrelacija od #$knows (dve osebi ki sta
prijatelja, sta hkrati tudi dve osebi ki se poznata).
(#$and
(#$larkc-hasInput ?PLUGIN2 ?INPUTPUTTRIPLE)
(#$larkc-hasOutput ?PLUGIN1 ?OUTPUTTRIPLE)
(#$larkc-sparql-hasSubject ?INPUTPUTTRIPLE ?SUBJECT2)
(#$larkc-sparql-hasPredicate ?INPUTPUTTRIPLE ?PREDICATE2)
(#$larkc-sparql-hasObject ?INPUTPUTTRIPLE ?OBJECT2)
(#$or
(#$larkc-sparql-hasSubject ?OUTPUTTRIPLE ?SUBJECT2)
(#$isa ?SUBJECT2 #$larkc-sparql-Variable)
(#$and
(#$larkc-sparql-hasSubject ?OUTPUTTRIPLE ?SUBJECT1)
(#$or
(#$isa ?SUBJECT1 #$larkc-sparql-Variable)
(genls ?SUBJECT1 ?SUBJECT2)
)
)
)
(#$or
(#$larkc-sparql-hasPredicate ?OUTPUTTRIPLE ?PREDICATE2)
(#$isa ?PREDICATE2 #$larkc-sparql-Variable)
(#$and
(#$larkc-sparql-hasPredicate ?OUTPUTTRIPLE ?PREDICATE1)
(#$or
(#$isa ?PREDICATE1 #$larkc-sparql-Variable)
(genlPreds ?PREDICATE1 ?PREDICATE2)
)
)
)
(#$or
(#$larkc-sparql-hasObject ?OUTPUTTRIPLE ?OBJECT2)
(#$isa ?OBJECT2 #$larkc-sparql-Variable)
(#$and
(#$larkc-sparql-hasObject ?OUTPUTTRIPLE ?OBJECT1)
(#$or
(#$isa ?OBJECT1 #$larkc-sparql-Variable)
(genls ?OBJECT1 ?OBJECT2)
)
)
)
(#$not(#$equals ?PLUGIN1 ?PLUGIN2))
)
Na koncu upoštevamo še trditev #$pluginByDataConnectsTo iz poglavja 3.4 da se izognemo
povezovanju podatkovno nezdružljivih vtičnikov, ter spremenimo našo poizvedbo v pravilo,
ki postavja trditve tipa #$pluginConnectsTo (tranzitivni predikat, tako kot
pluginByDataConnectsTo). Na koncu imamo izpeljano pravilo:
62
(#$implies
(#$and
(#$larkc-hasInput ?PLUGIN2 ?INPUTPUTTRIPLE)
(#$larkc-hasOutput ?PLUGIN1 ?OUTPUTTRIPLE)
(#$larkc-sparql-hasSubject ?INPUTPUTTRIPLE ?SUBJECT2)
(#$larkc-sparql-hasPredicate ?INPUTPUTTRIPLE ?PREDICATE2)
(#$larkc-sparql-hasObject ?INPUTPUTTRIPLE ?OBJECT2)
(#$or
(#$larkc-sparql-hasSubject ?OUTPUTTRIPLE ?SUBJECT2)
(#$isa ?SUBJECT2 #$larkc-sparql-Variable)
(#$and
(#$larkc-sparql-hasSubject ?OUTPUTTRIPLE ?SUBJECT1)
(#$or
(#$isa ?SUBJECT1 #$larkc-sparql-Variable)
(genls ?SUBJECT1 ?SUBJECT2)
)
)
)
(#$or
(#$larkc-sparql-hasPredicate ?OUTPUTTRIPLE ?PREDICATE2)
(#$isa ?PREDICATE2 #$larkc-sparql-Variable)
(#$and
(#$larkc-sparql-hasPredicate ?OUTPUTTRIPLE ?PREDICATE1)
(#$or
(#$isa ?PREDICATE1 #$larkc-sparql-Variable)
(genlPreds ?PREDICATE1 ?PREDICATE2)
)
)
)
(#$or
(#$larkc-sparql-hasObject ?OUTPUTTRIPLE ?OBJECT2)
(#$isa ?OBJECT2 #$larkc-sparql-Variable)
(#$and
(#$larkc-sparql-hasObject ?OUTPUTTRIPLE ?OBJECT1)
(#$or
(#$isa ?OBJECT1 #$larkc-sparql-Variable)
(genls ?OBJECT1 ?OBJECT2)
)
)
)
(#$not(#$equals ?PLUGIN1 ?PLUGIN2))
(#$larkc-pluginByDataConnectsTo ?PLUGIN1 ?PLUGIN2)
)
(#$larkc-pluginConnectsTo ?PLUGIN1 ?PLUGIN2)
)
3.6.2. Uporaba pravila za povezovanje
V prejšnjem poglavju smo izpeljali dokaj kompleksno pravilo, ki preko trditve
#$pluginConnectsTo, poveže med seboj združljive vtičnike. Preko te trditve, omogočeno
preko pravila, postane poizvedovanje po možnostih povezovanja vtičnikov veliko
63
enostavnejše. Namesto da pri vsaki poizvedbi pišemo kompleksno strukturo trditev, sedaj
preprosto uporabimo poizvedbe tipa
(#larkc-pluginConnectsTo ?PLUGIN1 ?PLUGIN2)
Na primer poizvedba
(#larkc-pluginConnectsTo #$larkc-ArticleIdentifier ?PLUGIN2)
Nam kot rezultat vrne vse vtičnike, na katere se lahko poveže »ArticleIdentifier« (spodnja
slika).
Slika 17: Rezultati poizvedbe (#larkc-pluginConnectsTo #$larkc-ArticleIdentifier ?PLUGIN2)
Pri tem nam sklepalni pogon upošteva tranzitivno lastnost pluginConnectsTo predikata, tako
da poleg vtičnika »GateTransformer«, dobimo še »CycSelecter« ter »CycReasoner«, ker se
»GateTransformer« oveže z »CycSelecterjem«, ki se poveže z »CycReasonerjem«. Do
vmesnih povezav pridemo s pomočjo dokaza (spodnja slika).
Slika 18: Utemeljitev za povezavo med ArticleIdentifier vtičnikom ter CycReasoner vtičnikom
Zgornjo poizvedbo pa lahko naredimo še bolj informativno, ker vemo da Select SPARQL
64
poizvedba zahteva rezultate v obliki »VariableBinding«, lahko vprašamo za celoten potek
dela, ki nam vrne določen RDF v obliki »VariableBinding«:
(#$and
(#$larkc-pluginConnectsTo #$larkc-ArticleIdentifier ?PLUGIN2)
(#$larkc-hasOutputType ?PLUGIN2 #$larkc-VariableBinding)
)
Tokrat je rezultat samo »CycReasoner«, celoten potek dela pa zopet dobimo preko dokaza:
Slika 19: Potek dela ki se začne z »ArticleIdentifier« vtičnikom ter konča z vtičnikom ki vrne »VariableBinding«
3.7. Združitev pristopov
Pristopi in logična pravila za samodejno povezovanje ki so opisana v predhodnih poglavjih,
so integrirana v register vtičnikov in so preko API vmesnika na voljo vtičnikom ter ostalim
delom platforme.
65
Vsak izmed naštetih pristopov je uporaben sam zase kot pomoč načrtovalcem tokov dela
(osebam ali aplikacijam kot je grafični načrtovalec tokov dela), za samodejno povezovanje
tokov dela pa jih je potrebno združiti med sabo, ter predlagane tokove dela preveriti še
programsko.
V predlagani »decider« komponenti (Slika 8), ki je trenutno še v prototipni fazi, za
sestavljanje uporabljamo sledeč algoritem:
1. Ko uporabnik platofrme pošlje SPARQL poizvedbo, se le-ta serializira v logiko ter shrani
v tabelo za primer kasnejše ponovitve (ni potrebno še enkrat serializirati in zaganjati
sklepalnega pogona) Za lažjo razlago gradimo okrog druge poizvedbe (poglavje 3.5.1).
2. Po uspešni serializaciji SPARQL poizvedbe, se izvede CycL poizvedba, ki poišče
vtičnike ki so potrebni za odgovor na SPARQL poizvedbo (poglavje 3.5.3). Ta
poizvedba nam vrne preprost seznam vtičnikov. V primeru druge poizvedbe iz poglavja
3.5.1, sta to »GateTransformer« in »CycSelecter«.
3. Za vse dobljene vtičnike nato v zanki s pomočjo CycL poizvedbe iz prejšnjega poglavja
(3.6.2) pridobimo predlagane tokove dela. V tem primeru dobimo dva tokova dela, ki se
oba končata v »CycReasoner« vtičniku:
4. Dobljene tokove dela nato preverimo za ponavljajoče se vtičnike (če se v različnih
tokovih dela pojavi isti vtičnik). V primerih ko se da različne tokove dela združit v enega
samega, to storimo, v nasprotnih primerih pa samo povežemo eno ali več vej na skupne
vtičnike. V našem primeru nam ostane le ena veja.
66
5. V preostalih vejah toka dela, preverimo začetne vtičnike, če imajo kakšne neizpolnjene
vhodne zahteve, ki se lahko izpolnejo z dodajnjem predhodnega vtičnika. To enostavno
preverimo z CycL poizvedbo, ki je v našem primeru:
(#$larkc-pluginConnectsTo ?PLUGIN #$larkc-GateTransformer)
V primeru da takih predhodnih vtičnikov ni, preidemo na korak 6. V našem primeru dobimo
dopolnjen tok dela:
6. V zadnjem koraku nato za vsak vtičnik na začetku veje (v našem primeru samo
»ArticleIdentifier«), preverimo če lahko vhodne zahteve dobi iz SPARQL poizvedbe. Za
to uporabimo predelano (obrnjeno) poizvedbo iz poglavja 3.5.3:
(#$and
(#$larkc-sparql-hasTriple ?SPARQL_QUERY ?SPARQLTRIPLE)
(#$larkc-sparql-hasPredicate ?SPARQLTRIPLE ?PREDICATE)
(#$larkc-hasInput #ArticleIdentifier ?OUTPUTTRIPLE)
(#$larkc-sparql-hasPredicate ?OUTPUTTRIPLE ?PREDICATE)
(#$larkc-sparql-hasObject ?SPARQLTRIPLE ?OBJECT1)
(#$or
(#$larkc-sparql-hasObject ?OUTPUTTRIPLE ?OBJECT1);ali isto
(and
(#$larkc-sparql-hasObject ?OUTPUTTRIPLE ?OBJECT2)
(isa ?OBJECT2 larkc-sparql-Variable)
)
)
)
Kadar je ta pogoj izpolnjen imamo veljaven tok dela ter ga lahko pošljemo komponenti za
sestavljanje tokov v RDF obliki. V primeru, da pa zadnji pogoj ni izpolnjen pa pomeni da za
dano SPARQL poizvedbo ne moremo sestaviti ustreznega toka dela.
67
4. Zaključek in nadaljnje delo
V tem diplomskem delu je predstavljen način opisovanja LarKC vtičnikov z ontologijo ter
primer uporabe opisov za samodejno sestavljanje tokov dela z računalniškim sklepanjem.
Primer sklepanja ter sestavljanja tokov dela je predstavljen na obstoječih LarKC vtičnikih ter
z realnimi opisi le-teh.
Vsi opisani postopki ter metode so skupaj z API vmesnikom registra vtičnikov, razviti do
porototipne faze kot vtičnik tipa »decider«, ki bo na voljo tudi v repozitoriju [18] ob izidu
naslednje verzije platforme LarKC.
Predlagana rešitev zadovoljivo rešuje problem povezovanja v kontroliranem okolju platorme
LarKC ter množice specifičnih vtičnikov in v večini primerov trenutne uporabe platforme
odvzame potrebo po ročnem sestavljanju toka dela. Takšna komponenta je predvsem
primerna za uporabo kot privzet način delovanja ob prvi namestitvi platforme in se jo
nadomesti z ročno določenim tokom dela le po potrebi.
Kljub temu da predstavljena komponenta deluje zadovoljivo v trenutnih razmerah, je na voljo
še veliko maneverskega prostora za izboljšave. Poleg opisov vhodnih ter izhodnih podatkov bi
bilo smiselno upoštevati in opisati še podatke o kvaliteti storitve (ang: QoS, quality of
service), na primer hitrost izvajanja, poraba spomina, zmožnost sočasnega izvajanja, količina
podatkov ki jih lahko sprejme vtičnik, cena, itd..
Izboljšati je pa mogoče tudi trenutne opise vhodnih ter izhodnih zahtev, kjer je potrebno
dodati še konjuktivne ter disjunktivne relacije med trditvami. Na tak način se da natančnejše
določiti vrednost povezave med vtičniki. Nekatere povezave pokrijejo le določen del zahtev,
nekatere pa celotno vhodno zahtevo nekega vtičnika.
Prav tako je možno izboljšati pravila za sklepanje, da poleg razredne ter predikatne hierarhije,
nad osebkom, predikatom ter predmetom, upoštevajo še rdfs:domain ter rdfs:range trditve in
iz tega pridobijo razred osebka in/ali predmeta..
68
69
5. Reference
1. Yahoo. Yahoo Pipes. Yahoo Pipes. [Online] Yahoo, 2010. http://pipes.yahoo.com/pipes/.
2. Orange. Orange. Orange. [Online] Orange. http://www.ailab.si/orange/.
3. Mitchell, Tom. Machine Learning. s.l. : McGraw Hill, 1997.
4. Towards LarKC: a Platform for Web-scale Reasoning. Dieter Fensel, Frank van
Harmelen, Bo Andersson, Paul Brennan, Hamish Cunningham, Emanuele Della Valle,
Florian Fischer, Zhisheng Huang, Atanas Kiryakov. Tony Kyung-il Lee, Lael School,
Volker Tresp, Stefan Wesner, Michael Witbrock, Ning Zhong. 2008. IEEE Computer
Society Press Los Alamitos.
5. An Introduction to the Syntax and Content of Cyc. C, Matuszek, et al. s.l. : AAAI Press,
2006. Proceedings of the 2006 AAAI Spring Symposium on Formalizing and Compiling
Background Knowledge and Its Applications to Knowledge Representation and Question
Answering.
6. Inc., Cycorp. Cycorp Inc. Homepage. [Online] 2010. http://www.cyc.com/.
7. CycEur. Cycorp Europe Homepage. [Online] Cycorp Europe, 2010.
http://www.cycorp.eu/.
8. Coupled Semi-Supervised Learning for Information Extraction. A. Carlson, J. Betteridge,
R.C. Wang, E.R. Hruschka Jr. and T.M. Mitchell. 2010. Proceedings of the ACM
International Conference on Web Search and Data Mining (WSDM).
9. First-Order Logic. [book auth.] Peter Norvig Stuart Russell. Artificial Intelligence: A
Modern Approach. New Jersey : Pearson Education, Inc, 1995.
10. The Syntax of CycL. Cycorp, Inc. Corporation Web site. [Online] Cycorp, Inc. [Cited: 6
27, 2010.] http://www.cyc.com/cycdoc/ref/cycl-syntax.html.
11. Bibel, Wolfgang. Deduction : automated logic. London : Academic Press, 1993.
70
12. W3C. Resource Description Framework (RDF):. Resource Description Framework
(RDF):. [Online] W3C, 2 10, 2004. http://www.w3.org/TR/2004/REC-rdf-concepts-
20040210/.
13. Ontotext. OWLIM Web page. Ontotext's web page. [Online] Ontotext, 2010.
http://www.ontotext.com/owlim.
14. W3C. RDF Vocabulary Description Language 1.0: RDF Schema. RDF Vocabulary
Description Language 1.0: RDF Schema. [Online] W3C, 2 10, 2004.
http://www.w3.org/TR/rdf-schema/.
15. —. SPARQL Query Language for RDF. SPARQL Query Language for RDF. [Online]
W3C, 1 15, 2008. http://www.w3.org/TR/rdf-sparql-query/.
16. LarKC. Plug-in Marketplace. LarKC. [Online] LarKC, 2010. http://www.larkc.eu/plug-
in-marketplace/.
17. Apache License, Version 2.0. [Online] Apache, 2 2004.
http://www.apache.org/licenses/LICENSE-2.0.html.
18. SourceForge. Large Knowledge Collider on Source forge. [Online] 2010.
http://sourceforge.net/projects/larkc/.
71
Izjava
Izjavljam, da sem diplomsko delo izdelal samostojno pod mentorstvom doc. dr. Boštjana
Murovca in somentorstvom doc. dr. Dunje Mladenić. Izkazano pomoč drugih sodelavcev sem
v celoti navedel v zahvali.
top related