Wednesday, 13 July 2005

Proposal: Chat and Discussion Interchange Datamodel

via Stephen Downes' OLDaily, I am pointed to this interesting proposal. This is a very good first step towards a data model for inter-operability between discussion forums and chat applications. Here are a few comments:

  • I don't understand why it is necessary to define the term "entity". As a vendor-neutral data model, we should not be concerned with implementations. The addition of "entity" does not contribute any additional useful concept in the data model.

  • The proposal has identified "role" as an important concept to be captured by the data model. However, this has not been further linked to the concepts of "rights". Typically discussion forums, list servers included, have moderator or administrative roles. [Administrative role needs not be captured in this data model if this role is solely concerned with the assignment of rights of participations.] Moderator typically have rights such as blocking participant's expression (using the term as proposed which is the same as message). Other typical rights include read-only participation for some participants.

  • Two typical features in many implementations which have not been captured by the data model are:

    • channel - e.g. in chat, many implementations allow "whisper" between participants

    • threading in discussion forum.

1 comment:

Norm said...


Thanks for the helpful comments. Here are my responses:

Entity: You’re right; there is no need to define entity. The sentences provided under this definition are not really a definition. I will eliminate the reference to “database tables” and include the enumeration of the entities.

Role: I also agree that this could be developed further in the data model --or clearly designated as “out of scope.” If there is a relatively simple way of modeling this, I’d definitely be open to integrating it.

Channel and Threading: These two items are not explicitly included in the datamodel; however, these can both represented indirectly through other elements in the model: Channels through personal identifiers combined with the message, and/or through the use of one or more message attributes; Threading through the reply to element of the message entity. What I will do, however, is provide examples of how these two items (and a few others) are accommodated in the datamodel, although they are not explicitly mentioned.