Information Model Development Recommendation: Data Element Repository

An entity is “a set of ideas, abstractions, or things in the real world that can be identified with explicit boundaries and meaning and whose properties and behaviors follow some rules.” [ISO-11179, 1-14] In the context of information, an entity is “a description of [a set of] objects that share the same attributes, …, relationships and semantics.” [UML1.5, 2-26]. There is distinction between a set of entities (entity type) and a particular entity (entity instance). As with the concept of objects, there is some imprecision in the term; it is not always obvious which aspect, classification or instantiation, is more important to a particular usage. It is usually possible to determine the connotation from the context, otherwise the term should be qualified as entity type or entity instance.

An entity embodies the abstraction mechanisms of classification and instantiation; an entity is the unit of instantiation The first defining characteristic of an entity (instance) is that it is “a thing that can be distinctly identified.” [ER 2.2]. The second defining characteristic is that is can be classified as a distinct type. Classification is an essential characteristic because it designates the specific properties that are applicable to an instance. Without such a designation, it would not be possible to instantiate the entity. The data content of an entity (instance) encompasses one value for each property in its full entity description. There is no concept of an “abstract” DER entity; the notion of partial implementation has no meaning in the context of the DER, which essentially provides a laundry list of information components.

Although not explicit in the meta-entity xde:Entity, an entity contains a set of properties. An entity may participate in associations. The DER explicitly manages a set of entities, properties (with their datatypes), and associations. Each particular context schema designates a set of data elements and associations. The DER is comprised of the set of data elements that can correctly be inferred from the entities, properties, associations and the meta-relationships among them.

A property is “a peculiarity common to all members of an [entity type]”. [ISO11179 1.6].

In an entity instance, a property is materialized as a value without identity. A property is similar in some ways to an association, except that a property value is always contained within its entity instance. A property is final in that it imposes no further structure on the instance beyond its containment. The relationship of an instance to its property values is always one-way. Properties are unordered within an entity and accessed only by name.

Historically, a property name is local, scoped to the entity that contains it. However, in order to support global interoperability and re-use, property names in the DER shall be globally unique and persistent. A property in the DER may be used in more than one entity (type). This applies not only to types related by generalization/specialization but also to unrelated types.

A property is a dependent concept. The owning entity determines the context of the property. The definition of the property itself must be confined to the meaning of the property that is irrespective of context.

A datatype (also known as a simple type) is a named, reusable value domain with a set of permissible values. As with entity, the two defining abstractions of a simple datatype are classification and instantiation. A simple datatype must be associated with a type because that is what defines the domain of possible values (value space). A simple datatype is materialized as a pure value without identity; that is what distinguishes it from an entity type.

Some sources note that a characteristic of simple datatypes is that they are unstructured and atomic. This is not, strictly speaking, a defining characteristic, because it is possible that the simple type could be parsed into smaller semantic units. This occurs in the case of a list of other simple types or a composite simple datatype (see below). It only makes sense to characterize a datatype as unstructured and atomic if the nuances of this characterization are well understood. A datatype is unstructured in the sense that it is not further divided by the structural components within its data model. For example, a text string in XML is a simple datatype because if contains no markup and, thus, contains further structure beyond its being a sequence of characters. The simple datatype may not always be atomic semantically, but it is always atomic with respect to its data model. For example, the value of XML attribute is, conceptually, a single unit of information – even though it may be a whitespace-separated list of values.

Although the simple datatype defines a set of permissible values, a distinction must be made between that value space and the lexical space of the datatype. It is customary that a datatype entails more than one lexical representation for a single value in its value space. For example, the values of boolean may be represented by true/false, 1/0, yes/no, etc. The trend in XML Schema has been to restrict this representational permissiveness by designating a canonical lexical representation for each value. If there is a one to many mapping from the value space to the lexical space, the definition of the simple datatype shall designate not only the value space but also its precise relationship to the lexical space.

Within the data model, a collection of simple types can itself be defined by a simple type. With XML the solution is that such a type consists of a whitespace-separated list. There are obvious implementation issues as well as semantic issues with such a type. These issues are addressed below.

Another form of datatype is the composite simple type. Sometimes there is an advantage to composing several semantic elements into a single datatype, for example, when making a list of the composite values; or a datatype such as xs:date, in which day, month, and year have separate meaning but are typically managed together. Another (very prevalent) example is a quantity that must be associated with a unit of measure.

There are three alternative ways that a composite simple type can be modeled in the DER: a) as a simple datatype with concomitant interpretation/parsing rules, b) as an entity type (which comes with an identifier), or c) as a separate property for each semantic atom. The DER model can accommodate either alternative because a complete representation mapping to any of the other alternatives can be defined for these representations. (described later).

An association defines a semantic relationship between entity types. An instance of an association is a set of tuples relating instances of entities. Each tuple value may appear at most once.

Association is a first-class (independent) concept, just as is entity. An association is similar to a relationship, as described in the entity-relationship (E-R) model. An association differs from a relationship in that associations are relationships that may be instantiated in the infoset.

Some legacy data models do not treat association as a first-class concept. In some cases it is not possible to distinguish a property from an association. Associations have not always been explicitly designated in DED’s. Association is a first class concept in the UML metamodel.

An association must have a globally unique persistent name (just as an entity does). The association name defines the association itself. However, an association can be instantiated in either or both directions without loss of information. An association is to a link as an entity type is to an entity instance. An association and it links are similar to an entity and its instances in that a classification abstraction is instantiated, but the association/link differs since a variety of instantiation modes are possible. This makes the definition somewhat more involved. An association is bi-directional but not symmetrical; more names (beyond the association name) are needed to define the association fully.

The association name itself is globally unique, but each end of the association also needs a name (which shall be local to the association). The name of each association end may be meaningful (eg corresponding to a role name), but it does not need to be. Its main purpose is to distinguish each end. Each end also has metadata properties that apply only to that end. These properties specify the set of conditions that must be satisfied for the association to be valid.

An association shares some of the characteristics of a property, but it has more facets. An association implies a navigation path between entities that is more demanding than the simple containment relationship of an instance to its property values.

Different data models and object models have adopted different approaches regarding association metadata. The UML model supports n-ary associations; the OMG MOF model supports only binary associations, citing the rationale that the simpler form is sufficient for metamodeling. (The major difference between the MOF model and the UML metamodel is that the former is primarily a data model, while the latter is primarily an object model.)

The DER metadata model adopts the simpler approach: allowing only binary associations. As with the MOF, the goal is simplicity of the metadata model, keeping the number of basic concepts small. Binary associations can be used as building blocks to construct n-ary associations if needed. Moreover, binary associations are by far the most prevalent form of association found in information modeling.

A second form of more sophisticated association is the association entity. This concept is defined both in the E-R model (relationship entity) and in UML (association class). This construct is used when an association has properties in its own right, distinct from the properties of the associated entities. An association entity has all the characteristics of an entity, including identity. It may participate in other associations. (In UML the association class is multiply inherited from Association and Class.) Following the goal of simplicity, the DER model does not recognize the association entity as a primitive construct. An association entity should be modeled as an entity with an association for each relationship.

Figure 2. Association entity

The representation of an association entity is illustrated in Figure 2, “Association entity” The association entity is treated like any other entity in the DER. Its associations correspond to the legs of a UML AssociationClass. The only problem is that there are more names affiliated with the association entity than with an association class. Some of the names in the association entity are generated synthetically in order to align the semantics of the concept. The AssociationClass has a class name and one(role) name for each association end. The association entity has a corresponding entity name and one (role) name for each remote association end. However, each remote association end is attached to the association entity by means of an association, which itself has a name as well as a (role) name for the attached end. The role name of the attached entity is always set to ex_assoc_entity, which signifies that the entity is an association entity. The association name is the concatenation of the association entity name and the remote role name.

The same approach should be used to model n-ary associations, which more often than not do have their own properties and identity. The definition of the n-ary assocation is illustrated in Figure 3, “n-ary association”. In UML an n-ary association is represented by a diamond that connects n (where n >=3) association ends. There is one association name and n rolenames. In the DER the n-ary association is modeled as an entity (ie an association entity). Each leg of the n-ary association is mapped to an association. Again there are more names than are absolutely needed. The standard association entity mapping of names is followed. Each leg maps to a remote role name in the association entity.

Figure 3. n-ary association

An association end has properties that control the validity of a particular link. Some of those properties define the aggregation semantics of the association end. The aggregation semantics apply to part-of associations, indicating which end is the composite and which the part. The part end may be further qualified with respect to existence dependence, shareability, and the potential for containment. The aggregation semantics are part of DE model and are described in detail later in this part.

The metadata for an association end designates the types of entities that may appear at that end. In object systems, an association may refer to multiple types via polymorphism. Since entity inheritance is not captured in the DER metadata model, the association end must explicitly enumerate the types that may appear at each association end. The types may be related by some generalization classification, or they may be completely unrelated.

The primary purpose of the DER is to manage associations and data elements, the key elements of the information interoperability contract. A data element (DE) is “a unit of data for which the definition, identification, representation and permissible values are specified…” [ISO11179-1]

The importance of the data element stems from the fact that it is the irreducible unit of information interoperability. “A data element then is a single unit of data that in a certain context is considered indivisible.” [ISO11179-B-1]. Th context in which a data element is irreducible is the formation of a context schema, the contract between the parties for a particular information interchange. The data element is a complete, unambiguous contractual element; it is the re-usable building block from which any number of contracts can be assembled.

A data element is a unit of information, that is, data plus context. Structurally, the data element is an aggregation of an entity type, a property type (and its datatype), which designates the representation. Both properties and datatypes, as they are represented in the DER, are independent of context. The association of a property/datatype with an entity establishes the semantic context.

The data element is uniquely and persistently identified by the identifiers for its entity and its property, each of which is itself a globally unique persistent identifier.

Data element concept

Some methodologies introduce the notion of a data element concept, which is an aggregation of an entity and property that can then be associated with different datatypes. This approach introduces aspects of representation into the DER model. After a property has been associated with an entity, there remain two open questions that must be settled before a data element instance can be created: the value space for the data element and the representation for the data element instance. There is one and only one value space associated with a particular data element. This has been a basic tenet in number of methodologies and data models (such as E-R, UML, domain key normal form, strong static typing in programming languages). This applies even in the case of redeclared properties because the redeclared property appears in a subtype entity and, thus, a separate data element.

For a single value domain, there may be a number of permissible representations, including variants in the type’s lexical space, alternative representations for composite datatypes, mappings to synthetic entities, and representations in alternative media. The first three representations are handled in the representation layer of the II architecture (described later). An alternative media representation should be handled at the presentation layer.

To introduce the notion of data element concept into the DE model would be a violation of the layering that is needed for information interoperability. The data element SHALL be concerned exclusively with the data model; representations SHALL be handled in the representation layer.

Naming convention

To facilitate the re-use of data elements, a naming convention is typically applied for combining the name components of data element.

In the DER the naming convention for data elements is the concatenation of expanded name for each component name in the following order: entity, property. Component names are separated by the “#” character. The expanded name of an xs:Qname is the concatenation of open curly brace, the namespace URI, close curly brace, the local name.