Asset Oriented Modeling (AOM)

- Assets -

Assets are the basic building blocks of AOM. Unlike the various flavors of Entity Relationship Modeling, AOM does not separate between entities and relationships. In AOM both entities and relationships are represented as assets (the relationships are reified). In this respect is AOM closer to the relational approach (where both entities and relationships are represented as tables). This approach allows to represent n-ary relationships easily, and similarly higher order relationships (i.e. relationships between relationships).

Assets can be concrete or abstract. Abstract assets cannot have instances. They can be used for inheritance and type definitions. Abstract assets are denoted by a label with grey background.

Assets are connected via directed arcs.

required item. Identifies the asset within the scope.
Names can be prefixed with a namespace prefix. If the name is not prefixed, it belongs to the model default namespace. The namespace is relevant when models are merged. The combination of namespace and asset name must be globally unique. Name formulas may be used as asset name.
optional. An image in the top right corner may be used for asset illustration.
optional. The display name for asset instances. If omitted, the display name of instances is the asset name. Several names are possible within one label which then act as aliases. Labels are not necessarily unique but belong to the asset's namespace.
A label with a gray background denotes an abstract asset, i.e. an asset that cannot have instances.
Name formulas may be used as a display label.
defines a limited context for assets. Multiple scopes are allowed. All asset definitions are only valid within the specified scope(s). A typical example for using scopes is versioning. If no scope is supplied, the asset is valid in all scopes defined for the model.
an arbitrary number of primary keys (usually one) that identify asset instances uniquely. A key can be decorated with a name which must be unique within the context of the asset.
Each property describes a certain aspect of an asset. For example, an asset Person would have properties such as Name, Height, Weight, Birthdate, etc. Properties can be structured. Optionally, a property can be constrained by a datatype definition. For the property syntax, please see here.
By default, the properties of an asset form a sequence (an ordered list). However, it is also possible to arrange the properties of an asset in a bag construct and to define nested bags, choices, or sequences. The usage of a bag is indicated by marking the Property section with the bag operator (&).
The property section may also contain type declarations.
Constraints can be used to define additional restrictions for properties. Constraints can be defined for single properties, across properties, or across assets. 
Operations define the access methods to asset instances. Operations are specified as abstract method names. The semantics depend on the implementation.
The definition of annotations is optional.
Subject IDs
The definition of subject IDs is optional. A subject ID identifies the concept or idea to which the asset relates. It usually refers to an existing ontology. Subject IDs can be specified with or without a prefix. If not prefix is specified, the subject ID is assumed to come from the declared Default Subject Ontology. A prefix may either be a Subject Ontology Prefix, or it may specify an ontology namespace explicitely be URI.
Subject IDs play a role when models are merged. Assets from different models are candidates for asset binding when the intersection of their subject ID sets is not empty.


Home Definition Step-by-Step Examples Downloads

Contact: support 'at'