Context Modeling Framework

What is Context in DUL?

DUL provides rich machinery for context-sensitive modeling—representing how facts and relations depend on:

Temporal context: When does this relation hold?
Conceptual context: Under what theory/frame is this interpreted?
Social context: Within what institution/agreement is this valid?

The primary mechanism is the Situation class and related patterns.

The Situation Pattern

Core Structure:

graph TB
    Situation -->|satisfies| Description
    Situation -->|isSettingFor| Entity

A Situation:

Includes multiple entities (via isSettingFor and subproperties)
Satisfies a Description (the conceptual frame)
Has a coherent identity as a contextualized view

Example: Coffee Preparation

Situation: "My coffee preparation this morning"

satisfies: Recipe Description (defines roles, tasks, ingredients)
includesAgent: Me (as baker role)
includesAction: Grinding action, brewing action
includesObject: Coffee beans, water, coffee maker
includesTime: This morning (8:00-8:15 AM)

The Situation unifies these entities into a coherent context, interpreted through the Recipe frame.

Descriptions: Conceptual Contexts

Description is the most important SocialObject subclass—it represents conceptualizations.

Types of Descriptions:

Practical / Intentional

Plan

A Description with an explicit Goal: it specifies how to achieve a desired outcome by defining who acts (Roles), what steps to perform (Tasks), and any constraints on execution (Parameters). Plans are inherently forward-looking — they describe a Situation that does not yet exist but is intended to be brought about. The OWL axiom someValuesFrom Goal captures this: every Plan must include at least one Goal component.

Key distinction: a Plan is a description, not an execution. The actual execution is a Situation that satisfies the Plan. The same Plan can be satisfied by multiple distinct Situations (different execution instances).

Example: a recipe defines Cook Role, Mixing Task, Temperature Parameter; an emergency evacuation procedure; a software sprint plan.

Plan subclasses:

Project A Plan with a subgoal structure and multiple roles and tasks, organized to achieve an overarching main goal. Projects are typically one-time and time-bounded.

OWL constraints: must define at least one Role and one Task.

Example: R&D project, construction project, software development project with milestones and deliverables.

Workflow A Plan that defines roles and tasks with a specific execution structure, typically supporting the recurring operations of an Organization. Differs from Project in being operational and repeatable rather than one-time and goal-bounded.

OWL constraints: must define at least one Role and one Task.

Example: invoice approval workflow, patient intake process, CI/CD pipeline definition.

Method

A Description that provides a strategy or approach for solving a class of problems, at a level of abstraction above any specific Plan. The key distinction from Plan is that a Method is implementation-agnostic: it says "how to approach this kind of problem" while a Plan says "here are the specific steps to take." Multiple concrete Plans can all follow the same Method.

Methods define the conceptual structure of a solution approach — the Roles involved, the kinds of Tasks to perform — without committing to specific sequences or parameters.

Example: the scientific method (Hypothesis, Experiment, Analysis, Conclusion as Tasks; no specific experiments mandated); agile development (Scrum and Kanban are concrete Plans following the same agile Method); the Socratic method (approach to philosophical inquiry).

Goal

A Description of a Situation that an Agent desires to bring into existence. Goals are the teleological anchor of Plans — while a Plan specifies the path, a Goal specifies the destination. The OWL axiom requires every Plan to contain at least one Goal component.

Goals can exist independently of plans: an agent can have a Goal without yet knowing how to achieve it. Conversely, the same Goal can be achievable through multiple alternative Plans. A Situation satisfies a Goal when its state of affairs matches the desired state described by the Goal — making Goals central to monitoring and feedback systems.

Example: "increase market share to 25% by Q4" (business KPI); system requirement "response time under 200ms"; a research question framed as a desired state of knowledge.

Functional / Structural

Design

A Description of an entity in terms of its structure and function, plus the rationale behind those choices. Designs typically describe entities-to-be-constructed, but can also describe "refunctionalized" entities (existing objects repurposed for a new function) or hypothesize unknown functions (reverse engineering).

The rationale aspect is what separates Design from a mere blueprint or specification: it carries the designer's intentional framework, explaining why the structure is as it is.

Example: an architectural blueprint with spatial rationale; an API design document with interface decisions explained; a policy document describing an institutional structure with its political reasoning.
DUL example: a cradle (physical object) satisfies a BabyFurnitureDesign; when repurposed as a flower pot, the same object satisfies a GardenDecorationDesign.

Relation

A Description that reifies a formal or informal relational structure as a first-order social object. Formal ontologies typically represent relations as predicates (second-order entities), but Relation in DUL allows a multi-argument relational structure to become a named, manipulable entity — a social fact that can be referenced, tracked through time, and situated in a context.

The mechanism: a Relation Description defines Role Concepts for each argument position; a Situation satisfies it by including entities that fill those roles. This is also why Theory's OWL axiom requires at least one Relation component — theories are fundamentally built on networks of relations.

Example: GivingGrantToInstitution (defines Provider, Grant, Recipient Concepts); Authorship (Author Role, Work Role, Date Parameter); Employment (Employer, Employee, Contract roles).

Relation subclasses:

Pattern Any invariance detected from a dataset or observation, or proposed from top-down considerations. Pattern recognition algorithms, machine learning, and human abstraction all produce Patterns. An occurrence of a Pattern is an observable Situation.

Example: a recurring behavioral pattern in user interaction data; a statistical regularity abstracted from sensor readings; a recurring narrative structure across stories.

SocialRelation Any social relationship — a Relation specifically grounded in the social sphere, holding between agents, groups, or institutions.

Example: friendship, authority, trust, kinship, organizational membership.

Interpretive

Diagnosis

A Description applied to an observed system state, typically to control normal behavior or explain abnormal behavior (OWL: "a notable behavior, e.g. a functional breakdown"). Diagnosing is intrinsically comparative: the Diagnosis implies a reference state (what is expected) against which deviations are measured.

The same observations can support competing Diagnoses depending on which descriptive framework is applied — making Diagnosis a paradigm case of context-dependent interpretation within D&S.

Example: a medical diagnosis (symptoms → disease description); software fault diagnosis (logs → failure mode description); an ecological health assessment interpreting sensor data against a baseline norm.

Theory

A Description that represents a set of assumptions for describing a domain, typically at a general and systematic level. Theories can be formal (scientific theories with axioms), philosophical (metaphysical frameworks), or commonsense (folk theories underlying everyday reasoning). The OWL axiom someValuesFrom Relation captures their systematic character: a Theory must be built on at least one Relation — theories are about how things relate, not just what exists.

DUL also uses Theory to represent "naturalized reifications" of logical theories: first-order representations of what would otherwise be second-order structures, necessarily incomplete but practically useful.

All other Description subclasses implicitly rely on some background Theory: a Diagnosis applies a medical or engineering theory; a Plan applies a theory of how actions produce effects.

Example: Newtonian mechanics (defines Force, Mass, Acceleration and their relations); criminal law theory (Crime, Punishment, Culpability); frame-semantic theory (which DUL itself models to describe lexical frames in FrameNet).

Narrative

A Description that organizes entities and events into a coherent sequential or causal story. Narratives impose temporal and causal structure on raw data — they explain how a state of affairs came to be by tracing a path from earlier events to current ones.

Unlike a Plan (forward-looking and prescriptive), a Narrative is typically retrospective and interpretive. Different Narratives can cover the same underlying events but attribute different significance to them (historical revisionism, alternative legal theories of a crime).

Example: a clinical case narrative (symptom onset → diagnosis → treatment → outcome); a crime reconstruction; an incident post-mortem report; a historical chronicle that establishes causal links between events.

Normative / Entitlement

Norm

A Description that specifies social rules, obligations, prohibitions, or permissions that ought to govern behavior within a social context. Norms are prescriptive rather than descriptive — not about what is but what should be. A Situation satisfies a Norm when the behavior of agents within it conforms to the norm's requirements.

Norms define Roles (who is subject to the rule), Tasks (obligated or forbidden actions), and Parameters (threshold values, time limits). They differ from Plans in that compliance is expected or enforced by an external authority rather than voluntarily chosen. The ODBASE paper notes that Norms can epistemologically "overrule" social practices — a legal norm can constrain a practice without having to describe it.

Example: traffic law (Driver Role, speed limit Parameter); a professional ethics code; a building code; an academic honor policy.

Contract

A Description of an agreement between at least two agents, each playing a Party Role, concerning a contract object — typically a Task to be executed by one or both parties. Contracts are mutual: they impose reciprocal obligations and rights on their parties.

Contracts have both normative and intentional dimensions: they function as Norms for what each party must do, and as expressions of the parties' Goals. The execution of contracted obligations is a Situation that satisfies the Contract. Contracts typically ground specific Rights for each party.

OWL note: must involve at least two Party Roles and at least one Task.
Example: employment contract (Employer/Employee roles, Work task, Salary parameter); software license (Licensor/Licensee roles, Permitted Use task); research collaboration agreement; international treaty.

Right

A Description of a legal or normative entitlement: one Agent (the right-holder) may demand something from another Agent (the duty-bearer) under stated conditions, with the entitlement backed by an enforcement mechanism — a Law, Contract, or other normative Description.

Rights are asymmetric, favoring a specific party — unlike Norms which govern all parties symmetrically. They differ from Contracts in that they can derive from Law rather than mutual agreement; the duty-bearer need not consent. A Right without an enforcement backing is merely a claim.

OWL constraints: must define at least two Roles (right-holder and duty-bearer) and at least one Task (what the duty-bearer must do or provide). This mirrors Hohfeld's jurisprudential right/duty correlates.
Example: property right (Owner Role, duty-bearer Role, Transfer Task); right to privacy (Citizen Role, State duty-bearer, Non-disclosure Task); patent right (Inventor Role, Licensee Role, Royalty Task).

The defines Relation

Descriptions define Concepts:

graph TB
    Description -->|defines| Concept
    Concept -->|isDefinedIn| Description

Example:

Recipe (Description) defines "Ingredient" (Role), "Mixing" (Task)
Traffic Law (Norm) defines "Driver" (Role), "Vehicle" (Concept)

The satisfies Relation

Situations satisfy Descriptions:

graph TB
    Situation -->|satisfies| Description
    Description -->|isSatisfiedBy| Situation

Example:

My coffee preparation (Situation) satisfies the recipe (Plan)
Today's traffic (Situation) satisfies (or violates) traffic law (Norm)

Classification: Concept-Based Contexts

Classification is a special Situation subclass for time-indexed classification:

graph TB
    Classification -->|satisfies| Description
    Classification -->|isSettingFor| Entity
    Classification -->|isSettingFor| Concept
    Classification -->|isSettingFor| TimeInterval

Why Classification as Situation?

Direct relation Concept classifies Entity is atemporal and acontextual. But:

Classifications change over time: "John is a student (in 2020), then a teacher (in 2024)"
Classifications depend on context: "This object is furniture (in museum), but art (in gallery)"

Solution: Reify classification as a Situation:

Simple: Concept 'Student' classifies Entity 'John' (timeless)
Contextual: Classification Situation satisfying University Description, including John, 'Student' concept, and TimeInterval '2020-2024'

Parthood: Mereological Contexts

DUL provides time-indexed parthood through the Parthood Situation:

graph TB
    Parthood -->|includesWhole| Entity_whole
    Parthood -->|includesPart| Entity_part
    Parthood -->|includesTime| TimeInterval

Why Time-Indexed Parthood?

Parts change:

"My bike has a luggage rack (since March 29, 2021)"
"This ship had a mast (until the storm destroyed it)"

Direct hasPart relation is timeless. Parthood Situation adds temporal context.

Multiple Parthood Relations

DUL distinguishes several mereological relations:

hasPart / isPartOf

Reflexive + transitive (classical mereology)
"The body has a brain as part"
"2024 is part of the 21st century"

hasProperPart / isProperPartOf

Transitive + asymmetric (irreflexive)
Strict parthood (part ≠ whole)

hasComponent / isComponentOf

Asymmetric (not transitive)
For designed systems with structural roles
"The car has an engine as component"

hasConstituent / isConstituentOf

Cross-layer parthood
Links entities from different ontological strata
"The person has molecules as constituents"
"The social system has persons as constituents"

N-ary Relation Reification

Standard ontologies struggle with n-ary relations (more than 2 participants):

Traditional: "John gave Mary a book on Tuesday" — how to model?

DUL Solution: Use Situation as a reified relation:

graph LR
    Situation_Giving -->|satisfies| GivingDescription
    Situation_Giving -->|includesAgent| John_giver
    Situation_Giving -->|includesAgent| Mary_receiver
    Situation_Giving -->|includesObject| Book_transferred_object
    Situation_Giving -->|includesTime| Tuesday_when

All binary relations project from the Situation via isSettingFor (and subproperties like includesAgent).

Advantages:

Arbitrary arity (any number of participants)
Add context freely (time, place, conditions)
Attach qualifications (degree, modality, evidentiality)

Practical Context Modeling Examples

Example 1: Role-Based Context

Scenario: "John is a professor at MIT in 2024"

Model:

Classification₁ (Situation)
  --satisfies--> AcademicStructure (Description defining 'Professor' Role)
  --isSettingFor--> John (Person)
  --isSettingFor--> 'Professor' (Role)
  --isSettingFor--> MIT (Organization)
  --isSettingFor--> TimeInterval₂₀₂₄

This captures:

What role (Professor)
Who plays it (John)
In what institution (MIT)
When (2024)

Example 2: Evolving Design Context

Scenario: "An old cradle is refunctionalized as a flower pot"

Model:

OriginalSituation (satisfying Baby Furniture Design)
  --isSettingFor--> Cradle₁
  --includesTime--> HistoricalPeriod
  --satisfies--> BabyFurnitureDesign (Description)
    --defines--> 'Cradle' (Role)

RefunctionalizedSituation (satisfying Garden Decoration Design)
  --isSettingFor--> Cradle₁ (same object!)
  --includesTime--> CurrentPeriod
  --satisfies--> GardenDecorationDesign (Description)
    --defines--> 'FlowerPot' (Role)

The same physical object (Cradle₁) participates in different Situations satisfying different Designs.

Example 3: Multi-Perspective Event Analysis

Scenario: "An avalanche that may have been triggered intentionally"

Model:

Event: Avalanche₁

PhysicalSituation
  --isSettingFor--> Avalanche₁
  --satisfies--> PhysicsDescription (natural forces theory)

LegalSituation
  --isSettingFor--> Avalanche₁
  --isSettingFor--> SuspectPerson
  --satisfies--> CriminalLawDescription (intentional causation theory)

Same event, two interpretations, both valid in their respective descriptive contexts.

Situation vs. Context (Conceptual Clarification)

Situation (DUL) ≈ Context (informal usage), but more precise:

Context (informal): Vague notion of "relevant circumstances"
Situation (DUL): Formal reification with:
- Identity (a first-order entity)
- Structure (isSettingFor relations to included entities)
- Interpretation (satisfies a Description providing meaning)

DUL's Situations enable context-aware reasoning:

What entities are co-present in a context? (Follow isSettingFor)
What concepts apply in this context? (Check Description that is satisfied)
What are the temporal bounds of this context? (Check includesTime)

Modeling Workflow

Identify Core Entities
- What are the main objects, agents, events in your domain?
- Classify as PhysicalObject, SocialObject, Event, etc.
Identify Conceptual Frames
- What theories, standards, or schemas organize your domain?
- Model as Descriptions (Plan, Norm, Design, Theory, etc.)
Define Concepts
- What roles, tasks, categories are defined by those frames?
- Model as Concepts (Role, Task, EventType, Parameter)
- Link via defines to Descriptions
Model Contexts
- What situations or contexts instantiate those frames?
- Model as Situations (PlanExecution, Classification, etc.)
- Link via satisfies to Descriptions
- Include entities via isSettingFor and specializations
Add Participation
- How do objects participate in events?
- Use hasParticipant and specializations
Add Mereology
- What part-whole relations exist?
- Choose appropriate parthood property (hasPart, hasComponent, hasConstituent)
Add Temporal/Spatial Info
- When/where do events occur?
- Use hasTimeInterval, hasLocation, hasRegion (for SpaceRegion)
Add Information Layer (if applicable)
- What information objects express domain concepts?
- Model InformationObjects and their realizations
- Use expresses, realizes
Refine with Parameters and Qualities (if needed)
- Add Quality-Region pattern for fine-grained attributes
- Add Parameters to Concepts for constraints
Validate Against Patterns
- Check that Descriptions define Concepts
- Check that Situations satisfy Descriptions
- Check that Classifications include Concepts, Entities, and Times
- Check that Properties have appropriate domains/ranges