Building types in DeepaMehta 4 is creating Type Definitions. But why should you care about, as it says, defining types? Well, that term names already one of what are overall seven terms to be defined in this article helping you to express and build (pretty much) any complex software application exactly the way you see or want it. One idea behind inventing and designing this small vocabulary (7 terms) was to create a structure which enables users to shape the technology they see they need for.
When defining types users decide model their outer world into their database and for such an “application model”, DeepaMehta 4 equips you with a graphical user interface allowing you to enter and edit the databases contents without further work. Now the harder part, creating a so called “application model”, is defining a composition of types and in DeepaMehta 4 one can currently do so through drawing a diagram of nodes and edges.
Let me introduce just one general idea behind this type building toolkit before i start introducing its language: Your diagrams will be part of one or many of so called Topicmaps. Topicmaps always represent some subset of your database and if you throw them away after you finished work (in this case you might’ve been type building) everything you’ve done (created or edited) will be in your database as you would expect. The contents are still available and ready to be revealed in any new or other Topicmap later. In that sense, so called Topicmaps stored in this machine are “views” (as in: certain aspects of your database) and they should be seen as independent from the contents (like e.g. your notes, contacts, mails, type definitions, …) in your database.
Introducing DeepaMehtas type building language
In this world, Type Definitions are simple or complex structures describing how information is represented in a machine. Through understanding and creating our own type definitions in DeepaMehta 4 we can create personal database structures. Every type definition you will get one human readable and one machine readable name. The machine readable name is a so called “URI” and through this every type in this article can be referenced by writing down its URI. For constructing URIs, I always use the following convention: “language.domain.project.type_name”.
As an example, a Person (human readable name) in the DeepaMehta Standard Distribution database is of type “dm4.contacts.person” (machine readable name) and so a Notification sent out to subscribers (dm4-subscriptions module) is of type “org.deepamehta.subscriptions.notification”. Having a unique name will help everyone to share her and call upon certain other type definitions which in turn will help us to get to a deeper understanding of both, the views we have about the world and how we would represent them in a database.
Especially when collaborating with software developers you may encounter diagrams and drawing diagrams together may really help you to fast forward a collaboration through better communication. That is exactly what DeepaMehta 4 enables you but with the power of a framework for developing situational-apps (“good enough” software) behind the diagram. Once you created your first type definition you can (at the very minimum) present others your personal idea and design as (1) a diagram and (2) as a working multi-user database.
Now, when looking into the “Create” menu of DeepaMehta 4 we are confronted with two specific types of type definitions, so called Topic Type definitions and Association Type definitions. These two terms are derived from the fact that DeepaMehta 4 stores information in a networked fashion and when we express our world views in type definitions we do so through using the general means of network representation, nodes (“Topics”) and edges (“Associations”). In other words, in DeepaMehta 4 you draw connections between terms to construct type definitions for the machine. Through using the right connections types can contribute to other types and this works for both, you can not only specify arbitrary type of nodes you want to use in your system but also the edges. Together all these topics and associations form an associative and navigable network of information, we know this structure for information from browsing the world wide web. With typed nodes and edges this network can make up for applications, too.
To get it clear: Defining types allows you and other users to create embodiments of a concept or say higher-level abstraction. When one wants to build up a catalogue of her dogs, “dog” is a higher level abstraction for “Beagle”, of which “Snoopy” is kind of an embodiment of, right? Various degrees of abstraction and different categorizations of concrete embodiments are constantly floating when we as humans communicate but let’s leave that for some scientists and have a look at how we can express our database model.
Enough forewords, let’s get going
We differentiate all our types into so called Topic Types representing items (like subjects or objects) and so called Association Types representing relations between items (like predicates or special form of subjects), building up our network. Like expressing: Snoopy (first item) likes to philosophize on (predicate) the world (item). That’s it, very amazing!
Topic and Association Types have in common that each must have a so called Data Type defined. Additionally they can be combined. A so called complex type definition has the data type Composite set and a simple type definition has either the data type Number, Boolean, Text or HTML set. What now remains to be discussed for building up whatever data model housing information is what is a complex type definition, what Role Types are used for and whether using an Aggregation Definition or a Composition Definition suites better in your case.
The following seven terms allows you to build up the structure of your personal graph-database, without programming (just to give you a short outlook on the following paragraphs): Topic Types, Association Type, Data Types, Parent Type, Child Type, Aggregation Definition and Composition Definition. Any Type Definition which currently exists in DeepaMehta 4 is a meaningful connection made of these seven terms. Within the machine this “meaningful connection” is stored under any given name as either a Topic Type definition or an Association Type definition, which internally is represented and thus can be edited as a network of topics and associations itself. I like to call a type definition along with all its topics and associations which embody all related type definitions a “data tree”. Whatever that means, it is yours now.
Topic Types and Data Types
Currently there are four Data Types supporting you to store simple values like numbers or text in the database, plus there is the special data type called Composite allowing you to store more complex types of data. Every Topic Type or Association Type can have exactly one Data Type set. Once that is set for a type definition and users entered records of that type into your database it is not possible to adjust the data type without programming, just through writing a migration.
All of the following data types can currently be used by referencing them, either via interactive selection in the webclient after triggering a “Create” > “New Topic Type” or “New Association Type” command or by writing down their so called URI (Unique Resource Identifier) in the declarative migration part of your personal plugin.
When writing a migration and you come to the data_type_uri-option of your type definition, you have the option to choose one of the following values referring to the five Data Types (the latter being the exact URI):
- Number = dm4.core.number
- Boolean = dm4.core.boolean
- Text = dm4.core.text
- HTML = dm4.core.html
- Composite = dm4.core.composite
The role of a Composite is often just to be there, as it is the role of a parent for its child’s, while the child’s are the ones in which the values get located. This sounds like a bad analogy, I am sorry, but a type definition in DeepaMehta is hierarchical and similar to a parent-child relation in nearly every family with newborn. To get back, while navigating and focusing on an association between two specific items we often speak of the role a topic plays in such. For example: Father Max plays the role of the parent in the family relation with his child Merlot. And so, given by the DeepaMehta core, the Role Types of Parent Type (“dm4.core.parent_type”) and Child Type (“dm4.core.child_type”) are essential for building up more complex type definitions.
Example: The title of a Note (“dm4.notes.title”, data type: “dm4.core.text”) plays the Child Type role within an association where the type Note (“dm4.notes.note”, data type: “dm4.core.composite”) plays the Parent Type role. While the association is a one-to-one of type Composition Definition relating these two types. Visually revealed in a diagram the complete Type Definition of a Note might look somehow like two cherries which have some thin parent (node) at the top and the two saggy fruits as child (nodes). Their parent is just there to reference the composition of both values in specific type of information.
Composites: Building more complex type definitions
Now we’ve heard about the Role Types named Parent Type and Child Type let me reveal: Setting these is mandatory for successfully building a complex type definition. These two terms enable us to express the necessary parent-child relationship when setting types in relation with a type of Data Type composite. So, the question will be, in our application is an E-Mail Address more likely to be part of a Person or is it the other way around? Often the correct answer is either straightforward to grasp or philosophizing is less important than practical considerations.
Let’s have a look at the visual representation of an exemplary composite type definition in Illustration 1 (see below). There we can see that the default composite type definition of a Person relates to, and thus groups, other type definitions such as another composite type definition named Address Entry. So we know now, composites can also have further composites as child types. Similarly, if we want to build a complex Association Type we can simply associate new Topic Types to the complex Association Type, we just need to make sure that that is also of data type Composite.
When defining a composite its associations to other type definitions are what builds them up. Therefore we need to know about two very special Association Types. For constructing our composites we always need to choose between the two available association types ending on ” Definition” in their name, which is, between a Composition Definition (coming as dark red association) and an Aggregation Definition (coming as bright green association). These are the only two specific association types for relating types with each other.
Using Composition Definition or Aggregation Definition
The Composition Definition and the Aggregation Definition let us express a different degree of dependency between the types in our type definition. The red coloured edge signals a strong, direct dependence of the child to the parent type while the green edge signals a loose dependence of the child to its parent type. In the following diagram you see the type definition of a “Person” of the dm4-contacts module revealed (to some illustrative extent) . When have the webclient open and you start searching for “Topic Type” via the “By Type” menu you can easily reveal, alter or extend any type definition already present in your system. Get inspired and learn from all the existing type definitions, there are tens of them already available and these may help and guide you when conceiving others.
The important thing to notice now when looking at the type definition for a Person provided (in Illustration 1) by the dm4-contacts module is the following: When a user removes a person entry from the database all topics of types related (directly or indirectly) through a green edge to the type Person would not be deleted of our database as these are defined via an Aggregation Definition which connects a type as being independent from the other (parent/child) type. On the other hand, the cases complementing each other, if we remove a person entry all topics of type associated via a Composition Definition (a dark red edge) are deleted from our database as part of a user requesting to delete all data composing items (in terms of: items directly making up the being) of this person (in our database), here e.g. the Name and Phone Entry. This notion of a “Composition” and “Aggregation” relation is derived from the one developed and used as a part of the universal modelling language (UML).
When all the green edges signal us that an Aggregation Definition is defined and this would mean for example: If one of your users deletes an entry for a Person which lives in “Paraguay” that topic (with the value “Paraguay”, of type “Country”) will not be deleted from our database as part of your users request to delete that specific Person entry. Because the type country is correctly modelled as being independent of type Person. We could say that the country “Paraguay” is just aggregated by (but not composing) a contact entry for a person in our address book. Therefore the relation between the simple type Country and the composite type Address (which later becomes part of type Person) is modelled as we would expect, as a green coloured Aggregation Definition.
Illustration 2 shows us the type definition for an Address Entry and that the types Street, Postal Code, City and Country are modelled independent (as in: going to be re-used, shared between many person entries). Additionally, just when an Aggregation Definition is used to model the relation between types (just like here by the dm4-contact module) a simple join of a group of person entries become possible through graph navigation mechanisms via a specific and shared data value (better named key then). A simple shared value in this example would be a concrete Zip Code value as that potentially connects many entries in your address book and in doing so potentially is a (in graph-databases called) “super-node”.
Index modes and preparing for keys in your data
At the moment there is just one sensible rule of thumb to share to enable the formation of “super-nodes” in your database (while I am not sure if this is possibly when interactively building type definitions): When a type is connected via an Aggregation Definition, is of a simple data type like Text or Number you may want to set the so called Index Mode for that to IndexMode.KEY. In a declarative type definition this is done through adding the “dm4.core.key”-uri to the types array of “index_mode_uris”.
For each Topic Type defined as one of the four simple Data Types (number, text, html or boolean) a developer needs to specify one of the four IndexModes provided by the dm4-core. You do so, as always, by URI and here is the current listing of all:
- dm4.core.off – Deactivates indexing for this type
- dm4.core.key – Values indexed with key are those that must be unique
- dm4.core.fulltext – Queries will match on values here from the beginning of each word
- dm4.core.fulltext_key – Queries will match values from the beginning of each character of a word
The right IndexMode depends, boldly spoken, on (a) the values you want to index and the queries you want to fire at those later. For example URLs are unique per definition, as well as E-Mail Addresses. Using the IndexMode.KEY allows you to fetch the one and only topic in your database by its exact value via, e.g. in Java fetchin the topic representing this blogpost and its author in your system would be something like:
// fetching the topic that represents this webpage in any dm 4 system
Topic webpage = dms.getTopic("dm4.webbrowser.url", "http://infokitchen.net/?p=411");
// asking if there are any persons via an "is_author" edge
Topic author = webpage.getRelatedTopics("org.wordpress.is_author", "dm4.core.child", "dm4.core.parent", "dm4.contacts.person");
One more thing.
Cardinality between types
The cardinality for all Child Topic Types can (interactively) be adjusted through editing a Topic Type or Association Type topic through the webclient and through choosing between “One” and “Many” in the corresponding drop-down menu of the type in question. One example for defining the cardinality between two types from the exemplary Address type: There is alwasy exactly one Country (“Paraguay”) involved in any Address but many Addresses who are able to contain the one Country (“Paraguay”). See Illustration 2.
As you can also in the Address type definition by the dm4-contaacts module: One Street, City, Country or Postal Code can belong to many Addresses. Similarly further up this very type definition we find that a Person in our database can have many different Address Entries, while here, through having an Aggregation Definition modelled between the Address Label type and Address Entries types, a concrete Address Entry can share for example, the label “home” or “work”.
When one now creates a new “Person” entry, the edit form in the Page Panel will specifically take everything of our type definition, the cardinality, the parent-child relation, the order of Child Topic Types and the Association Types between our types into account and adjust the input fields automatically generated as a form for composite. Additionally the system matches and interprets any create, update or delete requests to a person entry by users (or also via the REST API) accordingly to your type definition currently stored in the database.
Putting stuff to work
If you are familiar with the e.g. Content Type Definitions (of Drupal CMS) or Post Types (of WordPress CMS) you can use DeepaMehta 4 Type Definitions for similar purposes when developing a bigger application. As shortly mentioned above, sharing type definitions enables us to improve these in collaboration and they are a good starting point for substantial discussions when reaching for more advanced or bigger goals in software application development. Type definitions help you to envision and re-think what needs to be covered by this app exactly and in first place, enables experienced developers to calculate additional programming efforts, helps you to see various types in relation and get the bigger picture. Additionally, i found type definitions useful to describe tough task to a designers, sort of in a way that they really can’t wait to sketch out some first drafts.
The good part of building types with DeepaMehta 4 is, its standard webclient will give you an edit formula and a structured rendering out of the box for many personal use cases. Through getting to know this language for building types, engaged and interested users can design their graph database and present that accessible and usable to others. May that be then set up as a web-application on your office-net or on a public and secured web server.
In the meantime i published another article in which i share four thoughts on building a network of apps through combining type definitions. It briefly explains how to reference and therewith build upon available plugins already made by others.
I would be happy for any constructive feedback or comment. I will try to incorporate suggestions for improvements whenever possible. Thanks for reading & have a nice day!
Disclaimer
I am on the executive board of the non-profit organisation supporting the developers and users of the DeepaMehta Software Platform (DeepaMehta e.V.).
Annotations
[1] Playing around is: Open DeepaMehta, click “Create” > “New Topic Type”, vary with the “Data Type” and then click “Create” again and choose the name of your just created type definition.
[2] To create new elements use either the “Create” menu in the upper toolbar or click with your context-button (usually right click) of your mouse directly into the Topicmap Panel. To relate existing elements hold down your mouse over a topics icon and let loose your mouse pointer over the element to be related to the other or click the context-button (usually right click) over an element and choose the “Associate” command. All details for both, topics and associations are edited in the Page Panel on the right side if your screen after either clicking “Edit” or after double-clicking an element.
Changelog
Jan, 10 2015, 11:43am:
Slightly changed the first two paragraphs, inserted basics about naming and URIs for identifying our types, the “New Topic Type” screenshot and added a short introduction to Topicmaps as views.
Jan, 11 2015, 11:49pm:
Pasted paragraph about IndexModes into this article.
Feb, 16 2015, 2:45pm:
Revised all paragraphs until “Topic Types and Data Types.