Back to ontology

Table of Contents

Actor Management

Relations to Other Scenarios

Summary🔗

This scenarios covers how the actors are managed in the system, their roles and their relationships to other entities.

Models🔗

Intentionally left empty.

Definitions🔗

actor🔗

Actors are entities corresponding to people and organizations (legal, non-legal, imagined etc.).

The granularity of an actor is variable:

Some common actors include:

The actors are represented using corresponding IFC entities such as:

The contact information about the actor is modeled as IfcTelecomAddress in Addresses property.

relationship🔗

An actor can be linked to many other entities in bim3d (from evolving_plan) and bim_extended (from evolving_plan).

The relationships are modeled by using corresponding IFC entities such as:

role🔗

The role of an actor in an arbitrary context, not necessarily information security context.

Scenario🔗

As-planned🔗

The actors and their relationships (as well as relationships between the actors to other entities) are captured in bim_extended (from evolving_plan).

The system provides an application that allows the user to manage the actors and their relationships.

This application should allow creating and viewing arbitrary relationships and actor s.

In contrast, more specific applications, such as those implemented for "Risk Management" and "Truck guidance", should allow creating and viewing of the relationships in the manner more appropriate for the context of the application.

Additionally, this application is not a replacement for a much more low-level tool like explorer (from evolving_plan).

(Note for implementation. For example, we can use Express or XSD to generate the code and the relevant part of user interface automatically. See this buildingsmart table .)

(Note about the relationships: We need to decide how we structure them. We might allow free-form relationships, but they should not conflict with our internal relationships such as assignment (from risk_tracking). This is something that needs to evolve during the implementation and iterations of the system.)

(Note about the roles: there are special pre-defined roles, such as preventive resource (from risk_tracking), that have consequences in terms of information security.

How we handle this pre-defined set of these roles with special semantic is left out as an important implementation detail. We could not decide right now, 2021-01-15, how it should be handled.

For example, there might be a separate application, "role management", where you can add new roles, but a certain set of pre-defined roles can not be changed/removed. Additionally, the user should be warned if she creates a role with a similar name to the existing one (e.g., with or without underscore).

The system might provide a set of common, frequently-used roles at instantiation time of the system. These common roles, however, can be modified/removed.

Check also DICO agents for an example of pre-defined roles and relationships, capabilities etc. Perhaps we can map the interesting bits to IFC classes and use them to initialize the system.

Additionally, we can introduce these entities in bim_extended (from evolving_plan) as IFC "shadows" where we lock them and do not allow a user to modify them, similar how we plan to deal with roles conveying special semantic.)

Actor list import. The system should provide an import of the complete list of actors from external sources. (For example, an excel table or from Visilean.)

This import is not a complete overwrite, but an extension to the existing actors.

The mapping of actor identifiers to the existing identifiers is the responsibility of the individual import tool.

The remaining aspect sections intentionally left empty.

Test Cases🔗

blank state🔗

We test that the actor management works on empty data.

We install the system and do not populate anything.

recorded state🔗

We record the data of a toy project.

We freeze the data.

We pre-define a set of actions (such as insert a new actor, create a new role, assign an actor to a role or to an organization etc.).

We record the effects, so that we can repeatedly test the behavior of the system in automatic way.

big data🔗

We generate automatically the data of a toy project to test that the system can handle the magintude.

We only check if nothing crashes and perform a set of pre-defined actions.

(Implementation note: use a tool for property-based testing to generate data such as https://en.wikipedia.org/wiki/QuickCheck)

Acceptance Criteria🔗

magintude🔗

We expect the system to handle the number of actors in the order of thousands (not millions).

We also expect the number of relationships to be in the order of tens of thousands (not in millions).