Bluetooth detection points. These can be any device which is capable of detecting bluetooth devices, and then send the information over HTTP to the central mapper. They also need to know their own location, any Bluetooth PC, or PDA, or even many mobile phones are capable of this.
Mapping server. The mapping server needs to collate the information from the various devices, and plot the locations on the map, all very simple.
Tieing people to their bluetooth device Bluetooth devices all have unique addresses, similar to an ethernet mac-address. If users include the address of their bluetooth devices in their FOAF files, then we get to tie all the information to the device. However there is little to be gained by having the address freely available, so a SHA1 hash of the address is more appropriate to avoid spoofing. The address should be in all lower-case, and use a : as a seperator e.g. 00:40:05:aa:77:de
The FOAF file
The bluetooth address is introduced into the file with a address_sha1sum in the Bluetooth namespace - http://jibbering.com/vocabs/bluetooth#. Example RDF/XML snippet:
<foaf:Person> <foaf:name>Jim Ley</foaf:name> <foaf:mbox rdf:resource="mailto:firstname.lastname@example.org"/> <BT:address_sha1sum>2cadc55f5ec9d13e17cb44f87159edb5ead8fac6</BT:address_sha1sum> </foaf:Person>
The Detection Point Protocol
The detection points will register themselves to the central server by sending an RDF file by HTTP post, similar to:
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:BT="http://jibbering.com/vocabs/bluetooth/#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <BT:SpottingDevice> <BT:address_sha1sum>37a5875adb18739b3931a041a3d06b7e62208114</BT:address_sha1sum> <geo:lat>50.629345</geo:lat> <geo:long>-3.388382</geo:long> <BT:posX>100</BT:posX> <BT:posY>100</BT:posY> <BT:posZ>100</BT:posZ> <BT:range>10</BT:range> <BT:ownedBy> <foaf:Person foaf:mbox_sha1sum="35022e505e6a64c05837eccf4beb5d8f981a4e5a"/> </BT:ownedBy> </BT:SpottingDevice> </RDF>
This says there is a detection point with a bluetooth address, which will alos be unique and can therefore be used to uniquely identify the detection point. The posX/posY/posZ properties can be used in place of the lat/long properties for when the detection point is inside a building or otherwise not easily locatable globally, an agreement on which co-ordinate space these points were defined in would need to be agreed, that's currently an open issue. Range is the range of the device, so as to tell exactly how close the devices might be.
The Discovery Protocol
When a detection discovers a new device, it should send an HTTP post to the server with an RDF document similar to:
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:BT="http://jibbering.com/vocabs/bluetooth/#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <BT:SpottingDevice> <BT:address_sha1sum>37a5875adb18739b3931a041a3d06b7e62208114</BT:address_sha1sum> <BT:deviceFound> <BT:Device> <BT:ID>Jibbering.com</BT:ID> <BT:address_sha1sum>37a5875adb18739b3931a041a3d06b7e62208114</BT:address_sha1sum> <BT:date>2003-09-15Z19:22:00</BT:date> </BT:deviceFound> </BT:Device> </BT:SpottingDevice> </RDF>
This announces the new bluetooth device, and the time it was discovered, when the device is lost, a similar document should be posted, but using BT:deviceLost. Since we cannot rely on recieving any packets on the server, there may be a case for deviceStillHere packets being sent to allow the server to know that the device is still there, when a person doesn't move for some time. This is another open-issue.
The server will use FOAF data, from an appropriate data source, and tie this with the bluetooth data to plot the locations of people.
Still to do
- Finish the demo implementation.
- Solve data-privacy, authentication of the data - who can view where you are?
- Find some people to run detectors.