Support for One-to-Many Document Annotations

Related products: Contextualization

Today the annotations used on PDFs in CDF only point to one resource. I.e. in a P&ID when clicking on a document annotation it assumes there is a unique object that represents that annotation. However, in reality there is a one to many relationship. Examples from ExxonMobil:

  1. P&IDs have the following structure, all are considered the latest revision which share the same short name used when being references in other documents, hence should be offered to the user as options for which document to jump to. E.g. FM-1234 in a P&ID should be linked to all the below:
    1. FM-1234 Revision X
    2. FM-1234 Revision X Markup 1
    3. FM-1234 Revision X Markup 2
    4. FM-1234 Revision X Markup N
  2. Isometric diagrams represent actual piping drawn at scale. Due to this, they can span several documents while still referenced in the P&ID with a common name. E.g. HT-1234 should link to all the below.
    1. HT-1234 section 1
    2. HT-1234 section 2
    3. HT-1234 section 3
  3. Time series tags in a diagram are referenced with the core tag name, e.g. PI-1234, but in the control system it is expanded up to have aggregated information or properties. These are often added as a post fix to the name used in the diagram. E.g. PI-1234 should link to all the below.
    1. PI-1234.HH
    2. PI-1234.LL
    3. PI-1234.Offset

The usual way to handle these situations is to group together the entities that are related, typical case being timeseries mapped to a sensor asset, and link to the object representing the group. I understand that there are obstacles in the way for doing that, and I think we should look into those, for now, I will elaborate on why we want to group entities together, as well as what the current possibilities are. 

 

The way to get multiple links currently without having a collection object to go via is to create multiple annotations on top of each other. The UI works so that if you click on a spot with mutliple annotations, you can page through them and see all the linked resources. 

 

On why we want to group objects that belong together and then only point to the groups from the annotation: 

Entities that belong together (e.g. different versions of a file) should be linked together if they are referenced in a document or not. If the grouping of entities is done once, it can be reused later. There will be a single place to update if new versions of documents come in and lower risk of inconsistent data. We dont want the annotation to be a source of truth for what elements belong to the referenced group, it should only tell which group is referenced. 

 

Grouping entities can be done in different ways, by explicit linking to a group object, or more implicitly, e.g. by making the entities share a metadata value. If it does not make sense for the customer data model to create explicit group objects, we might consider having annotations that provide a filter on a resource type so that a query can be performed. (e.g. list files with metadata.dwg_no == “FM-1234”). 

New→Gathering Interest

Hello spobri1, 

Thank you for your request. I hope the workaround Ola provided addressed your short-term challenge. While we understand that there's room for improvement in this workflow, it's not currently within our immediate focus. We've included this in our long-term roadmap for future consideration.

Once again, thank you for your valuable input.

Best regards,
Elka

Terms & ConditionsCookie Settings