zeitgeist team mailing list archive

[Seif Lotfy <seif@xxxxxxxxx>]

2009/7/20 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)
>
Ok i used the name apps instead of actor but non the less very similar

>
>
> 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.

shouldn't be a uri of an app could be http://youtube.com

>
>
> 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
>
So as i see it event.subject is what i called target
so far i agree with you


>
> 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)

ME like alot

>
>
> 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)

Event better

>
> 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
>
> LOVE IT LOVE IT LOVE IT
however what happens if i want to log an event where the subject has not
been registered yet?
It is not a big deal but I wonder...
All in all I am ok with following this structure very very very nice!
kick ass!!!