March 05, 2004

OmniaMea Data Model

I've long wanted to write this post, but unfortunately too much of my energy is taken by actually developing and managing the project... oh, well. Now I've found the time, and after this I'll be able to cover many other interesting topics - why OmniaMea will be so easily extensible, how OmniaMea's resource store compares with Chandler's repository, and so on.

The data model of OmniaMea has been heavily inspired by RDF, but it is somewhat less generic and more tailored to our needs.

The basic unit of information managed by OmniaMea is a resource. Most of the things you can see in OmniaMea (and some of the things we try to hide) are resources. For example, an email is a resource, a contact is a resource, and a contact's phone number is a resource too.

Every resource has a type, which is a string. The type allows to associate a resource with a plugin (or several plugins) which are responsible for the resource. Some of the responsibilities of a plugin are:

  • how to display the resource;
  • how to provide the text contents of the resource for indexing;
  • what icons to show for the resource depending on its state;
  • what to do when a resource is selected in a resource tree and so on.

Resource also have properties. The property type defines the name of the property, its data type (integer, string, date, boolean and some others) and some other specific information. For example, the property IsUnread has a type Bool, the property UnreadCount has a type Int, and the property PubDate has a type Date.

While a property is an attribute of a single resource, a link connects two resources with each other. Just like properties, links have types, and, generally speaking, "Link" is one of possible property data type values. Links can be symmetric, where both ends are equivalent to each other, and directed, where one resource is marked as a source and another as a target. For example, the link Category, linking a resource to its category, is currently defined as symmetric, and the link Parent, on which most of the hierarchical resource structures are built, obviously needs to be directed.

A resource can have only one property of each type (for example, a Contact has only one FirstName), but can have many links of a certain type (a Contact can be linked to multiple Category resources).

The most important feature of the OmniaMea data model is that it does not restrict which properties can be set on which resources. For example, a Contact usually has a FirstName, but this information is not encoded in the data model - you can create a Contact without one, and the respective field in the contact edit form will simply be empty. What's more important, you can add any additional properties to any resource. If you create a plugin which needs to store some additional information about a standard resource - for example, the LiveJournal username of a contact - you can simply register a property LiveJournalUsername of type String and set this property for all the contacts that need it.

However, for some usages this total freedom can be harmful. For example, the RSS plugin assumes that the link of type RSSItem from a resource of type RSSItem resource points to a resource of type RSSFeed, and there is only one such link (an RSS post cannot belong to multiple feeds). To enforce this assumption, the plugin can register a link restriction, and the resource store will throw exceptions if someone creates an RSSItem link from an RSSItem resource to something other than an RSSFeed, or if someone creates multiple links of that type.

The current version of OmniaMea with all plugins has about 50 resource types and almost 200 property types.

Coming soon: How we actually store all that data...

Posted by Dmitry Jemerov at 01:02 AM | Comments (0) | TrackBack