You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@ossie.apache.org by "FactEngineCommunity (via GitHub)" <gi...@apache.org> on 2026/07/28 02:09:55 UTC

[D] Proposal: Representing reified relationships as Entity Types [ossie]

GitHub user FactEngineCommunity created a discussion: Proposal: Representing reified relationships as Entity Types

## Proposal: Representing reified relationships as Entity Types

Consider this business fact:

> Part is stocked in Bin at Warehouse.

Initially this may be modelled as a relationship among `Part`, `Bin`, and `Warehouse`. The business may then need to record:

> StockedItem has Quantity.
> StockedItem was counted at DateTime.

The original relationship now needs to be addressed as an object in its own right. We might call that object `StockedItem`.

This is **relationship reification**: treating an instance of a relationship as an entity so that it can have its own properties, participate in other relationships, and be referenced independently.

The pattern appears in many modelling approaches:

- In a relational model, it commonly becomes an associative or junction table with foreign keys to the participating tables and additional columns of its own.
- In a graph database, it may become a node type connected to the participating nodes, particularly when the relationship needs an identity or must participate in further relationships.
- In conceptual modelling, it may be called a reified relationship, relationship entity, association object, or association class.
- In Fact-Based Modelling and Object-Role Modeling, it is commonly called an **objectified Fact Type** or **nested Fact Type**.

This proposal leads with the generally applicable idea of reification. Objectification is included as secondary terminology for interoperability with modelling systems that use it.

## Another example

A cinema system may begin with:

> Film is shown at Cinema at DateTime.

Once the showing needs a ticket price, capacity, screen, booking collection, or cancellation status, the relationship is naturally reified as `Session`:

```text
Session represents:
Film + Cinema + DateTime

Session has TicketPrice
Session is held in Screen
Booking is for Session
```

In both examples, the reified relationship has two aspects:

1. It is an Entity Type that can participate in further relationships.
2. It retains the ordered participants and natural-language readings of the relationship it represents.

## The apparent Ossie representation gap

Ossie can already represent most of this:

- `StockedItem` can be an `EntityType`;
- ordinary Ossie relationships can connect it to `Part`, `Bin`, and `Warehouse`;
- it can participate in further relationships such as `StockedItem.has_quantity`; and
- `verbalizes` can preserve natural-language readings.

What appears to be missing is a machine-readable statement that these elements form one reification:

- `StockedItem` represents the fact involving `Part`, `Bin`, and `Warehouse`;
- those participants have a defined order;
- each participant corresponds to a particular relationship from `StockedItem`; and
- readings such as “Part is stocked in Bin at Warehouse” describe the reified relationship as a whole.

Without that statement, a consumer sees an ordinary Entity Type with several relationships. It cannot reliably distinguish a reified relationship from any other Entity Type with a compound identifier.

## Candidate YAML

One possible representation is an optional `objectifies` member on the reifying `EntityType`:

```yaml
version: 0.2.0.dev0
name: WarehouseOntology

ontology:
- concept: Part
type: EntityType

- concept: Bin
type: EntityType

- concept: Warehouse
type: EntityType

- concept: StockedItem
type: EntityType

objectifies:
roles:
- concept: Part
relationship: StockedItem.part

- concept: Bin
relationship: StockedItem.bin

- concept: Warehouse
relationship: StockedItem.warehouse

verbalizes:
- "{Part} is stocked in {Bin} at {Warehouse}"
- "{Warehouse} stocks {Part} in {Bin}"

relationships:
- name: part
roles:
- concept: Part
multiplicity: ManyToOne
verbalizes:
- "{StockedItem} involves {Part}"

- name: bin
roles:
- concept: Bin
multiplicity: ManyToOne
verbalizes:
- "{StockedItem} involves {Bin}"

- name: warehouse
roles:
- concept: Warehouse
multiplicity: ManyToOne
verbalizes:
- "{StockedItem} involves {Warehouse}"

- name: has_quantity
roles:
- concept: Quantity
multiplicity: ManyToOne
verbalizes:
- "{StockedItem} has {Quantity}"

- concept: Quantity
type: ValueType
extends: [Integer]
```

The name `objectifies` is retained here because it describes the relationship between the Entity Type and the underlying fact. `reifies` may be more familiar across modelling communities, so the keyword itself is open for discussion.

The important design point is that the additional information belongs to the Entity Type that represents the reified relationship.

## How to interpret it

```text
StockedItem
├── represents the ordered tuple (Part, Bin, Warehouse)
├── has readings describing that tuple
├── links each tuple position to an existing Ossie relationship
└── remains an ordinary EntityType for all other purposes
```

Each `objectifies.roles` entry identifies:

| Position | Participant | Corresponding relationship |
| ---: | --- | --- |
| 1 | `Part` | `StockedItem.part` |
| 2 | `Bin` | `StockedItem.bin` |
| 3 | `Warehouse` | `StockedItem.warehouse` |

The order is significant. The references make the correspondence explicit instead of asking consumers to infer it from names or document order.

The readings under `objectifies.verbalizes` describe the reified relationship as a whole. Readings on `StockedItem.part`, `StockedItem.bin`, and `StockedItem.warehouse` continue to describe the individual binary relationships.

## Why attach this to `EntityType`?

The reifying Entity Type is the natural home because:

- it is the object that participates in further business relationships;
- it is already a first-class concept in the Ossie ontology;
- the reification information is meaningful only for Entity Types that use it;
- ordinary Entity Types need no additional YAML because the member is optional; and
- the roles and readings would otherwise have no non-arbitrary first-class home in Ossie's hierarchical ontology.

This avoids introducing:

- a third `ConceptType`;
- a separate top-level collection of Fact Types or relationship types; or
- an arbitrary choice of `Part`, `Bin`, or `Warehouse` as the primary owner of the reified relationship.

## Advantages

### Accessible across modelling paradigms

The representation describes a general semantic pattern, not a feature belonging to one modelling method. It can be mapped to associative tables, junction entities, graph nodes, association classes, and objectified Fact Types.

### Lossless interchange

A converter can preserve the distinction between an ordinary Entity Type with several relationships and an Entity Type that represents instances of a particular relationship. It can also reconstruct participant order, readings, and correspondence to the linking relationships.

### Small conceptual addition

`EntityType` and `ValueType` remain the only concept types. Existing relationships, role ordering, qualified relationship names, multiplicities, and verbalizations are reused.

### Existing Entity Type behaviour remains intact

`StockedItem` can still have descriptions, supertypes, constraints, derivations, mappings, and ordinary relationships. Reification adds meaning without replacing its Entity Type behaviour.

### Explicit rather than convention-based

Consumers do not need to guess that several similarly named relationships form a reification. This reduces ambiguity and makes validation possible.

## Impact on the existing ontology section

### Existing documents and producers

Existing ontology documents would be unchanged. `objectifies` would be optional and absent for ordinary Entity Types. Producers that do not support reification could continue producing current Ossie YAML.

### Existing consumers

Consumers processing documents that do not use the new member would require no behavioural change.

Consumers of a document that does use it could support the reification fully, preserve the Entity Type and relationships while warning that the added semantics are unsupported, or retain the new data without interpreting it.

The current JSON Schema uses `additionalProperties: false`. An older validator would therefore reject the new member. If adopted, the addition should be introduced through a new ontology specification version rather than described as compatible with validators for the current version.

### JSON Schema and validation

The structural schema change would be limited to:

- an optional property on an ontology component whose type is `EntityType`;
- a definition containing ordered roles and verbalizations; and
- a role definition containing a concept and relationship reference.

A semantic validator should also confirm that each referenced concept and relationship exists, that each relationship belongs to the reifying Entity Type, and that it links to the stated participant concept.

### Ontology mappings

No new top-level mapping section appears necessary. The Entity Type and its relationships can continue using Ossie's existing object and link mappings.

One point needs community guidance: whether the relationships listed under `objectifies.roles` automatically identify the reifying Entity Type, or whether they should also appear in `identify_by`. It would be preferable to avoid two conflicting sources of truth.

### Physical implementations

The proposal does not prescribe storage. Implementations could map the same concept to a junction table, a table with a surrogate key, a graph node and connecting edges, an association class, an event, a document, or another suitable structure.

The purpose is to preserve the conceptual meaning across those implementations.

## Alternatives considered

Using only `identify_by` can identify a `StockedItem` by `Part`, `Bin`, and `Warehouse`, but it does not say that the Entity Type represents their relationship or preserve the readings of that relationship.

Inferring reification from naming conventions would be fragile and could misclassify ordinary entities with compound identifiers.

Adding a new `ConceptType` or a separate top-level relationship-type collection would make the distinction explicit, but would have a much broader effect on the existing ontology model and its consumers.

The optional Entity Type member appears to capture the missing meaning while retaining Ossie's present hierarchy.

## Questions for the community

1. Is there already an intended Ossie representation for a relationship that must be treated as an entity?
2. Is the reifying `EntityType` the appropriate home for this information?
3. Is `objectifies` or `reifies` the clearer keyword for the wider Ossie audience?
4. Is explicitly linking every ordered participant to its corresponding relationship useful?
5. Should these relationships implicitly identify the reifying Entity Type, or should `identify_by` also be required?
6. What validation rules would be essential for interoperable implementations?

If this direction is useful, I would be happy to refine the syntax and contribute a focused specification change, JSON Schema update, worked example, and validation tests.

## References

- [Apache Ossie ontology specification](https://github.com/apache/ossie/blob/main/ontology/ontology.md)
- [Apache Ossie ontology JSON Schema](https://github.com/apache/ossie/blob/main/ontology/ontology.json)
- [Apache Ossie contribution guidance](https://github.com/apache/ossie/blob/main/CONTRIBUTING.md)
- [Ossie-FBM independent converter and viewer](https://github.com/FactEngineCommunity/Ossie-FBM)

GitHub link: https://github.com/apache/ossie/discussions/277

----
This is an automatically sent email for dev@ossie.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@ossie.apache.org