Item - Item (internal data type)

Considering object related concepts as a container containing information of any complexity (elementary value, instance, collection or classified collection), corresponding data concepts can be described on different levels:

• Elementary type
• Property
• Object type
• Classification
• Aggregation types

Those categories describe object related concepts or schemata for data states. There is no common designation that describes the generalization of object related concepts. Here, it will be called item .

An item is a feature that defines common features for object related concepts as behavior and causalities. In general, each object related concept may define behavior and causalities for the object defined by the item.

An individual item is the reflection of an individual object property or object collection. Individual items are defined in detail in [UDT]. A general item (or item) describes the conceptual view to data and appears as property, elementary and object type or aggregation type.

Each item consists of a number of features, which describe the details of the item. The item defines what a concept has, how it behaves and how it reacts. The concept of an item is provided as textual definition that defines what the item is about, it's meaning.

Different categories of items have been discovered so far and are supported in TM. Items are not defined as such, but as type, property or classification.

Since objects or object views the item refers to, are always defined in a higher context, each item has a parent item. Indeed, there are no items existing outside any context, i.e. each item (except perhaps the topmost, e.g. the universe) has a parent (item) describing the context in which the item and its features are defined.

Relational data modeling [ERM] does not consider items and defines a number of tables without defining the higher item. E.g. invoices could be such a table, which does not at all mean all the invoices in the universe, but the invoices for the company, only, which deals with those invoices.

Indeed, the invoices are a feature of a company in this case. Most data models try to model "global" data sets ignoring the parent item, which is not a big problem, since the application works within the implicitly defined item, only.

Rules defined for an item describe the way an object, object collection or part of an object behaves. Mainly, rules are defined in order to derive information from other properties, in order to react on different events or for defining specific behavior of related objects. Rules are often referred to by feature relations, e.g. in causalities (reactions) or constraints.

Constraints allow defining sort of validation rules for instances (object, property, collection), e.g. the birth date of a person must not be greater than the current date or persons younger than 18 years cannot be married (at least in some countries).

Events are often considered as process events but happen also as state transition events [UDT] caused by state transitions of one or more item instances. Events might also be defined in combination with time events.

Causalities (reactions) describe the way an item reacts on specific events. Typically, items react on process events as inserting or removing an object instance (parts, associations) or updating a property value (characteristics). When an event has been recognized, the action referred to by the causality will be called. Actions are typically defined by means of rules.