Configuration of the default View in Search, and the order they appear in Search

Hi Gunnar. 

Appreciate this challenge and the confusion it causes. 

This is a challenging topic. Understanding how the views connect is not straightforward today, and there are ongoing discussions around how to make this easier to interpret programmatically. With the mapping pattern used in your organization, it is harder. It is also more challenging to determine how to group data, as we would need logic for whether a group-level aggregate/count would make sense through selecting a view as the “parent” of a group, vs allowing the creation of “folders” for views with a free-naming structure (not tied to views). 

If time permits, we could discuss this a bit during our scheduled call next week.

Best, 

Sofie, Product Manager

With the data modelling framework, most models will end up with a significant number of Views. Today we are not able to control the order the Views are presented in a good way. 
By reverse engineering it seems like the order of the Views is based on 

• The order of the (first mentioned) CDM extension in the model definition. Alle non-CDM Views are listed at the end, irrespectively whether it is listed before CDM or not 
• What is considered a CDM extension by the UI is not based on the implements, but whether it reference at least one property from one of the CDM containers
• Inside each Category (eg, a specific CDM extension, or the non-CDM Views), the order in the model definition dictates the order

If I choose alphabetic sorting it seems to only affect the non-CDM-Views, and not the order inside each CDM category. It do however put all the CDM categories first or last 

It is very inconvenient to use the order of appearance in the model definition as the way of sorting (we have to sort both the CDM extension, and then inside each category) since any change in the order will require pushing a new model definition to CDF.

We need the ability to define the order it appears in the UI, independent of how it is listed in the model definition, and we need to be able to create groupings that do not follow the CDM extensions. Eg, we have maintenance information that are not a CogniteActivity extension, that we still want to group next to the other CogniteActivity extended maintenance information.
The CDM based grouping is more relevant from a model developer point of view, and not that much from an end user point of view.

We also need the ability to define what is the default View. Right now it seems to be the first View in the model definition that is a CogniteAsset extension.

When changing location filer, it always reset to the (non-configurable) default, which we see create a lot of initial confusion with the users. 

Since the CDM Views are not explicitly described in our model, we do not see the CDM based grouping.

 

Hi Gunnar, the post was insightful. From my understanding then, is it not possible to reconfigure the ordering of the views (under a CDM) directly via the infrastructure toolkit? I noticed that the ordering of my views (under “assets”) is correctly done in the infrastructure code. The default preset location in my LocationFilter.yaml points to the correct data model, however the views are reordered.

Under the default:

Wanted:

1. Facility Owner
2. Facility
3. Slot
4. Activity Type

Hi Gunnar, the post was insightful. From my understanding then, is it not possible to reconfigure the ordering of the views (under a CDM) directly via the infrastructure toolkit? I noticed that the ordering of my views (under “assets”) is correctly done in the infrastructure code. The default preset location in my LocationFilter.yaml points to the correct data model, however the views are reordered.

Under the default:

Wanted:

1. Facility Owner
2. Facility
3. Slot
4. Activity Type

Hi

No, using a sorting based on the CDM extensions will not work since we want to group information that do not extend the same CDM view.

Eg:Our LCI information is split into several Views where only one can be a CogniteAsset extension (all Views are part of the same instance). The Views will then end up under the CogniteAsset grouping, and the “non-CDM extended” group.

Another example is documents where we have three views to organize versions and file formats

• RevisionFile: Extends CogniteFile and holds a specific revision for a specific file format
• DocumentRevision:  Extends CogniteDescribable/Sourcable and reference Revisionfiles with same version but different file formats
• Document: Extends CogniteDescribable/Sourcable and reference DocumentRevisions of the same document

These views will also be split into different groupings, CogniteFile extensions and the “non-CDM extended” group.

The CDM categories is not something that necessary makes sense to the end users. It would make much more sense to group into categories that follow domain and/or data types.

Eg (the examples are not necessarily well thought through, but illustrates the point):

• LCI
• M&I
• Documents