Context Models: Giving Data Its Operational Meaning

What a Context Model Means

Foundational research on context-aware systems understands context as information that can characterize the situation of a relevant entity. An entity can be a person, place, or object that is relevant to the interaction between a user and an application.^[1] For operational processes, this general idea needs to be made more precise: Which contextual details change the meaning of a record or determine whether it applies in a specific situation?

A context model answers this question structurally. It defines which kinds of context are distinguished, how they are connected, and the period or scope for which a statement applies. This creates a foundation for Process Intelligence: observed relationships can be meaningfully compared and used later only if the conditions under which they arose remain identifiable.

The model itself is neither an analysis nor a decision. It provides the frame of meaning within which data can be analyzed, rules applied, and guidance assessed.

Example: A Measurement Value in a Batch Process

An illustrative case: During the same production task, 18.4 °C is recorded twice. Sensor R measures the air in the workroom. Probe P measures the temperature of the product being processed. The number, unit, and time match; the observations nevertheless answer different questions.

For the room value, the workroom is the observed object. The batch belongs to the accompanying work context. For the product value, by contrast, the product itself is the subject of measurement. The context model must keep these references separate and assign the respective measurement location and method.

A check of product temperature must not use the room value as a substitute merely because the numeric format matches. That would require a separate derivation justified in domain terms. Nor does an appropriate room temperature imply that the product temperature is within the intended range.

For a later comparison, observations of the same object and property are therefore selected first. Only then can further conditions such as process phase, measurement method, and applicable requirements be compared. The same numeric value is not a sufficient similarity criterion.

Identical Numbers Are Not Yet Comparable Observations

In the 18.4 °C example, the numeric value, unit, and time match. Yet the room sensor answers a different question from the product probe. An additional “Location” field does not resolve this difference if it remains unclear what was measured.

The context model must therefore first express the object and property of the observation. Conditions relevant to the purpose, such as process phase and measurement method, are then added. A flat table can model these references just as explicitly; their meaning, not the form of representation, is decisive.

Observation, Result, and Reference Object Must Remain Separate

For measurement and sensor data, context consists of more than a value and timestamp. It must be possible to distinguish which property was observed, which object has that property, which procedure or sensor was used, and which result arose from it.

The W3C SSN/SOSA Recommendation models observations, sensors, observed properties, features of interest, procedures, and results, among other concepts, for this purpose.^[3] This separation prevents the temperatures of a room, a piece of equipment, and a product from being treated as equivalent merely because their numeric values are similar.

Manual observations also need such a frame of reference. If the condition of a material is assessed visually, the system should distinguish between the observed property, the assessment method used, the recorded result, and the responsible person. Only then can a later analysis identify which observations are actually comparable.

Observed and Derived Context Are Not the Same

Some context is captured directly: a person confirms a task, equipment supplies a measurement value, or a system logs a state change. Other information is derived. Several signals may support an inference, for example, that equipment was operating or a process phase had begun.

The context model should therefore indicate whether a statement was observed, entered manually, taken from master data, or derived by a rule or model. For derived statements, the inputs used, rule version, and time of derivation also form part of the context.

A derivation is not automatically wrong or weaker. It does, however, answer a different evidential question from a direct observation. If the two are stored without distinction, a later review can no longer identify where the original information ends and the system's interpretation begins.

Context Changes with Time and State

Operational context is rarely static. An SOP is replaced, a person changes roles, equipment receives a new calibration, and a batch moves from “in process” to “on hold” or “released.” A current master-data view must not retroactively apply current conditions to historical operations.

The context model must therefore distinguish when information was recorded from when it applied. Today's active SOP version is not necessarily the version under which a task was performed yesterday. Likewise, a material may have been assigned to a different storage location or status at the time of measurement than at the time of a later analysis.

Reliable comparisons therefore require versioned relationships. They record which context belonged to a specific operation, even if roles, rules, or objects change afterward. Without this temporal link, an apparently complete but historically incorrect picture emerges.

Versioned Knowledge Models preserve which model version was identified, approved and applied at a given time.

Relationships Hold the Context of Meaning Together

Context arises not only from properties but above all from relationships. A person performs a task. A task uses a material. A measurement operation observes a property of a sample. A result is checked against a particular specification. A release refers to a specific product state.

For provenance relationships, W3C PROV provides entities, activities, and agents, as well as usage, generation, and responsibility relationships, among other concepts. The model is domain-independent and explicitly extensible, allowing application-specific information to be added.^[2]

A context model can adopt such general relationship patterns and extend them with operational concepts. This can preserve, for example, that a task consumed a particular material, produced a new batch state, and was performed by an authorized person under an applicable work instruction.

Data Provenance focuses primarily on the origin, creation, and modification of information. Here, by contrast, the focus is on the situational scope in which information applies. The questions can overlap; this does not imply a general hierarchy between a context model and provenance.

Dimensions Needed in an Operational Context

The context required depends on the question. Several dimensions are typically relevant to regulated product and batch processes:

• Object context: The batch, material, product, sample, document, equipment, or resource to which information refers.
• Process context: Task, process phase, preceding action, result, and subsequent transition.
• Person and role context: The identity performing, reviewing, or releasing, and the role exercised in doing so.
• Time context: Recording time, validity period, sequence, and, where applicable, the start and end of an activity.
• Location and system context: Operational area, production equipment, device, application, or interface in which the information arose.
• Rule context: Applicable SOP version, specification, permission, review rule, or release requirement.
• Condition context: Temperature, humidity, energy consumption, material property, or another relevant condition.
• Assessment context: Review, deviation, rework, rationale, and substantive decision.

Not every record needs every dimension. A good context model therefore does not enforce maximum data collection. It determines which relationships are required for a specific purpose and which remain optional.

Checking Context Against Its Intended Use

In the example, simply having any temperature value is insufficient for a product assessment. The review must ask whether it belongs to the intended measured object and procedure. If this reference is missing, the application should make the uncertainty apparent instead of silently substituting the room value.

Structural rules can check required relationships, for example using SHACL.[5] Whether the selected contextual details suffice for the substantive use must be assessed separately. Unnecessary details increase data-entry effort without closing this specific gap.

From Key-Value Pairs to a Semantic Model

Context can be represented in different ways. Simple key-value pairs are suitable for manageable details such as “Room = Production 2.” Hierarchical structures can represent nested relationships. Relational data models organize information through tables and keys. Graph models place objects and their relationships directly at the center.

Knowledge Graphs are suitable when specific objects, events, people, and conditions need to be connected and queried across many relationship types. The graph must not, however, be equated with the context model: it is one possible form of representation, while the context model defines which situational relationships matter in domain terms.

Ontologies can formally define concepts, classes, and relationships. OWL 2 provides classes, properties, individuals, and logically defined meanings for this purpose.^[4] Not every context model has to be an ontology. An ontological design can nevertheless be useful for shared semantics and machine inference.

Describing and Using a Situation Remain Distinguishable

The table, graph, and ontology forms described above answer the question of representation. The context model, by contrast, determines which situational differences are relevant. Its subsequent use must define how to respond to appropriate, missing, or contradictory context.

In the temperature example, the model describes the measured object. Whether a missing product value triggers a clarification request, an additional measurement, or an interruption is a separate application decision.

Context Limits When Knowledge Applies

An operational model of insights should not merely store that a measure was associated with a good result in the past. It must also record the conditions under which that experience was gained and the situations for which it has been reviewed.

Operational knowledge models use this context of applicability to connect knowledge to specific tasks, states, and decisions. The context model supplies the descriptive foundation. The operational knowledge model adds rules for use, approval, and application.

This can prevent experience from product A from being transferred to product B without review, or a statement from a particular equipment configuration from being treated as universally valid. Context does not automatically make knowledge correct. It makes its scope understandable.

What a Context Model Does Not Provide

• It does not automatically capture every relevant influence. Conditions that are not modeled remain invisible.
• It does not prove factual correctness. Formally complete contextual information can be wrong in substance.
• It does not justify unlimited data collection. The scope of collection, purpose, permissions, and retention must be appropriately defined.
• It continues to require maintenance. New process variants, rules, and object types can require extensions to the model.

Comparison Begins with the Subject of Observation

The two values of 18.4 °C are not interchangeable. Only the question of the measured object and property determines whether they may be considered together for a particular analysis. Further conditions can additionally restrict this comparison.

A good context model preserves precisely the distinctions that justify such decisions. It also indicates when information is missing or merely derived. This keeps the scope of an observation visible.