Siegfried, I think you make a good case. However I don't see it conflicting with what we have now though. Whether origin is something on the event or the subject(s) is purely a matter of how one looks at it now that we have a 1 to 1 mapping between events and subjects in the db.
The tricky part is defining how we want to assign the origins for which types of events. It would be most useful to have a written spec here. Consider your download example (which is a good one btw!), what if I downloaded the files via a download manager app? Then the event context is lost and we have to resort to guess work to establish the origin (and likely use the host URL of the subject). Let's not go into these details here. We should have a spec! For me, I don't think it makes a lot of sense to talk about the origin (or root) of an event, events are intangible things. All relations to the physical world is described in the subjects. Furthermore it is technically impossible to use the event as the entity to store the origin since an event can have several subjects each with their own origin. Consider for instance if I select files ~/foo/bar.txt ~/other/one.txt and move them to the trash in Nautilus. This is one event, but each subject will have a different origin. Then there's the topic of full text searching. I think there are two sides of the matter you touch in your comment. 1) In relation origin, and 2) in the more general sense where we want full text search on any fields that make sense. So for 1), one reason that the parent folder is useful for file events is that we can look for "hot origins". Like we can detect that a lot of activity has been in the folder ~/Projects/zeitgeist in the past two days. We could for instance introduce new ResultTypes for the FindEventIds() method, like ResultType.MostRecentOrigin and ResultType.MostPopularOrigin. Such things can not be done easily with full text searching (it can be done though, and it is called "clustering", but no desktop search engine provides that atm. (and they likely wont in the near to mid-term future)). That said I still think that a full text search could be useful, but I don't think we should intermix it with our FindEventIds() method. Full text searching is very different in nature than strict SELECTS on a DB. We can maybe open up a separate bug report to discuss full text searching the events? -- origin should be a property of events, not items https://bugs.launchpad.net/bugs/425258 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: Invalid Bug description: Both http://live.gnome.org/GnomeZeitgeist/DatabaseDesign and our current implementation have "origin" as a property of items, but this makes no sense, as the origin can be different for every event and should as such be a property of it. (Further, to improve disk space usage we should save the actual value of it in the "uri" table). I'm filling this bug so that we don't remember to fix it, but please let's ignore it until we get the basic event/item separation stuff merged - most important stuff first. _______________________________________________ Mailing list: https://launchpad.net/~zeitgeist Post to : email@example.com Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp