Lokasjons- og kontekstbaserte tjenester - Department of Computer ...
Lokasjons- og kontekstbaserte tjenester - Department of Computer ... Lokasjons- og kontekstbaserte tjenester - Department of Computer ...
4 PROTOTYPING 51 4.3.1 Valgt teknologi i informasjonsdel I tillegg til valgene diskutert i avsnitt 4.2.1 er det tatt flere valgt med tanke p˚a informasjonsdelen. Valgene tatt i lokasjonsdelen har p˚avirket valgene i informasjonsdelen, mens valget av VB.NET gjorde at ogs˚a informasjonsdelen er utviklet i VB.NET. Teknologiene er diskutert i kapittel 2, men unntak av nettleseren som diskuteres under. • AROUND AROUND er en arkitektur for ˚a knytte tjenester til en eller flere lokasjoner. Arkitekturen er ˚apen med tanke p˚a posisjoneringssystem eller teknologi. AROUND [16] foresl˚ar en arkitektur for ˚a oppdage og relatere tjenester til en geografisk posisjon. Artikkelen opererer med to framgangsm˚ater: a) avstands-basert utvelgelse (distant-based utvelgelse), og b) omfangs-basert utvelgelse (scope-based utvelgelse), som nevnt i avsnitt 2.3.6. Dette avsnittet ser nærmere p˚a selve arkitekturen. Grunnen til at kun omfangs-basert utvelgelse er aktuell for denne oppgaven er at avstands-basert utvelgelse krever at det er mulig ˚a avgjøre avstanden mellom to punkter. Dette er ikke mulig ved hjelp av posisjoneringsmodulen slik den er implementert i denne oppgaven, og heller ikke mulig med tilsvarende posisjoneringsteknikker basert p˚a WiFi som er tilgjengelig. Selv om artikkelen argumenterer for at begge modellene burde implementeres i et kontekstavhengig system, er det i artikkelen ogs˚a kun benytte seg av omfangs-basert utvelgelse, selv om feks. GPS tilbyr avstand mellom to punkter. Som forklart i avsnitt 4.2 er lokasjonsdata organisert i en trestruktur, der “Campus” er rotnoden. Bygninger, etasjer og rom er hhv. første, andre og tredje niv˚a under rotnoden. Grunnen til en slik enkel struktur er at den er med p˚a ˚a støtte omfangs-basert utvelgelse av tjenester. Ser vi p˚a figur 9 er lokasjonsdata representert ved sirkler, og tjenester som rektangler. Omfang eksisterer allerede i lokasjonsdata avhengig av hvor vi kobler tjenestene i treet. En tjeneste knyttet til noden “Campus” vil være tilgjengelig uansett lokasjon, mens tjenester knyttet til node 1.etg. vil kun være tilgjengelig i første etasje i bygning IT-Vest. Modell tilbyr ogs˚a ˚a lage egne omfangs omr˚ader ved ˚a kombinere flere lokasjoner, som feks første, tredje og femte etasje i en bygning. Det er heller ingenting i veien for ˚a kombinere en hel bygning med noen f˚a rom fra en annen bygning. Noe av informasjonen som blir presentert i “Fumble” har dedikerte komponenter, som feks. kontekstavhengige meldinger og alternativ tekst. Dette er gjennomg˚att i avsnitt 4.7.2. Ved ˚a velge ˚a lese en melding overfører Fumble kontrollen til en intern nettleser, som overtar ansvaret for ˚a presentere informasjonen.
52 4 PROTOTYPING • Nettleser En nettleser er et program som gjør brukere i stand til ˚a lese websider. Det finnes flere konkurrerende nettlesere p˚a markedet som Opera, FireFox, Netscape Navigator og Internet Explorer. Grunnen til at det ble implementert en nettleser er at dette gjør det enkelt ˚a integrere andre systemer. Nettleseren gjør at systemer som Innsida, webmail og It’s:Learning kan presenteres i prototypen, i tillegg til at prototypen kan fungere som et mellomlag mellom andre systemer og brukeren for ˚a tilby økt funksjonalitet. VB.NET rammeverket inneholder en plugin som gjør det lett ˚a integrere en nettleser i Windows Applikasjoner. N˚ar dette er gjort oppfører den seg akkurat som en hvilken som helst annen nettleser. Arbeidet mitt ved NTNU har gitt meg erfaring med flere m˚ater˚a lagre informasjon p˚a. Spesielt viktig for denne oppgaven er metadata og Gazetteers. • Metadata Metadata (avsnitt 2.2.3) er viktig for at systemet skal kunne nyttegjøre seg informasjon. Fumble inneholder kun et utvalg av dataposter med tilhørende beskrivelser. Dette fordi prototypen er kun ment som et verktøy som har som oppgave ˚a bevise at det er mulig ˚a gjøre det p˚a foresl˚atte m˚ate. Det kan nevnes at det er enkelt ˚a utvide prototypen med flere dataposter hvis dette er ønskelig. Postene som er valgt implementert er i tillegg til en unik ID: – Alternativ beskrivelse: Dette er en beskrivende tekst som trer i kraft hvis systemet ikke har en databærer tilgjengelig eller at meldingen ikke er knyttet til en webside. – URL: Denne inneholder en webadresse hvis meldingen er knyttet til en webside. Se punkt Gazetteers under. – Type: Denne inneholder en klassifisering av informasjonen. Se punkt Gazetteers under. • Gazetteers Systemet har implementert en generell Gazetteer (se ogs˚a avsnitt 6.3). Selv om Fumble kun benytter en generell Gazetteer, var det planlagt ˚a implementere en standard Gazetteer som feks. ADL Gazetteer. Dette er en standard som tillater bidrag til samme lokasjon fra flere bidragsytere. Noe som vil være reelt i et ferdig kontekstavhengig system. Attributtene i en generell Gazetteer, med tilhørende oppføringer, er listet under: – Geografisk navn inneholder: Stedsnavn, Gyldig navn (Boolean), Dato fra og Dato til. I Fumble ble kun Stedsnavn implementert.
- Page 13 and 14: 2 1 INNLEDNING mye tid du har tilgj
- Page 15 and 16: 4 1 INNLEDNING baren. Etter en lite
- Page 17 and 18: 6 2 STATE OF THE ART 2.1.1 Lokasjon
- Page 19 and 20: 8 2 STATE OF THE ART fastsl˚a at e
- Page 21 and 22: 10 2 STATE OF THE ART Se ogs˚a avs
- Page 23 and 24: 12 2 STATE OF THE ART 2.2.3 Metadat
- Page 25 and 26: 14 2 STATE OF THE ART graphs with p
- Page 27 and 28: 16 2 STATE OF THE ART 2.3.2 RADAR R
- Page 29 and 30: 18 2 STATE OF THE ART sisjonsavheng
- Page 31 and 32: 20 2 STATE OF THE ART det ikke fore
- Page 33 and 34: 22 2 STATE OF THE ART som befinner
- Page 35 and 36: 24 3 MITT SYSTEM 3.2 Brukere av sys
- Page 37 and 38: 26 3 MITT SYSTEM Appendix B. Bruker
- Page 39 and 40: 28 3 MITT SYSTEM Figur 4: Systemstr
- Page 41 and 42: 30 3 MITT SYSTEM stavhengig system.
- Page 43 and 44: 32 3 MITT SYSTEM Figur 6: Mulige ka
- Page 45 and 46: 34 3 MITT SYSTEM AROUND-arkitekture
- Page 47 and 48: 36 3 MITT SYSTEM I de neste punkten
- Page 49 and 50: 38 3 MITT SYSTEM logge seg inn i de
- Page 52 and 53: 4 PROTOTYPING 41 4 Prototyping P˚a
- Page 54 and 55: 4 PROTOTYPING 43 vil være unik for
- Page 56 and 57: 4 PROTOTYPING 45 Figur 12: Signalst
- Page 58 and 59: 4 PROTOTYPING 47 oppgaven og det er
- Page 60 and 61: 4 PROTOTYPING 49 en del av samme sy
- Page 64 and 65: 4 PROTOTYPING 53 - Navnetyper inneh
- Page 66 and 67: 4 PROTOTYPING 55 - Finn lokasjon: D
- Page 68 and 69: 4 PROTOTYPING 57 Figur 14: Fumble :
- Page 70 and 71: 4 PROTOTYPING 59 Figur 15: Fumble :
- Page 72 and 73: 4 PROTOTYPING 61 scope, slik det er
- Page 74 and 75: 4 PROTOTYPING 63 muligens fordi enk
- Page 76 and 77: 4 PROTOTYPING 65 AP ID MAC Signal N
- Page 78 and 79: 4 PROTOTYPING 67 Utover dette har i
- Page 80 and 81: 4 PROTOTYPING 69 Figur 19: Informas
- Page 82: 4 PROTOTYPING 71 4.8 Oppsummering p
- Page 85 and 86: 74 5 TESTING OG EVALUERING AV FUMBL
- Page 87 and 88: 76 5 TESTING OG EVALUERING AV FUMBL
- Page 89 and 90: 78 5 TESTING OG EVALUERING AV FUMBL
- Page 91 and 92: 80 5 TESTING OG EVALUERING AV FUMBL
- Page 93 and 94: 82 5 TESTING OG EVALUERING AV FUMBL
- Page 95 and 96: 84 5 TESTING OG EVALUERING AV FUMBL
- Page 97 and 98: 86 5 TESTING OG EVALUERING AV FUMBL
- Page 99 and 100: 88 5 TESTING OG EVALUERING AV FUMBL
- Page 101 and 102: 90 5 TESTING OG EVALUERING AV FUMBL
- Page 103 and 104: 92 5 TESTING OG EVALUERING AV FUMBL
- Page 105 and 106: 94 6 KONKLUSJON OG VIDERE ARBEID in
- Page 107 and 108: 96 6 KONKLUSJON OG VIDERE ARBEID M
- Page 110 and 111: REFERANSER 99 Referanser [1] A9. A9
4 PROTOTYPING 51<br />
4.3.1 Valgt teknol<strong>og</strong>i i informasjonsdel<br />
I tillegg til valgene diskutert i avsnitt 4.2.1 er det tatt flere valgt med tanke p˚a informasjonsdelen.<br />
Valgene tatt i lokasjonsdelen har p˚avirket valgene i informasjonsdelen,<br />
mens valget av VB.NET gjorde at <strong>og</strong>s˚a informasjonsdelen er utviklet i<br />
VB.NET. Teknol<strong>og</strong>iene er diskutert i kapittel 2, men unntak av nettleseren som<br />
diskuteres under.<br />
• AROUND<br />
AROUND er en arkitektur for ˚a knytte <strong>tjenester</strong> til en eller flere lokasjoner.<br />
Arkitekturen er ˚apen med tanke p˚a posisjoneringssystem eller teknol<strong>og</strong>i.<br />
AROUND [16] foresl˚ar en arkitektur for ˚a oppdage <strong>og</strong> relatere <strong>tjenester</strong><br />
til en ge<strong>og</strong>rafisk posisjon. Artikkelen opererer med to framgangsm˚ater: a)<br />
avstands-basert utvelgelse (distant-based utvelgelse), <strong>og</strong> b) omfangs-basert<br />
utvelgelse (scope-based utvelgelse), som nevnt i avsnitt 2.3.6. Dette avsnittet<br />
ser nærmere p˚a selve arkitekturen.<br />
Grunnen til at kun omfangs-basert utvelgelse er aktuell for denne oppgaven<br />
er at avstands-basert utvelgelse krever at det er mulig ˚a avgjøre avstanden<br />
mellom to punkter. Dette er ikke mulig ved hjelp av posisjoneringsmodulen<br />
slik den er implementert i denne oppgaven, <strong>og</strong> heller ikke mulig med<br />
tilsvarende posisjoneringsteknikker basert p˚a WiFi som er tilgjengelig. Selv<br />
om artikkelen argumenterer for at begge modellene burde implementeres<br />
i et kontekstavhengig system, er det i artikkelen <strong>og</strong>s˚a kun benytte seg av<br />
omfangs-basert utvelgelse, selv om feks. GPS tilbyr avstand mellom to punkter.<br />
Som forklart i avsnitt 4.2 er lokasjonsdata organisert i en trestruktur, der<br />
“Campus” er rotnoden. Bygninger, etasjer <strong>og</strong> rom er hhv. første, andre <strong>og</strong><br />
tredje niv˚a under rotnoden. Grunnen til en slik enkel struktur er at den er<br />
med p˚a ˚a støtte omfangs-basert utvelgelse av <strong>tjenester</strong>. Ser vi p˚a figur 9 er<br />
lokasjonsdata representert ved sirkler, <strong>og</strong> <strong>tjenester</strong> som rektangler. Omfang<br />
eksisterer allerede i lokasjonsdata avhengig av hvor vi kobler tjenestene i<br />
treet. En tjeneste knyttet til noden “Campus” vil være tilgjengelig uansett<br />
lokasjon, mens <strong>tjenester</strong> knyttet til node 1.etg. vil kun være tilgjengelig<br />
i første etasje i bygning IT-Vest. Modell tilbyr <strong>og</strong>s˚a ˚a lage egne omfangs<br />
omr˚ader ved ˚a kombinere flere lokasjoner, som feks første, tredje <strong>og</strong> femte<br />
etasje i en bygning. Det er heller ingenting i veien for ˚a kombinere en hel<br />
bygning med noen f˚a rom fra en annen bygning.<br />
Noe av informasjonen som blir presentert i “Fumble” har dedikerte komponenter,<br />
som feks. kontekstavhengige meldinger <strong>og</strong> alternativ tekst. Dette er gjennomg˚att<br />
i avsnitt 4.7.2. Ved ˚a velge ˚a lese en melding overfører Fumble kontrollen til en<br />
intern nettleser, som overtar ansvaret for ˚a presentere informasjonen.
Change language