Lokasjons- og kontekstbaserte tjenester - Department of Computer ...

More documents

Recommendations

Info

3 MITT SYSTEM 33 p˚a hvilket avtrykk dette aksesspunktet tilhører, i tillegg til hvilket Fingeravtrykk (attributt Fingerpring ID). Ved˚a utvide AROUND-arkitekturen p˚a denne m˚aten, har systemet n˚a muligheten for ˚a definere et punkt og i tillegg kunne knytte flere m˚alinger opp mot dette punktet. 3.6.3 Informasjonsdel Informasjonsdelen bygger p˚a lokasjonsdelen og er blitt utformet med tanke p˚a hva slags informasjon systemet skal forvalte, i tillegg til hvordan systemet skal integreres med andre systemer. Det er alts˚a tre viktige kriterier som m˚a oppfylles: 1) det m˚a være en sammenheng mellom informasjonen og lokasjonen i modellen 2) hva slags informasjon systemet skal ta vare p˚a, og 3) hvordan systemet skal integreres mot andre systemer. AROUND-arkitekturen definerer informasjon som en tjeneste. Mitt system vil tilby b˚ade informasjon og tilgang til andre tjenester. Det er derfor nødvendig ˚a utvide AROUND-arkitekturen. Figur 8 beskriver hvordan AROUND-arkitekturen utvides for ˚a tilpasse modellen til ˚a gjelde b˚ade tjenester og informasjon. Figur 8: Struktur i informasjonsdel Det er flere faktorer som har vært avgjørende for informasjonsdelen. For det første har GUIDE[8] identifisert fire typer informasjon som hører til i en informasjonsdel. For det andre har metadata vært viktig for ˚a beskrive informasjonen. Til slutt har en generell gazetteer blitt brukt med tanke p˚a at denne kan utvides p˚a et senere tidspunkt (se avsnitt 2.2.4). Figur 8 beskriver hvordan systemet beskriver informasjon, Informasjon er knyttet til en navne-type (tabell “Type”) slik det er foresl˚att i avsnitt 3.5, samt informasjonen grupperes for ˚a slippe ˚a søke igjennom all tilgjengelig informasjon (tabell “Scope”). Modellen støtter dermed raske oppslag, samtidig som relasjonen mellom det fysiske rommet og informasjonsrommet er ivaretatt, se punktet under. Relasjonen mellom lokasjonsdel og informasjonsdel Et av m˚alene med denne oppgaven er ˚a skape en relasjon mellom lokasjon og informasjon. I et system der b˚ade lokasjon og informasjon er i konstant endring er det viktig ˚a utvikle en modell som gjør det konseptuelt enkelt ˚a forst˚a hvordan lokasjon og informasjon henger sammen[16, 22].
34 3 MITT SYSTEM AROUND-arkitekturen foresl˚ar en abstrakt relasjon mellom lokasjon og informasjon som knytter informasjon til lokasjon. I den fysiske verden er informasjon knyttet til en bestemt lokasjon, og m˚alet er ˚a knytte samme informasjon p˚a en lignende m˚ate til en eller flere informasjonsrom i systemet. Et kontekstavhengig system vil inneholde store mengder informasjon. I tillegg vil denne informasjonen best˚a av flere typer (se avsnitt 3.6.3). Som nevnt benyttes metadata for ˚a beskrive denne informasjonen. Dette er nødvendig da informasjon kan være en adresse til en tjeneste som tilbyr informasjon, historisk informasjon, geografisk informasjon, osv. Figur 9 foresl˚ar en slik relasjon. Figur 9: Informasjonsmodell Lokasjonsdelen er her den øverste rekken med tabeller, mens informasjonsdelen er den nederste. Relasjonen er den stipla linjen som g˚ar mellom tabellen L S (Location Service) og tabellene “Campus”, “Building”, “Floor” og “Room”. Tanken er her at det er attributten “Coverage” som forteller systemet hvilken lokasjon informasjonen er knyttet til, alts˚a hvilken tabell i lokasjonsdelene systemet skal sl˚a opp i. En slik relasjon kan opprettes s˚a mange ganger som ønskelig, som beskrevet i avsnitt 2.2.1, og dermed kan informasjon eksistere for flere lokasjoner samtidig. Hva slags informasjon skal systemet ta vare p˚a og hvordan Et kontekstavhengig system skal ikke ta over for eksisterende informasjonssystem, men er et system som skal fungere som en slags personlig assistent som har kjennskap til omgivelsene. Derfor skal det ikke i dette systemet lagres informasjon som allerede finnes andre steder, eller i andre systemet. Det som blir viktig for mitt system er ˚a lagre pekere til andre informasjonskilder og tjenestetilbydere, og hvordan kommunikasjon mot disse skal foreg˚a. Systemet m˚a ogs˚a kunne lagre diverse opplysninger om informasjonene, som rettigheter, tilgjengelighet (begrenset feks. av tid), alternative kilder, osv. Oppgaven ser her bort fra data som er nødvendig i lokasjonsdelen, da dette er gjennomg˚att i avsnitt 3.6.2. Figur 9 beskriver i tillegg til type, to andre attributter:
Page 1 and 2: Lokasjons- og kontekstbaserte tjene
Page 3 and 4: ii Sammendrag Denne oppgaven presen
Page 6 and 7: INNHOLD v Innhold Forord i Sammendr
Page 8 and 9: INNHOLD vii 5.3.1 Innhold i testdat
Page 10: TABELLER ix 15 Tabell Type . . . .
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: 32 3 MITT SYSTEM Figur 6: Mulige ka
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 62 and 63: 4 PROTOTYPING 51 4.3.1 Valgt teknol
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 95 and 96:
84 5 TESTING OG EVALUERING AV FUMBL
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
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
Page 112 and 113:
REFERANSER 101 [22] Ole Hestnes og
Page 114 and 115:
A TERMINOLOGI 1 Appendix A Terminol
Page 116 and 117:
B KRAVSPESIFIKASJON 3 Alternative c
Page 118 and 119:
B KRAVSPESIFIKASJON 5 3. Case condi
Page 120 and 121:
B KRAVSPESIFIKASJON 7 - Attributten
Page 122 and 123:
C INSTALLASJONSMANUAL FUMBLE 9 C In
Page 124 and 125:
D BRUKERMANUAL FUMBLE 11 D Brukerma
Page 126 and 127:
E TR˚ADLØSE SIGNALER 13 E Tr˚adl
Page 128 and 129:
F FUNKSJONER 15 dette. I tillegg er
show all

Lokasjons- og kontekstbaserte tjenester - Department of Computer ...

Create successful ePaper yourself

Delete template?

Save as template?