Feature - Feature categories (internal data type)

Many concepts refer to subordinated concepts (e.g. via concept relations). Subordinated concepts that belong to exactly one concept (parent or owner) are called feature . Features may appear as directly subordinated concepts (e.g. characteristics) or as concept relation referring to other concepts.

When a feature refers to another concept, the feature still belongs to its owner, but not the referenced concept. E.g. a constraint hat refers to a rule belongs to its owning concept, but not the rule referenced. Features, that define concept relations, are also called feature relations . A feature relation is a concept relation that refers to a feature defined as feature of another concept. Usually, feature relations do not contain subordinated features, but the relation to exactly one other feature. There are, however, also features, that define a feature relation by referring to the feature of another concept and providing own features. Thus, TM does not strictly distinguish between feature and feature relation, but refers to feature and feature relation in order to refer to the owner or relation aspect of a feature.

The feature relation is a concept describing the use of a defined feature within another feature, while subordinated features are part of its parent feature. E.g. the validation rule (constraint) for the salary property of an employee (feature relation) refers to a rule (feature) defined for object type employee (checks, whether an employee does not earn more than his boss). The rule is defined as feature of the object type employee but it is referenced from the property salary as constraint (feature relation). Thus, the feature relation defines the role the referenced feature plays in a specific environment.

Defining the details of a concept by means of features allows expressing detailed knowledge not only about a subject area, but also about object types, properties and object collections.

Features may get subordinated features, again. Thus, features may form a hierarchy. The meaning of the term referring to a feature is uniquely defined within the owning feature, only.

Since features define the meaning of a term in the context of another feature, the same term might be assigned to features owned by another feature (e.g. properties assigned to different object types may use the same name with different meaning, as size property for person and company ). Thus, the meaning of a feature, i.e. its concept definition, may differ depending on the owning feature.

In a terminology model, each concept is defined at least in the context of the individual or general object, which provides the frame for the terminology model. Hence, instead of defining concepts, TM defines features and feature hierarchies.

In order to simplify the terminology model, features levels are assigned to features. Level 1 features allow defining a simple terminology model and include object types, classifications and properties. Level 2 features describe an enhanced terminology model that also includes rules, causalities and keys.

In [1087], features are not defined as such. There, object relations and characteristics are defined as details of a concept, but those are not considered as subordinated concepts. In [ODMG], properties and behavior (what objects of a class are able to do) are considered as features for object types, as well as extents defining object collections or keys. In addition, TM supports a number of feature categories, which play an important role when expressing knowledge.

• Rule

• Event
• Causality
• Item

Items summarize a number of more specific features. Rule, event and causality are features defined for items as well as constraints.