DeepaMehta 3 v0.5 comes with a property-less data model
Jörg Richter
Maybe you know the situation from using DM2 or DM3 v0.4: 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.
a) 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/DM3v0.4 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.
b) 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/DM3v0.4'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.
2) Crippled data models.
The user is tempted to design the data model according to what the display should look like.
3) Weak display.
Although not enforced by the type/property duality DM2/DM3v0.4'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 v0.5 DeepaMehta 3 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 3 v0.5 with the new property-less data model is planned to be released in July 2011. Unfortunately, existing content from DM3 v0.4.x 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 DM3 v0.5 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:
https://github.com/jri/deepamehta3/tree/no-properties
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
Torsten Ziegler
thanks for the update, it is good to hear
what is going on at the deepamehta core.
This new approach sounds very good to me,
and I am curious to which re-use scenarios
this will lead.
Thanks,
Torsten
On 13.06.2011 20:07, J�rg Richter wrote:
> A thing is not characterized by its properties but by its relationships.
--
Torsten Ziegler
tor...@ziegi.de
Jörg Richter
On Jun 13, 2011, at 20:36, Torsten Ziegler wrote:
> thanks for the update, it is good to hear
> what is going on at the deepamehta core.
>
> This new approach sounds very good to me,
> and I am curious to which re-use scenarios
> this will lead.
Thank you, Torsten, for feedback!
We got the final push for the new data model when working on the DM3 Freifunk Geomap application.
https://github.com/jri/dm3-freifunk-geomap
There, a user is assigned to a "Bundesland", and this is currently modelled as a property. But for us it was clear that future Freifunk use cases, and possibly future applications in general, want to re-use a "Bundesland" topic type along with its instances.
Besides re-use another aspect that benefits from the new data model is *display*. In the old data model property values never appear in the network visualization (left-side), just the topics do. So, the context display was limited to topics. The new (property-less) model allows to visualize the "Baden-Württemberg" context exactly in the same manner as the "Torsten Ziegler" context.
Cheers,
Jörg