As of this afternoon, the University of Oxford is a member of the iPhone Developer programme which can help facilitate the production and distribution of applications to potential developers within the organisation (and to the app store). If you are a member of the University and would like to submit an app to the app store or require provisioning to allow testing on your devices, please drop a line to erewhon at oucs.ox.ac.uk
Location Based Services (LBS) require us to know where we are to differing degrees of accuracy, so how can we best obtain this information electronically in different scenarios? Below is a list of common technologies we can use today to help determine our location:
- Point Of Interest (accuracy of points of interest database and identification by human)
We can enter a known point of interest, e.g. a church to let an algorithm search through a database of known places and thus find where we are.
- Traditional Maps (accuracy dependant on reading of map)
If we know where we are on a map, we can enter a latitude/longitude by reading scales along the side of the map or ordinance survey grid coordinates.
- WiFi Positioning (accuracy <100m)
Many mobile devices now have WiFi built in, by reading the SSID or MAC Address of a WiFi hotspot, we can search through a database of hotspots with known locations to find out where we are by virtue of WiFi hotspots having a range of <≈ 100m.
- Cell Tower ID (accuracy 200m – 32km)
Using a similar method to WiFi positioning a mobile phone will be connected to one GSM cell transceiver at any one time by knowing the ID of the transceiver and comparing that with a database of known locations we can obtain a location with varying degrees of accuracy. Within urban areas where transceiver density is high, we can expect accuracy in the order of hundreds of metres. Whereas further out in the countryside where there are less users and fewer black spots accuracy will be in the order of kilometres.
- Cell Tower Triangulation (accuracy – unreliable)
As GSM mobile phones are designed to be able to hop between different cell transceivers as the user moves across the land/air, they must be looking out for other transceivers that they may be able to jump to in case they lose signal with the cell they are currently connected to. Because of this the phone will keep a regularly updated list of cell towers it can ‘see’, the relative signal strength of each and their IDs. By comparing the signal strengths of known cell towers it is possible to triangulate the position of the user. This method is rarely used due to the extremely difficult nature of comparing signals with confidence, for example transmitter A may have a signal which is 10dB weaker than transmitter B and therefore we may deduce that transmitter B is closer to us. However, it may be that transmitter A is actually much closer to us, but is hidden behind a hill and thus displays a lower signal than B which has direct line of sight to us but is further.
- Inertial Navigation Systems (accuracy losses of > 0.6 nautical miles per hour)
An Inertial system comprises of motion-sensing devices (often gyroscopes or accelerometers) which are used to determine forces exerted on the moving object over a period of time. By measuring these forces, we are able to determine that the object has moved a certain distance. Inertial systems therefore require the user to calibrate the system prior to it being used and thus are not particularly practical for personal navigation. However, for personal applications it can be used in conjunction with a different positioning method to provide a backup in case the primary method fails. For example, this is sometimes used on high-end car GPS based navigation systems where it is used to keep a ‘lock’ on the vehicle’s position when inside a tunnel. Inertial Navigation Systems have been used predominantly on aircraft but are being replaced by GPS systems in the US and similarly will be the world over when Europe’s Gallileo and China’s Compass are launched.
- GPS – Global Positioning System (accuracy <≈ 10m)
GPS was established in the early nineties, although it was not until the middle of the year 2000 when the accurate positioning channels of the system were available for civilian use. Since then, there has been an explosion in satellite navigation options and devices for consumer use which has helped spur growth in LBS. In simple terms, GPS consists of a constellation of around thirty satellites, each orbiting the earth twice a day. Each of these satellites transmits the time according to its on-board atomic clock. Your GPS device receives these time signals and compares the time sent on each signal. The difference in time between each of the signals lets us calculate our relative distance to each satellite (the time signal will be delayed according to the distance between the satellite and the receiver according to the speed of light). By knowing the distances of the known locations of the satellites we can triangulate our location. For best accuracy GPS requires that the receiver have an open, unobstructed view of the sky as it is easily susceptible to various distorting effects e.g. obstructions in direct line of sight, ‘urban canyon’ effect, ionospheric disturbances etc.
- Consumer methods of improving GPS accuracy (more to follow):
- WAAS/EGNOS (SBAS)
On Friday December 5th we held our first Erewhon workshop — an opportunity for us to tell people about the aims of the project, get their feedback on some of our initial ideas, and give them a chance to make suggestions of their own. Despite a few last-minute cancellations we still had about 40 attendees (staff and students) — not a bad turnout for the last day of term!
The first half of the workshop was all about ‘setting the scene’, showing the technological landscape we’re working in. Tim started this off with a lively overview of the capabilities of smartphones, with demonstrations of a wide variety of tools on the iPhone, the G1 and the HTC TyTN — the aim being to show people just how much functionality is already available and in use now (and, by extension, what imagined possibilities might be reality by this time next year…). We wanted to make it clear that we’re not just talking about browsing the web on a small screen; we’re talking about the phone as a platform and an interface in its own right.
From the technological landscape we moved to the physical landscape, and our attempts to map it; I gave an overview of the work we’d done so far on ‘OxPoints’ (the original name for our fledgling geo database), the data we’d amassed, the simple services already available making use of that data (more about that on the handout — see link below), and the direction the new data model was taking; building on this, Sebastian then talked about some of the more exciting future possibilities for mapping, creating visualisations, and enhancing existing services.
After deciding to implement the new OxPoints system with Semantic Web technologies (see OxPoints and the Semantic Web) I started to read up on all I could find on RDF (Resource Description Framework) and related technologies like RDFS and OWL. In particular I was looking for
- best practices and
- reports on projects using RDF.
I was astonished to find that, even though many people talk about RDF, it seems that only very few have actually ever used it (i.e. outside academic studies). Or if they have, they at least did not tell anyone about it.
However, one thing, that I did definitely not expect to find was that there seems to be a fundamental design flaw in RDF. I thought about this a lot, and hope that by blogging about it, you will either tell me, that I am wrong and how to do it right, or that we might find a solution on how to solve the problem.
But before talking about what I think is wrong with RDF and proposing one way to solve that problem (yes, luckily I think there is a solution), we need to establish a common language, which is what I want to achieve with this introduction. If you are already familiar with RDF, you might want to have a look at the sections: Triples are Facts, Reification and Entailment. If you are new to RDF, I hope that this will give you a first start. However, I kept this introduction very short and so many aspects are missing. If you want to learn more about RDF I would recommend you to start with the RDF Primer, the introduction to RDF from the W3C. In most sections I have also linked the specific sections from the RDF Specifications.
I will try to assume as little previous knowledge as possible, but since RDF is not a trivial topic, I have to start somewhere. Basic knowledge of XML and some knowledge of mathematical notation would therefore probably be of help.
RDF (Resource Description Framework)
The Resource Description Framework (or short RDF) is a set of W3C specifications which were first published in 1999 and revised in 2004 (more information on the history of RDF can be found at its Wikipedia page or at the W3C pages on RDF). RDF is “a language for representing information about resources in the World Wide Web” (RDF Primer [http://www.w3.org/TR/REC-rdf-syntax/]).
So what are resources in the World Wide Web?
One of the main strands of our work on this project is geolocation — ‘where we are’ — so it felt quite appropriate to kick-start the project with last week’s two-day orientation meeting for all the ‘institutional innovation’ projects. This intensive session helped us to focus on ‘where we are’ not just in relation to the JISC — the wealth of supporting frameworks and infrastructure made available to us, and the rights and responsibilities which must underpin our work — but also in relation to our fellow institutional innovators. That side of things was more about inspiration, an opportunity to see ourselves as part of the wider web, part of a shared vision for more interconnected (and intraconnected) institutional services. It wasn’t all serious and abstract, though; we had a lot of fun visualising the actual and potential links between instutitions with a hands-on creative mapping exercise (and a lot of fighting for the use of marker-pens, which hopefully doesn’t reflect the institutional attitude to other resources!), and most of the real work ofmaking connections with colleagues took place at the dinner-table and in the bar…
Discussions about the themed ‘clusters’ of projects (suggested to us by JISC as a starting-point for collaboration) got a bit heated on Friday morning, as we debated how trusted networks are formed between people, and whether synthetic connections — patterns imposed from outside — can be as strong or effective as the more ‘organic’ communities we naturally grow into. The question remained unresolved, of course, but it’s an interesting analogy for the networked services we’ll be researching and building in our project: are we providing things which people will want to buy into, or will users feel that we’re trying to stamp our own shape on their social networks or their patterns of working? Can we guard against this by listening to our users?