GNOME.org
 

Re: [Tracker] Procedure to change Tracker Ontologies in Running System

Hi Martyn and Philip,

Thank you for responding so quickly to my questions.

Right now Iâm just trying to figure out Tracker's capabilities for a customer, and I think this is mostly a 
theoretical "what is Tracker capable of?" and "what if we need to change something?" questions from them.

[More responses inline below]

From: Martyn Russell [mailto:martyn lanedo com] 
Sent: Friday, August 13, 2010 1:38 AM


On Fri, 2010-08-13 at 09:44 +0200, Philip Van Hoof wrote:

On Thu, 2010-08-12 at 14:56 -0700, Compton, Matthew wrote:

Hello,


Hi,


I'm wondering if it is possible to change the Tracker ontology in
running system that already contains data.  I think the only needed
changes are to add classes or properties to classes.  Also, I'm hoping
to avoid having to re-index everything that is already stored in
Tracker.

From the page
http://live.gnome.org/Tracker/Documentation/SupportedOntologyChanges it
looks like it is possible to update the ontology on a running system,
but I don't see anywhere (in code documentation or the online
documentation) if there is a specific procedure for doing this.


OK, first a few VERY important things about changing the ontology:

o. We DON'T support it for packages, software and people who aren't
   Tracker. This means that only the Tracker team can do a good official
   ontology change. An application CAN NOT do it, IS NOT allowed to do
   it, MUST NOT do it (or face serious incompatibility with upstream).
o. It's limited in capability, and its error reporting is vague, buggy
   and even more limited in accurateness.
o. When done wrong, you'll loose data (possibly all your data) plus the
   capability to make a backup and restore. Plus the capability to
   replay your journal: the data is permanently gone then. Not possible
   to recover it, unless you use a hexeditor over hundreds of megabytes.


I think what's important to take away from this is, we try to keep
things that are useful upstream, you can of course have your own
ontology for your specific environment, but we don't recommend it unless
your use case is quite specific.

Philip presents a "world will end" scenario here, but the point is
mainly to avoid people complaining about data loss when they are messing
around with the ontology.


Thank you for the warnings. I understand that this is not a common request or use case and this code path has 
had limited testing.  I'll definitely explain this to our customer.


OK, that's for the warning. Which boils down to: don't do this, etc etc.


From the code it looks you can:
1. Shutdown Tracker
2. Update the ontology files
3. Restart tracker and I think it will update the database to match


That #3 only happens for supported ontology changes, when done right.


I'm going to test this today but I thought I'd ask the experts if there
are any things to watch out for and if there is an official procedure
for doing this.


The official procedure is to change the nao:lastModified at the top of
every .ontology file, add the classes and properties (in order, a class
that is the domain of a property, must go above the property, etc), save
the file, restart tracker-store.


Just to add to what Philip said here, the nao:lastModified is for the
specific ontology file itself, not ALL ontology files need updating.


Thank you for providing and explaining the steps if we do end up needing to modify the ontologies ourselves.


Creating a new file should work, but this has not been thoroughly
tested, and you need to add a correct namespace and prefix part at the
top of the file (copypaste and change from existing .ontology files).


Creating a new file is probably the best solution here if you are adding
ontologies and not just correcting existing ones. We do this with
Zeitgeist in a branch right now.


Again, I can't stress this enough: this can only be useful to you for
either testing purposes or for private use (you maintain your own
ontology completely separate from upstream Tracker). Not for official
use. NO future version of Tracker will support YOUR ontology changes.
Only OUR OWN ontology changes will be supported (in forward direction,
not backwards compatibility). ANY change that YOU make WILL conflict
with our changes.


Matthew, are you able to share your considered changes in the event that
they might be useful to a wider audience (i.e. upstream) ?

Additionally, we may be able to sanity check it for you.


I agree that it would be best that any changes we need to be made be maintained in the upstream version of 
Tracker, but I'll need to get the buy-in from the customer before discussing specifics with you.  Thank you 
for the sanity check offer as well, since you guys know Tracker best and have much more experience dealing 
with ontology design, I'm sure you will be a great resource.




What you should do to make an ontology change, instead, is to make a
patch and send it to this mailing list for review.


Right ;)


Thanks for the help,


NP (but notice the warnings)


Philip, if this isn't on the WIKI already, (which I suspect it isn't due
to the query here) can you update the documentation page so it is clear
there too please?


I agree it would be great if this information was in the online documentation or in documentation that comes 
with the source code.  That way you won't have to write so many "world will end" emails. ;-)



-- 
Regards,
Martyn


Thanks,
Matt
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]