An Ontology Editor for Android. 5. Mobile Consideratons - Power

 Source: Wikipedia, Public Domain Licence

Source: Wikipedia, Public Domain Licence

In my previous post I showed the comparative ease with which the execution times of methods can be monitored using the Timer class of the Android logging framework. Apart from monitoring the time, the next obvious question on a mobile device is: how much power does my application/thread/instruction consume on execution? 

Monitoring power consumption is, of course, not only interesting for my little application and ontology loading, but also for on-device data processing and reasoning. Particularly in the context of the internet-of-things, this will be very important: constantly sending data back and forth between a device and a server for data processing and retrieval of processed data will soon explode any network capacity we may have. On-device processing is one way of mitigating against this.

 So I went hunting for some information concerning how power consumption can be monitored on Android devices and was somewhat disappointed with what I found. The bottom line is: there is nothing provided by the Android framework itself. Functionality along the lines of "Settings > ... > Battery Usage" are not programatically available via the official APIs.

There are a number of open-source and academic applications such as PowerTutor, but on the whole these seem to suffer from unreliable support and in many cases haven't been maintained for too long or are device specific.

if your Android device happens to run on a Qualcomm Snapdragon processor, you may be able to use the Trepn power monitoring tool provided by Qualcomm both as a .apk and a plugin to Eclipse. The only Android device I currently have is the 2012 Nexus 7, which runs on an NVIDIA Tegra 3 processor, though the 2013 model does indeed have a Snapdragon.

The most interesting tool I have seen so far - and I haven't had a chance to test it - is a commercial tool by Little Eye Labs, called - surprisingly - "Little Eye". The tools is free to evaluate for 30 days, but after that, will cost 50 USD PER MONTH for a single pro licence making it prohibitively expensive for a hobby programmer.

I haven't found much else - as always I am grateful for any comments and pointers to other solutions.

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.