Technical Ramblings

Geolocation is the technique of determining a user’s geographic latitude, longitude and, by inference, city, region and nation. There are a number of ways to do this: one of the common ones discussed on the internet (according to a Google search for “geolocation”, as we all know Google is the Answer) is geolocation via IP address. The kind I’m interested in is much more accurate: geolocation via GPS device.

I want to be able to know where I am. I want this for a lot of reasons, most of them geeky rather than actually reasonable. However, it would be nice to offer more specific statistics on where my pictures are actually taken with fine grain granularity that a GPS can offer. Additionally, some of my alternative projects – cell based geolocation and the like – could benefit from actual coordinates on which to base everything from restaurant locations to searches. Openguides is, in particular, one area that could benefit from this.

I want something that works over bluetooth. My laptop and phone both speak bluetooth, and something with an actual display is out of my price range, for the most part, so I want something I can use my phone to get data out of. (USB / serial obviously doesn’t work for that.) From what I understand, most GPS devices which support NMEA are going to work okay for communication, as there are tools out there which support them. (Whether I can get the thing to talk over bluetooth is a different concern, but one I’m becoming more proficient at every day.)

For a long time, all I could find for Bluetooth GPS devices were 200-250 USD and up. However, while discussing it with someone in #mobitopia on Freenode, I found the Delorme Bluelogger, a Bluetooth GPS device for $150. Matt already posted about our discussion, but I hadn’t yet.

I have some cash left over from Christmas, and I know that I almost never actually buy anything for myself. So, I’m going to splurge, and I’m going to get it. I’m going to learn to use it, and I’m going to do all kinds of neat things with it. Plans include:

• GPS Annotation of Photos – This rolls into my photo annotation project, and is part of the reason I was keen to get it done: I want to actual have some fun queries for normal people (rather than just RDQL-aware people) over my photos.
• Location Based Description of things for Openguides – Describing where things are with GPS coordinates allows searches by distance. Once I have that, the guide allows more niftyness.
• Association of Cell IDs to Geo locations – Tied to the previous, this allows me to know where I am based on a Cell ID: Useful for “what’s nearby”, as well as useful for the general “where are you” that I like to be able to do – with just my cell phone.

All in all, some of the apps I have in mind seem nifty, some geeky, some just demonstrative of something bigger. Some are RDF related, some are just fun. The Bluelogger seems like a decent tool to achieve everything I need to.

Over the weekend, I had some fly time to work on my image annotation application. I had asked for a bit of help on the way to get input in Python, and sbp pointed me towards “raw_input()”, which is what my application is based around.

Originally, it was going to be written using the Redland python bindings. I had prepared myself for the flight by installing Redland, and browsing a bunch of pages with annotation examples, which Slogger grabbed for me and stuck into a local log. With this, I thought I was prepared. So, I got on the plane, got past 10,000 feet, opened the laptop, executed my program (I already had about 20 lines of code)… and smacked myself in the head as it complained that there was no module RDF.

You see, Redland has two parts: the library itself and the language bindings. You kinda need both for working in Python.

So, after a little bit of thinking, I remembered that I had installed rdflib for testing of n3p, and decided that I would convert my existing code to that. In about 15 mintues, I was back up and running.

The program is simple, although it’s still lacking some important functionality. It basically just asks a series of questions about the image you tell it to annotate. Sample program input is available, as well as the sample output, and the sample passed through cwm to demonstrate how it looks when cleaned up.

You’ll notice that there’s data there that I didn’t enter: that data is brought in from a FOAF file. This file is only specified in the code at the moment. The code intelligently works on the name you give and checks for either a nickname or name matching: if there are multiples, it provides you a list from which you can choose a number given. In any entry form, you can just skip enter to either accept the default or skip past it.

The source is available, as depiction.py. This source code is messy, the way it’s laid out is very procedural, and you’ll have to modify things inside the code in order to get it to work for you. (Specifically, the foaf.rdf file is hardcoded to the location of mine.) The wordnet features are the newest and the least complete. I’m going to continue working on it, and the application is not considered even alpha-level release yet. However, I know that other people are interested in the arena, so feel free to take the code. You will need RDFLib to run it. It is MIT licensed. Share and enjoy!

Today, Nokia released Python for Series 60 based phones. I’d been hearing about this stuff for months, but it had been in closed beta, so I hadn’t paid much attention to it. In addition, when this stuff was being discussed originally, back in April, I’d never had a hand in any Python coding: I was a Perl and PHP hacker only.

However, when mattb asked today who would be the first to write an RDF parser that would run on the phone, I asked what he was talking about, and received a pointer to Nokia’s announcement. I immediately started playing. (A bad thing, given that I had work today.)

So, in 5-10 minute increments, plus hacking after the kids went to bed, some help from sbp in the form of an ntriples parser written in Python, some help from Dave Beckett and Redland in the form of an easy RDF/XML->ntriples conversion, I now have a working (although clunky) FOAF application for the Series 60 phone running Python.

So, without further ado, I explain to you the steps behind the process:

First, the user runs Python. This is installed the way any other application is. Once Python is installed, the user must send two files to their phone: an ntriples parser and the actual FOAF Service script. The ntriples script is installed as a “library”: this means that it is installed on the include path, so that it can be imported as a module. The FOAF script is installed as a script.

The user opens Python, and chooses to run a script. They choose the script that they installed, and run it. A standard query box opens, and asks the user for a URL. Here, they enter the URL of a FOAF file. Once they do, the file is passed through an rdf/xml->ntriples web service: this converts most FOAF files to a format the phone can understand. An example URL for this webservice is http://crschmidt.net/semweb/xml2nt.cgi?uri=http://crschmidt.net/foaf.rdf : It is created using Redland, and source is available at http://crschmidt.net/semweb/xml2nt.cgis . It uses the Redland Python bindings. You can feel free to use this web service: however, if you’re going to be exceeding 10 hits/minute, please let me know so I can find someplace better to host it.

Much of the time for the script to run is simply fetching this content: my FOAF file generates 70k of ntriples, which is then parsed into a simple list of triples. Some post processing sorts the data, and looks for a personal profile document to whom the document can be attributed. If it is found, then the script prints out a list of contact information for that person, including email and contact IDs.

Many thanks to mattb for pointing out the Python release, sbp for his invaluable ntriples parser and his help getting it working, and to other people who muttered encouragement throughout the day.

The source is available at my Symbian Semantic Web Page. More images are available in my Symbian Hacking gallery.

Chris: 2, Redland: 0

For quite a while, I’ve been having some problems with installing the latest version of the Redland RDF Application Framework. I’m sure that these were problems of my own: I know that my system is a little goofy, in part because I’ve got a combination of ebuild-built and non-ebuild versions of things. So, for a while, I’ve been unable to compile the lateset Redland, because whenever I’d try and compile, the system-wide redland-config would get in the way, and then Redland would try to link against the already installed libraries, etc. etc.

However, yesterday I started having issues with julie crashing, returning a glibc exception. I wrote a small test script, and found that the issue was occuring any time I was using two “AND” clauses in an RDQL query. I recompiled glibc with debug info this morning, and was amazed to find that my backtraces suddenly became much more informative: Instead of gdb returning ?? in ?? in my backtrace, it actually gave me function names and line numbers. I didn’t think that just recompiling glibc would have helped so much.

After I was able to do this, I sent mail to the Redland-dev list: Here’s my problem, here’s my backtrace, where do I go from here? That Email got several responses back and forth from Dave Beckett (maintainer of Redland) and Morten Fredrickson (maintainer of the MySQL storage backend). I ended up stopping all services which used Redland, uninstalling redland completely, and making the latest release successfully. In combination with discussion on IRC, I moved onto testing with valgrind, an open-source memory debugger for x86-GNU/Linux and ppc-GNU/Linux. Sending the data dump from that helped Dave to find the problem, which was related to the way that the mysql backend frees results.

One patch later, the problem was cleared up. There’s still the question of why it broke, which seems to be related to some broken statements in my database. However, it’s good to know that I helped to find a bug in Redland, rather than just finding something broken locally.

In the end, I did learn a few things:

1. Having glibc debug symbols on is a Good Thing.
2. If you can’t install the latest version, try uninstalling the previous version first.
3. valgrind is an app which may help you locate the source of bad free() calls
4. glibc has some extra sanity check memory detection: you can adjust its behavior via MALLOC_CHECK_. Levels of sanity are 0->3, with 0 being “display error message and kill application” and 3 being “do nothing”. (I found this via fedora core release notes.)

I also was able to compile new Redland bindings: this means that I fixed my Perl Query problem (which has been fixed for a while, but I couldn’t install new bindings), as well as adding Sparql support to my local Redland tools. Now, I just need to write something that uses it.

So, in the end, I helped squish a bug, and upgraded all my Redland related stuff on my system. That’s what I call a good day.

I have about 1500 images that I’ve taken over the last 1.5 years since I got a digital camera. These photos vary wildly in what they contain, from parties with friends to buildings to family photos to stuff around the house. There is a variety of images depicting people from all walks of life, from my college friends to my family now.

I want to search them.

I’ve become very convinced that the best way to store the information about these photos is in RDF: It’s the only data description framework that lets me extend and expand my descriptions to include everything I need. (There’s also the fact that I’m an RDF nut, so everything is a case for RDF.) Once the data is created, adding it to an RDF store and asking that store questions will not be difficult; the main problem is to get the data created.

There are some web based tools for photo/image annotation: mortenf uses a tool he created which spits out ntriples, and there is also the java app attached to the foaf codepiction project. However, neither one of these lets me describe my images very easily; There’s a lot of effort to go through for it.

My ideal photo annotation tool works like this:

• Provide a URL to a photo.
• This photo may or may not have EXIF data included. If it does, use the exif data to generate the appropriate RDF; something along the lines of the EXIF metadata created by Mashide’s exif2rdf web app would be good.
• Allow me to describe the image with a title and description: dc:title and dc:description.
• Allow me to describe the person who took the photo: foaf:maker. This part can work from the existing triple store I have; Let me enter a name, and then use that name, along with an mbox_sha1sum, to describe the person.
• Offer me a license list: a list of CC licenses to choose from.
• Allow me to describe “things” that are included in the photo: entering a term and checking it against wordnet, then using the right sense of the word.
• Allow me to describe “people” in the photo: enter a name or nickname, and then present me a list of options from my triple store, or the option to describe a new person. Once I choose a person, a name + IFP should be included in the output so that I can smush the data together.

I’d like for the entire interface to be text based. I don’t want a web or graphical app: with 1500 photos, that’s just too damn much. I want to be able to describe these things quickly and easily, so very little should get in the way, with as few keystrokes as possible. If I want to skip something, I can just hit enter to skip over it.

I’m lucky in some respects, because some of the hard work of gathering information about people is already done for me: I have a large triple store at hand that can help me with this project. I also have some limited experience in working with the Redland framework, so I may even have the experience I need to make this work. So, here’s how I see it working on the inside:

Create an interface along the lines of what Config::Tiny (in perl) does: Question [default] ? then allow for the user to either skip past (and use the default, which may be none in some cases) or to use their option: if their option, possibly provide a list of choices after that. For example, if I enter “Jessica” as a name, it should tell me “There is no name Jessica in the database: would you like to create a new user?” with a yes or no option; if no, it would go back to the previous step and let me enter a different name. Dump the data, as its created, to an in-memory Redland model. Once the photo description is complete, serialize the model to a file, which can then be run through cwm to clean it up for more permanant storage.

I’m probably going to actually get off my butt and write this pretty soon: I have a lot of interest in describing this data, in part because it’s another case where a nifty project can lead to a great demonstration of why and how RDF can work. I’m most interested in someone who may have suggestions on what kind of tools would be good for creating the interface: the last time I did any kind of user input other than command line was when I was working with cin>> statements in C++. I’m probably going to write it in Python (I feel that I really accomplish things much more quickly writing in that language than in either perl or PHP), so tips on how to create command line user interfaces in Python are appreciated.