Tags provide a mechanism to attach labels or categories to data items such as worksheet records or documents in Opus 2 Platform.  There is one project-wide set of tags so the same tag can be used in different contexts. Tags provide the main cross-cutting mechanism to associate content from different sources with the same concept.

Because tags are not specific to any particular area within platform, the dialog to manage them is raised from the project button which appears on all pages within the project. 


Provided the user has this capability enabled, which can be managed by the assigned system admin users, the first option of the project button drop down is ‘Manage tags’. Here, users can find option to:




Add tag

Create and define a new tag.

Export tag as spreadsheet (xlsx)

Allows users to export the tag as a spreadsheet.

This is can be used in conjunction with the ‘Import tags’ tool if users want to copy across a tag set into another project.

Import tags

Allows users to digest tags from .xsl/.xlsx/.csv formats.


Remove a tag from the list - this will remove the tag from already tagged documents.



The data stored about an existing tag will be displayed in the right panel if the user highlights that tag. A tag can be created with the following elements: 

Element of tag



Required - Name of the tag, usually describes its purpose.

A tag cannot be created without user input in this field.


Optional - Users can select icons from a built in icon library.

If not selected, a simple tag icon is used by default.


Optional - Users can select a colour from using a predetermined catalog of company colours (if set up), hex numbers, RGB value, or the colour gradient sliders.

If not selected, tags are coloured mid-grey by default.


 Optional - Users can set the location of the tag at either the ‘Top level’ or ‘Nested’ beneath a selected tag or subtag.

If not selected, the location is set to ‘Top level’ by default.


Simple use of tags

At its simplest, a tags list may just be a flat heterogeneous list of all the tags that a user wishes to use. For many solutions, this level of structure may be sufficient. However, as the concepts to be expressed become more complicated it may be useful to separate the tags to group them in various ways. For this use case, tags can be nested in a hierarchy with some tags located as children (or subtags) of other tags in a tree-like structure. Users can find this structure in the Tags panel. Tags can be nested under other tags up to ten levels deep.

To apply tags to worksheet records or documents a "Tags" metadata field must be added to the worksheet definition or document fields set. Optionally, this can be set to allow selection only from a sub-tree of the main tags tree. This allows the creation of different collections of tags for particular purposes. When applying a tag, an auto-complete mechanism makes it easy to find a particular tag without scanning the whole list. 

Nesting and ontologies

Strictly speaking, Platform does not support ontologies in the general sense. It just provides a hierarchy of terms that the user must add their own interpretation to: there is no representation of the relationships between terms or what the nesting means. But frequently that is obvious from the context so the hierarchy itself is sufficient. 

For example, a car dealer wishing to document their car collection in platform might start by setting up a tag structure such as this:

  • Britain . . . 

  • Germany

    • BMW

    • Volkswagen Group

    • Mercedes Benz

      • C-Class Saloon

      • GLB SUV . . .

  • Japan . . . 

Then, for each car they could tag it with the company it comes from. They could then add another level and add an appellation if required. Or they might go further than the example above and include the year of manufacture as another layer of classification. Depending how enthusiastic they are, this structure could grow to thousands of entries. Tags in platform are designed to support this comfortably.  Once the hierarchy is set up, the next question the user faces is how to actually use it. If the user has a GLB SUV, should they tag it "GLB SUV" and "Mercedes Benz" and "Germany", or just "GLB SUV"? Or would they want a mechanism to automatically apply the ancestor tags when they apply a tag further down the tree?  

This might seem useful, as they could then filter their cars by "German" to find all the German ones, or by a particular company to find all the cars from that company. However, in platform this kind of duplication of information is discouraged. Suppose when creating the initial hierarchy they had erroneously put "GLB SUV" under "BMW". Then every GLB SUV would also be tagged "BMW" which would then need correcting.   This concern is known as the "single source of truth" principle in software development: each piece of information should only be stored in one place and other uses should derive from that rather than replicating it.

But the desire to find all the cars from BMW is still a valid requirement, so how do we do that if they are not actually tagged with that value? The platform solution is to do this by enriching the query rather than modifying the data. In this particular case when selecting a tag for a filter it is easy to automatically select all the sub-tags.  Other requirements are handled in a similar manner. For example, suppose the user adds a worksheet of pricing, where each record includes notes about a particular car. Then they may wish to pull up all notes about GLB SUV’s. Rather than propagating the tags through and applying them to the pricing directly, the worksheets model supports derived fields to display them dynamically and the ability to filter on properties of remote records. 

Mixed hierarchies

In the example above, if the user is only using tags for labelling cars, then it makes sense to make all tags available when picking a tag for a car. But perhaps they start collecting motorbikes too and wish to do the same thing for motorbikes.  They could start a new project, but maybe they are concerned about price differences between cars and motorbikes from various brands and want to start a worksheet for that. Then, they could add two new top-level tags "car" and "motorbikes" say, move all the car countries under "car" and start a parallel tree for “motorbike”. Then when tagging a car, it is unhelpful for the user interface to present both the car and motorbike tags to them since we know that at that point they can only be wanting to pick a car tag. For this purpose, anywhere a tag field is used, the project designer can set a particular root tag so that only tags below that can be selected as values for the field.  Thus, although there is only one set of tags for the project they may be split up into multiple different hierarchies such that any particular context only uses one of those hierarchies. 

Tags view panel

The tags view panel is one section of the left folders panel. This section lists every existing tag and subtag. It allows users to filter their view of documents to only those documents which have been tagged with the selected tag. This filter does not recognize or therefore show any instances of the tags within any documents or worksheets themselves, only tags that have been applied to the document as a whole. 

Users can interact with the tags view panel through the single and double chevrons, as well as the tick boxes that appear next to each listed tag:





Single down chevron


Collapses the view of the related tag hierarchy/section

Single right chevron


Expands the view of the related tag hierarchy/section

Double down chevron


expands every tag and subtag within the section

Double up chevron


Collapses every tag and subtag within the section back to the first level of tags

Tick box


Selecting a tag via the tick box allows users to filter their view to show only documents that have been assigned the selected tag.