Logging format for Contact interaction events

working on a telepathy logger I noticed an issue of how logging/retrieving contact interactions could be a challenge.
There are 3 types of interaction with contacts:
* Messaging
* Calling
* Filetransfer

=== MESSAGING ===

So with Messaging I have to proposed solutions and would like you to pick out the best fit.
Both have the event metadata in common.
* Access/Leave Event: When a conversation is initiated/ended by any of the parties (starting/ending a channel)
* Send/Recv Event: When sending out a msg or receiving a msg
* Origin: The user account used for this interaction (telepathy based)
* Actor: dbus://(service file)

The big difference starts on the Subject metadata level:

** Solution 1:
        1 Subject with:
            * uri: contact-telepathy identifier
            * interpretation = Interpretation.IMMESSAGE,
            * manifestation = Manifestation.SOFTWARE_SERVICE,
            * text: contact alias
            * origin: contact-telepathy identifier
            * mimetype: plain/text

** Solution 2:
       2 Subjects with:
           * Subject1 (describing the message):
               * uri: path_to_log
               * interpretation = Interpretation.IMMESSAGE,
               * manifestation = Manifestation.SOFTWARE_SERVICE,
               * text: message_text
               * origin: contact-telepathy identifier
               * mimetype: plain/text
           * Subject2 (describing the contact):
               * uri = contact-telepathy identifier,
               * interpretation = Interpretation.CONTACT.PERSON_CONTACT,
               * manifestation = Manifestation.CONTACT_LIST_DATA_OBJECT,
               * origin =contact-telepathy identifier,
               * text: contact alias
               * storage = "net")

I honestly prefer the second solution most. Since It allows me to query for contact details

=== FILE TRANSFER ===

With File Transfer I intended to use the interpretation SEND, RECEIVE, ACCEPT, REJECT. However I found it difficult to query for successfully FINISHED RECEIVING or FINISHED SENDING .So I ignored the ACCEPT and REJECT. I also log events post completion, or rejection etc. and not while still uploading. After a send or receive event i fill out a payload describing the status of the file transfer and the reason via json. I use the enumerations provided by Telepathy GLib as seen http://telepathy.freedesktop.org/doc/telepathy-glib/telepathy-glib-enums.html#NUM-TP-FILE-TRANSFER-STATES:CAPS and http://telepathy.freedesktop.org/doc/telepathy-glib/telepathy-glib-enums.html#TpFileTransferStateChangeReason

The log would entry for a canceled sending would end up looking like:

Event:
  - timestamp: 1332041362770
  - actor dbus://org.freedesktop.Telepathy.Logger.service
  - interpretation: http://www.zeitgeist-project.com/ontologies/2010/01/27/zg#SendEvent
  - manifestation: http://www.zeitgeist-project.com/ontologies/2010/01/27/zg#UserActivity
  - origin: x-telepathy-account-path:gabble/jabber/seif_2elotfy_40collabora_2eco_2euk0
  - subjects:
      - subject 0:
         - uri: file:///home/seif/test.test
         - interpretation: http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#TextDocument
         - manifestation: http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#FileDataObject
         - mimetype: text/plain
         - origin: file:///home/seif/
         - text: test.test
         - storage:
      - subject 1:
         - uri: x-telepathy-identifier:<email address hidden>
         - interpretation: http://www.semanticdesktop.org/ontologies/2007/03/22/nco#PersonContact
         - manifestation: http://www.semanticdesktop.org/ontologies/2007/03/22/nco#ContactListDataObject
         - mimetype:
         - origin: x-telepathy-identifier:<email address hidden>
         - text: <email address hidden>
         - storage: net
  - payload: {'http://zeitgeist-project.com/1.0/telepathy/filetransfer': {'requested': True, 'description': '', 'reason': 2, 'date': 1331915086L, 'size': 7L, 'mimetype': 'text/plain', 'sender': 'x-telepathy-account-path:gabble/jabber/seif_2elotfy_40collabora_2eco_2euk0', 'service': '', 'uri': 'file:///home/seif/test.test', 'state': 5, 'receiver': 'x-telepathy-identifier:<email address hidden>'}}

As you can see I am using 2 Subjects again. And at last the payload has come in handy. It is easier for me to ask for all sent file or received files and THEN filtering them out according to their status. Unless we have a SEND_COMPLETE/SEND_FAILED and RECEIVE_COMPLETE/RECEIVE_FAILED, it is really hard to make sense of knowing what happened with the sent/received file. So I find the only soltuion for now is actually a post-send post-recv entry with the description

=== CALLING ===

Calling is pretty straight forward. We will have 2 subjects once describing the contact and the other describing the call
the event interpretations used will be: ACCEPT, DENY, EXPIRE for incoming calls and CREATE for outgoing. Once a call start we will use the ACCESS EVENT and when ended we will use the LEAVE EVENT, upon a leave event we will use the payload to describe the call duration and maybe also who hung up first or the reason of the leave event.
The only issue we have with calls is there is no interpretation for the subject describing a call :(

So with that being said I would like to bring up the subject that now we will be using multiple subjects and payload. We do not support querying events with multiple subjects yet. I hope we can discuss this ASAP.
Please don't hesitate to discuss here what you think of my proposal.

=== COMMENTS ===
kamstrup: On the overall I think the 2-subject solution makes sense. However I also think that it might be relevant to consider which use cases the logged data will be involved in. To make sure you adequately cover them. Also - nice to see you're using payloads - that's exactly how I imagined them used :-)

kamstrup: Regarding file send/recv in particular. I think it hightlights a small problem we have in our basic data model. How do we model and event that starts one way but can end with two different outcomes? Maybe logging a "temporary event" that you delete when you know the final answer?