After the many discussions the Tracker team did at the Desktop Summit in Gran Canaria I think a lot of people will start trying out Tracker’s master. We will indeed start making 0.7.x releases somewhere this or next month.
Meanwhile I’d like to point out that among the decisions that we made during the meetings and at the Ontology BOFs is that we wont use the URL of resources as the RDF’s subject field anymore. Instead we’ll use the nie:isStoredAs predicate for storing the URL.
Right now we already set nie:isStoredAs, but we still use the URL as subject. This will change, though. Just assume the subject to be something you should only use as an unique piece of data about the resource, pointing at it (in the RDF store). More details can be found here. If you want the thing itself (the file, the E-mail, the .desktop file, the website’s URL), ask for nie:isStoredAs.
For example:
<file:///tmp/myfile.png> a nfo:FileDataObject . <urn:nepomuk:file:d7ea...> a nfo:Image ; nie:isStoredAs <file:///tmp/myfile.png> .
And to query:
tracker-sparql -q "SELECT ?url WHERE { ?subject a nfo:Image ; nie:isStoredAs ?url }
We know that many people want these 0.7.x releases to happen soon. I can only invite those people to just join coding. Awesome stuff is indeed taking place, but at the same time there is a lot of work and decision making to do.
Things like a user interface like the T-S-T (Tracker Search Tool) from Tracker 0.6, documentation with a lot of examples. SPARQL, SPARQL Update and Nepomuk all have quite a lot of documentation by themselves. But people are still asking for even more examples. Anybody interested in making that? Maybe if somebody who was at Rob Taylor’s BOF could write down his and Jürg’s lectures on RDF and SPARQL? I think they explained it all very well.
Really, just copy the search entries from firefox / OS X. There really isn’t a need for a seperate search GUI application.
Tracker search tool might look nice. But it’s an application…. and searching shouldn’t be a seperate application. Just a simple clean live-updating searchentry-applet ;)
Deskbar is the best possible out there… but it’s a bit big/slow (login) and a bit bloated with python for a single entry and backend (tracker).
@anon: I don’t disagree. But people want to write this app anyway. Perhaps we’ll split it out of the Tracker project and make it a new mini project. Maybe it’ll be optionally part of Tracker’s compilation (just like the tracker-explorer tool made by Rob Taylor two weeks ago).
Doesn’t really matter that much, as long as it’s optional. Right? (Packagers can still separately package it, which is probably what they should do too).
I just wanted to point out again (I think I mentioned that at the GCDS, too) that in Nepomuk-KDE we will be using the file URL only as the object to nfo:fileUrl and not as the subject. And even there it will be relative. The reason is that otherwise moving files would mean to update all triples relating to this file.
Also, and even more important, it means that we can handle removable and fixed media the same way. If a removable media is unmounted the absolute URl is not correct anymore. Thus, we store it relative to the mount point. If then the media is mounted again (even at a different location) we can simply adjust the data by only changing one triple.
@Sebastian: nfo:fileUrl doesn’t work for non-file resources. Which is why we also use nie:isStoredAs. Let me know if you think that’s a bad idea for some reason (nie:isStoredAs requires a nie:DataObject, but so far that has been fine for us).
@pvanhoof: Well, using the file URL as resource URI is nicer and maybe even cleaner but I think using only nfo:fileUrl makes things much easier.
Keep in mind that I was only referring to files. The scheme I described does not make sense for any other type of resource like emails or web pages or the like.
I see files as a special case that we need to handle differently (sadly).
nie:isStoredAs is a bit independent from the other issue. NIE uses it to state the difference between DataObject and InformationElement, i.e. storage and content. So for me using nie:isStoredAs does not really solve the problem.