Et verktøy for visualisering av wiki-ontologier: Enklere utvikling og bedre forståelse av ontologier?

(1)

Masteroppgave i informasjonsvitenskap

Et verktøy for visualisering av wiki-ontologier:

Enklere utvikling og bedre forståelse av ontologier?

André Sørbø

Institutt for informasjons- og medievitenskap Det samfunnsvitenskapelige fakultet

Universitetet i Bergen Juni 2008

Veileder: Weiqin Chen

(2)

André Sørbø: Et verktøy for visualisering av wiki ontologier: 2

Enklere utvikling og bedre forståelse av ontologier? Forord

Forord

Dette prosjektet markerer avslutningen på mitt masterstudium ved Universitetet i Bergen. Arbeidet med oppgaven har vært både spennende og lærerikt. Det har vært et krevende og utfordrende prosjekt og det er derfor med en stor lettelse og en følelse av tilfredsstillhet jeg ser alle bitene til slutt falt på plass. Jeg håper at både programmet som er blitt utviklet gjennom dette prosjektet og

resultatene og erfaringene jeg har forsøkt å videreformidle vil være et viktig bidrag i et fagfelt som etter min mening vil bli svært viktig i fremtidens informasjonssamfunn.

Jeg vil til slutt takke min veileder, Weiqin Chen som har vært til stor hjelp med oppgaven.

Bergen, 26. juni 2008

(3)

Enklere utvikling og bedre forståelse av ontologier? Sammendrag

Sammendrag

En ontologi er et system innenfor et bestemt fagområde som inneholder termer, spesifikasjon av disse termene og hvordan de henger sammen. Det er en konseptualisering, det vil si en forenklet

beskrivelse av den verdenen eller det fagområdet vi ønsker å representere. Fagområdet kan være alt fra medisin til heissystemer eller dyrearter. Ontologier er viktige fordi de skal gi en felles forståelse av det aktuelle fagfeltet. For kunstig intelligens systemer brukes ontologier til å definere hva som

”eksisterer” for det aktuelle systemet.

En wiki er en hjemmeside som kan leses og redigeres av ”alle”¹ som leser den. Det kreves ingen spesiell programvare fra brukerens side. Den nye koden legges inn direkte i hjemmesiden.

Ontologier kan ofte være store og omfattende og utviklingen av disse vil derfor ofte bli utført av mange personer samtidig. Wikier kan være godt egnet for dette formålet, ettersom disse er lagt spesielt til rette for at flere personer kan samarbeide om å legge inn informasjon. Et av problemene for slike prosjekter, kan være å beholde oversikten når informasjonsmengden (ontologien) vokser.

Gjennom dette prosjektet blir det foreslått at problemet kan løses ved hjelp av et verktøy som visualiserer innholdet i en wiki. Med en slik visualisering mener jeg at programvaren kan lese inn ontologien fra en gitt wiki-side for så å ”oversette” den til en tilsvarende grafisk måte.

Problemstillingen som prosjektet ønsket å utforske og besvare var: ”Kan et verktøy for visualisering av wiki-ontologier føre enklere utvikling og bedre forståelse av ontologier?”

Et slikt verktøy var ikke utviklet fra før og det ble derfor bestemt at det skulle utvikles en fungerende prototype av et slikt verktøy. Prototypen, som fikk navnet WikiVis, skulle senere bli brukt til å besvare problemstillingen. Hoveddelen av prosjektet har derfor gått ut på å planlegge, designe og utvikle en slik prototype. Denne delen er beskrevet i kapittel 3.

Problemstillingene til prosjektet ble besvart på grunnlag av en evaluering som ble foretatt av den ferdige prototypen. Resultatene og konklusjonen fra denne evalueringen viste at et slikt program for visualisering av wiki-ontologier vil være et nyttig hjelpemiddel, særlig for utviklere. Prototypen hadde likevel en del begrensninger, og det var enighet blant kandidatene som ble evaluert om at det ville være nødvendig å forbedre prototypen en god del før den ville være av særlig nytteverdi for andre enn utviklere og spesielt interesserte. Samtidig viste evalueringen at det finnes behov for et slikt program og at en fullverdig utvikling av programmet vil kunne bidra til forenkling av utvikling og bedre forståelse av wikiontologier.

(4)

Enklere utvikling og bedre forståelse av ontologier? Innholdsfortegnelse

Innholdsfortegnelse

Et verktøy for visualisering av wiki-ontologier: ... 1

Forord ... 2

Sammendrag ... 3

Innholdsfortegnelse ... 4

Tabeller og figurer ... 9

Prototypen ... 9

Forkortelser og begreper... 10

1. Introduksjon ... 12

1.1 Problemdomenet ... 12

1.1.1 Ontologier ... 12

1.1.2 Semantic Web ... 12

1.1.3 Ontologispråk ... 13

1.1.4 Wikier ... 13

1.1.5 Wiki-ontologier ... 13

1.1.6 Visualisering ... 14

1.2 Problemstilling ... 14

1.3 Løsningsforslag ... 14

1.4 Dokumentoversikt ... 15

2. Teori ... 16

2.1. Design og utviklingsdelen ... 17

2.1.1. Fossefallsmetoden ... 17

2.1.2. Iterativ utvikling ... 18

2.1.3. Agile metoder ... 18

2.2. Evalueringsdelen ... 19

2.2.1. Usability ... 19

Usability testing ... 20

2.2.2. Datainnsamling ... 20

(5)

Observasjon ... 20

Tenke høyt ... 21

Spørreskjema ... 21

Intervju ... 21

2.3. Tidligere forskning og utvikling ... 22

2.3.1. Ontologi språk ... 22

2.3.2. Eksisterende ontologiverktøy ... 23

Protégé ... 24

OntoEdit ... 24

Ontolingua ... 25

DOE (The Differential Ontology Editor) ... 25

pOWL ... 25

2.3.3. Samarbeid ... 26

2.3.4. Ontologi-wikier ... 26

SweetWiki ... 26

Semantic MediaWiki ... 26

IkeWiki ... 26

FOAF (Friend of a Friend) ... 27

2.4. Oppsumering ... 27

3. Design –og utvikling... 28

3.1. Metode ... 28

3.1.1. Valg av metode ... 28

3.1.2. Proof of concept ... 29

3.2. Kravspesifikasjon ... 29

3.2.1. Funksjonelle krav ... 30

3.2.2. Ikke-funksjonelle krav ... 30

(6)

3.2.4. Andre krav ... 31

3.3. Verktøy ... 31

3.4. Utviklingen ... 33

3.4.1. Planlegging og overordnet design ... 33

3.4.2. GUI ... 35

3.4.3. Programmodul: Kommunikasjon ... 38

3.4.4. Programmodul: Tolk ... 46

3.4.5. Programmodul: Visualisering ... 53

3.5. Oppsummering ... 58

4. Evaluering ... 60

4.1 Formål ... 60

4.1 Metode: ... 60

4.1.1 Detaljer for valg av intervju ... 62

4.2 Testpersoner ... 62

4.2.1 Kriterier ... 62

4.2.2 Rekruttering:... 63

4.3 Plan for gjennomføring av testen: ... 64

4.3.1 Del 1 Usability test: Løse oppgaver under observasjon ... 65

4.3.2 Del 2: Semi-strukturert intervju ... 66

4.4 Evalueringene ... 68

4.4.1 Evaluering 1 ... 68

4.5 Oppsummering ... 76

5. Oppsummering og konklusjon ... 78

5.1 Tolkning av resultater ... 78

(7)

5.1.1 Design og utvikling... 78

5.1.2 Evaluering av funksjonalitet ... 78

5.1.3 Evaluering av nytteverdi, besvarelse av problemstilling ... 79

5.1.4 Konklusjon ... 79

5.2 Tanker, refleksjoner og videre arbeid ... 79

5.2.1 Antall testpersoner ... 79

5.2.2 Programmets brukergruppe ... 80

5.2.3 Forbedringer og videre arbeid ... 81

Referanseliste ... 82

Appendiks ... 85

Appendiks A: Klassediagram, WikiVis ... 85

Klassediagram: Oversikt ... 85

Klassediagram: Detaljer Meny (1) ... 86

Klassediagram: Detaljer Tolk og visualiseringer (2) ... 87

Klassediagram: Detaljer WikVis hovedmodul (3) ... 88

Klassediagram: Browser (4) ... 89

Appendiks B: Oversikt over kildekodefiler ... 90

Rot-katalog og oppstartsfiler ... 90

Dialogbokser ... 90

Exceptions (Feilhåndtering) ... 90

Importfiltre ... 91

Hovedfiler for program og GUI ... 91

Innstillinger ... 92

Datastrukturer ... 92

Utilities (Nyttige funksjoner) ... 93

Visualiseringer ... 93

(8)

WikiVis Manual ... 94

Quick install guide: ... 94

The rest of the subdirectories contain the program itself ... 94

The program’s layout:... 95

Example: Visualizing an ontology: ... 96

Program history: ... 99

2008-04-24 ... 99

New functions/Improvements: ... 99

Version 1.1 ... 99

2008-03-11 ... 99

New functions ... 99

Version 1.1 ... 99

Appendiks D: Prototypen på nett ... 100

(9)

Tabeller og figurer

Figur 1. XML: XML-fil brukt av prosjektets prototyp, WikiVis. (Exclude list=Innhold som ikke skal tas

med i en visualisering.) ... 22

Figur 2. Protégé screenshot: Visualisering av OWL-ontologi ... 24

Figur 3. OntoEdit Screenshot (http://www.ontoknowledge.org/tools/ontoedit.shtml) ... 24

Figur 4. Ontolingua: Screenshots ... 25

Figur 5. Screenshot: Eclipse 3.3 Europa ... 32

Figur 6. Programmets moduler ... 34

Figur 7. Skisse til programmets brukergrensesnitt, første utkast ... 35

Figur 8. Screenshot: De ulike delene av programmets GUI (WikiVis 1.0) ... 36

Figur 9. Inndeling ved hjelp av tabs (JTabMenu) og splits (JSplitMenu) ... 37

Figur 10. Kommunikasjonsmodulens oppgave (Svært forenklet) ... 38

Figur 11. Importfilter - abstrakte metoder ... 39

Figur 12. Skisse for design av Importfilter - Komplett ... 39

Figur 13. Mockup: Program - Kommunikasjonsmodul ... 40

Figur 14. MediaWiki testserver benyttet under utviklingen av SMW Filteret ... 41

Figur 15. Feilhåndtering ved oppkobling til Semantic MediaWiki ... 43

Figur 16. Importfilter, hente liste over artikler ... 44

Figur 17. Class diagram - Kommunikasjonsmodul (Filter) ... 45

Figur 18. Skisse som viser første utkast til design av tolkmodulen ... 46

Figur 19. Funksjonaliteten for en parser. URL: http://en.wikipedia.org/wiki/Parsing... 48

Figur 20. Hjelpemetoden getSubClassList() (Fra Utils_Jena class-filen) ... 50

Figur 21. loadOntology() - Laste inn ontologi fra RDF/OWL vha Jena API ... 51

Figur 22. Skisse som viser endelig utkast til design av tolkmodulen ... 51

Figur 23. Class diagram - Tolk modul (Engine) ... 52

Figur 24. Visualisering: Abstrakte metoder i visualiserings-malen ... 53

Figur 25. Screenshot: Visualisering - JTree/Classes ... 54

Figur 26. Screenshot: Visualisering - "Circle Layout" ... 55

Figur 27. Screenshot: Visualisering - JGraph ... 56

Figur 28. Class diagram - Visualiseringsmodul ... 57

Figur 29. Klassediagram for WikiVis: Oversikt over de viktigste klasser og relasjoner ... 85

Figur 30. Detaljer fra klassediagram: Meny (1) ... 86

Figur 31. Detaljer fra klassediagram: Tolk (Engine) og visualiseringer (2) ... 87

Figur 32. Detaljer fra klassediagram: WikiVis hovedmodul (3) ... 88

Figur 33. Detaljer fra klassediagram: Browser (4) ... 89

Figur 34. Prosjektets hjemmeside: http://www.student.uib.no/~st01360/Master/... 100

Prototypen

WikiVis 1.1b (Siste versjon ved avslutning av prosjektet) URL: http://www.student.uib.no/~st01360/Master

(10)

Forkortelser og begreper

Term/Begrep Forklaring

API Application Programming Interface. Et sett med funksjoner og prosedyrer som et program, operativsystem eller bibliotek tilbyr for at andre programmer eller programmeringsspråk skal kunne kommunisere med det.

Applet Et javaprogram som kan vises i en nettleser med java-støtte. Programmet kjører altså inne i nettleseren.

Class Norsk: Klasse. I Java lagres koden i ”klasser”, hvor hver klasse representerer et dataobjekt (struktur). En javafil kan inneholde en eller flere klasser. Hver av disse blir ved kjøring oversatt til en egen fil med maskinkode (Med endelsen ”.class”).

Compiler Et program som oversetter kildekode til maskinkode (Kjørbart program).

DAML+OIL The DARPA Agent Markup Language. Dette språket ligner på OWL Full.

Funksjonaliteten er stort sett det samme da OWL Full er bygget med dette språket som modell. DAML+OIL blir presentert i kapittel 2.

GUI Graphical User Interface. Grafisk brukergrensesnitt. Den delen av et program som vises på skjermen og som brukeren bruker til å kommunisere med programmet.

IDE Integrated Development Environment. Et programmeringsverktøy der de nødvendige utviklingsverktøyene er blitt integrert i et program. En IDE vil som oftest inneholde et grensesnitt for å redigere kode, en kompiler (som oversetter koden til maskinkode), verktøy for å finne feil (debugging) og verktøy for å utvikle grafiske brukergrensesnitt til programmer (GUI).

Java Et programmeringsspråk utviklet av Sun Microssystems.

Java Package En Java package er en måte å organisere Java-classer (filer). Hver class-fil kan tilhøre en package. Class-filer som tilhører samme package, kan få tilgang til hverandres metoder. En slik pakke kan og bli komprimert i en enkelt fil (JAR-fil).

Javadoc Javadoc er et Java-verktøy som brukes til å dokumentere Java-kode.

Dokumentasjonen skrives direkte i kildekoden som kommentarer. Javadoc henter frem disse kommentarene sammen med en oversikt over kildekodens struktur og funksjoner (metoder) og generer dokumentasjon i HTML-format.

JDBC Java DataBase Connectivity. En API for kommunikasjon mellom Java-programmer og databaser.

Metode (Java) I Java-sammenheng er en metode en funksjon.

Ontologi Ontologier kan også defineres som læren om det eksisterende (ordenes mening).

I datasammenheng blir ontologier da en måte å beskrive meningene og relasjonene til en term. Se kapittel 1.

(11)

Ontologi-språk Et formelt dataspråk som kan brukes til å beskrive ontologier. Se kapittel 1.

OWL Web Ontology Language. Standard språk for beskrivelse av ontologier utviklet av W3C.

OWL formatet tillater alt som RDFS formatet tillater i tillegg til en rekke nye og mer avanserte funksjoner. OWL er delt i tre syntaks klasser: OWL Lite, OWL DL og OWL FULL. OWL blir gjennomgått i kapittel 2.

Parser Et program som leser inndata og identifiserer strukturen til denne i henhold til en gitt grammatikk. Mer om parsere og parsing i kapittel 3.

Plug-in En utvidelse til et program i form av et lite program som kommuniserer med hovedprogrammet og gir det en bestemt ekstra funksjonalitet.

RDF Resource Description Framework. RDF er en modell og XML-syntaks for å

representere informasjon slik at programmer kan ”forstå” meningen bak teksten.

Det er bygget etter et utsagnsprinsipp (statements), med tripler i formen {predikat, subjekt, objekt}. Mer om RDF i kapittel 2.

Semantic Web ”Fremtidens internett” som bruker ontologier for å gi innholdet ”mening” for datamaskiner. Se kapittel 1.

SQL Structured Query Language. Et standard interaksjons- og programmeringsspråk for databaser. Utviklet av IBM tidlig på 1970-tallet.

URL Uniform Resource Locator. Internett-adresse (Link).

Visualisering En grafisk ”oversettelse” av for eksempel en ontologi.

W3C World Wide Web Consoritium. En internasjonal organisasjon for standardisering av verdensveven (internett) som blant annet har definert HTML-standarden.

Wiki En nettside som tillater å redigere innholdet, uten bruk av eksterne programmer eller kode.

Wiki En hjemmeside hvor det er mulig å endre innholdet direkte. Se kapittel 1.

Wiki-ontologi En ontologi som er lagret på en wiki.

XML eXtensible Markup Language. Markeringsspråk for dokumenter. Brukes i stor grad til også til overføring av data mellom ulike programmer. XML blir gjennomgått i kapittel 2.

(12)

Enklere utvikling og bedre forståelse av ontologier? Introduksjon

1. Introduksjon

Et verktøy for visualisering av wiki-ontologier: Enklere utvikling og bedre forståelse av ontologier? Slik lyder tittelen og problemstillingen for denne oppgaven. Dette kapitlet vil forklare hva denne

problemstillingen innebærer, hvorfor problemstillingen er viktig og hvordan den kan besvares. Den første delen av kapitlet vil gjennomgå problemdomenet og forklare de viktigste begrepene og teknologiene som er relevante for prosjektet mens den neste vil gi en klarere definisjon og forklaring av problemstillingen.

1.1 Problemdomenet

1.1.1 Ontologier

En ontologi er et system innenfor et bestemt fagområde som inneholder termer, spesifikasjon av disse termene og hvordan de henger sammen. Det er en konseptualisering, det vil si en forenklet beskrivelse av den verdenen eller det fagområdet vi ønsker å representere (Akrivi, Constantin et al.

2007). Fagområdet kan være alt fra medisin til heissystemer eller dyrearter. Ontologier er viktige fordi de skal gi en felles forståelse av det aktuelle fagfeltet. De kan være beregnet for mennesker, maskiner eller programmer. For kunstig intelligens systemer brukes ontologier til å definere hva som

”eksisterer” for det aktuelle systemet (Gruber 1992).

Ontologier kan også defineres som læren om det eksisterende (ordenes mening). I datasammenheng blir ontologier da en måte å beskrive meningene og relasjonene til en term. På denne måten kan en datamaskin ”forstå” hva de ulike termene betyr, hvilken relasjon de har til andre termer osv.

1.1.2 Semantic Web

Ontologier er en viktig del av fremtidens semantiske web. Den semantiske weben (eng: Semantic Web) er fremtidens verdensvev (World Wide Web) og en utvidelse av internett vi kjenner det i dag.

Denne utvidelsen, som er definert av W3C² går ut på å bruke semantisk tilleggsinformasjon (ontologier) og på den måten å gi informasjonen på weben struktur og ”mening” for datamaskiner.

Maskinene ”forstår” riktignok ikke innholdet på samme måte som mennesker, men den ekstra informasjonen gjør at informasjonen kan deles opp i logiske deler som kan bli mekanisk manipulert av maskiner. Dette åpner for en rekke nye muligheter da programmer vil ha mulighet til behandle informasjon på en langt mer intelligent måte. Det vil for eksempel bli mulig å foreta langt mer nøyaktige søk basert på innhold (i stedet for stikkord) og det blir lettere å kombinere informasjon fra ulike steder (Berners-Lee 2001; Denny 2002; Wikipedia 2008).

2 W3C (World Wide Web Consortium) Se forklaring under termer og begreper etter innholdsfortegnelsen

(13)

1.1.3 Ontologispråk

For å kunne lagre og håndtere en ontologi i datasammenheng, er det nødvendig å ha et format å lagre denne i. Formatet må være i stand til å håndtere strukturen til ontologien. Strukturen vil gjerne bestå av ”klasser” som definerer begreper og ”instanser” som vil være data assosiert med den enkelte klasse. For eksempel: ”hund” kan være en klasse og hunden ”Fido” kan være en instans av denne klassen. ”Egenskaper” vil også være en naturlig del av en slik struktur (Eksempel: Fido er en

”snill” hund). Utover dette bør strukturen også innholde regler og restriksjoner på hva som er tillatt å lagre i ontologien og hvordan (Akrivi, Constantin et al. 2007). Eksisterende ontologispråk vil bli presentert i kapittel 2 (Tidligere forskning).

1.1.4 Wikier

En wiki er en hjemmeside som kan leses og redigeres av ”alle”³ som leser den. Det kreves ingen spesiell programvare fra brukerens side. Den nye koden legges inn direkte i hjemmesiden (Soanes 2005; Marc 2006).

Wikier har fått en stor utbredelse de siste årene og har medvirket til å øke mengden av informasjon som deles blant nettbrukere dramatisk. En wiki forenkler nettpubliseringsprosessen betraktelig, slik at dette ikke lenger er forbeholdt de med over middels IT-kunnskaper. Wikiene er spesielt godt egnet når mange personer skal være sammen om å publisere informasjon.

1.1.5 Wiki-ontologier

Ontologier kan ofte være store og omfattende og utviklingen av disse vil derfor ofte bli utført av mange personer samtidig. Wikier kan være godt egnet for dette formålet, ettersom disse er lagt spesielt til rette for at flere personer kunne samarbeide om å legge inn informasjon.

En wiki-ontologi eller wiki-basert ontologi vil heretter være definert som en ontologi som er lagret på en wiki. For at en slik ontologi skal ha noen særlig nytteverdi bør wikiprogramvaren (serveren) ha støtte for ontologier. Dette kan være funksjonalitet for å redigere ontologier, herunder validering av kode og regler, og mulighet til å utføre spørringer (queries) på ontologien. I sin enkleste form kan en slik wiki-ontologi være en wiki der det er mulig å legge inn kode i et ontologiformat (OWL, RDF eller DAML+OIL) uten at wikien ellers har noen forståelse av hva dette er.

En wiki med ontologistøtte defineres som programvaren bak en wiki (server) som er tilrettelagt for å kunne lagre ontologier.

(14)

1.1.6 Visualisering

Å visualisere en ontologi vil si å ”oversette” den til en tilsvarende grafisk måte. En oversiktlig, høynivå visualisering kan gjøre det lettere å få et raskt overblikk og forståelse av hvordan en stor og

komplisert ontologi er satt sammen. Visualisering kan også være en nyttig funksjon for navigering og utforskning av store ontologier. Interaktiv utforskning av data kan lede til flere oppdagelser innen relasjoner, mønstre osv (Babu 2008). Visualiseringer kan være alt fra enkle tre- og grafstrukturer,

”topic maps” (som går ut på å lage en slags indeks eller kart over et emne) til mer avanserte tredimensjonale visualiseringer. Aktuelle visualiseringer vil bli gjennomgått og forklart senere.

1.2 Problemstilling

Wikier har fått en enorm utbredelse de senere årene. Fordi de er tilrettelagt for samarbeid ved at flere enkelt kan være med på å endre innholdet kan de også være godt egnet for utvikling av ontologier. Det finnes allerede en del wikier som støtter ontologier. Noen av disse vil bli presentert i kapittel 2. Det er også naturlig å tro at wikiontologier vil få større betydning etter hvert som

ontologier og den semantiske weben tas mer i bruk. Som en konsekvens av flere, voksende

wikiontologier vil det fort bli et problem å beholde oversikten over ontologien. Særlig dersom det er flere som samarbeider om utviklingen, noe som ofte vil være tilfelle for wikiontologier. Som nevnt, kan visualisering gjøre det lettere å få et raskt overblikk over en ontologi.

I dette prosjektet blir det foreslått at dette problemet kan løses ved hjelp av et verktøy som visualiserer innholdet i en wiki-ontologi. Med en slik visualisering mener jeg at programvaren kan lese inn ontologien fra en gitt wiki-side for så å ”oversette” den til en tilsvarende grafisk måte.

Prosjektet vil ha som mål å besvare hvorvidt det er behov for et slikt verktøy og om det kan være med på å forenkle og forbedre forståelsen av wiki-ontologier, og da særlig med tanke på utviklere av slike wiki-ontologier.

Problemstillingen for prosjektet blir derfor:

Kan man forenkle både utviklingen og forståelsen av wiki-ontologier ved hjelp av et verktøy som visualiserer ontologien?

1.3 Løsningsforslag

For å besvare problemstillingen vil det være nødvendig å evaluere et slikt verktøy og kartlegge hvorvidt det vil kunne forenkle utvikling og forståelse av ontologier. For å gjøre dette, vil det bli utviklet en prototyp på et slikt verktøy som en del av prosjektet. Denne vil senere bli evaluert og resultatene av denne evalueringen vil være et viktig utgangspunkt for å kunne besvare

problemstillingen. Prototypen har fått navnet ”WikiVis”.

(15)

Utviklingsstrategier og metoder som vil bli benyttet for å oppnå dette målet, samt resultater fra disse vil bli gjennomgått i de neste kapitlene.

1.4 Dokumentoversikt

Oppgaven er delt opp i følgende hoveddeler:

1) Kapittel 1 har forklart problemdomenet og problemstillingen for oppgaven. Kapittel 2 vil gjennomgå det teoretiske rammeverket for oppgaven og hvilke metoder som vil bli brukt for å løse oppgaven.

2) Kapittel 3 tar for seg hoveddelen av oppgaven, nemlig utviklingen og designen av en applikasjon for visualisering av wikiontologier.

3) Kapittel, 4 vil ta for seg evalueringen av dette programmet og gjennomgå erfaringene fra utviklingen.

4) I kapittel 5 vil disse resultatene bli brukt til å besvare problemstillingen for oppgaven: Kan et slikt verktøy føre til enklere utvikling og bedre forståelse av ontologier? Kapitlet vil også diskutere nytteverdien av den ferdige applikasjonen og eventuell fremtidig videreutvikling av dette.

(16)

Enklere utvikling og bedre forståelse av ontologier? Teori

2. Teori

Dette kapitlet vil undersøke og utforske teorier og metoder som kan bli brukt for å besvare problemstillingen som ble beskrevet i kapittel 1.

Metode (av gr. methodos, til hodos, vei, eg. vei mot målet), planmessig fremgangsmåte for å løse et problem, oppnå et resultat etc. — metodikk, læren om metodene, beskrivelse av den fremgangsmåte som brukes i et bestemt fag. — metodisk, planmessig, systematisk (Caplex 2008).

Metoder en samling av regler, prosedyrer og teknikker for å nå et mål. Uten en god metode som styrer prosjektet kan utviklingen raskt ende opp som et mareritt av uforutsigbarhet, gjentatte feil, bortkastet tid og et generelt dårlig program.

Hovedformålet til denne masteroppgaven er å undersøke og besvare hvorvidt et verktøy for

visualisering av wiki-ontologier kan føre til enklere utvikling og bedre forståelse av ontologier. Det ble foreslått i kapittel 1 å utvikle en prototyp på et slikt verktøy. Denne prototypen vil være et viktig bidrag for å kunne besvare problemstillingen. For det første vil utviklingen, med den nødvendige forstudien og designdelen, gi en bedre forståelse av problemstillingen. Senere vil en evaluering av den ferdige prototypen bli brukt til å måle nytteverdien av programmet og til å besvare hvorvidt prototypen, eventuelt et forbedret tilsvarende program, vil kunne føre til forenklet utvikling og enklere forståelse av ontologier. Evalueringen vil også ha som mål å avdekke om det er behov for et slikt verktøy.

Prosjektet vil derfor bestå av to deler: En design og utviklingsdel, der målet er å utvikle en prototyp for et verktøy som visualiserer wikiontologier, og en evalueringsdel, der målet er å besvare selve problemstillingen for prosjektet, nemlig i hvilken grad et slikt verktøy kan bidra til en forenklet utvikling og forståelse av slike ontologier. Metodene er derfor fordelt på to tilsvarende grupper: De som vil være aktuelle for design og utviklingsdelen, og de som vil være aktuelle for evalueringen av programmet. De konkrete valgene av metoder vil bli gjennomgått i kapitlene som omhandler bruken av disse.

(17)

2.1. Design og utviklingsdelen

Utviklingsdelen går ut på å utvikle en prototyp for et verktøy for visualisering av wikiontologier. De neste avsnittene vil beskrive ulike metoder for utvikling som vil kunne være aktuelle for denne delen.

Den endelige avgjørelsen av hvilke metoder som er best egnet og som vil bli brukt til utviklingen, vil bli tatt i kapitlet som omhandler utviklingen, dvs. kapittel 3. Det finnes flere metoder som beskriver hvordan et utviklingsprosjekt bør utføres: Dette inkluderer håndtering av tekniske utfordringer, design, utvikling, styring og drift av et utviklingsprosjekt.

2.1.1. Fossefallsmetoden

I 1970 gav Winston Royce ut artikkelen ”Managing the Development of Large Software Systems”. Her delte han sine meninger om det som senere skulle bli kjent som fossefallsmetoden (Larman 2003).

Denne metoden går i korte trekk ut på å dele prosjektet i faser, som skal løses fullstendig før man går i gang med neste. Fossefallsmetoden er en metode som brukes for hele livssyklusen til et program, fra planlegging, design og utvikling og til drift, utfasning og utskiftning. Hele utviklingen blir bestemt i en tidlig planleggingsfase basert på en kravspesifikasjon. Deretter følger utvikling, testing og drift (Tabell 1). Tradisjonelt har fossefallsmetoden vært mye brukt som metode for utviklingsprosjekter.

Problemene med denne metoden er at utvikling kan være vanskelig å forutsi, det kan dukke opp nye krav eller problemer underveis. Metoden gir liten fleksibilitet ettersom man i utgangspunktet skal holde seg til fasene (Dix 1993).

Tabell 1. Fasene i fossefallsmetoden

(18)

2.1.2. Iterativ utvikling

Den største svakheten med fossefallsmetoden er kanskje at det er overambisiøst å tro at

programutvikling kan foregå som strengt fastsatte faser. Det vil alltid bli oppdaget feil og behov kan bli endret underveis. Disse kan enten bli oppdaget under utviklingen eller gjennom testing.

Den eneste måten å være sikker på at den enkelte egenskap fungerer tilfredsstillende, er å utvikle den og teste den ut. Designet kan så bli endret dersom det viser seg at funksjonen ikke var implementert på en god nok måte. Det er dette som kalles iterativ design. Iterativ design blir av mange sett på som en modernisert fossefallsmetode (Tom 1985; Larman 2003).

Iterativ eller evolusjonær systemutvikling er basert på at systemet utvikles i ”evolusjonære faser”.

Man utvikler en eller flere egenskaper, tester dem og retter opp eventuelle feil. Denne prosessen fortsetter til alle egenskapene fungerer tilfredsstillende. Iterativ design benytter prototyper, som inneholder eller simulerer deler av funksjonaliteten til det ferdige programmet. Det finnes tre hovedmåter å utvikle disse prototypene på:

1) Bruk og kast: Man utvikler en prototyp og tester denne. Erfaringene fra utviklingen og testingen av denne ”øvelsen” blir brukt til å utvikle det endelige programmet, men prototypen brukes ikke i det ferdige produktet.

2) Inkrementell: Det ferdige programmet består av ulike komponenter, og disse blir utviklet en etter en. Det ferdige programmet blir lansert som en serie produkter. Hver lansering vil inkludere en ekstra komponent.

3) Evolusjonær: Denne metoden går ut på å utvikle en enkel prototyp og teste denne. Den foregående prototypen vil så bli brukt som basis for den neste prototypen. På denne måten blir programmet bedre. ”Bedre” kan innebære mer funksjonalitet eller bedre funksjonalitet (raskere, mindre feil osv) (Dix 1993).

2.1.3. Agile metoder

Agile metoder, også kalt ekstrem programmeringsmetoder (XP) er en familie teknikker og praksiser som blant annet har fokus på fleksibilitet og tilpasningsdyktighet. Metodene er basert på stadige, raske leveranser av ferdig kode, omfattede testing og et tett samarbeid mellom utviklere og eksperter.

De agile metodene er resultatet etter at en gruppe industrieksperter, den såkalte ”Agile alliansen”, gikk sammen i 2001 for å løse problematikken med at stadig flere prosjekter ble sittende fast i en hengemyr av en utviklingsprosess. Agile metoder fokuserer på at mennesker er den viktigste faktoren for suksess: En god metode vil ikke være nok til å redde et prosjekt fra å mislykkes dersom

(19)

utviklerteamet ikke har gode medspillere. Samtidig er det ikke nok å ha gode folk, dersom disse ikke samarbeider godt nok. Kommunikasjon er derfor en viktig egenskap blant utviklerne. En annen viktig faktor for et vellykket utviklingsprosjekt er å ha gode verktøy. Et godt verktøy trenger derimot ikke å være det nyeste og dyreste. Det viktigste er at man forstår og håndterer verktøyene godt.

Dokumentasjon er også en viktig del av et prosjekt. Men her er det viktig å begrense mengden dokumentering til det som strengt tatt er nødvendig. For mye dokumentasjon er sløsing med ressurser og er verre enn ingen eller mangelfull dokumentasjon.

Kommunikasjon med kunden er også viktig. For at et prosjekt skal lykkes, er det viktig at kunden (brukeren) av programmet følger utviklingen tett. Tilbakemeldinger og testing underveis er viktig. Det vil ofte være vanskelig, både for kunden og utvikleren, å forutsi alle egenskaper og funksjoner programmet skal ha. Misforståelser kan også oppstå. Derfor er det viktig at utviklingsplanene er fleksible slik at man kan svare på endringer og krav til nye funksjoner underveis (Martin 2001;

Cockburn 2002).

2.2. Evalueringsdelen

En evaluering har tre hovedmål: Å vurdere omfanget og tilgjengeligheten til systemets funksjonalitet, å vurdere brukernes erfaring av interaksjonen, og å identifisere spesifikke problemer med systemet (Dix 1993).

Slik lyder målene for en evaluering av et program. I tillegg vil evalueringen av prototypen bli brukt for å hente inn erfaringer og meninger fra brukerne for å kunne besvare oppgavens problemstilling.

Evalueringsdelen har derfor to målsetninger:

1) Å gi en vurdering av prototypen (Funksjonalitet, brukervennlighet osv).

2) Besvare problemstillingen: Kan et slikt verktøy forenkle utvikling og forståelse av wikiontologier?

For å kunne besvare (2) må prototypen være i stand til å utføre de viktigste oppgavene for et slikt visualiseringsprogram: Koble seg til en wiki, laste ned en ontologi fra denne, og gi en alternativ visualisering av ontologien.

2.2.1. Usability

Det ene formålet med evalueringen er få en vurdering av selve programmets ”brukbarhet” eller usability. Til denne delen vil det være behov for en usability metode. Usability studier er en

fellesbetegnelse på metoder der man studerer eller analyserer egenskaper til et produkt for å finne ut om det oppfyller de nødvendige krav til brukervennlighet og funksjonalitet. Det finnes i hovedsak

(20)

Expert usability review

Expert usability review (Abratt 2003; Tasha and David 2007) går som navnet antyder ut på å bruke eksperter under evalueringen. ”Eksperter” kan være utviklere, ”profesjonelle testere” eller andre med inngående kjennskap til produktet som skal testes. Disse vil gjennomgå programmet og dets funksjoner, enten fritt eller basert på heuristisk evaluering (basert på retningslinjer), for avgjøre hvordan programmet fungerer. Heuristic evaluation (Tasha and David 2007) er et eksempel på en slik metode. Denne ble introdusert i 1990 av Nielsen (som regnes som en ”guru” innen usability) og Molich og går ut på at en mindre gruppe usability-eksperter evaluerer brukergrensesnittet ved å bruke et sett med retningslinjer eller metoder og notere viktigheten av hvert usability-problem. I følge utviklerne av metoden, vil fem til ti slike eksperter være i stand til å avdekke 55 til 90 prosent av alle problemer med det aktuelle brukergrensesnittet. Andre eksempler på denne typen metoder er Cognitive walkthrough og Heuristic evaluation (Nielsen 2005).

Usability testing

Usability testing (US_Goverment; Wikipedia 2008) er en metode som brukes til å evaluere et produkt ved å teste det på en gruppe brukere. Det er et kontrollert eksperiment der testpersonene aktivt bruker produktet fremfor å bli vist hvordan det fungerer og så bli spurt om de skjønner det.

Testingen har som målsetning å måle ulike sider ved produktet:

• Effektivitet: Hvor lang tid tar det å løse grunnleggende oppgaver.

• Nøyaktighet: Hvor mange feil gjør brukerne? Og hvor alvorlige er de i så fall?

• Recall: Hvor mye husker brukeren i etterkant. Vil han/hun klare å løse oppgavene igjen uten å måtte bli forklart hvordan det skal gjøres på nytt?

• ”Emosjonell respons”: Hvordan opplever brukeren systemet? Forstår han det? Kan programmet anbefales?

For å måle disse ulike sidene av produktet vil det være nødvendig å anvende ulike metoder for datainnsamling. Observasjon, høyttenkning eller opptak vil være nødvendig for å måle effektivitet og nøyaktighet, mens intervju, spørreundersøkelse eller lignende kan brukes for å måle emosjonell respons.

2.2.2. Datainnsamling

Observasjon

Observasjon er en svært enkel metode der den som evaluerer kun ser på og noterer hva kandidatene gjør når de bruker grensesnittet. Metoden brukes mye til testing av nettsider, men kan også brukes til å teste brukergrensesnittet til et program. Den som utfører testen, heretter kalt administrator, vil sitte nær kandidaten som blir testet for å kunne besvare eventuelle spørsmål testeren måtte komme

(21)

med underveis. Administratoren vil følge nøye med hvordan kandidaten beveger musen og navigerer i programmet. Negative kommentarer vil ofte være til mer hjelp enn positive, ettersom de negative som oftest vil være med på å avdekke problemer med brukergrensesnittet (Jerilyn and Matt 1999).

Tenke høyt

Denne metoden er nesten den samme som observasjon og går ut på at brukerne selv beskriver hva de gjør og hvorfor ved å tenke høyt. Resultatene blir enten notert eller tatt opp (Video eller lydopptak) (Abratt 2003).

Spørreskjema

Spørreskjema er en kvalitativ metode består av en serie spørsmål som på forhånd er definert av forskeren. Disse spørsmålene kan ikke endres av den som er med i testen og svarene er begrenset til et sett med alternativer. Metoden er ment å bli utført på et (ofte stort) antall potensielle

respondenter og prosedyren vil være identisk for alle disse (Tett 2003).

Fordelen med å bruke spørreskjema er at man da har et presist utvalg med spørsmål og

svaralternativer. Dette gjør det lettere å tolke dataene i ettertid. Selve testen er enkel å utføre. Den kan sendes på e-post, deles ut som et skjema eller legges ut på en nettside. Det er enkelt å utføre testen på en stor testgruppe og testpersonene har også mulighet til å være anonyme. Problemene med en slik test er blant annet at det kan være tidkrevende å lage et spørreskjema som fanger opp alle de nødvendige svarene (Hva med ting intervjueren ikke har tenkt på?). Dersom testpersonene ikke forstår spørsmålene har de ingen mulighet til å få avklart disse. Det kan også ta tid å få tilbake svarene.

Intervju

Et alternativ til datainnsamling er å bruke intervjuer. Intervjuer trenger i utgangspunktet mindre planlegging ettersom antall nødvendige spørsmål vil være mindre. Intervjuobjektet kan svare mer og forklare i større detalj hva han faktisk mener for hvert spørsmål. Intervjuobjektet har også mulighet til å avdekke spørsmål og problemstillinger en ikke hadde vært klar over på forhånd. Dette gir bedre svar og mer informasjon for hvert intervjuobjekt. Intervjueren har også mulighet til å gi hjelp underveis dersom intervjuobjektet ikke skjønner problemstillingen. Fordi man får mer informasjon fra hver enkelt testperson, kan man kan klare seg med færre intervjuobjekter. På den negative siden vil mangelen på systematiske svar og mye informasjon gjøre at etterbehandlingen av data bli tidkrevende.

(22)

2.3. Tidligere forskning og utvikling

Ontologier har fått mye oppmerksomhet de siste årene, ikke minst på grunn av den tidligere nevnte semantiske weben hvor de spiller en viktig rolle. De neste avsnittene vil gjennomgå ulike verktøy og tidligere utvikling som er relevant i forhold til dette prosjektet.

2.3.1. Ontologi språk

Ontologi-språk er nødvendige for å kunne lagre ontologier i datasammenheng. Noen formater som vil være aktuelle å støtte under utviklingen vil bli presentert i de neste avsnittene:

XML (eXtensible Markup Language)

XML er et fleksibelt tekstformat som er spesielt tilrettelagt for utveksling av informasjon. Det brukes for å definere dataelementer ved hjelp av ”Tagger” på samme måte som HTML. Disse brukes til å dele opp dokumentet i strukturelle deler. I motsetning til HTML er disse ikke forhåndsdefinerte og hvert dokument kan derfor tilrettelegges med sin egen struktur. Ved å tilby en standard for identifisering av data har XML blitt det mest brukte formatet for utveksling av informasjon mellom programmer og elektroniske tjenester (W3C 1996) (Figur 1).

Figur 1. XML: XML-fil brukt av prosjektets prototyp, WikiVis. (Exclude list=Innhold som ikke skal tas med i en visualisering.)

RDF (Resource Description Framework)

RDF, også kjent som RDFS (RDF Skjema), er utviklet av W3C som en utvidelse av XML med støtte for ontologier. W3C (World Wide Web Consoritium) er en internasjonal organisasjon for standardisering av verdensveven (internett) som blant annet har definert HTML-standarden. W3C definerer formatet som en ”lettvekts ontologi ” for utveksling av kunnskap på weben. Formatet er basert på tripler som beskriver ”ressurser”. Triplene består av tre deler: subjekt, predikat og objekt. Eksempel: ”boken ligger på bordet” vil i RDF bli beskrevet som trippelen: Subjekt: Ressurs som beskriver boken, Predikat: Beskrivelse av egenskapen: ”ligger på” og Objekt: Ressurs som beskriver ”bordet”. De ulike triplene danner til sammen en graf, kalt metadatamodell. Denne måten å beskrive ”ressurser” på er

(23)

en viktig del av W3Cs Semantiske Web: Et forbedret verdensvev hvor automatisert programvare kan lagre, utveksle og bruke maskinlesbar informasjon som blir distribuert på verdensveven (Tauberer 2006; McBride 2007; Herman 2008).

OWL (Web Ontology Language)

OWL er en familie med språk for ontologiutvikling som er utviklet av W3C som en utvidelse av RDF.

OWL består av tre ”underspråk”: OWL Lite er den enkleste formen og tillater enkle regler for å klassifisere hierarkier og enkle begrensninger i en ontologi. OWL DL er designet for å gjøre det mulig å utrykke så mye som mulig i ontologien samtidig som alle konklusjoner og spørringer ontologien tillater er garantert å kunne utføres av en datamaskin. OWL Full er den mest avanserte av språkene.

Det finnes foreløpig ikke programvare som er i stand til å gi en komplett forståelse av alle ontologier utviklet i dette språket og det heller ikke sikkert at dette kan utvikles. Hvert av disse språkene er en utvidelse av det foregående, slik at alt som kan uttrykkes i OWL Lite kan uttrykkes i OWL DL og alt som kan uttrykkes i OWL DL kan uttrykkes i OWL Full, men ikke omvendt (Herman 2007).

DAML OIL. (The DARPA Agent Markup Language)

DAML var et prosjekt som gikk ut på å utvikle språk og verktøy for ontologier med den hensikt å forenkle Semantic Web. Det ble utviklet av DARPA (Defence Advanced Research Projects Agency) i perioden 2000 til 2006. Ontologispråket DAML+OIL er et resultat av dette prosjektet og er en utvidelse av XML og RDF (Horrocks 2001).

2.3.2. Eksisterende ontologiverktøy

Utforskning av eksisterende verktøy og programvare som er relatert til prosjektet vil være en viktig ressurs for å få en bedre forståelse og inspirasjon til utviklingen. Det finnes en rekke verktøy av ulike slag for å håndtere ontologier, enten det er snakk om redigering eller utvikling, utforskning

(browsing), dokumentering, konvertering mellom formater eller grafisk visualisering. En del verktøy kombinerer flere av disse funksjonene. Dette avsnittet vil beskrive noen eksempler på slike verktøy som er blitt studert i forkant av utviklingen.

(24)

Protégé

Protégé (Figur 2) er et av de mest komplette og mest brukte verktøyene for utvikling og visualisering av ontologier. Programmet er utviklet i Java og er gratis og åpen kildekodebasert. Programmet bruker OWL som hovedformat, men støtter også de fleste andre kjente ontologispråk, som RDF, DAML+OIL m.fl. En av de store styrkene til programmet er muligheten for utvidelser gjennom plug- ins. Ettersom programmet er åpenkildekodebasert finnes en rekke plug-ins som tilbyr ekstra funksjonalitet.

Figur 2. Protégé screenshot: Visualisering av OWL-ontologi

OntoEdit

OntoEdit er et utviklingsverktøy for utvikling og vedlikehold av ontologier. Verktøyet er spesielt tilrettelagt for støtte av flere språk i samme ontologi. Ontologier utviklet med verktøyet kan redigeres gjennom et programmeringsgrensesnitt (API) og det er mulig å eksportere ontologiene til generiske, rasjonelle databaser gjennom JDBC grensesnittet. Blant formatene som støttes er RDF, OIL og F-Logic (Figur 3).

Figur 3. OntoEdit Screenshot (http://www.ontoknowledge.org/tools/ontoedit.shtml)

(25)

Ontolingua

Nettbasert verktøy. Grensesnittet består av enkel HTML-funksjonalitet, dvs. valg gjennom HTML- skjema (forms) og linker. Verktøyet bruker sitt eget format med samme navn for å representere ontologiene. Dette er et sært format som minner om programmeringsspråket LISP. Det er likevel mulig å eksportere til andre formater, hvorav DAML+OIL er det mest universelle innen ontologier.

Verktøyet er tilrettelagt for samarbeid ved at flere personer kan logge seg på systemet og redigere den samme ontologien samtidig (Figur 4).

Figur 4. Ontolingua: Screenshots

DOE (The Differential Ontology Editor)

Dette er en enkel editor for å utvikle ontologier. Den har ikke noen form for visualisering, annet enn en tekstbasert utforskning av ontologiens hierarki. Den følger et spesielt sett med regler og metoder for å bestemme posisjonen til de ulike delene av ontologien dette hierarkiet. Programmet er utviklet i Java og støtter noen få ontologiformater, herunder OWL og RDF.

pOWL

pOWL er et verktøy for lagring og manipulering av RDF og OWL ontologier. Redigeringsmulighetene er relativt enkle, men verktøyet støtter også spørringer på ontologiene.

(26)

2.3.3. Samarbeid

Ontologier vil ofte være store og omfattende, derfor blir de ofte utviklet av flere personer. Støtte for samarbeid om utviklingen er derfor en viktig del av mange av de eksisterende ontologi-verktøyene.

Av vertkøyene som er nevnt støtter Ontolingua og pOWL dette. Protégé støtter det gjennom ekstra plugin-funksjonalitet.

Wikier er verktøy som er spesielt tilrettelagt for at flere skal kunne samarbeide om å publisere innhold på nett. Det er derfor et naturlig steg at wikier etter hvert får støtte for å kunne håndtere ontologier. Neste avsnitt vil gjennomgå en del slike wikier.

2.3.4. Ontologi-wikier

Det finnes en rekke wikier som støtter ontologier. Enkelte av disse er utviklet fra grunnen for dette formålet. Eksempler på slike wikier er SweetWiki og IkeWiki. Andre har fått støtte for denne funksjonaliteten lagt til i ettertid. Semantic MediaWiki er et eksempel på det siste. De neste avsnittene gir en kort gjennomgang av ulike wikier som har støtte for ontologier.

SweetWiki

Dette er et prosjekt under utvikling og som er utviklet i Java. Den største forskjellen mellom denne og en vanlig wiki (uten støtte for ontologier), er at den inneholder en WYSIWYG editor (grafisk tillegg) hvor brukeren enkelt kan legge til den ekstra informasjonen som gjør dette til en ontologi. Struktur, arv, definering av begreper og lignende skjer på en grafisk måte uten bruk av kildekode slik de fleste andre ontologi-wikier gjør (SweetWiki 2007; Michel, Fabien et al. 2008).

Semantic MediaWiki

Semantic MediaWiki er et tillegg til MediaWiki (Programvaren som blant annet brukes av

nettleksikonet Wikipedia). Dette tillegget gjør det mulig å legge til innhold i wikien i RDF eller OWL.

Utover muligheten til å lagre innhold i disse formatene har er det stort sett opp til

tredjepartsprogrammer å utnytte den ekstra funksjonaliteten disse formatene tilbyr (Heiko, Markus et al. 2006; SMW 2008).

IkeWiki

Denne wikien støtter RDF og OWL formatene. Både wikisidene og linker kan inneholde kode i disse formatene. I motsetning til Semantic MediaWiki forstår IkeWiki disse formatene og kan derfor blant annet utføre spørringer og validering av ontologiene som er lagret på wikien. Det er mulig å utføre

”smarte” søk basert på begreper og termer som er definert av ontologien, og ikke bare stikkord. For eksempel: Dersom en person som omtales i en side har egenskapene ”Forfatter” og ”kvinne”, vil det

(27)

være mulig å søke frem en liste over andre kvinnelige forfattere. En slik kobling ville vært umulig med en vanlig, stikkord-basert søkefunksjonalitet (Schaffert 2006; IkeWiki 2008).

FOAF (Friend of a Friend)

Dette er et eksperimentelt prosjekt som inneholder et Semantic web vokabular (ontologi) for å beskrive brukerne av systemet. Det er ikke en wiki i vanlig forstand, men prinsippene er omtrent de samme. Brukerne fyller ut informasjon om seg selv som lagres i ontologiformatet RDF. På denne måten kan informasjonen forstås av datamaskiner, som også vil kunne oppdage relasjoner mellom brukerne (Samme interesser, felles venner osv). Det samme prinsippet brukes også av de stadig mer populære nettsamfunnene (Facebook, MySpace osv.) og er bare en av mange måter å utnytte ontologier på.

2.4. Oppsumering

Dette kapitlet har gjennomgått det teoretiske rammeverket for prosjektet. Fra før er det blitt foreslått å besvare prosjektets problemstilling ved å utvikle og evaluere en prototyp av et verktøy for visualisering av wiki-ontologier. Metodene som er gjennomgått er derfor relatert til utvikling og evaluering av programvare. Eksempler på metoder som vil være aktuelle til utviklingen er ”Iterativ utvikling” og ”agile metoder”. For evalueringsdelen ble ulike usability metoder gjennomgått.

Siste del av kapitlet har gjennomgått eksisterende verktøy for utvikling og visualisering av ontologier og wikier med støtte for ontologier. Gjennomgangen viser at finnes det en rekke verktøy for begge disse formålene. Det finnes derimot ingen verktøy som er i stand til å koble seg til en gitt wiki og visualisere innholdet av denne. Det er dette gapet prosjektet vil forsøke å utforske gjennom utviklingen og evalueringen av en prototyp på et slikt verktøy.

(28)

Enklere utvikling og bedre forståelse av ontologier? Design –og utvikling

3. Design –og utvikling

Dette kapitlet tar for seg design og utviklingsdelen av en prototype av et verktøy for visualisering av wikiontologier. Prototypen har fått navnet WikiVis. Kapitlet vil beskrive hovedtrekkene for hvordan utviklingen har foregått, hvilke krav som er satt og hvilke løsninger som er blitt benyttet samt hvorfor. De ulike delene av utviklingen har bestått av hver sine forprosjekt med innhenting av informasjon, design og planlegging. Detaljene for denne planleggingen vil ikke bli tatt opp, bare hovedtrekkene for designet som ble utviklet på grunnlag av disse.

3.1. Metode

I kapittel 2 ble aktuelle metoder for utviklingsdelen presentert. Blant disse var fossefallsmetoden som tradisjonelt har vært brukt som metode for utvikling, særlig for store prosjekter. Videre ble agile metoder beskrevet. Disse har fått mye oppmerksomhet de siste årene. Prototyping ble også

presentert som en aktuell metode. Neste avsnitt vil forklare hvilke metoder som ble valgt for prosjektet og hvorfor.

3.1.1. Valg av metode

Fossefallsmetoden har den fordelen at den er enklest å administrere. Dersom man gjør et godt forarbeid i form av kravspesifikasjon og design og klarer å holde seg til planen vil denne metoden være godt egnet. Fordi dette er et lite prosjekt er nok administrasjon ikke det viktigste. Det vil også være et problem at de ulike fasene må gjøres ferdig før man går videre til neste fordi det kan være vanskelig å forutse alle krav og funksjoner som må implementeres på forhånd. Agile metoder har en langt bedre fleksibilitet og tilpasningsdyktighet, noe som vil være en klar fordel for prosjektet. Disse metodene er derimot basert på hurtige leveranser av kode som stadig blir endret basert på

kommunikasjon med ”kunden”. Det kan bli vanskelig å overholde i dette prosjektet, ettersom det bare er en utvikler (vanskelig å produsere mye kode) og fordi det ville være nødvendig å bruke tid på å rekruttere brukere (”kunder”) til å kommunisere med. Evolusjonær design seiler dermed opp som den mest aktuelle metoden. Også denne metoden er fleksibel, men er mer fokusert på å utvikle en prototyp som blir stadig forbedret. Det kan dukke opp uforutsette problemer underveis og det er på forhånd vanskelig å vite hvilke deler av programmet som vil bli mest krevende å utvikle. Fordi det er begrenset tid og ressurser til disposisjon, er det heller ikke sikkert at det blir mulig å implementere alle ønskene til programmet. Ved å bruke en evolusjonær metode vil det være mulig å starte med de mest kritiske og krevende delene av programmet og utvide programmet gradvis. Fordi prosjektet først og fremst vil være opptatt av å utvikle en fungerende prototyp, vil det ikke være nødvendig å utføre mange små tester underveis, slik de agile metodene krever. En eller noen få tester når programmet ser ut til å fungere tilfredsstillende burde være nok.

(29)

Valget faller altså på evolusjonær (iterativ) metode for utviklingsdelen. Det vil bli utarbeidet en kravspesifikasjon som forteller hva programmet skal eller bør kunne gjøre. Utviklingen vil starte med å utvikle de funksjonene som må utvikles. Dersom det blir tid vil også funksjoner som bør/kan utvikles tatt med. Programmet vil bli utviklet i iterasjoner så langt prosjektet tillater det.

3.1.2. Proof of concept

Som det har blitt nevnt, er formålet med oppgaven først og fremst å besvare problemstillingen: ”Kan et verktøy for visualisering av wiki-ontologier føre til forenklet utvikling og bedre forståelse av slike ontologier?” Prototypen er i så måte et verktøy for å kunne besvare denne problemstillingen, først og fremst gjennom evalueringen, selv om utviklingen også vil kunne gi bedre forståelse av problemet.

Prototypen vil derfor være en såkalt ”Proof of concept”. Det vil si at jeg ønsker å vise at det er mulig å utvikle et fungerende program som tilfredsstiller kravspesifikasjonen i prosjektbeskrivelsen og som kan brukes til å utføre en tilfredsstillende evaluering. Implementering av funksjonene i en eller annen form vil derfor være prioritet fremfor å perfeksjonere og optimalisere hver enkelt del.

3.2. Kravspesifikasjon

Før utviklingen kan starte er det nødvendig å avklare alle krav til programmet som skal utvikles. En kravspesifikasjon skal gi svar på spørsmålene ”Hva” og ”Hvorfor” når det gjelder hvilke funksjoner og generelle egenskaper et system må, bør og kan ha. Enkelte krav vil være viktigere enn andre (”Må”

og ”bør ha”). Disse vil i størst mulig grad bli utviklet først, mens mindre viktige krav (”kan ha” / kjekt å ha”) vil bli utviklet til slutt dersom det blir tid til dette. Listen over krav ble satt opp på forhånd, men har til en viss grad blitt endret etter hvert som planlegging og utvikling har avdekket nye krav.

(30)

3.2.1. Funksjonelle krav

Funksjonelle krav er krav til hvilke funksjoner systemet skal eller bør ha.

Programmets funksjonelle krav er vist i Tabell 2 (Nr. vil bli brukt for å referere til de ulike kravene).

Tabell 2. Funksjonelle krav

3.2.2. Ikke-funksjonelle krav

Ikke-funksjonelle krav er krav til egenskaper som programmet skal eller bør ha.

Programmets ikke-funksjonelle krav er vist i Tabell 3.

Tabell 3. Ikke-funksjonelle krav

(31)

3.2.3. Krav til dokumentasjon

• Det skal skrives en enkel manual som dekker installasjon og innføring i bruk av programmet.

• All kode skal dokumenteres ved hjelp av Javadoc⁴

• Hjelp funksjonalitet i programmet

• Dokumentasjonen skal være på engelsk (Eventuelt norsk og engelsk) for at så mange som mulig skal kunne forstå den. Det samme gjelder for programmet.

3.2.4. Andre krav

• Programmet og koden skal publiseres på web

• Programmet skal være ikke-kommersielt og fritt tilgjengelig (Åpen kildekode)

• Som følge av punktet over skal alle eksterne biblioteker (APIer) også være ikke-kommersielle

3.3. Verktøy

Det er blitt benyttet en rekke ulike verktøy under utviklingen av programmet. Dette avsnittet vil gi en kort presentasjon av de viktigste verktøyene som er blitt benyttet for prosjektet.

Java har blitt valgt som programmeringsspråk for prosjektet. Det er flere årsaker til at dette språket ble valgt fremfor andre språk. Den viktigste årsaken har vært at dette er det programmeringsspråket undertegnede er best kjent med. I tillegg er Java plattformuavhengig og kan i prinsippet kjøres på alle maskinvareplattformer (Windows, Mac, Unix, Linux osv). Det er også mulig å kjøre javaprogrammer direkte i en nettleser.

Hovedverktøyet var Eclipse 3.3 Europa (Figur 5). Dette er en komplett utviklingsplattform (IDE) for blant annet Java, utviklet av IBM. Dette programmet ble benyttet til å utvikle mesteparten av kildekoden for programmet. Mens Eclipse er godt egnet til å utvikle kode og funksjonalitet, har verktøyet noe begrenset mulighet for å utvikle grafiske brukergrensesnitt (Vinduer, dialogbokser, knapper osv). Derfor ble et annet verktøy, NetBeans 5.5.1 benyttet til denne delen. NetBeans gjør det mulig å ”tegne” det grafiske brukergrensesnittet ved å dra og slippe elementer for vinduer og knapper. NetBeans har stort sett samme funksjonalitet som Eclipse, og er utviklet av Sun

Microsystems (Samme selskap som har utviklet Java).

(32)

Figur 5. Screenshot: Eclipse 3.3 Europa

Programmet genererer automatisk koden for dette designet. Andre verktøy som ble benyttet var grafiske verktøy for å lage skisser og planlegge det overordnede designet til programmet og designe grafiske elementer i programmet (Logoer, ikoner osv). MediaWiki, som er en wikiserver, ble også benyttet for å teste programmets funksjonalitet under utviklingen. Tabell 4 viser en liste programmer og verktøy som er blitt benyttet under utviklingen. De viktigste verktøyene og Javabibliotekene vil få en nærmere presentasjon senere.

Tabell 4. Verktøy som er brukt under utviklingen

(33)

3.4. Utviklingen

3.4.1. Planlegging og overordnet design

Utviklingen av et verktøy for visualisering av wikiontologier vil være et stort og omfattende prosjekt.

For å ikke miste oversikten over utviklingen og i henhold til ”god programmeringsskikk” ble derfor de ulike hovedfunksjonene fordelt på ulike programmoduler. Ideen med modularitet er at det ferdige programmet skal bestå av uavhengige ”byggeklosser” eller ”moduler”. Hver modul har et minimalt antall inn og ut parametre som er nødvendig for å kunne utføre modulens oppgave. Resten av detaljene er skjult for de øvrige modulene (Også kjent som ”black box”). Utover dette er hver modul uavhengig. Fordelen med denne modellen er at hver modul kan byttes ut eller endres uten at dette får innvirkning på resten av programmet. Dette gjør det enklere å oppgradere og utvide programmet i ettertid, ikke minst for andre utviklere uten kjennskap til hele programmets struktur og

funksjonalitet.

De ulike modulene vil være basert på generelle klasser. Funksjonaliteten og informasjonsflyten mellom de ulike modulene vil være bestemt gjennom disse klassene. På denne måten vil det være mulig å bytte ut hver enkelt modul uten at de øvrige modulene eller programmet trenger å

forandres. Programmet vil være lagt opp til at det kan finnes flere implementasjoner av den enkelte modul, for eksempel flere ”tolker” for å håndtere ulike typer informasjon, flere ”visualiseringer” for å vise alternative grafiske fremstillinger av den samme ontologien osv. I Java er det to måter å

implementere generelle klasser: Interface og Abstract class. Interface er den vageste av de to løsningene og definerer kun et sett med metoder (funksjoner) som må implementeres. Hva

funksjonene faktisk gjør er helt opp til den enkelte implementasjon. Abstract class er en mer konkret løsning og består av en halvferdig klasse der deler av koden allerede er implementert, mens resten (det som vil skille ulike implementasjoner) blir definert som abstrakt. Abstrakte klasser må utvides for å kunne brukes og de abstrakte funksjonene må implementeres av underklassene. Alle utvidelser kan derimot behandles på samme måte fordi de har samme funksjoner. Forskjellen vil være at de gjennom ulik implementasjon håndterer funksjonaliteten på ulike måter.

(34)

Oppdeling i moduler

Programmet ble delt opp i tre moduler som ble utviklet uavhengig som egne prosjekter. Figur 6 viser en tidlig skisse av modulene og den overordnede funksjonaliteten til programmet. Chat-modulen som vises i figuren, ble ikke tatt med i det endelige programmet. Denne funksjonen er definert som mindre viktig i kravspesifikasjonen og ble fjernet fordi den ville ta for mye tid å utvikle. Av figuren fremgår det også hvordan de ulike modulene er avhengige av hverandre. Visualiseringsmodulen er avhengig av å kunne kommunisere med tolkmodulen som igjen er avhengig av dataene

kommunikasjonsmodulen laster ned fra en wiki. Den mest programkritiske modulen er derfor kommunikasjonsmodulen. Den ble derfor utviklet først, etterfulgt av tolkmodulen og

visualiseringsmodulen. De to siste ble delvis utviklet parallelt da utviklingen av visualiseringsmodulen avdekket nye behov og tilpasninger for å fungere optimalt med tolkmodulen.

Figur 6. Programmets moduler

Programmets grafiske brukergrensesnitt (GUI) ble utviklet med denne modellen som grunnlag. Tabell 5 forklarer hvilken funksjonalitet de ulike modulene skal løse. Løsninger og valg som er gjort under resten av utviklingen vil bli gjennomgått i avsnittene som omhandler de ulike modulene.

Tabell 5. Tabell: Modulenes funksjoner

(35)

3.4.2. GUI

Programmets brukergrensesnitt (GUI) ble utviklet parallelt med programmets moduler. Denne delen har som formål å binde sammen de øvrige modulene samt å håndtere interaksjon mellom bruker og program. Det har vært en målsetting at denne delen av programmet skal være så intuitiv og

brukervennlig som mulig. Figur 7 viser en tidlig skisse til hvordan brukergrensesnittet skulle se ut.

Chat-funksjonen ble som nevnt fjernet. I stedet har denne delen av brukergrensesnittet fått en ny funksjon, ”Statuspanelet”. Dette er et tekstfelt de øvrige modulene kan bruke til å vise informasjon og feilmeldinger. Det ble også utviklet en egen nettleser for programmet. Denne kan brukes til å studere den opprinnelige wikisiden (uten visualisering). I tillegg har programmet en

hjelpfunksjonalitet. Denne kan åpnes fra programmets meny.

Figur 7. Skisse til programmets brukergrensesnitt, første utkast

(36)

Figur 8 viser det endelige brukergrensesnittet til programmet. Som det fremgår av figurene har designet knapt blitt endret i forhold til den første skissen. Brukergrensesnittet er delt opp i 4 hoveddeler (Se Figur 8).

1)

Figur 8. Screenshot: De ulike delene av programmets GUI (WikiVis 1.0)

2) Denne delen inneholder funksjoner for å koble til en wiki. En kan velge hvilken type wiki programmet skal koble seg til fra en liste over ”Filter” (Nærmere forklaring i avsnittet om utvikling av kommunikasjonsmodulen). Knapper og felt for utfylling av informasjon vil være definert av filteret som er valgt.Visualisering: Programmet støtter flere visualiseringer. Det er lagt til rette for å legge til flere i ettertid. Det er mulig å veksle mellom de ulike

visualiseringene.

3) Viser en oversikt over klasser og instanser i ontologien. Informasjonen hentes ved hjelp av Tolkmodulen

4) Statuspanelet: Viser meldinger og feilmeldinger (Kan brukes fritt av de ulike modulene).

Applet vs Java application

Javaprogrammer kan utvikles enten som selvstendige (Stand alone) programmer eller som ”Applets”.

En ”applet” er et javaprogram som kan kjøres direkte i en nettleser. En av fordelene med denne løsningen er at brukeren ikke trenger å installere programmet på egen maskin, noe som forenkler bruken av det. På den andre siden er man da avhengig av at nettstedet som inneholder appleten er tilgjengelig når programmet skal kjøres. Den største begrensningen for appletløsningen er likevel de

(37)

sikkerhetsmessige begrensningene knyttet til denne typen programmer. Dette gjelder særlig tilgang til filsystem. Selvstendige javaprogrammer har ikke isse begrensningene. Et slikt program må derimot installeres og kjøres lokalt på en maskin og kan ikke kjøres i en nettleser. Selv om dette medfører ekstraarbeid i form av installasjon, betyr det at programmet ikke er avhengig av en eventuell

tjenestetilbyder som tilbyr en applet over nett. Den tredje muligheten er å utvikle programmet slik at det fungerer både som applet og som selvstendig program. Dette krever derimot en god del

tilpasninger for hvert av de to ”modusene”. Fordi en applet vil ha begrenset funksjonalitet ble denne løsningen forkastet. Hybridløsningen ble vurdert, men fordi dette vil medføre mye ekstraarbeid ble det bestemt at programmet skulle utvikles som et ”fullverdig”, selvstendig javaprogram.

Splits

Det grafiske brukergrensesnittet er delt opp i tre hoveddeler (Tilkoblingsdel/kommunikasjon, visualiseringer/nettleser og statuspanel). Statuspanelet kan gi nyttige tilbakemeldinger, særlig dersom noe går galt (En tilkobling mislykkes eller en annen feil oppstår), men kan også ta beslag på unødvendig plass. Når en side først er visualisert, kan det dessuten være nyttig å forstørre

visualiseringsvinduet så mye som mulig for å studere visualiseringen. For å få til dette er de ulike delene av programmet delt opp ved hjelp av såkalte "splits" (I Java kalt JSplitPane).

Størrelsesforholdet mellom disse kan endres ved behov. De kan maksimeres eller minimeres eller man kan tilpasse størrelsen (Det er dog satt inn en del begrensninger og minimumsstørrelser på enkelte av delene).

Visualiseringer er delt opp ved hjelp av faner (Engelsk: Tabs, Java: JTabPane). Dermed kan man veksle mellom de tilgjengelige visualiseringene (Herunder nettleseren). Bare den valgte visualiseringen vil bli vist på skjermen. Statuspanelet har samme funksjon for å skille mellom ulike typer meldinger (Figur 9).