Tracker based ORM

This Summer of Code proposal is about building an ORM using Tracker as a backend. Tracker (for versions 0.7 and above) is an RDF database, with which you can interact using the SPARQL query language. Dealing directly with SPARQL can sometimes be tedious, this project aims at building a higher level layer above RDF, where the developer can deal with native objects and get them reflected in Tracker's database.

The ORM will read a list of mapping files, and produce source code for a target language (currently Vala, but the design will be modular enough to allow plugging other output languages). The generated classes will be proxies to RDF classes in Tracker.

See also

Proposed name

I'm going to name that ORM "hormiga". It means "ant" in Spanish. An ant is lightweight, and works hard. I'd like to have both those qualities for the ORM :)

Give me the code!

All the code and documentation is hosted on my git forge.


This is a preliminary documentation. There are no API/ABI stability guarantee yet, nor there is a guarantee that this documentation is up to date (you've been warned :-p )


Hormiga is composed of several parts:

  • the hormiga binary, used to generate the proxies

  • the libhormiga library, used at runtime by the programs using Hormiga. It contains various bits of code used by all proxies generated by Hormiga, therefore having it as a shared lib reduces the overall memory usage.

When shipping code that uses Hormiga, you can ship the generated proxies so that users who want to compile the code don't need to install Hormiga. However, the libhormiga lib will always be needed at runtime.


Various steps are required when using Hormiga:

  1. Write the mapping files
  2. Run hormiga on those mapping files to generate the proxies

  3. Use the proxies in your application

Those various steps are explained below

Writing mapping files

Mapping files are used to tell Hormiga what classes you want to generate proxies for, and what predicates you want to use. There is one mapping class per file you want to map, and you can pass several mapping files to hormiga at the same time.

Mapping files must have the extension .map. They are JSON files. The example below shows the various fields that can exist in a mapping file:

        "Class": "nmm:Photo", ①
        "Name": "Photo", ②

        "Properties": [ ③
                        "Property": "dc:title", ④
                        "Name": "title", ⑤
                        "GenerateLoader": true ⑦
                        "Property": "nao:hasTag",
                        "Range": "nao:Tag", ⑥
                        "Name": "tags"

The Class attribute holds the name of the RDF class you want to map.

This field is mandatory.

The Name attribute holds the name of the class you want to generate in the target language.

This field is mandatory.

The Properties array holds the list of the predicates you want to bind.

This field is mandatory.

The Property attribute of a property object holds the name of an RDF predicate you want to bind. The corresponding data type in the generated proxy will be automatically detected.

This field is mandatory.

The Name attribute of a property holds the name you want to give to the property generated in the target language.

This field is mandatory.

The Range attribute can be used to override the range of a property (originally defined in the ontology).

This field is facultative.

The GenerateLoader attribute tells if the code generator should create a load_from_foo function, where foo is the name of the property. In this example, the generated function in Vala would be public static Gee.List<Photo> load_from_title (string value, int limit = -1, int offset = -1) throws Error.

This field is facultative.

Generating the proxies

When all your mapping files are written, run hormiga on these to generate proxies. Currently, the only supported target language is Vala.

If using the mappinf file above, you would also need a mapping file for the nao:Tag class. In that case, you would run

hormiga -O /path/to/dir/with/ontologies

The ontology directory is generally the one used by Tracker, which is ${prefix}/share/tracker/ontologies. The command above would generate two files, Photo.vala and Tag.vala.

Using the proxies

How to use the proxies differ depending on the target language. The complete source of the example above is available at . It is probably the best way to have a clear understanding of how to work using Hormiga.

Bugs, suggestions etc.

There is an issue tracker on the forge, which you can use. I also generally hang on IRC, on #vala and #tracker as abustany. Any feedback will be appreciated!

Outreach/SummerOfCode/2010/AdrienBustany_Tracker (last edited 2013-12-03 18:33:12 by WilliamJonMcCann)