Feature Ideas for the new Mobile Portal

We’re currently working out what kind of features we’d like to present to users (both staff and students) on the up-and-coming mobile portal. At the moment we have the following ideas (in no particular order of priority):

• Contact search – This could possibly be location-based, e.g. “Find all lodge / reception numbers for buildings that are near me”.
• OLIS search – Find a book by title, ISBN etc., and be presented with a map of relevant libraries.
• Emergency contact numbers – e.g. University security services, NHS direct, the OBSU/OUSU Safety Bus, police.
• Wake-on-LAN (WoL) – As part of the University’s Green IT initiative, many departments support WoL to encourage people to turn off their computers overnight. Being able to turn your PC on from your mobile as you enter the building could save Vital Seconds.
• A condensed calendar – With the move to a University-wide calendaring solution we should be able to present a simplified interface to one’s itinerary.
• OUCS service status
• University / departmental news feeds
• Simplified access to the new VLE, WebLearn.

Anything else you’d like to see in that list? A major hurdle we’re still working out how to overcome is the issue of authentication and delegated authority. Some of these ideas (such as WoL, calendaring and the VLE) require the user to authenticate, which they’d either have to do directly (requiring each project to implement a separate mobile interface) or we’d act on the user’s behalf (requiring each service to implement an API for use by the mobile portal). OAuth may not fit the use case exactly as it requires the user to confirm access from the delegated service, which isn’t mobile-friendly.

Other points of inspiration include the mobile portals of the MIT, Warwick University, the University of Iowa, and Swinburne University.

Thoughts and suggestions welcome!

Talk to OxPoints! E-mail and Twitter

Tweeter tweeting #oxp

As our new OxPoints system is starting to take shape, people have started coming to us with more use-cases and feature requests. To aid in this process we’ve got two main methods of communication for you:

Twitter:
Follow us, message us @oxforderewhon
If you want to talk about OxPoints we encourage you to use the tag #oxp which will help us track all talk relating to OxPoints and hopefully provide you with a better service.

E-Mail:
erewhon@oucs.ox.ac.uk
If you prefer e-mail, chuck us some suggestions, problems etc at this address.

Software Development with Certainty

The current phase of the project is to turn an impressive prototype developed by one person into a library, and applications based upon it, that can be simultaneously developed and used by a team.

The development process gains a new dimension once you have published your first version or have your first user. The task is made more tricky due to the absence of the original author.
In other words: situation normal, don’t start from here.

The Erewhon applications, Gaboto library and its main dependencies ng4j and Jena are all changing rapidly. New functionality is being added and code and dependencies are being refactored and changed. The challenge is to enable this change without breaking installed systems or at least not breaking them unknowingly. This is ensured by establishing a contract between the code and the design by the use of tests. The tests guarantee that the system actually does do what it claims. Or, more properly, the tests are exactly what the system claims to do.

A simple library mashup

At the Erewhon workshop in December we asked people to choose/suggest applications for geodata. One of the favourites was: “Find the nearest copy of a book from a reading list (bearing in mind which libraries you can use, and the opening hours of libraries)” so we decided to use this as an example of how we’d begin to use Oxpoints data to enhance other services.

Ingredients:

• Locations of many libraries already in Oxpoints data
• A list of all libraries, with unique codes
• Search results pages on OLIS (Oxford’s OPAC), conveniently including library codes (below)

A library search results page

We couldn’t easily get hold of the patron data (i.e. which libraries a user has access to), and the opening hours looked fairly indigestible in their current form (see example); so we decided to leave these out of this mashup.

Exploring Oxpoints: directions from place to place

In order to demonstrate the data now available in Erewhon’s
geodata store, Oxpoints, I wanted a way to quickly browse
the holdings on a simple web page. Oxpoints already has a way
to show a map of all departments (for example), by opening
http://m.ox.ac.uk/oxpoints/departments.kml, but that means opening
Google Earth or loading it into Google Maps. If instead we
specify
http://m.ox.ac.uk/oxpoints/departments.xml, an XML
representation of all the data is returned, which can be fairly easily
transformed into HTML for display.

Since we have a lot of XSLT expertise to hand in the Erewhon project,
I decided to write this service as an XSL transform, mediated by a
Perl CGI wrapper. The result is shown at
http://m.ox.ac.uk/cgi-bin/oxshow.pl:

New OxPoints and how to use it!

It’s been a while since we’ve posted anything about OxPoints, but at last we now have a lot of Arno Mittelbach’s work in Gaboto implemented into our new OxPoints system. With a new home at http://m.ox.ac.uk/oxpoints !

Last Friday we announced the availability of a few ways to access queries from our new system at an OxPoints workshop in OUCS. Here’s a brief overview of what you can get out of our new oxpoints system as of today.

We’re aiming to improve features incrementally and as demand dictates, so for now we’re offering a simple URL access method to get at a few pre-defined queries (more on complex queries later). The stem for all OxPoints queries is:

http://m.ox.ac.uk/oxpoints/

Following this, you’ll have to specify the query. As of today, we support two main query types -

1. Query by item type (receives list of all items of a certain type).
2. Query by OUCS/OLIS code (receive a list of all items associated with a unit, as specified by unique id from computing services or library services)

Item types available -

1. colleges
2. departments
3. museums
4. libraries
5. carparks

Next we need to add a file type extension. We support a number of types but these are our primary formats:

Full Data Output

1. .json (Direct JSON transformation of all data related to a query)
2. .xml (RDF XML – not completely compliant.. yet)

Simplified Output (usually adequate for 95% of uses) – omits irregularly used fields

1. .kml (Keyhole Markup Language – perhaps the most common, used by Google Earth & Maps)
2. .gjson (Simplified version of .json, omitting irregularly used fields and is easier to read)
3. Almost any format supported by GPSBabel

Some simplified formats output via GPS Babel (not supported but should work):

• .tomtom
• .csv
• .yahoo

Examples:

All college data represented in JSON: http://m.ox.ac.uk/oxpoints/colleges.json

Oxford University Car Parks in TomTom format: http://m.ox.ac.uk/oxpoints/carparks.tomtom

Sakai tools

Earlier this year we surveyed all the tools available to us in our Sakai VLE, with a view to deciding which were the top candidates for mobilisation (whether by developing a new mobile-friendly interface or by tidying up the existing tool).

When evaluating these tools we tried to consider:

1. how widely they were used
2. how relevant they were to mobile use, and
3. whether they were reasonably implementable within the timeframe of the project

As a result we’ve divided the tools into four categories:

1. essential
2. desirable
3. initially unnecessary
4. unnecessary or unfeasible

We’ve concentrated on tools which provide the best ratio of participation to user-input (input of extended information is often difficult and time-consuming on the keypads or miniature keyboards of even the most modern smartphones), and on tools which allow the user to perform a single discrete task (e.g. “see what’s new”, “answer a poll”, “sign up for a tutorial”) rather than more complex tasks requiring extensive navigation. These more discrete tasks also allow for atomic operations rather than requiring the preservation of state throughout potentially unreliable network access — hopefully avoiding that only-too-familiar “I got halfway through and then I lost the signal and now I don’t know if it’s sent it or not” user experience.

Oxford now a member of the University iPhone Developer Programme

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

National Rail App Released for the iPhone

A quick post to note that National Rail has released an application for the iPhone/iPod Touch which allows for comprehensive live train departure boards and journey planning. Head over to: http://nationalrail.co.uk/iphone/ for more information and a demo.

It’s probably the most comprehensive mobile transport application in the UK and is certainly a welcome replacement for the now missing Kizoom MyRail Lite which strangely disappeared from the Apple App Store some time ago.

The new OxPoints

After spending lots of time looking into RDF and how we could use RDF as the data model for the new OxPoints system we finally decided to give it a try. One of the big problems we had with RDF was the difficulty of storing dimensional data as one of the key features of the new OxPoints system should be its ability to record the change of Oxford University over time. However, RDF does not really cope with change and we had to think about how to work around this. We presented a detailed description and two possible workarounds in previous posts:

• RDF – an Introduction
• RDF and the Time Dimension – Part 1
• RDF and the Time Dimension – Part 2

Both solutions are somewhat similar as they try to add additional RDF statements to define the validity of other statements. Solution one was to use statement reification and to add temporal information on individual statements. The other way we saw was to use named graphs and use different graphs to group statements that talk about the same time span. In the end we decided to go with the second solution, as it seemed to be the cleaner and more efficient solution.

As the platform for the new system we chose Java with Jena as the underlying RDF triple store.

We have spend the last weeks developing the prototype and so far the results are promising. The minimal requirements for the new system were to do everything the old system does, which was basically to allow for point queries (ask for a specific unit, or for a specific type) and to transform the results into KML.
Besides KML the new system offers transformations into JSON and RDF for any kind of resultset produced by the system and it is able to handle the temporal aspect of the data. In fact the new system is much more powerful and not specific to OxPoints at all. It is an RDF to Java object mapper (comparable to object relational mapping systems) and we are currently working on documentation and we are hoping to make more information available soon.

A first demo we produced, built upon the new OxPoints, is a Greasemonkey script that adds links to the OLIS (Oxford Libraries Information System) result pages, to display where a particular library is, using Google maps. The demo is not yet publically available but we are working hard on publishing this and more demos soon.

Screenshot of library demo