As many people already voiced here don’t I think you should go for ‘multiple backends’: it would require some sort of abstract layer for the query language, or implementing a SPARQL -> to -> storage’s native query language – function.

I think that for metadata SPARQL is ~ the language that we, desktop and mobile developers, should standardize on. So just do SPARQL UPDATE to insert your data into the store, use SPARQL to query it, and write custom ontologies if necessary. All tree are supported by Tracker’s master, by the way.

About events – what you are describing is really a version controlled triple store. Store all objects with full history and the event log will be completely redundant. As it stands I am not sure that this is feasible and/or a good idea.

You may have events that are far less tangible than files and emails etc. Consider mouse gesutures, system notifications, unlocking the screen after screen lock, approaching the computer with your bluetooth enabled device, etc.

As to where to store all the data, I’d say everything is an event. If I write a file, that is an event, so the file contents should go into the event log. When I receive an email, that’s an event, the content of the mail should be in the same storage that records the event.

Any new event stored should trigger the appropriate analysis calls. These can be map/reduce functions, SPARQL queries and metadata extractors. The results of these all wander in temporary indexes/caches/views that provide the user interface with nice views on the data.

With that approach I’d see Zeitgeist kind of as an “extension” to Tracker, where it’s functions would be on one side, the logging of events, and on the other providing a high-level D-Bus API to easily access events and to get relationships between them (Seif’s magic); this way we get to keep a very simple to use API but applications needing more advanced stuff (or maybe requiring more fine-grained control on what to fetch for performance reasons) have the chance to query Tracker directly. What are your thoughts on this?

Ofcourse if we go to the abstraction level of RDF graphs they are alike, but in a more structured datamodel they are very different.

Zeitgeist Items has metadata such as content type, mimetype, source type (where they are from fx. filesystem, web page, email account, …), URL.

Events have such metadata as timestamp, the app emitting the event, what type of event (user action, system notification), what happended (created, modified, deleted, etc.), and some more.

Annotations are really identical to Items just with the extra property that they have a set of subjects.

It is not impossible that we settle on one backend only. My brain storming is specifically to figure out if there exist a common abstraction that is powerful enough. If there ain’t then we’ll most likely marry ourselves to what ever fits best.

We will also use Nepomuk for describing the all non-Event objects.

And taking your attachment example – an attachment in itself will not be an event in Zeitgeist. You would have an event for when you send or received the parent email. I am not sure that Zeitgeist events would go to the granularity of specific attachments, but since we are Nepomuk based this is really something that depends on the apps submitting the events.

Like Bejamin I agree choosing one backend instead of trying to make generic with an abstraction layer. Abstraction will slow down the development, narrow the possibilities and make everything much more complex then needed.

Tracker also got my vote since it’s active, specialized for files/program (meta)data and it’s ontology and is not like an content repository which used to have the content itself. It’s also close to Gnome and they’re hopefully open to optimize their API for Zeitgeist.

And keep in mind that you will throw away and redesign 3 more times anyway when you try to actually make useful applications from that data. (You might also want to tell that to the Nepomuk and Tracker guys.)

If I were you, I’d go Tracker, because you’ll likely get a bunch of people (read: Tracker hackers) that will implement features just for you, because you’re the only real user of their awesome library. And also because Tracker has a proper idea what “Items” are and how to query them effectively. As opposed to SQL or soe such.

the whole events thingy looks to be too generic to be useful – indeed it subverts an ontology. Differnt apps could use different names for events further destroying its usefulness and making it almost impossible to query

EG take a file attachment to an email, for zeitgeist this might be an event but for an ontology based system like tracker it is not – Its a semantic relationship defined in the onto.

The same could be said for file history, web history etc. These are all semantic relationships that belong in a structured onto and not loosely defined in a table

What zeitgeist should do IMO is copy what Dashboard did for beagle but store the events fired off as well in tracker for a limited time period (say 6 months) so it does not bloat up and use tracker to query them. When tracker goes into gnome as it should zeitgeist wont need to worry about other backends