In order to make Tracker aware of this private setup, a domain ontology rule must be dropped by the application on $(datadir)/tracker/domain-ontologies/, the file name will be usually the DBus name or application ID of the client prepended by ".rule", eg. org.example.App.rule

The following example would allow org.example.App to set up a private set of services to index the filesystem.

[DomainOntology]
# All locations accept
# 1) Paths relative from a variable, the variables
#    may be: HOME, XDG_CACHE_HOME, XDG_DATA_HOME, XDG_RUNTIME_DIR,
#    XDG_DESKTOP_DIR, XDG_DOCUMENTS_DIR, XDG_DOWNLOAD_DIR,
#    XDG_MUSIC_DIR, XDG_PICTURES_DIR, XDG_PUBLICSHARE_DIR,
#    XDG_VIDEOS_DIR.
#
#    eg. $XDG_CACHE_HOME/...
#
# 2) URIs
#
#    eg. file:///var/...
#

# Location for the Tracker database (not optional)
CacheLocation=$XDG_CACHE_HOME/example-app

# Location for the data journal, used in data recovery
# situations (optional)
JournalLocation=$XDG_DATA_HOME/example-app/journal

# Name of the ontology to use, must be one located in
# $(sharedir)/tracker/ontologies
OntologyName=nepomuk

# DBus name for the owner (not optional). Tracker will use
# the domain as the prefix of the DBus name for all the
# services related to this domain ontology.
#
# eg. org.gnome.Photos
Domain=org.example.App

# Miners that the domain ontology will require. This is
# purely a hint (mainly for libtracker-control), and not
# any sort of white list. Anything else knowing about this
# domain ontology may still perform updates, miners and
# non-miners.
Miners=Miner.Files;Miner.Extract;
    

The client could then instruct Tracker libraries to use this private set up through the following call:

tracker_sparql_connection_set_domain ("org.example.App");