The introduction of Referencing

As part of our Distributed Integration concept, we proudly introduce a new functionality for Relatics: Referencing. Referencing dismantles the classic boundaries of Workspaces and brings information management to a higher level.

The concept of Referencing

With Referencing, it is easy to integrate information from generic sources, projects and central libraries. You use, enrich and build on information from other workspaces, as if this information is part of your own workspace. The possibilities are endless, for example: eliminating redundant information, creating central dashboards, managing ad-hoc information or adopting external information in its original markup.

The distributed character of our integration concept assures that workspaces are still autonomous entities. Users stay in charge of their own information and needs. They have flexibility on workspace level and at the same time they are able to create one coherent web with all information effectively shared. Refer to article Distributed integration for best practices and patterns.

The following sections cover the features that together form the Referencing functionality.

Pointer type and instances

Reference1 Relatics type elements (e.g. Requirement, Person or Document) have a new setting “Reference behaviour”. When set to “Act as pointer”, this defines instance elements as pointers that refer to a source.

As an example, we have “Project ABC” with activities and project members that are responsible for these activities. We can set the type “Project member” to act as pointer and make the project rely on the “Employees” workspace for its project members (refer to article Referencing – Step by step approach).

Reference2 When assigning “John Brown” to an activity for the first time, John is automatically created as a pointer element. The “John Brown” instance in the “Employees” workspace is called the referent.

New pointers are always based on a referent and a pointer cannot be created ‘from scratch’. Actually, a pointer’s existence is justified by its referent.

For end users, Referencing works rather straightforward and similar to web services. In the project workspace, users simply assign a responsible person, while they actually select from the “Employees” workspace.

To inform users of the project workspace that project members are actually pointers, icons show a green dot. This makes users aware of the pointer status and the fact that personal information of a project member is actually maintained somewhere else.

The most obvious application of the feature described above, is sharing generic information across many workspaces. For example, employees, generic documents, project roles and requirement categories can each be maintained in one workspace and effectively be reused in many workspaces.

In the example below, information about employees is centrally managed in one workspace.


This eliminates any duplication of addresses or phone numbers. The ability to distribute information ownership and information usage across multiple workspaces offers endless opportunities to improve information management. For example, large projects typically cover different specialist fields, each with its own information needs. A smart distribution of information across different workspaces, makes such a project more flexible and more adaptive to changing information needs. And by using Referencing, all information needs in each specialist field are still satisfied.

Another application is integrating external data with your own (project) workspace. Consider a large amount of requirements provided by the project’s client. Of course these requirements can be imported into the project workspace directly. As an alternative, you can simply store the requirements in a separate workspace in its original structure (e.g. a COINS structure). Then in the project workspace, you set up requirements as pointer elements referring to the original client requirements. By doing so, the project workspace can be adjusted as desired, while leaving the original client requirements untouched.

Extending pointers


Although pointer elements are based on a referent, they can still be enriched with their own information. Like ordinary elements, pointer elements are allowed to have their own properties and relations. If additional information is desired, the pointer type can be extended like any other element type.

After extending a type, information that is only ‘locally’ relevant, can be maintained exactly in the place where it belongs. For example, personal information that is only relevant for members of project ABC can be maintained in the “Project ABC” workspace without affecting the “Employee” workspace.Reference5

Extending also enables users to create temporary workspaces for ad hoc analyses or short term information needs. Suppose that a company wants to manage which employees receive only a Christmas card by the end of the year, and which employees receive a complete wine box. Formerly, information like this was stored in the“Employees” workspace. With Referencing, the temporary information can be stored in a separate workspace “Christmas” without cluttering up the “Employees”workspace.

After the cards and wine have been sent, the workspace can be deleted. Again, because “Christmas” is a separate workspace, this disposal does not affect the “Employees”workspace.




The referent elements that pointers are based upon, do not necessarily have to come from a single source; a pointer type is allowed to have multiple sources. This feature enables the integration of separately managed sources like document containers, internal and external requirements or several parts libraries into one set of pointer instances.

For example, end users might want to select from both employees and freelancers when assigning responsible persons to project activities. This is achieved by setting up the “Project member” pointer to have two referents “Employee” and “Freelancer”.

Source libraries

In order to create pointer elements based on referent elements, reference sources need to be defined. This is accomplished in a way similar to defining pointer elements. Instead of “Act as pointer”, the reference behaviour of a Relatics type element is set to “Act as referent” (refer to article Referencing – Step by step approach). This setting makes the instances available to other workspaces in the Relatics Environment.


Where pointer elements cannot be created from scratch, a referent element cannot be deleted if there is any pointer element that references the referent element. If employee “John Brown” (which is referent) is also project member (pointer) in any workspace, John cannot be removed from the “Employee” workspace.

Use the “Find Pointers” option to see which workspaces contain a pointer to a given referent.

It is even possible to set a type element to act both as pointer and as referent. In the example, type “Employee” acted as referent. When set up as ”Act as pointer and referent”, we can make the “Employees” workspace draw from a third, even more generic “Name-Address” workspace containing all contacts. In this way stacked configurations of Referencing are supported.

Security & integrity

To prevent unwanted referencing and querying of other workspaces, a security layer is introduced. Workspaces now have setting “Entry code” that, if specified, enables the workspace to be used as a source. Other workspaces need this entry code before they can access the source.

Additionally, an integrity feature is introduced to manage unwanted inconsistencies between workspaces. Inconsistencies might occur after uploading or reconfiguring a workspace. Appropriate feedback is an incentive for end users to repair these inconsistencies.


For example, consider Project DEF that has maintained their own project members. In order to link workspace “Project DEF” to the “Employees” workspace, the behavior of type “Project member” is switched to “Act as pointer”. As a result each of the employee instances turns into a pointer. But these pointers inevitably start as invalid pointers, because according referents are not yet determined. Inconsistency like an invalid pointer is indicated by a warning. Users should repair inconsistency and get rid of warnings, before continuing to work in the workspace.

Another scenario that might result in warnings, is the upload of a workspace. Note that during the ‘offline’ period of the pointer workspace, a referent can be removed from the source workspace. After uploading, the according pointer is invalid and should be repaired. A third scenario that results in warnings is when a pointer workspace switches from one source to another. A referent in the old source, might no longer be available in the newer version of the source.

Release date

Released on December 22, 2015.