SAMODEJNO POVEZOVANJE PROGRAMSKIH …lie.fe.uni-lj.si/diplome/PDF/2010/Diploma_LukaBradesko.pdf · 3.2. Register vtičnikov ... LarKC ontologija ..... 42 3.4. Povezovanje na nivoju

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

http://shodan.ijs.si:3602/cgi-bin/cg?cb-cf&c1651





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.

http://www.w3.org/1999/02/22-rdf-syntax-ns%23

http://www.w3.org/1999/02/22-rdf-syntax-ns%23

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:[email protected]> .

_:b foaf:name "Peter Goodguy" .

_:b foaf:mbox <mailto:[email protected]> .

_:c foaf:mbox <mailto:[email protected]> .

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:[email protected]>

"Peter Goodguy" <mailto:[email protected]>

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) {


return null;

}

@Override

public void shutdown() {


}

}

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.





larkc:SomeIdentifier


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.





larkc:SomeTransformer


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





larkc:SomeSelecter


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.





larkc:SomeReasoner


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:




larkc:GoogleCalendarIdentifier


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:arg2Genl larkc:DataResource .

Predikat »pluginByDataConnectsTo«

Tudi predikat »pluginByDataConnectsTo« definiramo znotraj Larkc.rdf.

larkc:pluginByDataConnectsTo rdf:type owl:TransitiveProperty;


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:




larkc:GoogleCalendarIdentifier


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




SPARQLToTripplePatterntQueryTransformer

FirstDataSetOnlySelecter

CycSelecter

SPARQLQueryEvaluationReasoner


SwoogleOntologySearchIdentifier


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,[email protected],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;



larkc:sparql-hasObject rdf:type rdf:Property;



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:triple1 rdf:type larkc:sparql-Triple;

larkc:hasSubject larkc:v1;

larkc:hasPredicate rdf:type;

larkc:hasObject cyc:Person.



larkc:hasPredicate cyc:hasLoginData;

larkc:hasObject "[email protected],uime,geslo".



larkc:hasPredicate cyc:scheduleFor;

larkc:hasObject larkc:v2.



larkc:hasPredicate cyc:scheduledEvents;


larkc:sparql1 rdf:type larkc: SPARQLQuery;

larkc: sparql-hasOutputVariable larkc:v3;

larkc:hasTriple larkc:triple1;




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:hasPredicate cyc:mentionedInArticle;

larkc:hasObject "http://shodan.ijs.si/article.txt").




larkc:hasObject cyc:PubliclyHeldCorporation.

larkc:sparql2 rdf:type larkc:SPARQLQuery;

larkc: sparql-hasOutputVariable larkc:v1;



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:hasObject cyc:LegalAgent.



larkc:hasPredicate cyc:hasLoginData;




larkc:hasPredicate cyc:scheduleFor;




larkc:hasPredicate cyc:scheduledEvents;


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-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






(#$or


)

(#$or


)

(#$or


)

)

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






(#$or


(#$isa ?SUBJECT2 #$larkc-sparql-Variable)

)

(#$or


(#$isa ?PREDICATE2 #$larkc-sparql-Variable)

)

(#$or


(#$isa ?OBJECT2 #$larkc-sparql-Variable)

)


)

60

Podobno velja, da so lahko spremenljivke, oziroma poljubne vrednosti na izhodih.

(#$and






(#$or



(#$and



)

)

(#$or



(#$and



)

)

(#$or



(#$and



)

)


)

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






(#$or



(#$and


(#$or


(genls ?SUBJECT1 ?SUBJECT2)

)

)

)

(#$or



(#$and


(#$or


(genlPreds ?PREDICATE1 ?PREDICATE2)

)

)

)

(#$or



(#$and


(#$or


(genls ?OBJECT1 ?OBJECT2)

)

)

)


)

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






(#$or



(#$and


(#$or


(genls ?SUBJECT1 ?SUBJECT2)

)

)

)

(#$or



(#$and


(#$or


(genlPreds ?PREDICATE1 ?PREDICATE2)

)

)

)

(#$or



(#$and


(#$or


(genls ?OBJECT1 ?OBJECT2)

)

)

)


(#$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


(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.

Documents

SAMODEJNO POVEZOVANJE PROGRAMSKIH …lie.fe.uni-lj.si/diplome/PDF/2010/Diploma_LukaBradesko.pdf · 3.2. Register vtičnikov ... LarKC ontologija ..... 42 3.4. Povezovanje na nivoju