An Ontology Editor for Android. 4. Mobile Considerations - Ontology Load Times

In my last post, I showed the beginnings of an ontology editor for Android come into existence. When I developed this first version, I did so mainly against relatively small ontologies, such as the General Formal Ontology, the Basic Formal Ontology and others.

Once this was stable, I tested in particular the loading of ontologies without import statements (which need to be resolved over the web) from a location on the device. As I was part of the ChEBI team for a short while, it was natural to try and use ChEBI.

Well, I was in for a rude shock. Once I had selected the ontology and started to load - well - nothing happened. The application didn't crash and the developer console clearly indicated that it was running - and more importantly, that the memory allocated to this process was expanding and expanding. So I stopped the loading and decide to dig into this a bit more. 

Logging on Android

Android has a rather wonderful logging framework built in and getting hold of the data was a breeze using the Android TimingLoggerClass:

TimingLogger timings = new TimingLogger("LOAD", "ontology loading");

ontology = manager.loadOntologyFromOntologyDocument(in);
timings.addSplit("LoadTime");
timings.dumpToLog();
Log.d("LOAD", "loading finished");

The output from the logger will then show up in the LogCat console.

 

Ontology Load Times

To get a better handle on loading behaviour I started to look at load times for ChEBI (can't remember which version - this is not a completely scientific experiment), GFO and DOLCE Light. I loaded each ontology from the shared storage area on the device into the application and observed the load process. The experiment was repeated 10 times for each ontology. The link to the data is here. The bottom line is: GFO and Dolce-Light with its 78 and 37 classes respectively had reasonably similar load times (within standard deviation): 483 (+/- 38) ms and 540 (+/-35) ms. Still somewhat surprising as Dolce-Light is the smaller ontology and should have loaded faster (but maybe there are other factors at play here). ChEBI by contrast required a whopping 370391 (+/-7039) ms - i.e. about 6 minutes - to load. The device didn't crash and I could explore the class list just fine. I did, however, have to remove memory restrictions on the application and allow OntoDroid to just take over whatever device memory it could get hold of.

This is a problem which - in time - will probably solve itself as devices get more powerful. Until then, however, it has got consequences for how to program - OWLOntology is not serialisable and hence cannot just be passed around via Intents.

More about this later.

 

An Ontology Editor for Android. 3. It's here.

Due to the usual combination of distractions caused by work and a significant amount of travel, I haven't blogged on this as much as I wanted to recently. Still, the ontology editor project for Android is progressing and a first version is here. There are bugs still (of course) and design wise it is pretty squidgy round the edges (more material for another blog post), but it does many of the things I set out as specifications in my previous post.

Here are some screenshots that show the current progress.

 

 The Start Screen.

The Start Screen.

 Loading an ontology from a shared location: the Downloads folder.

Loading an ontology from a shared location: the Downloads folder.

 Displaying a list of ontology classes. Here, the  General Formal Ontology (GFO)  has been loaded.

Displaying a list of ontology classes. Here, the General Formal Ontology (GFO) has been loaded.

 A detailed view onto a class and the ability to add subclass/superclass relationships.

A detailed view onto a class and the ability to add subclass/superclass relationships.

 Editing a class.

Editing a class.

 Creating a new ontology - defining IRIs and file name. From there it goes into the editor shown above.

Creating a new ontology - defining IRIs and file name. From there it goes into the editor shown above.

I will work on this further, squat some bugs and introduce more functionality. I have also run into a number of problems relating to the mobile form factor and computing power of mobile devices, but that merits several separate posts.

Some questions that immediately arise from these screenshots are:

  • Mobile devices have limited screen real estate. What is the best way of displaying complex and multi-level hierarchies?
  • How to display non hierarchical relationships?
  • What do editor user interfaces need to look like, when asserting axioms on a class (clearly, the complex UIs offered by Protege are not appropriate) ?

It would be interesting to kick off that discussion and see what the community thinks. Feedback and comments are always welcome.

 

An Ontology Editor for Android - Defining a first set of specs

In my previous post, I have discussed some of the motivation for wanting to write an ontology editor - or at least the beginnings of one - for the Android platform. In this post, I want to discuss how I got started.

Before writing code, I actually sat down and spec'ed out the first bits of functionality that I wanted to get to before releasing some code. A 0.1 version of the ontology editor - working title "ontodroid" - should have the following functionality:

  • ontodroid should be able to create a new ontology from scratch
  • ontodroid should be able to load an existing ontology from a predefined shared location on the android device - for the first version I have decided that that should be the "Downloads" folder. In future iterations, Dropbox and Google Drive functionality should be added.
  • ontodroid should be able to list all non-anonymous classes in the ontology in a list view: no hierarchical representation at this stage
  • ontodroid should display all asserted superclasses and subclasses of a class selected from the class view
  • ontodroid should allow the assertion of new subclass and superclass relationships
  • ontodroid will not deal with ontology imports in this iteration
  • ontodroid will not allow the user to define new relations or relate classes via relations in this iteration

I even did some wireframes using the excellent Balsamiq tool (can be used for free from their website), but I suspect that by the time some of this is implemented, it'll look nothing like the wireframing - so I am not going to even post them here.

Time to get hacking....