It used to be in Tracker that you couldn’t just change the ontology. When you did, you had to reboot the database. This means loosing all the non-embedded data. For example your tags or other such information that’s uniquely stored in Tracker’s RDF store.
This was of course utterly unacceptable and this was among the reasons why we kept 0.8 from being released for so long: we were afraid that we would need to make ontology changes during the 0.8 series.
So during 0.7 I added support for what I call modest ontology changes. This means adding a class, adding a property. But just that. Not changing an existing property. This was sufficient for 0.8 because now we could at least do some changes like adding a property to a class, or adding a new class. You know, making implementing the standard feature requests possible.
Last two weeks I worked on supporting more intrusive ontology changes. The branch that I’m working on currently supports changing tracker:notify for the signals on changes feature, tracker:writeback for the writeback features and tracker:indexed which controls the indexes in the SQLite tables.
But also certain range changes are supported. For example integer to string, double and boolean. String to integer, double and boolean. Double to integer, string and boolean. Range changes will sometimes of course mean data loss.
Plenty of code was also added to detect an unsupported ontology change and to ensure that we just abort the process and don’t do any changes in that case.
It’s all quite complex so it might take a while before the other team members have tested and reviewed all this. It should probably take even longer before it hits the stable 0.8 branch.
We wont yet open the doors to custom ontologies. Several reasons:
- We want more testing on the support for ontology changes. We know that once we open the doors to custom ontologies that we’ll see usage of this rather sooner than later.
- We don’t yet support removing properties and classes. This would be easy (drop the table and columns away and log the event in the journal) but it’s not yet supported. Mostly because we don’t need it ourselves (which is a good reason).
- We don’t want you to meddle with the standard ontologies (we’ll do that, don’t worry). So we need a bit of ontology management code to also look in other directories, etc.
- The error handling of unsupported ontology changes shouldn’t abort like mentioned above. Another piece of software shouldn’t make Tracker unusable just because they install junk ontologies.
- We actually want to start using OSCAF‘s ontology format. Perhaps it’s better that we wait for this instead of later asking everybody to convert their custom ontologies?
- We’re a bunch of pussies who are afraid of the can of worms that you guys’ custom ontologies will open.
But yes, you could say that the basics are being put in place as we speak.
I think it would also make sense as the next step to start supporting out-of-ontology triplets and allow introduction of suitable ontology that describes those previously out-of-ontology triplets (or quads), to be digested into the the optimized data structures.
@Urho: I kinda like the strict aspect of our current RDF store. It means that all data in it is well structured and well described. This allows for more cooperation between applications that use the data. Rather than each application just dumping its information in it, like how they dump information on a filesystem (which also doesn’t necessarily create a meaningful way for applications to work together on metadata).
I think allowing custom ontologies is therefor a step that we should take first (rather than having a generic triplet store). We also can’t optimize a generic triplet store very much (it ends up being stored in huge tables of generic triplets). Unless you have fully dynamic table creation in case a predicate appears, or something. Sounds complicated …
Dno. Maybe.