## Defining a private domain ontology

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");