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:mar...@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 _______________________________________________ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
