Topic Management
Relations from Other Scenarios
- Logistics ← deliveries ← Topic Management
- Risk Tracking ← issues ← Topic Management
- Virtual Inspection ← issues ← Topic Management
Relations to Other Scenarios
- Topic Management → focus spots → UXV Recording
Summary🔗
This scenario is about providing a communication platform for BIMprove system.
Models🔗
topics🔗
This model lists all the available topics, topic boards and comments.
notification_protocols🔗
This model comprises all the defined and pre-defined notification protocols.
Definitions🔗
topic🔗
A topic is an issue, a problem or a communication thread.
It consists of a subject, a description and the comments.
A topic is associated with:
- exactly one requester,
- zero or one assignee,
- the creation time stamp,
- the dead line (as a time stamp),
- stage and
- zero, one or more labels.
A topic is accompanied with comments.
topic board🔗
A topic board (called "project" in BCF) is a collection of topics.
A topic board can have different access rights as well as different semantics.
For example, there is a special topic board for deliveries (from logistics).
requester🔗
The actor (from actor_management) who created/requested a topic to be focused on.
assignee🔗
The actor (from actor_management) who is responsible for a topic.
stage🔗
The stage is a phase or a milestone of a topic.
This is usually a stage in the building life cycle.
For example, "planning", "construction" or more fine-grained like a phase in the phase plan (from scheduling).
comment🔗
A comment introduces additional information about a topic.
A viewquery can be optionally attached to a comment.
Comments are usually free-form.
There are also specially structured comments. For example, we use comments to represent the status change of a delivery (from logistics).
viewquery🔗
A viewquery is an encoding of the camera position, the view angle and the query from "Virtual Inspection".
Note that the viewquery as we refer to here is not the BCF viewpoint as usually exported in a BCF. The BCF viewpoint is much sparser than viewquery.
BCF viewpoint🔗
This is the viewpoint as exported in a BCF.
This includes:
- camera position,
- selected objects (from bim3d (from evolving_plan)), and
- visible objects (from bim3d (from evolving_plan)).
BCF🔗
The BCF is a format for structuring topics as defined by building Smart: https://www.buildingsmart.org/standards/bsi-standards/bim-collaboration-format-bcf/
notifiee🔗
The notifiee is an actor (from actor_management) that is notified when there are new comments on a topic.
notification protocol🔗
The notification protocol specifies the notifiee as well as the channels used for the notification.
For example, notify person A over e-mail with severity high.
The protocol can also include an optional trigger (if late etc.).
The notification protocol is associated with a single delivery.
This is a non-IFC entity and lives in notification_protocols.
Scenario🔗
We use "Virtual Inspection", "Scheduling", "Truck guidance", "Risk Management" and other scenarios as "explorers" (or "browsers").
These "explorers" give us links to the instances and entities as identifiers (from unique_resource_identification).
References. We link the identifiers (from unique_resource_identification) through topics to structure the communication. This includes both the elements from bim3d (from evolving_plan) and bim_extended (from evolving_plan) as well as our BIMprove-specific entities such as risk (from risk_management).
For example, if there is a problem with a UXV (from uxv_recording), we can reference it with a identifier (from unique_resource_identification) in the topic's subject, description of a comment.
Management. BIMprove system provides an application for creating and managing the topics and adding the comments.
If a comment is attached a viewquery, the user should be able to follow it through to "Virtual Inspection".
The topic management does not provide the modification of a viewquery. If you need to modify a viewquery, you have to use "Virtual Inspection". For example, you can use an existing viewquery as the starting point.
The topic is assigned access rights based on individual actors (from actor_management) and/or roles (from actor_management).
The topic is also optionally assigned a notification protocol.
The management of notification_protocols is part of a separate application and the notification protocols can be referenced through identifier (from unique_resource_identification).
Topic from a task. The user can create a topic from an arbitrary task shadow (from scheduling) using "Scheduling".
There is also a more structured task-to-topic translation for specific tasks such as deliveries (from logistics).
Export to BCF. The topics are exportable to BCF.
The export can be either to:
- a BCF file, or
- directly to a BCF API.
Special care has to be taken to convert viewqueries to BCF viewpoints. For example, the query itself can be left as a string in the comment though it can not be included as-is in the BCF viewpoint. Additionally, the elements selected by the viewquery need to be converted to an explicit list in the BCF viewpoint.
Ingress of comments. If time permits, a nice-to-have: when a notifiee is notified, the notifiee can respond to a notification and the reply should be imported directly as a comment.
This is easy for e-mails (e.g. by including special fields in the e-mail header referencing the topic), and a bit more involving for SMS and other channels.
An example workflow with a viewquery. An example workflow for creating a topic involves:
-
Create the topic, write the subject and the description.
The subject and the description can include arbitrary references as identifiers (from unique_resource_identification).
-
Go to "Virtual Inspection" and select the relevant elements.
Use "Virtual Inspection" to create a viewquery and attach it automatically to the topic.
The aspect sections intentionally left empty.
Test Cases🔗
property-based test🔗
We automatically generate topics and assign them to actors (from actor_management) randomly.
We also randomly generate comments. Some of the generated comments have viewqueries attached.
The generated data should be of expected magnitude.
The generated data is frozen prior to ingress (e.g., before the API calls), so that we can reproduce the test.
We test that we can:
- list the tasks (from scheduling),
- list the comments,
- view the viewqueries etc.