Version 1 (modified by jri, 12 years ago) (diff)


DeepaMehta 4 comes with a property-less data model

This announcement has been posted on June 13, 2011
to the (now defunct) DeepaMehta Google group.

Maybe you know the situation from using DM2 or DM3: when modelling a domain you always have to answer the question "Is it a type or is it a property?". The decision has crucial impact for both, storage and display.

  1. Storage:

A type encapsulates an aspect of the domain's *semantic*. Types are instantiated through topics. So, a topic is a typed thing that is loaded with semantic, e.g. the city topic "Berlin". Relationships are expressed by associating Topics with each other. Thus, once stored in the DB a topic can be re-used in future usage scenarios and is also a vital building block for meshed applications.

Properties on the other hand are no units of its own. Property values are more-or-less plain text strings that are attached to topics. They are deleted along with the topic. In DM2/DM3 properties carry no semantic (except a low-level one in terms of "Text", "Number", "Date"). The string "Berlin" is never re-used but duplicated for each topic instance and there is only a string match but no semantic identity.

  1. Display:

Topics and their associations are displayed as network in the left-side panel of the DM screen: the *context*. Property values are always displayed in DMs right-side panel. This panel displays all the properties of the selected topic: the *detail*.

The Type vs. Property duality along with DM2/DM3's simple/weak display strategy creates crucial problems:

  1. Hindered application evolution.

What is regard second-class (a property) today may become first-class (a type) tomorrow. But once the type/property decision is made it is not easy to revise it later on.

  1. Crippled data models.

The user is tempted to design the data model according to what the display should look like.

  1. Weak display.

Although not enforced by the type/property duality DM2/DM3's display strategy reflects it strictly. The modeller must ask: is it context (typed topics) or is it detail (properties)? But there is no clear answer. What is detail in one situation is context in another.

To address these problems, starting from upcoming DeepaMehta 4 will be build on a fundamemtally changed data model. There will be no properties anymore. Just types. This means (philosophically):

=> A thing is not characterized by its properties but by its relationships.

So, a person for example is no longer represented as a single topic along with its properties (name, birthday, city of birth, profession, ...) but as an aggregate: a network of interconnected typed topics. Among others there might be a city topic that is connected to the person topic via a "city of birth" relationship. So, the concrete "Berlin" topic is shared with and associated to all Berliners. Furthermore that very topic might be involved in "city of death", "country", and "borough" relationships.

The quite radical concept of a property-less data model was actually targeted for DM3 from the start but was not tackled until now. This is because it is unknown territory (at least for me) and requires a lot of conceptualization (not to say brain fuck ;-). A whole bunch of new questions needs to be answered, e.g.: What are the reasonable processing units for both, the service API and the display? And what are the rules for constructing them? Respectively:

=> What are the borders of a thing?

In the first run we solve this question by leveraging the known object-orientd/UML concepts of *association*, *aggregation*, *composition*, and *cardinality*.

One clearification: we see the problem with properties not in the missing semantic (properties can be loaded with semantic as well like W3C's RDF model does) but in the very type/property *duality* (class/property duality in RDF).

DeepaMehta 4 with the new property-less data model is planned to be released in July 2011. Unfortunately, existing content from DM3 can not be used. We hope a community developer feels motivated to build a migration tool (and there are signs there is at least one :-). Besides the fundamental under-the-hood changes DM4 will include some smaller improvements that are suggested by user feedback.

Developers (and users with Git and Maven installed) can checkout the work-in-progress from the "no-properties" branch:

A greeting goes to Jürgen N. who encourages us to tackle the property-less data model now instead of continue building on a weak foundation.

Cheers, Jörg