2009/7/20 Mikkel Kamstrup Erlandsen <mikkel.kamst...@gmail.com> > 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: > > 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!!!
_______________________________________________ Mailing list: https://launchpad.net/~zeitgeist Post to : firstname.lastname@example.org Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp