2009/7/17 Seif Lotfy <s...@lotfy.com>:
> Hey Here is my take again on the issue
> An event is something that happens
> Something happens needs and application to triger it and a target on which
> the happening takes place (in our case a doc, note or webpage)
> So my current proposal is to send around a tuple of 2 dicts that describe
> the event:
> eventinfo: timestamp, app, eventype, eventtags and eventbookmark (if this
> specific event is important)
> targetinfo: name, uri, tags, comment, mimetype, origin, source, content.
> I think this makes sense to be honest and I hope most of you agree with me.
> This way we can clearly sperate the info we have. PLEASE PLEASE AGREE :P

Sorry for the late response, but I don't think this makes a lot of sense.

I think an event (or within Zeitgeist a "log entry") consists of five things:

 - action: What happened (The URI of some formal action defined in an
Events Ontology)
 - subject: What did it happen to (the target URI)
 - actor: The entity (app or other) from which the event was sent
 - timestamp: At what point in time did this happen (Unix epoch)
 - A persistent unique id for the event itself (a carefully
constructed URI would do fine)

Note that I am not sure that restricting 'actor' to applications is
entirely future proof. What about web apps? If I am tracking events
from Google Docs saying that the actor is Firefox is not good enough.

What we need to know about items linked in event.subject:

 - URI
 - Any annotations (such as tags, comments, and ratings)
 - Mimetype
 - Content type
 - Source type

With these Event, Item (and indirectly Annotations) metaphors in place
I think I would make sense to really differentiate them in the API. So
instead of a Insert(event, item) I think we should have a:


Thus *no item struct here*. We also need apps to be able to inform us
about they items, so a method like:


This method will also automagically update the item if it already
exists. Calling RegisterItem will *not* implicitly generate an event.
Items in their own right are timeless entities.

With this mindset it also makes sense to differentiate the lookup
functions, so we have something like:



Mailing list: https://launchpad.net/~zeitgeist
Post to     : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help   : https://help.launchpad.net/ListHelp

Reply via email to