<%BANNER%>

Context-Driven Programming Model for Pervasive Spaces

xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd
INGEST IEID E20110331_AAAAAU INGEST_TIME 2011-03-31T10:33:54Z PACKAGE UFE0013044_00001
AGREEMENT_INFO ACCOUNT UF PROJECT UFDC
FILES
FILE SIZE 25827 DFID F20110331_AAAVXR ORIGIN DEPOSITOR PATH jansen_e_Page_71.QC.jpg GLOBAL false PRESERVATION BIT MESSAGE_DIGEST ALGORITHM MD5
6113b22698b7b72fb8a51d9c7f293867
SHA-1
8cec427e00dd697a301889b3dc1c0870cdc1d985
989510 F20110331_AAAVSU jansen_e_Page_18.jp2
35c4e1e52e57ee44d1d8146cb2559f9f
acfe4e51b09e98109b7b12c3d13900e5f4a97351
48707 F20110331_AAAVNX jansen_e_Page_12.pro
1107b0e27cabfb0609c99f7ed2e57d17
4052432f50dec25f766afab7d4d772c60b93a316
25271604 F20110331_AAAVGB jansen_e_Page_27.tif
fd13e0a94f6c84a3ea75fbfa878b3cbd
05d103d523de257bd5cd935f5e374346593df8bb
1053954 F20110331_AAAVIZ jansen_e_Page_02.tif
ca1273eac1983d51916a30084ad27f3a
f5fba94e4c9369d4d4768b15f9f7dab8f7081af0
7412 F20110331_AAAVXS jansen_e_Page_62thm.jpg
e042b3e1d2a531d1bdea9b7616765e3a
97aede8b329b77dfe496a5adb6fd19ec930f32b5
1051923 F20110331_AAAVSV jansen_e_Page_19.jp2
3feb949682238b0667b2ad202fb1e46b
df45b7228214366cd5b00562a974ca76c69cef07
50340 F20110331_AAAVNY jansen_e_Page_15.pro
29b0fc02fb0cc02d55419d428224680c
f975d8ea982680c590e5554c5c289a20d3c7284c
30725 F20110331_AAAVGC jansen_e_Page_57.QC.jpg
42bb257fccfe5a314ff000b67d2f3331
c442f1f485e4fa9d9f89a8e49137a24dfed880cc
5724 F20110331_AAAVXT jansen_e_Page_59thm.jpg
5a114a7a1918440703d7c5c8fbb08fd6
72c42765522d5a18eca50433eaedc4ba13e1796c
1051976 F20110331_AAAVSW jansen_e_Page_21.jp2
5f763137e17beb11d83611230f3b3e35
39bd3af18e22c3e554575e512dd6e97eaeb78066
F20110331_AAAVLA jansen_e_Page_82.tif
f4e23c8559c64fb14a9fc55e5fdcae73
b440b70e72abe3484d02f2480b5df7f7ad7b5b7d
34334 F20110331_AAAVNZ jansen_e_Page_16.pro
a9bafebb5b77772db15cfbd7fbaa2ee7
69830d16ca6ce18c26fbcc48487ab6791866d92d
1051973 F20110331_AAAVGD jansen_e_Page_22.jp2
c36814a536d245021b9c7b1143a3aac7
1816cbf8090a07655fd181d5fe7e65860e3e5349
34082 F20110331_AAAVXU jansen_e_Page_82.QC.jpg
30ae2cf2df5630a2cf6ed9a0c04c3dea
4e52ad35ff791652ad1276dcda136e8cc2324072
1051943 F20110331_AAAVSX jansen_e_Page_23.jp2
608fa1a532c3a7591c143b863ebebbee
07f76a5375dc691468b73774c3da9339a1e996b6
F20110331_AAAVLB jansen_e_Page_83.tif
51c4b566fd4d6ae08811d2963def4386
b8d649dcd4a9d528df7a9161472f9e1a55c243b6
7794 F20110331_AAAVGE jansen_e_Page_82thm.jpg
088b5ac0bfa79a0d5916d7a35662fb87
b28a591accff56dd82548f87fe0dd70cb3f242da
31941 F20110331_AAAVXV jansen_e_Page_83.QC.jpg
8cb24ce439f47582d7fc37479750c31d
d85ed85e37ec32b7f0dcdb8b23533baff80d1812
1028224 F20110331_AAAVSY jansen_e_Page_24.jp2
384fb5367aa3a14396d673822c3509d3
db5a96e73b6c2d59ebf8b6a847513b8ff1111f25
F20110331_AAAVLC jansen_e_Page_84.tif
cc52ab2908287717b6559c81221cf008
8a08fc08b9eecd1ce861c875603226439218b762
F20110331_AAAVGF jansen_e_Page_65.tif
fcfa91672335eede1a54db61281064e6
d6f100026e2ae2efc327d5ce54587d8e9b807223
5465 F20110331_AAAVQA jansen_e_Page_03.jpg
bd61bf53460dd18dbe6aa1a85fdf4c26
8507122f1c8788f5361d84bc70eb3b003d370aca
4704 F20110331_AAAVXW jansen_e_Page_51thm.jpg
dbadb5025898438cb73f82e12bd5f728
af04cf08b11080c2debfc3a4224b7ff4c43c68dd
840241 F20110331_AAAVSZ jansen_e_Page_25.jp2
c00a987996124b0f846690604bb7404c
57fa4fa39a146f346ff31e2e68946052864e7a31
F20110331_AAAVLD jansen_e_Page_85.tif
c2d68c08e0f1a041896127d2f61d99a9
2c03e78664b366241dd4e2ab47b154626521a031
1095 F20110331_AAAVGG jansen_e_Page_02.pro
c232602e4633cb4f7413c42f11610428
056ff54a5ff7ffa1c8f0916164de972f4c0e21e5
21325 F20110331_AAAVXX jansen_e_Page_28.QC.jpg
bd60d2f8aff0fd3e0bfb094c67489186
ca4bbc411f760aac7e124957c5b51c038bbeee1d
F20110331_AAAVLE jansen_e_Page_86.tif
fe7d66e5363f8b549db075895ffe2310
fe34679f256fd103230d2596d40b6d88e5f1288d
22344 F20110331_AAAVGH jansen_e_Page_10.jp2
a3564523e1d66eb82aa7607388bf69e9
0ef79740bac3f2ac93f70d17cd54c2aeb39e9861
95565 F20110331_AAAVQB jansen_e_Page_05.jpg
34d99445616cd9675346817876677e2b
dbd61bce46f004d08db564068636e1b603197da3
5794 F20110331_AAAVXY jansen_e_Page_05thm.jpg
0e41c9514a03630d3aa749308f01e239
2a399f40a0dc6076c6cbb5296388745a679abe9e
7030 F20110331_AAAVVA jansen_e_Page_40thm.jpg
22c70dc43cd017fc6726b72639f505bd
d021363950aac76df40f9e94fe4bf604475fd31d
405 F20110331_AAAVLF jansen_e_Page_01.txt
bbf12a6251a831fc7c31f7422ffa8b2d
89db80a5f10cf914f1d768f614e3cbd64ec56ad6
108628 F20110331_AAAVGI jansen_e_Page_80.jp2
2bdd5a5404b860f804b3544e3d044c22
9a8a26c4893b2e12b4a777b2f074b5ab3991d2b1
114095 F20110331_AAAVQC jansen_e_Page_06.jpg
99c536ace909406a00bfbd376852c199
3c1da20962da23a001425feaac528d1233c84865
139337 F20110331_AAAVXZ UFE0013044_00001.xml FULL
bb32f918aab6b4008c4cf3c216d20049
527b3328e3a11d85de47b5f606ecb0b35b4cc335
25600 F20110331_AAAVVB jansen_e_Page_29.QC.jpg
b938fe291503185e5e6e93a046e00adb
1fcb9ac7c3933e361cf9d567cf6a76dee4446ac5
110 F20110331_AAAVLG jansen_e_Page_02.txt
ea92c847a82c942db31857f58d3b332f
95f2c0366e2866e11abf42e785a80293fac87bd3
99470 F20110331_AAAVGJ jansen_e_Page_60.jp2
b9ca915396e98e5587b152249b2096ff
d6fc6bb2492d21ad6d02fb275050d6a93817164e
44666 F20110331_AAAVQD jansen_e_Page_07.jpg
bbbb84ed21137866789d687b9946e74c
91d5c1a7e2570738be8dace4b783b7a6ac5329b0
12892 F20110331_AAAVVC jansen_e_Page_07.QC.jpg
a06c36b553ae615f6c9ab2c1e688bc59
89316c6c96b3df533a66bc539faab34ea97d25d1
96 F20110331_AAAVLH jansen_e_Page_03.txt
799555d88f272ecfc719c3ad3755ced5
430ca8db0dc23847fe3ab5850ecbed6ab620428f
4199 F20110331_AAAVGK jansen_e_Page_02.jpg
44e6e2f14659bf4da578174d7e2ee6ec
fdf982c1432185da6304b4ee6ee606a7b5431aae
45800 F20110331_AAAVQE jansen_e_Page_08.jpg
b89822844503ec49be88bc3dafdc0ce8
f4956ac73ef5cfc5a2b7ea56f5056a6fccb324c3
30905 F20110331_AAAVVD jansen_e_Page_66.QC.jpg
5436330f4dfb05b972fe127d8930ac00
3a7eedfdd8159892d0a2a85faa48085bdab67523
2321 F20110331_AAAVLI jansen_e_Page_05.txt
9f407205f6994ddafff37e0b9a4f114e
e41ffb0a278fcd1ece8f0da9705a8e4c48c9982c
98426 F20110331_AAAVGL jansen_e_Page_30.jpg
8e9c97a7edece83649161712ff2b375a
01252bcf1a1d27a6158d2ced851f4c574a15c6e4
76519 F20110331_AAAVQF jansen_e_Page_09.jpg
0341c2c3fea275e8df1ce750d035e6f1
282b1bedbe3aaf85071cc13006e0d4aeefa604a3
5067 F20110331_AAAVVE jansen_e_Page_46thm.jpg
4ef1ec329a798c02fc9657d2449c7963
5b2ac2d46f12f6ba41bfa6b8330b46ceb32c1de0
88499 F20110331_AAAVGM jansen_e_Page_31.jpg
e36cd008a4ad638601e5d8d4a47f0c9c
ad30205ed994480859f3dda3c560ee8f45d017e7
89698 F20110331_AAAVQG jansen_e_Page_11.jpg
1a979378e57e71fa8bf6b74c03788182
6d2b45b059f60b85e9dff6a3613d53b07a1c45ca
932 F20110331_AAAVLJ jansen_e_Page_07.txt
aa39723c23d7f899a6073d6cd2cc2397
9634a3c18401a585786ddffc860193c1edb2f202
6735 F20110331_AAAVVF jansen_e_Page_80thm.jpg
7ce6dbadb40e8a2018c2843f23ed2f1d
d50de7243328d5242855ff32bb283fe8a5016f26
50212 F20110331_AAAVGN jansen_e_Page_23.pro
7fa2163859ecb8b92c76a400b76d1530
5ba83ef582f40c556c602dc122277a59aaba9d5a
95276 F20110331_AAAVQH jansen_e_Page_13.jpg
fc1cb911a7c019a9f2240b1266430596
66c4f3923a2d2c2c963a604c816d00db18ce6ea8
1061 F20110331_AAAVLK jansen_e_Page_08.txt
5430c54c38c868e69cb28065fd060e0f
089364a4acdba6fcb6b8efcdcae01fdf43e3a934
49495 F20110331_AAAVGO jansen_e_Page_13.pro
61f7379ab0f974c0beb8b29584ddb5e5
349848e5b86b478cb6ab6cc4200ea91ff812a2cd
95388 F20110331_AAAVQI jansen_e_Page_15.jpg
6f3e8d8643c9840cc4647e94633733f1
eb0314d512adcc28c9c3be9c42d5128f22f08b12
1859 F20110331_AAAVLL jansen_e_Page_11.txt
03482f82dea198a693d2c646bea678e4
60f805a6480024fd0f4f93c46c6a399e588d878f
30806 F20110331_AAAVVG jansen_e_Page_58.QC.jpg
63ff299f8a303d2bbf674a3a0618a71e
a7e73d1326a5ecdc0229e86dd071a668f2b0d0ed
7456 F20110331_AAAVGP jansen_e_Page_81thm.jpg
0143dd8b84a906e1ada417fac6035121
ed258f5595c6bd1e3d4a8e2177336d25797c5c9f
67856 F20110331_AAAVQJ jansen_e_Page_16.jpg
90028d0e47a6c974bfa1122b315cbdaf
4d22f1a3157b627f45f297bed358e6536fb28481
1951 F20110331_AAAVLM jansen_e_Page_12.txt
bcdc13f3c1a10ddfea7bd8fb8d90f93c
b1879c31695573bbf40377ca60175d821d3d1e8e
7102 F20110331_AAAVVH jansen_e_Page_14thm.jpg
d6db1a54859311d6b3d9f4a568e2c566
34eaeeaf2436694d50c173c0adeb7beb20d91e71
1383 F20110331_AAAVGQ jansen_e_Page_51.txt
68a50d7d96c68f608393be6376abc765
9ec1a7b058d0427057b7970c756dbaa101108abc
89693 F20110331_AAAVQK jansen_e_Page_18.jpg
3df27f45cd6831181d52a35879879018
30b3142d5948f4fa117db9e35a14277f64234df6
2036 F20110331_AAAVLN jansen_e_Page_13.txt
7de225fde26778a1a23c2f78ee46b1b0
2a7a37cacf1bae02a8282a744679ba51fead758a
32463 F20110331_AAAVVI jansen_e_Page_56.QC.jpg
247eebf80c4343f0706fc74fcf1aa1ea
fb6c69d96da0cec9a4a28143513a54e0d71d3a63
5702 F20110331_AAAVGR jansen_e_Page_38thm.jpg
ca8a4d9a0333611b5442a6a0938e3933
13f4838fabcd724fef0334c3afa4aa467c8b580c
94164 F20110331_AAAVQL jansen_e_Page_19.jpg
afb3d845008e41ff2ca501b92ea80565
ad051972057b0d6a0da6271c21dc75f2796a3091
2027 F20110331_AAAVLO jansen_e_Page_15.txt
074a8e85bb88b005869c879dfbe9d39d
95896f34f6023ac17d146dbf1298c0f49c25acda
27495 F20110331_AAAVVJ jansen_e_Page_68.QC.jpg
7f5adbbc66a82e6b369172c7b44e4daa
270f9ddc32416e2054cf7e37161107402e65dc4d
F20110331_AAAVGS jansen_e_Page_24.tif
29c27f2f79150f7c4c927c7afd5ed551
3212ec08d88d829bf8b5e42a6f69dcab3ff718da
96890 F20110331_AAAVQM jansen_e_Page_20.jpg
16404de4c0b6ef83115b60b32392fa36
52721b1c36a1005cbc82670e43e5bdd53ab4b577
1713 F20110331_AAAVLP jansen_e_Page_16.txt
1b58ff7bcc25e42a9281b37dac4d6995
00da6bc4ec442f1278dc6745af4c18eb97f36069
28314 F20110331_AAAVVK jansen_e_Page_64.QC.jpg
2fafd9b4b670ef9472d279a6def48b8f
54a8c5c743c4bef9a54ec19c4d2726a693732215
46152 F20110331_AAAVGT jansen_e_Page_24.pro
b39ad6d2d4f25026548730dfd071c068
bfd917b9bcf284e42bc2b5bb899595ea8e38b7b1
100575 F20110331_AAAVQN jansen_e_Page_21.jpg
977ab33b38a0a4439eb64bb08a34ffa5
4e9fa5160e8e067aa1f90d98ef79ea7116359a07
1855 F20110331_AAAVLQ jansen_e_Page_17.txt
9e33ca6dbb5fcc1aba4ede9d76650575
6a4751645c125b20f49abafdf5347bd191327300
27148 F20110331_AAAVVL jansen_e_Page_05.QC.jpg
680b29bbb3e0dc13ed242a6b810c0eff
76afc1b8a855460cb47ba943669ac464838e0af1
49125 F20110331_AAAVGU jansen_e_Page_14.pro
0ef943559373b1943bfc22d666ab9a4f
9f560c3bc471c8ec574ecf19a31633eec6c17324
93751 F20110331_AAAVQO jansen_e_Page_24.jpg
786c0e1d5e065991e028efe861e31407
75ffd51250fe703eea2902c9092b113afe537dc4
1857 F20110331_AAAVLR jansen_e_Page_18.txt
1c9d867a62a98cb8ed188d74282b735f
eb23f6de1d094288040d3c12a529875ea3e68d4a
25865 F20110331_AAAVVM jansen_e_Page_85.QC.jpg
3822913ed6ca78240aa263cb554da1ff
90cf971f78dad2e362d41563fd214ba2e84112fc
787599 F20110331_AAAVGV jansen_e_Page_41.jp2
21a33c6845809c18bc22c23444f3f274
e22c10ac189d9935198c5363f50a492c69234860
88667 F20110331_AAAVQP jansen_e_Page_26.jpg
f0e6e77666c078ea7358db94b4ee66bf
64730f8ee39ceaf6320ad46caef9a541e2e3c1f3
1977 F20110331_AAAVLS jansen_e_Page_19.txt
5ff4b9ba02b11679c34cc4693198796d
1d109109e13e6af1faabea6611dafda7c3ecd724
7005 F20110331_AAAVVN jansen_e_Page_32thm.jpg
75563fe1a5effed0208b8a7abbafc30c
ba41d0060ee8152c88e575b33c045738d3022ee3
50665 F20110331_AAAVGW jansen_e_Page_21.pro
a4ca2856e8d37c0f2217d0e63143a988
fd5ada80a60a9d2c7dd41a0706ab324bd34736c3
82032 F20110331_AAAVQQ jansen_e_Page_29.jpg
a410e0fc3d9a629ae49dd28de758a64f
2d3291f812b39c7064a83d0e68d652c0aa33abfb
1961 F20110331_AAAVLT jansen_e_Page_20.txt
0cc01549de8657c1e44beaf3daa73907
1029e394620a31f3de8ca467c3ef7057e3d4711c
5537 F20110331_AAAVVO jansen_e_Page_09thm.jpg
5f9ba965ed816f5090dff797f42a2a13
04592593aee6bc3b947b94b1542a8756f39ed20c
97475 F20110331_AAAVQR jansen_e_Page_32.jpg
0e7630cf78c54ca9dddc2b50acf287b1
64221b29f2ded00248a5598c2c7271237741e1d5
2012 F20110331_AAAVLU jansen_e_Page_21.txt
f2de22841e773be0f450c9441f19310e
90c56bded3a797fa22b87326e3371ee4a73ea89a
7593 F20110331_AAAVVP jansen_e_Page_61thm.jpg
b931878fddcabbaccf70777cd428e1a3
7f9743bb92bf651295c37a356a14ae8812389efc
2116 F20110331_AAAVGX jansen_e_Page_34.txt
eea34f5711c9181b052a577b19811c1d
ea2dafc02c670d9e734ae88d09fbc215b13c86cb
93229 F20110331_AAAVQS jansen_e_Page_33.jpg
9fc7cd6c7e0e6bac23c6e939d32875c6
587f5276a7b76d904defb8ac5abd2ed1cd7d9d01
2043 F20110331_AAAVLV jansen_e_Page_22.txt
452304ccbf267b81f347cb0da83b555d
ef79bce87e969e8eeaa77be4a4e4418f886ed597
6585 F20110331_AAAVVQ jansen_e_Page_60thm.jpg
251c7558ba3e787119e8b48e249c13dc
d9cead93348da3386a8bdccdffabfefa752b19b6
F20110331_AAAVGY jansen_e_Page_75.tif
2be21d4b4f6224efc720aadc3f9a1a18
136953966a1aad95b1866d94a9179b28a6923a75
83033 F20110331_AAAVQT jansen_e_Page_35.jpg
5420190f4728bb300685afdabdccea25
e3201548eb3945feac670b837c7de03a18baf4ba
1817 F20110331_AAAVLW jansen_e_Page_26.txt
8a5c67ff3f359ae7e7612d6e8bfb8f05
1632caa290d79854185563734dd1a6254759ddb5
F20110331_AAAVEA jansen_e_Page_19.tif
4eef52c3222caf831d95ef01126d9372
cc807f1c29d2286d2c1ca2f0e421b6d1f635349f
31394 F20110331_AAAVVR jansen_e_Page_34.QC.jpg
f6d0b842aa155b76c284470d848ef042
2fde9b2be329a919de381224b4147a97b52546f1
80461 F20110331_AAAVGZ jansen_e_Page_25.jpg
46b71057241b706c74ca37fd6fb4bc5f
1d9607e0fbc2b645becc380668730d14cfb7f631
85090 F20110331_AAAVQU jansen_e_Page_36.jpg
55b2bbcf80fe5506c882a2011d7e1abc
524f9901a81cef271c4a9abfe30fb3dbde313e64
1323 F20110331_AAAVLX jansen_e_Page_28.txt
c700041e872f04573a82dd8eaba09a82
c99b390c8b1814d34209cf6ffa53f65df5ead652
29915 F20110331_AAAVEB jansen_e_Page_20.QC.jpg
db1b161aa9606e08b0d657cf60913086
9c85ff325ce62c0607f460b3742eac0468956609
30910 F20110331_AAAVVS jansen_e_Page_27.QC.jpg
2692845c888f324f1c08d6f28606d5e6
75172f806d7ca00977321f7925a9a8d1299393c7
74521 F20110331_AAAVQV jansen_e_Page_38.jpg
b3965fa1c59142c70664401437d3789f
f1b97d27e6cbba385ee4ba99f07633a8e84800b4
2037 F20110331_AAAVLY jansen_e_Page_30.txt
9f8b9a5cc0e37ab2239024c5f8a37b22
77bbbf40ebecba970fa6ce2d80228c7129ee4afb
66617 F20110331_AAAVEC jansen_e_Page_82.pro
9ca22e7a87d54040cca5dc67ada2800e
e3b0514cb67229c94083b4c8f06421fcc39506c6
15019 F20110331_AAAVVT jansen_e_Page_49.QC.jpg
a31ae30aea768c09d7d97418be2abddf
4f25658d820293c8167816097cde86fc529d09cd
88014 F20110331_AAAVQW jansen_e_Page_39.jpg
55ff339eef324952eaacbae763cff6c6
0aef6253fb749fb9c78b7e897f8c1aa231681acb
F20110331_AAAVJA jansen_e_Page_03.tif
8f6d6ec1161386b095546f677a2ffa88
16af4bbc1c031e4d98ba80bae279c6d6cb22946f
1845 F20110331_AAAVLZ jansen_e_Page_31.txt
4a1ffe92a7a885e31d6d53ccea77d82e
260adb0e55ba3e6a519a8b8a21a00815f95a813a
44127 F20110331_AAAVED jansen_e_Page_75.pro
51ed691cbbede6bee04b672c7fa69609
1a393411f2c6a21a4f4d989ed945d4630e0a2a59
22820 F20110331_AAAVVU jansen_e_Page_53.QC.jpg
6b323e22a6c93c9e89e45e17a1865420
00fcac00b8c80051fc3b3551d8d4e0ea86b2bb2e
94347 F20110331_AAAVQX jansen_e_Page_40.jpg
59a7d9d60b7df5678f37480fd726559f
b8686e93957bb67ba6d2ca81cbaff98282a22ab9
F20110331_AAAVJB jansen_e_Page_04.tif
4526d3de2659111c1f73becf726e7d80
206e62f3676ddcb8b4497ca37050f2c4fa8e3a88
F20110331_AAAVEE jansen_e_Page_78.tif
fc726ac06f98a29d64128a7d72a194e7
a0b8af72f6bebe8eff76b2fceb8a293a11b0607a
29796 F20110331_AAAVVV jansen_e_Page_40.QC.jpg
8c1d758afd7e71b9d0ddf569ad7cf67d
cd9b21d7abe21d6b0ea11a0b98fa8776ac29807b
72185 F20110331_AAAVQY jansen_e_Page_41.jpg
a9e06eb64dfc8c8f7f533e3e213a3419
116213c2f04a9c02559232a8a4d3e5863f931b43
F20110331_AAAVJC jansen_e_Page_05.tif
8939884b4d494e7faccf6a7cb1ebbe67
ab77bb5d81b0c0f7622f455676c07baffcd6b2c5
4107 F20110331_AAAVEF jansen_e_Page_79thm.jpg
4cc7dc75939b9036b8caf7b50a0ed7f3
410eec262c433e14745173cca6e75c99eceafaeb
6724 F20110331_AAAVVW jansen_e_Page_35thm.jpg
8acc7b44d924d80fa2ad5d9bd049282f
3bdf8bc1476d1abaf754744c07067a4348f41d12
44809 F20110331_AAAVOA jansen_e_Page_17.pro
62ab10df4e92ea8047286516cebca0c2
600d4a71ce49a01515b9ce7fe12c6394150cd160
91135 F20110331_AAAVQZ jansen_e_Page_42.jpg
cbcc9bd57577f287425593837e1ece6c
1f98d8749a7f886dfd8a3266198221fd62a64454
F20110331_AAAVJD jansen_e_Page_06.tif
3f342638ef29035bb595792ab7f53eff
c9b4b8af0218205f7b95e524b02a132a03ba58ec
1651 F20110331_AAAVEG jansen_e_Page_53.txt
e210ed0b83bef29d06a32899f2bfd467
397a2c5cd2cd798181b0f924dfdb966c6232e0e5
6826 F20110331_AAAVVX jansen_e_Page_42thm.jpg
921d2e509dc09227f6e49c517cd716e5
f253bc0e536ac3a382e93408164e21a9fd67c7b4
48654 F20110331_AAAVOB jansen_e_Page_19.pro
abc13ff7504765c774d9502ddfb1e1fe
d015cf8a0fd3b2871c75c6d6350737e738209552
F20110331_AAAVJE jansen_e_Page_07.tif
d36050cf6b9c847cb6d9a132d04843b8
2abfa195dc5bc06afe1b75722cf4f7303b78e32b
12324 F20110331_AAAVEH jansen_e_Page_04.QC.jpg
cecc2dd52de316e05d8ee0f616431fd0
3fcfe7ffa77b6d7ee7830d334b332dd4b6382299
2987 F20110331_AAAVVY jansen_e_Page_04thm.jpg
533ffe4893e1831802ffdcb51102b227
f9fe2bca38bd335946705e51b3691f16bf042533
968219 F20110331_AAAVTA jansen_e_Page_26.jp2
94a7c7bae3a71aaeb27b2d6b18607ab7
6247f849b2279d55d757d70fc995c05fabe5eb72
49272 F20110331_AAAVOC jansen_e_Page_20.pro
45e7002d330ddd487856682d3c4eacc4
4bd3efa053f2d72db21eac294c43610258ed1fdc
F20110331_AAAVJF jansen_e_Page_08.tif
4c39a8e19050b1f74c281c266396bc50
e64d91710bebede47d979753345116de2c569b83
F20110331_AAAVEI jansen_e_Page_37.tif
f26638bf4e5445d163678581b61e82ad
d813f87cbb93b0093978bc5e86d8ad3f10eb8d7a
32897 F20110331_AAAVVZ jansen_e_Page_61.QC.jpg
ac4cc4f0b70ae637d84213316ecc9f8d
a7f8a0e45426685131b47f493c4f3907c465e95a
736071 F20110331_AAAVTB jansen_e_Page_28.jp2
acd4b56d8dfb9bd6cb3b8387484c9cd0
a561b0fd1a9ecc81970ea544cbc55bd037e8b86c
50374 F20110331_AAAVOD jansen_e_Page_22.pro
bfeafe35bc45938f0c7f3e4771fefcda
be1c153751721651c12961da99432255d7cb650c
F20110331_AAAVJG jansen_e_Page_11.tif
00de7c93075fbeff87d6b6bbb5f15567
b7b3cc7b99f09e41bfe373b16ac2ba35c23c6ad3
2001 F20110331_AAAVEJ jansen_e_Page_32.txt
caee722f3d2ab51ea3998a95bdd63ccd
ad8507def7fc3da68fe5e5c23e95f4fc49abe22d
90986 F20110331_AAAVTC jansen_e_Page_29.jp2
202346568d6036438ce98eafcbe1c8ba
b63e96cada247882964e9c7b4f3d5141a12c95dd
38262 F20110331_AAAVOE jansen_e_Page_25.pro
09e759eb419d330e1dee0d69a43d61ad
3681a518225ec659c8e421eb528373a9ee3f738f
F20110331_AAAVJH jansen_e_Page_14.tif
7848733ab955711b1449c48f7ca211cf
7d4ae28d9cd7a4e92d1898c23566713e0a2c643e
19497 F20110331_AAAVEK jansen_e_Page_51.QC.jpg
3d4552a5bc8ef831676da2c4ea19ada1
efd7d8d0e6d3ec9321edd45364dd9f13bed5f1ca
2059 F20110331_AAAVYA jansen_e_Page_03.QC.jpg
9d2848aab1861b28de097c9d7f136166
7e54f00abfe31eda0353c7efa677655221e8a328
106290 F20110331_AAAVTD jansen_e_Page_30.jp2
6b68a8e0ea0f541e8a159ed2a97171a3
48fdc1d226a384834c505c12620c2eb44690c9a6
F20110331_AAAVJI jansen_e_Page_15.tif
7f195c0c895a195f0514f0dea9b78541
7d58fce34c491992e6b19da4eca1f232b1db6cc1
5978 F20110331_AAAVEL jansen_e_Page_45thm.jpg
f32a460bb6588acde7c6d51d205ddcd2
9c64f80e739af0852267d14d4a8504dd5519d2b3
50143 F20110331_AAAVOF jansen_e_Page_27.pro
ce3286ad654f072a475f7a08b693cdcf
cee2e707445765cfd3555b892e253ded7b044e0b
14328 F20110331_AAAVYB jansen_e_Page_08.QC.jpg
b1e980f6a0045df04321c18b071c479f
a98dd2f950ac088ef4a21cb88bd2a01da2783ee0
F20110331_AAAVJJ jansen_e_Page_20.tif
80686117d7c261a70c71ddd026472548
3cd0e7977949aeea8ad40eff0a072e00a798ecf0
30648 F20110331_AAAVEM jansen_e_Page_21.QC.jpg
6f6b6a7fd2b15cfd7975eb0e5ae042f5
5b878c0005002807a32d934d4d5cf1742cad0107
32629 F20110331_AAAVOG jansen_e_Page_28.pro
2a558840fd187b50d09c9499834668a2
838534976686c474432a4ff15504d421c21db83f
6467 F20110331_AAAVYC jansen_e_Page_10.QC.jpg
959690a69a2642bc3b94c338bdd8ea17
aca7beb9372439336ac6e858488c361b0b87a8fb
105997 F20110331_AAAVTE jansen_e_Page_32.jp2
5f431f410a32521ffcedec8506d91554
84c02cdce345e9ff09d05d59c87a4b855b996088
F20110331_AAAVJK jansen_e_Page_21.tif
f9bfdd8a2402a317ac3931359df794b8
0003cb39131bb279333c527870e57ffbac4b5cee
30669 F20110331_AAAVEN jansen_e_Page_65.QC.jpg
8db8239962d507945f4be9f448c27867
b129b14a0fce7fbac5977095acd9f9819550fdb7
42234 F20110331_AAAVOH jansen_e_Page_29.pro
cd67f3e507c521b026f189350348e146
83e2325ba7a2e4aaad70ec3a9224b108d1ec0ce1
28001 F20110331_AAAVYD jansen_e_Page_18.QC.jpg
cb0c05d33636b8f4b175174bd84f5d32
7106393ad08b8fe357ac149a5772f93347e6c71a
111166 F20110331_AAAVTF jansen_e_Page_34.jp2
f952bcacb9fc7f92984af6e3a69c2a58
c43cf4f5d70dcf91e8ff7f0feb40ad772ff29687
F20110331_AAAVJL jansen_e_Page_22.tif
c2e9c2f810af5cb6aecbba6bd43a5b41
b6c0292bdf95003b9281619544e02842d0165f61
52481 F20110331_AAAVEO jansen_e_Page_80.pro
223d66819f549377840539737636b48f
ace4391c8eb8dc3de26bbb2a984f2cb46e3a38b8
50078 F20110331_AAAVOI jansen_e_Page_30.pro
f0ef29c3cd23e529577c28404d60b284
b64eef1d3029ee0d4df5bae6309f8d6c3b07c2a4
29428 F20110331_AAAVYE jansen_e_Page_19.QC.jpg
d2f31ea6419a975fbf1e4c21c98e650e
bfc213ec591b06203d253bc0540fc78af4ebbf2b
883540 F20110331_AAAVTG jansen_e_Page_35.jp2
7028d675ef9094a3b7cf0769357056b5
e477112436b556f0084401ad1183e8582c8ee012
F20110331_AAAVJM jansen_e_Page_23.tif
c8f00011ad2871aafc635491a296a289
3a4acf861e16bced6171a4cb5e5a53eb1ea01d6b
52891 F20110331_AAAVEP jansen_e_Page_37.pro
4bd88ee057f19764dfe7cfaf513024d3
7e5917648e288839dd3a681509bd54030844362b
45676 F20110331_AAAVOJ jansen_e_Page_31.pro
c6cdcfc242b8579d5742602cab7da2b8
04f7ef582bb6c4dedc68092cf06bc24b37675770
31402 F20110331_AAAVYF jansen_e_Page_22.QC.jpg
53014e1a509fe0465788135eeefc1e69
accf380a65ca58d5ff2a39c3aba37fcb96599309
94041 F20110331_AAAVTH jansen_e_Page_36.jp2
468d2c33562d157be7dd030999b401ff
49cee1aebe3474dedfeed2fdd877c735fdae76a4
F20110331_AAAVJN jansen_e_Page_26.tif
6b0e3d51c45c7fd0ff482bb522c9f8c2
8385d10de07a8a4f61c86c3d3ae3c197cfb5a68f
605580 F20110331_AAAVEQ jansen_e_Page_46.jp2
e2e87ddb23978eb5857e3bd8c53f2019
de08cdaa61d818664210917eac44677d72cdc5a0
49692 F20110331_AAAVOK jansen_e_Page_32.pro
051f7aacebbf4dea43ee5eb7bc62c0df
6f30a6cf5ba237d5a704372e53738ef9fddedd88
28837 F20110331_AAAVYG jansen_e_Page_24.QC.jpg
f23d4157a0f9fccfc3ae7981b6219d32
9c44db73b9dcf4022c4c3db6ea8a2b1792354f37
111487 F20110331_AAAVTI jansen_e_Page_37.jp2
c30ddac0cf61156afe66c829bdd7a09e
243701e61595aade38e9fb54b1c8cf83cc114ae3
F20110331_AAAVJO jansen_e_Page_28.tif
edd096486e28fd075d6f2b05494a45d9
791328ba7bf1289ab06aab39ae17a42fce7d41f8
1051924 F20110331_AAAVER jansen_e_Page_12.jp2
8bc3535d76e99dd55a6a101bb73829de
7c465220c2110ae3ea44a6715daf14f9cbdd883e
53609 F20110331_AAAVOL jansen_e_Page_34.pro
b968f7128af2589273015fd975fa2949
6789d736c1aa9bcdbc476edb35f879ab8acdf2b5
25307 F20110331_AAAVYH jansen_e_Page_25.QC.jpg
9d22f04b71493bf3c484ee0a873f558a
0cf8f5c68e1ce10acf07ec3aaeef0408f4f530a4
82722 F20110331_AAAVTJ jansen_e_Page_38.jp2
ac6bf49339c1c55c15e794134bcb938d
0244198f02f91949b6bf4795bc2d5c079e220f2c
F20110331_AAAVJP jansen_e_Page_29.tif
c335508b14c5691dd2bd190d0f3eb839
bb1c7a33ef6546ef5128ae792b5fe131699a181c
18837 F20110331_AAAVES jansen_e_Page_10.jpg
cb6c49fe167e42813a126cabf71dac90
2733d26840d54451a6ca0a895bdfeb9dd287d8a0
40254 F20110331_AAAVOM jansen_e_Page_35.pro
8dcabbd085f157250d621682a9abfce2
0507175c79aae62bf1258fd26531d49f6fb7c42d
27348 F20110331_AAAVYI jansen_e_Page_26.QC.jpg
920311a795390729582cd3ca027ff5f8
22350506a99de63f1bd47bf0b022d28a4a7b363c
97612 F20110331_AAAVTK jansen_e_Page_39.jp2
3032121b2b359d1b2cda0d91a02ff6f6
ee556cc51817116fdaaffff893f920c17f4316a9
F20110331_AAAVJQ jansen_e_Page_30.tif
1465b5cef51ba400533dcb8216d60a4c
54ded035a8c5a2995c4907788dfa2b070d2f0c57
44037 F20110331_AAAVET jansen_e_Page_18.pro
fa7fd7fd2bbb1c031997cf64fc7e14e9
3015846da27be47e17e32bd2a58c8435720ccc05
44715 F20110331_AAAVON jansen_e_Page_36.pro
bd9b7142dfa17e4df19140430047d5c3
0021c4bf0237b31a23ca704978d911ccceb5b355
1051940 F20110331_AAAVTL jansen_e_Page_43.jp2
137ef1358d49f1a8303b1f46712d9868
6527e7ac311ec9886b83b0784af47a846435fd0a
F20110331_AAAVJR jansen_e_Page_31.tif
732b92d377a05a905bfe10264497b04f
3ff5c6edc443ca10b189f65681072302d83d37f9
1703 F20110331_AAAVEU jansen_e_Page_72.txt
e125b74956193f6ccfbadfc92b54a89e
3119934c93c2fd6091ae87a7e7024b4532474408
38300 F20110331_AAAVOO jansen_e_Page_38.pro
6e48dd507c6db993c3156e4bb2ccb62b
07b83564bf1bb9a7674ffc33ba72e92504f55a75
27623 F20110331_AAAVYJ jansen_e_Page_31.QC.jpg
3faead90baca739b32a97fd89d2ee488
306c1564abd4cf3db9a8af7d9d63151bc5ce461f
782923 F20110331_AAAVTM jansen_e_Page_44.jp2
d9faeaf85dd8bdf89d79b946969a4cf3
43766580b7cfd11361a2f8745db85148cf49cfcd
F20110331_AAAVJS jansen_e_Page_32.tif
1dc7031d16db87cc8fe5e1a2ddc8abfa
59c529a5a45b61d171ca1a68bba64d8138dd68ad
45879 F20110331_AAAVOP jansen_e_Page_39.pro
7ef8fcdaf87e49d981daa786c94062e6
75c34be7e3a2d4c7599364f74622646b85ad6fff
29658 F20110331_AAAVYK jansen_e_Page_32.QC.jpg
65499e120c8a27d6af2bcc0cdabcb3d8
dd9eb7b8f84d2e2ddb20914a1ef0eac104811012
794686 F20110331_AAAVTN jansen_e_Page_45.jp2
a4053a6b40fdde28666170eb2afcd92d
d4b429e2593a3717da6673549928fa80a7afcbf0
F20110331_AAAVJT jansen_e_Page_33.tif
a8d0eeeca814a300e3e0c670d4f63eb8
0e932da7c22f2cfc2b779766e28bead629291cba
81807 F20110331_AAAVEV jansen_e_Page_54.jp2
ece9f6f446caca0194f08ea5f277b164
6cd85ed4271d5199c14664e8ee4a03931c728a0a
48607 F20110331_AAAVOQ jansen_e_Page_40.pro
97fc9ca207a37494767bc70675b2a1ab
f6c9e0b1ce42ccb728a77f8fbdcf4e102e25850a
29091 F20110331_AAAVYL jansen_e_Page_33.QC.jpg
b37de6ca626645546645ee0d2526b39d
22d963c975735fbd49c2573919a6272885df415d
1051955 F20110331_AAAVTO jansen_e_Page_47.jp2
4fd59ca91ed2a4de99cf5c619674dd2f
ff38a19d6e662da76be0629148caeb5d03ab7d11
F20110331_AAAVJU jansen_e_Page_34.tif
e8f745b1df82efec60c18bab049db5d2
2ea94f0397d7f40ce8973c0af484f43d773ad893
F20110331_AAAVEW jansen_e_Page_17.tif
d29298e93dcef9a97a90b0b54e44f829
d8df945b4cca3db34e71e9730d9b4a220486695a
45506 F20110331_AAAVOR jansen_e_Page_42.pro
3b4749df60b0f8edf6d046e6ed6675b4
3414de6d93040f36daeb75f761645ea6c6b4dc68
22800 F20110331_AAAVYM jansen_e_Page_41.QC.jpg
f087210eec88609ce436a9b94e57c04d
c2c47591a4830e8be211647b1cc8642c8f30c4a7
820036 F20110331_AAAVTP jansen_e_Page_48.jp2
41f049685119a497048a7f6a37aafd86
a4f41b5f89ca358e1cbe455ead76d341773352d8
F20110331_AAAVJV jansen_e_Page_35.tif
c48d7d615fb2c0e8e23424dc99d36962
0be7366bd44d38f0d325e5a25fb70f09c68d1c0f
40188 F20110331_AAAVEX jansen_e_Page_65.pro
72c9e2775ed20de8b6644c28ce5849b5
573dfd9631cb3a5161e94965942ea1131309ede8
50344 F20110331_AAAVOS jansen_e_Page_43.pro
ba49eeefcfdbfaa18111f243d029f61f
76cdddb34f9f8f12c3b2303794848ffab2afeb6f
22410 F20110331_AAAVYN jansen_e_Page_44.QC.jpg
377a998daf8bf68928250b5b651dece0
95c9d35226d59e351e0a79cb52f8808a8b287e8c
73378 F20110331_AAAVTQ jansen_e_Page_50.jp2
9158c7e8ddce630ca9a2d2050e70aea7
b5cb5a1b41fcc9bf819b50fb00be56fee8d0513b
F20110331_AAAVJW jansen_e_Page_36.tif
784f978bf108b699252ed1cc8d6afbac
87339f9c96a1efe17068e5da7cdd93fc66a39418
1885 F20110331_AAAVEY jansen_e_Page_85.txt
9b6d36e893e27ddb9177deea4f36ce4c
4d9bf5ed9f0b7fab9d801d5a1ade4ea5c0e93f93
32462 F20110331_AAAVOT jansen_e_Page_45.pro
7510bd1f94a244ba71a2dd3158a90e10
f822d0f0a6702e22029e59388ebbcda170bb4bd4
31279 F20110331_AAAVYO jansen_e_Page_47.QC.jpg
ad39b7d5dba8e2d13188c90ff7c60d74
0449c689e8dd398cef6c957fb326e742ac3776fc
67152 F20110331_AAAVTR jansen_e_Page_51.jp2
4254b67fabf334b1b4ad7b86733f2d05
904280446bc913acd25677fda69e65fb647e01d5
F20110331_AAAVJX jansen_e_Page_38.tif
9d4234bfb6a861bdb431d8520f716cd2
ed3aa79657eed1ece505337f61e1c7b977c7f5e4
27564 F20110331_AAAVEZ jansen_e_Page_36.QC.jpg
22c471bdf10d8037b6f415fe599b7c0b
1466fe7ec0ab7abf83baed2938d861df18f1b77c
26192 F20110331_AAAVOU jansen_e_Page_46.pro
44da21f122a52260e2aafb4c19710e3e
4c559bf8d28ab3de5fcf29d1551630ab59f55c1f
20776 F20110331_AAAVYP jansen_e_Page_50.QC.jpg
c7473be4a6f964eb4cd4d6ed9a7a7a2d
a99214f6d3d2330a99450d68f37415f3b5f50e14
873435 F20110331_AAAVTS jansen_e_Page_52.jp2
abd79abc042f40137b31f6d1ae00c957
d3c8025acc65148dc729319501ce729e312d01c7
F20110331_AAAVJY jansen_e_Page_39.tif
9fa80ef5ff6fd62522773dc3ae292342
b4eb29fb36059b301cf42e244758a00f360327de
49636 F20110331_AAAVOV jansen_e_Page_47.pro
18a8b64939b9681d684497b98f8b7812
94060ef1c4cc1c00578335d395575ed3debc8157
29961 F20110331_AAAVYQ jansen_e_Page_55.QC.jpg
6393c61bc70ac40c834519bec05d2a29
ee3d6aebd00917692f2dcd6c654a070b8b8ad211
86446 F20110331_AAAVTT jansen_e_Page_53.jp2
4ee87de162b629f6d9939aeafbf22967
d772dc0afd43a661ef013a9bb1be0057d72be3b5
F20110331_AAAVJZ jansen_e_Page_40.tif
8d9e842262455f046f9f09fae67435ad
19fa4d67f27086c5ab5d8bd0a65ba4aa2d71ea83
38934 F20110331_AAAVOW jansen_e_Page_48.pro
35e6408ad4d847234f0038e66e3743a1
98ceb643778aa5e905e887c4cf686700a8c9e67c
6990 F20110331_AAAVHA jansen_e_Page_24thm.jpg
e73ccdee172e051cf3e332c4f0dd048e
af2ea074c66277ec5d43f8c5d2ca04a9ec939fd2
28740 F20110331_AAAVYR jansen_e_Page_60.QC.jpg
f36b81008d9318ebb2c1d66d77270d16
bdd84c752b28e3b32c690d284cca072b1b1357b8
114260 F20110331_AAAVTU jansen_e_Page_56.jp2
4710541f13e587cb311a44bd70775937
bf2769406e7c8f5e13c0cea08eda95bc2ce782ed
21449 F20110331_AAAVOX jansen_e_Page_49.pro
21e4a5ae33217bb1dd224de58069eb4c
d22d99aa4f9631acad50723c61d6772b26eb7774
6817 F20110331_AAAVHB jansen_e_Page_64thm.jpg
cf50c4f8f93fd84099aa6be4f545a24a
a51f880174c9fea82ee08a3d143000280ae21d16
33024 F20110331_AAAVYS jansen_e_Page_63.QC.jpg
bf5296dce9d241ff990502f800c0009d
5f523e7e7a40e2135fafd699be6070ed9e789f51
107224 F20110331_AAAVTV jansen_e_Page_57.jp2
15f02d92ce941cd9b5fd5923c48e3def
285c226a3acfaa981c6be6c7ddec177d301822a4
33568 F20110331_AAAVOY jansen_e_Page_50.pro
8450983699d5a263dde2725c346330ec
9310929b3c5ac8918afa36dc9b502c4b3f6772da
F20110331_AAAVHC jansen_e_Page_44.tif
d5ae7ec60512bba9766b5b299df9c2d4
473717babe66c588658d987f3985762db6f7fec6
32980 F20110331_AAAVYT jansen_e_Page_69.QC.jpg
180691d05631439bc7c8a2348f4bb222
3209e309e99f36d68adbb0cc492787f34270c54b
1051972 F20110331_AAAVTW jansen_e_Page_58.jp2
f1af37a0aaeb8aac814cad49f33b6aed
edaabf9f98f2fd781c4b23e367fc9f60e73b800b
1908 F20110331_AAAVMA jansen_e_Page_33.txt
566310ca84ce1841253e693463e98980
81370f598bc9d3503187dccb568bded652b4cfe5
31151 F20110331_AAAVOZ jansen_e_Page_51.pro
4557ca5bff6c4f2dbe0364c1820b03b1
5344fc8160097c74c094153fe2d8908a4123da16
2021 F20110331_AAAVHD jansen_e_Page_43.txt
8f0abb772edc5140302118f2e9569203
f61c593a4d995771246a0c0fd03beb22678f838e
23378 F20110331_AAAVYU jansen_e_Page_74.QC.jpg
96efa4c0edb2f2a7b2d14de02a7766a6
45613b1f4e432a4b0a4ae2866c88d00458d9c753
863476 F20110331_AAAVTX jansen_e_Page_59.jp2
257d245e37d89c9f198e41cb07a1067b
dc43c7b9faf6690951d493b712dd0ba14de18343
1842 F20110331_AAAVMB jansen_e_Page_35.txt
9fd1d1ad468d500aa4e7ff93ebe04adc
ca58ba5297b4dc92f3399c996ff313779dac3dfa
22925 F20110331_AAAVHE jansen_e_Page_08.pro
f282422dd868773cfe39ef046b8b4ca8
516d6d80dfc7838908b72ef81bcd0f46530571fa
27290 F20110331_AAAVYV jansen_e_Page_75.QC.jpg
86fe637dc9cc71f7882dc8e935858d08
e5417aaae72e2c09eaa49c1ada8893749352eab8
114628 F20110331_AAAVTY jansen_e_Page_61.jp2
63a438bbfe46b0a766fd63d75203dd5f
9fa63ba01ba5820e165470354323af74bff28d7c
73892 F20110331_AAAVRA jansen_e_Page_45.jpg
dc6a4ecf76036dc28667dac91152c8f6
efdb485650e1e81d627e1d00393e0b6491769212
1998 F20110331_AAAVMC jansen_e_Page_36.txt
f5f1ef0a790938936395954b6f2cbc7c
96bb91f43c9c485d1f57fbd0c34fbe2ad596cace
1051986 F20110331_AAAVHF jansen_e_Page_20.jp2
bd5fefa76cf846d339fbfafbc6f77bf6
991c1b14627bc6602e581e2be4fafe1ba66d7ddb
26110 F20110331_AAAVYW jansen_e_Page_76.QC.jpg
58ed02f8b5c5f0e67f02d1c64c423da0
3769d60407560209b5aebc408ef4b298f424791e
116605 F20110331_AAAVTZ jansen_e_Page_62.jp2
fe463ee35ec74e14357d6571e222474c
43209dc49193d7febeee9a6e9ac8043c4b86ecfe
57618 F20110331_AAAVRB jansen_e_Page_46.jpg
627f456c90f81c25124073149067fdb5
188b2d5a58ceafbbc476c3602f1a974a6388cfe0
1540 F20110331_AAAVMD jansen_e_Page_38.txt
9351e64cdd287dd4b14ef4c0b8a0d548
2c5d9fa9490e7a700545c5ae447132c89ae982ee
F20110331_AAAVHG jansen_e_Page_49.tif
26c9247d2fd4377ad95b14f7446e5bcd
ece707b9af5e28a33f16bbdbb1750fd4a25de35a
13108 F20110331_AAAVYX jansen_e_Page_79.QC.jpg
4607fef2052d8bce642dc1b9a21f8ed3
06c7fa6688b6ff636f86ec3333ce6dfd81c1e995
1879 F20110331_AAAVME jansen_e_Page_39.txt
d7147465cd00a4bef7a8c66b8cc75438
77cb9254e5772ba1246ba801579729b84017b7e4
F20110331_AAAVHH jansen_e_Page_09.tif
8d018ea14b116f1ea7312f30f4ffdca5
a4780b5314ccad5a271b02eb32b3d88adb18004c
1974 F20110331_AAAVYY jansen_e_Page_01thm.jpg
a5b3633fcac183564bc39515f28162c8
c097b41c05b56dd578346c3ff716a7aa7bb663e5
6209 F20110331_AAAVWA jansen_e_Page_71thm.jpg
0be2f2d7026838129d54116ca1f958d0
6a29b01fc3b89a88abe4c6ae775e5b8c23a503ec
F20110331_AAAVCL jansen_e_Page_10.tif
f9786b9ddc9ecb6bca16859fe55561fe
ef45c592d90d3ca98a10b8b19036f0193e570509
1978 F20110331_AAAVMF jansen_e_Page_40.txt
2c560a1c799ba61f1bd9449c71ee49fe
049234b0cc22fc00a1650d650ffb40b780b07c56
F20110331_AAAVHI jansen_e_Page_25.txt
64cb41dded08ae379679cff2af258996
4eb71f51f7ddb40e6219147596cdf63289aae895
99617 F20110331_AAAVRC jansen_e_Page_47.jpg
0ff5b7f0d877110e38c4db030d647b2f
db8d371de76108b233945614e3e2066db489363b
F20110331_AAAVYZ jansen_e_Page_16thm.jpg
0a80b3a69616a9aa1d2ccf2d278af39d
05ea867659a49a3785a99adfb53b7decc998e530
7692 F20110331_AAAVWB jansen_e_Page_83thm.jpg
2a397b3d9d7cc1340c334bdbb5e1fbc0
dde32763109f4beb47558e89feeab7cbdf96a4d5
104331 F20110331_AAAVCM jansen_e_Page_40.jp2
22c496ba83f53da73de0053cb744ba4e
9fa42d8a9fcb31f959e7e3635e349076ad854e91
1646 F20110331_AAAVMG jansen_e_Page_41.txt
931c835cdb082310499455734a9abfba
940f4644354e7066db401c924cfab7ac18e7c506
54162 F20110331_AAAVHJ jansen_e_Page_69.pro
9e7a1bbdd518e6741e7a4c830f623acc
a2d21acefabb77d6a3268ba4bbc1500ebf7f4690
76672 F20110331_AAAVRD jansen_e_Page_48.jpg
9e503a52098f5d78f08974031bce2df5
0cfb3f2df93ec5d475ed2ec543130f543ddeebdd
27024 F20110331_AAAVWC jansen_e_Page_17.QC.jpg
bc8171278b7cbd7f4657b63874fc65b7
6aaa8d0ee0bb28ae7620c1ee6e55d7faa3f181f7
2025 F20110331_AAAVCN jansen_e_Page_68.txt
a368baa8aa582245aaf174670f319ca2
44c1a85adf252ce8ec3b991e5b407bc313cae992
1922 F20110331_AAAVMH jansen_e_Page_42.txt
0adbc627a117f8bc8e8f86a0e0221769
be0a9e40ffdf1e7105b6b2d809897bed3a95a8e7
32387 F20110331_AAAVHK jansen_e_Page_81.QC.jpg
3cac441821f77efe10d80bf9e4920b0f
0154a1ed0bc213d624245e41bae792d7e805855a
66039 F20110331_AAAVRE jansen_e_Page_50.jpg
8dc9701ff8d10bd3abb95d2202c4cdc4
0d1a47749a185a0611a04333c03741f62dc7ae4b
7496 F20110331_AAAVWD jansen_e_Page_22thm.jpg
2ddfda188d5ccedb1f7a66acfddc827e
98f3d81b828350d164fe932ff8411ce33a59f87e
2090 F20110331_AAAVCO jansen_e_Page_37.txt
74b098b9238009d77f4e02b8b52afab9
c5dc5f18a18ca347f8e49fe2103c57b29c06446c
1330 F20110331_AAAVMI jansen_e_Page_44.txt
7a8ff8ba8f092e829811836f2f996792
f93b0c3906f16f695f196592b244998fb13595d0
31980 F20110331_AAAVHL jansen_e_Page_44.pro
739126a62b1c98d0808ab2c7e54ff7bb
30bf19c80753c342cbab755656974ddd87686008
61378 F20110331_AAAVRF jansen_e_Page_51.jpg
fc49b7bce1e194252097fad2884c765c
7d7b950fe07625c6c22accc8ff91c6ae73f48ca6
6566 F20110331_AAAVWE jansen_e_Page_06thm.jpg
e3e3ce0c139dacef85e631b1d0811c6e
64bf83426486afeb91bdfe35a0e5ecad860be6ab
7132 F20110331_AAAVCP jansen_e_Page_13thm.jpg
1b9e0f8fe47e97683a42dcc2c74d575f
cac4f39acbc950d5c6d5d9aa14d7b1bbcaca7ae2
1311 F20110331_AAAVMJ jansen_e_Page_46.txt
a0935bd5bbca28645f677b190cfa4849
ba2b3140b409498808689129bb1ac00460da0f7c
48257 F20110331_AAAVHM jansen_e_Page_49.jpg
5b4b9ad0d2d2f5b84533e0cd3e84d7f5
627ed2865d6897e384d4f74181ab40bb8c2bb453
78325 F20110331_AAAVRG jansen_e_Page_52.jpg
4d9392b99374a48212f9d15eafce818c
571d94d6cabae628bc96f27648ea6b2b234f192d
3469 F20110331_AAAVWF jansen_e_Page_08thm.jpg
dd087ce0e3b6841dafd27ef796a5aceb
6016966e6f39f7b043996a688e5570b0ef06f096
88809 F20110331_AAAVCQ jansen_e_Page_68.jpg
7a5845bc1b9d46ea72161c0fee115fdc
9ebb6a35f6bb5188861b743855dc1378d8ba818e
2005 F20110331_AAAVMK jansen_e_Page_47.txt
5e3b8abec4a3bc470d0ff46f52bab5c5
060280d8318ac8915bb30b7e4f408ecd9bb9a1dc
3665 F20110331_AAAVHN jansen_e_Page_49thm.jpg
c4fb73cbd767f741366cbd06920311d3
66499789acedc29d3c0e6f99a5738bc3311118ab
73200 F20110331_AAAVRH jansen_e_Page_53.jpg
380d1c195213c2381969c595b1579948
2771555fcae16284e550014a7cfcaf60c0aba6c7
32194 F20110331_AAAVWG jansen_e_Page_23.QC.jpg
febf8ac5e5fefa032fdd636ba84375df
50c15129897edaa1e573f76fb710b3c34ae4a0ed
1805 F20110331_AAAVCR jansen_e_Page_48.txt
410b504d79b754d532071f3b9dee71b0
ddeb0ea5e44c8744084034aa3f0f75faa64092f1
866 F20110331_AAAVML jansen_e_Page_49.txt
200cd1ca5fe9f6d42edca28cc87ae606
d82ee613bb343df4e112b97aa6199dafcdb7422d
F20110331_AAAVHO jansen_e_Page_80.tif
5ec196bee8bab54c6c9f46c82b9bab07
4c0cbe47a769407b4a9d58a4a4d629cabe5ea9e6
72695 F20110331_AAAVRI jansen_e_Page_54.jpg
df471528630736679d5f9c683682c3bf
6ee3ec175aadbff53a94bb47b9cd6ebbc7b42b29
26063 F20110331_AAAVCS jansen_e_Page_67.QC.jpg
fa9bc9b0bbd1574a3a9c88d709334fdd
9c02a596eb255743f6185f7092e269d7aaf183b8
1423 F20110331_AAAVMM jansen_e_Page_50.txt
da8f7af1dc1bd4f06bc0295d863d3536
d952cbfdc118a46d29729854beb160695caca4d9
97876 F20110331_AAAVHP jansen_e_Page_43.jpg
d3b4b7b91eba1dad21d0797bc5766116
473c1a9f1a42b3c1b54c9aa4fe37bccb1db9429f
98182 F20110331_AAAVRJ jansen_e_Page_55.jpg
c3fee2c7b465e1e18c600c58066950e6
82b3d453c892b0eaab424e305b6563bde10950db
7388 F20110331_AAAVWH jansen_e_Page_27thm.jpg
a09ff7b8f69b1576388d33d7c2080623
b380219172126b9141ccc5d3bb393be1e9f6bfb5
1719 F20110331_AAAVMN jansen_e_Page_52.txt
91ed1c8013a07234dcd0b2f0abab401d
215bc181038811bf79128c5c01a02ee57b0cab2b
72823 F20110331_AAAVHQ jansen_e_Page_74.jpg
a78eb600c554fa94acc7ade5219f6d67
7402f13f2937b8b3b361c5ec5af92e117d2fb071
102942 F20110331_AAAVRK jansen_e_Page_56.jpg
26390dd19da96a8d213a6cdc02677017
142eb3678ea768eba8da0919bbe22dbb738819ff
30768 F20110331_AAAVWI jansen_e_Page_43.QC.jpg
3317eefbc3548868b43f4e6b131048e6
1c3e7c74ac7ecf380985709bc1243293ae1527cf
43428 F20110331_AAAVCT jansen_e_Page_26.pro
7517835ed0225aa9260c24f88fd29d85
4b1a858585d91706dcfe6e210936b7bd8be92183
1976 F20110331_AAAVMO jansen_e_Page_55.txt
d67b88d64216cdae1fc72e322e222ce9
fe5c3191d0d8e7d3062ae2613c5790927d3707ca
100147 F20110331_AAAVHR jansen_e_Page_34.jpg
65ca2d5928ead0da8d2aa74ed4e4d012
9a47eea15d8e1f4a43ea6541b2ff6d643b30a893
97988 F20110331_AAAVRL jansen_e_Page_57.jpg
ca7237fe8559cc7d7dd72e2ccd10ea38
6ec74d568d7578ccf3054a520cbb7ed03e84f3d2
7069 F20110331_AAAVWJ jansen_e_Page_33thm.jpg
9d8179b88fc9e73878e6aadd9cb96b0c
563219680bba289f125b9360bbb2e2f6be9eea21
2130 F20110331_AAAVMP jansen_e_Page_56.txt
99738ea715531c68faadde05d386fd73
b6c969b2b37c41fb332109049980fd80dd41cb2d
71456 F20110331_AAAVHS jansen_e_Page_44.jpg
7d60729eaf18c91594a5d872e418e719
3654c772c25bb38ac5831af5e2d3adf4d5dfa8cd
99752 F20110331_AAAVRM jansen_e_Page_58.jpg
cd729cfbfa6b04c06dd110b80b95a028
dbf61d5eea607a01e61b3fa137d6811444719876
F20110331_AAAVCU jansen_e_Page_55thm.jpg
8209be077d0f10d6282c1c5debf3fa74
f1f8b4626e20b377a7729b18a29f8e2df617bed5
4969 F20110331_AAAVWK jansen_e_Page_73thm.jpg
5290a787ae015cb82b44dc7a2aa7f829
b57587f17b976c5c7dc4729fd159af3ddd97c558
2029 F20110331_AAAVMQ jansen_e_Page_57.txt
bd59973891caec4fa28385887af9e007
f16123024324fbe971082a989a6af060cd5152a6
28163 F20110331_AAAVHT jansen_e_Page_78.QC.jpg
b6a6960f347da32f42b58837ef98e6ad
2afbaad8acb6d3f2d7076859839b8eb400d4b8fb
68368 F20110331_AAAVRN jansen_e_Page_59.jpg
cb3df53939c5b5362ac05eae209e144e
ae3f4e85d96218979c7192a2055ff6f5dd33fd5b
996362 F20110331_AAAVCV jansen_e_Page_78.jp2
6950bdd3e3acb4a20450b6711d487826
fb6c6bfc783b8d3ac854be7cea16239c378abad0
32008 F20110331_AAAVWL jansen_e_Page_06.QC.jpg
3461eb792c1399c17da45574e453f03b
d250846d299d0c52ab09abb5291d04cc1a281643
2017 F20110331_AAAVMR jansen_e_Page_58.txt
3272e8fa0159b9a5f8b1fde02482e6d0
2c74ca80d0c9179d121ff9fdea5ecc7645fe0c9a
F20110331_AAAVHU jansen_e_Page_13.tif
481ca9679eefdb598dcf9cda82e68409
3682f34541405c4d730762461cd4f14bb9cedfa1
91194 F20110331_AAAVRO jansen_e_Page_60.jpg
5a14d1fc81b4bbdd4de690f481e3cad7
09a630252c680ddff7573a2d17492b8288dee179
F20110331_AAAVCW jansen_e_Page_63.tif
dd1642590d7467611a4f6387c0502a55
99342da8a3610914f1de33ca77865194449f2d1c
25075 F20110331_AAAVWM jansen_e_Page_48.QC.jpg
424f58f165e9ecadfd8006983f798a25
6a0f92cc0d9319f29c151cbfb788f5cb1c52f529
1493 F20110331_AAAVMS jansen_e_Page_59.txt
708a13d29f38ef1fba6536ab1ce7b5f3
612534bdb74b575b60e15b413a0c48152eebebca
89783 F20110331_AAAVHV jansen_e_Page_71.jp2
36371d2b8c47f25a875ff61bf0163b63
42e129230a75e0eaf1ce8c624857f9e3a84df61c
107890 F20110331_AAAVRP jansen_e_Page_62.jpg
835f67dfcd2a7c5d503c46165bb7e362
4a0be02ddd4552dd46964ba50fc96081cd8f456b
97593 F20110331_AAAVCX jansen_e_Page_27.jpg
ca98e9a28395fb90f58a92dfad477c28
3256eecde5f8f9e4a537be6c1ba2fb60cd059495
19329 F20110331_AAAVWN jansen_e_Page_46.QC.jpg
fb24c7ad4f2cf0b000ff64b7c6bc796a
7f70840af384f96062c5cb47e9705d5c1f5210eb
1906 F20110331_AAAVMT jansen_e_Page_60.txt
33e3c8481c4a390dd75ffbbf30f5e29f
a10aa7602d20c5bf1c913f872d416637ecd03efd
66921 F20110331_AAAVHW jansen_e_Page_28.jpg
f03ee671680b7a1168016af0381200c9
6831bf2ac71f2370a723ed80d5708beaca5c164f
90010 F20110331_AAAVRQ jansen_e_Page_64.jpg
66b0120c61c513228fdaa755f030755b
820f23235fb3419abb16b5ecc810ae5285d624e9
1051956 F20110331_AAAVCY jansen_e_Page_27.jp2
c8829e2d57289872abf015a14df9e424
7ede355e60306babe2df50b5ffd8f9a81f6087be
7901 F20110331_AAAVWO jansen_e_Page_65thm.jpg
30177bab6f06f1a5a03d55882f24464a
fe7ca74d0156a93113c29f0cded8055dafe0b4ba
2223 F20110331_AAAVMU jansen_e_Page_61.txt
1fae03bd65f0d68775f4f1480f80dc3f
b9f49ba5ca137f3ece62f2cfcf22c840ff1f8fd5
F20110331_AAAVHX jansen_e_Page_61.tif
10240237c6dff7c4b508ea713e36a741
0ccb08c956d3bbe3fa4759a621389622147ae2c0
93622 F20110331_AAAVRR jansen_e_Page_65.jpg
d019bc86015808b8cc8dc1fd25eab842
fe7203e6a51cedaa674a396282519e976d83b46b
89028 F20110331_AAAVCZ jansen_e_Page_17.jpg
a956f319adb6eb22fe8dba5d19208124
7d34ff10234cf8a4276ccbac6c84b5fab2f3abb3
28424 F20110331_AAAVWP jansen_e_Page_11.QC.jpg
b86064607a25e4768aab8dc14b77ce35
0b7d812018a4cf9d657d174e435cd47e4ec0d107
1887 F20110331_AAAVMV jansen_e_Page_64.txt
ace1339cc9a4f6509a4bd800d43ca80f
b8238692655d72457eb14893e2426e6eba9f7f2a
83250 F20110331_AAAVRS jansen_e_Page_67.jpg
921e9e479fbf6f641b3128bd5692a9ea
0e2512c03b47ba9df7048be89e01bfcebadb1992
5749 F20110331_AAAVWQ jansen_e_Page_72thm.jpg
61b7aca12e0e7a6b86c7ff490d34a579
e84e557c85c038c4617ed9abcd822a6d8379f1c0
1776 F20110331_AAAVMW jansen_e_Page_65.txt
e211a0f0da61a02fd238b34f54c9a0af
dbcbe10a41963c6959f160484d0d2a96bb70103b
F20110331_AAAVFA jansen_e_Page_77.tif
424234d8beea872db3aa41f2e762f0d1
89832d166ce6a70ad4d0dd2c3f6ccf8bca673423
33114 F20110331_AAAVHY jansen_e_Page_84.QC.jpg
18f328484c77badb64b2ecc3b80e939a
ebf6f6ba9b948d8a13e8a1fb5e1e602dd00a9f3c
104926 F20110331_AAAVRT jansen_e_Page_69.jpg
3ecbcc776728e63253aca44c7ab29f66
4f8574aed89068c6e0ca444c0e5c4d793173ac3d
7194 F20110331_AAAVWR jansen_e_Page_15thm.jpg
2bd3c1c0b4b4689506200b5062470d60
7e63e567b107c082596483348bee7612c07d5f19
1973 F20110331_AAAVMX jansen_e_Page_66.txt
752993786334d6429e50c6d7a78ae56b
fd2038daf0f3ec03b9dc19e8650e3a97f8939770
83652 F20110331_AAAVFB jansen_e_Page_09.jp2
167aaa99807cce6bf81bb5f7fbce5162
f517a718a2ca2cb57dd027b15efcfc52816ed423
49201 F20110331_AAAVHZ jansen_e_Page_66.pro
05bd3d7e0c7af3a0f7791e53f65d9c6f
c9038df58e165b025e353a464a0b164fa9b6e3c7
28464 F20110331_AAAVRU jansen_e_Page_70.jpg
17bcfba6ada8d0f27e769efcffe12716
bc59c652005bea4f765d17163a5e1cd362793de5
23355 F20110331_AAAVWS jansen_e_Page_45.QC.jpg
b954d236bdaaf78cb0b4875422e5180f
18a297a6808786f62d1b1e7a724f32dd92baf008
1582 F20110331_AAAVMY jansen_e_Page_67.txt
4ce04fdf067534b3c1f348dc4e6104b4
5a3f619be71264b8d1eb8a79a22080cef76327b6
38398 F20110331_AAAVFC jansen_e_Page_04.jpg
cc7c66a4d37b0f9c914f2266d3654793
b25464b91248a5abf03b7d704bacbed35ab7af08
81706 F20110331_AAAVRV jansen_e_Page_71.jpg
0e7bd67cc7b368cd8ad130b29ad1144e
75a6244f195a554bb6db8062d576c3c97b2e9cca
7070 F20110331_AAAVWT jansen_e_Page_66thm.jpg
cef5792d9dfb6c424209cd63bf46c987
cb14933328ac3e14c0e66ed6a556c7581ad9e2df
2138 F20110331_AAAVMZ jansen_e_Page_69.txt
ab522c5fd569aa85416f99e8313a5416
71256912794a86cac80f9a3402fd89d3baf1dfd7
21840 F20110331_AAAVFD jansen_e_Page_59.QC.jpg
87598b74130cb3cc3fc4bb54fb037d23
bc21b4005a8743890764c67fc33acb7ed4bb5ee1
71461 F20110331_AAAVRW jansen_e_Page_72.jpg
ed59f481f6de6d9341ba21e87201d864
b118fcddfe1cd1171601d41fbd8e2366ffc9d2d9
F20110331_AAAVKA jansen_e_Page_41.tif
d4095414fb7b5413f3d7a8e05443a274
df128eb6d3f77db90c54496ca60422a020ad39c8
29454 F20110331_AAAVWU jansen_e_Page_14.QC.jpg
dd9dea7938719bcecf98393f9e082e42
a2bf4416a95be1239a7ec6cb7309ffa1bb407791
65626 F20110331_AAAVRX jansen_e_Page_73.jpg
665497619e94274eba5d0c5564793fbb
466e8f45ed22fabfc0e6d0a2b31dfe8fc35eddf0
F20110331_AAAVFE jansen_e_Page_12.tif
b36d28d91a77f25ed5abb6e6ba8660da
5b307b483c53f865eaeee3514dd7149ff157faf0
F20110331_AAAVKB jansen_e_Page_42.tif
e70843d8eaa87dce82a9b8ef054159cf
1a9638628772c7d8ab38fb4357de4631ed70a187
26379 F20110331_AAAVWV jansen_e_Page_35.QC.jpg
1a89238464c34ebcbc1d9dd0701ca980
baae8efbf2fcd589a80874fff82be18fc410d77a
86619 F20110331_AAAVRY jansen_e_Page_75.jpg
279c54fdd5780ac5dbe51c1f524275be
1dbe29cab1ff47733a616d18c2eecacced58d8e4
6521 F20110331_AAAVFF jansen_e_Page_36thm.jpg
2baca33febb1e3e0389e58b6983dd31d
89514265ea9a524212c2792216b0f96cced3187f
F20110331_AAAVKC jansen_e_Page_43.tif
5d64fcec188504078b89ba38becd7fed
664884e3569b4ab4ec93d1be53365b83ba95a32b
543 F20110331_AAAVWW jansen_e_Page_02thm.jpg
f310cb61d0e05c07b25c294faa659b52
87286a0414639c6da0e1222668bf6849d7380935
82925 F20110331_AAAVRZ jansen_e_Page_77.jpg
54a9c782b82424ed6a0d2f472401f18c
151bef24681848da9fe3e240255b76b49169b8b3
7464 F20110331_AAAVFG jansen_e_Page_58thm.jpg
ce82aae33cb9fdc4b279ea5bd9848e5c
5d59071faaed349e44ecf0d9563342663eeaa49a
37935 F20110331_AAAVPA jansen_e_Page_53.pro
d9d958d783a258ae5b8be5219f23c8fb
4ce4305d5eafb483fa418524d9d652e1ac46be28
F20110331_AAAVKD jansen_e_Page_45.tif
1acdfdc6b38e32af99acb4a3a3131b08
ee9e0d1b84d5a54cf085f2793a2198787f3b041a
25090 F20110331_AAAVWX jansen_e_Page_52.QC.jpg
059388e319863db4ea1eea36858471cb
c2070f7e6f00e3071064910ed6c776d9c8e82dc8
F20110331_AAAVFH jansen_e_Page_72.tif
090de3ade82bb0ad7579a506a9441d26
32f303e1d9fc6dd289c8e88743c44899e53f0194
37537 F20110331_AAAVPB jansen_e_Page_54.pro
f04878fedc2d83f12618664b086ce5d7
5b39f265a02e8154b0bc5c6782b54f58633268be
F20110331_AAAVKE jansen_e_Page_47.tif
f74462df53c3e22ad89a648fe0f20453
7a051206a208b60a02c93e693ed91dc5a1518c0a
5997 F20110331_AAAVWY jansen_e_Page_85thm.jpg
77128aabbe8505d0aeb873956ca97772
747170874f11e835b0ab0c4aa8c38d791bbf7a0e
115719 F20110331_AAAVUA jansen_e_Page_63.jp2
b7e0244f27d71322d87fbc1eab481539
0313801e9ae4f2ce50974eba1554b3429d67a988
2197 F20110331_AAAVFI jansen_e_Page_62.txt
2da98c23ac8c257e9ca668d30fa291d5
f316eabbfdbd67632930d5227be2d294057b0692
49953 F20110331_AAAVPC jansen_e_Page_55.pro
586e4fae4d3c83ab2138eb1e40673ea4
7743448b03f8e2612d263a4d69de3950687e9861
F20110331_AAAVKF jansen_e_Page_48.tif
b46b13fba850cab2ca4de398c075c875
82491e828598bd846812523888fed1891deac824
1200715 F20110331_AAAVWZ jansen_e.pdf
6b1e2356aa20f87ea60d2b1090837419
19b6a121801efd7080423789e0186e15db3c630b
100045 F20110331_AAAVUB jansen_e_Page_64.jp2
7282a7edf1509e66d9f8ff03109c2c51
8a250d36829aef25e16a941547276b59b82d736c
372 F20110331_AAAVFJ jansen_e_Page_10.txt
6d415aa5463450d68af479c81a227db6
bfefb3d49dae67e563efa5ff083e21c7d167724a
54075 F20110331_AAAVPD jansen_e_Page_56.pro
ba5d0f7a448d6c5461b4bec1c43a5083
366fc1762b9b0b2c60c91a8cff3fcef83d651cd0
F20110331_AAAVKG jansen_e_Page_50.tif
d2bb73591dd606948d993fc71aaf5507
06bb058dc2b930dacd43e22c816d2d4f34263201
1051983 F20110331_AAAVUC jansen_e_Page_65.jp2
b24fb7151c5001e184a7b0d8e31f32de
327d61c79043c789aa5313d307a2f23eb159512c
6625 F20110331_AAAVFK jansen_e_Page_39thm.jpg
bb172550a4058639fd059ad352571e7c
566de1a23dafa7bb8fa34e1e1baded23957254a5
51337 F20110331_AAAVPE jansen_e_Page_57.pro
a3d1478b59eeaca45fc2e514a7428d0a
cb5ffd5e5221388a3a23b0110f9bf2c7d264fecd
F20110331_AAAVKH jansen_e_Page_51.tif
70125008f837a523752c8e673c08d27f
f988d1b36f4feca3f8a46d4ecad66ff31a208d24
6597 F20110331_AAAVZA jansen_e_Page_17thm.jpg
295c71e3ad2d409afe04759ed60c235e
0cd54b428a68b0440531bdd986dd99a7d7b2b65f
1051978 F20110331_AAAVUD jansen_e_Page_66.jp2
9e48f46f7acdb19b745daaee5d9bee57
be213e54e07a34055dfbcf431d55deae618434d2
F20110331_AAAVFL jansen_e_Page_56.tif
45320da019931c16168c2c420100e5e8
1f03587f4975aaf37d56f4dd41a72a29dd478581
50697 F20110331_AAAVPF jansen_e_Page_58.pro
4899525876a6aac2868ac65671cc8f6d
29bd99dfbd59fed926841228ce15fb272b770cf4
F20110331_AAAVKI jansen_e_Page_52.tif
ea0a1562c506ab4634429255bf612efc
9c96b492d289a2cec99b7404420dde2996115e54
6645 F20110331_AAAVZB jansen_e_Page_18thm.jpg
d046097174739d73e51e58571550f72b
9bb40cdff414a09b03938d7aea0bcfa0300ff4bf
1012572 F20110331_AAAVUE jansen_e_Page_67.jp2
ab06ae9326059042e56bd6f4062bbc21
9eb3f8336f6e65889240a4e432f85ab3f83e56b8
81157 F20110331_AAAVFM jansen_e_Page_76.jpg
7c12f8ff09c46a1fe6194d5ab76f2e8c
1bcc8c64f195ca54b1d7169fa080e73e53f7234a
25074 F20110331_AAAVPG jansen_e_Page_59.pro
c95b78ea5c945799ec905e0055ff8c04
bd244ed91f4149008133d85d2cb24af634dbd8be
F20110331_AAAVKJ jansen_e_Page_53.tif
b3dcacf6a0c43a1a784d6d5374604705
ed36d1165caf7a709e7ccd345f9dbf486e518178
6965 F20110331_AAAVZC jansen_e_Page_19thm.jpg
a691d26d0525242de6c6a5c9f8f491e3
03ced74c6493d7cc2f501611c77700ea6647710a
20416 F20110331_AAAVFN jansen_e_Page_73.QC.jpg
b5a3a14b0536d33c1d061d3e2f24cafc
3dacf3904b4042c7acf530169e05b2c74e9d0360
46075 F20110331_AAAVPH jansen_e_Page_60.pro
fcb3cf7c27731ae2982af38d93589035
47d61f1a62ccad5fb0fec1e03ea8216f3599c6f6
F20110331_AAAVKK jansen_e_Page_54.tif
3cf309c49b3787a01e4e4c3b13fb5e1b
be45b888a3e5ab5e56b836dcd62e310a48e83458
7654 F20110331_AAAVZD jansen_e_Page_23thm.jpg
d971528f2bb4b10a5c5ea855b901c99a
1d554810b3c738ffe40583bc1f8af759ff10f0ac
F20110331_AAAVUF jansen_e_Page_68.jp2
8e628bf7622856956f834d3658b0d997
2421817c0d0aa7c3ef145c3a42e76cb1d575d5fa
6956 F20110331_AAAVFO jansen_e_Page_75thm.jpg
ea527812482cea7fd00d47f3db738df7
7e74b0507fba321e01603f0f338c1be76af654bf
55849 F20110331_AAAVPI jansen_e_Page_62.pro
eecf40e39bf65b5d6734490951ff9848
ea09ebd5db80c19f0b43117925bb0db0bce7d120
F20110331_AAAVKL jansen_e_Page_55.tif
984b826cee35ac9c3327f6ea9fa8b528
83e71b5788d5248df6b89df8591cf3e0d6400678
6905 F20110331_AAAVZE jansen_e_Page_26thm.jpg
7a34ccb79b795b6799d3e2c74427e8c6
cecc54db43bb103f9a35b1d0e7d1c8847ae8f037
113946 F20110331_AAAVUG jansen_e_Page_69.jp2
71b78f3e4ef223fef0420268a014b232
257a73aaaf7adac5fa4d4647e8562167d780e867
2034 F20110331_AAAVFP jansen_e_Page_14.txt
a65be337846088a04dcdaa843c27e16a
a8d617df12afb388dfd54f3d26bb99e5854b892c
54808 F20110331_AAAVPJ jansen_e_Page_63.pro
3c0e992989c9ac4a0e40e939280fd1a6
e178da2adf105774e43201b40f80060445f82efe
F20110331_AAAVKM jansen_e_Page_57.tif
1512d51f757ca98f57ead9521769bab1
7b042cc4cc8cef58e968cfe9b24b57fe300571ed
6013 F20110331_AAAVZF jansen_e_Page_29thm.jpg
f9a1da389879f0ac304f69ecf3d18116
147d45fb0458da9cfc14065ba8a95174ff5eb115
407272 F20110331_AAAVUH jansen_e_Page_70.jp2
c43638a3ae05b770fe4d2c532116ce5a
bce2bc65b93d0d8dae86a04bf921deb4fbe4b888
27947 F20110331_AAAVFQ jansen_e_Page_39.QC.jpg
e878f6b4361fabacea6d0418972189e2
1021bf4109ad684f653b9d9370187a7cb9b16eea
46641 F20110331_AAAVPK jansen_e_Page_64.pro
0a637d3ac165393bfc53668c4ee9abd9
e4d5207a4fa632d8a7cb0169a37c3cf9c0b558ac
F20110331_AAAVKN jansen_e_Page_59.tif
4ff9b1c61d2290a22430d723fd530912
a57780328a03281c82bf72cebe35f62e60243b38
6471 F20110331_AAAVZG jansen_e_Page_31thm.jpg
cbdf608965e4ddc3e4cd5a2f95d5aab1
3c4c41ed6371ac68a11e92fc0da4814a36674cb2
786034 F20110331_AAAVUI jansen_e_Page_72.jp2
06ff351b666254845df9593b20f30e03
7a280799fc8e5a0861a4043b6247c0f57719e723
37931 F20110331_AAAVPL jansen_e_Page_67.pro
7eb5e1f15253c52a522383be18a1399d
9e193728df56ab283a1e72e1da6c131483082b8e
F20110331_AAAVKO jansen_e_Page_60.tif
057daed0a07b4769a087dc58e8ab0683
b55b303931da530ca43136c5ef00ab76151f4668
47846 F20110331_AAAVFR jansen_e_Page_33.pro
a1b75511c39c328facff128534744d35
467b5453d7b91c3c99eab7dab5e7dfaa951cc1e6
7340 F20110331_AAAVZH jansen_e_Page_34thm.jpg
e4006a8ab158cf3973dfaf84c96f4b35
343b20a29eab901fcf6c5c453e8914a1b06b1a62
69725 F20110331_AAAVUJ jansen_e_Page_73.jp2
66f3c1c6966b20344b3df6eaf14a2ec8
60c129580f4803f75103e72352149c42106cf0b6
38514 F20110331_AAAVPM jansen_e_Page_68.pro
1dcdf6d97787ff75a68970ef1822fb47
13ce705a69f96ecebfa8d32c25677dc7869104ec
F20110331_AAAVKP jansen_e_Page_62.tif
77e6e758ad5d67957d23f10044a86a1e
be69222cb2eb81238daafab969351e31498264e1
7259 F20110331_AAAVFS jansen_e_Page_68thm.jpg
a136be934345d55f5d98273359813f32
2742187c1561062855b7177d9fc8caa433fe208d
5767 F20110331_AAAVZI jansen_e_Page_41thm.jpg
043cddfb3debf82e958b52cd0a87ce3e
413183339d8a467d6b3a3ca2b60f3de351ab53f6
80424 F20110331_AAAVUK jansen_e_Page_74.jp2
2cb7b8cc758b0bed248ccdcfb3957279
38854e847e4faacfcb9ef78c3794e13d55b4b9d8
41070 F20110331_AAAVPN jansen_e_Page_71.pro
d2a37fa7a2cc84e8a72baa04a0fe6dec
9ff93a2ee01f34ae87cb40efbd1648f073fb2ada
F20110331_AAAVKQ jansen_e_Page_64.tif
78c8ddb9d398009441cf0755e089ab70
3b90115a2d7c071bd8a2893e88d04fcc5b08087b
35345 F20110331_AAAVFT jansen_e_Page_41.pro
a9e2a1346d74f9b018eaa96cf8e63414
cc6725f9658a983f0ea64ee70468b79878baa999
5850 F20110331_AAAVZJ jansen_e_Page_44thm.jpg
2854b11457438424743281cccbdb4b10
3bc745c07998a3356787ad28916dc4b3af44b92a
972321 F20110331_AAAVUL jansen_e_Page_75.jp2
c7dc46719b869fe1486f748b41ab8ac7
02e8869f7a0203d42cd9140301898133daafba0d
35652 F20110331_AAAVPO jansen_e_Page_72.pro
86d340c244cd139671c047baeab36c21
f4e4002ec37ee235a678ccab7e180e1076034657
F20110331_AAAVKR jansen_e_Page_66.tif
afea3d4441109354d4a600728f10178a
6900aebd7e22d10288f1ca7f53906016eca8a406
7186 F20110331_AAAVFU jansen_e_Page_43thm.jpg
d2966104509389d024d3471d399d0016
b83b4bc80da4b4270471bbcf42288e93b8c474ae
876173 F20110331_AAAVUM jansen_e_Page_76.jp2
e3efd1b40f481ddd4eb7860509f950ce
390a896fbc83a78563449249bb2d0e1753494854
31196 F20110331_AAAVPP jansen_e_Page_73.pro
a0e0694bf511bba095f591d9fcafd6f6
b35797283c49d7089b9200ed4a40010031702552
F20110331_AAAVKS jansen_e_Page_68.tif
4932c36ad2fc361d7c25eaa1572c7cbd
71222d6a4b05478a87a250fc8d29eb10b0de30ae
103424 F20110331_AAAVFV jansen_e_Page_61.jpg
c1517e2900a44172c130e09c39decc18
458f4adfb401281bebee0b0109bbdf2f55dabd5d
7463 F20110331_AAAVZK jansen_e_Page_47thm.jpg
0d46ef1167176ace717d49183e70908e
5590c9f208fd6ef43652a4cc479fabd25cd40bf7
90646 F20110331_AAAVUN jansen_e_Page_77.jp2
c25ffa21af2ba8bc45e0816758425b8d
269452b80ff90e321db832c4ef78f9399fa88fd7
36829 F20110331_AAAVPQ jansen_e_Page_74.pro
fef6ff1f8648ba577679a0342eee33bf
4b0eb8940531657e416d81ec75a035627ac10061
F20110331_AAAVKT jansen_e_Page_69.tif
aac4aaf33aafba89503f5017ceeae7d9
d983f8837e10bd42fd7d000012d1e83e86006a09
6580 F20110331_AAAVZL jansen_e_Page_48thm.jpg
ee64ce1a87d61089391baaf10c569e7a
d90af29e3e416f48a2b86a236c18f2bcef1b29a4
433849 F20110331_AAAVUO jansen_e_Page_79.jp2
334d4da8a3c854a368e62807ed6edbef
885a1d3139068c33a1c4f37ca130ceb26719d3ed
40260 F20110331_AAAVPR jansen_e_Page_76.pro
9b38f1a6300e9bfee69b95c60a4afb9a
505c72bbc828407dfd8ee4015533a66f8328db76
F20110331_AAAVKU jansen_e_Page_70.tif
0aa2c1e24734931f9f0ac809cc762e82
07fe694419f65297b8d7008c7e29fd77960a26cf
F20110331_AAAVFW jansen_e_Page_25.tif
664fbea012cd5c4b68ad046f56e1a865
c928f9f8af53e886fffe49baab435e94cd35ee34
6376 F20110331_AAAVZM jansen_e_Page_52thm.jpg
d09d0ff46f141b414a5bd3143d4803ce
5ea6d189ebf507598675dce99733381218d8d4be
127237 F20110331_AAAVUP jansen_e_Page_81.jp2
5bb3c68eeb78b8e52c6806cb78d5ff3a
726b636fd705695a1d1de6ba4544b773d0698b12
41764 F20110331_AAAVPS jansen_e_Page_77.pro
a3e2d579da237a997c3bec060320d3af
0d42d0d5309dbc13dcf05794855c0faa5af3af31
F20110331_AAAVKV jansen_e_Page_73.tif
04e23367c25568f07ab19eb8d5df7e28
fe1e24dd7c2cdc43fdb7340d3160b9e390e60e31
2221 F20110331_AAAVFX jansen_e_Page_06.txt
bbe0b759d46af44445fc4fdb17286e43
0aba59b740b2ca54d12cc1fd436ed29e7838f46e
6091 F20110331_AAAVZN jansen_e_Page_53thm.jpg
722aad3b012af74786b393b606797ea6
5e0841b270de68ac282cd76fb9d3c1441fdc432c
135077 F20110331_AAAVUQ jansen_e_Page_82.jp2
da12ca3ebfa376f01578d6fdc9d8e16f
1c8253e8d4907ea9f211ccdb2b22d98f0ab516a3
41852 F20110331_AAAVPT jansen_e_Page_78.pro
532938f28212d10a78306a91af757677
eafd4b40f819fb06707fbd44c24a61e60d4a2afc
F20110331_AAAVKW jansen_e_Page_74.tif
dc29ad85184562c49252e12556d19e83
21e0e3bf1c36eee8e35a1c4e7e190dba49464da5
1992 F20110331_AAAVDA jansen_e_Page_27.txt
7ae6685cc187f17e5c0409b4542df84b
ec5d39845ed3d2e3372227449cc5246907663dab
1264 F20110331_AAAVFY jansen_e_Page_02.QC.jpg
8dff2576fa1a09e7b55d35347f4f88c5
2564d7af48745f7020fd078b443c070030027ec0
7379 F20110331_AAAVZO jansen_e_Page_57thm.jpg
5ee1e129b4c456a65a0b1b1e8ec07554
b8d9eeb9ce1ef76014b7702828a047708ebfa6d5
119441 F20110331_AAAVUR jansen_e_Page_83.jp2
0807ac0721e346c94993384e772aa026
6d2b7b68db07aed96fdc92a02088afd889c406c6
8792 F20110331_AAAVPU jansen_e_Page_79.pro
65dd74dd1d981c4b1171eb9215172d37
e486ef50c6c97949feeec53669347bce88b315e8
F20110331_AAAVKX jansen_e_Page_76.tif
a6522283affa1ae45a6a6d07475a4291
0efed5923241ff02afb4ecb19edee90506f305d9
95787 F20110331_AAAVDB jansen_e_Page_12.jpg
db36d4bc97d9a71fee7d96a746173ebd
8b0be3d3d1436dae4a40bc9c35e6901c1e83a22f
101898 F20110331_AAAVFZ jansen_e_Page_23.jpg
ea43c38b6d77b10da8ff78358cf70328
2b3de694b02ee3bd5efee074456abbc2dfa50ebc
7427 F20110331_AAAVZP jansen_e_Page_63thm.jpg
1af3fc4d070c1954cbc8ed67ecf4544e
e9429655d21699152fa1013bdd5c178c3e3c8b6f
128633 F20110331_AAAVUS jansen_e_Page_84.jp2
26778fd30cbb3cca4f5c97d9deef19ed
23bd3e6efcc6288338e1322146259d6095332e21
61879 F20110331_AAAVPV jansen_e_Page_81.pro
1eed096d729dd0ac7dc00652c530bacc
6b314fb25917d9afbcbdd1c4924e5fc7389f808c
F20110331_AAAVKY jansen_e_Page_79.tif
2fc27162f71d5f43401fec366c91942c
fc4fb2bd23f4ed3cda62564390295199f755768b
21106 F20110331_AAAVDC jansen_e_Page_07.pro
02b136a8b6413207dc0849ec57959a56
7cbada94712f5137031d279ce164580077b0656e
6568 F20110331_AAAVZQ jansen_e_Page_67thm.jpg
43c78ee54a650b02ae6268da0285491f
93b78b2de3ec79fdf6bc6fbe9e321f097252ea32
24180 F20110331_AAAVUT jansen_e_Page_86.jp2
199b0fa7be82934772850164c9a6d1a9
aa8654f7aa8f2128665fbd54c9c8f05c15ab0743
57247 F20110331_AAAVPW jansen_e_Page_83.pro
33db007af5475cfa4f23edaf96271aa6
cb9ea0e23cf91baa05908559e40adbc7e54ff914
22786 F20110331_AAAVIA jansen_e_Page_01.jpg
7d13a76d6e31331d58fa8f40888dc3b9
4cdeb14bb0fc52842802d8f230e9ffd79954449b
F20110331_AAAVKZ jansen_e_Page_81.tif
7a87d7dc833b53fe16cc27b5074f6423
d78bea3d118a55268ccbea26749990b657574952
765 F20110331_AAAVDD jansen_e_Page_04.txt
4d19e6859c15f47eadded784b821ca87
aff7c49e10274a79183c14a90231f13904bed3fc
2765 F20110331_AAAVZR jansen_e_Page_70thm.jpg
88b20167bda78c13a9e75c7b3ae32b15
ad9488d28ca74d086bcd37093e3dfce60fa306bf
6455 F20110331_AAAVUU jansen_e_Page_11thm.jpg
145077eb03fac2928d6b429c3c17acee
f95d2a4f40d4e3e749d5b129d585b864534a080a
62593 F20110331_AAAVPX jansen_e_Page_84.pro
b1f15465a5ea9dec25c883d7290eb339
eb0db8708a10ff37a6a4b59dac99a931f2420b8d
28126 F20110331_AAAVIB jansen_e_Page_42.QC.jpg
3ac5418b7c69b2788bf57838ae305068
811851a5a7ff411d78ced72818ab46d4eb988cee
5797 F20110331_AAAVDE jansen_e_Page_54thm.jpg
637f04f3887849287874e22424115b24
b8fcb5384ea4d72dc7009a8d7c9c24e94274cde7
5858 F20110331_AAAVZS jansen_e_Page_74thm.jpg
b441634658e27f819bb2af6df6728b97
512356c0bbe83a2b4f62ee4fdf5ac279b76f5dc7
29480 F20110331_AAAVUV jansen_e_Page_12.QC.jpg
938d96563d7c343128b347e62729e19f
0f17487faf7c617a904cdfa0af77c72df898e70d
46268 F20110331_AAAVPY jansen_e_Page_85.pro
af6ddca6184836ffa7cb1798bf68cfa1
35d8dbda1e5e58991c3fdd3f05e32168ae2770f6
104545 F20110331_AAAVIC jansen_e_Page_13.jp2
c4315f89ff7058b6dd6089e646ab85c8
30151826475b5488f7f5c554535792f984603484
F20110331_AAAVDF jansen_e_Page_58.tif
29e9e8cc7df431c61313437d1af5906e
2d95ddf93c1da4085249b18dcd356b9b73d6d937
7747 F20110331_AAAVZT jansen_e_Page_84thm.jpg
c8689c8aaeecea3b858ff322dd070b35
1c741631cb5faa08f379c5d8d540a9e3ac55b013
7430 F20110331_AAAVUW jansen_e_Page_56thm.jpg
51d22843e6d1948ecb2b457b6239f398
e11f4273e02e20c241edf95a6da7e5f64f89addc
9382 F20110331_AAAVPZ jansen_e_Page_86.pro
7cc08c5bdfd30cada34140a5a954a1b6
57fe5e839ae0d53aa3252ffb716851bc4474d03b
40496 F20110331_AAAVID jansen_e_Page_52.pro
40b1ccf933ee316da8f87110fe17eb77
4b2234923797d1907f78a59a589aaa5f4cc099bd
6643 F20110331_AAAVDG jansen_e_Page_76thm.jpg
04a94d29d2299142a4b6351c939320f9
037f02e092bf0bc499c3dc5ae60c05b7ed4db3d0
336 F20110331_AAAVNA jansen_e_Page_70.txt
5c2628c1fb366e5bc2f06cee8cfc4269
04e75c94ab02ca7ab814d1c6dd91796f630e7f7e
6612 F20110331_AAAVUX jansen_e_Page_01.QC.jpg
e9c5e407fcbe01f109bdccfd77db3cb3
ff3305916eda6810716a9ae6485c51f5ae98cf54
636158 F20110331_AAAVIE jansen_e_Page_07.jp2
e60d903e03c938410363d0047d77743d
b5d3c819fa8b82e403f8a0fda4e421923e33c40b
1608 F20110331_AAAVDH jansen_e_Page_54.txt
ddba47441c58f19cac5dfd65da7da655
cdfc688ca9947345c2cf2a3b3bee23c794e5adf4
1728 F20110331_AAAVNB jansen_e_Page_71.txt
b1f2897075de70b65189dbbe44012d85
7a0d2f4c7d93774987f91e1413d839c66087110c
31481 F20110331_AAAVUY jansen_e_Page_37.QC.jpg
517923ed93f20f972ffb23e43cbccf90
da8ecaa7b0720ef35a7db32a826fca488b7b029b
89419 F20110331_AAAVSA jansen_e_Page_78.jpg
69bc8c3303b897d55f89f23fa90217f8
b5b34ea84c8798f4f513f8269f848c088ad0610b
98171 F20110331_AAAVIF jansen_e_Page_85.jp2
577e82e4a8b7de9d65ebc7ea66e2434a
1619cf4c2c66f575ca55bc3714c7f3dcabc81d8b
5375 F20110331_AAAVDI jansen_e_Page_02.jp2
9df157345596ee4527e34399d82c4f25
34635f397ae4749267600514c92ecbf0026e5fcd
1437 F20110331_AAAVNC jansen_e_Page_73.txt
a4736ca7be8e7a9bde5818a1e9a9d48c
e6cf4d7dd2bf5b19253d19fee019d4f0b8b2ff82
6669 F20110331_AAAVUZ jansen_e_Page_25thm.jpg
1bab9bbff0aa83550fd8c721d5f3f36c
cba1bea15f596d406b2926a72fa8ad3cfc0fdda3
39605 F20110331_AAAVSB jansen_e_Page_79.jpg
2af24791b620e575d88fdeb1198ecc43
7da1bc197bd50138fcdde1ee83cc19c75ee12374
101812 F20110331_AAAVIG jansen_e_Page_33.jp2
887b08a7822c75a088a15bb6af80bc16
7dbd0c0c5b1e4cc005d40b635e1d6c25ec8f4363
7175 F20110331_AAAVDJ jansen_e_Page_20thm.jpg
52cbf033e0bdcdb9b2c44b2b2d772a73
749c5a7f5f1cff6f7116ea96a8234fc12ac51d8f
F20110331_AAAVND jansen_e_Page_74.txt
372862123bdbb58a25842262b6c23e74
edd30543b2c66f3af2d83bea7950622b9c258f52
103516 F20110331_AAAVSC jansen_e_Page_80.jpg
5e6aebe90ff6f34d700681976010b77d
750ba16e43a35398986e072ba50217366145419f
55133 F20110331_AAAVIH jansen_e_Page_61.pro
81013259e748d24dc8b1eec241dcdd38
5a9adc650ebfea6dc4b02dd023a46e0e97d602d6
30425 F20110331_AAAVDK jansen_e_Page_30.QC.jpg
b3c184e33b65baa595d9f9abc98cce0c
bd12904c4d709199b39ac903ec527f7cf507e4e9
1827 F20110331_AAAVNE jansen_e_Page_75.txt
6cab366b2d1842b3c933712702fc342b
511cd0b10c895c76dbef116795aa9ae034b7c17a
6389 F20110331_AAAVXA jansen_e_Page_77thm.jpg
43594a9d5e019f07d259faa3a067c78d
8a882457b4c37a72914848b9762a8274ee4072c5
F20110331_AAAVII jansen_e_Page_18.tif
50626d9c3673300e7613e9a342426f87
14643464faec0ccd3d1fefba90f93475e2e03f8b
6700 F20110331_AAAVDL jansen_e_Page_86.QC.jpg
9210fc5e5630da741681ec6139794d15
1db680451ea54621066f3fcc8154782933f8f947
1654 F20110331_AAAVNF jansen_e_Page_76.txt
40b8ada0077455a9338f3b13040b2903
93594d22c70df02f896f2aba941358b1828db36b
667 F20110331_AAAVXB jansen_e_Page_03thm.jpg
0ec6b8c72b7f6a8a8366e6f3cccc32ec
d6e55a917197b192ccd530c46f4a29b884b16669
120392 F20110331_AAAVSD jansen_e_Page_81.jpg
9d17a7d69734c33d86178e2c6a46854a
b9f85cf566bcb612385f415ab11445bcb155a699
1774 F20110331_AAAVIJ jansen_e_Page_29.txt
94ebd419fed16939d6536a06f308e3b2
53937810bce93dd0ed9b44b63c9a67ed4d84c2eb
2008 F20110331_AAAVDM jansen_e_Page_23.txt
cb049faf3f63d3221d0fffa0ffe5554a
ae5fecd29f267fa8fe87968443cfb23904d221dc
1808 F20110331_AAAVNG jansen_e_Page_77.txt
8483de3cd769991ec2c6ed3f3b6a7a7c
138053ea725130b40087b3bc61dc7b71bd7040a0
22844 F20110331_AAAVXC jansen_e_Page_72.QC.jpg
839c59758e0e58f18d2c13947546e25c
7eeff99dcda7985ed6273acc0bd93522c8a2b1e4
127096 F20110331_AAAVSE jansen_e_Page_82.jpg
d5aa97b96469ea11ba373f43ef95c6e9
6e709034ff06ef28b2586b7cc22604c36e673443
105823 F20110331_AAAVIK jansen_e_Page_55.jp2
30db4b7a80d7794233fe7887de805384
3631791801960d8edf9869f6fde5e3bae3c310a6
106360 F20110331_AAAVDN jansen_e_Page_63.jpg
f51142d023d498076180d39f3a7158b2
651716fd94a787d6f5942dd1cfc7888145d6d35e
1830 F20110331_AAAVNH jansen_e_Page_78.txt
a2cee35eb845fe07b64402ff16982ec0
3f68d20e20716c282e1e4bda054fb29c0df05a60
6837 F20110331_AAAVXD jansen_e_Page_78thm.jpg
416ddd57757278504efa4568530e6acf
a561fe6a44711c698e956c81bf929839381741bd
112927 F20110331_AAAVSF jansen_e_Page_83.jpg
00e22887dee8e054bd1d19e5cff1d9f2
c53bdc5d61658201f905c2e74bac423e7419c742
95089 F20110331_AAAVIL jansen_e_Page_14.jpg
8775306d36ee4bce67ab1e6222066027
12d0ef65b4a54ae3060831f2da00f15d0b09fb7f
F20110331_AAAVDO jansen_e_Page_67.tif
2d1c216bc6989c7b729f31fc18c66ae0
bd8584dde4c697b8287167a9a85c1599d45b3ae3
388 F20110331_AAAVNI jansen_e_Page_79.txt
93f31b87da0e7ef7644c7130b30127bf
2448a1dd082d6adf6c910d26d109383d5347e9f2
30044 F20110331_AAAVXE jansen_e_Page_15.QC.jpg
159f35d425b2f030a8c4f165ec639af5
763ceab84257f839e3b706d063ad51a6a794fa81
122138 F20110331_AAAVSG jansen_e_Page_84.jpg
84bff905fe9d78b70868b0d969553896
eeb62299d50bbcba0cdaf61c04b7c3436f55c460
1667 F20110331_AAAVIM jansen_e_Page_09.txt
805a5e81ad01a206f23ae8f192e657ca
93606c96932ad72892af56dd05c491ec4579cdbe
F20110331_AAAVDP jansen_e_Page_71.tif
76b4f8d9130023a00d7726631277933c
99fc46017441323667488804e9edda351342ff83
2119 F20110331_AAAVNJ jansen_e_Page_80.txt
d381e85c34ba6bb67892ce333f6f08ce
d842e20566034295d8f9dca5eeb4bb65c57e4cad
5471 F20110331_AAAVXF jansen_e_Page_50thm.jpg
1e9101f1e362f70dd93a1380dd339c33
a6908b9df1d9224cc5ea64903555671ccf53c69e
93625 F20110331_AAAVSH jansen_e_Page_85.jpg
922d14a93eb1fad02cfe57c646801541
c93ee98d541407ce3b4bb50f0d7fece77ebfda6e
F20110331_AAAVDQ jansen_e_Page_16.tif
ac0db2c8ef4d051acabd142a3c1c111d
23f8a1d9e2f513e34e78e48803766e88f917f4e5
2500 F20110331_AAAVNK jansen_e_Page_81.txt
3168c02fa9792af280feee2409af1769
8e2081ad808381d495e2570c721149a26c59e802
2178 F20110331_AAAVIN jansen_e_Page_63.txt
456c26f223207170608c3e859f0e01fc
2f848295e8b8cc276e501735caed6dca594055bf
21477 F20110331_AAAVXG jansen_e_Page_16.QC.jpg
77935ac52c2fbe29e42fb60fa508e251
cf24b0d1d1808b9e7661d97fade092a4cf3eb968
19736 F20110331_AAAVSI jansen_e_Page_86.jpg
a72a32768b4271c4888b724aa63dc6d7
9486dfa11700ad31052bee26b1970418fc546c8a
8609 F20110331_AAAVDR jansen_e_Page_70.pro
4822e5d8053e50801d03f5290380c483
9c1f734c04fa91389a654075208050c2bb3ed341
2679 F20110331_AAAVNL jansen_e_Page_82.txt
1c4196a694cd18ec2ec961f5ff3d886d
46549996d28b30c0183339ca96fa032bca653052
100279 F20110331_AAAVIO jansen_e_Page_22.jpg
34b5ac313fc2061cea347753ff974361
60908f1314ec5ce81f7d36ac231a12c07770f047
7539 F20110331_AAAVXH jansen_e_Page_69thm.jpg
ca82c2990d2bb4ec622617e31257e203
d244a9d98cde82ae87b8fac17358f7f734c29822
23119 F20110331_AAAVSJ jansen_e_Page_01.jp2
a5a6d0b6344d06290d4174344a39c4ea
9536c16bfd6b7036b5fcf0a13de7e2b7dcffb709
5424 F20110331_AAAVDS jansen_e_Page_28thm.jpg
b7eef45b4c12d66e2745ea93199c4a1c
b0d567102f0763a19869d9410541b47e63a03cd2
2311 F20110331_AAAVNM jansen_e_Page_83.txt
dee508288e154c7ddb5232b4f11693c5
e7ef35187b4f775b03373cb1f13f45b285f59611
23577 F20110331_AAAVIP jansen_e_Page_09.QC.jpg
b8f447cb38dd67d76abffc8fd4a34cfd
f3db4bd2b30701770158fd6ea14a237dd979f089
7312 F20110331_AAAVSK jansen_e_Page_03.jp2
ece552a025f6b73ea37991b0c0edceae
6865e85b92d83a49756ad1e1a13c5c202c234332
F20110331_AAAVDT jansen_e_Page_77.QC.jpg
9070ab08fd40fc65c6bae9382eb2c4cf
1d360da10775d3a6e625568cb0ed7fe1d5a33177
2515 F20110331_AAAVNN jansen_e_Page_84.txt
909cadb17eda313e7014bd45332f3c40
00f241ea23d33642b3bc3868ca534bb0dd527876
1847 F20110331_AAAVIQ jansen_e_Page_24.txt
b24d77eab859fff800a84cdb7541e0b4
a0d1962379ac0884dea4f446983e5500be89fe15
3010 F20110331_AAAVXI jansen_e_Page_07thm.jpg
283b3e39f4eec06068e4a49ca6f9c1d1
c2570493023a821c53b59cb42cb328ac51143fc9
40553 F20110331_AAAVSL jansen_e_Page_04.jp2
e1583d6e15d1040b3ebee304515f03b6
b3745c1a0e8bb986837651350e3f9f6da3c29440
421 F20110331_AAAVNO jansen_e_Page_86.txt
7666c4f164239cfd9c3c654b4b6461c9
74b01a86d39da47d48c8215a7bc6bdfc42f1ad5d
98683 F20110331_AAAVIR jansen_e_Page_66.jpg
e2b592b2f91e4728ceafe57640761008
4769fb0262ea351488d207735ed5899e6d50d4a2
6933 F20110331_AAAVXJ jansen_e_Page_37thm.jpg
292a2871849f22863b31510d322eedf4
2a0787d3a0c9abd30f829eeeed571db689da19a5
1051982 F20110331_AAAVSM jansen_e_Page_05.jp2
10c18f8de8f857799a318f3bff323d25
1f01fff563497095f14260a88bb7d7757167b3f4
F20110331_AAAVDU jansen_e_Page_46.tif
6739a9956f7f1ec2e8fb91b328083f28
d9fef4c36869c43fe2da071eeb490157ea2c8614
7389 F20110331_AAAVNP jansen_e_Page_01.pro
d4725d30f0b1f394f5b85b3f530b08bd
e6b747893b43d90aebbb768c1cf337e506ee0841
498278 F20110331_AAAVIS jansen_e_Page_49.jp2
2ab0f46d95e62a8f7f77ed363d8e0cbb
29f25acf98b274d02aeee97f18f55631b68a3949
23043 F20110331_AAAVXK jansen_e_Page_54.QC.jpg
fd850e522ef4b4f3d18536a9ecf5cd7d
41cb1c12f8532c80b83de3328c8f14e148c05fa1
F20110331_AAAVSN jansen_e_Page_06.jp2
cd5e8e4d11151069090d8e7db44727c9
b49b7b12ed4c0b02737f094cba886146ede1850c
1332 F20110331_AAAVDV jansen_e_Page_45.txt
7d7c44c2424759c935afabddde2250bd
579b8d35dead1d51eefe94c253c66a8d4ffdc9ec
F20110331_AAAVNQ jansen_e_Page_03.pro
7e97c8b46b3f91fcf883a682ff5db826
0245ac30aeca566755b92d81584e2fccf8831b9f
29660 F20110331_AAAVIT jansen_e_Page_13.QC.jpg
d259a6431561fca454a5337ffbc086db
34805faf5081e542fcbb1c6fa15f657434995198
1766 F20110331_AAAVXL jansen_e_Page_86thm.jpg
9ace92b34cd629d2a1a79864105deb7f
8758d0cb2c21a665ebcebdfc7be87efb0ccfd49a
653335 F20110331_AAAVSO jansen_e_Page_08.jp2
43291f1f9547c8ce9025923c75d649de
3fd64b394e7f19e5b5bcf2592a5210aaf8e3e13f
7474 F20110331_AAAVDW jansen_e_Page_21thm.jpg
058a8c02bd442fc46a4430d525b7bc0f
a632817e69dbd920983dc75bf11e6c80b9baca55
18075 F20110331_AAAVNR jansen_e_Page_04.pro
18382becb1c637b2001dcbdac7917a62
ef89737988bb49e7681decd2d5e873349aed7fc0
100933 F20110331_AAAVIU jansen_e_Page_37.jpg
5d635a31894a9b336e0b567bd00eabd8
1aa32858cc4d2db67783c517f3d34df506f49e17
7154 F20110331_AAAVXM jansen_e_Page_12thm.jpg
01b52677665ee32bd0f6dc1d7294bb82
9e67d29ea1b1d18b2af7f60da1442574a4e8ea64
1005205 F20110331_AAAVSP jansen_e_Page_11.jp2
e53ee0206b6c51a934ea0e09dcaa7013
ff7553fdf10591045c72ffd312040d21fb27c511
98650 F20110331_AAAVDX jansen_e_Page_31.jp2
f79b0c33781d6db6e119ab6829da3d3f
4ffb270facfaf0806836f1ad3db6acdad785b091
51227 F20110331_AAAVNS jansen_e_Page_05.pro
10ed38c8dbc28280a5b27d759f71022e
388e6930b621fcb673f6d6dbce64318b8648af55
101724 F20110331_AAAVIV UFE0013044_00001.mets
5c3edeb962b7209d41e5c437abf04ca4
3ad6648a0a60aa524015e666b521483b66d1d2ff
6821 F20110331_AAAVXN jansen_e_Page_30thm.jpg
95a9097a97c62b606cea5550256bab3e
e5b6cefcea4663e4063fdde16cca5d4577768ede
105940 F20110331_AAAVSQ jansen_e_Page_14.jp2
01a1bbe0bcf6c2d9511a66d1e3f7b613
eb7a691cf8e09a57ae5b22a4c55ef5ad8332de96
29316 F20110331_AAAVDY jansen_e_Page_80.QC.jpg
c99cdd571f1070bc22d12df4c29c8efb
2a8fb5c74ec916e14880a94d1c82c97164e3575a
52489 F20110331_AAAVNT jansen_e_Page_06.pro
7e25a52f574b46b2e80837617d79f642
5eb25cee1fb40edaf1d67c11b04141a2327782e0
1590 F20110331_AAAVXO jansen_e_Page_10thm.jpg
05e9d83fe1ac2342c59e1a519cda0bca
70ed70c8c9ce9159ecb6d18db442802b20c3fe27
105725 F20110331_AAAVSR jansen_e_Page_15.jp2
d871f5239051249264a0426a3a877874
1d69b1ff9b55375c5b47b69cf00f4e8c725b5a64
F20110331_AAAVDZ jansen_e_Page_42.jp2
b053d68a52b07ce36ca68f813c7c9751
cef0512e74c04c06a36c9330572449a2f14010ce
37917 F20110331_AAAVNU jansen_e_Page_09.pro
c56315922ba5a0db7904e84dfefad2c2
ac0be26cf85ff39f9cc5355e83f76139bf561ef6
9294 F20110331_AAAVXP jansen_e_Page_70.QC.jpg
545f23df8047a5d316b4981c9be4f895
f9fd0f87d758b04afa46bbb7a1ebef156607649a
73396 F20110331_AAAVSS jansen_e_Page_16.jp2
b1e427f36201b54c139a9d1c8ff4fb91
606efcd33f142c09fdf295e798bcae1403d1a9b4
9133 F20110331_AAAVNV jansen_e_Page_10.pro
55179f40a90e7fec486f70b92a108420
22c12c099a890562ba5f1ff73d2e0283b5e8f366
F20110331_AAAVIY jansen_e_Page_01.tif
85c371e03abc7646aa36d1bb6fd59ff4
a8325cc56b409fcef0943886cd4f736ae4e9735b
33674 F20110331_AAAVXQ jansen_e_Page_62.QC.jpg
b33ccd73da83e3ba09ecda22dfa23f8d
db5d4e9ee4913a7415eff627446fad67ed37ae4c
97769 F20110331_AAAVST jansen_e_Page_17.jp2
4b4f20caca439ef01244d9a1bf174fff
1930d8ae7e5d526c8b8c7022558253508e10b7c2
45283 F20110331_AAAVNW jansen_e_Page_11.pro
6165866f8f07e1a3f39a179e36a2403f
fec8aff72860645252a0d7b716bd37c0cd157a48
23381 F20110331_AAAVGA jansen_e_Page_38.QC.jpg
52356e4b89e070c978b8e1c86d9cf353
fd2ebdb914634bb6f7015c5a69a6f48748142023



PAGE 1

CONTEXT-DRIVENPROGRAMMINGMODELFORPERVASIVESPACESByERWINJANSENADISSERTATIONPRESENTEDTOTHEGRADUATESCHOOLOFTHEUNIVERSITYOFFLORIDAINPARTIALFULFILLMENTOFTHEREQUIREMENTSFORTHEDEGREEOFDOCTOROFPHILOSOPHYUNIVERSITYOFFLORIDA2005

PAGE 2

Copyright2005byErwinJansen

PAGE 3

IdedicatethisworktoMissLee,theladywhodancesinmydreams.

PAGE 4

ACKNOWLEDGMENTSIthankDr.SumiHelalforhisguidanceandsupportthroughouttheyearsthatIhavebeenapartofhislab.Withouthisencouragement,guidance,andbeliefinsuccessIwouldnothavecomethisfar.IwouldalsoliketothankProfessorsP.Fishwick,M.Bermudez,G.Ritter,andB.Mannfortheirvaluablesuggestions.IthankMr.Bowersformakingallthesemanylast-minutearrangements.IthankKellyZoboroskiforherlove,support,andthejoyinherheartthatsheshareswithmeonadailybase.WithoutherIdoubtifIeverwouldhavestartedonthisendeavor.Finally,Ithankmyfamilyforlettingmegotothisfar-awaycountrytopursuemydreams. iv

PAGE 5

TABLEOFCONTENTS page ACKNOWLEDGMENTS ............................. iv LISTOFFIGURES ................................ viii ABSTRACT .................................... ix CHAPTER 1INTRODUCTIONANDMOTIVATION .................. 1 1.1LimitationsofFirst-GenerationSpaces ............... 2 1.2RequirementsforHardwareIntegration ............... 3 1.3ProgrammabilityofaSpace ..................... 4 1.4SafetyofSpaces ............................ 4 1.5BehaviorversusInformation ..................... 7 1.6Goals .................................. 7 2RELATEDWORK .............................. 8 2.1SmartSpaces ............................. 8 2.1.1Context-AwareComputing .................. 9 2.1.2MiddlewareArchitectures ................... 11 2.2OntologiesandSemanticWeb .................... 12 2.2.1ResourceDescriptionFramework ............... 13 2.2.2DescribingDomainKnowledge ................ 14 2.2.3DescriptionLogicsandtheWorld-WideWeb ........ 16 2.3TemporalLogic ............................ 16 2.3.1IntervalTemporalLogic .................... 17 2.3.2LinearTemporalLogic .................... 17 2.3.3ComputationalTreeLogic .................. 18 3PROBLEMDESCRIPTION ......................... 19 3.1NonScalableIntegration ....................... 19 3.2ClosedWorldAssumption ...................... 20 3.3Fixed-PointConcepts ......................... 20 3.4Objectives ............................... 21 3.4.1EnhancedProgrammability .................. 21 3.4.2InteroperabilityandExtensibility .............. 21 3.4.3CapabilityofExceptionCapturing .............. 22 v

PAGE 6

3.5Approach ............................... 22 3.5.1KnowledgeEngineering .................... 24 3.5.2SoftwareEngineering ..................... 24 3.6Advantages .............................. 26 3.6.1Explicitness .......................... 26 3.6.2InteroperabilityandExtensibility .............. 27 3.6.3ConictDetection ....................... 27 3.6.4CaptureEnvironmentalEect ................ 27 3.6.5AutomaticTuningandMachineLearning .......... 28 3.6.6Scalability ........................... 28 4OBTAININGINFORMATIONFROMSENSORS ............. 29 4.1DerivingContextfromSensorsReadings .............. 30 4.2UsingOntology ............................ 31 4.3TemporalContext ........................... 34 4.3.1SyntaxofTemporalContext ................. 35 4.3.2SemanticsofTemporalContext ............... 37 4.3.3DescribingEventsusingTemporalContext ......... 37 4.3.4ComputationalComplexityofTemporalContext ...... 38 5DESCRIBINGACTUATORSANDSERVICES .............. 40 6PROGRAMMINGTHESPACE ...................... 42 6.1Beliefs-Desires-IntentionsofUsers .................. 43 6.2InheritanceandOverride ....................... 44 6.3ScenarioandProgrammingProcedures ............... 44 6.3.1LighteningControlApplication ................ 45 6.3.2DescribingContext ...................... 45 6.3.3AssociatingBehavior ..................... 46 6.3.4ConnectingSensors ...................... 47 7INTEGRATEDDEVELOPMENTENVIRONMENT ........... 50 7.1DesignoftheContextGraph ..................... 50 7.2InterpretationofSensorReadings .................. 51 7.3DesiredBehaviorsunderEachContext ............... 51 7.4MappingPhysicalSensorsandActuatorstotheContextModel .. 52 7.5ImplementationoftheIDE ...................... 53 7.5.1PremiseandPlatformSelection ............... 53 7.5.2RequirementAnalysis ..................... 54 7.5.3EnablingMiddlewareRuntime ................ 54 vi

PAGE 7

7.6ComponentsoftheIDE ........................ 56 7.6.1EntityDenitionView .................... 56 7.6.2BehaviorDenitionView ................... 57 7.6.3ImpermissibleContextChecker ................ 58 7.6.4CommunicationModule .................... 58 APPENDIXDESCRIPTIONLOGICS ..................... 61 A.1DescribingIntensionalKnowledge .................. 61 A.2Terminologies ............................. 64 A.3ExtensionalKnowledge ........................ 65 A.4Reasoning ............................... 65 A.5Open-WorldversusClosed-WorldAssumption ........... 67 REFERENCES ................................... 70 BIOGRAPHICALSKETCH ............................ 76 vii

PAGE 8

LISTOFFIGURES Figure page 1{1Safetyversusprogrammability ...................... 6 2{1Knowledgenetwork ............................ 15 3{1Negativeinteractionbetweenentities .................. 25 4{1Indoorandoutdoorsensors ........................ 34 4{2Asequencedenotingsomeoneenteredthehouse ............ 35 4{3Actualsequenceofevents ......................... 38 6{1Asamplecontextgraph ......................... 49 7{1Interactionbetweencomponents ..................... 55 7{2Entitydenitionview ........................... 57 7{3Contextbrowser .............................. 58 7{4Impermissiblecontextvercation .................... 60 A{1Openworldversusclosedworld ..................... 69 viii

PAGE 9

AbstractofDissertationPresentedtotheGraduateSchooloftheUniversityofFloridainPartialFulllmentoftheRequirementsfortheDegreeofDoctorofPhilosophyCONTEXT-DRIVENPROGRAMMINGMODELFORPERVASIVESPACESByErwinJansenDecember2005Chair:AbdelsalamSumiHelalMajorDepartment:ComputerandInformationScienceandEngineeringOuraimwastoestablishaprogrammingmodelthatcanbeusedbydeveloperswhobuildpervasiveapplications.Currentlythereislittletonosupportforprogrammingpervasivespaces.Everysolutionisstillanad-hocsolution.Ourprogrammingmodelacknowledgesarelationshipamongsensors,actuators,andsoftware.Bymakingthisrelationshipexplicit,wederivedaprogrammingmodelthatisgearedtowarddescribingknowledgeanddeninggoals.Agoalcanbeaccomplishedbyinvokingaseriesofactuators.Wedividethesoftware-engineeringprocessintotwodistinctphases.Inonephaseweareconcernedwithdescribingbehavior.Anengineerspecieshowaserviceoperatestoachieveaparticulargoal.Theotherphaseisthedescriptionofwhattheservicetriestoaccomplish.Italsoallowsustoreasonbeforehandabouttheeectoftheinvocationofasetofservices.Thisinturnhelpsadeveloperdeterminewhethertwoservicesintendtoaccomplishsimilargoals.Thisissimilartotype-checking,whichgreatlyreducesprogrammingmistakes. ix

PAGE 10

Thevisionofthistechnologyisthat,inthefuture,youwouldbuyanactuator,orsoftwareservice,thatcontainsastandardizeddescriptionofitsintentionaleectontheworld.Withthisdescription,thehousecanusetheservicetoavoidundesirablecontexts.ThisdirectlytiesinwithourSelf-SensingSpacesandSmartPlugwork. x

PAGE 11

CHAPTER1INTRODUCTIONANDMOTIVATIONInterestintheareaofubiquitouscomputinghasgrowninthelastfewyears.Theideabehindubiquitouscomputingisthatthetechnologyshouldbecalm[ 1 ],meaningthatmanycomputersareavailablethroughoutthephysicalenvironment,makingthemeectivelyinvisibletotheuser[ 2 ].Henceubiquitouscomputingissometimescalledpervasivecomputing.Itisconsideredthethirdwaveofcomputing.Ubiquitouscomputingischaracterizedbythe"anywhere,anytime,anymeans"paradigm.Anywhere,atanytime,andbyanymeans,ausershouldbeabletoperformcomputationsthathelptheusertoaccomplishhisorhergoals.Forthistohappenmanydierenttechnologiescometogether.Hardwaremustprovideinteractionwiththeenvironmentbluetooth,GPS,etc.,andsoftwareisneededthatinteractsandcoordinateswiththehardwareOSGi,Jini,CORBA,SOAP,WSDL,etc.[ 3 4 5 ].Weconsiderasmartspacetobeanambient[ 6 ],inthesensethatthereisaboundarythatdetermineswhatispartofthesmartspace,andwhatisnot.Insidethesmartspace,computationstakeplace,toassisttheusersofthespace.Apervasivespaceconsistsofacollectionofdevicesandsoftwarethatcontrolsthesedevices.Devicesthatsensetheenvironmentarecalledsensors.Devicesthatcanchangetheenvironmentarecalledactuators.Sensorssenseaparticularvalueinaparticulardomain,andprovideinformationonaverydetailedlevel.Atemperaturesensormighttellusthatitis95F,oralightsensormighttellusthatthereis10,000luxoflightcomingthroughthewindow.However,wearegenerallynotinterestedinthedirectsensor 1

PAGE 12

2 values,butratherinahigh-leveldescriptionofthestate.Wewanttoknowthattheweatheris"hot"and"sunny"outside.Thestates"hot"and"sunny"encompassarangeoftemperatureandluminescencevalues.Hard-codingbehaviorforeachpossiblecombinationofrelevantsensorvaluesisdiculttoimplement,diculttodebug,anddiculttoextend.Workingwithgeneralizationsismucheasier.Actuatorsarephysicaldeviceswithwhichwecaninteract.Anactuatoriscapableofchangingthestateoftheworld.Sensors,inturn,mayobservetheeectofanactuator.Alightsensormayobservethatthesmarthouseortheresidentturnedonalamp.Basedontheobservedstateoftheworld,thehouseortheresidentmightdecidetoactivateanactuator.Mostresearchprojectsthatinvolvedubiquitouscomputinghavebeenpilotprojectsthatshowthatpervasivecomputingisusable.TheActiveBadge[ 7 ]systemusedbadgesthattransmittedIR-signalstotrackthelocationofvariouspersons.Thislocationinformationwasthenusedtoroutecallsforpersonstothenearestphone. 1.1 LimitationsofFirst-GenerationSpacesThemajorityofpervasivecomputingresearchsofarhasfocusedonsystemintegration.Mostofthesearepilotprojectsdemonstratingthatpervasivecomputingisuseableoverview[ 8 ].Ingeneral,thesepilotprojectsrepresentad-hoc,specializedsolutionsthatarenoteasytoreplicate.Unfortunately,manyoftheserst-generationpervasivecomputingsystemslacktheabilitytoevolveasnewtechnologiesemergeorasanapplicationdomainmatures.Integratingnumerousheterogeneouselementsismostlyamanual,adhocprocess.Insertinganewelementrequiresresearchingitscharacteristicsandoperation,determininghowtocongureandintegrateit,andtediouslyand

PAGE 13

3 repeatedlytestingtoavoidcausingconictsorindeterminatebehaviorintheoverallsystem.Integrationofnewdevicesdoesnotscalewellwiththisapproach.Intheworst-casescenariotheaddingofanewdevicemeansreconguringnexistingdevices.Theenvironmentsareclosed,limitingdevelopmentorextensiontotheoriginalavailabledevicesorsoftwareentities. 1.2 RequirementsforHardwareIntegrationThedevicesthemselvesmustbeabletointegrateandadapttotherelevantcircumstancesinthespace.Fordevicestobeabletointegratetheremustbeauniformwaytointeractwiththedevices.Thisuniformwayofinteractionisaccomplishedbyamiddlewarelayerthatcreatesabstractionsforthevariousavailabledevices.Heterogeneousdevicescannowbeaccessedinauniformway.Therequirementsforthemiddlewarelayerarasefollws, Open: Awiderangeofdiversityinherentinthefuturepervasivecomputingenvironments,theopennessisoneofkeyrequirements.Theenvironmentismadeupoftinysensors,mobiledevices,andfull-edgedcomputersfromdiversesources.Therefore,themiddlewarearchitecturemustbeopenandexibletoembraceavarietyofentitieswithoutanyspecialfavortowardsparticularparticipantsortargetdomains. Extensible: Themiddlewareshouldbeabletosupportadynamicbuild-upofmiddlewareitself,newmiddlewarecomponentscanbeincorporated,componentscanbeupgradedorreplacedandunnecessarycomponentscanberemovedfromthemiddleware.Allthesechangesmustbepossiblewithoutrequiringdown-timeforthewholemiddleware.Themiddlewareitselfevolvesovertime,anditiscancopewithnewtechnologiesandrequirements. Adaptive: Themiddlewareshouldbeabletoadapttothechangingenvironments.Inotherwords,themiddlewareshouldrecongureitself

PAGE 14

4 inaccordancewithchangesinthespacethroughtheabovecomponentaddition,upgrade,andreplacement;andshouldprovideamechanismbywhichapplicationscanadaptthemselvestothesechanges. Self-integrative: Themiddlewareshouldenableajoiningentitytoexplorethemiddlewareenvironmentandsupportamechanismbywhichitcanparticipateinthemiddleware.Inotherwords,thezero-congurationstylesupportisnecessarytoautomatethejoiningprocess. 1.3 ProgrammabilityofaSpaceThemiddlewarelayeraloneisnotsucient.Thewholeaimofthisexerciseistoprovideaprogrammingmodelforsoftwareengineers.Theprogrammingmodeldetermineshowengineerswillinteractanddevelopsoftwareforthemiddlewarelayer.Aprogrammingmodelallowscomplexsystemstobeunderstoodandtheirbehaviorpredictedwithinthescopeofthemodel.OntopoftheprogrammingmodelweaimtobuildaninteractiveorintegrateddevelopmentenvironmentIDE.TheIDEneededtobeasystemforsupportingtheprocessofwritingsoftwareforpervasivespace.Suchasystemmayincludeasyntax-directededitor,graphicaltoolsforprogramentry,andintegratedsupportforcompilingandrunningtheprogramandrelatingcompilationerrorsbacktothesource.Thegoalwastogiveprogrammersaclearmodelandvisualtoolsforprogrammingtheactualpervasivespace. 1.4 SafetyofSpacesIntraditionalcomputingsystems,suchasthedesktoppc,thereishardlyanyinteractionwithphysicaldevices.Ingeneraltherearefewinputdevices,andfewoutputdevicesI/Odevices.Amonitor,speakers,keyboard,andmousesumsupatraditionaldesktopsystem.TheproblemofmodelingI/Odevicesisthattheyhavesideeects:specicallytheychangethestateofthesystem,unlikereferentiallytransparentexpressions.

PAGE 15

5 Furthermore,I/Ooperationsarenotguaranteedtosucceed.Failurescanoccur,anddealingwiththesefailuresisawkward.Modernprogramminglanguagesprovideforexceptionstodealwiththeseexceptionalcases.SincefewI/Odevicesaecttheactualworld,thereisnoseriousconcernaboutconictingeectsonthephysicalworld.However,assoonaswestarttointroducemoredevicesinaspacecontrolledbycomputers,thisdoesbecomeanissue.Adisastrousexamplewouldbeacomputerthatdecidestoturnothesprinklersystemincaseofare.Softwarecomponentsareregularlyinconictwithoneanother.AverywellknownrecentexampleisthattheinstallationofNetscape8willbreakInternetExplorer.Usersacceptthesesoftwareawswithlittlecomplaints.Usersareunlikelytoacceptthesprinklererror.Unexpectedbehavior,orsoftwareerrors,arefarlessacceptableinpervasivespaces,especiallywhentheynegativelyaectsthequalityoflife.Apervasivespaceissafeifwearecertainthatthespacewillnevermovetoanundesirablestatebecauseofanautomatedinvocationofanactuator.Thecomputershouldneverperformanactionthatleadstoanundesirablestate.Sinceacomputercanonlychangethestateofthespaceusingactuatorswecanmakethefollowingdivisionsinsafety: Non-pervasive: Aspacethatdoesnotcontainanycomputationaldevicescontrollingtheenvironment.Everychangeinthestateoftheenvironmentisbecauseoftotheactivityofalivingentity. ObservationalPervasiveness: Aspacethatonlycontainssensors.Thesensorsprovideinformationaboutwhatistakingplaceinsidethespace,butnothingwillbedonetoalterthestateofthespace. GuardedPervasiveness: Apartfromsensorsthespacecontainsactuatorsthatcanchangethestateofthespace.Theactuatorsarelimitedasfollows:

PAGE 16

6 { Iftheactuatorfailstooperate,thespacedoesnotchange.Anexampleisalamp.Ifthelight-bulbisbroken,turningonthelampewillnotchangethestateofthespace. { Thespacecanaccuratelypredictthenextstatebeforethisstatearises.Forexampleifweturnonthelamp,wecanpredictthattherewillbelight. { Thespacecanderiveifaservicewillactivateanactuator.Everysoftwarecomponentiscapableofreportingwhichactuatoritwillactivateandunderwhichcircumstances. UnguardedPervasiveness: Thespacecontainssensorsaswellasactuators.Howeverthespaceisnotabletodeterminewhetherornotaservicewillinvokeanactuator.Thespaceisnotalwayscapableofpredictingthenextstateofthespace.Thisdivisionhasconsequenceofthepowerofexpressionthatthelanguageweareusinghas.Therequirementtopredictthepossibleoutcomeofanactionwithinalimitedamountoftimehasimplicationsfortheexpressivenessoftheprogramminglanguage.IfittakesOntodeterminethenextstateofthespaceitisunlikelythespacewillbecapabletopredictthenextstateofthespaceinatimelyfashion. Figure1{1:Safetyversusprogrammability

PAGE 17

7 Toguaranteesafetyofthepervasivespaceweconsideraprogrammingmodelthatisexpressiveenoughtowriteprograms,yetrestrictedsowecanguaranteethatstateofthespaceisnotundesirable. 1.5 BehaviorversusInformationOurapproachtoguaranteesafetyisbymakinguseofdescriptionsofthevariousavailablesoftwareandhardwarecomponents.Wedescribecomponentsusingatemporalontology.Thistemporalontologyisusedtointerpretthestateofthespaceandtodescribehowservicechangethestateofthespace.Weseparatethedevelopmentprocessofsoftwareintotwophases.Therstphasedealswithtraditionalsoftwareengineering.Theotherphasedealswithknowledgeengineering.Inthesoftwareengineeringphasewedescribebehaviorwhereasintheknowledgeengineeringphasewedescribeinformationofrelevance. 1.6 GoalsTheaimofourresearchwastoestablishaprogrammingmodelthatcanbeusedbydevelopersthatbuildpervasiveapplications.Currentlythereislittletonosupportforprogrammingpervasivespaces.Theareaisstillinthestagewhereeverysolutionisad-hoc.Theprogrammingmodelweintroduceisbasedontherelationshipbetweensensors,actuatorsandsoftware.Bymakingthisrelationshipexplicitwecanderiveaprogrammingmodelgearedtowardsdescribingknowledgeanddeninggoals.Agoalcanbeaccomplishedbyinvokingaseriesofactuators.Italsoallowsustoreasonbeforehandabouttheeectoftheinvocationofasetofservices.Thisinturnhelpsadeveloperdeterminewhethertwoservicesintendtoaccomplishsimilargoals.Thisissimilartotype-checking,whichgreatlyreducesprogrammingmistakes.

PAGE 18

CHAPTER2RELATEDWORKInrecentyearsubiquitouscomputinghasreceivedanincreasingamountofattentionintheacademiccommunity.Herewewillreviewsomeoftheworkthathasreceivedalotofattentionoverthelastdecade. 2.1 SmartSpacesThePARCTAB[ 9 ]systemconsistsofpalm-sizedmobilecomputersthatcancommunicatewirelesslythroughinfraredtransceiverstoworkstation-basedapplications.Thesystemprovidedlocationinformationtotheuser,helpedtondresourcesandactedasaremotecontrolforvariousdevices.TheActiveBadge[ 7 ]isasystemthatkeepstrackofthelocationofapersonusingbadgesthattransmittedanIR-signal.Thetelephonereceptionistcouldndoutwhereapersonwasanddirectthecalltoanappropriatephone.ManyconsiderthePARCTABandActiveBadgeprojectstobetherstexamplesofpervasivecomputing.Theseprojectsshowedhowcomputationcanbecalmly"integratedintheenvironment.Microsoft'sEasylivingproject[ 10 ]focusesonhomeandworkenvironment.Theeasylivingroomisawareofthelocationofpeopleintheroomandusesthisinformationforaccesstocomputationaldevices.Thespacerecognizesusersandgesturesandusesthisinformationtoadjustthestateoftheroomaccordingly.Pearl[ 11 ]isanursingrobotthatassistselderlywithmildcognitiveimpairments.Ithasanautomatictrackinganddetectionsystemforpersons.Thesystemremindstheelderofeventsandcanguidethemthroughtheenvironment.TheRoomwareandi-Land[ 12 13 ]projectsaimtointegrateinformationtechnologyintoroomelementsas,walls,doors,andfurniture.Roomware 8

PAGE 19

9 componentsareinteractiveandnetworked;someofthemaremobileduetoindependentpowersupplyandwirelessnetworks,andareprovidedwithsensingtechnology.Thefocusontheseprojectsseemtoleanmoretowardsthehardwareaspectofpervasivecomputing.Contextawarecomputingisacomputingparadigminwhichapplicationscandiscoverandtakeadvantageofcontextualinformation.Thiscouldbetemperature,locationoftheuser,activityoftheuser,etc.Thedenitionofcontextisrathervagueandvariousresearchersgivedierentdenitionsofcontext.Inthischapterwewillexaminethevariousdenitionsanddenethekeyingredientsofcontextawareness. 2.1.1 Context-AwareComputingContextisaconceptthathasbeenhardtograsp.Ingeneralwecanconsiderthatcontextusesexternalinformationtoidentifythecurrentmeaningofanobject.Inlanguageforexamplecontextisusedtodisambiguatecertainwords[ 14 ],whereasinvisionrecognitionitisusedtollinblanksininterpretation[ 15 ].Intheareaofubiquitouscomputingtherearemanydierentdenitionsinuse.Earlyresearchersintheelddenecontextbythefollowingcharacteristics:auser'slocation,environment,identityandtime[ 16 17 ].Thisviewoncontextisratherapplicationspecic.Abowdetal,[ 18 ]denedcontextasfollows: Contextisanyinformationthatcanbeusedtocharacterizethesituationofanentity.Anentityisaperson,place,orobjectthatisconsideredrelevanttotheinteractionbetweenauserandanapplication,includingtheuserandapplicationthemselves.SimilarlyChenandKotz[ 8 ]denedcontextas: Thesetofenvironmentalstatesandsettingsthateitherdeterminesanapplication'sbehaviororinwhichanapplicationeventoccursthatisinterestingtotheuser.

PAGE 20

10 Theyalsomakeadistinctionbetweenactiveandpassivecontexts,wheretherstinuencesthebehaviorandthesecondisrelevant,butnotcritical.Inthelastdecadewehaveseenvariousprojectsthattaketherststepsatcontextawarecomputingintheeldofpervasivecomputing[ 19 20 ].Manyoftheseapplicationswerepilotprojectsthatdemonstratedtheuseofcontextandusedtoinvestigatetheusage,limitsandbenetsofcontextawarecomputing.Duetothesuccessoftheseapplicationsaneedaroseforaframeworkforcontextawarecomputing.Thecontexttoolkit[ 21 22 ]isajavatoolkittohataddressesthedistinctionbetweencontextanduserinput.Thecontextconsistsofthreeabstractions:widgets,aggregatorsandinterpreters.Contextwidgetsencapsulateinformationaboutasinglepieceofcontext,aggregatorscombineasetofwidgetstogethertoprovidehigherlevelwidgets"andinterpretersinterpretbothofthese.AninterpreterforexamplecanusetheidentityandlocationwidgettoderivethatDr.Helalisinhisoce".Theaimofthetoolkitistohidethecomplexityofobtainingsensorinformation.Thecontexttoolkithasprovenitsvalueinvariousapplicationsthathavebeenbuiltwithit[ 23 24 25 ].iQueue[ 26 ]andiQL[ 27 ]areaprogrammingmodelandlanguageforcomposinghigherleveldatafromlow-levelrawdata.ThedierencebetweeniQueueandiQListhattherstoneisanimplementationofthemodelinjava,whereasthelatterisaspecicprogramminglanguageresemblingafunctionallanguage.Theprogrammingmodelisbaseduponsocalledcomposersthatcontainacurrentvaluecomputedfrominputvalues.Thesevaluesintermstemfromvariousdatasourcesi.e.,sensors,orothercomposers.Theruntimesystemthenadvertisesthesecomposerstoexternalsources.

PAGE 21

11 Everysourcecaneitheractpassively,producingdataonlyonrequest,oractivelyproducingdatawhenevernewdataisavailable.Usingthesecomposerswecanconstructanacyclicdi-graph,oftenreferredtoascontextgraph,wherethenodescontainfunctionsthatproducesvaluesforthenodeshigherupinthegraph.SimilartotheapproachdescribedaboveistheSolarframework[ 28 29 30 ].Solarallowsresourcetoadvertisecontextsensitivenamesandforapplicationstomakecontext-sensitivenamequeries.Themainaimoftheframeworksisthatresourcescanadvertisetheirexistence,thatotherscanndtheresourcesandthatcontext-awareapplicationsmayindicatehowtoderivetheirdesiredcontextfromthesesources.SolarprovidesasimilarmechanismasiQLforthederivationofhigh-leveldatafromlowlevelsources.Ontopofthistheyprovideaqueryingmechanismforretrievingcontextinformation.DFuse[ 31 ]isanotherexampleofatechnologythatallowstheconstructionandevaluationofacontextgraph.TheDFusearchitectureisgearedtowardsmobiledevicesoptimizingitforpowerconsumption. 2.1.2 MiddlewareArchitecturesGaiaOS[ 32 33 ]isacomponentbasedmiddlewareoperatingsystemrunningontopofanexistingoperatingsystem.TheGaiaOSprovidesasetofbasicservices,suchasdiscovery,security,aswellasanapplicationmodel.Theapplicationmodelprovidesamechanimstobuildapplicationsforubiquitouscomputingscenarios.GaiaOSisbasedupontheModel-View-Controller[ 34 ]paradigm.However,insteadofthetraditionalnotionofacontrollergaiamakesuseofacomponentadapterthatisresponsibleforadaptingtheformatofthemodeldatatoanarbitraryoutputdevice.Gaiaomakesuseofascriptinglanguage,calledlua[ 35 ]todoservicecompositionandeventhandling.Gaiaisintendedtobeageneralcomputationalenvironment.

PAGE 22

12 TheSOCAMarchitecture[ 36 ]isamiddlewarelayerthatmakesuseofontologiesandpredicates.Thereisanontologydescribingthedomainofinterest.Bymakinguseofrulebasedreasoningwecanthencreateasetofrulestoinferthestatusofaanentityofinterest.Theirresearchshowsthatontologiesareusablebutrequiresomecomputationpowerandhencearenotsuitableforsmallerdevices.TheCoBraarchitecticture[ 37 ]isabrokercenteragentarchitecture.Atthecoreisacontextbrokerthatbuildsandupdatesasharedcontextmodelthatismadeavailabletoappropriateagentsandservices.TheMavHomeproject[ 38 39 ]viewsthesmarthomeasanintelligentagentthatperceivesitsenvironmentthroughtheuseofsensors,andcanactupontheenvironmentthroughtheuseofactuators.Thehomehascertainoverallgoals,suchasminimizingthecostofmaintainingthehomeandmaximizingthecomfortofitsinhabitants.Inordertomeetthesegoals,thehousemustbeabletoreasonaboutandadapttoprovidedinformation.Theirapproachisbasedonmachinelearningandoptimizationtechniques. 2.2 OntologiesandSemanticWebMostoftheinformationthatisaccessiblethroughtheworldwidewebisinthehtmlformat.Thisformatisgearedtowardsthelayoutofinformationonascreen.Itdoesnotcontaininformationaboutthemeaningofthedocumentthatisbeingdisplayed.Thisiscurrentlyabigobstacleinretrievinginformationontheweb.Mucheortisbeingputindevelopingthesocalledsemanticweb".Accordingto[ 40 ]: TheSemanticWebisanextensionofthecurrentwebinwhichinformationisgivenwell-denedmeaning,betterenablingcomputersandpeopletoworkincooperation."Thevisionisthatweassociatemeaningwithdocumentsinsuchawaythatitcanbeprocessedbymachines.Inordertoaccomplishthisweneedamechanism

PAGE 23

13 todescribeinformation.Thiscanbedonebyassociatingmetainformationwiththedocumentsthatwestore,orbyprovidinganontologythatgivesmeaningoftheconceptsusedinaparticulardomain.Wearetryingtocreateamodeloftheworldinsymbolicstructuresthatcanbeprocessedbyacomputer.Wecallthisaconceptualmodeloftheworld.Conceptualmodelsarewellknowintheeldofcomputerscience,rangingfromtheentityrelationshipmodel[ 41 ]toUML[ 42 ].Theseconceptualmodelsprovideabstractionmechanismsthatresultinastructuredinformationmodel[ 43 ].ThesemanticwebbuildsextensivelyonXMLasimpleextensiblemarkuplanguage,RDFanXMLlanguagetodescriberesourcesandOWLaRDFlanguagetodescribeontologies.Inthefollowingsubsectionswewillinvestigatethesevarioustechnologies.WeassumethereaderisfamiliarwithXML[ 44 ]. 2.2.1 ResourceDescriptionFrameworkTheResourceDescriptionFramework[ 45 ]RDFisalanguageforrepresentinginformationaboutresourcesintheWorldWideWeb.Bygeneralizingtheconceptofa"Webresource",RDFcanalsobeusedtorepresentinformationaboutthingsthatcanbeidentiedontheWeb,evenwhentheycannotbedirectlyretrievedontheWeb.TheideabehindRDFisthatwecandescriberesourcesbymakingstatementsabouttheseresources.Thestatementsthatwemakeconsistsofpropertieswithvaluesthatdescribeaparticularresource.Thisisdonebyassociatingtwoobjectstogetherwithapredicate.Thepartthatwearedescribingiscalledthesubject.Itisassociatedwithanotherobjectthroughapredicate,thatdescribesthesubject.TakeforexamplethefollowingEnglishsentence: http://www.cise.u.edu/people/ejansenhasacreatorErwinJansenWecanseethefollowingrelationships: thesubjectistheURLhttp://www.cise.u.edu/people/ejansen

PAGE 24

14 thepredicateisthewordcreator" theobjectisthephraseErwinJansen"RDFcanbeusedtodescribeanyrelationshipwewantusingtheappropriatepredicate.ThesedescriptionsaregiveninanXMLlanguage,andhenceareeasilyprocessedbycomputers.HoweverthefreedomRDFgivesintroducesanewproblem.Howarewegoingtopickappropriatepredicatesandhowdoweinterpretthesepredicates.Anyonecanmakearbitrarypredicates,butwedonothaveanycomputationalguaranteeswhatsoeverthatweareabletodeduceanyvaluableinformationfromourdescriptions.Drawingconclusionsfromasetofrdfstatementsmightnotbefeasibleinalimitedamountoftime.AlthoughRDFisagoodstartfordescribingresources,itleavesuswithtoomuchfreedom.Weneedawayofdescribingknowledgewithbettercomputationalguarantees,suchasadescriptionlogic. 2.2.2 DescribingDomainKnowledgeAmechanismfordescribingknowledgearesocalleddescriptionlogics[ 46 ].Whichweshallbrieydiscusshere.Descriptionlogicsareknowledgerepresentationlanguagestailoredforexpressingknowledgeaboutconceptsandconcepthierarchies.TheyareusuallygivenaTarskistyledeclarativesemantics,whichallowsthemtobeseenassub-languagesofpredicatelogic.Theyareconsideredanimportantformalismunifyingandgivingalogicalbasistothewellknowntraditionsofsemanticnetworks,object-orientedrepresentations,semanticdatamodels,andtypesystems.Thebasicbuildingblocksareconcepts,rolesandindividuals.Conceptsdescribethecommonpropertiesofacollectionofindividualsandcanbeconsideredasunarypredicateswhichareinterpretedassetsofobjects.Rolesareinterpreted

PAGE 25

15 Figure2{1:Knowledgenetwork asbinaryrelationsbetweenobjects.Forexampleingure 2{1 thereistheroleofaparent,expressedthroughthehasChildrelationship.Eachdescriptionlogicdenesalsoanumberoflanguageconstructssuchasintersection,union,rolequantication,etc.thatcanbeusedtodenenewconceptsandroles.Wecouldexpresstheconceptofafatherasbeingaparentthatisnotawoman.Descriptionlogicscanbetranslatedintoasubsetrstorderpredicatelogics.ForexampletheexpressionPersonandWomancanbetranslatedintoPersonx^Womanx,wherexisavariablethatrangesoveralltheindividualsintheinterpretationdomainandCxistrueforallxthatbelongtocontextC.NotethatrstorderlogicFOLisnotdecidable,butthatdescriptionlogicsareasubsetoffolthatisdecidable.Themainreasoningtasksareclassicationandsatisability,subsumptionandinstancechecking.Subsumptionrepresentstheis-arelation.Classicationisthecomputationofaconcepthierarchybasedonsubsumption.Thereisatradeowemustmakebetweentheexpressivenessofourdescriptionlogicandthetimecomplexityofderivingknowledge.Themoreexpressiveour

PAGE 26

16 languageis,themoretimeitwilltaketocomputewhetherornotasentenceisvalid[ 47 ]. 2.2.3 DescriptionLogicsandtheWorld-WideWebOWL[ 48 ]isadescriptionlogicthatbasedonRDF.UsingOWLwecandescribeanontology.Therearethreeversionsofowl,eachwithdierentcomputationalguarantees. OWLLite: Owlliteisprimarilyusedfordeniningaclassicationhierarchyandsimpleconstraints.Forexample,whileitsupportscardinalityconstraints,itonlypermitscardinalityvaluesof0or1.OwlLitehasalowerformalcomplexitythanOWLDL. OWLDL: Hasmaximumexpressivenesswhileretainingcomputationalcompletenessallconclusionsareguaranteedtobecomputableanddecidabilityallcomputationswillnishinnitetime.OWLDLincludesallOWLlanguageconstructs,buttheycanbeusedonlyundercertainrestrictions.OWLDLisadescriptionlogic. OWLFull: OWLFullismeantforuserswhowantmaximumexpressivenessandthesyntacticfreedomofRDFwithnocomputationalguarantees.OWLFullallowsanontologytoaugmentthemeaningofthepre-denedRDForOWLvocabulary.ItisunlikelythatanyreasoningsoftwarewillbeabletosupportcompletereasoningforeveryfeatureofOWLFull. 2.3 TemporalLogicInlogic,thetermtemporallogicisusedtodescribeanysystemofrulesandsymbolismforrepresenting,andreasoningabout,propositionsqualiedintermsoftime.Itissometimesalsousedtorefertotenselogic,aparticularmodallogic-basedsystemoftemporallogicintroducedbyArthurPriorinthe1960s.Foranintroductiontotenselogicsee[ 49 ].

PAGE 27

17 AnexamplewouldbethetemporalstatementErwiniswritinghisdissertation".Althoughtheinterpretation,ormeaning,ofthissentencedoesnotchangeovertimethetruthvaluewillmostdenitelyvaryastimeprogresses.Intemporallogicthetruthvaluecanvaryovertime.Temporallogiccanbeusedtoreasonabouthowasystembehavesovertime.Therearethreevariantsthathavefoundwidespreadusage: 2.3.1 IntervalTemporalLogicIntervalTemporalLogicITLisaexiblenotationforbothpropositionalandrst-orderreasoningaboutperiodsoftimefoundindescriptionsofhardwareandsoftwaresystems.Unlikemosttemporallogics,ITLcanhandlebothsequentialandparallelcompositionandoerspowerfulandextensiblespecicationandprooftechniquesforreasoningaboutpropertiesinvolvingsafety,livenessandprojectedtime[ 50 ].SinceITLisbasedonintervalsandtheirsequences,itispossibletodescribebothconcurrentandserialbehaviorsbyspecifyingbehaviorsinsideintervalsandsequencesamongthem.UnfortunatelyafullsetofITLdoesnothaveadecisionprocedure.Howeverasubsetdoes. 2.3.2 LinearTemporalLogicLinearTemporalLogicLTLisalogicthatextendspropositionallogicwithtwooperatorsthatdealwithtime.Theseoperatorsaretheunarynextandbinaryuntiloperator.Thenextoperatorspeciesthataformulawillholdinthenextstate,whereastheuntiloperatorexpressesthataformulaisatleasttrueuntiltheotherformulabecomestrue.Fromtheseonecanderiveoperatorsaseventuallyandalways.LTLdealswiththeexistenceofonlyonepossiblefuturepath.AnLTLformulacanbetranslatedintoadeterministicnitestateautomatonDFA[ 51 ].ThisapproachhasbeenusedtodeterminewhetherornottheLTLformulaissatisable.TheLTLformulaistranslatedintoanequivalentDFA

PAGE 28

18 andoneveriesifthisDFAacceptstheemptylanguage.Ifso,thereisnomodelsatisfyingtheformula.ThegoodnewsisthattheLTLproblemisdecidable,thenegativeresultisthatitisNPcomplete,thisisevidentsince3-satiscontainedinLTL.ThisisreectedinastateexplosionthatoccursduringthistranslationfromanLTLformulatoaDFA[ 52 53 ],makingitveryexpensivetoestablishthiscorrectness.Howevervariousvericationtools,suchasMaude[ 54 ]andSpin[ 55 ],arecapableofverifyingthesatisabilityofnotoverlycomplexLTLformulas.AlthoughtheproblemisNPcompletethealgorithmsusedhavebeenproventoworkwellformanypracticalproblems. 2.3.3 ComputationalTreeLogicComputationalTreeLogic[ 56 ]CTLcanbeseenasanextensionofLTL.Apartfromtemporaloperatorswealsointroduceunarypathoperatorsallandexists.Thealloperatorexpressesthatforeverypossiblepathinthefuturetheformulaholds,whereastheexistsoperatorexpressesthatatleastonepathexistsforwhichtheformulaholds.Thisextendsthenotionoftimewithasetofpossiblebranchesoverpossiblefutures.SurprisinglythesatisabilityproblemofaCTLformulaisdecidableaswell[ 57 ].

PAGE 29

CHAPTER3PROBLEMDESCRIPTIONResearchgroupsinbothacademiaandindustryhavedevelopedprototypesystemstodemonstratethebenetsofpervasivecomputinginvariousapplicationdomains.Theseprojectshavetypicallyfocusedonbasicsystemintegrationinterconnectingsensors,actuators,computers,andotherdevicesintheenvironment.Unfortunately,manyrst-generationpervasivecomputingsystemslacktheabilitytoevolveasnewtechnologiesemergeorasanapplicationdomainmatures.Integratingnumerousheterogeneouselementsismostlyamanual,adhocprocess.Insertinganewelementrequiresresearchingitscharacteristicsandoperation,determininghowtocongureandintegrateit,andtediousandrepeatedtestingtoavoidcausingconictsorindeterminatebehaviorintheoverallsystem.Theenvironmentsarealsoclosed,limitingdevelopmentorextensiontotheoriginalimplementers. 3.1 NonScalableIntegrationAnypervasivesystemisboundtoconsistofnumerousheterogeneouselementsthatrequireintegration.Unfortunately,thesystemintegrationtaskitself,whichismostlymanualandadhoc,usuallylacksscalability.Theresalearningcurveassociatedwitheveryelementintermsofrstunderstandingitscharacteristicsandoperationsandthendetermininghowbesttocongureandintegrateit.Also,everytimeyouinsertanewelementintothespace,theresthepossibilityofconictsoruncertainbehaviorintheoverallsystem.Thus,tedious,repeatedtestingisrequired,whichfurtherslowstheintegrationprocess.Considera 19

PAGE 30

20 temperaturesensorthatneedstobeconnectedtoanembeddedJavaprogramtoperiodicallyreportarefrigeratedtruckstemperature. 3.2 ClosedWorldAssumptionAnotherproblemisthatanintegratedenvironmentisarelativelyclosedsystemitsnotparticularlyopentoextensionsorexpansion,exceptperhapsaccidentally.Itstightlycoupledtoacombinationoftechnologiesthathappenedtobeavailableatdevelopmenttime.Itsthusdicultifnotimpossibletoaddnewtechnologies,sensors,anddevicesaftersystemintegrationiscomplete.Anintegratedenvironmentisalsoclosedandrestrictedtoonlyafewparticipantsthedesigners,systemintegrators,andusers.Theresnoeasywaytoletathirdpartyparticipate.Forexample,anenergy-andutility-ecientsmarthomedevelopedin2005mightnotbecompatiblewithautility-savingsprinklersystemdevelopedin2006byathird-partyvendor. 3.3 Fixed-PointConceptsAlsoproblematicisthefactthatourexperienceinbuildingintegratedenvironmentsislimitedbythesetofconceptsweknowatthetimeofdevelopment.Thismightsoundlikeanalways-truestatementregardlessofwhetherweredoingpervasive,mobile,ordistributedcomputing,butitsespeciallytroublinginpervasivecomputing.Takesmarthomes,forexample.UnlikeNokiaphones,youcantupgradeandreplacethemeverysixmonths.Oncebuiltforaspecicgoalsuchastoassisttheelderlyorhandicapped,savepower,orsupportproactivehealthforanentirefamily,thehomewilllikelybeusedfordecadestocome.Thatswhyweneedtoensurethatoursmartspaceswillbecompatiblewithnot-yet-developedconcepts.Thismightnotberealistic,butsmartpervasivespacesareboundtooutlastanyknownsetofpervasivecomputingconcepts.Servicegatewaysandcontextawarenessaretwoexamplesofrecentconceptsthathave

PAGE 31

21 steeplyinuencedhowwethinkofpervasivecomputing.Surelyothernewconceptsareonthehorizon. 3.4 ObjectivesThegoalofourresearchistopresentaprototypemiddlewarelayerandidecapableofremotelybrowsingcurrentavailableentitiesinasmartenvironment,suchassensors,smartappliancesorservices,inasmartspace,providinginformationaboutthecapabilitiesoftheseentities,oeringprogrammingtoolsandassistancetoguidetheimplementationofnewservicesandavoidrestrictions.Wewilladdresstheissuesofenhancedprogrammability,interoperabilityandexceptioncapturing. 3.4.1 EnhancedProgrammabilityOncethecomponentssuchassensors,actuators,andsmartappliances,areinplace,theprogrammershouldbeabletoprogramthesmartspacebypro-activelyorreactivelyspecifyingpredenedbehaviorundervariouscontextsforthesecomponents.Theprogrammingmodelshouldprovideguidanceandwarningsthroughoutthedevelopmentcycle,includingprogramming,debugginganddeploymentphases.Itshouldprovideassistancetoallowprogrammerstofocusonprogrammingthebehaviorofthehouse,notbotheredbytechnicalitiesofwritingbundlesoragents. 3.4.2 InteroperabilityandExtensibilityItiscrucialthattheeectsofthenewlyintroduced,altered,oreliminatedentitiesorservicesbereectedintheprogrammingmodel,andbroughttotheattentionofthesystemdesignerordeveloper.Theprogrammingmodelshouldguaranteethattheintroductionofnewservicesordevicewillnotdisruptthealreadyexistingdevicesorservicesorwillalertthedeveloperandresidentthatthenewservicewillcauseadisruptionandunderwhichcircumstances.

PAGE 32

22 3.4.3 CapabilityofExceptionCapturingThisprogrammingmodelshouldbeabletocapturecontradictoryinstructionsorcontextspecicationsduringtheimplementationprocess.Themodelshouldbeabletocapturedesignawsandconictsatbothdesignandimplementationstagesbeforebeingdeployedtoandactivatedintherealsmarthouseenvironment. 3.5 ApproachThemostprevalent,current,programmingparadigmsdealwithbehaviordescriptions.Whethertheprogramsorapplicationsrunonamainframe,PCorembeddedcomputers,thisparadigmrequiressoftwareengineersorprogrammerstodescribehowasoftwareartifactbehavesbywritingthecodeacceptingagivensetofinputparameters,whiletheimplementationmustfollowasetofsyntacticandsemanticconstraintsspeciedforaspecicprogramminglanguage.Toassistothersinunderstandingwhatthissoftwaredoes,itisusuallyagoodpracticetonamethisartifactmeaningfullysuchasquickSortorcontextInterpreterinsteadofprocedureA.Thereareobviousshortfallswiththisapproach.Thenamingofthesesoftwareartifactsissubjecttointerpretationbythereader,andunlesstracingthrougheverysinglelineofcodeinthisartifact,thereisnowayofknowingwhetheritactuallydeliverswhatitsnameimplies.Inshort,programmersencapsulatethebehaviorsintothesesoftwareartifacts,andbystandersmostlikelywouldtaketheirnamevalueastheexpectedbehavior.Theimplicitnatureofthesedescriptionsofbehaviorbecomesespeciallytroublesomeinpervasivecomputingspaces,sincetheyaremuchmoreopenwithalmostunlimitedpotentialdevicesandoperations.Thefactthatsmartspacescanactuallyalterthestateoftheworldisevenmoreunnervingifprogrammerscanonlyguesswhataparticularsoftwareartifactcanandwilldobyjustlookingatitsname.

PAGE 33

23 Makingexistingcomponentsawareofnewlyintroducedcomponentsisachallengebyitself.Forexistingcomponentstounderstandthecapabilitiesofthesenewcomponentsisafurtherchallenge.Thus,itisonlynaturaltondtheneedtodescribetheeectsoftheinvocationonaparticularcomponent.Itwouldthenallowreasoningaboutthebehaviorofthenewcomponent.Thedescriptionofcomponentsshouldusetermsthatarecommonlyunderstood,inessence.Anontologythatisagreeduponiskey.Contextdrivenapproachisourattempttomakeknowledgeexplicit.Bydescribingpossiblecontextsinasmarthouseusingstandardontology,theruntimesystem,aswellasanybystanders,cannowunambiguouslyidentifywhichcontextsarecurrentlyineect.Bydeningwhichactionstotakebasedonwhatthecurrentcontextsare,theknowledgeofthebehaviorofthesystemismadeexplicit,incontrasttobeingimplicitintraditionalprogramming.Thisexplicitnessisimportantforseveralreasonsinanopenandconstantchangingsystemsuchasasmartspace.First,theentitiessuchassensorsandactuators,bothnewandexisting,behavebasedontheexplicitlydenedbehaviorincontextgraphs.Thusnoguessingisnecessarywhenitcomestocooperation,Second,sincethereisnoambiguityinwhatthecurrenteectivecontextsare,andallpotentialactionsareexplicitlydened,conictingbehaviorsandimpermissiblecontextscanbeeasilychecked.Weaddressthenon-scalabilityandclosedworldissuebyexplicitlydescribingwhatadeviceorserviceiscapableof.Thisdescriptionassuresthatthereisnosecondguessingontheprogrammerspart.Ifaserviceordeviceviolatesitsdescriptionitcanbedetectedimmediatelyandappropriateactionscanbeundertaken,

PAGE 34

24 Theseparationofthisknowledgedenitionandtheavailabilityoftheentitiesinsmarthousesalsogreatlyenhanceitscapabilitytoadapttoeverchangingnatureofopensmartspaceshenceaddressingourthirdissueofxedpointconcepts. 3.5.1 KnowledgeEngineeringKnowledgeengineeringisconcernedwiththedenitionofcontextinformation,actuatorsandtherelationshipbetweenthem.Duringthisstagewedenehowwecanderivecontextfromthevarioussensors.Thisusuallymeansthatweconstructataxonomyandidentifyhowtheactuatorscaninuencethevariousavailablesensors.Thisphaseisalsoconcernedwithidentifyingwhichactuatoractivationsarevalidunderwhichcontext.Theaimofthisphaseistoidentifypotentiallydangeroussituationsandtopreventthembyrestrictingcertainoperationsinacontext.Forexample,wecanrestricttheactivationofakitchenburnerwheneverwearenotinthekitchen.Apartfromidentifyingcontext,wealsoneedtodenewhichbehaviorsareassociatedwithacontext.Thisinvolvesidentifyingwhichbehaviorsarestartedandwhichonesareterminateduponenteringandleavingacontext.Thisisalsotheplacewherewecaninstallbehaviorthatwillbeinvokedwheneveranagenttriestoactivateanactuatorthathasbeenrestricted. 3.5.2 SoftwareEngineeringThesoftwareengineeringphase,ontheotherhand,isconcernedwiththedenitionofbehavior.Herewedenehowvarioussoftwareagentsorservicescaninteractwitheachotherandhowtheycanactivateactuators.Themaindierencebetweenanactuatorandagentisthatthelattercanneverchangethephysicalstateoftheworld;itwillneedacooperatingactuatortoaccomplishastatechangeofthephysicalworld.Forexample,aDJagentwouldorganizetheelectronicmusiccollectionofitsowner,butwillinvokeanactuator,suchasthestereo,toactuallyplaythemusic.Theinteractionwithactuatorsisnotguaranteedtosucceed.Ifthe

PAGE 35

25 contextprohibitstheactivationofanactuatortheapplicationwillbenotied.Theapplicationcannowdecidetotakecareoftheproblemitself,orhanditovertothesmartspace.ConsidertheexampleofFigure 3{1 ,ifsomeoneistakingashowerandanotherpersoninthesameapartmentwantstoushthetoilet.Inmostcasesushingthetoiletwillleadtoadecreaseintheamountofcoldwateravailablefortheshower,whichtheninturncanmaketheshowertoohot.Inthisscenario,ushingthetoiletwillleadtoasituationthatisnotallowed.Thesmartspacecannowinvokeahandlerthatreducesthehotwater,preventingtheundesiredsituation. Figure3{1:Negativeinteractionbetweenentities Insummation,ourprogrammingmodelcaptures: Knowledge: Thisconcernsthewritingandconstructionofcontextinformation.Constructionofcontextconsistsofveparts: { Deningconceptualmodelofthespace: Aconceptualmodel,ortaxonomy,isaninterpretationofthespaceintermsofhigherlevelconcepts.Theseconceptscapturethepossiblestatesofthespacebyinterpretingsensorvalues.Forexamplewecandenethataroomcanbewarmorcold.Thisconceptualmodelspeciestheusersunderstandingofthespace. { Deningdesiresofauser: Auserinaspacehascertaindesiresaboutthestateofthespace.Thesedesiresareexpressedintermsoftheconceptual

PAGE 36

26 model.Forexampleausercouldpreferawarmroomoveracoldroomduringwinter,butacoldroomoverawarmoneinsummer. { Deninghandlersforinvalidactivities: Aprogrammercancouplebehaviortotheinvocationofinvalidactuators.Ifthespacedetectsaninconsistentstateofthespaceanappropriatehandlershouldbeinvokedtoeitherinformtheuserortorectifythesituation.Forexampleifthespacedetectsthatthehouseisonreitshouldinformtheauthorities. { Deningactuatorsandrelationshipswithsensors: Theprogrammerneedstoidentifywhichactuatorsareavailableinasmartspaceandspecifywhatkindofrelationthereexistsbetweentheactuatorsandthesensors.Forexampleaheaterhasaneectonaheatsensor.Describingthisrelationallowsthespacetoreasonabouttheeectofactivatingthatactuator. Behavior: Thisistheclassicalsoftwareengineering { Deningbehavior: Aprogrammerimplementscertainbehavior.Thisistheactualimplementationofaservice.Forexampleaclimatecontrolsystemthatiscapableofkeepingtheroomtemperateatacertainsetting. { Associatingbehaviorswithcontext: Aprogrammerneedstoidentifywhichsetsofbehaviorsneedtobeactivatedwhenacontextbecomesactive,inordertosatisfythedesiresoftheuser. 3.6 AdvantagesTheapproachthatwetakehasseveraladvantageswhichwewilldiscusshere. 3.6.1 ExplicitnessThebiggestadvantageofcontextdrivenprogrammingmodelresidesinitsexplicitness.Bydescribingpossiblecontextsinasmarthouseusingdescriptionlogic,themiddlewareruntimeandbystanderscanallunambiguouslyidentifywhich

PAGE 37

27 contextsarecurrentlyactive.Bydeningactionstotakebasedonthecurrentlyactivecontexts,theknowledgeonthebehaviorofsystemisexplicit,contrastingtotheencapsulatedfunctioncallsoftraditionalprogramming.Thisisofgreatimportancesincethestateofthespaceismeaningfulandessentialtoitsresidents. 3.6.2 InteroperabilityandExtensibilityEntitiessuchassensorsandactuators,bothnewandexisting,behavebasedontheexplicitlydenedbehaviorinthedescriptionlogicsonoguessingisnecessarywhenitcomestocollaborationandintegration.Theexplicitnessgreatlypromotesextensibilityandinteroperabilityinanopenandconstantlychangingsystemsuchasapervasivespace.Theseparationoftheknowledgedenitionandtheavailabilityoftheentitiesinthespacegreatlyenhanceitscapabilitytoadapttoitschangingcongurations. 3.6.3 ConictDetectionBecausethereisnoambiguityinidentifyingwhichcontextsareactive,andtheassociatedactionstotakeareexplicitlydened,context-drivenmodelisextremelypowerfulindetectingimpermissiblecontextsandcontradictorybehaviors.Sincecontextsofinterestaredescribedinthedescriptionlogic,itismucheasiertoexplicitlyidentifyimpermissiblecontexts.Descriptionlogicmakestestingforsubsumptionandmembershipstraightforward,hencemakinginheritanceandoverridingastandardpartofbehaviordenition.Inaddition,atomiccontextsalongthesamedimensionaresupposedtobedisjoint.Allthesecharacteristicsmakeitmuchlesspossibletocreateclashingcontradictorybehaviors. 3.6.4 CaptureEnvironmentalEectOneobservationaboutcontext-drivenmodelisthatitisreactive.Insteadofsettingagoalandproactivelytryingtocontrolandcoordinateallentitiestoachievethatgoal,systemsfollowingthismodelwouldpassivelyreacttotheactivecontextsobservedbyexecutingpredenedactionsassociatedwithactivecontexts.

PAGE 38

28 Thesystemhasanideaaboutwhatthemostpreferablecontextsare,andsomeaboutwhereactionstakenmayleadto,butitwouldstayoncourseuntilcontexttransitionstakeplace.Thisreactivenaturecontributestoitsstrongcapabilitytocaptureimpermissiblecontextsandenvironmentaleects. 3.6.5 AutomaticTuningandMachineLearningTheeectofactuatorsisdescribedintermsoftheavailablecontext.Howeveritmightbepossibletobringtheeectanactuatorhasonasensorbymakinguseofmachinelearningtechniques,therebyrenderingtheexplicitdescriptionofanactuatorunnecessary. 3.6.6 ScalabilityUnliketheserviceorientedmodelwhereeachserviceisencapsulatedintoastandalonesoftwareartifact,themiddlewarebundleistheonlybraininthecontext-drivenmodel.Thebundleonlytakesactionduringcontexttransitions,whicharenotexpectedtobefrequentoncethesystemhasstabilized.Thesingle-bundlereactiveapproachwouldfaremuchbetterintermsofscalabilitycomparingtodozensofservicebundlesallproactivelycollecting,calculatingandmanipulatingatthesametime.Anotheraspectofscalabilityariseswhenweareintegratingnewservicesintoaspace.Duetotheexplicitdescriptionoftheservicewecandetermineimmediatelyiftherewillbeaconictwiththeexistingdevices.Theirisnoneedtoresearchthecharacteristicsoftheentitysincethishasbeenstatedexplicitly.

PAGE 39

CHAPTER4OBTAININGINFORMATIONFROMSENSORSApervasivespaceneedstoobtaininformationaboutthephysicalworld.Thisisdonebymakinguseofsensors.Sensorsareactiveobjectsthatprovideinformationaboutaparticulardomain,providingdatatothesystemaboutthecurrentstateofthespace.Asensorcannotchangethestateofthespace{itcanonlyobserve.Atemperaturesensor,forexample,canonlyobservethecurrenttemperature,notinuenceit.Thesystemisabletointerpretthesensordatatogeneratethecontextofthespace.Asensorisanautonomousembeddeddevicewhichhastheabilitytocollaboratewithotherdevicesandprovidesdatareadingsforanapplication.Asensoristypicallybatterypowered,butthisisnotastrictrequirement.InteractionwithasensorisestablishedbymakinguseofeitherRS-232,RS-485,ethernet,bluetoothoranyotherinteractionprotocol.Asensornetworkiscomprisedoftwoormoresensornodesworkingtogethertogatherinformationandprovideoneormoreservicestoanapplication.Thesensornetworkissimplyalogicalgroupingofsensornodes.Dataandcommunicationbetweenthesensornetworkgatewayandthesensornodesistransmittedalongthesensornetwork.ThesensornetworkisnotaphysicalmediumlikeRF,orawire,butratheralogicalinstrument.Thesensornetworkdevelopedatthepervasivecomputinglabintegratesvarioussensorsfromvarioussourcesinauniedway.Thistakesawaytheburdenofconguringandinstallingsensorsonasensortosensorbasis.Thesensorplatformconsistsofahardwarepartandasoftwarepart.Thehardwareusesastackbasedarchitectureallowingtheindividuallayerstobe 29

PAGE 40

30 redesignedandreplacedwithoutaectinganyoftheothercomponents.Thislayeredarchitectureallowscustomizationofthesensornodesforaspecicapplication.Thesensorplatformthathasbeendevelopedcontainsasoftwareframeworkthatcanautomaticallydownloadtherequiredsoftwareusedtointeractwithaspecicsensornodefromthenodeitself.Thissurrogateconceptallowsthenodestobeeasilyupgradedwithoutrequiringsoftwarechangestothesensorgateway.Thesoftwarecannotonlyresideonthenodeitself,butalsoreferencedbyaURLwhichthesensorgatewayaccesses.ThisreferralURLallowsthesensornodedrivertoeasilybeupdated. 4.1 DerivingContextfromSensorsReadingsApervasivespaceneedstoobtaininformationaboutthephysicalworld.Thisisdonebymakinguseofsensors.Sensorsareactiveobjectsthatprovideinformationaboutaparticulardomain,providingdatatothesystemaboutthecurrentstateofthespace.Asensorcannotchangethestateofthespace{itcanonlyobserve.Atemperaturesensor,forexample,canonlyobservethecurrenttemperature,notinuenceit.Asmartspacetypicallycontainsmanyphysicalsensorsthatproduceaconstantstreamofoutputinvariousdomains.Asthisdataisconsumedbythesmartspace,eachphysicalsensorcanbetreatedasafunctionthespacecancalltoobtainavalue. Denition1Sensor. Asensorisafunctionthatproducesanoutputatagiventimeinaparticulardomain.fji:U!DiNoticethatwecanhavemultiplesensorsoperatinginagivendomain.Multiplesensorswillbeindicatedbyf1i;f2i,etc.Sensorsinthesamedomainmayproducedierentvaluesduetodierentlocations,malfunctionorcalibrationissues.Thesmartspacesystemwillberesponsibleforcorrectlyinterpretingdata.

PAGE 41

31 Wewillgroupallavailablesensorstogetheranddenef=Qfitobeasnapshotofallsensorsatapointintime. 4.2 UsingOntologyDealingdirectlywithsensordataisratherawkward.Insteadwewouldliketoworkwithhigherlevelinformationthatdescribesthestateoftheworld.Anaturalchoicefordescribingknowledgeistousedescriptionlogics.Usingadescriptionlogicwecandeneanontologythatdescribesthesmartspace.Wewillrestrictourselvestotaxonomicstructures,andthereforewillhavenoneedtodeneroles.Traditionallytaxonomiesdealwithconcepts.Howeverweusethetermcontext,sincethistermiswidelyusedinthepervasivecomputingcommunity[ 30 58 ].Sincetaxonomicstructuresdonotmakeuseofrelationstheycanbeconsideredequivalenttopropositionallogic.Foranindepthdiscussionondescriptionlogicsandtherelationshipbetweenotherformalismswereferto[ 59 ].WewillcloselyfollowthedenitionsgiventhereandintroducethelanguageLforcontextdescriptions: Denition2ContextDescriptions. ContextdescriptionsinLareformedusingthefollowingsyntaxrule:C;D)167(!Ajatomiccontext>juniversalcontext?jnon-existingcontext:CjcontextnegationCuDjintersubsectionCtDunionWhereAdenotesanatomiccontext.

PAGE 42

32 ThelanguagedescribedallowsustodenetheatomiccontextsWARM,MODERATE,COLDandDOOROPEN.Ormorecomplexcontextdenitionscanbeconstructed,suchasCOLDuDOOROPEN.Thesyntaxabovetellsushowwecanconstructavalidsentencethatdescribedacontext.Apartfromthesyntaxwealsoneedtoaddsemanticstothesyntaxsowecanproperlyinterpretthesyntacticaldenitionofacontextexpression.WeneedaninterpretationI=I;IthatcontainsanonemptydomainofinterestIandaninterpretationfunctionIthatallowsustointerpretourlanguage.Thedomainofinterestinourcaseisthepossiblestateofthespace,henceI=f.TheinterpretationfunctionmapseveryconcepttoasubsetofI: Denition3ExtensionalSemanticsofL. WedenetheinterpretationIasfollows:AII>I=I?I=?:CI=I)]TJ/F22 11.955 Tf 11.955 0 Td[(CICuDI=CIDICtDI=CI[DIUsingthelanguageLwecandeclarerelationshipsbetweenseveralcontexts.Oneistheinclusionoris-arelation.Forexample,acatisananimal.Theotheristheequivalentrelation.Forexampleadogisananimalwithfourlegsthatbarks.Formallythesearedenedas: Denition4ContextRelations. Inclusionandequalityaredenedasfollows: Inclusion:CvD,interpretedbyCIDI. Equality:CD,interpretedbyCI=DI.NoticethatinclusionCvDcanbeexpressedbyintroducinganewbasecontextCanddeneCvDasCCuD.TheideaisthatCexactlycapturesthedierencebetweenaCandaD.ThedescriptionofhowasetofcontextsrelatetoeachotheriscalledaterminologyorT-Box,denotedbyTBox.AterminologyTBoxisacollectionof

PAGE 43

33 inclusionsandequalitiesthatdenehowasetofcontextsrelatetoeachother.Eachiteminthecollectionisuniqueandacyclic.Contextsthataredenedintermsofothercontextsarecalledderivedcontexts.IfwehaveaninterpretationIthatonlyinterpretstheatomiccontexts,wecaninterprettheentiretaxonomy.Conceptscannowbedened,andtheprimitivecontextscanbegivenaninterpretation.Forexample:COLD=f0;::10g,MODERATE=f11;::17g,WARM=f18;::25g.Noticethatthisinterpretationfunctionisnotunique.Dierentusersofthespacewillmostlikelyhavedierentinterpretationsoftheavailableconcepts.Wecannowidentifywhetherthecurrentstateoftheworldisamemberofanyconcepti.e.,toverifywhetheru2fsatisesconceptCwecheckthatuI2CI.Usingthiswecanidentifythecontextsthatarecurrentlyactive: Denition5ActiveContext:. TheactivecontextofthespaceR:U!2CisR=fCjuI2CIgMostsensornetworksintheliteraturemakeuseofahierarchyofinterpretationfunctions,oftenreferredtoascontextderivation[ 28 27 31 ].Sinceataxonomyallowsustodeneinheritancerelationsweoftenrefertoataxonomyasacontextgraph.Contextderivationtypicallyisdonebymakinguseofderivedinterpretationfunctions.Thesefunctionstakeasinputthevalueorhistoryofvaluesfromothersensorsandproduceanewoutputvalue.Theproblemwiththisapproachisthatitisnolongerpossibletoverifywhetherornotthederivationofaparticularcontextissensibleornot,thatisthereisanactualstateoftheworldthatsatisesthedenedcontext.Itisstraightforwardtoconstructasensornetworkthatderivesinconsistentinformation.Thestrengthofadescriptionlogicliesinthefactthateverycontextthatwedeneissensibleandcanactuallyoccurinaspace.

PAGE 44

34 Figure4{1:Indoorandoutdoorsensors 4.3 TemporalContextInterpretingthestateoftheworldonlygivesusanunderstandingoftheworldatasinglemomentintime.Byonlylookingatasinglemomentoftimeitbecomesimpossibletodescribeeventsorcontextsthatdependonsometemporalorderingofevents.Usingmerelysnapshotswecannotdescribeanactivityofdailyliving.Forexampletheactivityofdoinglaundryconsistsofasequenceofevents.Firstwegatherthelaundry,weobtaindetergentandweactivatethewashingmachine.Anotherscenarioisapersonwalkingindoors.Wecandetectthissequenceofeventsbymakinguseoftwopressuresensorsunderthedoormatasshowningure 4{1 .Onesensoronadoormatthatisoutdoorsandonethatisindoors.Assoonasapersoncomesinsidehewillpresstheoutdoorsensorfollowedbytheindoorsensor.Ifapersonleavesthehouseitwillhappeninreverseorder.Firsttheindoorsensorispressedthentheoutdoorsensorispressed.Figure 4{2 showthissequenceisadiagram.Toexpressthiscontextwesomehowneedtoincorporatetimeintoourtaxonomy.ThiscanbedonebyextendingthelanguageLtohandletime.

PAGE 45

35 Figure4{2:Asequencedenotingsomeoneenteredthehouse 4.3.1 SyntaxofTemporalContextWeintroduce,anextensiontoourtaxonomyLthatallowstoexpressandreasonaboutcontextsovertime.Wemodeltimeasadiscretechangeinthestateofthespaceandfollowthesocalledexternalapproach[ 60 ].Intheexternalapproachtheverysameindividualcanhavedierentsnapshots"indierentmomentsoftimethatdescribethevariousstatesoftheindividualatthesetimes.Inourcasetheindividualisthatstateofthepervasivespace.Inthisapproachcontextdenitionsremaininvariant,meaningthatthemeaningofaconceptdoesnotchangeovertime.TheconceptCOLDforexamplewillhavethesameinterpretationregardlessofthecurrenttime.Themembershipofanindividualcanhoweverchangeovertime.InmomentintimethehousecanbeCOLDandanothermomentintimeitisnot.Thesameindividualisclassieddierentlybasedupontime.WeintroducethelanguageLT,byextendingLwithtimeconstructs.ThelanguageLTisusedtodescribetemporalcontexts.Wefollowtheapproachtakenby[ 61 ],whichinturnisbasedontenselogic[ 62 63 ].

PAGE 46

36 Denition6SyntaxofLT. ContextdescriptionsinLTextendLbyaddingthefollowingsyntaxrules:C;D)167(!CjpreviousinstantCjnextinstantCUDjuntilCSDsinceTheadditionofthesefourconstructsarequitepowerful.Forexampleweareabletointroducethefollowingabbreviationswithregardstotime:BC:=>UCC:=:B:CCC:=>SCC:=:C:CWhereCreadsasonce",Baseventually",asalways"andreadsasithasalwaysbeen."TheconstructsallowustoexpressthingsasOwnerAtDoor@Dooropen,thehousewillopenthedoorinthenextinstantifitdetectstheowneratthefrontofthedoor.Wecanfurtherenhanceourexpressivenessbyaddingthefollowingxpointabbreviationsaswell:CbeforeD:=:D^C_CbeforeDUsingtheseabbreviationswecandescribetheexamplegiveningure 4{1 ,anditsoppositeasfollows:WalkIndoorsOutdoorMatbeforeIndoorMatWalkOutdoorsIndoorMatbeforeOutdoorMat

PAGE 47

37 4.3.2 SemanticsofTemporalContextInordertoreasonovertimeweneedatemporalstructureTthatcapturesournotionoftime.ForourpurposewedeneT=P;t0^9t0:t0
PAGE 48

38 Figure4{3:Actualsequenceofevents contextWalkIndoors,sincethiscontextistrueinthepast.Thecontextbeforeshouldbeactiveaftertimeinterval7,notbefore!Theproblemstemsfromtheusageoffuturetenseinsteadofpasttenseinourdenitionofbefore.Inthecaseofrecognizingcontextwewouldlikeourexpressionstobetrueassoonaswehaverecognizedasequenceofcontextstates.Meaningthatanactivityofdailylivingshouldbedescribedintermsofthepastnotofthefuture.Replacingthedescriptionusingpasttenseoperatorswouldsolvethisissue.Anotherproblemwiththedenitionofbeforeisthatitisasocalledweakoperator.AbeforeBdoesnotnecessarilyimplythatBwillbetrueatacertainpoint.Again,thisisnotdesirable.Theeasiestsolutiontotheseproblemsistogivedirectsemanticstothebeforeoperator,insteadofexpressingthemintermsofothers.Thesemanticsofbeforecanbegivenasfollows:CbeforeDIt=fa2Ij9t0:t0
PAGE 49

39 operatorsdoesnotmakethelanguageanymorepowerful,theadditionofroleshoweverdoes.HeprovesthatconceptsatisabilityinALCThasthesametimecomplexityasALCifwetakePtobeadiscretetimestructurelikethenaturalnumbers.ThusreasoningoverALCTisPSPACEcomplete.UnfortunatelythetimeboundsfortenselogictransfertothisclassandhencetheproblemisEXPTIMEhard[ 64 ].Howeverimplementationsofreasoningenginesthatcandealwithtemporaldescriptionlogicsexist[ 65 66 ]anddespitethecomputationalcomplexityofthesealgorithms,theyperformreasonablywellfornormal"applications.NoticethatOWL-DLhassimilarcomplexityresultsbutisstillwidelyusedinaneectivemanner.Forexample[ 67 ]showshowOWLcanbesuccessfullyusedinapervasivespace.

PAGE 50

CHAPTER5DESCRIBINGACTUATORSANDSERVICESThedevicesinasmartspacearenotturnedonrandomly.Weturnonanactuatorbecauseofitseect.Everyactuatorhasasocalledintentionaleectontheworld.Theintentionofturningontheheaterforexampleistoraisethetemperature.Bydescribingtheintentionaleectofanactuatorwecanusethistoreasonabouttheeectoftheinvocationofacertainactuator.Thiscanassistthedeveloperwhenprogrammingthespace.WecanidentifyforexamplethatinvokingtheA/Candtheheateratthesametimeisratherstrange.Onahigherlevelwehaveservicesthataccomplishcertaingoals.Forexampleatemperaturecontrolservicemightbeabletokeepthetemperatureataconstant.Thisservicecanaccomplishthisbymakinguseoftheintentionaleectoftheavailableactuators.Ifwehaveadescriptionofhowanactuatororservicebehavesovertime,wecanusethistopreventconictsandassistadeveloperinhowtoaccomplishastateinthespace.TheontologyLTcannowbeusedtodescribetheeectoftheinvocationofaserviceoractuator.Thedescriptioncanbeusedbythespacetoreasonabouttheeectoftheactivationofaparticularactuatororservice.Considerthefollowing 40

PAGE 51

41 descriptionofaheaterandactuator:Heater^Moderate!ModerateUWarmHeater^Cold!ColdUModerateAirco^Moderate!ModerateUColdAirco^Warm!WarmUModerateIfthecurrentstateoftheworldismoderateandweinvokeboththeheatherandtheair-conditionerwecandetectalogicalinconsistency.ModerateUColduModerateUWarmarelogicallyinconsistent,thereisnoexistingmodelthatsatisesthisformula.Wedetectthattheinvocationofthesetwoactuatorsleadtoanunpredictablestate,orwillresultinanilldenedstate.Similarlywecandescribeservicesintermsofhowtheyeectthespace.ForexampleaclimatecontrolservicecanbedescribedasBModerate.Afteractivatingtheclimatecontroltherewillbeatimeafterwhichitisalwaysmoderate.Ingeneral: Theorem1. Letpandqbethedescriptionsofactuatororserviceaiandaj.aiandaiaresaidtobeinconictinstaterifpuq?. Proof. Thisistrivial.Ifpuq?thentheredoesn'texistamodelthatsatisespuq.Thisdirectlyimpliesthatthereisnosequenceofstatesthatsatisestheseformulas.

PAGE 52

CHAPTER6PROGRAMMINGTHESPACESofarwehavedescribedaspaceconsistingofsensorsandactuators.Thekeyelementthatismissingistheuser.Tomodeltheuserweroughlyfollowthebelief-desire-intention[ 68 ]model,inthesensethattheuserobservesthestateofthespaceand,baseduponthisinformation,commitstoaplanofaction.Wehavethefollowingingredients: Desires: Auserhasasetofpreferencesaboutthestateoftheworld.Thesepreferencesdictatehowtheworldshouldbeatthatgivenmoment.Forexample,whenauserisgoingtobed,heorshewouldlikethedoorslocked. Belief: Thisisthecurrentobservedstateoftheworld,interpretedbyataxonomy.Inanygivenstateoftheworldtheuserhasasetofpreferencesabouttheworld.Whenthestatechanges,thesetofpreferencescanchangeaswell. Intention: Thisistheplantowhichtheusercommits.Inasmartspacethiswouldbetheactivationofasetofactuators.Theaimoftheactivationistofulllthedesirementionedbefore.Theideaisthattheuserobservesthatstateoftheworld.Theuserthenclassiesthestateaccordingtotheusersspecictaxonomy.Thisclassicationgivesrisetoasetofcontextsthatareactive.Associatedwhicheachcontextisasetofbehaviors.Theintentionofthesebehaviorsistochangethecurrentstatetoamoredesiredstate.Forexample,ifuserinterpretstheworldasdark"weturnonalampwiththeintentiontoreachthedesiredstateoflight." 42

PAGE 53

43 6.1 Beliefs-Desires-IntentionsofUsersAswementionedearlierauserhasabeliefaboutthecurrentstateoftheworld.Thecurrentbeliefaboutthestateoftheworldcanbecapturedwithataxonomyandanaccompaniedinterpretation.Theinterpretationmapsthevaluesobtainedfromasensortotheatomicconcepts.Weexpresstheintentionsoftheusersbyasequenceofactionstheuserwishestoexecuteinaparticularcontext.Formally: Denition8User. Auserisa3-tupleB::=hT;I;IiWhereTandIarethetaxonomyaccompaniedbytheinterpretationoftheuser.LetI:C!Sbeamappingfromcontexttostatements.Wecannowdeneaspaceconsistingofsensorsandactuatorsandauserusingthefollowingoperationalsemantics: Denition9StatementSequence. GivenasetofactuatorsA,asequenceofactionsSisdenedasfollows:S::="aij#aijS1;S2Where"aiturnstheactuatorai2Aon,#aiturnstheactuatoraio.With;wedenoteactionprexing.WerstperformactionS1afterwhichweexecutetheremainingstatementsS2. Denition10ProgrammablePervasiveSpace. AprogrammablepervasivespaceisatupleconsistingofP::=hB;U;S;2AiWhereBistherepresentationoftheuser,Uthestateofthespaceasobservedthroughoursensors,Sthestatementswearecurrentlyprocessingand2Athesetofactuatorsthatarecurrentlyactive.

PAGE 54

44 Aspaceschangesovertimeduetonature.Wemodeltheeectofnaturebyatransitionsthatchangesthestateofthespace,andobservethechangesofthespacethroughoursensors. Nature:hb;S;fu;ai)575(!hb;S;fu0;aiwherefu6=fu0Theotherwayinwhichthespacecanchangeisbyactuatorsthatthespacecontrols.Thefollowingtransitionscapturetheturningonandoofactuators: Activation:hb;"ai;u;ai)575(!hb;;u;a[aii Deactivation:hb;#ai;u;ai)575(!hb;;u;anaiiIfthesetofactivecontextshaschanged,weobtaintheintentionsfromtheuserandexecutethedesiredsequenceofactions: ContextChange:hb;fu;S;ai!hb;fu0;iRfu0;aiwheneverRfu06=Rfu 6.2 InheritanceandOverrideTheconceptofsubsumptionintroducesinheritance. Denition11Inheritance. CR^CvD^"ai2ID!"ai2ICNaturallythisholdsforturningo:CR^CvD^#ai2ID!#ai2IC 6.3 ScenarioandProgrammingProceduresWehaveformallyestablishedacontext-drivenprogrammingmodelforpervasivespaces,employingdenitionsforsensors,actuators,users,andcontexts.Buthowexactlywouldthismodelhelpprogrammerscreateormodifysmartspaces?Inthissectionwepresentascenarioandoutlinetheprogrammingproceduretodemonstratethefeasibilityofthecontext-drivenpervasivespaceprogrammingmodel.

PAGE 55

45 6.3.1 LighteningControlApplicationThefollowingscenarioissetinasmartapartmentataretirementcommunity.Itisastudioapartmentintendedforasingleoccupant,andtheservicetobeprogrammedistheambiencelightingcontrol.Theambiencelightinginsidetheapartmentisautomaticallyadjustedbasedupontheactivecontexts.Asageneralrule,whentheroomistoodark,lampsandotherlightxturesshouldbeturnedon;whentheroomistoobright,blindsshouldbeclosedtomaintainacomfortablelivingenvironment.Whentheresidentissleeping,theapartmentshouldbekeptdark.WhentheresidentiswatchingTV,inordertoensurethebestviewingexperience,theambiencelightingshouldbekeptatamoderatelevel. 6.3.2 DescribingContextTherststepinprogrammingthedescribedlightingcontrolinthissmartapartmentistoproperlymodelthephysicalaspectsofthespace.Atanymoment,wecandescribethissmartspaceasbeingincertainstates;forinstance,thesmartspacecanbedescribedasBright,Dark,ResidentwatchingTV,orResidentsleeping.Whilehumanbeingscantakeaglimpseattheapartmentandalmostimmediatelyidentifythesecontextsasmartspacetomakesenseofallthese,twocriteriamustbesatised.First,theremustbeappropriatesensorsthatcanperformtherelevantmeasurements.Forinstance,inordertoidentifyBrightorDark,somesortofluminancesensormustbepresentinthesmartspace.And,withoutathermometer,thereisnowayforasmartspacetoobservewhethertheroomtemperatureisHotorCold.Second,theremustbeaninterpretationofthereadingsgeneratedbythesensorstomoreabstractcontexts.Forexample,wecaninterpretanyreadingofhigherthan600luxfromaluminancesensorasBright,readingsunder400luxasDark,andanythinginbetweenasIlluminated.

PAGE 56

46 Inadditiontotheseatomiccontextsthatcanbedirectlymeasuredbyphysicalsensors,itisalsousefultohavederivedcontexts,whichcanbedenedwiththehelpoftaxonomyoperations.Fortheambiencelightingcontrolservice,thederivedcontextssuchasBrightTVOn,IlluminatedTVOnandDarkTVOn,whicharebuiltfromatomiccontextsBright,Illuminated,DarkandTVOn,areextremelyhelpfulinidentifyingthecurrentcontextofinterestwhentryingtodecidethenextappropriateactionthesystemshouldperform. 6.3.3 AssociatingBehaviorOncecontextsofinterestbothatomiccontextsandderivedcontextsaredenedandinterpretationfunctionsaredevised,thesmartspacecannowunderstandwhichcontextsarecurrentlyactive.Foreachreadingofeachsensorwithproperlydenedcontextsinitsassociateddomain,thatreadingshouldbeabletobeinterpretedasexactlyoneactiveatomiccontextinthatdomain.Forinstance,iftheluminancesensorweretoreportareadingvalueof700lux,atomiccontextBrightwouldberecognizedasactive,whileaqueryofasimplesensorintheTVsetshouldreporteitherTVOnorTVOffisthecurrentactiveatomiccontext.Theseactiveatomiccontextscanbeusedtogeneratefurtheractivederivedcontexts,whenallitschildcontextsareactive.Forinstance,BrightTVOnwouldbecomeactiveautomaticallywhentheluminancesensorreportsactiveBrightcontextandTVsetreportsactiveTVOnstatus.Inordertoachievethegoalofautomaticallyadjustingambientlighting,wehavetondsomewayforthesmartspacetointeractandinuencetherealworld.Thiscanbeachievedbymanipulatingactuators.Withthecurrentversionofourcontext-drivenprogrammingmodel,actuatorsareonlyallowedbinaryoperations,whichmeansthattheyareeitherturnedonoro.Eachactuatorthatisturnedonshouldgenerateatleastoneintentionaleect,whichresultsinacontexttransitions.Forexample,turningonlampswouldbrightentheroomthat

PAGE 57

47 is,thespacewouldtransitionbetweencontexts,suchasDark!IlluminatedorDark!Bright,whileclosingtheblindswoulddarkentheroomBright!DarkorIlluminated!Dark.Howdoesthesmarthouseknowwhentoturnonthelampsorclosetheblinds?Thatiswhereuserscomein.Theoccupantoftheapartmentshouldhavetheultimatepowertomakedecisions.TheresidentcallstheshotsondeningwhatDarkorBrightmean,andthecontextgraphshouldbebuiltbasedonhisorherbeliefssoastohelptheusertrulyunderstandthecurrentactivestateoftheentiresmartspace,aswellasfacilitatetheplanningofactions.Theuseralsogetstoexpresshisorherdesiresbyspecifyingthepreferablecontexts.Thisultimatelydenesthegoalsthesmartspaceshouldworktowardswhendecidingwhichactionsifanytotake.Inessence,thespacemustndandexecutearoutefromthecurrentactivecontextstothepromisedpreferablecontextsusingtheonlytoolsithastochangethestateofthespace:actuators.Andsincethesmartspaceknowsaboutthecurrentactivecontexts,thenalpreferablecontexts,andtheintentionaleectsofeachactuator,ithasalltheinformationneededtodevisethisrouteandfullltheuser'sintention. 6.3.4 ConnectingSensorsWenowreturntothescenarioofprogrammingambiencelightingcontrol.Inordertoprovidethisserviceasdescribed,threedierentsensorshavetobepresentintheapartment:aluminancesensor,aTVsetsensor,andasmartbedthatcandetectwhethertheresidentisonit.TheTVsetsensorandsmartbedgenerateBooleanvaluesastowhethertheTVsetisonoro,andwhethertheresidentisinbedornot.Theluminancesensor,however,requiresaninterpretationfunctionbetweennumericalreadingvaluesandatomiccontextsBright,IlluminatedandDarkthevaluesforthesecontextshavebeendenedabove.

PAGE 58

48 Inadditiontothesensors,weassumetwoactuatorsareavailableintheapartment:onetocontrolthelampsandonetocontroltheblinds.Theintentionaleectsofeachactuatorarealsodescribedabove.Asforcontexts,thereareatomiccontextssuchasBright,TVOnorInBedthatcanbeinterpreteddirectlyfromsensorreadings,andtherearealsoderivedcontextssuchasDarkInBedandIlluminatedTVOn.Sincetheuserwouldpreferthelightstobeturnedocompletelywhileheorshesleeps,butprefersadequatelightingwhilewatchingTV,DarkInBedandIlluminatedTVOnarepotentialgoalsdependingontheuser'scurrentintentions,andarethereforepreferredcontexts.Foreachnon-preferredcontext,anassociatedstatementconsistingofasequenceofactionsmanipulatingactuatorsisattached,whichspecieshowtomovefromthatcontexttoanother.HencethesmartspaceidentiesDarkInBedandIlluminatedTVOnaspreferredcontexts,andwillstrivetomakeeitheroneofthemtheactivecontextbyexecutingtheactionstatementassociatedwiththecurrentactivecontext.Figure 6.3.4 showsthecontextgraphdescribedinthissection.Thederivedcontextsautomaticallyinherittheactionstatementsfromtheirchildcontexts.HenceifBrightInBedisassociatedwithactionclosingtheblindsthenBrightTVOnInBedshould,unlessspeciedotherwise,alsoretainthesameaction.However,aninterestingscenariooccurswhenweconsiderasituationwiththeresidentlyinginbedwhilewatchingTVbeforegoingtosleepinthecurrentlyilluminatedroom.Inthissituationwehavethreeactivederivedcontexts:IlliminatedTVOn,IlluminatedInBed,andIlluminatedTVOnInBed,withthelastonederivedfromtheprevioustwo.Weobservethatthereareconictinginheritedactionstatements.Toresolvetheseconictingactions,withonetryingtoclosetheblindswhilethe

PAGE 59

49 Figure6{1:Asamplecontextgraph otherindicatingthatnoactionisneeded,weneedtodeneanewactionstatementwhenIlluminatedTVOnInBedisactive.SincetheresidentisstillwatchingTV,thelightingshouldbekeptilluminateduntilsheorhedecidestogotosleep.Thecontextdrivenprogrammingmodeliseectiveindetectingconictingactionsandcanprompttheuserforresolution.Wealsoobservehowinheritanceandoverridingactionstatementsenablethedevelopmentofrobustsmartspaces.

PAGE 60

CHAPTER7INTEGRATEDDEVELOPMENTENVIRONMENTWiththecontextdrivenprogrammingmodelformallydened,wearenowreadytoexplorehowprogrammerscanactuallyprogramasmartspace. 7.1 DesignoftheContextGraphTheprogrammingprocedurewouldstartwithdesigningacontextgraph,whichisasemanticwebthatiscomposedofinterestingstatesofthespace.Therearetwotypesofcontextsinacontextgraph,theatomiccontextsandderivedcontexts.Atomiccontextsdierfromderivedcontextsinthattheycanbedirectlyassociatedwithreadingsofoneparticulartypeofsensor,whilederivedcontextsarecomposedofmultipleatomiccontexts.Forexample,coldandhotaretwoatomiccontexts,becausetheycanbeassociatedwiththermometers,withapredenedrangeofreadingsfromthethermometer.Ontheotherhand,contextscoldanddry"hotanddry"derivedcontexts,sincetheycannotbedirectlyassociatedwithsensors,butinsteadcanonlybederivedfromacombinationofatomiccontextssuchascoldanddryforcoldanddry"context.Thedesignofacontextgraphcanproceedwithoutknowledgeofavailabilityofvariousentitiesinthehouse,andcanbeappliedtodierentsmartspaces.However,foreachsmartspace,thecontextsofinterestwouldvarybasedonthecollectionsofavailablesensorsandactuators.Thecontextsofinterestarealsoaectedbysuchthingsastheresidentsactivitiesandpreferencesandthecaregiversprimaryconcerns.Itwouldbenatural,therefore,toassumeonepossiblepracticewhendesigningthecontextgraph.Thiswouldbetogetagenericcontextgraphasatemplate,andthencustomizeforeachsmarthouseandresidentbasedonfactorssuchas 50

PAGE 61

51 availabilityofsensorsandactuators,orresidentspreference.Therewouldbenoproblemshouldthecontextgraphcontaineithermoreorfewercontextsthancouldbesensedbyavailablesensors,althoughifthecontextgraphcannotinterpretreadingfromsomesensors,itwouldrenderthesesensorsuseless.Thispropertyallowsagenericcontextgraphtemplatetobeused,andalsoprovidessystem-widerobustnesswhensomeentitiesfailornewonesareintroducedtothesmarthouse. 7.2 InterpretationofSensorReadingsToallowtheruntimeplatformtointerpretsensorreadings,theentirerangeofpossiblereadingsfromeachsensormustbemappedtodisjointatomiccontexts.Forexample,forathermometerwhichiscapableofreadingtemperaturesbetween)]TJ/F15 11.955 Tf 9.298 0 Td[(20F222F,weneedtospecifythat20F55Fwouldmaptocoldatomiccontext,and55F70Fwouldmaptocoolatomiccontext,and70F80Fwouldmaptowarmatomiccontext,and80F222Fwouldmaptohotatomiccontext.Theassociationofarangeofpossiblereadingvaluesinintegerorrealnumbers,Booleanvaluesorenumeratedstringstocertaindenedatomiccontextenablestheruntimeplatformtomakesenseofthesensorreadingsasthecurrentstateofthesmarthouse,whichleadstothedecisionofwhichactionstotake. 7.3 DesiredBehaviorsunderEachContextContextsdenedinacontextgraphrepresentthewholespectrumofpossibleinterestedstatesthatcanbeusedtodescribethecurrentstandingofthesmarthouse.Therearecontextsthatarenotallowedandshouldbeavoided,if,unfortunately,thecurrentcontextfallsintooneoftheseimpermissiblecontexts,somesortofemergencyactionsshouldbetakentomoveoutofthiscontextassoonaspossible.Forexample,thecontextofextremelyhotandsmoking"wouldbeanexampleofimpermissiblecontext,andextrememeasuressuchascall911andinitiateredepressantwouldbewarranted.Thereareothersthataresituationsconsideredtobenormal,butnotquitethemostdesirablesituation.In

PAGE 62

52 thosecontexts,actionsshouldbespeciedsothestateofthesmarthousewouldgraduallymovetowardmoredesirablecontexts.Thespeciedactionsinorderproducetothismovementwouldbecalleddesiredbehaviorassociatedwiththecontext.Forexample,inacoldFebruaryinanorthernclimate,itisquitepossiblethecurrentcontextwithinthesmarthousewouldbecoldanddry",whichisnormalbutnotquitedesirable.Themorecomfortable,hencedesirablecontextinthisexamplewouldbewarmwithmoderatehumidity",andthedesiredbehaviorassociatedwithcoldanddry"contextwouldthereforeprobablybeturnontheheaterandthehumidier.Thesystemdesignersandprogrammerswouldprogramsmarthousesbyassociatingbehaviorstoeachofthespeciedcontextsinthecontextgraph.Thiswouldnormallyleadtocontexttransitionsthatmoveclosertothedesirablecontexts. 7.4 MappingPhysicalSensorsandActuatorstotheContextModelAfterthecompletionofthepreviousthreesteps,wenowhavetheknowledgetodescribeallcontextsofinterestofthehouse,theknowledgetointerpretthesensorreadingsanddecidewhatthecurrentcontextsare,andtheknowledgeofwhatactionstotaketosteerthehousetowardthedesirablecontext.Buthowdoweapplyallthisknowledgetothephysicalentitiesinthesmarthouse?Anarrayofdisjointedatomiccontextslikecold,cool,warmandhotistheoreticallygreatindescribingthecontextofthehouse,butwouldnotbeeectiveunlesscertainsensorsactuallyavailableinthehouseareassociatedwiththesecontexts.Thesamewouldapplytotheactuators,whichneedtobemanipulatedforactionsassociatedwitheachcontext.Thisassociationisestablishedatruntime,whentheruntimeplatformdynamicallylinksthecontextsandactionswithexistentsensorsandactuatorsbasedontheirassociatedmeasuringdimensions,locations,andotherinformationWiththeprogrammedknowledgeinstalledandphysicalentitieslinked,thesmarthouseisnowreadytooperatebasedonprogrammersdirectives.

PAGE 63

53 7.5 ImplementationoftheIDEInthissectionwelookathowweimplementedthedevelopmentenvironment. 7.5.1 PremiseandPlatformSelectionTheexistingserviceplatformforGTSHisbuiltuponOSGi.Itprovidesexcellentfacilitiestomanagethelifecycleofallservicesandentities,implementedasindividualbundles,andhandlesdynamicadditionorremovalautomatically.ItalsoprovidesgoodAPIssuchaswiringbetweendatasourcesandsinks,andserviceregistrationtoallowdynamicallyfulllingbundledependencies.OSGiAlliance,whichmaintainsthetechnology,consistsofmanymajorplayersinthecomputerandapplianceindustry,assuringthewideacceptanceofOSGi.RealizingthatalthoughprovidinganIDEforsmartspacesandexploringreasonableprogrammingmodelsisrelativelynovelforpervasivecomputingresearches,theeortofprogrammingbundlesinJavaorestablishingcontextgraphswithontologyarenot.HencewedecidedearlyontoimplementthisIDEasanenhancementorattachableplug-instoestablisheddevelopmenttoolsinsteadofafulledgestandalonesoftware.Twopotentialtargetsareidentied:EclipsewhichisoneofthemostpredominantIDEusedbyJavadevelopers,allowingeasybundleauthoring,and2Protegewhichisoneofthemostheraldedtoolforontologyandsemanticwebediting.Aftercarefulconsideration,wedecidedthatProtegewaspreferablefortheinitialphaseofourworksincemostoftheprogrammingeortusingthecontextdrivenprogrammingmodelrequiresestablishingandeditingthesemanticwebandcontextgraphratherthanimplementingJavacode.Protegealsohasthecapabilitytoemployreasoningenginewhichcanestablishwhetheraconceptsubsumes,isequivalenttoanotherorwhetheracertainindividualisamemberofaparticularconcept,whichiscrucialinexceptioncapturingandactivecontextsderivationinthecontextdrivenprogrammingmodel.ShouldwehaveafutureneedtoincorporateheavybundlecodinginJava,thecurrentenhancement

PAGE 64

54 totheProtegewouldbecarriedovertotheProtegeplug-inforEclipsetopreservethecurrenteortandprovideseamlessintegrationbetweenthetwoenvironments. 7.5.2 RequirementAnalysisSmallscaleinterviewsregardingtherequirementsoftheIDEwereconductedamongthein-houseinvestigatorswhoparticipatedintheinitialsetupofGTSH.Withtheirhands-onexperienceinactuallyprogrammingafull-scalesmarthouse,thefollowingrequirementsfortheIDEwereidentied: 1. capabilityforbrowsingexistingsensors,actuatorsandservicesinthesmartenvironment. 2. capabilityforbrowsingthecontextcompositions. 3. capabilityforviewingandeditingtheinterpretationofsensorreadingstoassociatedatomiccontexts. 4. capabilityforviewingandeditingthebehaviorsassociatedwitheachcontext. 5. capabilityforcreatingcontradictorybehaviorsandimpermissiblecontextchecks. 6. capabilityforinstallinganddeployingtheprogramstotheruntimeplatform. 7. Easeofusetoallowdomainexpertstomodifycurrentorcreatenewbehaviorsofsmarthouses. 7.5.3 EnablingMiddlewareRuntimeAspartoftheGTSHproject,middlewarearchitecturehasbeenproposedanddeveloped[15].Themiddlewareservesasthebackboneofsmarthouse,allowingphysicalentitiessuchassensorsandactuatorstobeautomaticallyintegratedintotheenvironmentuponentry.Themiddlewarealsoempowersdesignerstodenecontextsandknowledgeandprogramthebehaviorofthesmarthouse.Therearetwosoftwareartifactsthatareessentialinactualenablingtheprogrammingprocessofsmarthouses.Thereis,ofcourse,theIDEthatprovidestoolsandguidancethatallowsystemdesignerstoactuallyimplementcodeand/or

PAGE 65

55 congureandspecifyknowledgethatdepictstheexpectedbehaviorofthesmartenvironment.ThereisthemiddlewareruntimethatwouldlikelyresidesomewhereinthesmarthousethatactuallyinterpretsandexecutestheseinstructionscreatedusingIDE.TheinteractionsbetweenthesetwosoftwareartifactsareshowninFigure 7{1 Figure7{1:Interactionbetweencomponents ThecurrentactivemiddlewareruntimeisimplementedonanOSGiplatformasabundle.Thisbundleservesasthebrainofthesmarthouse.ItisconnectedtovariousbundlesrepresentingsensorsviaOSGiwiringAPI,andfeedstheseproactivelycollectedsensorreadingsintoatomiccontextinterpreters.TheseclassiedatomiccontextsarefedintoaJenaandreasoningenginetoactivatealltheactivecontexts.Themiddlewarebundlethenlooksupthebehaviorassociatedwiththesecontextsandtriggerstheprogrammedactions,mostlybyeitherturningonorocertainrelatedactuators.CurrentversionofthismiddlewarealsoperformsapredenedassociationbetweenphysicalsensorsoractuatorsandtheentitiesrepresentedintheOWLle.AsthecurrentprojectofenhancingthecontextdrivenprogrammingmodelandimplementationofIDEprogress,there

PAGE 66

56 alsohavebeenminorrevisionsofthemiddlewarebundletosupportthesechangesandenhancement.InthewakeoftheprocessofdevelopingtheIDE,thereareundoubtedlyiterationsamongIDE,themiddlewarebundleandtheprogrammingmodel.Sincetheyactuallyrepresentdierentfacetsofthesamething,theyaredenitelytightlycoupled.SystemdesignersuseIDEtoprogramandcongurethesmarthouse,whiletheprogrammedcodeandcongurationsareinterpretedandexecutedbythemiddlewareruntime.TheprogrammingmodelprovidesthetheoreticalbackgroundanddesignrationalforboththeIDEandthemiddleware. 7.6 ComponentsoftheIDEInthissectionwelookathowthevariouscomponentsintheIDEhelpthedeveloperprogrammingthepervasivespace. 7.6.1 EntityDenitionViewAsshowningure 7{2 ,thisviewprovidesthetoolsforbrowsingsensorandactuatorentitiescurrentlyavailableinthesmarthouse.Italsoprovidesthegraphicalinterfaceforeditingthesensorreadingsmappingtoatomiccontexts,aswellasspecicationoftheeectsofactuatorsintermsofswitchingbetweenatomiccontexts.Thisviewisimplementedasaplug-intabtoProtege3.1,andthevisualizationsareimplementedusingstandardJavaSwingcomponent.AllinformationandspecicationseditedanddisplayedonthisviewarestoredintheOWLlethatservesastheblueprintofthesmarthouseunderdevelopment.Itshort,thepurposeofthisviewistoprovidethesystemdesignerwiththeknowledgeabouttheavailabilityofvarioussensorandactuatorentities,anddetailedinformationaboutthem,suchaslocation,entityID,thetypeofmeasurement.,Thisallowssystemdesignerstoprogramandupdatecertainaspectsofeachentitypresented,suchasreadingsvaluemappingofsensorsanddefaulteectsofactuators.

PAGE 67

57 Figure7{2:Entitydenitionview 7.6.2 BehaviorDenitionViewAsshowninFigure 7{3 ,thisviewprovidesthetoolsforbrowsingthecontextgraphofthesmarthouse,editingthegraphtoreectthecontextsofinterest,anddeningexpectedbehaviorassociatedwitheachcontextofinterest.Italsoprovidesvisualizationofthepotentialmigrationpathofcontextsastheeectofprogrammedbehaviorsthatshouldbeinvaluableinguidingtheprogrammingprocess.Insteadofaskingsystemdesignerstodrawtheentirecontextgraphalistofvariousatomiccontextsareprovidedandsystemdesignerscansimplypickthederivedcontextofinterest,andtheIDEwouldautomaticallyderivethecontextgraphbasedonontologyandtheinheritrelationsbetweencontexts.Thisviewisimplementedasanotherplug-intabtoProtege3.1,andthevisualizationsareimplementedusingstandardJavaSwingcomponent.AllinformationandspecicationseditedanddisplayedonthisviewarestoredintheOWLlethatservesastheblueprintofthesmarthouseunderdevelopment.Inshort,thepurposeofthisviewistohelpsystemdesignersgrasptheprogrammedbehaviorsandtheireects,andmodifythesebehaviorsifsodesired.

PAGE 68

58 Figure7{3:Contextbrowser 7.6.3 ImpermissibleContextCheckerThischeckerservesasasafeguardmechanismbeforeaprogramisdeployedtotherealremotesmarthouses.Someofthepre-deploymentcheckingincludesoverlappingofsensorreadingsfordisjointatomiccontexts,contradictoryactionsspecicationassociatedwithsamecontext.ThischeckerisimplementedusingJenareasonengine,whichautomaticallyexaminestheOWLleprogrammedusingtwoviewsdescribedintheprevioussections.Shouldanyimpermissiblecontextbefound,theIDEpreventsthedeploymenttoavoiddestabilizingthetargetsmarthouse. 7.6.4 CommunicationModuleThismoduleenablescommunicationbetweentheIDEandthemiddlewareruntime.Thecommunicationsshouldhappenonlytwiceduringtheprogrammingprocess,onceatthebeginningwhenretrievingasnapshotofcurrentrunning

PAGE 69

59 programsandavailablesensor/actuatorentitiesinformationfromthesmarthouse.Systemdesignerswouldprogramthesmarthousebasedonthisretrievedsnapshot.Attheendoftheprogrammingprocess,afterthecontextcheckerveriedthedesign,theOWLleisuploadedtothetargetsmarthouseandreplacesthecurrentrunningprogram.Thisminimalcommunicationpatternischosenfortworeasons.First,sincesmartspacesareanopenandvolatileenvironment,itisassumedthatsensors,actuatorsorsmartappliancescanbebroughtintothehouseortakenoutatanytime.Withthelargenumberoftheseentities,failureiscouldbethenorm.HenceiftheIDEconstantlytracksallthechangesandreectsthemonvariousviewsinrealtime,itwouldcauseconfusionandinconveniencetodesignersatwork.Second,sincetheIDEisusedforprogramming,notmonitoring,continuousrealtimecommunicationdoesnotseemnecessary.Instead,weoptforpre-deploymentcheckingtoseeifanychangesinthesmarthousewouldmeritfurtherchangesofthetargetOWLle.Thiscompromisewouldgrantarelativestableworkingenvironmentfordesignersduringprogrammingprocess,yetmaintainintegrityoftheprogramwhileusingminimalcommunicationbandwidth.Allthenecessaryknowledgesuchassensorreadingmappings,actuatoreectsandcontextassociatedbehaviorsneededtospecifyhowsmarthouseshouldbehaveareallstructuredaspartofthetargetOWLle.TheretrievalanddeploymentofinformationbetweenIDEandmiddlewareruntimeismadeextremelysimpleascorrespondingtodownloadinganduploadingtheOWLlerespectively.Thecommunicationmoduleisimplementedasaservlet.SystemdesignerscanselectwhichsmarthousetoconnecttobyspecifyingitsIPordomainname,andseparateconnect"anddeploy"buttonwouldinitiateeitherdownloadoruploadsequencerespectively.Inshort,thismoduleprovidesthebridgebetweenIDEandmiddlewareruntimelocatedataremotesmarthouse.

PAGE 70

60 Figure 7{4 showsthesnapshotduringcontextcheckingandprogramdeploymentprocess. Figure7{4:Impermissiblecontextvercation

PAGE 71

DESCRIPTIONLOGICSSincetheframeworkpresentedinthisdissertationdependsheavilyondescriptionlogicswewilldelveintomoredetailsandprovidethemathematicalfoundationofadescriptionlogic.Agoodunderstandingofthefoundationswillshowthattheinterpretationofsensordatausingadescriptionlogicisstraightforward.Descriptionlogicsareconcernedwithdescribingknowledgeaboutaproblemdomain.Aknowledgebaseconsistsoftwoparts: IntensionalknowledgeT-BoxTBox: Theintensionalknowledgecontainsthegeneralknowledgeaboutaproblemdomain.Itisdenedintermsofaterminology.Aterminologydenesasetofrelationsbetweenvariousconcepts.Forexampleanelderisaperson.Anelderisatleast75yearsold. ExtensionalknowledgeA-BoxABox: Describesthespecicknowledgetoaparticulardomain.Aworlddescriptiondenesasetofindividualinstancesbelongingtothedenedterminology.Forexample:Mathildais85yearsold.Theknowledgebasecannowbeusedtoderiveadditionalinformationthatisnotexplicitlystatedintheextensionalknowledge.ForexamplewecanderivethatMathildaisanelder,sincesheis85yearsoldandanyonewhoisolderthan75isanelder. A.1 DescribingIntensionalKnowledgeTheaimofintensionalknowledgeistodescriberelationshipsbetweenvariousconceptsinaproblemdomain.Thekeyingredientsareconcepts.Conceptsarenamesthatrefertoconceptsthatareusedintheproblemdomain.Therearetwotypesofconcepts: 61

PAGE 72

62 Primitive: AprimitiveconceptdenotedbythelettersACisaconceptthatstandsonitself.Itreferstoavalidconceptinaproblemdomain.ForexampletheconceptLocationcouldrefertoalocationinthespace. Derived: AderivedconceptisaconceptdenotedbytheletterCorDthatisdenedintermsofrelationstoasetofprimitiveconcepts.ForexamplewecouldsaythataRoomhasaLocationinsideaHouse.Apartfromsimplenamestoorganizeconceptswecanalsoaddpropertiestoconcepts.Propertiesarebinaryrelationsassociatingindividualsfromdierentconceptstogether.Forexampleapersoncanplaytheroleofaparent,associatinganotherpersontothisperson.WewillusetheletterRtodenotearole.Wecannowgivethesyntaxofthelanguageasfollows: Denition12BasiclanguageALC[ 59 ]. ConceptdescriptionsinLareformedusingthefollowingsyntaxrule:C;D)167(!Ajatomicconcept>juniversalconcept?jbottomconcept:CjconceptnegationCuDjintersectionCtDjunion8R:Cjuniversalquantier9R:CexistentialquantierThelanguageALCallowsustoexpressvariousconcepts.ForexamplewecoulddeneaHappyprofessor"usingtheatomicconceptsTenureandtheroleFunding:HappyProfessor=Tenureu9Funding:>

PAGE 73

63 Aprofessorishappyifheorshehassomeformoffundingandtenure.Thesyntaxabovetellsushowwecanconstructavalidsentencethatdescribedaconcept.Apartfromthesyntaxwealsoneedtoaddsemanticstothesyntaxsowecanproperlyinterpretthesyntacticaldenitionofaconceptexpression.WeneedaninterpretationI=I;IthatcontainsanonemptydomainofinterestIandaninterpretationfunctionIthatallowsustointerpretourlanguage.TheinterpretationfunctionmapseveryconcepttoasubsetofIandeveryroletoasubsetofII: Denition13ExtensionalSemanticsofALC. WedenetheinterpretationIasfollows:AII>I=I?I=?:CI=I)]TJ/F22 11.955 Tf 11.955 0 Td[(CICuDI=CIDICtDI=CI[DI8R:CI=fa2Ij8b:a:b2RI!b2CIg9R:CI=fa2Ij9b:a:b2RI^b2CIgAnotherwayofgivingsemanticstoALCisbygivingacorrespondencewithrstorderlogicFOL.WecantranslateeveryconceptdenitionintoanequivalentFOL.AtomicconceptsandrolesaremappedontoAandR;respectively.AconceptCandaroleRcorrespondtotheFOLformulaeFCandFR;whereanddenotefreevariables..

PAGE 74

64 Denition14TransformationalSemanticsofALC. WedenetheinterpretationIasfollows:>I=true?I=false:CI=:FCCuDI=FC^FDCtDI=FC_FD8R:CI=9x:FR;x^FCx9R:CI=8x:FR;x!FCxSincewecangivethistransformationalgrammaritbecomesclearthatALCisasubsetofFOL. A.2 TerminologiesTheprevioussectionshowedthebasicingredientsthatallowusdeneaconcept.Inordertodescribeadomainofinterestweneedtospecifyhowagroupofconceptsrelatetoeachother.ThedescriptionofhowasetofconceptsrelatetoeachotheriscalledaterminologyorT-Box.Aterminologyisdenedasfollows: Denition15T-Box. WedeneaT-BoxTBoxasfollows: Inclusion:C@DwiththeinterpretationCIDI,meaningthattheconceptCisasubclassofD. Equality:CDwiththeinterpretationCI=DI,meaningthatCcanbedenedasD. Denition:Anequalitywhoselefthandsideisatomic. Unique:Nosymbolisdenedmorethanonce. A-Cyclic:Nodenitionisindirectlydenedintermsofitself.Conceptsthatonlyoccurontherighthandsideofdenitionsarecalledprimitiveconcepts.NoticethatinclusionC@DcanbeexpressedbyintroducinganewbaseconceptCasCCuD.TheideaisthatCexactlycapturesthe

PAGE 75

65 dierencebetweenaCandaD.Theinclusiondoesnotreallymakealanguagemoreexpressible,itmerelyisaconvenientwayofdescribinghowoneconceptismoregenericthananother.NoticethataT-BoxasdenedabovecanalwaysbeexpandedintoaT-Boxwhereeverydenitionisdenedintermsofonlybasesymbols.Theexpansionprocedurerecursivelysubstituteseverydenedconceptoccurringinadenitionwithitsdeningexpression.ThisprocedurecangenerateaT-Boxthatisexponentialinsize.In[ 69 ]itisshownthatthisblowupispolynomialifoneimposessomerestrictions. A.3 ExtensionalKnowledgeExtensionalknowledgedealswithactualindividualsthatareinstancesaspecicconcept.Forexamplewecouldstatethattheindividualmathildaisaperson.TraditionallythisiswrittenasPersonMathilda.AnA-BoxABoxisacollectionofsuchassertions.InordertodealwithindividualsweextendtheinterpretationfunctionIinsuchawaythatforeveryindividualawehavethataI2I.ItisassumedthatifaandbaredistinctnamesthenaI6=bIConceptmembershipCacannowbeinterpretedasaI2CIandrolefulllmentasaI;bI2RI. A.4 ReasoningTherearebasicallytwoformsofreasoningthatareofrelevancefordescriptionlogic.Reasoningwithintensionalknowledgeandreasoningwithextensionalknowledge.Reasoningwithintensionalknowledgedealswithinferringrelationsthatarenotdenedbutcanbeextractedfromthedescription.Thebasicinferenceonconceptexpressionsissubsumption,writtenasCvD.Wecheckiftherstconceptalwaysisasubsetofthesecondconcept.

PAGE 76

66 Subsumptionisusedinordertoclassifyaknowledgebase.Theaimistoinferwhichconceptssubsumeoneanother.Considergure 2{1 inthepreviouschapter.Wecanderivethatamotherisawoman,sincebothmotherandwomanaresubclassoffemaleandperson.Subsumptionformsthebaseforextractingallotherformsofrelevantinformation.Thenotionofsatisabilityi.e.,assuringthateveryconceptallowsatleastoneindividual.Aconceptmakesaknowledgebaseinconsistentifitsubsumestothebottomconceptwhichallowsnoindividualsi.e.,theconceptCisinconsistentwhenever:Cv?.Thethirdformofreasoningisusedtoestablishwhethertwoconceptsaremutuallyexclusive.MeaningthatitisnotpossibletondaninstanceofCthatisaninstanceofDaswell.DisjointnesscanbecomputedbyobservingthatCuDv?.Forextensionalknowledgewehavetwoformsofinferencethatareofrelevence.Firstwehavetheproblemofinstanceclassication.Thatisgivenanindividualaweverifyifaisaninstanceofthatspecicconcept.Secondistheretrievalproblem.GivenaconceptexpressionCwhichindividualsa2ABoxintheknowledgebaseareaninstanceofthisconcept.Tosumthingsup,wehavethefollowingtoolsforreasoningavailable: Subsumption:C@D,CIDI Equality:C=D,CI=DI Disjointness:CandDaredisjointwhenCI[DI=? Inconsistent:C=? Membership:Ca,aI2CI Retrieval:TheretrievalofCisthesetfaja2ABox^Cag

PAGE 77

67 Asshownaboveallofthesecanalsobeexpressedusingsubsumption,soanyreasoningenginesupportingsubsumptioncanbeusedtoverifytheotherrelationshipsaswell. A.5 Open-WorldversusClosed-WorldAssumptionOnecouldsaythataknowledgebaseisverysimilartoadatabase.Theintensionalknowledgerepresentsthedatabaseschemaandtheextensionalknowledgerepresentsthedataitemscontainedwithinadatabase.Thiscomparisonisnatural,butthereishoweverakeydierencebetweenadatabaseandadescriptionlogic.Thisdierenceliesintheapproachbothsystemstaketoabsenceoffacts.Whendataisabsentitmightnotbepossibletodeducewhetheracertainfactistrueornot.Ingeneralthishasleadtotwoapproachestodealingwiththeabsenceofinformation: ClosedWorld: IfitisimpossibletoprovewhetherafactPor:Pistrue,weassumethat:Pistrue. OpenWorld: IfitisimpossibletoprovewhetherafactPor:Pistrueweconsiderthefacttobeundeterminedforthetimebeing.Supposewehavethefollowingstatement: ErwinisacitizenoftheNetherlandsAndthefollowingquestion: IsErwinacitizenoftheUSAUndertheclosedworldassumptiontheonlyconclusionwecandrawisNo,sincetheabsenceoftheinformationimpliesthatErwinisnotacitizenoftheUSA.Ifweusetheopenworldassumptionhoweverthiscannotbeconcluded,andtheanswerwouldbeunknown,sinceErwincouldhaveadualcitizenship.Anotherclassicexampleis: APersoncanhaveonlyoneMother,ThemotherofErwinisMaria

PAGE 78

68 Supposeweaddthestatement:ThemotherofErwinisMieketoourknowledgebase.Undertheclosedworldassumptionthiswouldresultinanexception,sinceaPersonErwincanonlyhaveonemother.UndertheopenworldassumptionthesystemwouldderivethatMariaandMiekearethesameperson.Whichhappenstobethecaseinthisparticularexample.Databasesnormallyoperateundertheclosedworldassumption,whereasdescriptionlogicsoperateusingtheopenworldassumption.Thetwodierentapproacheshaveboththeiradvantagesanddrawbacks.Theopenworldassumptionismoreexpressive,sinceifthefactPisabsentwemustconsideramodelwherePistrueandamodelwhere:Pistrue.Considertheexamplegivenin[ 59 ].Supposewehavethefollowingknowledgebase:hasChildJOCASTA;OEDIPUShasChildOEDIPUS;POLYNEIKEShasChildJOCASTA;POLYNEIKEShasChildPOLYNEIKES;THERSANDROSPatricideOEDIPUS:PatricideTHESANDROSTheknowledgebaseisshowninFigure A{1 .Supposewewanttoknowwhetherornot9hasChild:Patricideu9hasChild::PatricideJOCASTAholds,i.etheanswertothequestionwhetherJocastahasatleasttwochildren,onewhichkilledhisorherfatherandonethatdidnot.WecannotconcludethistobethecaseforJocastaifweusetheclosedworldassumption.ThisfollowsfromthefactthatitisunknownwhetherornotPolyneikeskilledhisfather.Undertheopenworldassumptionhowevertherearetwopossiblemodels,asshowninFigure A{1 .OneworldinwhichPolyneikesisapatricideandonein

PAGE 79

69 FigureA{1:Openworldversusclosedworld whichheisnot.Forbothcaseswecanestablishamodelthatmakesthesentencetrue.HenceweconcludethistobethecaseforJocasta.

PAGE 80

REFERENCES [1] M.Weiser,J.Brown,Designingcalmtechnology,PowerGridJournal1. [2] K.Lyytinen,Y.Yoo,Issuesandchallengesinubiquitouscomputing,CommunicationsoftheACM45200262{65. [3] F.Bolton,PureCorba,1stEdition,Sams,Indianapolis,Indiana,USA,2001. [4] M.Gudgin,M.Hadley,N.Mendelsohn,J.Moreau,H.Nielsen,Soapversion1.2part1:Messagingframework,Tech.rep.,WorldWideWebConsortium,Cambridge,MA003. [5] A.E.Walsh,UDDI,SOAP,andWSDL:TheWebServicesSpecicationReferenceBook,PearsonEducation,UpperSaddleRiver,NJ,2002. [6] L.Cardelli,A.D.Gordon,Mobileambients,TheoreticalComputerScience240000177{213. [7] R.Want,A.Hopper,V.Falco,J.Gibbons,Theactivebadgelocationsystem,ACMTrans.Inf.Syst.1019291{102. [8] G.Chen,D.Kotz,Asurveyofcontext-awaremobilecomputingresearch,Tech.Rep.TR2000-381,Dept.ofComputerScience,DartmouthCollegeNovember2000. [9] B.N.Schillit,N.Adams,R.Gold,M.Tso,R.Want,Theparctabmobilecomputingsystem,in:ProceedingsFourthWorkshoponWorkstationOperatingSystemsWWOS-IV,IEEE,1993,pp.34{99. [10] B.Brumitt,B.Meyers,J.Krumm,A.Kern,S.A.Shafer,Easyliving:Technologiesforintelligentenvironments,in:HUC'00:Proceedingsofthe2ndinternationalsymposiumonHandheldandUbiquitousComputing,Springer-Verlag,London,UK,2000,pp.12{29. [11] J.Pineau,M.Montemerlo,M.Pollack,N.Roy,S.Thrun,Towardsroboticassistantsinnursinghomes:Challengesandresults,RoboticsandAutonomousSystems42003271{281. [12] N.A.Streitz,J.Geiler,T.Holmer,Roomwareforcooperativebuildings:Integrateddesignofarchitecturalspacesandinformationspaces,in:ProceedingsoftheFirstInternationalWorkshoponCooperativeBuildings,IntegratingInformation,Organization,andArchitecture,Springer-Verlag,Berlin,Germany,1998,pp.4{21. 70

PAGE 81

71 [13] N.A.Streitz,J.Geiler,T.Holmer,S.Konomi,C.Muller-Tomfelde,W.Reischl,P.Rexroth,P.Seitz,R.Steinmetz,i-LAND:Aninteractivelandscapeforcreativityandinnovation,in:CHI'99:ProceedingsoftheSIGCHIconferenceonHumanfactorsincomputingsystems,ACMPress,NewYork,NY,USA,1999,pp.120{127. [14] W.Gale,K.W.Church,D.Yarowsky,Estimatingupperandlowerboundsontheperformanceofword-sensedisambiguationprograms,in:Proceedingsofthe30thannualmeetingonAssociationforComputationalLinguistics,AssociationforComputationalLinguistics,Morristown,NJ,USA,1992,pp.249{256. [15] G.Toussaint,Theuseofcontextinpatternrecognition,PatternRecognition101977189{204. [16] P.Brown,J.Bovey,X.Chen,Context-awareapplications:fromthelaboratorytothemarketplace,IEEEPersonalCommunications4599758{64. [17] N.S.Ryan,J.Pascoe,D.R.Morse,Enhancedrealityeldwork:thecontext-awarearchaeologicalassistant,in:V.Ganey,M.vanLeusen,S.ExxonEds.,ComputerApplicationsinArchaeology1997,BritishArchaeologicalReports,TempusReparatum,Oxford,UK,1998. [18] G.D.Abowd,A.K.Dey,P.J.Brown,N.Davies,M.Smith,P.Steggles,Towardsabetterunderstandingofcontextandcontext-awareness,in:Proceedingsofthe1stinternationalsymposiumonHandheldandUbiquitousComputing,Springer-Verlag,Berlin,Germany,1999,pp.304{307. [19] G.D.Abowd,A.K.Dey,R.Orr,J.A.Brotherton,Context-awarenessinwearableandubiquitouscomputing,in:ISWC'97:Proceedingsofthe1stIEEEInternationalSymposiumonWearableComputers,IEEEComputerSociety,Washington,DC,USA,1997,p.179. [20] B.Schilit,N.Adams,R.Want,Context-awarecomputingapplications,in:IEEEWorkshoponMobileComputingSystemsandApplications,SantaCruz,CA,US,1994. [21] A.K.Dey,D.Salber,G.D.Abowd,Aconceptualframeworkandatoolkitforsupportingtherapidprototypingofcontext-awareapplications,Human-ComputerInteractionHCIJournal160197{166. [22] D.Salber,A.K.Dey,G.D.Abowd,Thecontexttoolkit:Aidingthedevelopmentofcontext-enabledapplications,in:CHI'99:ProceedingsoftheSIGCHIconferenceonHumanfactorsincomputingsystems,ACMPress,NewYork,NY,USA,1999,pp.434{441.

PAGE 82

72 [23] J.A.Brotherton,G.D.Abowd,K.N.Truong,Supportingcaptureandaccessinterfacesforinformalandopportunisticmeetings,Tech.rep.,GeorgiaInstituteofTechnology,Atlanta,Georgia,USA999. [24] K.Nagel,C.D.Kidd,T.I'Connell,A.K.Dey,G.D.Abowd,Thefamilyintercom:Developingacontext-awareaudiocommunicationsystem,in:UbiComp'01:Proceedingsofthe3rdinternationalconferenceonUbiquitousComputing,Springer-Verlag,London,UK,2001,pp.176{183. [25] A.K.Dey,D.Salber,G.D.Abowd,M.Futakawa,Theconferenceassistant:Combiningcontext-awarenesswithwearablecomputing,in:ISWC'99:Proceedingsofthe3rdIEEEInternationalSymposiumonWearableComputers,IEEEComputerSociety,Washington,DC,USA,1999,p.21. [26] N.H.Cohen,A.Purakayastha,L.Wong,D.L.Yeh,iqueue:Apervasivedatacompositionframework,in:ProceedingsoftheThirdInternationalConferenceonMobileDataManagement,IEEEComputerSociety,Washington,DC,USA,2002,p.146. [27] N.H.Cohen,H.Lei,P.Castro,J.S.D.II,A.Purakayastha,Composingpervasivedatausingiql,in:ProceedingsoftheFourthIEEEWorkshoponMobileComputingSystemsandApplications,IEEEComputerSociety,Washington,DC,USA,2002,p.94. [28] G.Chen,D.Kotz,Solar:Anopenplatformforcontext-awaremobileapplications,in:aninformalcompanionvolumeofshortpapersoftheProceedingsoftheFirstInternationalConferenceonPervasiveComputing,Zurich,Switzerland,2002,pp.41{47. [29] G.Chen,D.Kotz,Context-sensitiveresourcediscovery,in:FirstIEEEInternationalConferenceonPervasiveComputingandCommunicationsPerCom'03,Dallas-FortWorth,Texas,USA,2003,pp.243{253. [30] G.Chen,D.Kotz,Contextaggregationanddisseminationinubiquitouscomputingsystems,in:ProceedingsoftheFourthIEEEWorkshoponMobileComputingSystemsandApplications,IEEEComputerSocietyPress,NewYork,USA,2002. [31] R.Kumar,M.Wolenetz,B.Agarwalla,J.Shin,P.Hutto,A.Paul,U.Ramachandran,Dfuse:aframeworkfordistributeddatafusion,in:ProceedingsoftherstinternationalconferenceonEmbeddednetworkedsensorsystems,ACMPress,NewYork,NY,USA,2003,pp.114{125. [32] M.Roman,C.K.Hess,A.Ranganathan,P.Madhavarapu,B.Borthakur,P.Viswanathan,R.Cerqueira,R.H.Campbell,M.D.Mickunas,Gaiaos:Aninfrastructureforactivespaces,Tech.rep.,UniversityofIllinoisatUrbana-Champaign01.

PAGE 83

73 [33] C.K.Hess,M.Roman,R.H.Campbell,Buildingapplicationsforubiquitouscomputingenvironments,in:Pervasive'02:ProceedingsoftheFirstInternationalConferenceonPervasiveComputing,Springer-Verlag,Berlin,Germany,2002,pp.16{29. [34] G.Krasner,S.Pope,Adescriptionofthemodel-view-controlleruserinterfaceparadigminthesmalltalk-80system,JournalofObjectOrientedProgramming1198826{49. [35] R.Ierusalimschy,L.H.deFigueiredo,W.C.Filho,Lua|anextensibleextensionlanguage,SoftwarePracticeandExperience261996635{652. [36] T.Gu,H.K.Pung,D.Q.Zhang.,Aservice-orientedmiddlewareforbuildingcontext-awareservices,JournalofNetworkandComputerApplicationsJNCA28051{18. [37] H.Chen,T.Finin,A.Joshi,F.Perich,D.Chakraborty,L.Kagal,Intelligentagentsmeetthesemanticwebinsmartspaces,IEEEInternetComputing8. [38] D.Cook,M.Youngblood,E.Heierman,K.Gopalratnam,S.Rao,A.Litvin,F.Khawaja,Mavhome:Anagent-basedsmarthome,in:proceedingoftheConferenceonPervasiveComputingPERCOM'2003,Dallas-FortWorth,Texas,USA,2003. [39] D.J.Cook,S.Das,SmartEnvironments:Technologies,ProtocolsandApplications,JohnWileyandSons.,Hoboken,NJ,USA,2004. [40] T.Berners-Lee,J.Hendler,O.Lassila,Thesemanticweb,ScienticAmerican279. [41] P.P.-S.Chen,Theentity-relationshipmodel,towardauniedviewofdata,ACMTransactionsDatabaseSystems19769{36. [42] J.Rumbaugh,I.Jacobson,G.Booch,TheUniedModelingLanguageReferenceManual,Addison-Wesley,Boston,MA,1998. [43] R.J.B.A.Borgida,TheDescriptionLogicHandbook,CambridgeUniversityPress,Cambridge,UK,2002,Ch.ConceptualModellingwithDescriptionLogic,pp.359{381. [44] I.S.Graham,XmlSpecicationGuide3,JohnWileyandSons,Hoboken,NJ,1999. [45] S.Powers,PracticalRDF,O'ReillyMedia,Inc.,Sebastopol,CA,2003. [46] D.Nardi,R.J.Brachman,TheDescriptionLogicHandbook,CambridgeUniversityPress,Cambridge,UK,2002,Ch.AnIntroductiontoDescriptionLogics,pp.359{381.

PAGE 84

74 [47] H.J.Levesque,R.J.Brachman,Expressivenessandtractabilityinknowledgerepresentationandreasoning.,ComputationalIntelligencejournal398778{93. [48] L.W.Lacy,Owl:RepresentingInformationUsingtheWebOntologyLanguage,TraordPublishing,Oxford,UK,2005. [49] J.P.Burgess,Basictenselogic,in:D.M.Gabbay,F.GunthnerEds.,HandbookofPhilosophicalLogic,Vol.2,Reidel,Dordrecht,TheNetherlands,1984,pp.89{133. [50] B.C.Moszkowski,Someverycompositionaltemporalproperties,in:PROCOMET'94:ProceedingsoftheIFIPTC2/WG2.1/WG2.2/WG2.3WorkingConferenceonProgrammingConcepts,MethodsandCalculi,North-Holland,1994,pp.307{326. [51] W.Thomas,Automataoninniteobjects.,in:J.LeeuwenEd.,HandbookofTheoreticalComputerScience:FormalModelsandSemantics,Vol.B,Elsevier,Amsterdam,TheNetherlands,1990,pp.133{191. [52] W.Thomas,Languages,automata,andlogic,in:G.Rozenberg,A.SalomaaEds.,HandbookofFormalLanguages,Vol.3,SpringerVerlag,Heidelberg,1997,Ch.7,pp.389{455. [53] A.Valmari,Thestateexplosionproblem,in:LecturesonPetriNetsI:BasicModels,AdvancesinPetriNets,thevolumesarebasedontheAdvancedCourseonPetriNets,Springer-Verlag,London,UK,1998,pp.429{528. [54] S.Eker,J.Meseguer,A.Sridharanarayanan,ThemaudeLTLmodelchecker,in:F.Gaducci,U.MontanariEds.,Proceedingsofthe4thInternationalWorkshoponRewritingLogicandItsApplicationsWRLA2002,Vol.71ofElectronicNotesinTheoreticalComputerScience,Elsevier,Amsterdam,2002. [55] G.J.Holzmann,ThemodelcheckerSPIN,SoftwareEngineering23997279{295. [56] L.Bolc,A.Szalas,TimeandLogic:AComputationalApproach,UCLPress,London,UK,1995. [57] I.M.Hodkinson,F.Wolter,M.Zakharyaschev,Decidableandundecidablefragmentsofrst-orderbranchingtemporallogics,in:LICS'02:Proceedingsofthe17thAnnualIEEESymposiumonLogicinComputerScience,IEEEComputerSociety,Washington,DC,USA,2002,pp.393{402. [58] S.Meyer,A.Rakotonirainy,Asurveyofresearchoncontext-awarehomes,in:ProceedingsoftheAustralasianinformationsecurityworkshopconferenceonACSWfrontiers,Vol.21,AustralianComputerSociety,Inc,Darlinghurst,Australia,Australia,2003,pp.159{168.

PAGE 85

75 [59] F.Baader,D.Calvanese,D.McGuinness,D.Nardi,P.Patel-SchneiderEds.,TheDescriptionLogicHandbook,CambridgeUniversityPress,Cambridge,UK,2002. [60] A.Artale,E.Franconi,Asurveyoftemporalextensionsofdescriptionlogics,AnnalsofMathematicsandArticialIntelligence30-42000171{210. [61] K.Schild,Combiningterminologicallogicswithtenselogic,in:EPIA'93:Proceedingsofthe6thPortugueseConferenceonArticialIntelligence,Springer-Verlag,London,UK,1993,pp.105{120. [62] J.P.Burgess,Basictenselogic,in:D.Gabbay,F.GuentherEds.,HandbookofPhilosophicalLogic,VolumeII:ExtensionsofClassicalLogic,KluwerAcademicPublishers,Dordrecht,TheNetherlands,1984,pp.89{133. [63] J.vanBenthem,TheLogicofTime,D.ReidelPublishingCompany,Dordrecht,TheNetherlands,1983. [64] E.Emerson,J.Y.Halpern,Decisionproceduresandexpressivenessinthetemporallogicofbranchingtime,JournalofComputerandSystemSciences3019851{24. [65] C.Lutz,Atableaucalculusfortemporaldescriptionlogic:Theconstantdomaincase,LTCS-Report01-01,LuFGTheoreticalComputerScience,RWTHAachen,Aachen,Germany01. [66] H.Sturm,F.Wolter,Atableaucalculusfortemporaldescriptionlogic:theexpandingdomaincase,JournalofLogicandComputation1202809{839. [67] T.Gu,H.K.Pung,D.Q.Zhang,Towardsanosgi-basedinfrastructureforcontext-awareapplicationsinsmarthomes,IEEEPervasiveComputing34. [68] M.Wooldridge,ReasoningaboutRationalAgents,TheMITPress,Cambridge,Massachussetts/London,England,2000. [69] B.Nebel,Terminologicalreasoningisinherentlyintractable,ArticialIntelligence43990235{249.

PAGE 86

BIOGRAPHICALSKETCHErwinwasborninMaarheeze,asmallvillageintheprovinceBrabantintheNetherlands.HeattendedtheUniversityofUtrechtandobtainedamasterofartsdegreeincomputerscience.Erwin'smainresearchinterestsarepervasivecomputing,articialintelligence,protocolvericationandsearchinginpeer-to-peersystems. 76


Permanent Link: http://ufdc.ufl.edu/UFE0013044/00001

Material Information

Title: Context-Driven Programming Model for Pervasive Spaces
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0013044:00001

Permanent Link: http://ufdc.ufl.edu/UFE0013044/00001

Material Information

Title: Context-Driven Programming Model for Pervasive Spaces
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0013044:00001


This item has the following downloads:


Full Text











CONTEXT-DRIVEN PROGRAMMING MODEL FOR PERVASIVE SPACES


By

ERWIN JANSEN















A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA


2005


































Copyright 2005

by

Erwin Jansen















I dedicate this work to Miss Lee, the lady who dances in my dreams.















ACKNOWLEDGMENTS

I thank Dr. Sumi Helal for his guidance and support throughout the years

that I have been a part of his lab. Without his encouragement, guidance, and belief

in success I would not have come this far. I would also like to thank Professors P.

Fishwick, M. Bermudez, G. Ritter, and B. Mann for their valuable s -l.- .- i1n,- I

thank Mr. Bowers for making all these many last-minute arrangements. I thank

Kelly Zoboroski for her love, support, and the joy in her heart that she shares

with me on a daily base. Without her I doubt if I ever would have started on this

endeavor. Finally, I thank my family for letting me go to this far-away country to

pursue my dreams.















TABLE OF CONTENTS
page

ACKNOWLEDGMENTS ................... ...... iv

LIST OF FIGURES ................... ......... viii

ABSTRACT ...................... ............. ix

CHAPTER

1 INTRODUCTION AND MOTIVATION .................. 1

1.1 Limitations of First-Generation Spaces ............... 2
1.2 Requirements for Hardware Integration ....... ..... ... 3
1.3 Programmability of a Space ......... ........ .... 4
1.4 Safety of Spaces ............................ 4
1.5 Behavior versus Information ................ .. 7
1.6 Goals ................... ...... ............ 7

2 RELATED WORK ................. ..... .......... 8

2.1 Smart Spaces ............. . . ... 8
2.1.1 Context-Aware Computing .... . ... 9
2.1.2 Middleware Architectures .... . . 11
2.2 Ontologies and Semantic Web ............. .. .. .. 12
2.2.1 Resource Description Framework .. . 13
2.2.2 Describing Domain Knowledge . . 14
2.2.3 Description Logics and the World-Wide Web . ... 16
2.3 Temporal Logic ............... ........ .. 16
2.3.1 Interval Temporal Logic ............... .. .. 17
2.3.2 Linear Temporal Logic ............... .. .. 17
2.3.3 Computational Tree Logic .............. .. .. 18

3 PROBLEM DESCRIPTION .................. ..... .. 19

3.1 Non Scalable Integration ..... .......... .... 19
3.2 Closed World Assumption ................ . .20
3.3 Fixed-Point Concepts ................ ... ... .. 20
3.4 Objectives .............. . . .. 21
3.4.1 Enhanced Programmability ................. .. 21
3.4.2 Interoperability and Extensibility . . ...... 21
3.4.3 Capability of Exception Capturing . . ..... 22









3.5 Approach ............... ......... .. 22
3.5.1 Knowledge Engineering ............ .. .. .. 24
3.5.2 Software Engineering ................ .. .. 24
3.6 Advantages .................. ......... .. .. 26
3.6.1 Explicitness .................. ....... .. 26
3.6.2 Interoperability and Extensibility . . ...... 27
3.6.3 Conflict Detection .................. .. 27
3.6.4 Capture Environmental Effect ............... .. 27
3.6.5 Automatic Tuning and Machine Learning . ... 28
3.6.6 Scalability .................. ........ .. 28


4 OBTAINING INFORMATION FROM SENSORS .


4.1 Deriving Context from Sensors Readings .. ..........
4.2 Using Ontology . . . . . . .
4.3 Temporal Context .. .....................
4.3.1 Syntax of Temporal Context .. ............
4.3.2 Semantics of Temporal Context .. ..........
4.3.3 Describing Events using Temporal Context .......
4.3.4 Computational Complexity of Temporal Context .

5 DESCRIBING ACTUATORS AND SERVICES .. ..........

6 PROGRAMMING THE SPACE .. ................


Beliefs-Desires-Intentions of Users ......
Inheritance and Override .. .........
Scenario and Programming Procedures .
6.3.1 Lightening Control Application ..
6.3.2 Describing Context .. ........
6.3.3 Associating Behavior .. .......
6.3.4 Connecting Sensors .. ........


7 INTEGRATED DEVELOPMENT ENVIRONMENT .. .........

7.1 Design of the Context Graph .. .................
7.2 Interpretation of Sensor Readings .. ...............
7.3 Desired Behaviors under Each Context .. ............
7.4 Mapping Physical Sensors and Actuators to the Context Model .
7.5 Implementation of the IDE .. ..................
7.5.1 Premise and Platform Selection .. ............
7.5.2 Requirement Analysis .. .................
7.5.3 Enabling Middleware Runtime .. .............









7.6 Components of the IDE ............... .. .. .. 56
7.6.1 Entity Definition View ............... .. 56
7.6.2 Behavior Definition View ............... .. .. 57
7.6.3 Impermissible Context C! : i . . .... 58
7.6.4 Communication Module ............. .. .. 58

APPENDIX DESCRIPTION LOGICS .................. .. 61

A.1 Describing Intensional Knowledge ................. .. 61
A.2 Terminologies .................. .......... .. 64
A.3 Extensional Knowledge .................. .... .. 65
A.4 Reasoning .................. .......... .. 65
A.5 Open-World versus Closed-World Assumption . ... 67

REFERENCES ............. .. ............ ... 70

BIOGRAPHICAL SKETCH .............. . .. 76















LIST OF FIGURES
Figure page

1-1 Safety versus programmability .................. 6

2-1 Knowledge network ............... ........ .. 15

3-1 Negative interaction between entities ................. 25

4-1 Indoor and outdoor sensors .................. .... .. 34

4-2 A sequence denoting someone entered the house ........... ..35

4-3 Actual sequence of events .................. ...... .. 38

6-1 A sample context graph .................. ..... .. 49

7-1 Interaction between components .................. .. 55

7-2 Entity definition view .................. ...... .. .. 57

7-3 Context browser .................. ........... .. 58

7-4 Impermissible context verification ................ 60

A-1 Open world versus closed world .................. ... 69















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Phil. .. 1hi

CONTEXT-DRIVEN PROGRAMMING MODEL FOR PERVASIVE SPACES

By

Erwin Jansen

December 2005

C'!I ,i: Abdelsalam (Sumi) Helal
Major Department: Computer and Information Science and Engineering

Our aim was to establish a programming model that can be used by developers

who build pervasive applications. Currently there is little to no support for

programming pervasive spaces. Every solution is still an ad-hoc solution.

Our programming model acknowledges a relationship among sensors,

actuators, and software. By making this relationship explicit, we derived a

programming model that is geared toward describing knowledge and defining

goals. A goal can be accomplished by invoking a series of actuators.

We divide the software-engineering process into two distinct phases. In one

phase we are concerned with describing behavior. An engineer specifies how a

service operates to achieve a particular goal. The other phase is the description of

what the service tries to accomplish.

It also allows us to reason beforehand about the effect of the invocation of

a set of services. This in turn helps a developer determine whether two services

intend to accomplish similar goals. This is similar to type-checking, which greatly

reduces programming mistakes.









The vision of this technology is that, in the future, you would buy an actuator,

or software service, that contains a standardized description of its intentional

effect on the world. With this description, the house can use the service to avoid

undesirable contexts. This directly ties in with our Self-Sensing Spaces and Smart

Plug work.















CHAPTER 1
INTRODUCTION AND MOTIVATION

Interest in the area of ubiquitous computing has grown in the last few years.

The idea behind ubiquitous computing is that the technology should be calm [1],

meaning that many computers are available throughout the physical environment,

making them effectively invisible to the user [2]. Hence ubiquitous computing

is sometimes called pervasive computing. It is considered the third wave of

computing.

Ubiquitous computing is characterized by the "anywhere, any time, any

ii. ii- paradigm. Anywhere, at any time, and by any means, a user should be

able to perform computations that help the user to accomplish his or her goals. For

this to happen many different technologies come together. Hardware must provide

interaction with the environment (bluetooth, GPS, etc.), and software is needed

that interacts and coordinates with the hardware (OSGi, Jini, CORBA, SOAP,

WSDL, etc.) [3, 4, 5].

We consider a smart space to be an ambient [6], in the sense that there is

a boundary that determines what is part of the smart space, and what is not.

Inside the smart space, computations take place, to assist the users of the space. A

pervasive space consists of a collection of devices and software that controls these

devices. Devices that sense the environment are called sensors. Devices that can

change the environment are called actuators.

Sensors sense a particular value in a particular domain, and provide

information on a very detailed level. A temperature sensor might tell us that it

is 95F, or a light sensor might tell us that there is 10,000 lux of light coming

through the window. However, we are generally not interested in the direct sensor









values, but rather in a high-level description of the state. We want to know

that the weather is "hot" and "sunny" outside. The states "hot" and "sunny"

encompass a range of temperature and luminescence values. Hard-coding behavior

for each possible combination of relevant sensor values is difficult to implement,

difficult to debug, and difficult to extend. Working with generalizations is much

easier.

Actuators are physical devices with which we can interact. An actuator is

capable of changing the state of the world. Sensors, in turn, may observe the effect

of an actuator. A light sensor may observe that the smart house (or the resident)

turned on a lamp. Based on the observed state of the world, the house or the

resident might decide to activate an actuator.

Most research projects that involved ubiquitous computing have been pilot

projects that show that pervasive computing is usable. The Active Badge [7]

system used badges that transmitted IR-signals to track the location of various

persons. This location information was then used to route calls for persons to the

nearest phone.

1.1 Limitations of First-Generation Spaces

The in i i i ly of pervasive computing research so far has focused on system

integration. Most of these are pilot projects demonstrating that pervasive

computing is useable (overview [8]). In general, these pilot projects represent

ad-hoc, specialized solutions that are not easy to replicate.

Unfortunately, many of these first-generation pervasive computing systems

lack the ability to evolve as new technologies emerge or as an application domain

matures. Integrating numerous heterogeneous elements is mostly a manual, ad

hoc process. Inserting a new element requires researching its characteristics and

operation, determining how to configure and integrate it, and tediously and









repeatedly testing to avoid causing conflicts or indeterminate behavior in the

overall system.

Integration of new devices does not scale well with this approach. In the worst-

case scenario the adding of a new device means reconfiguring n existing devices.The

environments are closed, limiting development or extension to the original available

devices or software entities.

1.2 Requirements for Hardware Integration

The devices themselves must be able to integrate and adapt to the relevant

circumstances in the space. For devices to be able to integrate there must be

a uniform way to interact with the devices. This uniform way of interaction is

accomplished by a middleware 1-.-r that creates abstractions for the various

available devices. Heterogeneous devices can now be accessed in a uniform way.

The requirements for the middleware lI,-r ar ase follows,

Open: A wide range of diversity inherent in the future pervasive computing

environments, the openness is one of key requirements. The environment

is made up of tiny sensors, mobile devices, and full-fledged computers from

diverse sources. Therefore, the middleware architecture must be open and

flexible to embrace a variety of entities without any special favor towards

particular participants or target domains.

Extensible: The middleware should be able to support a dynamic build-up

of middleware itself, new middleware components can be incorporated,

components can be upgraded or replaced and unnecessary components can

be removed from the middleware. All these changes must be possible without

requiring down-time for the whole middleware. The middleware itself evolves

over time, and it is can cope with new technologies and requirements.

Adaptive: The middleware should be able to adapt to the changing

environments. In other words, the middleware should reconfigure itself









in accordance with changes in the space (through the above component

addition, upgrade, and replacement); and should provide a mechanism by

which applications can adapt themselves to these changes.

Self-integrative: The middleware should enable a joining entity to explore

the middleware environment and support a mechanism by which it can

participate in the middleware. In other words, the zero-configuration style

support is necessary to automate the joining process.

1.3 Programmability of a Space

The middleware lv-r alone is not sufficient. The whole aim of this exercise is

to provide a programming model for software engineers. The programming model

determines how engineers will interact and develop software for the middleware

1~ iv-. A programming model allows complex systems to be understood and their

behavior predicted within the scope of the model.

On top of the programming model we aim to build an interactive (or

integrated) development environment (IDE). The IDE needed to be a system

for supporting the process of writing software for pervasive space. Such a system

may include a syntax-directed editor, graphical tools for program entry, and

integrated support for compiling and running the program and relating compilation

errors back to the source. The goal was to give programmers a clear model and

visual tools for programming the actual pervasive space.

1.4 Safety of Spaces

In traditional computing systems, such as the desktop pc, there is hardly any

interaction with physical devices. In general there are few input devices, and few

output devices (I/O devices). A monitor, speakers, keyboard, and mouse sums up a

traditional desktop system.

The problem of modeling I/O devices is that they have side effects: specifically

they change the state of the system, unlike referentially transparent expressions.









Furthermore, I/O operations are not guaranteed to succeed. Failures can occur,

and dealing with these failures is awkward. Modern programming languages

provide for exceptions to deal with these exceptional cases. Since few I/O devices

affect the actual world, there is no serious concern about conflicting effects on the

physical world.

However, as soon as we start to introduce more devices in a space controlled

by computers, this does become an issue. A disastrous example would be a

computer that decides to turn off the sprinkler system in case of a fire.

Software components are regularly in conflict with one another. A very well

known recent example is that the installation of N. i ipe 8 will break Internet

Explorer Users accept these software flaws with little complaints. Users are

unlikely to accept the sprinkler error. Unexpected behavior, or software errors, are

far less acceptable in pervasive spaces, especially when they negatively affects the

quality of life.

A pervasive space is safe if we are certain that the space will never move

to an undesirable state because of an automated invocation of an actuator. The

computer should never perform an action that leads to an undesirable state. Since

a computer can only change the state of the space using actuators we can make the

following divisions in safety:

Non-pervasive: A space that does not contain any computational devices

controlling the environment. Every change in the state of the environment is

because of to the activity of a living entity.

Observational Pervasiveness: A space that only contains sensors. The sensors

provide information about what is taking place inside the space, but nothing

will be done to alter the state of the space.

Guarded Pervasiveness: Apart from sensors the space contains actuators that

can change the state of the space. The actuators are limited as follows:










If the actuator fails to operate, the space does not change. An example

is a lamp. If the light-bulb is broken, turning on the lampe will not

change the state of the space.

The space can accurately predict the next state before this state arises.

For example if we turn on the lamp, we can predict that there will be

light.

The space can derive if a service will activate an actuator. Every

software component is capable of reporting which actuator it will

activate and under which circumstances.

Unguarded Pervasiveness: The space contains sensors as well as actuators.

However the space is not able to determine whether or not a service will

invoke an actuator. The space is not ahv--, capable of predicting the next

state of the space.

This division has consequence of the power of expression that the language

we are using has. The requirement to predict the possible outcome of an action

within a limited amount of time has implications for the expressiveness of the

programming language. If it takes 0(2") to determine the next state of the space

it is unlikely the space will be capable to predict the next state of the space in a

timely fashion.

Non-Pervasive
Safety
Observational

Restricted

Unrestricted




Programmability


Figure 1-1: S ,f. I v versus programmability









To guarantee safety of the pervasive space we consider a programming model

that is expressive enough to write programs, yet restricted so we can guarantee that

state of the space is not undesirable.

1.5 Behavior versus Information

Our approach to guarantee safety is by making use of descriptions of the

various available software and hardware components. We describe components

using a temporal ontology. This temporal ontology is used to interpret the state of

the space and to describe how service change the state of the space.

We separate the development process of software into two phases. The first

phase deals with traditional software engineering. The other phase deals with

knowledge engineering. In the software engineering phase we describe behavior

whereas in the knowledge engineering phase we describe information of relevance.

1.6 Goals

The aim of our research was to establish a programming model that can be

used by developers that build pervasive applications. Currently there is little to

no support for programming pervasive spaces. The area is still in the stage where

every solution is ad-hoc.

The programming model we introduce is based on the relationship between

sensors, actuators and software. By making this relationship explicit we can derive

a programming model geared towards describing knowledge and defining goals. A

goal can be accomplished by invoking a series of actuators.

It also allows us to reason beforehand about the effect of the invocation of

a set of services. This in turn helps a developer determine whether two services

intend to accomplish similar goals. This is similar to type-checking, which greatly

reduces programming mistakes.















CHAPTER 2
RELATED WORK

In recent years ubiquitous computing has received an increasing amount of

attention in the academic community. Here we will review some of the work that

has received a lot of attention over the last decade.

2.1 Smart Spaces

The PARCTAB [9] system consists of palm-sized mobile computers that

can communicate wirelessly through infrared transceivers to workstation-based

applications. The system provided location information to the user, helped to find

resources and acted as a remote control for various devices.

The Active Badge [7] is a system that keeps track of the location of a person

using badges that transmitted an IR-signal. The telephone receptionist could find

out where a person was and direct the call to an appropriate phone. Many consider

the PARCTAB and Active Badge projects to be the first examples of pervasive

computing. These projects showed how computation can be "calmly" integrated in

the environment.

Microsoft's Easy living project [10] focuses on home and work environment.

The easy living room is aware of the location of people in the room and uses this

information for access to computational devices. The space recognizes users and

gestures and uses this information to adjust the state of the room accordingly.

Pearl [11] is a nursing robot that assists elderly with mild cognitive

impairments. It has an automatic tracking and detection system for persons. The

system reminds the elder of events and can guide them through the environment.

The Roomware and i-Land [12, 13] projects aim to integrate information

technology into room elements as, walls, doors, and furniture. Roomware









components are interactive and networked; some of them are mobile due to

independent power supply and wireless networks, and are provided with sensing

technology. The focus on these projects seem to lean more towards the hardware

aspect of pervasive computing.

Context aware computing is a computing paradigm in which applications can

discover and take advantage of contextual information. This could be temperature,

location of the user, activity of the user, etc. The definition of context is rather

vague and various researchers give different definitions of context. In this chapter

we will examine the various definitions and define the key ingredients of context

awareness.

2.1.1 Context-Aware Computing

Context is a concept that has been hard to grasp. In general we can consider

that context uses external information to identify the current meaning of an object.

In language for example context is used to disambiguate certain words [14], whereas

in vision recognition it is used to fill in blanks in interpretation [15]. In the area of

ubiquitous computing there are many different definitions in use.

Early researchers in the field define context by the following characteristics:

a user's location, environment, identity and time [16, 17]. This view on context is

rather application specific. Abowd et al, [18] defined context as follows:

Context is any information that can be used to characterize the

situation of an entity. An entity is a person, place, or object that

is considered relevant to the interaction between a user and an

application, including the user and application themselves.

Similarly C(! i1 and Kotz [8] defined context as:

The set of environmental states and settings that either determines an

application's behavior or in which an application event occurs that is

interesting to the user.









They also make a distinction between active and passive contexts, where the

first influences the behavior and the second is relevant, but not critical.

In the last decade we have seen various projects that take the first steps at

context aware computing in the field of pervasive computing [19, 20]. Many of

these applications were pilot projects that demonstrated the use of context and

used to investigate the usage, limits and benefits of context aware computing. Due

to the success of these applications a need arose for a framework for context aware

computing.

The context toolkit [21, 22] is a java toolkit that addresses the distinction

between context and user input. The context consists of three abstractions:

widgets, .,. i--regators and interpreters. Context widgets encapsulate information

about a single piece of context, .,.--oregators combine a set of widgets together

to provide higher level v.Id;- I and interpreters interpret both of these. An

interpreter for example can use the identity and location widget to derive that "Dr.

Helal is in his office". The aim of the toolkit is to hide the complexity of obtaining

sensor information. The context toolkit has proven its value in various applications

that have been built with it [23, 24, 25].

iQueue [26] and iQL [27] are a programming model and language for

composing higher level data from low-level raw data. The difference between

iQueue and iQL is that the first one is an implementation of the model in java,

whereas the latter is a specific programming language resembling a functional

language.

The programming model is based upon so called composers that contain a

current value computed from input values. These values in term stem from various

data sources (i.e., sensors), or other composers. The runtime system then advertises

these composers to external sources.









Every source can either act passively, producing data only on request, or

actively producing data whenever new data is available. Using these composers

we can construct an .,11 ,l 1i: di-graph, often referred to as context 'ji''l where the

nodes contain functions that produces values for the nodes higher up in the graph.

Similar to the approach described above is the Solar framework [28, 29, 30].

Solar allows resource to advertise context sensitive names and for applications

to make context-sensitive name queries. The main aim of the frameworks is that

resources can advertise their existence, that others can find the resources and that

context-aware applications may indicate how to derive their desired context from

these sources.

Solar provides a similar mechanism as iQL for the derivation of high-level

data from low level sources. On top of this they provide a querying mechanism for

retrieving context information.

DFuse [31] is another example of a technology that allows the construction and

evaluation of a context graph. The DFuse architecture is geared towards mobile

devices optimizing it for power consumption.

2.1.2 Middleware Architectures

GaiaOS [32, 33] is a component based middleware operating system running on

top of an existing operating system. The GaiaOS provides a set of basic services,

such as discovery, security, as well as an application model. The application model

provides a mechanims to build applications for ubiquitous computing scenarios.

GaiaOS is based upon the Model-View-Controller [34] paradigm. However, instead

of the traditional notion of a controller gaia makes use of a component adapter

that is responsible for adapting the format of the model data to an arbitrary

output device. Gaiao makes use of a scripting language,called lua [35] to do service

composition and event handling. Gaia is intended to be a general computational

environment.









The SOCAM architecture [36] is a middleware 1-v r that makes use of

ontologies and predicates. There is an ontology describing the domain of interest.

By making use of rule based reasoning we can then create a set of rules to infer the

status of a an entity of interest. Their research shows that ontologies are usable but

require some computation power and hence are not suitable for smaller devices.

The CoBra architecticture [37] is a broker center agent architecture. At the

core is a context broker that builds and updates a shared context model that is

made available to appropriate agents and services.

The MavHome project [38, 39] views the smart home as an intelligent agent

that perceives its environment through the use of sensors, and can act upon the

environment through the use of actuators. The home has certain overall goals, such

as minimizing the cost of maintaining the home and maximizing the comfort of its

inhabitants. In order to meet these goals, the house must be able to reason about

and adapt to provided information. Their approach is based on machine learning

and optimization techniques.

2.2 Ontologies and Semantic Web

Most of the information that is accessible through the world wide web is in the

html format. This format is geared towards the layout of information on a screen.

It does not contain information about the meaning of the document that is being

di -i1 -, il. This is currently a big obstacle in retrieving information on the web.

Much effort is being put in developing the so called 11 il v- I' According to

[40]:

"The Semantic Web is an extension of the current web in which

information is given well-defined meaning, better enabling computers

and people to work in cooperation."

The vision is that we associate meaning with documents in such a way that it

can be processed by machines. In order to accomplish this we need a mechanism









to describe information. This can be done by associating meta information with

the documents that we store, or by providing an ontology that gives meaning of the

concepts used in a particular domain.

We are trying to create a model of the world in symbolic structures that

can be processed by a computer. We call this a conceptual model of the world.

Conceptual models are well know in the field of computer science, ranging from

the entity relationship model [41] to UML [42]. These conceptual models provide

abstraction mechanisms that result in a structured information model [43].

The semantic web builds extensively on XML (a simple extensible mark up

language), RDF (an XML language to describe resources) and OWL (a RDF

language to describe ontologies). In the following subsections we will investigate

these various technologies. We assume the reader is familiar with XML [44].

2.2.1 Resource Description Framework

The Resource Description Framework [45] (RDF) is a language for representing

information about resources in the World Wide Web. By generalizing the concept

of a \\. I resource", RDF can also be used to represent information about things

that can be identified on the Web, even when they cannot be directly retrieved on

the Web.

The idea behind RDF is that we can describe resources by making statements

about these resources. The statements that we make consists of properties with

values that describe a particular resource. This is done by associating two objects

together with a predicate. The part that we are describing is called the subject. It

is associated with another object through a predicate, that describes the subject.

Take for example the following English sentence:

http://www.cise.ufl.edu/people/ci i-,-, ii has a creator Erwin Jansen

We can see the following relationships:

the subject is the URL http://www.cise.ufl.edu/people/ei ii-, i









the predicate is the word "creator"

the object is the phrase "Erwin .1 i-, i,

RDF can be used to describe any relationship we want using the appropriate

predicate. These descriptions are given in an XML language, and hence are easily

processed by computers.

However the freedom RDF gives introduces a new problem. How are we

going to pick appropriate predicates and how do we interpret these predicates.

Anyone can make arbitrary predicates, but we do not have any computational

guarantees whatsoever that we are able to deduce any valuable information from

our descriptions.

Drawing conclusions from a set of rdf statements might not be feasible in a

limited amount of time. Although RDF is a good start for describing resources,

it leaves us with too much freedom. We need a way of describing knowledge with

better computational guarantees, such as a description logic.

2.2.2 Describing Domain Knowledge

A mechanism for describing knowledge are so called description logics [46].

Which we shall briefly discuss here.

Description logics are knowledge representation languages tailored for

expressing knowledge about concepts and concept hierarchies. They are usually

given a Tarski style declarative semantics, which allows them to be seen as sub-

languages of predicate logic. They are considered an important formalism unifying

and giving a logical basis to the well known traditions of semantic networks,

object-oriented representations, semantic data models, and type systems.

The basic building blocks are concepts, roles and individuals. Concepts

describe the common properties of a collection of individuals and can be considered

as unary predicates which are interpreted as sets of objects. Roles are interpreted










hasChild
(1,NIL)
as binary relations between objects. For exValue in figure 2 1 there is the role of a
Person Vl
e t t h restrictions


Female



Parent
is n Womanwo




Mother IS-a


Figure 2-1: Knowledge network


as binary relations between objects. For example in figure 2-1 there is the role of a

parent, expressed through the hasChild relationship.

Each description logic defines also a number of language constructs (such

as intersection, union, role quantification, etc.) that can be used to define new

concepts and roles. We could express the concept of a father as being a parent that

is not a woman.

Description logics can be translated into a subset first order predicate

logics. For example the expression Person and Woman can be translated into

Person(x) A Woman(x), where x is a variable that ranges over all the individuals

in the interpretation domain and C(x) is true for all x that belong to context C.

Note that first order logic (FOL) is not decidable, but that description logics are a

subset of fol that is decidable.

The main reasoning tasks are classification and satisfiability, subsumption and

instance checking. Subsumption represents the is-a relation. Classification is the

computation of a concept hierarchy based on subsumption.

There is a tradeoff we must make between the expressiveness of our description

logic and the time complexity of deriving knowledge. The more expressive our









language is, the more time it will take to compute whether or not a sentence is

valid [47].

2.2.3 Description Logics and the World-Wide Web

OWL [48] is a description logic that based on RDF. Using OWL we can

describe an ontology. There are three versions of owl, each with different

computational guarantees.

OWL Lite: Owl lite is primarily used for definining a classification hierarchy

and simple constraints. For example, while it supports cardinality constraints,

it only permits cardinality values of 0 or 1. Owl Lite has a lower formal

complexity than OWL DL.

OWL DL: Has maximum expressiveness while retaining computational

completeness (all conclusions are guaranteed to be computable) and

decidability (all computations will finish in finite time). OWL DL includes

all OWL language constructs, but they can be used only under certain

restrictions. OWL DL is a description logic.

OWL Full: OWL Full is meant for users who want maximum expressiveness

and the syntactic freedom of RDF with no computational guarantees. OWL

Full allows an ontology to augment the meaning of the pre-defined (RDF or

OWL) vocabulary. It is unlikely that any reasoning software will be able to

support complete reasoning for every feature of OWL Full.

2.3 Temporal Logic

In logic, the term temporal logic is used to describe any system of rules and

symbolism for representing, and reasoning about, propositions qualified in terms

of time. It is sometimes also used to refer to tense logic, a particular modal logic-

based system of temporal logic introduced by Arthur Prior in the 1960s. For an

introduction to tense logic see [49].









An example would be the temporal statement "Erwin is writing his

dissertation". Although the interpretation, or meaning, of this sentence does

not change over time the truth value will most definitely vary as time progresses.

In temporal logic the truth value can vary over time.

Temporal logic can be used to reason about how a system behaves over time.

There are three variants that have found widespread usage:

2.3.1 Interval Temporal Logic

Interval Temporal Logic (ITL) is a flexible notation for both propositional and

first-order reasoning about periods of time found in descriptions of hardware and

software systems. Unlike most temporal logics, ITL can handle both sequential

and parallel composition and offers powerful and extensible specification and proof

techniques for reasoning about properties involving safety, liveness and projected

time [50].

Since ITL is based on intervals and their sequences, it is possible to describe

both concurrent and serial behaviors by specifying behaviors inside intervals and

sequences among them. Unfortunately a full set of ITL does not have a decision

procedure. However a subset does.

2.3.2 Linear Temporal Logic

Linear Temporal Logic (LTL) is a logic that extends propositional logic with

two operators that deal with time. These operators are the unary next and binary

until operator. The next operator specifies that a formula will hold in the next

state, whereas the until operator expresses that a formula is at least true until the

other formula becomes true. From these one can derive operators as eventually and

alh--i-. LTL deals with the existence of only one possible future path.

An LTL formula can be translated into a deterministic finite state automaton

(DFA) [51]. This approach has been used to determine whether or not the LTL

formula is satisfiable. The LTL formula is translated into an equivalent DFA









and one verifies if this DFA accepts the empty language. If so, there is no model

satisfying the formula. The good news is that the LTL problem is decidable, the

negative result is that it is NP complete, this is evident since 3-sat is contained in

LTL.

This is reflected in a state explosion that occurs during this translation from

an LTL formula to a DFA [52, 53], making it very expensive to establish this

correctness.

However various verification tools, such as Maude [54] and Spin [55], are

capable of verifying the satisfiability of not overly complex LTL formulas. Although

the problem is NP complete the algorithms used have been proven to work well for

many practical problems.

2.3.3 Computational Tree Logic

Computational Tree Logic [56] (CTL) can be seen as an extension of LTL.

Apart from temporal operators we also introduce unary path operators all and

exists. The all operator expresses that for every possible path in the future the

formula holds, whereas the exists operator expresses that at least one path exists

for which the formula holds.

This extends the notion of time with a set of possible branches over possible

futures. Surprisingly the satisfiability problem of a CTL formula is decidable as

well [57].















CHAPTER 3
PROBLEM DESCRIPTION

Research groups in both academia and industry have developed prototype

systems to demonstrate the benefits of pervasive computing in various

application domains. These projects have typically focused on basic system

integrationinterconnecting sensors, actuators, computers, and other devices in the

environment.

Unfortunately, many first-generation pervasive computing systems lack the

ability to evolve as new technologies emerge or as an application domain matures.

Integrating numerous heterogeneous elements is mostly a manual, ad hoc process.

Inserting a new element requires researching its characteristics and operation,

determining how to configure and integrate it, and tedious and repeated testing

to avoid causing conflicts or indeterminate behavior in the overall system. The

environments are also closed, limiting development or extension to the original

implementers.

3.1 Non Scalable Integration

Any pervasive system is bound to consist of numerous heterogeneous elements

that require integration. Unfortunately, the system integration task itself, which

is mostly manual and ad hoc, usually lacks scalability. Theres a learning curve

associated with every element in terms of first understanding its characteristics and

operations and then determining how best to configure and integrate it.

Also, every time you insert a new element into the space, there the possibility

of conflicts or uncertain behavior in the overall system. Thus, tedious, repeated

testing is required, which further slows the integration process. Consider a









temperature sensor that needs to be connected to an embedded Java program

to periodically report a refrigerated trucks temperature.

3.2 Closed World Assumption

Another problem is that an integrated environment is a relatively closed

systemits not particularly open to extensions or expansion, except perhaps

accidentally. Its tightly coupled to a combination of technologies that happened

to be available at development time. Its thus difficultif not impossible to add new

technologies, sensors, and devices after system integration is complete.

An integrated environment is also closed and restricted to only a few

participants the designers, system integrators, and users. Theres no easy way

to let a third party participate. For example, an energy- and utility-efficient smart

home developed in 2005 might not be compatible with a utility-saving sprinkler

system developed in 2006 by a third-party vendor.

3.3 Fixed-Point Concepts

Also problematic is the fact that our experience in building integrated

environments is limited by the set of concepts we know at the time of development.

This might sound like an alh--, i-true statement regardless of whether were

doing pervasive, mobile, or distributed computing, but its especially troubling

in pervasive computing. Take smart homes, for example. Unlike Nokia phones,

you cant upgrade and replace them every six months. Once built for a specific

goal (such as to assist the elderly or handicapped, save power, or support proactive

health for an entire family), the home will likely be used for decades to come.

Thats why we need to ensure that our smart spaces will be compatible with

not-yet-developed concepts. This might not be realistic, but smart pervasive spaces

are bound to outlast any known set of pervasive computing concepts. Service

gatev--,si and context awareness are two examples of recent concepts that have









steeply influenced how we think of pervasive computing. Surely other new concepts

are on the horizon.

3.4 Objectives

The goal of our research is to present a prototype middleware 1l- -r and ide

capable of remotely browsing current available entities in a smart environment,

such as sensors, smart appliances or services, in a smart space, providing

information about the capabilities of these entities, offering programming tools

and assistance to guide the implementation of new services and avoid restrictions.

We will address the issues of enhanced programmability, interoperability and

exception capturing.

3.4.1 Enhanced Programmability

Once the components such as sensors, actuators, and smart appliances,

are in place, the programmer should be able to program the smart space by

pro-actively or reactively specifying predefined behavior under various contexts

for these components. The programming model should provide guidance and

warnings throughout the development cycle, including programming, debugging

and deployment phases. It should provide assistance to allow programmers to

focus on programming the behavior of the house, not bothered by technicalities of

writing bundles or agents.

3.4.2 Interoperability and Extensibility

It is crucial that the effects of the newly introduced, altered, or eliminated

entities or services be reflected in the programming model, and brought to the

attention of the system designer or developer. The programming model should

guarantee that the introduction of new services or device will not disrupt the

already existing devices or services or will alert the developer and resident that the

new service will cause a disruption and under which circumstances.









3.4.3 Capability of Exception Capturing

This programming model should be able to capture contradictory instructions

or context specifications during the implementation process. The model should be

able to capture design flaws and conflicts at both design and implementation stages

before being deploy, -1 to and activated in the real smart house environment.

3.5 Approach

The most prevalent, current, programming paradigms deal with behavior

descriptions. Whether the programs or applications run on a mainframe, PC or

embedded computers, this paradigm requires software engineers or programmers to

describe how a software artifact behaves by writing the code accepting a given set

of input parameters, while the implementation must follow a set of syntactic and

semantic constraints specified for a specific programming language. To assist others

in understanding what this software does, it is usually a good practice to name

this artifact meaningfully such as quickSort or contextInterpreter instead of

procedureA.

There are obvious shortfalls with this approach. The naming of these software

artifacts is subject to interpretation by the reader, and unless tracing through

every single line of code in this artifact, there is no way of knowing whether it

actually delivers what its name implies. In short, programmers encapsulate the

behaviors into these software artifacts, and bystanders most likely would take their

name value as the expected behavior. The implicit nature of these descriptions

of behavior becomes especially troublesome in pervasive computing spaces, since

they are much more open with almost unlimited potential devices and operations.

The fact that smart spaces can actually alter the state of the world is even more

unnerving if programmers can only guess what a particular software artifact can

and will do by just looking at its name.









Making existing components aware of newly introduced components is a

challenge by itself. For existing components to understand the capabilities of

these new components is a further challenge. Thus, it is only natural to find the

need to describe the effects of the invocation on a particular component. It would

then allow reasoning about the behavior of the new component. The description

of components should use terms that are commonly understood, in essence. An

ontology that is agreed upon is key.

Context driven approach is our attempt to make knowledge explicit. By

describing possible contexts in a smart house using standard ontology, the runtime

system, as well as any bystanders, can now unambiguously identify which contexts

are currently in effect. By defining which actions to take based on what the

current contexts are, the knowledge of the behavior of the system is made explicit,

in contrast to being implicit in traditional programming. This explicitness is

important for several reasons in an open and constant changing system such as a

smart space.

First, the entities such as sensors and actuators, both new and ::i-I i- behave

based on the explicitly defined behavior in context graphs. Thus no guessing is

necessary when it comes to cooperation,

Second, since there is no ambiguity in what the current effective contexts

are, and all potential actions are explicitly defined, conflicting behaviors and

impermissible contexts can be easily checked.

We address the non-scalability and closed world issue by explicitly describing

what a device or service is capable of. This description assures that there is

no second guessing on the programmers part. If a service or device violates

its description it can be detected immediately and appropriate actions can be

undertaken,









The separation of this knowledge definition and the availability of the entities

in smart houses also greatly enhance its capability to adapt to ever changing nature

of open smart spaces hence addressing our third issue of fixed point concepts.

3.5.1 Knowledge Engineering

Knowledge engineering is concerned with the definition of context information,

actuators and the relationship between them. During this stage we define how we

can derive context from the various sensors. This usually means that we construct

a ::.;.i, ion- and identify how the actuators can influence the various available

sensors. This phase is also concerned with identifying which actuator activations

are valid under which context. The aim of this phase is to identify potentially

dangerous situations and to prevent them by restricting certain operations in a

context. For example, we can restrict the activation of a kitchen burner whenever

we are not in the kitchen.

Apart from identifying context, we also need to define which behaviors are

associated with a context. This involves identifying which behaviors are started and

which ones are terminated upon entering and leaving a context. This is also the

place where we can install behavior that will be invoked whenever an agent tries to

activate an actuator that has been restricted.

3.5.2 Software Engineering

The software engineering phase, on the other hand, is concerned with the

definition of behavior. Here we define how various software agents (or services) can

interact with each other and how they can activate actuators. The main difference

between an actuator and agent is that the latter can never change the physical

state of the world; it will need a cooperating actuator to accomplish a state change

of the physical world. For example, a DJ agent would organize the electronic music

collection of its owner, but will invoke an actuator, such as the stereo, to actually

p i-, the music. The interaction with actuators is not guaranteed to succeed. If the










context prohibits the activation of an actuator the application will be notified. The

application can now decide to take care of the problem itself, or hand it over to the

smart space.

Consider the example of Figure 3-1, if someone is taking a shower and another

person in the same apartment wants to flush the toilet. In most cases flushing the

toilet will lead to a decrease in the amount of cold water available for the shower,

which then in turn can make the shower too hot. In this scenario, flushing the

toilet will lead to a situation that is not allowed. The smart space can now invoke a

handler that reduces the hot water, preventing the undesired situation.


SShower Temperature Toilet

Lowers
Raises
Rase -Activates
Hot Water Flush


Figure 3-1: Negative interaction between entities


In summation, our programming model captures:

Knowledge: This concerns the writing and construction of context

information. Construction of context consists of five parts:

Defining conceptual model of the space: A conceptual model, or

,ii::,niv, is an interpretation of the space in terms of higher level

concepts. These concepts capture the possible states of the space by

interpreting sensor values. For example we can define that a room

can be warm or cold. This conceptual model specifies the users

understanding of the space.

Defining desires of a user: A user in a space has certain desires about the

state of the space. These desires are expressed in terms of the conceptual









model. For example a user could prefer a warm room over a cold room

during winter, but a cold room over a warm one in summer.

Defining handlers for invalid activities: A programmer can couple

behavior to the invocation of invalid actuators. If the space detects an

inconsistent state of the space an appropriate handler should be invoked

to either inform the user or to rectify the situation. For example if the

space detects that the house is on fire it should inform the authorities.

Defining actuators and relationships with sensors: The programmer

needs to identify which actuators are available in a smart space and

specify what kind of relation there exists between the actuators and the

sensors. For example a heater has an effect on a heat sensor. Describing

this relation allows the space to reason about the effect of activating

that actuator.

Behavior: This is the classical software engineering

Defining behavior: A programmer implements certain behavior. This is

the actual implementation of a service. For example a climate control

system that is capable of keeping the room temperate at a certain

setting.

Associating behaviors with context: A programmer needs to identify

which sets of behaviors need to be activated when a context becomes

active, in order to satisfy the desires of the user.

3.6 Advantages

The approach that we take has several advantages which we will discuss here.

3.6.1 Explicitness

The 'i.--.- -1 advantage of context driven programming model resides in its

explicitness. By describing possible contexts in a smart house using description

logic, the middleware runtime and bystanders can all unambiguously identify which









contexts are currently active. By defining actions to take based on the currently

active contexts, the knowledge on the behavior of system is explicit, contrasting

to the encapsulated function calls of traditional programming. This is of great

importance since the state of the space is meaningful and essential to its residents.

3.6.2 Interoperability and Extensibility

Entities such as sensors and actuators, both new and ::i-l ir- behave based on

the explicitly defined behavior in the description logic so no guessing is necessary

when it comes to collaboration and integration. The explicitness greatly promotes

extensibility and interoperability in an open and constantly changing system

such as a pervasive space. The separation of the knowledge definition and the

availability of the entities in the space greatly enhance its capability to adapt to its

changing configurations.

3.6.3 Conflict Detection

Because there is no ambiguity in identifying which contexts are active, and the

associated actions to take are explicitly defined, context-driven model is extremely

powerful in detecting impermissible contexts and contradictory behaviors. Since

contexts of interest are described in the description logic, it is much easier to

explicitly identify impermissible contexts. Description logic makes testing for

subsumption and membership straightforward, hence making inheritance and

overriding a standard part of behavior definition. In addition,atomic contexts along

the same dimension are supposed to be disjoint. All these characteristics make it

much less possible to create clashing contradictory behaviors.

3.6.4 Capture Environmental Effect

One observation about context-driven model is that it is reactive. Instead

of setting a goal and proactively trying to control and coordinate all entities to

achieve that goal, systems following this model would passively react to the active

contexts observed by executing predefined actions associated with active contexts.









The system has an idea about what the most preferable contexts are, and some

about where actions taken may lead to, but it would stay on course until context

transitions take place. This reactive nature contributes to its strong capability to

capture impermissible contexts and environmental effects.

3.6.5 Automatic Tuning and Machine Learning

The effect of actuators is described in terms of the available context. However

it might be possible to bring the effect an actuator has on a sensor by making use

of machine learning techniques, thereby rendering the explicit description of an

actuator unnecessary.

3.6.6 Scalability

Unlike the service oriented model where each service is encapsulated into

a stand alone software artifact, the middleware bundle is the only brain in the

context-driven model. The bundle only takes action during context transitions,

which are not expected to be frequent once the system has stabilized. The single-

bundle reactive approach would fare much better in terms of scalability comparing

to dozens of service bundles all proactively collecting, calculating and manipulating

at the same time.

Another aspect of scalability arises when we are integrating new services into a

space. Due to the explicit description of the service we can determine immediately

if there will be a conflict with the existing devices. Their is no need to research the

characteristics of the entity since this has been stated explicitly.















CHAPTER 4
OBTAINING INFORMATION FROM SENSORS

A pervasive space needs to obtain information about the physical world.

This is done by making use of sensors. Sensors are active objects that provide

information about a particular domain, providing data to the system about the

current state of the space. A sensor cannot change the state of the space -it can

only observe. A temperature sensor, for example, can only observe the current

temperature, not influence it. The system is able to interpret the sensor data to

generate the context of the space.

A sensor is an autonomous embedded device which has the ability to

collaborate with other devices and provides data readings for an application. A

sensor is typically battery powered, but this is not a strict requirement. Interaction

with a sensor is established by making use of either RS-232, RS-485, ethernet,

bluetooth or any other interaction protocol.

A sensor network is comprised of two or more sensor nodes working together to

gather information and provide one or more services to an application. The sensor

network is simply a logical grouping of sensor nodes. Data and communication

between the sensor network gateway and the sensor nodes is transmitted along the

sensor network. The sensor network is not a physical medium like RF, or a wire,

but rather a logical instrument.

The sensor network developed at the pervasive computing lab integrates

various sensors from various sources in a unified way. This takes away the burden

of configuring and installing sensors on a sensor to sensor basis.

The sensor platform consists of a hardware part and a software part. The

hardware uses a stack based architecture allowing the individual l.zr-iS to be









redesigned and replaced without affecting any of the other components. This

1 ,. i1, architecture allows customization of the sensor nodes for a specific

application.

The sensor platform that has been developed contains a software framework

that can automatically download the required software used to interact with a

specific sensor node from the node itself. This surrogate concept allows the nodes

to be easily upgraded without requiring software changes to the sensor gateway.

The software can not only reside on the node itself, but also referenced by a URL

which the sensor gateway accesses. This referral URL allows the sensor node driver

to easily be updated.

4.1 Deriving Context from Sensors Readings

A pervasive space needs to obtain information about the physical world.

This is done by making use of sensors. Sensors are active objects that provide

information about a particular domain, providing data to the system about the

current state of the space. A sensor cannot change the state of the space -it can

only observe. A temperature sensor, for example, can only observe the current

temperature, not influence it. A smart space typically contains many physical

sensors that produce a constant stream of output in various domains. As this data

is consumed by the smart space, each physical sensor can be treated as a function

the space can call to obtain a value.

Definition 1 (Sensor). A sensor is a function that produces an output at a given

time in a particular domain.

fl : U D

Notice that we can have multiple sensors operating in a given domain.

Multiple sensors will be indicated by fi, fJ, etc. Sensors in the same domain

may produce different values due to different locations, malfunction or calibration

issues. The smart space system will be responsible for correctly interpreting data.









We will group all available sensors together and define f = I fi to be a snapshot of

all sensors at a point in time.

4.2 Using Ontology

Dealing directly with sensor data is rather awkward. Instead we would like to

work with higher level information that describes the state of the world. A natural

choice for describing knowledge is to use description logics. Using a description

logic we can define an ontology that describes the smart space. We will restrict

ourselves to taxonomic structures, and therefore will have no need to define roles.

Traditionally taxonomies deal with concepts. However we use the term context,

since this term is widely used in the pervasive computing community [30, 58].

Since taxonomic structures do not make use of relations they can be

considered equivalent to propositional logic. For an in depth discussion on

description logics and the relationship between other formalisms we refer to

[59]. We will closely follow the definitions given there and introduce the language L

for context descriptions:

Definition 2 (Context Descriptions). Context descriptions in are formed using

the following syntax rule:

C, D A (atomic context)

T (universal context)

S(non-existing context)

-C (context negation)

C n D (intersubsection)

C UD (union)


Where A denotes an atomic context.









The language described allows us to define the atomic contexts WARM,

MODERATE, COLD and DOOROPEN. Or more complex context definitions

can be constructed, such as COLD n DOOROPEN.

The syntax above tells us how we can construct a valid sentence that described

a context. Apart from the syntax we also need to add semantics to the syntax so

we can properly interpret the syntactical definition of a context expression. We

need an interpretation I = (A .z) that contains a non empty domain of interest

A' and an interpretation function .z that allows us to interpret our language. The

domain of interest in our case is the possible state of the space, hence A' = f. The

interpretation function maps every concept to a subset of A':

Definition 3 (Extensional Semantics of ). We /7;,'. the interpretation I as

follows:
A C Az Tz zA

I1 = ~Cz A'z Cz

(C n D) Cz n Dz (CU D)= Cz U D

Using the language L we can declare relationships between several contexts.

One is the inclusion or is-a relation. For example, a cat is an animal. The other is

the equivalent relation. For example a dog is an animal with four legs that barks.

Formally these are defined as:

Definition 4 (Context Relations). Inclusion and ../;,.;l.:l are fi,'., 1 as follows:

Inclusion: C E D, interpreted by Cz C D1.

E,;i,,;1.l,:, C D, interpreted by C = D'.

Notice that inclusion C C D can be expressed by introducing a new base

context C and define C C D as C = C n D. The idea is that C exactly captures

the difference between a C and a D.

The description of how a set of contexts relate to each other is called a

terry,.: .. '1.,'i; or T-Box, denoted by TBox. A terminology TBox is a collection of









inclusions and qualities that define how a set of contexts relate to each other.

Each item in the collection is unique and .,. vi i Contexts that are defined in

terms of other contexts are called derived contexts. If we have an interpretation I

that only interprets the atomic contexts, we can interpret the entire taxonomy.

Concepts can now be defined, and the primitive contexts can be given an

interpretation. For example: COLD = {O,..1},MODERATE = {11,..17},

WARM = {18, ..25}. Notice that this interpretation function is not unique.

Different users of the space will most likely have different interpretations of the

available concepts.

We can now identify whether the current state of the world is a member of any

concept (i.e., to verify whether u E f satisfies concept C we check that uz E C().

Using this we can identify the contexts that are currently active:

Definition 5 (Active Context:). The active context of the space R : U 2c is


R = {C | uZ e C1}


Most sensor networks in the literature make use of a hierarchy of

interpretation functions, often referred to as context derivation [28, 27, 31]. Since a

taxonomy allows us to define inheritance relations we often refer to a taxonomy as

a context graph.

Context derivation typically is done by making use of derived interpretation

functions. These functions take as input the value (or history of values) from other

sensors and produce a new output value. The problem with this approach is that it

is no longer possible to verify whether or not the derivation of a particular context

is sensible or not, that is there is an actual state of the world that satisfies the

defined context. It is straightforward to construct a sensor network that derives

inconsistent information. The strength of a description logic lies in the fact that

every context that we define is sensible and can actually occur in a space.


























Figure 4-1: Indoor and outdoor sensors


4.3 Temporal Context

Interpreting the state of the world only gives us an understanding of the world

at a single moment in time. By only looking at a single moment of time it becomes

impossible to describe events or contexts that depend on some temporal ordering

of events. Using merely snapshots we cannot describe an activity of daily living.

For example the activity of doing laundry consists of a sequence of events. First we

gather the laundry, we obtain detergent and we activate the washing machine.

Another scenario is a person walking indoors. We can detect this sequence of

events by making use of two pressure sensors under the doormat as shown in figure

4-1. One sensor on a doormat that is outdoors and one that is indoors. As soon

as a person comes inside he will press the outdoor sensor followed by the indoor

sensor. If a person leaves the house it will happen in reverse order. First the indoor

sensor is pressed then the outdoor sensor is pressed. Figure 4-2 show this sequence

is a diagram.

To express this context we somehow need to incorporate time into our

taxonomy. This can be done by extending the language L to handle time.















Transitions because a person walks indoor.


Figure 4-2: A sequence denoting someone entered the house


4.3.1 Syntax of Temporal Context

We introduce, an extension to our n i::,;,lniv L that allows to express and

reason about contexts over time. We model time as a discrete change in the

state of the space and follow the so called external approach [60]. In the external

approach the very same individual can have different i I .p!ii in different

moments of time that describe the various states of the individual at these times.

In our case the individual is that state of the pervasive space.

In this approach context definitions remain invariant, meaning that the

meaning of a concept does not change over time. The concept COLD for example

will have the same interpretation regardless of the current time. The membership

of an individual can however change over time. In moment in time the house can

be COLD and another moment in time it is not. The same individual is classified

differently based upon time.

We introduce the language LT, by extending L with time constructs. The

language LT is used to describe temporal contexts. We follow the approach taken

by [61], which in turn is based on tense logic [62, 63].









Definition 6 (Syntax of LT). Context descriptions in LT extend L by ilJ./:,i the

following syntax rules:

C, D C (previous instant)

D C (next instant)

CUD (until)

C S D (since)

The addition of these four constructs are quite powerful. For example we are

able to introduce the following abbreviations with regards to time:

>C -TUC C-SC > -C


Where < reads as "once", > as i., nii I!!y", S as "a- li-- and B

reads as "it has ah~ been." The constructs allow us to express things as

OwnerAtDoor c (Dooropen, the house will open the door in the next instant if it

detects the owner at the front of the door.

We can further enhance our expressiveness by adding the following fixpoint

abbreviations as well:


C before D AD A E(C VC before D)

Using these abbreviations we can describe the example given in figure 4-1, and

its opposite as follows:

WalkIndoors = OutdoorMat before IndoorMat

WalkOutdoors Indoor Mat before OutdoorMat









4.3.2 Semantics of Temporal Context

In order to reason over time we need a temporal structure T that captures

our notion of time. For our purpose we define T = (P, <) where P is a set of time

points with a strict partial order <. We assume that there is a start of time, which

we denote with to, which has the property that Vt P(to < t V to = t).

The interpretation of LT is a triple I (T, A', .-), where T = (P, <) is the

time domain, A' the individual domain and .1 is the interpretation function.

The points in T form the infinite informal time scale. A state is basically

a point in time. Notice that we nowhere describe 1 !.-- much" time it takes to

go from one state to the next state. Depending on the required precision of the

observations we can define the amount of "time" it takes to make a transition. The

semantics can now be given as follows:

Definition 7 (Semantics of LT). The semantics of LT are as follows:

(CC)Z = {a A IZ 3t'.t < t' A a e Cz, A E3t".t < t" < t'}

f(eC) ={ae A t > to A 3t'.t' < t A a Cz A 3t".t" < t' < t}

(C U D) ={ae A I Et'.t < t' A a D A t".t < t" < t' a C

(CS D)- ={a A I Et'.t' < t A a e D t, A Vt".t' < t" < t -a C,[,}

The semantics capture our notion that the context definitions remain invariant

over time. The membership assertions of individuals however can change over time.

4.3.3 Describing Events using Temporal Context

The language LT allows us to reason how the state of the space behaves over

time. There are however some counter intuitive observation we can make with

regards to the logic. Suppose we have the sequence as given in figure 4-3 where T

denotes that the state of the world satisfies the given context.

As we can see we the context in the house is active before we actually entered

the house, even worse since we obtain our snapshots one by one we never enter the









T
IndoorMat F I
T
OutdoorMat F

0 1 2 3 4 5 6 7 8 9
0123456789
T ----------
InTheHouse F ..--------.----

Figure 4-3: Actual sequence of events


context WalkIndoors, since this context is true in the past. The context before

should be active after time interval 7, not before!

The problem stems from the usage of future tense instead of past tense in

our definition of before. In the case of recognizing context we would like our

expressions to be true as soon as we have recognized a sequence of context states.

Meaning that an activity of daily living should be described in terms of the past

not of the future. Replacing the description using past tense operators would solve

this issue.

Another problem with the definition of before is that it is a so called weak

operator. A before B does not necessarily imply that B will be true at a certain

point. Again, this is not desirable.

The easiest solution to these problems is to give direct semantics to the before

operator, instead of expressing them in terms of others. The semantics of before

can be given as follows:


(C before D) = {a Ac EIt'.t' < t a a Cf A 3t".t' < t" < t a c D,,}


4.3.4 Computational Complexity of Temporal Context

Burgess gives a complexity analysis of ALCT [61]. The language of ALCT

is similar to the language we described above, except with the addition of roles

and removal of temporal operators that deal with the past. The addition of past









operators does not make the language any more powerful, the addition of roles

however does.

He proves that concept satisfiability in ALCT has the same time complexity

as ALC if we take P to be a discrete time structure like the natural numbers. Thus

reasoning over ALCT is PSPACE complete. Unfortunately the time bounds for

tense logic transfer to this class and hence the problem is EXPTIME hard [64].

However implementations of reasoning engines that can deal with temporal

description logics exist [65, 66] and despite the computational complexity of these

algorithms, they perform reasonably well for i.i i!, !I" applications. Notice that

OWL-DL has similar complexity results but is still widely used in an effective

manner. For example [67] shows how OWL can be successfully used in a pervasive

space.















CHAPTER 5
DESCRIBING ACTUATORS AND SERVICES

The devices in a smart space are not turned on randomly. We turn on an

actuator because of its effect. Every actuator has a so called intentional effect

on the world. The intention of turning on the heater for example is to raise the

temperature.

By describing the intentional effect of an actuator we can use this to reason

about the effect of the invocation of a certain actuator. This can assist the

developer when programming the space. We can identify for example that invoking

the A/C and the heater at the same time is rather strange.

On a higher level we have services that accomplish certain goals. For example

a temperature control service might be able to keep the temperature at a constant.

This service can accomplish this by making use of the intentional effect of the

available actuators.

If we have a description of how an actuator or service behaves over time, we

can use this to prevent conflicts and assist a developer in how to accomplish a state

in the space.

The ontology LT can now be used to describe the effect of the invocation of a

service or actuator. The description can be used by the space to reason about the

effect of the activation of a particular actuator or service. Consider the following









description of a heater and actuator:

Heater A Moderate Moderate U Warm

Heater A Cold Cold U Moderate

Airco A Moderate Moderate U Cold

Airco A Warm Warm U Moderate

If the current state of the world is moderate and we invoke both the

heather and the air-conditioner we can detect a logical inconsistency.

(Moderate U Cold) n (Moderate U Warm) are logically inconsistent, there is

no existing model that satisfies this formula. We detect that the invocation of these

two actuators lead to an unpredictable state, or will result in an ill defined state.

Similarly we can describe services in terms of how they effect the space.

For example a climate control service can be described as > ] Moderate.

After activating the climate control there will be a time after which it is alv--i

moderate. In general:

Theorem 1. Let p and q be the descriptions of actuator (or service) ai and aj. ai

and ai are said to be in conflict in state r if p n q 1.

Proof. This is trivial. If p n q then there doesn't exist a model that satisfies

p n q. This directly implies that there is no sequence of states that satisfies these

formulas. O















CHAPTER 6
PROGRAMMING THE SPACE

So far we have described a space consisting of sensors and actuators. The

key element that is missing is the user. To model the user we roughly follow the

belief-desire-intention [68] model, in the sense that the user observes the state of

the space and, based upon this information, commits to a plan of action. We have

the following ingredients:

Desires: A user has a set of preferences about the state of the world. These

preferences dictate how the world should be at that given moment. For

example, when a user is going to bed, he or she would like the doors locked.

Belief: This is the current observed state of the world, interpreted by a

taxonomy. In any given state of the world the user has a set of preferences

about the world. When the state changes, the set of preferences can change

as well.

Intention: This is the plan to which the user commits. In a smart space this

would be the activation of a set of actuators. The aim of the activation is to

fulfill the desire mentioned before.

The idea is that the user observes that state of the world. The user then

classifies the state according to the users specific' .::. .:,nv. This classification gives

rise to a set of contexts that are active. Associated which each context is a set of

behaviors. The intention of these behaviors is to change the current state to a more

desired state. For example, if user interprets the world as "dI I : we turn on a

lamp with the intention to reach the desired state of "light."









6.1 Beliefs-Desires-Intentions of Users

As we mentioned earlier a user has a belief about the current state of the

world. The current belief about the state of the world can be captured with a

taxonomy and an accompanied interpretation. The interpretation maps the values

obtained from a sensor to the atomic concepts. We express the intentions of the

users by a sequence of actions the user wishes to execute in a particular context.

Formally:

Definition 8 (User). A user is a 3-tuple


B ::= (T,, I)


Where T and I are the '1-.i .,,.,;i accompanied by the interpretation of the

user. Let I : C --- S be a im.ijrr,:,. from context to statements.

We can now define a space consisting of sensors and actuators and a user using

the following operational semantics:

Definition 9 (Statement Sequence). Given a set of actuators A, a sequence of

actions S is 1. I;,, 1, as follows:


S ::= ail ailS; S2


Where T ai turns the actuator ai E A on, I ai turns the actuator ai off. With

; we denote action pr. I ':,'i1 We first perform action S1 after which we execute the

remaining statements S2.

Definition 10 (Programmable Pervasive Space). A ,. 'l m iii, 1 ''l. pervasive space

is a tuple consisting of

P:: (B,U, S, 2A)

Where B is the representation of the user, U the state of the space as observed

through our sensors, S the statements we are curr. i,'ll processing and 2A the set of

actuators that are curr, /ll;/ active.









A spaces changes over time due to nature. We model the effect of nature by

a transitions that changes the state of the space, and observe the changes of the

space through our sensors.

Nature: (b, S, f(u), a) (b, S, f(u'), a) where f(u) / f(u')

The other way in which the space can change is by actuators that the space

controls. The following transitions capture the turning on and off of actuators:

Activation: (b, T aj, u, a) (b, c, u, a U aj)

Deactivation: (b, I ai, u, a) (b, c, u, a \ ai)

If the set of active contexts has changed, we obtain the intentions from the

user and execute the desired sequence of actions:

Context ('C! 11 : (b, f(u),S,a) (b, f(u'), i(R(f(u'))), a)

whenever R(f(u') / R(f(u))

6.2 Inheritance and Override

The concept of subsumption introduces inheritance.

Definition 11 (Inheritance).


C C R A C E DA T ai c I(D) -T ai E I(C)

Nature dll, this holds for turning off:


SC R A C E DA I ai E I(D) -[ ai E I(C)

6.3 Scenario and Programming Procedures

We have formally established a context-driven programming model for

pervasive spaces, employing definitions for sensors, actuators, users, and contexts.

But how exactly would this model help programmers create or modify smart

spaces? In this section we present a scenario and outline the programming

procedure to demonstrate the feasibility of the context-driven pervasive space

programming model.









6.3.1 Lightening Control Application

The following scenario is set in a smart apartment at a retirement community.

It is a studio apartment intended for a single occupant, and the service to be

programmed is the ambience lighting control.

The ambience lighting inside the apartment is automatically adjusted based

upon the active contexts. As a general rule, when the room is too dark, lamps

and other light fixtures should be turned on; when the room is too bright, blinds

should be closed to maintain a comfortable living environment. When the resident

is sleeping, the apartment should be kept dark. When the resident is watching TV,

in order to ensure the best viewing experience, the ambience lighting should be

kept at a moderate level.

6.3.2 Describing Context

The first step in programming the described lighting control in this smart

apartment is to properly model the physical aspects of the space. At any moment,

we can describe this smart space as being in certain states; for instance, the

smart space can be described as Bright, Dark, ResidentwatchingTV, or

Residentsleeping.

While human beings can take a glimpse at the apartment and almost

immediately identify these contexts a smart space to make sense of all these,

two criteria must be satisfied. First, there must be appropriate sensors that can

perform the relevant measurements. For instance, in order to identify Bright or

Dark, some sort of luminance sensor must be present in the smart space. And,

without a thermometer, there is no way for a smart space to observe whether the

room temperature is Hot or Cold. Second, there must be an interpretation of the

readings generated by the sensors to more abstract contexts. For example, we can

interpret any reading of higher than 600 lux from a luminance sensor as Bright,

readings under 400 lux as Dark, and anything in between as Illuminated.









In addition to these atomic contexts that can be directly measured by physical

sensors, it is also useful to have derived contexts, which can be defined with the

help of ::;n, iv operations. For the ambience lighting control service, the derived

contexts such as BrightTVOn, IlluminatedTVOn and DarkTVOn, which are

built from atomic contexts Bright, Illuminated, Dark and TVOn, are extremely

helpful in identifying the current context of interest when trying to decide the next

appropriate action the system should perform.

6.3.3 Associating Behavior

Once contexts of interest (both atomic contexts and derived contexts)

are defined and interpretation functions are devised, the smart space can now

understand which contexts are currently active. For each reading of each sensor

with properly defined contexts in its associated domain, that reading should be

able to be interpreted as exactly one active atomic context in that domain. For

instance, if the luminance sensor were to report a reading value of 700 lux, atomic

context Bright would be recognized as active, while a query of a simple sensor

in the TV set should report either TVOn or TVOff is the current active atomic

context. These active atomic contexts can be used to generate further active

derived contexts, when all its child contexts are active. For instance, BrightTVOn

would become active automatically when the luminance sensor reports active

Bright context and TV set reports active TVOn status.

In order to achieve the goal of automatically adjusting ambient lighting,

we have to find some way for the smart space to interact and influence the real

world. This can be achieved by manipulating actuators. With the current version

of our context-driven programming model, actuators are only allowed binary

operations, which means that they are either turned on or off. Each actuator that

is turned on should generate at least one intentional effect, which results in a

context transitions. For example, turning on lamps would brighten the room (that









is, the space would transition between contexts, such as Dark -- Illuminated or

Dark -- Bright), while closing the blinds would darken the room (Bright -- Dark

or Illuminated -- Dark).

How does the smart house know when to turn on the lamps or close the

blinds? That is where users come in. The occupant of the apartment should have

the ultimate power to make decisions. The resident calls the shots on defining

what Dark or Bright mean, and the context graph should be built based on his or

her beliefs so as to help the user truly understand the current active state of the

entire smart space, as well as facilitate the planning of actions. The user also gets

to express his or her desires by specifying the preferable contexts. This ultimately

defines the goals the smart space should work towards when deciding which actions

(if any) to take. In essence, the space must find and execute a route from the

current active contexts to the promised preferable contexts using the only tools it

has to change the state of the space: actuators. And since the smart space knows

about the current active contexts, the final preferable contexts, and the intentional

effects of each actuator, it has all the information needed to devise this route and

fulfill the user's intention.

6.3.4 Connecting Sensors

We now return to the scenario of programming ambience lighting control. In

order to provide this service as described, three different sensors have to be present

in the apartment: a luminance sensor, a TV set sensor, and a smart bed that can

detect whether the resident is on it.

The TV set sensor and smart bed generate Boolean values as to whether

the TV set is on or off, and whether the resident is in bed or not. The luminance

sensor, however, requires an interpretation function between numerical reading

values and atomic contexts Bright, Illuminated and Dark (the values for these

contexts have been defined above).









In addition to the sensors, we assume two actuators are available in the

apartment: one to control the lamps and one to control the blinds. The intentional

effects of each actuator are also described above.

As for contexts, there are atomic contexts such as Bright, TVOn or InBed

that can be interpreted directly from sensor readings, and there are also derived

contexts such as DarkInBed and IlluminatedTVOn.

Since the user would prefer the lights to be turned off completely while he

or she sleeps, but prefers adequate lighting while watching TV, DarkInBed and

IlluminatedTVOn are potential goals (depending on the user's current intentions),

and are therefore preferred contexts.

For each non-preferred context, an associated statement (consisting of a

sequence of actions manipulating actuators) is attached, which specifies how to

move from that context to another. Hence the smart space identifies DarkInBed

and IlluminatedTVOn as preferred contexts, and will strive to make either one

of them the active context by executing the action statement associated with the

current active context. Figure 6.3.4 shows the context graph described in this

section.

The derived contexts automatically inherit the action statements from their

child contexts. Hence if BrightInBed is associated with action closing the blinds

then BrightTVOnInBed should, unless specified otherwise, also retain the same

action. However, an interesting scenario occurs when we consider a situation with

the resident lying in bed while watching TV before going to sleep in the currently

illuminated room.

In this situation we have three active derived contexts: IlliminatedTVOn,

IlluminatedlnBed, and IlluminatedTVOnlnBed, with the last one derived from

the previous two. We observe that there are conflicting inherited action statements.

To resolve these conflicting actions, with one trying to close the blinds while the











Close Blind (Turn on electric blind)


\Close Blind (Turn on electric blind)
Bright TVOff No Action















when Illuminated is active. Since TVOff he resident is sill watching TV,
TV On
Dark TVOn InBed

ark TVOff
TV Off












he lighting should be kep illuminated until e Blnd (Turn on electric blind)o go o sleep.


The conex driven programming model is effeclove Blind (Turn on electnc bind)flicing
InBed
Dark InBed
No Action






Figure 6-1: A sample context graph


other indicating that no action is needed, we need to define a new action statement

when IlluminatedTVOnInBed is active. Since the resident is still watching TV,

the lighting should be kept illuminated until she or he decides to go to sleep.

The context driven programming model is effective in detecting conflicting

actions and can prompt the user for resolution. We also observe how inheritance

and overriding action statements enable the development of robust smart spaces.















CHAPTER 7
INTEGRATED DEVELOPMENT ENVIRONMENT

With the context driven programming model formally defined, we are now

ready to explore how programmers can actually program a smart space.

7.1 Design of the Context Graph

The programming procedure would start with designing a context graph,

which is a semantic web that is composed of interesting states of the space. There

are two types of contexts in a context graph, the atomic contexts and derived

contexts. Atomic contexts differ from derived contexts in that they can be directly

associated with readings of one particular type of sensor,while derived contexts are

composed of multiple atomic contexts. For example, cold and hot are two atomic

contexts, because they can be associated with thermometers, with a predefined

range of readings from the thermometer. On the other hand, contexts "cold and

dry" "hot and dry" derived contexts, since they cannot be directly associated with

sensors, but instead can only be derived from a combination of atomic contexts

such as cold and dry for "cold and dry" context.

The design of a context graph can proceed without knowledge of availability

of various entities in the house, and can be applied to different smart spaces.

However, for each smart space, the contexts of interest would vary based on the

collections of available sensors and actuators. The contexts of interest are also

affected by such things as the residents activities and preferences and the caregivers

primary concerns.

It would be natural, therefore, to assume one possible practice when designing

the context graph. This would be to get a generic context graph as a template,

and then customize for each smart house and resident based on factors such as









availability of sensors and actuators, or residents preference. There would be no

problem should the context graph contain either more or fewer contexts than could

be sensed by available sensors, although if the context graph cannot interpret

reading from some sensors, it would render these sensors useless. This property

allows a generic context graph template to be used, and also provides system-wide

robustness when some entities fail or new ones are introduced to the smart house.

7.2 Interpretation of Sensor Readings

To allow the runtime platform to interpret sensor readings, the entire range

of possible readings from each sensor must be mapped to di-i, ini atomic contexts.

For example, for a thermometer which is capable of reading temperatures between

-200F ~ 222F, we need to specify that 20F ~ 55F would map to cold atomic

context, and 55F ~ 70F would map to cool atomic context, and 70F ~ 80F

would map to warm atomic context, and 800F ~ 222F would map to hot atomic

context. The association of a range of possible reading values in integer or real

numbers, Boolean values or enumerated strings to certain defined atomic context

enables the runtime platform to make sense of the sensor readings as the current

state of the smart house, which leads to the decision of which actions to take.

7.3 Desired Behaviors under Each Context

Contexts defined in a context graph represent the whole spectrum of possible

interested states that can be used to describe the current standing of the smart

house. There are contexts that are not allowed and should be avoided, if,

unfortunately, the current context falls into one of these impermissible contexts,

some sort of emergency actions should be taken to move out of this context

as soon as possible. For example, the context of :;i i1, I- hot and smoking

would be an example of impermissible context, and extreme measures such as call

911 and initiate fire depressant would be warranted. There are others that are

situations considered to be normal, but not quite the most desirable situation. In









those contexts, actions should be specified so the state of the smart house would

gradually move toward more desirable contexts. The specified actions in order

produce to this movement would be called desired behavior associated with the

context. For example, in a cold February in a northern climate, it is quite possible

the current context within the smart house would be "cold and dry", which is

normal but not quite desirable. The more comfortable, hence desirable context in

this example would be '. ii, with moderate humidity", and the desired behavior

associated with "cold and dry" context would therefore probably be turn on the

heater and the humidifier. The system designers and programmers would program

smart houses by associating behaviors to each of the specified contexts in the

context graph. This would normally lead to context transitions that move closer to

the desirable contexts.

7.4 Mapping Physical Sensors and Actuators to the Context Model

After the completion of the previous three steps, we now have the knowledge

to describe all contexts of interest of the house, the knowledge to interpret the

sensor readings and decide what the current contexts are, and the knowledge of

what actions to take to steer the house toward the desirable context. But how do

we apply all this knowledge to the physical entities in the smart house? An array

of disjointed atomic contexts like cold, cool, warm and hot is theoretically great

in describing the context of the house, but would not be effective unless certain

sensors) actually available in the house are associated with these contexts. The

same would apply to the actuators, which need to be manipulated for actions

associated with each context. This association is established at runtime, when the

runtime platform dynamically links the contexts and actions with existent sensors

and actuators based on their associated measuring dimensions, locations, and other

information With the programmed knowledge installed and physical entities linked,

the smart house is now ready to operate based on programmers directives.









7.5 Implementation of the IDE

In this section we look at how we implemented the development environment.

7.5.1 Premise and Platform Selection

The existing service platform for GTSH is built upon OSGi. It provides

excellent facilities to manage the lifecycle of all services and entities, implemented

as individual bundles, and handles dynamic addition or removal automatically.

It also provides good APIs such as wiring between data sources and sinks, and

service registration to allow dynamically fulfilling bundle dependencies. OSGi

Alliance, which maintains the technology, consists of many in r pi1 lii ris in the

computer and appliance industry, assuring the wide acceptance of OSGi. Realizing

that although providing an IDE for smart spaces and exploring reasonable

programming models is relatively novel for pervasive computing researches, the

effort of programming bundles in Java or establishing context graphs with ontology

are not. Hence we decided early on to implement this IDE as an enhancement

or attachable plug-ins to established development tools instead of a full fledge

standalone software. Two potential targets are identified: (1) Eclipse which is

one of the most predominant IDE used by Java developers, allowing easy bundle

authoring, and (2) Prot6g6 which is one of the most heralded tool for ontology and

semantic web editing. After careful consideration, we decided that Prot6g6 was

preferable for the initial phase of our work since most of the programming effort

using the context driven programming model requires establishing and editing the

semantic web and context graph rather than implementing Java code. Prot6g6

also has the capability to employ reasoning engine which can establish whether

a concept subsumes, is equivalent to another or whether a certain individual is a

member of a particular concept, which is crucial in exception capturing and active

contexts derivation in the context driven programming model. Should we have a

future need to incorporate heavy bundle coding in Java, the current enhancement









to the Prot6g6 would be carried over to the Protdg4 plug-in for Eclipse to preserve

the current effort and provide seamless integration between the two environments.

7.5.2 Requirement Analysis

Small scale interviews regarding the requirements of the IDE were conducted

among the in-house investigators who participated in the initial setup of GTSH.

With their hands-on experience in actually programming a full-scale smart house,

the following requirements for the IDE were identified:

1. capability for browsing existing sensors, actuators and services in the smart

environment.

2. capability for browsing the context compositions.

3. capability for viewing and editing the interpretation of sensor readings to

associated atomic contexts.

4. capability for viewing and editing the behaviors associated with each context.

5. capability for creating contradictory behaviors and impermissible context

checks.

6. capability for installing and deploying the programs to the runtime platform.

7. Ease of use to allow domain experts to modify current or create new

behaviors of smart houses.

7.5.3 Enabling Middleware Runtime

As part of the GTSH project, middleware architecture has been proposed and

developed [15]. The middleware serves as the backbone of smart house, allowing

physical entities such as sensors and actuators to be automatically integrated into

the environment upon entry. The middleware also empowers designers to define

contexts and knowledge and program the behavior of the smart house.

There are two software artifacts that are essential in actual enabling the

programming process of smart houses. There is, of course, the IDE that provides

tools and guidance that allow system designers to actually implement code and/or










configure and specify knowledge that depicts the expected behavior of the smart

environment. There is the middleware runtime that would likely reside somewhere

in the smart house that actually interprets and executes these instructions created

using IDE. The interactions between these two software artifacts are shown in

Figure 7-1.


lp .. .. .1 1

L onti Services klu I d_
nLlnii rmen Layer Composie La.er
Laier ces


"" 0
6 a*- B I ;


* 6630 S*
S S //"


I


Sco aor






Figure 7-1: Interaction between components


The current active middleware runtime is implemented on an OSGi platform

as a bundle. This bundle serves as the brain of the smart house. It is connected

to various bundles representing sensors via OSGi wiring API, and feeds these

proactively collected sensor readings into atomic context interpreters. These

classified atomic contexts are fed into a Jena and reasoning engine to activate all

the active contexts. The middleware bundle then looks up the behavior associated

with these contexts and triggers the programmed actions, mostly by either

turning on or off certain related actuators. Current version of this middleware

also performs a predefined association between physical sensors or actuators and

the entities represented in the OWL file. As the current project of enhancing the

context driven programming model and implementation of IDE progress, there


111111









also have been minor revisions of the middleware bundle to support these changes

and enhancement. In the wake of the process of developing the IDE, there are

undoubtedly iterations among IDE, the middleware bundle and the programming

model. Since they actually represent different facets of the same thing, they are

definitely tightly coupled. System designers use IDE to program and configure

the smart house, while the programmed code and configurations are interpreted

and executed by the middleware runtime. The programming model provides the

theoretical background and design rational for both the IDE and the middleware.

7.6 Components of the IDE

In this section we look at how the various components in the IDE help the

developer programming the pervasive space.

7.6.1 Entity Definition View

As shown in figure 7-2, this view provides the tools for browsing sensor

and actuator entities currently available in the smart house. It also provides the

graphical interface for editing the sensor readings mapping to atomic contexts,

as well as specification of the effects of actuators in terms of switching between

atomic contexts. This view is implemented as a plug-in tab to Protdg6 3.1, and

the visualizations are implemented using standard Java Swing component. All

information and specifications edited and di-pl i-, iI on this view are stored in

the OWL file that serves as the blueprint of the smart house under development.

It short, the purpose of this view is to provide the system designer with the

knowledge about the availability of various sensor and actuator entities, and

detailed information about them, such as location, entity ID, the type of

measurement., This allows system designers to program and update certain

aspects of each entity presented, such as readings value mapping of sensors and

default effects of actuators.





























Figure 7-2: Entity definition view


7.6.2 Behavior Definition View

As shown in Figure 7-3, this view provides the tools for browsing the context

graph of the smart house, editing the graph to reflect the contexts of interest,

and defining expected behavior associated with each context of interest. It also

provides visualization of the potential migration path of contexts as the effect

of programmed behaviors that should be invaluable in guiding the programming

process. Instead of asking system designers to draw the entire context graph

a list of various atomic contexts are provided and system designers can simply

pick the derived context of interest, and the IDE would automatically derive the

context graph based on ontology and the inherit relations between contexts. This

view is implemented as another plug-in tab to Protdg6 3.1, and the visualizations

are implemented using standard Java Swing component. All information and

specifications edited and di- p1 i, .1 on this view are stored in the OWL file that

serves as the blueprint of the smart house under development. In short, the

purpose of this view is to help system designers grasp the programmed behaviors

and their effects, and modify these behaviors if so desired.


I ....... .. .. ... ....... .......... ..... 1 "11 1 [ IB S Ia II Ib l I B i b t< p r t g
' L I ...... ,h r I / hrr I huI. *e o I I









r,












'4im~~m ~ ~ ~


te Edi er d A pAde I idw Tads bj


* B l lr ~ .B~ *..n E. ..


... --_



a '. .. ..

i .- .' _- ', '__"_ _






a ._ _, '. _
r ,, .. ,. ^ . .
S, y -












J ________ *~ ~ ~ ~ ______________
'--- -
CI







*I ---,
CI I,

U ~ i t
*






..\
IC ,' -- -


C : .
U -






.
I"-I ,


<4protdtgd





S ... : a

L- U-


.. C,-.
... :.,: *.




c. c. *
.:. 0-'
C, 3




,-, C, U
,-, C, U


Figure 7-3: Context browser



7.6.3 Impermissible Context C('I. 1: i


This checker serves as a safeguard mechanism before a program is deployi, 1


to the real remote smart houses. Some of the pre-deployment checking includes


overlapping of sensor readings for di- PiilI atomic contexts, contradictory actions


specification associated with same context. This checker is implemented using Jena


reason engine, which automatically examines the OWL file programmed using two


views described in the previous sections. Should any impermissible context be


found, the IDE prevents the deployment to avoid destabilizing the target smart


house.


7.6.4 Communication Module


This module enables communication between the IDE and the middleware


runtime. The communications should happen only twice during the programming


process, once at the beginning when retrieving a snapshot of current running









programs and available sensor/actuator entities information from the smart house.

System designers would program the smart house based on this retrieved snapshot.

At the end of the programming process, after the context checker verified the

design, the OWL file is uploaded to the target smart house and replaces the current

running program. This minimal communication pattern is chosen for two reasons.

First, since smart spaces are an open and volatile environment, it is assumed

that sensors, actuators or smart appliances can be brought into the house or taken

out at any time. With the large number of these entities, failure is could be the

norm. Hence if the IDE constantly tracks all the changes and reflects them on

various views in real time, it would cause confusion and inconvenience to designers

at work.

Second, since the IDE is used for programming, not monitoring, continuous

real time communication does not seem necessary. Instead, we opt for pre-

deployment checking to see if any changes in the smart house would merit further

changes of the target OWL file. This compromise would grant a relative stable

working environment for designers during programming process, yet maintain

integrity of the program while using minimal communication bandwidth. All the

necessary knowledge such as sensor reading mappings, actuator effects and context

associated behaviors needed to specify how smart house should behave are all

structured as part of the target OWL file.

The retrieval and deployment of information between IDE and middleware

runtime is made extremely simple as corresponding to downloading and uploading

the OWL file respectively. The communication module is implemented as a servlet.

System designers can select which smart house to connect to by specifying its

IP or domain name, and separate "connect" and "d 1. '!. button would initiate

either download or upload sequence respectively. In short, this module provides

the bridge between IDE and middleware runtime located at a remote smart house.








Figure 7-4 shows the snapshot during context checking and program deployment
process.


- ., - 1-
DI M ... .. . ..... ... .. ..... .. ..
'. .. .
............... I ....................... L I


Figure 7-4: Impermissible context verification


''1















DESCRIPTION LOGICS

Since the framework presented in this dissertation depends heavily on

description logics we will delve into more details and provide the mathematical

foundation of a description logic. A good understanding of the foundations

will show that the interpretation of sensor data using a description logic is

straightforward.

Description logics are concerned with describing knowledge about a problem

domain. A knowledge base consists of two parts:

Intensional knowledge (T-Box) TBox: The intensional knowledge contains

the general knowledge about a problem domain. It is defined in terms of

a terminology. A terminology defines a set of relations between various

concepts. For example an elder is a person. An elder is at least 75 ;/, ,- old.

Extensional knowledge (A-Box) ABox: Describes the specific knowledge to a

particular domain. A world description defines a set of individual instances

belonging to the defined terminology. For example: Mathilda is 85 ;. .,, old.

The knowledge base can now be used to derive additional information that is

not explicitly stated in the extensional knowledge. For example we can derive that

Mathilda is an elder, since she is 85 years old and nonee who is older than 75 is an

elder.

A.1 Describing Intensional Knowledge

The aim of intensional knowledge is to describe relationships between various

concepts in a problem domain. The key ingredients are concepts. Concepts are

names that refer to concepts that are used in the problem domain. There are two

types of concepts:









Primitive: A primitive concept (denoted by the letters AC) is a concept

that stands on itself. It refers to a valid concept in a problem domain. For

example the concept Location could refer to a location in the space.

Derived: A derived concept is a concept (denoted by the letter C or D) that

is defined in terms of relations to a set of primitive concepts. For example we

could iv that a Room has a Location inside a House.

Apart from simple names to organize concepts we can also add properties

to concepts. Properties are binary relations associating individuals from different

concepts together. For example a person can pl-l- the role of a parent, associating

another person to this person. We will use the letter R to denote a role.

We can now give the syntax of the language as follows:

Definition 12 (Basic language ALC [59]). Concept descriptions in L are formed

using the following syntax rule:

C, D A (atomic concept)

T (universal concept)

S(bottom concept)

-C (concept negation)

C n D (intersection)

CUD (union)

VR.C (universal /I,,'1A7. r)

3R.C (existential /I,a,',I.:; r)

The language ALC allows us to express various concepts. For example we

could define a "Happy pi' .. --.i using the atomic concepts Tenure and the role

F ,,,1J. './


HappyProfessor = Tenure n (3F',,1 :,.T)









A professor is happy if he (or she) has some form of funding and tenure.

The syntax above tells us how we can construct a valid sentence that described

a concept. Apart from the syntax we also need to add semantics to the syntax so

we can properly interpret the syntactical definition of a concept expression. We

need an interpretation I = (A', .z) that contains a non empty domain of interest

Az and an interpretation function .z that allows us to interpret our language. The

interpretation function maps every concept to a subset of A' and every role to a

subset of A' x A':

Definition 13 (Extensional Semantics of ALC). We /. I;,'. the interpretation I as

follows:
A' C A'

'= A'

Tz 0
Cz x Cz


(Cn D)' CZ n D

(CU D)z CZ U D

(VR.C)Z = a c AVb.(a.b) e Rz b e C}

(3R.C)Z = {a c Az3b.(a.b) C RZ A b e C}

Another way of giving semantics to ALC is by giving a correspondence with

first order logic (FOL). We can translate every concept definition into an equivalent

FOL. Atomic concepts and roles are mapped onto A(a) and R(a,/3) respectively. A

concept C and a role R correspond to the FOL formulae Fc(a) and FR(a,03) where

a and 3 denote free variables..









Definition 14 (Transformational Semantics of ALC). We /. I;,.: the interpretation

I as follows:
T = true

1- = false

-C1 = -Fc(a)

(Cn D)Z Fc(a) A F(a)

(CU D)Z Fc(a) V F(a)

(VR.C) = 3x.FR(a, x) A Fc(x)

(3R.C)Z = Vx.FR(a,(x) Fc(x)

Since we can give this transformational grammar it becomes clear that ALC is

a subset of FOL.

A.2 Terminologies

The previous section showed the basic ingredients that allow us define a

concept. In order to describe a domain of interest we need to specify how a group

of concepts relate to each other. The description of how a set of concepts relate to

each other is called a terminology or T-Box. A terminology is defined as follows:

Definition 15 (T-Box). We /. FI,:. a T-Box TBox as follows:

Inclusion: C E D with the interpretation Cz C DZ, i,,'.:,, that the concept

C is a subclass of D.

E./;,1.:1;,' C D with the interpretation Cz = DZ, ,,, ,.i.:,, that C can be

1r, ,'.l as D.

D. ril.'/,. .' An ;a,',l./I/ whose left hand side is atomic.

Unique: No symbol is 1. f,,, l more than once.

A-C,'; .:. 1 No 1 Fl;,.:l.:. n is (indir,. i;,) 1, i,. ,1 in terms of itself.

Concepts that only occur on the right hand side of definitions are called

primitive concepts. Notice that inclusion C E D can be expressed by introducing

a new base concept C as C = C n D. The idea is that C exactly captures the









difference between a C and a D. The inclusion does not really make a language

more expressible, it merely is a convenient way of describing how one concept is

more generic than another.

Notice that a T-Box as defined above can alv-i- be expanded into a T-Box

where every definition is defined in terms of only base symbols. The expansion

procedure recursively substitutes every defined concept occurring in a definition

with its defining expression. This procedure can generate a T-Box that is

exponential in size. In [69] it is shown that this blowup is polynomial if one

imposes some restrictions.

A.3 Extensional Knowledge

Extensional knowledge deals with actual individuals that are instances a

specific concept. For example we could state that the individual mathilda is a

person. Traditionally this is written as Person(Mathilda). An A-Box (ABox) is a

collection of such assertions.

In order to deal with individuals we extend the interpretation function Z in

such a way that for every individual a we have that az E A'. It is assumed that if

a and b are distinct names then a1 / bz

Concept membership C(a) can now be interpreted as a1 E Cz and role

fulfillment as (aZ, bZ) E R'.

A.4 Reasoning

There are basically two forms of reasoning that are of relevance for description

logic. Reasoning with intensional knowledge and reasoning with extensional

knowledge.

Reasoning with intensional knowledge deals with inferring relations that are

not defined but can be extracted from the description. The basic inference on

concept expressions is subsumption, written as C C D. We check if the first

concept ah--,v- is a subset of the second concept.









Subsumption is used in order to classify a knowledge base. The aim is to

infer which concepts subsume one another. Consider figure 2-1 in the previous

chapter. We can derive that a mother is a woman, since both mother and woman

are subclass of female and person.

Subsumption forms the base for extracting all other forms of relevant

information. The notion of satisfiability (i.e., assuring that every concept allows

at least one individual). A concept makes a knowledge base inconsistent if it

subsumes to the bottom concept which allows no individuals (i.e., the concept C is

inconsistent whenever: C C I).

The third form of reasoning is used to establish whether two concepts are

mutually exclusive. Meaning that it is not possible to find an instance of C that

is an instance of D as well. Disjointness can be computed by observing that

CnD .

For extensional knowledge we have two forms of inference that are of relevence.

First we have the problem of instance classification. That is given an individual

a we verify if a is an instance of that specific concept. Second is the retrieval

problem. Given a concept expression C which individuals a E ABox in the

knowledge base are an instance of this concept.

To sum things up, we have the following tools for reasoning available:

Subsumption: C E D #> CZ C DZ

Equality: C = D > C = DZ

Di- iil i. -- C and D are di-ji;l when Cz U Dz 0

Inconsistent: C = I

Membership: C(a) <> aZ E CZ

Retrieval: The retrieval of C is the set {a a E ABox A C(a)}









As shown above all of these can also be expressed using subsumption, so

any reasoning engine supporting subsumption can be used to verify the other

relationships as well.

A.5 Open-World versus Closed-World Assumption

One could -iv that a knowledge base is very similar to a database. The

intensional knowledge represents the database schema and the extensional

knowledge represents the data items contained within a database. This comparison

is natural, but there is however a key difference between a database and a

description logic. This difference lies in the approach both systems take to absence

of facts.When data is absent it might not be possible to deduce whether a certain

fact is true or not. In general this has lead to two approaches to dealing with the

absence of information:

Closed World: If it is impossible to prove whether a fact P or iP is true, we

assume that -P is true.

Open World: If it is impossible to prove whether a fact P or iP is true we

consider the fact to be undetermined for the time being.

Suppose we have the following statement:

Erwin is a citizen of the Netherlands

And the following question:

Is Erwin a citizen of the USA

Under the closed world assumption the only conclusion we can draw is No,

since the absence of the information implies that Erwin is not a citizen of the USA.

If we use the open world assumption however this cannot be concluded, and the

answer would be unknown, since Erwin could have a dual citizenship.

Another classic example is:

A Person can have only one Mother,

The mother of Erwin is Maria









Suppose we add the statement: The mother of Erwin is Mieke to our

knowledge base. Under the closed world assumption this would result in an

exception, since a Person (Erwin) can only have one mother. Under the open world

assumption the system would derive that Maria and Mieke are the same person.

Which happens to be the case in this particular example.

Databases normally operate under the closed world assumption, whereas

description logics operate using the open world assumption. The two different

approaches have both their advantages and drawbacks. The open world assumption

is more expressive, since if the fact P is absent we must consider a model where P

is true and a model where -P is true. Consider the example given in [59].

Suppose we have the following knowledge base:

hasChild(JOCASTA, OEDIPUS)

hasChild(OEDIPUS, POLYNEIKES)

hasChild(JOCASTA, POLYNEIKES)

hasChild(POLYNEIKES, THERSANDROS)

Patricide(OEDIPUS)

-Patricide (THESANDROS)

The knowledge base is shown in Figure A-1. Suppose we want to know

whether or not (3hasChild. (Patricide n 3hasChild. Patricide)) (JOCASTA)

holds,i.e the answer to the question whether Jocasta has at least two children, one

which killed his or her father and one that did not.

We cannot conclude this to be the case for Jocasta if we use the closed

world assumption. This follows from the fact that it is unknown whether or not

Polyneikes killed his father.

Under the open world assumption however there are two possible models, (as

shown in Figure A-1). One world in which Polyneikes is a patricide and one in













Jocasta


Jocasta


There are two possible
models, making the sentence
true!


(3hasChild.(Patricide n 3hasChild.-,Patricide))(JOCASTA)
Figure A-1: Open world versus closed world

which he is not. For both cases we can establish a model that makes the sentence

true. Hence we conclude this to be the case for Jocasta.















REFERENCES


[1] M. Weiser, J. Brown, Designing calm technology, PowerGrid Journal 1 (1).

[2] K. Lyytinen, Y. Yoo, Issues and challenges in ubiquitous computing,
Communications of the ACi\ 45 (12) (2002) 62-65.

[3] F. Bolton, Pure Corba, 1st Edition, Sams, Indianapolis, Indiana, USA, 2001.

[4] M. Gudgin, M. Hadley, N. Mendelsohn, J. Moreau, H. Nielsen, Soap version
1.2 part 1: Messaging framework, Tech. rep., World Wide Web Consortium,
Cambridge, MA (2003).

[5] A. E. Walsh, UDDI, SOAP, and WSDL: The Web Services Specification
Reference Book, Pearson Education, Upper Saddle River, NJ, 2002.

[6] L. Cardelli, A. D. Gordon, Mobile ambients, Theoretical Computer Science 240
(2000) 177-213.

[7] R. Want, A. Hopper, V. Falc6, J. Gibbons, The active badge location system,
ACi\ Trans. Inf. Syst. 10 (1) (1992) 91-102.

[8] G. (', i. D. Kotz, A survey of context-aware mobile computing research, Tech.
Rep. TR2000-381, Dept. of Computer Science, Dartmouth College (November
2000).

[9] B. N. Schillit, N. Adams, R. Gold, M. Tso, R. Want, The parctab mobile
computing system, in: Proceedings Fourth Workshop on Workstation
Operating Systems (WWOS-IV), IEEE, 1993, pp. 34-99.

[10] B. Brumitt, B. A1. l,- rs, J. Krumm, A. Kern, S. A. Shafer, Easyliving:
Technologies for intelligent environments, in: HUC '00: Proceedings of the
2nd international symposium on Handheld and Ubiquitous Computing,
Springer-V. i1 .- London, UK, 2000, pp. 12-29.

[11] J. Pineau, M. Montemerlo, M. Pollack, N. Roy, S. Thrun, Towards robotic
assistants in nursing homes: C'!! 11,!, i and results, Robotics and Autonomous
Systems 42 (2003) 271-281.

[12] N. A. Streitz, J. GeiBler, T. Holmer, Roomware for cooperative buildings:
Integrated design of architectural spaces and information spaces, in:
Proceedings of the First International Workshop on Cooperative Buildings,
Integrating Information, Organization, and Architecture, Springer-V i1 I-
Berlin, Germany, 1998, pp. 4-21.









[13] N. A. Streitz, J. GeiBler, T. Holmer, S. Konomi, C. Miiller-Tomfelde,
W. Reischl, P. Rexroth, P. Seitz, R. Steinmetz, i-LAND: An interactive
landscape for creativity and innovation, in: CHI '99: Proceedings of the
SIGCHI conference on Human factors in computing systems, AC'\ Press, New
York, NY, USA, 1999, pp. 120-127.

[14] W. Gale, K. W. C'lin, !I! D. Yarowsky, Estimating upper and lower bounds
on the performance of word-sense disambiguation programs, in: Proceedings
of the 30th annual meeting on Association for Computational Linguistics,
Association for Computational Linguistics, Morristown, NJ, USA, 1992, pp.
249-256.

[15] G. Toussaint, The use of context in pattern recognition, Pattern Recognition
10 (1977) 189-204.

[16] P. Brown, J. Bovey, X. C'!, i,1 Context-aware applications: from the laboratory
to the marketplace, IEEE Personal Communications 4 (5) (1997) 58-64.

[17] N. S. Ryan, J. Pascoe, D. R. Morse, Enhanced reality fieldwork: the context-
aware archaeological assistant, in: V. Gaffney, M. van Leusen, S. Exxon (Eds.),
Computer Applications in Archaeology 1997, British Archaeological Reports,
Tempus Reparatum, Oxford, UK, 1998.

[18] G. D. Abowd, A. K. Dey, P. J. Brown, N. Davies, M. Smith, P. S'-, Z-'
Towards a better understanding of context and context-awareness, in:
Proceedings of the 1st international symposium on Handheld and Ubiquitous
Computing, Springer-Verlag, Berlin, Germany, 1999, pp. 304-307.

[19] G. D. Abowd, A. K. Dey, R. Orr, J. A. Brotherton, Context-awareness in
wearable and ubiquitous computing, in: ISWC '97: Proceedings of the 1st
IEEE International Symposium on Wearable Computers, IEEE Computer
Society, Washington, DC, USA, 1997, p. 179.

[20] B. Schilit, N. Adams, R. Want, Context-aware computing applications, in:
IEEE Workshop on Mobile Computing Systems and Applications, Santa Cruz,
CA, US, 1994.

[21] A. K. Dey, D. Salber, G. D. Abowd, A conceptual framework and a toolkit
for supporting the rapid prototyping of context-aware applications, Human-
Computer Interaction (HCI) Journal 16 (2001) 97-166.

[22] D. Salber, A. K. Dey, G. D. Abowd, The context toolkit: Aiding the
development of context-enabled applications, in: CHI '99: Proceedings of
the SIGCHI conference on Human factors in computing systems, AC'\ Press,
New York, NY, USA, 1999, pp. 434-441.









[23] J. A. Brotherton, G. D. Abowd, K. N. Truong, Supporting capture and
access interfaces for informal and opportunistic meetings, Tech. rep., Georgia
Institute of Technology, Atlanta, Georgia, USA (1999).

[24] K. N ;,. 1 C. D. Kidd, T. I'Connell, A. K. Dey, G. D. Abowd, The family
intercom: Developing a context-aware audio communication system, in:
UbiComp '01: Proceedings of the 3rd international conference on Ubiquitous
Computing, Springer-Verlag, London, UK, 2001, pp. 176-183.

[25] A. K. Dey, D. Salber, G. D. Abowd, M. Futakawa, The conference assistant:
Combining context-awareness with wearable computing, in: ISWC '99:
Proceedings of the 3rd IEEE International Symposium on Wearable
Computers, IEEE Computer Society, Washington, DC, USA, 1999, p. 21.

[26] N. H. Cohen, A. Pui I1: .,i- i-i L. Wong, D. L. Yeh, iqueue: A pervasive data
composition framework, in: Proceedings of the Third International Conference
on Mobile Data Management, IEEE Computer Society, Washington, DC, USA,
2002, p. 146.

[27] N. H. Cohen, H. Lei, P. Castro, J. S. D. II, A. Pui I1: ,i-l- i, Composing
pervasive data using iql, in: Proceedings of the Fourth IEEE Workshop
on Mobile Computing Systems and Applications, IEEE Computer Society,
Washington, DC, USA, 2002, p. 94.

[28] G. C(! i1, D. Kotz, Solar: An open platform for context-aware mobile
applications, in: an informal companion volume of short papers of the
Proceedings of the First International Conference on Pervasive Computing,
Zurich, Switzerland, 2002, pp. 41-47.

[29] G. C(! i1, D. Kotz, Context-sensitive resource discovery, in: First IEEE
International Conference on Pervasive Computing and Communications
(PerCom'03), Dallas-Fort Worth, Texas, USA, 2003, pp. 243-253.

[30] G. (C! in, D. Kotz, Context ..-i--regation and dissemination in ubiquitous
computing systems, in: Proceedings of the Fourth IEEE Workshop on Mobile
Computing Systems and Applications, IEEE Computer Society Press, New
York, USA, 2002.

[31] R. Kumar, M. Wolenetz, B. Agarwalla, J. Shin, P. Hutto, A. Paul,
U. Ramachandran, Dfuse: a framework for distributed data fusion, in:
Proceedings of the first international conference on Embedded networked
sensor systems, AC'\ I Press, New York, NY, USA, 2003, pp. 114-125.

[32] M. Roman, C. K. Hess, A. Ranganathan, P. Madhavarapu, B. Borthakur,
P. Viswanathan, R. Cerqueira, R. H. Campbell, M. D. Mickunas, Gaiaos: An
infrastructure for active spaces, Tech. rep., University of Illinois at Urbana-
C(Il il1p ir;l (2001).









[33] C. K. Hess, M. Roman, R. H. Campbell, Building applications for ubiquitous
computing environments, in: Pervasive '02: Proceedings of the First
International Conference on Pervasive Computing, Springer-Verlag, Berlin,
Germany, 2002, pp. 16-29.

[34] G. Krasner, S. Pope, A description of the model-view-controller user interface
paradigm in the smalltalk-80 system, Journal of Object Oriented Programming
1 (3) (1988) 26-49.

[35] R. Ieru- i1iii-i, !i-, L. H. de Figueiredo, W. C. Filho, Lua -an extensible
extension language, Software Practice and Experience 26 (6) (1996) 635-652.

[36] T. Gu, H. K. Pung, D. Q. Zhang., A service-oriented middleware for building
context-aware services, Journal of Network and Computer Applications
(JNCA) 28 (1) (2005) 1-18.

[37] H. C'!i. T. Finin, A. Joshi, F. Perich, D. Chakraborty, L. Kagal, Intelligent
agents meet the semantic web in smart spaces, IEEE Internet Computing
8 (6).

[38] D. Cook, M. Youngblood, E. Heierman, K. Gopalratnam, S. Rao, A. Litvin,
F. K! ix- ii I Mavhome: An agent-based smart home, in: proceeding of the
Conference on Pervasive Computing (PERCOM '2003), Dallas-Fort Worth,
Texas, USA, 2003.

[39] D. J. Cook, S. Das, Smart Environments: Technologies, Protocols and
Applications, John Wiley and Sons., Hoboken, NJ, USA, 2004.

[40] T. Berners-Lee, J. Hendler, O. Lassila, The semantic web, Scientific American
279 (5).

[41] P. P.-S. (C! ii, The entity-relationship model, toward a unified view of data,
AC \l Transactions Database Systems 1 (1) (1976) 9-36.

[42] J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language
Reference Manual, Addison-Wesley, Boston, MA, 1998.

[43] R. J. B. A. Borgida, The Description Logic Handbook, Cambridge University
Press, Cambridge, UK, 2002, Ch. Conceptual Modelling with Description
Logic, pp. 359-381.

[44] I. S. Graham, Xml Specification Guide 3, John Wiley and Sons, Hoboken, NJ,
1999.

[45] S. Powers, Practical RDF, O'Reilly Media, Inc., Sebastopol, CA, 2003.

[46] D. Nardi, R. J. Brachman, The Description Logic Handbook, Cambridge
University Press, Cambridge, UK, 2002, Ch. An Introduction to Description
Logics, pp. 359-381.









[47] H. J. Levesque, R. J. Brachman, Expressiveness and tractability in knowledge
representation and reasoning., Computational Intelligence journal 3 (1987)
78-93.

[48] L. W. Lacy, Owl: Representing Information Using the Web Ontology
Language, Trafford Pul.11-1iir- Oxford, UK, 2005.

[49] J. P. Burgess, Basic tense logic, in: D. M. Gab'.-, F. Giinthner (Eds.),
Handbook of Philosophical Logic, Vol. 2, Reidel, Dordrecht, The Netherlands,
1984, pp. 89-133.

[50] B. C. Moszkowski, Some very compositional temporal properties, in:
PROCOMET '94: Proceedings of the IFIP TC2/WG2.1/WG2.2/WG2.3
Working Conference on Programming Concepts, Methods and Calculi, North-
Holland, 1994, pp. 307-326.

[51] W. Thomas, Automata on infinite objects., in: J. Leeuwen (Ed.), Handbook of
Theoretical Computer Science: Formal Models and Semantics, Vol. B, Elsevier,
Amsterdam, The Netherlands, 1990, pp. 133-191.

[52] W. Thomas, Languages, automata, and logic, in: G. Rozenberg, A. Salomaa
(Eds.), Handbook of Formal Languages, Vol. 3, Springer Verlag, Heidelberg,
1997, Ch. 7, pp. 389-455.

[53] A. Valmari, The state explosion problem, in: Lectures on Petri Nets I: Basic
Models, Advances in Petri Nets, the volumes are based on the Advanced
Course on Petri Nets, Springer-V i1 -. London, UK, 1998, pp. 429-528.

[54] S. Eker, J. Meseguer, A. Sridharanarayanan, The made LTL model checker,
in: F. Gaducci, U. Montanari (Eds.), Proceedings of the 4th International
Workshop on Rewriting Logic and Its Applications (WRLA 2002), Vol. 71 of
Electronic Notes in Theoretical Computer Science, Elsevier, Amsterdam, 2002.

[55] G. J. Holzmann, The model checker SPIN, Software Engineering 23 (5) (1997)
279-295.

[56] L. Bolc, A. Szalas, Time and Logic: A Computational Approach, UCL Press,
London, UK, 1995.

[57] I. M. Hodkinson, F. Wolter, M. Zakharyaschev, Decidable and undecidable
fragments of first-order branching temporal logics, in: LICS '02: Proceedings
of the 17th Annual IEEE Symposium on Logic in Computer Science, IEEE
Computer Society, Washington, DC, USA, 2002, pp. 393-402.

[58] S. ?1, l,, r, A. Rakotonirainy, A survey of research on context-aware homes,
in: Proceedings of the Australasian information security workshop conference
on ACSW frontiers, Vol. 21, Australian Computer Society, Inc, Darlinghurst,
Australia, Australia, 2003, pp. 159-168.









[59] F. Baader, D. Calvanese, D. McGuinness, D. Nardi, P. Patel-Schneider (Eds.),
The Description Logic Handbook, Cambridge University Press, Cambridge,
UK, 2002.

[60] A. Artale, E. Franconi, A survey of temporal extensions of description logics,
Annals of Mathematics and Artificial Intelligence 30 (1-4) (2000) 171-210.

[61] K. Schild, Combining terminological logics with tense logic, in: EPIA '93:
Proceedings of the 6th Portuguese Conference on Artificial Intelligence,
Springer-V, i1 .- London, UK, 1993, pp. 105-120.

[62] J. P. Burgess, Basic tense logic, in: D. C .1,1 .*v, F. Guenther (Eds.), Handbook
of Philosophical Logic, Volume II: Extensions of Classical Logic, Kluwer
Academic Publishers, Dordrecht, The Netherlands, 1984, pp. 89-133.

[63] J. van Benthem, The Logic of Time, D. Reidel Publishing Conri Ir:v,
Dordrecht, The Netherlands, 1983.

[64] E. Emerson, J. Y. Halpern, Decision procedures and expressiveness in the
temporal logic of branching time, Journal of Computer and System Sciences
30 (1) (1985) 1-24.

[65] C. Lutz, A tableau calculus for temporal description logic: The constant
domain case, LTCS-Report 01-01, LuFG Theoretical Computer Science,
RWTH Aachen, Aachen, Germany (2001).

[66] H. Sturm, F. Wolter, A tableau calculus for temporal description logic: the
expanding domain case, Journal of Logic and Computation 12 (5) (2002)
809-839.

[67] T. Gu, H. K. Pung, D. Q. Z!i Ii:- Towards an osgi-based infrastructure for
context-aware applications in smart homes, IEEE Pervasive Computing 3 (4).

[68] M. Wooldridge, Reasoning about Rational Agents, The MIT Press, Cambridge,
Massachussetts/London, England, 2000.

[69] B. Nebel, Terminological reasoning is inherently intractable, Artificial
Intelligence 43 (1990) 235-249.















BIOGRAPHICAL SKETCH

Erwin was born in Maarheeze, a small village in the province Brabant in

the Netherlands. He attended the University of Utrecht and obtained a master

of arts degree in computer science. Erwin's main research interests are pervasive

computing, artificial intelligence, protocol verification and searching in peer-to-peer

systems.