Datamodel

This page tries to answer all OPH's data-related questions. What data is used/created? Where does data come from? When is data created/consumed?

he data Open Proces Huis relies on, can broadly be divided into two categories:

A. OPH-specific data: generated by and unique to the application

B. Data that's imported into the application: mainly covers all user-related data

More information on each category is provided in the following information.

A. Process Data

What?

In essence, OPH is a large database of processes. Each process has a title, a description, an email and a status. It also contains multiple files.

The process itself has the dpv:Process class. We used to have https://data.vlaanderen.be/ns/proces# This was a URI that was based on the OSLO standard, but this class didn't exist yet. For this reason we went looking for an appropriate class. We chose for https://w3id.org/dpv#Process because this ontology fits our use case the best. From the DPV page: "The motivation of DPV is to provide a 'data model' or an 'ontology' of concepts for interoperable representation and exchange of information about processing of (personal) data and the use of technologies. For this, the DPV specification defines concepts and relationships using the [RDF] standard, and which can additionally be implemented and applied using technologies appropriate to a use-case's specific requirements."

The process status can be empty or http://lblod.data.gift/concepts/concept-status/gearchiveerd. The latter is set when a user removes a process, in fact archiving it.

Each file has a name, format, size, extension and status.

The file status can be empty or http://lblod.data.gift/concepts/concept-status/gearchiveerd. The latter is set when a user removes a file, in fact archiving it.

Based on the file extension, a distinction is made between diagrams and attachments. All files with a bpmn extension are considered diagrams, while all others are considered attachments.

A process can have multiple diagrams (i.e. BPMN files), but it needs at least one. The most recent diagram (cfr. created attribute) is the main diagram (and shown in Open Proces Huis), while the older ones are considered historical versions.

Each BPMN file is kept as is, but its content is also stored as linked data. A BPMN file contains one or more BPMN processes, with each BPMN process containing multiple BPMN elements. The BPMN Based Ontology (BBO) is used to represent all these BPMN processes and BPMN elements as linked data.

A process always belongs to a group/bestuur (i.e. administrative organization). The User Data paragraph goes into more detail on this.

The following image visualizes the model used by OPH to store all process-related data:

Where?

Open Proces Huis is the sole point of origin for the above discussed process data (except for group records, see User Data - Where?).

The application relies on the openproceshuis-bpmn-service for the creation of process-related records. For a given BPMN file, it runs through all its elements and for each of those, creates the necessary BBO triples.

When?

Process-related data is always created through the actions of a user.

To create a process, a user should upload a BPMN file. By default, the process's title is set to the file's title, but without the .bpmn extension. The title of the process can be changed in Open Proces Huis if wanted. The file's title will remain as it was when uploaded. The process's description can be set afterwards.

Each time a BPMN file is uploaded (either on creation of a new process, or when updating an existing one), the openproceshuis-bpmn-service is kicked into action. This generates and stores the BBO triples, as well as the links to the original BPMN file and the user's group.

Statistics

Whenever a process is created, a statistics object will be created for the process as well. In this object we will keep track of the following data:

Total process views
Total downloads
Downloads of type .bpmn
Downloads of type .vsdx
Downloads of type .svg
Downloads of type .png
Downloads of type .pdf

ICR metadata

Every uploaded process has the option to be designated as a blueprint. A blueprint is a standardized process that can only be approved by ABB or Digitaal Vlaanderen admins. To qualify as a blueprint, a process undergoes a rigorous evaluation based on a custom cybersecurity framework. Once a process is officially marked as a blueprint, additional metadata is assigned, capturing the results of this assessment.

The additional metadata includes values that describe:

Confidentiality score
Integrity score
Availability score
If process contains personal data
If process contains professional data
If process contains sensitive personal data
Additional information
Has control measure (A URL linking to a confluence page)
If process is marked as blueprint

Inventory data

OPH's inventory holds a series of processes that have no implementation, so-called conceptual processes. They only hold a title, and are assigned to a category, domain and group. The inventory is available to all users but is managed solely by admins. Users that are part of a local government can mark a regular processes as being an instance of a conceptual process found in the inventory.

B. User Data

What?

All process-related data originates from users. Therefore, OPH needs the necessary data for users to log in, as well as organizational data to provide the link between users and processes.

A user has a first name, a family name, one or more accounts and one or more groups/besturen.

An account contains the necessary data to log a user in. In OPH this can happen either through ACM/IDM.

A group/bestuur (i.e. administrative organization) has a name, a classification and a primary site.

The classification indicates the type of a group/bestuur (e.g. gemeente or OCMW).

The primary site describes the location a group/bestuur operates from.

Notice the difference between the group/bestuur's email (present in its primary-site contact information) and the process's email. The first is fixed and might be too broad of a contact point for questions/remarks about a single process, while the latter can be set manually and more directly lead to the person in charge of the process.

The following image visualizes the model used by OPH to store all user-related data:

The user data model is equivalent to how user data is stored in other LBLOD applications. It is based on the Besluit Publicatie OSLO application profile, and uses elements from the Persoon OSLO vocabulary.

Where?

Open Proces Huis gets its data from Organisatie Portaal (OP). The application uses the LBLOD delta consumer to import user data. Custom configurations indicate which parts of that original data should be stored in the OPH triplestore. One configuration is used for initial ingest (on first startup of the application), another is used for delta messages (these describe deletions, additions or updates to the initial data).

OP offers more data than is actually ingested in OPH. The consumer is configured to only ingest the data it needs. For clarity: all data described in the user data model, is actually ingested and therefore present in OPH's triplestore.

When?

The initial ingestion of OP data happens on the first startup of the application, with 'first' indicating the triplestore does not yet contain any of that data.

Throughout the application's lifespan, the delta consumer fetches the latest delta messages (if they exist) on regular intervals. OPH is configured to do this every minute.

Application profile

Class: Proces

Type

Klasse

URI

A. Process Data

What?

Where?

When?

Statistics

ICR metadata

Inventory data

B. User Data

What?

Where?

When?

Application profile

Translations