Proposal: Representing reified relationships as Entity Types

[FactEngineCommunity]

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:

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:

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

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
• Apache Ossie ontology JSON Schema
• Apache Ossie contribution guidance
• Ossie-FBM independent converter and viewer