Experiments in GNOMEland

Except if you squash them¹

I’ve been slowly but steadily making progress on Hormiga, the Tracker based ORM. I wish I had more time to dedicate to this project, but my work on Tracker and Buxus, the company I’m founding with a Chilean friend, have been keeping my rather busy.

Still, I finally reached a point where I can generate a mapping file, run hormiga on it, and get a vala proxy which I can use to access data in Tracker. Here is a quick demo of how it works:

Writing a mapping file

Mapping files are JSON documents. That means they’re easy to write, and they could even be generated by a graphical frontend in the future (or automatically from ontology files, whatever). Here’s a simple mapping file for the nao:Tag class:

{
	"Class": "nao:Tag",
	"Name": "Tag",

	"Properties": [
		{
			"Property": "nao:prefLabel",
			"Name": "label"
		}
	]
}

Here we say we want to generate a proxy to access objects of class nao:Tag, and we want to bind the property nao:prefLabel (the label of the tag) as the “label” property of our proxy. The data type (here, a string) will be automatically deduced from the ontology.

Generating the proxy

Generating the proxy should ideally be part of your build process, and is not more complex than running

hormiga -O /usr/share/tracker/ontologies Tag.map

This command generates a Tag.vala file, which you can compile with the rest of your project. The -O is used to tell Hormiga were ontology files are.

Using the generated proxy

If you look at the generated code, you’ll notice the constructor is private. Instead, you have to load the proxy using one of the dedicated functions. Well, so far, there’s only one, to load a proxy for an existing resource. This is the first point I’ll improve next week. So, say you have a tag in Tracker with an uri urn:my-tag. You can use a code like

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public class HormigaTest {
	public HormigaTest () {
	}
 
	public void run () {
		try {
			var tag = Tag.load ("<urn:my-tag>");
 
			if (!tag.exists) {
				warning ("Resource %s does not exist", tag.urn);
			}
 
			message ("label: %s", tag.label);
		} catch (Error e) {
			warning ("Couldn't load tag: %s", e.message);
		}
	}
}
 
public static int main (string[] args) {
	var t = new HormigaTest ();
	t.run ();
 
	return 0;
}

Where are we now, and where we’re going

This small demo shows around 100% of the current features implemented in Hormiga. You could say it’s useless, and you wouldn’t be totally wrong :). The interesting part is what comes now that I have my architecture set up.

Next week, I’ll work on loading functions: you’ll probably want to load all tags, or only those matching a certain property. I also intend to let developers use SPARQL to load objects, I don’t think abstracting all SPARQL under an API is a good idea.

I also have to work on data type mapping: currently, Hormiga deals with string, integers and dates. It does not handle yet “pointers” to other objects (basically, all predicates pointing to a resource), which is a rather serious limitation. But again, one piece at a time… I don’t want to rush now, and have to do a rewrite in three months because I did a bad design!

I’ll of course appreciate any type of contribution (feedback, patches), but I’m aware that at this stage the project is not very attractive :). Still, if you feel motivated, just go for it!

¹No animals were hurt during the redaction of this blog article. And the title is because “hormiga” means “ant” in Spanish.