DMX User Guide¶
The DMX User Interface¶
The upper toolbar contains the crucial steering tools for DMX: The workspace selector, the topicmap selector and the user menu.
The Workspace Selector¶
The Workspace Selector is part of the upper toolbar and lets you select your current workspace. Workspaces are the highest level of content organization in DMX. You can think of a workspace as a context in which you organize your work while you can associate items across different workspaces.
Everything you create is automatically assigned to the workspace selected in this menu. Every item in DMX is assigned to exactly one workspace.
Look at how we recommend to use workspaces on our Demo Server.
In DMX read and write permissions of users are tied to workspace memberships: Every user can create, edit and delete their own workspaces. If you create a new workspace you become its owner and you can invite users as members to share the workspace with. If a user has read or write permission for an item depends on whether the user has read or write permission for the workspace the item is assigned to. DMX’s permissions concept is called sharing modes. You can read more about the five sharing modes in the section Introduction to workspaces and sharing modes.
The DMX Standard Distribution comes with the following pre-installed workspaces: System, Administration and DMX. Additionally, each user has a private workspace. Content in a private workspace cannot be read by anyone other than the workspace owner.
Your choice in the Workspace Selector has direct influence on the available contents in the next menu, the Topicmap Selector.
The Topicmap Selector¶
The Topicmap Selector is the second drop-down menu in the upper toolbar. It lets you switch between all views in a workspace. A topicmap represents an individual working situation in the larger context of the selected workspace. On a topicmap you can visualize content that is relevant to the current context. It shows a situation-based view of selected content from the database.
Go to our Demo Server, navigate through the workspaces and have a look at the different topicmaps. They all show specific views on parts of the same underlying database.
For the moment, two types of topicmaps are supported: Topicmaps and Geomaps.
A new topicmap is always empty. In the beginning, there is only one topicmap, it’s called “untitled”. A topicmap view is like a canvas as it allows you to freely place items. The layout of the topicmap is persisted over working sessions. Edits to a topicmap are instantly mirrored to other connected users. The size of a topicmap can be well beyond the size of your screen. You can move it with your mouse.
Find out more about working with topicmaps and geomaps in the section on Organizing the working context.
The Topicmap Panel¶
The Topicmap Panel is the main area of the DMX user interface. It displays the currently chosen view. The topicmap panel is as wide as your browser window unless you open the detail panel.
When you select an item on a topicmap, a rectangle opens up displaying details about the selected item. This box is called the in-map details.
Note that the in-map details only show up if the detail panel is not visible.
The Search/Create Dialog¶
The search for existing items and the creation of new ones is done in the same dialog box. The search/create dialog is opened in the center of the screen with a right-click into the topicmap. Advanced search options are explained below in the Navigation section. Read more on how to create content in the section about Content Authoring.
The Detail Panel¶
The “Detail Panel” is opened by clicking “Details”, “Edit”, or “Related” in the context menu of an item. The detail panel shares your screen width with the “Topicmap Panel”. It has four tabs, “Info”, “Related”, “Meta”, and “View” described below.
The detail panel allows DMX to display more information than the in-map details. It is also used for editing data.
The detail panel can only be opened if you have selected an item on the map. Once opened, it stays open as long as you have selected an item. When you unselect an item by clicking somewhere onto your topicmap the detail panel closes.
DMX avoids to display redundant information by not opening both the detail panel and the in-map details at the same time unless you explicitly pin one of them: To show selected “In-map Details” while the “Detail Panel” is open you can pin the in-map details to your map. Pinning shows “In-map Details” in a topicmap, no matter what. Vice-versa you can also pin the “Detail Panel” by clicking the little pin icon in its upper right corner. Using the same button you can un-pin and close the detail panel.
Note that the detail panel only displays details of a single selected item, not when you bulk select several items.
The “Info” tab¶
The “Info” tab is the first section of the detail panel. It is named after the type of your current selection, e.g. a topic of type “Person” or “Event”. You can go to the info tab directly by choosing Details from the context menu or by selecting the first tab in the detail panel.
In display mode it shows the direct child topics of what is currently selected as this is the most commonly wanted information. It only shows child topics with a value assigned, that is fields containing data.
You can use the display mode to reveal selected child topics in the topicmap panel by hovering the child topics and using the little eye symbol (at the very right).
The info tab also has an edit mode. You can enter the edit mode either directly from within the topicmap by clicking “Edit” in the context menu or by clicking the “Edit” button at the bottom of the “Info” tab. If you enter the Edit mode, you get a form with all possible input fields regarding the respective item type. The form is generated using the type definition representing the content (for more details, see our section on Modeling).
The “Meta” tab¶
The “Meta” tab in the “Detail Panel” is the third tab and displays a summary of metadata about the selected item:
- the item’s technical identifier (ID)
- the Uniform Resource Identifier (see Wikipedia: URI)
- the creation date and the author’s user name
- the date of the last modification and the respective author’s user name
- the Workspace this item resides in as well as the workspace owner’s name
- the Type of the item (DMXType)
- all Topicmaps the item is visible (not hidden) on
Note that in contrast to the Meta tab the “Related tab” lists all related database content, e.g. topicmaps an item is part of but currently not visible in (hidden).
The “View” tab¶
The fourth tab “View” gives you access to what is called a “View Configuration”. With view configurations you can control the visual appearance of topics and associations of a specific type. So, editing a view configuration influences how items are rendered across all topicmaps. At the moment, DMX allows you to perform the following customizations for topic and association types:
- Topic Types: Icon, Font Color, Background Color
- Association Types: Association Color
For the moment view configurations are only available on a per-type base (which is why the “View” tab is grayed out on any item which does not represent a Type Definition). You can learn more about working with type definitions in the section about Modeling.
The Login Dialog¶
In a standard DMX installation, once you click “Login” in the upper toolbar you get this login dialog that prompts you for a user name and a password:
In some cases this dialog looks different. This can be the case when the DMX installation you are working with is run by your organization and you were told to use your normal credentials you have with the organization. In that case you can select the authentication method from the drop-down menu in the login dialog. To use the user name and password from your organization select the “LDAP” method and enter your credentials.
You can learn how to install plugins in our Admin Documentation.
Organizing the working context¶
The DMX database contains your knowledge at large, your knowledge base. Everything you enter is saved in the knowledge base until you delete it. What is important: Every item is saved in the knowledge base only once, even if you re-enter it or use it in many different contexts.
To visualize your knowledge base in different situations you use topicmaps. In each topicmap different items from your knowledge base may be relevant and the rest stays hidden. Thus, every topicmap represents one view, perspective, or working situation.
The following figure shows the relationship between content and its use in different working situations:
In the upper half two different working situations are shown (Topicmaps). On each of the maps there is a selection of topics and associations revealed depending on what the topicmap is about.
In the lower half you see a representation of a DMX database. It contains your complete knowledge graph made up of topics and associations. (Note that it also contains topic types and association types which are not visualized here for clarity.)
In the upper half there are two different working contexts respectively topicmaps. On each of them there is a selection of topics and associations revealed depending on what the topicmap is about. There can be much more content in the database than what you actually display but everything that is visible in topicmaps is stored in the database.
Working with topicmaps¶
Creating a topicmap¶
To document a meeting, prepare for an interview or to do some research you can create a topicmap. To create a new topicmap open the search/create dialog (right click). Enter the name of the new topicmap, select Topicmap from the “Create” menu and confirm with “Create”.
For topicmaps, the creation dialog has an additional choice between (usual) topicmaps and geo maps (see below). Once created, the new topicmap is opened. You can see its name in the Topicmap Selector and use it to switch between topicmaps.
Renaming a topicmap¶
You can rename a topicmap by clicking the “i” button next to the Topicmap Selector.
The “i” button reveals the topicmap topic itself on the topicmap. Long-click onto it and select “Edit” from the context menu.
The detail panel opens and lets you change the name.
After saving the change the new name appears in the Topicmap Selector. You can hide the topicmap topic from the map via the context menu.
DMX offers a plugin to support geodata. Every topic with an address can be shown on a geographical map. The so-called geomaps are a special type of topicmap in DMX. Geomaps are based on openstreetmap.org. Here is an example of how to create and populate them: Edit a person or an organization and add an address.
Open the search and create dialog. Enter a name for the new topicmap, e.g. “Our Geomap”. In the topic type selector choose “Topicmap”. Underneath it you can now choose the type of topicmap you want to add. Select “Geomap” and press “Create”.
Open the topicmap selector in the upper toolbar and select your newly created geomap. The map is displayed with all items you assigned an address to.
If you click onto an item the in-map details show you what is there.
Again, you return to the other topicmaps via the Topicmap Selector.
Moving things around¶
Note that you can drag the whole topicmap into any direction. Just hold the left mouse button pressed somewhere on the topicmap and drag.
Grab individual items with your mouse and drag them where you want them to be.
There is an important difference between hiding items and deleting them. If you delete items they are immediately removed from the database. If you hide them, they are just no longer visible on the topicmap but you can bring them back by revealing them.
You can hide items from the topicmap by long-clicking onto them and using the “Hide” button in the context menu. If you bring them back to the map later by searching them, they will reappear in the same spot in your map. All previously revealed associations do so as well (see Automatic Revelation of Associations).
You can “open” more than one item at the same time by pinning the in-map details. This is very useful for comparisons. Select a topic or an association so that its in-map details open. Click the little pin to keep them open.
Note that the pinnings are persisted in the database along with the topicmaps. That is why you can prepare a topicmap with pinned in-map details, knowing that everyone who opens the topicmap will see it in that very state.
You can bulk select several items by keeping the CTRL or SHIFT key pressed and drawing a rectangle around the items you want to select. You can also click them with the CTRL or SHIFT key pressed. The selected topics now have a blue border.
Moving topic clusters¶
Once you have bulk selected a few items, you can drag the whole selection where you want to place it.
Hiding multiple items¶
To hide several items at once select them by keeping the CTRL or SHIFT key pressed and drawing a rectangle around them or by clicking them with the CTRL or SHIFT key pressed.
Customizing the Look & Feel¶
Assigning icons and colors to topic types¶
You can assign icons from the Font Awesome collection to your topic types. Editing the view configuration is explained with the topic type “Publication”. In the section about Modeling you will learn how to create such a topic type. Let’s say you have a topic type “Publication” and you want all publications in your map to have a book icon.
- Click onto the topic type “Publication”, not onto an individual publication you already added. You are about to modify the general concept of all your publications, not an existing instance of it.
- Open the detail panel by selecting “Details” from the context menu.
- Go to the fourth tab called “View”. Here you can view and edit the configuration of the topic type. Click “Edit”.
- Click into the white field labeled “Icon”.
- You can either select an icon directly or use the search box.
- Hit save to apply the icon to all topics that are publications.
Adding colors to different topic types can help you to keep track of your content on a populated topic map. You can customize both the icon color and the background of a topic type. The settings are in the “View” tab of a topic type as well. Each of them lets you open a color picker or enter a 6 digit color hexcode.
After saving, all instances of that topic type are recolored to match your setting.
Assigning colors to association types¶
You can assign colors to association types just as you can assign icons to topic types. Select the association type on your map, open the details panel and open the fourth tab “View”. Choose a color for your association type and save it.
Collaboration and Sharing¶
Creating user accounts¶
In DMX, you create user accounts just the way you create everything else, too: Enter a user name into the search field. If the name does not exist yet you create it by selecting the topic type “User Account”. After that, a password field appears. Only privileged accounts (like admin) can create user accounts.
What is displayed after account creation is just the user name? The user account consists of the user name and the password. Investigate the newly created user name via the “Related” button. The user name is associated with some information:
- disk quota: how much space the user can use on the computer
- what type of sharing modes the account owner can select when creating new workspaces
- if the account owner is allowed to log in at all
It is important that every user account is tied to the “System” workspace (see below). In short, this allows others to read their user name (only the name) to share content.
Changing a password¶
Users can change their own password by searching for it and editing it. Open the Search/Create Dialog, enter your user name and click it to reveal it on the topicmap.
Click it to open the in-map details and investigate it: The user account is a composite consisting of a user name and a password. The password is not visible in clear text but it is hashed for more security.
Use the context menu to edit the user account.
Edit the password field in the detail panel. Enter the clear text password - DMX will hash it for you when you press “save”.
The admin password can be changed in the same way.
Introduction to workspaces and sharing modes¶
In DMX workspaces are the highest level content is organized in. Workspaces can be compared to folders containing everything related to a working area, a project, or an area of life. Each topic and association is tied to exactly *one* workspace but you can display them in many topicmaps. A workspace can have one or many members who have access to its content. Read and write permissions are tied to workspaces. This feature makes workspaces the basis of collaboration and the key to the configuration of access control:
DMX has five sharing modes:
- private: In a private workspace just the owner of the workspace can read and write.
- confidential: In a confidential workspace the owner can read and write. Workspace members can read, but not change anything.
- collaborative: A collaborative workspace can be read and edited by the owner and by all workspace members.
- public: A public workspace is world-readable. It can be read and edited by the owner and by all workspace members. The default “DMX” workspace is an example of a public workspace.
- common: For common workspaces, you can configure the behaviour in the configuration file
config.properties. You can decide whether you want to allow reading and/or writing for non-logged in users. If configured accordingly, a common workspace on a DMX instance connected to the internet can be readable and writable to everyone on the internet. See our Admin Documentation for more details.
Every workspace has an owner, usually the creator, and optional members. When you are logged in you can access the different workspaces via the workspace selector in the upper left corner. Once you log out DMX will switch back to a public (world-readable) workspace like the default workspace called “DMX”. All items that are publicly readable stay visible, the rest disappears from the view. In a public workspace you are no longer able to edit but you still have a customizable view of the topicmap, which means that you can move items and reveal other world-readable items. If you explicitly do not want or need any of the five sharing modes, you can disable them via configuration.
DMX comes with four default workspaces with the following sharing modes:
- DMX: This workspace a public, it is the one that is displayed publicly when people come to the site.
- Private Workspace: This is the private workspace of the respective logged in user. Only this user can see and and edit their items as the workspace is private.
- Administration: Only the admin or members can view and edit items in this workspace. Unprivileged user accounts do not have this entry in the menu.
- System: The System workspace is readable by everyone who is logged in. It contains all user names that exist in this DMX installation. The user names are readable to all users. This is needed for sharing content with others as you will see below.
Moving objects to a different workspace¶
As of DMX version 5.0-beta-7 it is possible to assign existing objects to a different workspace. For this, you must have write permission on both the selected object and the target workspace.
An example use case: You have a contact, a “Person” object, in your private workspace that you want to share with some other user.
Select the object and open the “Meta” tab in the detail panel. Hover over the Workspace field with your mouse pointer and click the edit button. You can now select the target workspace from the drop-down menu and hit “Save”.
This only works for individual selected objects. Bulk operations are not yet supported.
A data model is an abstract model that defines all elements needed to represent items, their properties and their relationships. DMX enables users to create their own data models.
Introduction to Data Modeling¶
DMX is built upon the so-called Associative Model of Data. It uses a suitable database model which can be considered opposed to the widely used Relational Database Management Systems.
If you want to dive deeper into this concept, we recommend the following sources:
- Joseph V. Homan, Paul J. Kovacs: A Comparison Of The Relational Database Model And The Associative Database Model, in: Issues in Information Systems, Volume X, No. 1, 2009 (6 page article)
- Simon Williams: The Associative Model Of Data, in: Journal of Database Marketing, Volume 8, 4, 2001 (24 page article)
- Simon Williams: The Associative Model Of Data, Lazy Software, 2nd edition, 2002 (book, 284 pages)
Types versus instances¶
To understand the fundamental concepts of DMX it is very important to understand the distinction between topics and topic types, respectively between associations and association types. This distinction separates an abstract concept (types) from the particular occurences (instances) of the concept.
For example, the particular bicycle in your garage is an instance of the type of thing known as “The bicycle”. Types are the ideas or abstract descriptions of the things you want to represent. They can be sets, collections, object classes or kinds of things.
Instances of a type are the concrete items, the content (topics and associations). In DMX you can visualize both, types and instances, even in the same topicmap.
Topics and topic types¶
On the level of topic types you describe models of the topics you want to create. You can add your own topic types.
|Topic Type||Instances / Topics|
|Fruit||banana, apple, cherry|
|First name||Cathy, Alice, Robin|
|Color||red, yellow, blue, green|
In DMX every topic is an in instance of a specific topic type.
Associations and association types¶
Associations represent the relationships between items. They represent real-world semantics. These can be relationships between topics or between associations or between a topic and an association. The most important characteristic of associations in DMX is that you can qualify them to give them the meaning you need. You do this by creating association types.
|Association type||Related items||Instances / Associations|
|Organizational role||person and organization||founder, member, employee|
|Involvement||person and publication||author, editor, reader, subject|
|Relationship||person and person||friend, enemy, lover, mentor|
Every association is an instance of a specific association type.
Simple data types¶
Every topic or association has a data type. There are six different data types in DMX. Four of them are so-called simple types:
- text: This is the default data type and it contains a text string.
- number: An example is “year”.
- boolean: yes/no resp. true/false
- html: HTML
Composites and composition definitions¶
The two other data types are composites. First of all, “composite” means that this data type is put together from several simple data types. The name of a person mostly consists of at least a first name and a last name. An address entry is put together from a street name, a number, a postal code, a city.
A composition definition is an association type within a composite: As you will see below you define a composite by creating associations between topic types and/or association types. By doing so you define the parent-child relations, the cardinality of properties, and the identity attributes (unique identifiers) for your data model. This kind of association type is called a composition definition.
For associations there is just one composite data type which is obviously called composite. For topic types DMX has both composite types: value and identity.
These terms exist to clarify what you are referring to when changes occur. Think of real-world contexts and how people are able to understand what changed. If a person has a new address this could mean they moved, but it could also mean the street was renamed. You can model these two different case by using the data types “identity” and “value”.
The composite type “identity”¶
In DMX, identity is used when you want to refer to the same thing as before even if something changes. If an address changes because the street is renamed you would still mean the same house at the same geolocation. If you save a bookmark to refer to an article and the URL of that article changes, the article and its description would be the same as before. If you edit a person’s details in your address book the person itself stays the same, even if their phone number changes.
The composite type “value”¶
The composite data type “value” is used whenever you want to refer to something different upon a change. While the topic type person is a composite of the data type “identity”, topic type person name is a composite of the data type “value”:
If a person changes their name the change is done by deleting the association to the old name and by creating an association to the new name.
The background to this is the following: In DMX, every item is saved in the database only once. For example, there is one last name called “Jones” in the database. All persons who share this name are associated to it. Technically, this means that many parents share the same child. Upon a change of name, the old name stays in the database because it may be associated to other items: Many people are called Cathy or Jones so the database entries can be considered to be a dictionary of names. The persons are just associated to immutable names but the associations between them can be deleted and redone.
Here is what this change looks like: Before, the person Cathy Jones is related to the person name, a composite of first name and last name. This is shown by the red associations.
To assign a different name to the person, you just edit the person’s entry and change the name. The association between the person and the person name is deleted. A new association is created. The old person name stays in the database, disconnected from this instance of a person. If you are sure you do not need it, you can explicitly delete it.
Defining your own Type URIs¶
Upon creation every type gets an automatically generated Type URI. It looks like this:
URIs (Uniform Resource Identifiers) identify resources unambiguously. For global uniqueness they follow a specific syntax.
When you dive into modeling or development with DMX you should adapt these Type URIs to your own projects with meaningful names. Developers working with the types in a specific project can then address them easily without unintended duplicates or changes.
There is a best practice for choosing your Type URIs:
Namespaces shall follow the pattern
You can use DNS domains for the first part, or just think of an unambiguous abbreviation.
An example for the URI of a topic type “publication” on our own demo server could be
systems.dmx.demo.publication or just
You can edit the Type URIs via the edit button.
You have adapt the TypeURIs before adding any instances!
Creating a simple topic type¶
You can add a topic type via the Search & Create Dialog. Search for what you want to add. If it does not exist in the DMX database, yet, select the topic type “Topic Type” and click “Create”. By default, a new topic type has the simple data type “Text”.
Creating a composite topic type¶
To create your own topic type with a few properties here is how to proceed. Let’s say you want to add a topic type “publication”. Each publication shall have a title and a year.
- Open the search field. Enter “Publication”, select “Topic Type” and press “create”.
- Go into editing mode via the context menu. Change the data type from “Text” to “Identity” and hit “Save”. Click somewhere into your map to close the detail panel.
- Open the search field and enter “Title”. You will find that two entries already exist. They come from the default topics types “Event” and “Note” which also have titles. Create a new topic type “Title”.
- Create an association between the title item and the publication item. DMX will display what you just created:
- You created an association of the type “Composition Definition”. Composition Definition means that you are defining a more complex context between items on your map: The relationship between a publication, a title and a year.
- “Cardinality: One” means that each publication has exactly one title, not more.
- The rest of the information refers to the role types: The publication is called the parent type, the title is the child type. These are technical terms to define that a publication has a title, but a title does not have a publication.
For a composite with the data type “identity” you should define at least one identity attribute. The identity attribute is the item’s unique identifier - the information that makes it unique. If needed, you can define more than one identity attribute. When modeling a composite it is important that you add the identity attribute as the first child to the parent. This is how you tell DMX to fill in this field with what you enter into the Search/Create Dialog.
- Add an identity attribute. In our example the title shall be the unique identifier of the publication. You thus edit the association you just created between the title and the publication. Tick the checkbox “Identity Attribute”. (In real life, you would maybe use the ISBN number as the identity attribute or as one of several identity attributes.)
- Right below that checkbox there is another one called “Include in Label”. Tick it for the information that should be used in the item’s name. It determines which attribute is shown on the topicmap and on top in the detail panel. In this example we want the book title to appear there.
- Again, click somewhere onto the map and reopen the search field. Search for the year and open the existing topic type “Year”. Pull it onto the publication.
You are now ready to use this data model you just built to add content.
- Open the search field and enter the title of a publication. From the Topic Type menu you can now select “Publication”.
- The title is automatically filled in from the search field.
- Edit your new publication and add a year.
Creating an association type¶
One of the strengths of DMX is that you can build your own association types in the same user interface. Let’s say you want to express the relationship between persons and publications. A person can be the author, the publisher, the reader, or even the subject of a publication.
- Create a topic type “Publication”.
- Create an association type and give it a name, e.g. “Relationship publication - person”.
- Select “Composite” as a data type.
- Create a topic type, name it “Role referring to publication” or anything that suits you. Its data type is “Text”.
- Create an association between the topic type and the association type and edit the newly created association between them. Click onto the “View” tab and then “Edit” to edit its configuration.
- Open the “Widget” setting and select “Select”. This will allow you to select roles from a predefined list when adding content later.
- There are two more checkboxes called “clearable” and “customizable”. It only makes sense to use them in connection with “Widget: Select”. Both have an effect on editing association types later on. Here is what they do: “Clearable” decides whether you allow instances of this association type to only have the values you explicitly defined or whether it shall be possible to clear the field to leave it empty. In this case, there will be a little cross icon for clearing it. “Customizable” decides whether you allow to enter values on the fly by just typing in something different that was not predefined by you. If both checkboxes are left empty, one of your predefined values has to be selected. The value cannot be empty and there will be no possibility of typing into the field.
- Create a topic “Author” that has the topic type “Role referring to publication” which is selectable from the create menu. If you want to have more roles, add them likewise.
- Create a person.
- Create a publication.
- Create an association between the person and the publication and edit the association. Open the drop-down menu under “Association Type” and select “Relationship publication - person”. Hit the save button and the edit button again. There is a new drop-down menu that lets you select the role the person shall have related to the publication.
You now have a map like this. On the left side you see the data model. There is your topic type “Publication” with a title and a year. And there is the association type you built with a few selectable roles.
On the right side you see the actual content, the instances. To continue working with a less crowded map, you might want to bulk select and hide the data model.
Custom Association Types¶
Custom Association Types are a different way of modeling associations. They are a powerful, semantic authoring tool that is unique to DMX. Custom Association Types are used to represent parent-child relationships when you create instances. Their semantics are carried over to all instances without you creating associations manually in each instance. At the same time you benefit from DMX’s model-driven form generator: The form you edit parent instances with will contain fields for all identity attributes of child instances. You thus get a form with all properties you want to add.
When to use Custom Association Types?
- If your data model contains a clear parent-child relationship Custom Association Types are the recommended way of modeling these relationships. This is the case when you need a child type to describe the whole entity. (For example you want publications to have authors, and authors are persons.) Create a Composition Definition between parent type and child type and add a Custom Association Type to it as described below.
- If your data model does not have a such clear parent-child relationship we recommend to create associations manually.
The same context as shown above can be modeled using a Custom Association Type.
- Create the topic types “Publication” (data type “identity”) and “Publication Title” (text).
- Reveal the built-in topic type “Year”.
- Reveal the built-in topic type “Person”.
- Create an association type called “Author”.
- Create an association between the topic type Person and the topic type Publication. Edit it and open the drop-down menu “Custom Association Type”. Select “Author” and click save.
Your Composition Definition looks like this:
This is your data model:
Use this model to create an instance:
- Create a person or reveal an existing one.
- Create a new publication by entering a title into the search/create dialog and selecting the topic type publication.
- Edit the publication.
- In the form you now have fields for the year and the author (first name, last name).
- When typing in a name, DMX’s autocompletion offers you existing person names that you can select. If the author you enter does not yet exist in the database, DMX creates a new person and directly adds the custom association “Author” between this person and the publication.
Creating a role type¶
Oftentimes when you create associations it is clear which of the two connected players is in which role: In the example above, the publication is the parent type and the title is the child type. There are cases though where you want to define your own role types because without them the relationship (or its “direction”) is not clear: This is likely needed when two players of the same type are associated. An example could be a hierarchical relationship between two persons like an employment relation. You would model the employment relation as an association type. But when you create instances of this association you would not see which player is in which role: Which person is the manager and which person is the employee? Here is how to deal with this use case:
- Create the association type “Employment relation”.
- Create two new role types called “Manager” and “Employee”.
Create your content, the instances:
- Create two persons.
- Create an assocation between them, edit it and select the association type “Employment relation”. Look at the in-map details: Both persons have the default role type. You cannot tell who is in which role.
- Edit the association again and edit the roles of both players. The role types you created are selectable from the drop-down menu.
This is what your result looks like:
Exploring the data model¶
You can explore the data model by revealing its parts in topicmaps. The topic types with all their properties (that is associations to other topic types) are saved in the database just like all your content. To understand how topic types and association types are built you can thus just navigate them.
To explore an example, we can once more refer to the built-in topic type “Person”. To look at the data model of a person, click onto an instance, e.g. a person you created and select “Related”.
- the organization you linked the person to
- the name of the person (because so far this is the only information you added to the person)
- the topic type “person”. Your concrete person is an instance of the general idea of persons, so it is linked to this general idea, the topic type.
- the topicmap this topic is associated with
- the workspace the topic is in
You can now click on each of the list items and they will appear on the topicmap. Click onto the topic type “person”. The topic type “person” is displayed with an association to the instance “Cathy Jones”. The link between both has a different color and you can again click onto the link, show what is related and you can see that this association is an “instantiation”: The topic is one instance of the topic type. To see if there are more instances (more persons), show the “Related” tab of the topic type “person”. Among other information about how the topic type is integrated into the rest of the context you can see all existing persons you entered so far.
Here you are looking at your data and at a part of the data model it is based upon. Again, you can hide what you do not want to see in your map when you are done exploring.
Visualizing edge connections¶
In the examples above you have seen nodes that are connected by edges, e.g. two topics (or topic types) that are connected by associations. This is not sufficient in a data model that is supposed to show real-world relationships. The associations themselves can be very complex and can have many properties.
With DMX’s associative data model, these complex associations can be modeled and they can even be visualized on topicmaps: They show as associations connected to other associations.
Let’s return to the example of a publication and its author: The authorship is a qualified description of the association between a person and a publication. If you look at the “Related” tab of such a qualified association you can see the connection between the association and and the association type:
Modeling patterns and pitfalls¶
How to model topic types with dates or time spans?¶
Let’s say you want to model plants. Among other properties, they shall have a blooming period. Here is how to proceed:
Create a topic type “Tree”. Edit it and change its data type to “identity”.
The data type “identity”
- Your tree is more complex than just a text field or a number: You want to add properties to it. You thus do not need a simple but a composite data type.
- You choose “identity” (not “value”) because upon a change of properties you still mean the same tree. You want to add, remove, or change properties, the number of properties might grow over time. By choosing the data type “identity” you tell DMX that regardless of those changes you will mean the same thing.
Create a topic type “Tree name”. It can keep the default data type “text”. Create an association between the “Tree name” and the “Tree”. By dragging from the child type (“Tree name”) to the parent type (“Tree”) you assign the right order on the fly.
Create a topic type “Blooming period”. Edit it and change its data type to “value”. Create an association between the topic type “Blooming period” and the topic type “Tree”.
The data type “value”
- Your blooming period is also more complex than a number. Even a single date (instead of a period with a beginning and an end) consists of more than a number, e.g. a day, a month, and a year. So you need a composite data type here, too.
- You choose “value” (not “identity”) because your data will just not stay identical when you change it. The blooming periods “April to June” and “June to July” are different blooming periods (even if they change for the same plant).
To add dates to your topic type “Blooming period”, just use the predefined date topic type: Search for it and reveal it on the topicmap.
Investigate it by looking at the in-map details.
In the next step you assign two dates to the topic type “Blooming period”: The start date and the end date.
Custom Association Types
You cannot create two or more associations of the same association type between two items. Use Custom Association Types to avoid errors.
Create the first association between the topic type “Date” and the topic type “Blooming period”. Edit the association and open the drop-down menu called “Custom Association Type”. Select “From”.
For the end date create another association between the topic type “Date” and the topic type “Blooming period”. Edit it, too, and select the Custom Association Type “To” this time.
Your data model now looks like this:
To check, create an instance, a tree, click edit, you now have a form for dates.
How to change the order of fields in a form?¶
You modeled a composite and when you created your first instance you saw that the fields are in the wrong order? You can fix it. DMX creates the form in the order you created the associations in when modeling. In this example we will change the order of the “To” and “From” fields:
Both fields are associated to a composite “Blooming period”. Edit that composite.
In the detail panel you can now drag the child types into the right order with your mouse.
How to unclutter the choice of topic types¶
When you have created many topic types for building composites you will notice that the drop-down menu for topic type creation fills up with topic types you might not need there.
To clean up, reveal a topic type you want to hide from the create menu on your topicmap. Open the detail panel by selecting “Details” from the context menu. In the detail panel switch to the fourth tab, the “View” tab and edit the View Configuration. Untick the “Add to Create Menu” checkbox and save the change.