Hello guys,
Briefly what there is so far. Note that all filenames, directory names,
GKeyFile key-names and command-line argument names and even concepts are
open for debate and change.
You can with the stuff in domain-ontologies do the following:
Create a file like this:
# cat /opt/tracker/share/tracker/domain-ontologies/tracker.rule
[DomainOntology]
Domain=org.freedesktop.Tracker1
CacheLocation=tracker
DBusPath=/org/freedesktop/Tracker1
# OntologyName=kumopen
#
You can also add the key OntologyName, but currently Tracker's own
ontology isn't in a directory location that this domain-ontologies can
already support. So this tracker.rule couldn't replace the defaults of
Tracker, yet (maybe this should be possible with the keyfile's config?).
If OntologyName is filled in, then the directory where the ontology will
be is SHAREDIR/$CacheLocation/ontologies/$OntologyName. I think, that
$CachLocation should for example be replaced with $Domain, and/or
CacheLocation as key should get a different name (it's also used to
define where meta.db will be, which is ~/.cache/$CacheLocation/meta.db).
so, all this is open for debate and necessary bike shedding.
Per Domain you can run a tracker-store instance. It corresponds to the
Name of a DBus service (to be configured in a .service file). So people
who create such domains should also create a DBus .service file, to make
their domain's tracker-store DBus activatable (calling a method on the
service = launch a tracker-store with the right parameters).
When you start tracker-store with the parameter --domain-ontology=name
then it tries to load tracker/domain-ontologies/$name.rule. So that
DBus .service file should add that --domain-ontology parameter to the
command line of the DBus service to let the domain get a store instance.
You can also override each setting individually with cmd-line args:
--domain=org.my-own.domain
--dbus-path=/org/my-own/domain-dbus-path
--cache-location=my-own
--ontology-name=org.my-own.domain
All this obviously needs fine-tuning, bike-shedding over key names,
parameters and command line parameter names, concepts and how to
integrate with DBus .service files. There should probably also be a
--list-ontology-domains, I guess? Yes, sure.
Ideas? Patches (feel free to join the feature-branch)?
ps. In future the idea would be that once libtracker-sparql is adapted
to support these in a new constructor of SparqlConnection, and that
tracker-store and libtracker-sparql get shipped together.
After that we can create a domain-ontology package for Tracker's
Nepomuk. And after that we make miner-fs dependent on libtracker-sparql
(which will then include tracker-store) and on the Tracker's Nepomuk
domain-ontology.
So, miner-fs would become just another user of libtracker-sparql using a
specific domain-ontology (that happens to look a lot like Tracker's
current Nepomuk based ontology).
And other applications can create their own domain-ontologies, package
them and share them with yet other applications. Kowabunga.
And I guess flatpak can specify which flatpak has rights to which
domain-ontology, so that the libtracker-sparql clients running in that
flatpak can access the right files and directories and DBus paths and
services that they need, to query a specific domain-ontology.
That way privacy over your metadata (a set of metadata or a domain) can
or could be enforced based on flatpak rules. Which I guess is the point
of all this.
ps. Other ideas: support that a tracker-store process can support
multiple ontologies and multiple domains? Sounds like overkill to
support but might be nice (in terms of correctness of the code) to make
this possible someday. Right now there are a few global variables and
singleton-like concepts, in tracker-store, that don't make this
possible. They shouldn't be there in my opinion (= that's just quick and
dirty code, not a good design or a indented concept in tracker-store's
code - so you can and should just fix this if you feel like doing so).
Kind regards,
Philip
On Thu, 2017-01-26 at 22:44 +0100, Philip Van Hoof wrote:
Hello guys, I just pushed a feature branch called domain-ontologies. It's a first attempt at providing the infrastructure for making it possible to have domain specific ontologies. First part is adapting the tracker_data_manager_init to have parameters domain and ontology_name. The idea would be that tracker-store gets told (via argv?) what domain and ontology_name to load. The meta.db would of course also be unique per domain (+ ontology_name). So the tracker_db_manager_init must be similarly adapted (not done yet). After that it should be possible to have a tracker-store per domain and per ontology, or just per domain. Etc. So that means adapting the D-Bus part (have a instance of the service per domain(+ontology_name), or make it possible for one tracker-store process to service multiple domains). Right now tracker-store can only run once. That will have to be adapted too. Noting that the default (NULL, NULL as parameter values) should do exactly the same as what current tracker-store does. Feel free to join, as I can't work on this very often. Kind regards, Philip _______________________________________________ tracker-list mailing list tracker-list gnome org https://mail.gnome.org/mailman/listinfo/tracker-list
Attachment:
signature.asc
Description: This is a digitally signed message part