Object types, instances and metadata
Business modeling distinguishes the definition of a kind of thing from the particular things recorded under that definition.
Customer is an object type. A particular customer's record is an instance of that type. Metadata describes the type's structure and relevant behavior; instance data supplies the values and relationships for a particular record.
Understanding these distinctions helps separate vocabulary composition from daily work with business information.
A type defines what instances represent
An object type defines a business entity, event or concept within the model's scope. Its definition identifies the meaning, attributes, relationships and applicable constraints for instances of that type.
A type is often called a class. A class groups instances according to its defined meaning; an individual instance is a member of that class.
CycleXplore's Customer definition might identify the information needed to represent a customer in the rental service. The definition of Rental Order describes a separate business concept and how it relates to Customer.
The model is selective. A Bicycle definition might include the asset identifier and service information needed for rentals. It need not describe every physical or historical characteristic of the bicycle.
An instance records a particular case
The following synthetic records illustrate the distinction:
| Object type | Instance identifier | Example instance data |
|---|---|---|
| Customer | CX-C-017 | Display name: Naledi Mokoena |
| Bicycle | CX-B-031 | Asset label: Trail bicycle 31 |
| Rental Order | CX-R-1042 | Requested start: 10 November 2026, 09:00; requested end: 10 November 2026, 12:00 |
The order record can be related to customer CX-C-017 and bicycle CX-B-031. The type definitions explain what those relationships mean and the permitted combinations; the actual links identify the records involved.
Identifiers and attributes in this example are illustrative. They do not prescribe MONJO's internal storage schema or a required identifier format.
A business entity and its digital record are also distinguishable. Naledi is a person in the world; the customer record captures the aspects relevant to CycleXplore's business relationship with her.
Metadata describes the definitions
In MONJO's metadata-driven approach, structured definitions describe the information and behavior an application needs to interpret. It is useful to distinguish several roles within that metadata:
| Metadata role | Describes | Example |
|---|---|---|
| Semantic | Meaning, classification and relationships | What Rental Order represents; the meaning of its Customer relationship |
| Structural | Attributes, value types and multiplicities | The rental-period fields and their value types |
| Constraint and behavior | Required conditions, calculations and operational requirements | End time must be after start time |
| Administrative | Ownership, documentation and change context | The steward responsible for reviewing a definition |
| Presentation | How information is entered or displayed | A date/time control, field label or grid visibility setting |
These roles help explain metadata; they are not presented here as a final list of editor field groups. One operational feature may draw on more than one role.
The distinction matters when definitions change. Renaming a display label differs from changing a relationship's meaning. Hiding an attribute in a grid differs from making its value optional. A presentation choice should not silently alter a business rule.
Attribute definitions and attribute values
An attribute definition describes a value an instance can hold. For example, Rental Order may define a requested start time. The particular order CX-R-1042 supplies a particular date and time.
Some values may be entered, some selected, and some calculated or derived. The definition needs to identify the intended meaning and relevant constraints. Control types, expressions and attribute settings provide implementation mechanisms in the established MONJO/Bizcloud environment.
An expression's executable syntax belongs to that environment. The business meaning of a calculation should remain understandable independently of the particular expression used to implement it.
Relationship types and actual relationships
A relationship type defines a permitted kind of connection. An instance-level relationship connects particular records.
| Definition | Instance-level relationship |
|---|---|
| Rental Order is placed by Customer | CX-R-1042 is placed by CX-C-017 |
| Rental Order concerns a Bicycle, under the example's chosen model | CX-R-1042 concerns CX-B-031 |
A more detailed rental model may use an order-line or allocation object between an order and each bicycle, particularly where the connection has information of its own. The appropriate construct follows from the business requirements and the Object Model's rules.
A name or identifier stored in a field is not, by itself, a complete explanation of a relationship. The definition establishes the referenced type, the meaning of the connection, multiplicity and applicable constraints.
Inheritance and ancestral definitions
When Customer is a subtype of Trading Partner, it retains the applicable definitions inherited through Trading Partner and Participant. The more specific definition adds the detail relevant to its scope while retaining its ancestry.
MONJO handles that context automatically. Users selecting a subtype need not separately populate each ancestor or open a workbook at each level of the classification.
This classification ancestry differs from a dependency relationship between separate instances. An Order Line that depends on an Order and a Customer classified as a Trading Partner express different kinds of connection.
Workspaces and the Object Explorer
A workspace provides the operational context in which vocabulary definitions are applied to business records. In the established Bizcloud environment, records are also described as Document Objects. This term refers to instances and does not imply that every instance is a Word document, PDF or other file.
The Object Explorer uses metadata to present the relevant information. A form represents an individual record; a grid represents a collection. Related panels, tabs and navigation links help users move through connected information.
For example, a rental-order form may show information about CX-R-1042, with related records accessible in additional panels. Opening a tab changes the user's view. Whether changing a selection also creates, modifies or removes data depends on the configured model and runtime behavior.
Definitions, records and implementation objects
| Kind | Purpose | Example |
|---|---|---|
| Business object type | Defines business meaning and structure | Customer |
| Business instance / record | Records a particular case | Customer CX-C-017 |
| Technical object | Implements computation, storage or interaction | An API handler or UI component working with customer records |
These may correspond in an implementation, but they are not interchangeable. A UI component is not the customer it displays. A metadata definition can shape an application without making every runtime concern part of the ontology.
A practical way to distinguish a change
When working with MONJO, ask: Am I changing the definition, a particular record, or the way the system handles it?
- Adding an attribute to Customer changes the definition.
- Correcting CX-C-017's display name changes instance data.
- Changing the form layout changes presentation configuration.
- Changing how the API enforces an update changes implementation behavior.
Keeping these distinctions visible makes vocabulary maintenance and application development easier to reason about.