How we describe events/items/annotations

Registered by Seif Lotfy on 2009-07-18

This blueprint has been superseded. See the newer blueprint "Revamped DBus API for the Zeitgesit Engine" for updated plans.

 We should rethink how we understand events. I thinḱ of and event as a one instance happening as in "opened" "saved" "closed" not "opening" "saving" and "closing"
I proposed a new definition of events so instead of sending 1 big dict with shit load of info! We should separate those into two dicts. One descibes the info of the event (as in the source of the event as well as the type of the event) and another describes the target (in our case documents websites and notes :P)

Mikkel proposed this ontology:

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
 - annotations (such as tags, comments on this specific event)
 - 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)

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

Annotations can be seen here
http://live.gnome.org/GnomeZeitgeist/EngineAPIRevamp#Annotations

- We will use the events in a list and items in a dict
- Make place for multiple subjects per event

Blueprint information

Status:
Complete
Approver:
Markus Korn
Priority:
Essential
Drafter:
Mikkel Kamstrup Erlandsen
Direction:
Needs approval
Assignee:
Siegfried Gevatter
Definition:
Superseded
Series goal:
Accepted for 0.3
Implementation:
Implemented
Milestone target:
milestone icon 0.3.0
Started by
Seif Lotfy on 2009-10-09
Completed by
Siegfried Gevatter on 2009-11-15

Whiteboard

*** Discussion:
Natan: I don't feel strongly about this one way or another. If it's only an issue of convenience then its fine by me.

Mikkel: This is not about convenience. This is about Zeitgeist needing a well thought out and flexible event model and API if we want to make it as part of the Gnome 3 core. As Zg is in the moment of writing I would veto any kind of core inclusion -- Mikkel

Seif: We need to have a solution for the annotation ASAP

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.