| Data transformation |
|---|
| Concepts |
| Transformation languages |
| Techniques and transforms |
| Applications |
| Related |
In metadata, a data element is an atomic unit of data with a precise meaning. A data element has a name and a definition, and may also include one or more representation terms, enumerated values, and synonyms in other metadata registries.
Data elements are fundamental components of data models, and are described by data dictionaries. Collections of data elements form data structures that represent and organize information within databases and other data systems.[1]
Well-defined data elements facilitate data mapping by providing consistent definitions and reducing ambiguity. If, however, data elements are overloaded with multiple meanings, data integration and system understanding become more difficult.
In telecommunications, the term "data element" also refers to a named unit of data or information that represents a distinct item or attribute.
Properties
A data element has:
- An identification such as a data element name
- A clear data element definition
- One or more representation terms
- Optional enumerated values Code (metadata)
- A list of synonyms to data elements in other metadata registries Synonym ring
Name
A data element name is a name given to a data element in, for example, a data dictionary or metadata registry. In a formal data dictionary, there is often a requirement that no two data elements may have the same name, to allow the data element name to become an identifier, though some data dictionaries may provide ways to qualify the name in some way, for example by the application system or other context in which it occurs.
In a database driven data dictionary, the fully qualified data element name may become the primary key, or an alternate key, of a Data Elements table of the data dictionary.
The data element name typically conforms to ISO/IEC 11179 metadata registry naming conventions and has at least three parts:
- Object, Property and Representation term.
Many standards require the use of upper camel case to differentiate the components of a data element name. This is the standard used by ebXML, GJXDM and NIEM.
Example of ISO/IEC 11179 name in XML
Users frequently encounter ISO/IEC 11179 when they are exposed to XML Data Element names that have a multi-part camel case format:
Object [Qualifier] Property RepresentationTerm
The specification also includes normative documentation in appendices.
For example, the XML element for a person's given (first) name would be expressed as:
<PersonGivenName>John</PersonGivenName>
Where Person is the Object=Person, Property=Given and Representation term="Name". In this case the optional qualifier is not used, in spite of being implicit in the data element name. This requires knowledge based on data element name, rather than use of structured data.
Definition
In metadata, a data element definition is a human readable phrase or sentence associated with a data element within a data dictionary that describes the meaning or semantics of a data element.
Data element definitions are critical for external users of any data system. Good definitions can dramatically ease the process of mapping one set of data into another set of data. This is a core feature of distributed computing and intelligent agent development.
There are several guidelines that should be followed when creating high-quality data element definitions.
Properties of clear definitions
A good definition is:
- Precise - The definition should use words that have a precise meaning. Try to avoid words that have multiple meanings or multiple word senses. The definition should use the shortest description. The definition should not use the term you are trying to define in the definition itself. This is known as a circular definition.
- Distinct - The definition should differentiate a data element from other data elements. This process is called disambiguation - The definition should be free of embedded rationale, functional usage, legal metadata registration.
Definitions should not refer to terms or concepts that might be misinterpreted by others or that have different meanings based on the context of a situation. Definitions should not contain acronyms that are not clearly defined or linked to other precise definitions.
If one is creating a large number of data elements, all the definitions should be consistent with related concepts.
Critical Data Element – Not all data elements are of equal importance or value to an organization. A key metadata property of an element is categorizing the data as a Critical Data Element (CDE). This categorization provides focus for data governance and data quality. An organization often has various sub-categories of CDEs, based on use of the data. e.g.:
- Security Coverage – data elements that are categorized as personal health record, personal health information or PHI warrant particular attention for security and access
- Marketing Department Usage – The marketing department could have a particular set of CDEs identified for identifying Unique Customer or for Campaign Management.
- Finance Department Usage – The Finance department could have a different set of CDEs from Marketing. They are focused on data elements which provide measures and metrics for fiscal reporting.
Standards such as the ISO/IEC 11179 Metadata Registry specification give guidelines for creating precise data element definitions. Specifically chapter four of the ISO/IEC 11179 metadata registry standard.
Common words such as play or run database documents over 57 different distinct meanings for the word "play" but only a single definition for the term dramatic play. Fewer definitions in a chosen word's dictionary entry is preferable. This minimizes misinterpretation related to a reader's context and background. The process of finding a good meaning of a word is called Word-sense disambiguation
Examples of definitions that could be improved
Here is the definition of "person" data element as defined in the www.w3c.org Friend of a Friend specification *:
Person: A person.
Although most people do have an intuitive understanding of what a person is, the definition has much room for improvement. The first problem is that the definition is circular. Note that this definition really does not help most readers and needs to be clarified.
Here is the definition of the "Person" Data Element in the Global Justice XML Data Model 3.0 *:
person: Describes inherent and frequently associated characteristics of a person.
Note that once again the definition is still circular. Person should not reference itself. The definition should use terms other than person to describe what a person is.
Here is a more precise but shorter definition of a person:
Person: An individual human being.
Note that it uses the word individual to state that this is an instance of a class of things called human being. Technically you might use "homo sapiens" in your definition, but more people are familiar with the term "human being" than "homo sapiens," so commonly used terms, if they are still precise, are always preferred.
Sometimes your system may have cultural norms and assumptions in the definitions. For example, if your "Person" data element tracked characters in a science fiction series that included aliens you may need a more general term other than human being.
Person: An individual of a sentient species.
In telecommunications
In telecommunications, the term data element has the following components:
- A named unit of data that, in some contexts, is considered indivisible and in other contexts may consist of data items.
- A named identifier of each of the entities and their attributes that are represented in a database.
- A basic unit of information built on standard structures having a unique meaning and distinct units or values.
- In electronic record-keeping, a combination of characters or bytes referring to one separate item of information, such as name, address, or age.
In practice
In practice, data elements (fields, columns, attributes, etc.) are sometimes "overloaded", meaning a given data element will have multiple potential meanings. While a known bad practice, overloading is nevertheless a very real factor or barrier to understanding what a system is doing.
See also
References
- ↑ Beynon-Davies P. (2004). Database Systems. 3rd ed. Palgrave, Basingstoke, UK.
This article incorporates public domain material from Federal Standard 1037C. General Services Administration. Archived from the original on 2022-01-22.- This article incorporates public domain material from Dictionary of Military and Associated Terms. United States Department of Defense.
Bibliography
- ISO/IEC 11179-5:2015 Metadata registries (MDR) - Part 5: Naming and identification principles
- ISO/IEC 11179-4:2004 Metadata registries (MDR) - Part 4
- ISO/IEC Technical Report 20943-1, First edition, 2003-08-01 Information technology — Procedures for achieving metadata registry consistency
- "XML Developer's Guide V1.1 – 1 May 2002". DON XML Working Group. 2002-05-01. Retrieved 24 June 2025.
External links
- Federal XML Developer's Guide
- ISO/IEC 11179 Standards (see ISO/IEC 11179-3:2003 clause 3.3.36)