zeitgeist team mailing list archive

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

2009/7/17 Seif Lotfy <seif@xxxxxxxxx>:
> 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:

 Event:
 - 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:

Item:
 - 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:

  LogEvent(event_struct)

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

  RegisterIterm(item_struct)

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:

  FindEvents(...filters...)
  FindItems(...filters...)

-- 
Cheers,
Mikkel