Lokasjons- og kontekstbaserte tjenester - Department of Computer ...
Lokasjons- og kontekstbaserte tjenester - Department of Computer ... Lokasjons- og kontekstbaserte tjenester - Department of Computer ...
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 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
3 MITT SYSTEM 33<br />
p˚a hvilket avtrykk dette aksesspunktet tilhører, i tillegg til hvilket Fingeravtrykk<br />
(attributt Fingerpring ID).<br />
Ved˚a utvide AROUND-arkitekturen p˚a denne m˚aten, har systemet n˚a muligheten<br />
for ˚a definere et punkt <strong>og</strong> i tillegg kunne knytte flere m˚alinger opp mot dette<br />
punktet.<br />
3.6.3 Informasjonsdel<br />
Informasjonsdelen bygger p˚a lokasjonsdelen <strong>og</strong> er blitt utformet med tanke p˚a<br />
hva slags informasjon systemet skal forvalte, i tillegg til hvordan systemet skal<br />
integreres med andre systemer. Det er alts˚a tre viktige kriterier som m˚a oppfylles:<br />
1) det m˚a være en sammenheng mellom informasjonen <strong>og</strong> lokasjonen i modellen<br />
2) hva slags informasjon systemet skal ta vare p˚a, <strong>og</strong> 3) hvordan systemet skal<br />
integreres mot andre systemer.<br />
AROUND-arkitekturen definerer informasjon som en tjeneste. Mitt system vil<br />
tilby b˚ade informasjon <strong>og</strong> tilgang til andre <strong>tjenester</strong>. Det er derfor nødvendig ˚a<br />
utvide AROUND-arkitekturen. Figur 8 beskriver hvordan AROUND-arkitekturen<br />
utvides for ˚a tilpasse modellen til ˚a gjelde b˚ade <strong>tjenester</strong> <strong>og</strong> informasjon.<br />
Figur 8: Struktur i informasjonsdel<br />
Det er flere faktorer som har vært avgjørende for informasjonsdelen. For det første<br />
har GUIDE[8] identifisert fire typer informasjon som hører til i en informasjonsdel.<br />
For det andre har metadata vært viktig for ˚a beskrive informasjonen. Til slutt har<br />
en generell gazetteer blitt brukt med tanke p˚a at denne kan utvides p˚a et senere<br />
tidspunkt (se avsnitt 2.2.4).<br />
Figur 8 beskriver hvordan systemet beskriver informasjon, Informasjon er knyttet<br />
til en navne-type (tabell “Type”) slik det er foresl˚att i avsnitt 3.5, samt informasjonen<br />
grupperes for ˚a slippe ˚a søke igjennom all tilgjengelig informasjon<br />
(tabell “Scope”). Modellen støtter dermed raske oppslag, samtidig som relasjonen<br />
mellom det fysiske rommet <strong>og</strong> informasjonsrommet er ivaretatt, se punktet under.<br />
Relasjonen mellom lokasjonsdel <strong>og</strong> informasjonsdel<br />
Et av m˚alene med denne oppgaven er ˚a skape en relasjon mellom lokasjon <strong>og</strong><br />
informasjon. I et system der b˚ade lokasjon <strong>og</strong> informasjon er i konstant endring<br />
er det viktig ˚a utvikle en modell som gjør det konseptuelt enkelt ˚a forst˚a hvordan<br />
lokasjon <strong>og</strong> informasjon henger sammen[16, 22].