Understanding 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. 

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:

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. 

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. 

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:

Name	Icon	Description
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.