This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex] 

1. Predefined content registration

In some circunstances the applications need some predefined content in the DB. With content we refer to instances and not new classes/properties. This document describe how and when the applications can add that content into tracker. Ontology changes from applications will be explained in a different document [FIXME add link when ready]

1.1. At package installation time (Import tool)

Tracker provides a tool called tracker-import that receives a file as parameter. That file should be a valid turtle file (not sparQL) with instances. The tool will send it to tracker as a big INSERT operation.

This tool can be used in the post-install of an application package (don't forget to make it depend on tracker package), or at any time from the command line. After that the tracker journaling and backup will take care of those instances (unless something goes really really wrong with the DB and journal).

1.2. Before tracker's DB creation (Installing .ttl files)

This is a way to install information just before the first boot. At booting time, if tracker needs to recreate the DBs (first boot or fallout), it will check for files under  $PREFIX/share/tracker/ontologies  and will use them to create the DB schema. Those files can contain also predefined instances, so an application can put there its own .ontology file. That file must be also a valid turtle file.

1.3. Direct DBus interface

Of course the application can set its instances in the DB at any time using the usual DBus interface and SparQL.

1.4. How to choose one mechanism or another (Considerations)

  1. Installing .ttl files will work only if the applications and its files are installed before the first tracker boot. This is probably only useful in pre-build environments like MeeGo.

  2. Import tool is useful for information known at installation time, for packages that are installed when tracker is already running. In case of a dramatical failure of the DB, those instances won't be present anymore, so the application should take care of that (rare but possible) recovery.
  3. Both previous solutions (1 and 2) can be combined: a package can install the .ttl file and use the import tool to push the info into tracker.
  4. The DBus interface is fine for application specific bits (there shouldn't be much in the ontology, anyway)
2024-10-23 10:59