zeitgeist team mailing list archive

[Mikkel Kamstrup Erlandsen <mikkel.kamstrup@xxxxxxxxx>]

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.