DDEX Data Dictionary

Digital Sales Reporting Message Suite Standard (DSR 3.2)
Electronic Release Notofication Message Suite Standard (ERN 3.2)

Pleae click here to access the data dictionary.

This DDEX Data Dictionary contains the names and descriptions of every data Element used in DDEX Message Suite Standards in their 1st Version, organised into a hierarchical framework which can be navigated in HTML, starting and finishing at any point. Its aim is to provide a comprehensive, consistent, structured and extensible dictionary of terms to support the consistent global development and use of DDEX Messages and other tools.

Structure

Each element is presented on a single HTML page with the following attributes:

Elements are linked in a hierarchical ("parent-child") structure, with other links shown where appropriate (see Relationships below for details). The whole Dictionary is also presented (Headwords and Descriptions only) in a single alphabetical list.

Navigation

A user can enter the Dictionary at any point and navigate by hyperlinks. Click here to go to the alphabetical list.

From the alphabetical list, click on any highlighted Element name to go to the page for that Element. From within that page, click on any other linked Element to go to its page: by this means a user can navigate all links in the Dictionary. Alternatively, click on any letter in the A-Z list at the top of any Dictionary page to go to a page showing an alphabetical listing of Elements beginning with that letter or number, from which a selection can be made.

Contents

The DDEX Data Dictionary contains every data Element used in a DDEX message.These Elements are of two kinds:

Element Names

Each Element has a main name or Headword, and may have any number of alternative names or Synonyms. Names are presented in upper and lower case, with initial capitals for each word, and with no spaces between words (for example: PartyRoleDescription). Words are normally spelled out in full (for example, CatalogNumber not CatalogNo), exceptions being Id (for Identifier) and Ref (for Reference).

Headwords of Composites within Messages normally end with the word Composite or Header. The names of Elements in the DDEX Namespace are presented without any prefix. Elements which are specific to sub-Namespaces are presented with their Namespace code as a prefix.

Language

The default language of the DDEX Dictionary is US English.

Namespaces

All Elements in the Dictionary belong to a Namespace: that is, a Party responsible for a set of Element values. All Simple Elements are in the ddex namespace. Composites may be either in the ddexC namespace, or in a namespace for a more specialised domain within DDEX such as the DDEX message namespaces ern (for the Electronic Release Notification message suite) or dsr (for the Digital Sales Reporting message suite). Finally, allowed value lists that are maintained by ISO bear an iso* namespace.

Element Descriptions

The aim of an Element's Description is to explain its meaning without ambiguity. Descriptions are created according to certain conventions. A Description may be broader than a formal definition, as it may include additional comments or examples.

The first part of a Description is normally in the form of a definition. Definitions are normally precise and compact. Where an Element is a child or a dependent attribute of another Element, it is normally defined by direct reference to that Element: for example, a CreationId is defined as 'An Identifier of a Creation'. It can be said that CreationId inherits or derives meaning from Creation and Identifier.

The Elements from which meaning is derived are shown with an initial capital letter in the Description. The Descriptions of these Elements can then be reviewed for further information about the meanings which they pass on to their dependents. For example, an Identifier is defined as 'A Name which is unique within its namespace', and a Creation is 'An entity that is made, directly or indirectly, by one or more human beings'. Both of these meanings are inherited by CreationId.

Element Relationships

The underlying structure of the Dictionary is a series of XML triples, in which Elements are linked by Relators. For example, the parent-child Relationship between Identifier and PartyId is created by a triple of these Elements:

PartyId - IsSubClassOf - Identifier

The middle Element in a triple is a Relator. A set of 14 Relators provide all the links within the Dictionary.

These Relators or 'linking Terms' are not used in any Messages, but are all included in the Dictionary. Relatives of each Element are shown as a simple set of lists under the headings below.

Relationship

Description

Relator(s) used

Parents

Shows the parent(s) or Supertypes of the Element. For example, CreationId has the parent Identifier.

IsSubClassOf
IsSubRelatorOf
IsSubTypeOf

Children

Shows the children or Subtypes of the Element. For example, Identifier has the child CreationId.

HasSubClass
HasSubRelator
HasSubType

Belongs To Class

Shows the Classes of which the Element is a member or 'instance'. For example, Licensee is a member of the class PartyRole.

IsA

Instances

Shows the members or 'instances' of a class. For example, the class PartyRole has a member Licensee.

HasInstance

Parts

Shows the parts of the Element. For example, the Element GRid has a part IssuerCode.

HasPart

Part Of

Shows the Elements of which an Element is a part. For example, the Element IssuerCode is a part of GRid.

IsPartOf

Components

Shows the components of a Composite. For example, the Composite SalesTransactionComposite has a component PriceRangeType.

HasComponentElement

Is Member Of Composites

Shows the Composites of which an Element is a component. For example, the Element PriceRangeType is a component of SalesTransactionComposite.

IsComponentElementOf

Has Same Components As

Shows a Composite from which the Composite is derived and whose components it uses. For example, the Composite TaxAmountComposite has the same components as AmountComposite.

HasSameCompositeElementsAs

Composites Using Same Components

Shows the derived Composites of the Composite. For example, the Composite AmountComposite has a derived component TaxAmountComposite that uses the same components.

IsModelCompositeFor

Global and local meanings

Every Element has a 'global meaning' which is true wherever it is used. For example, an Identifier is always 'a Name which is unique within its namespace'. A DDEX Dictionary Description always conveys an Element's global meaning.

However, this global meaning does not say, for example, what it is that the Identifier is naming: that will vary according to its particular application. For example, if Identifier is included as a SubElement of a Party in one part of a message, and as a SubElement of a Work somewhere else, then it will be an Identifier of a Party or a Work according to its context. These are its 'local meanings', and they are dependent upon the application of the Element itself. A local meaning never contradicts a global meaning, it only narrows it down (or 'specialises' it) by adding more constraints. Meaning in DDEX (as in all compatible systems) is therefore a combination of global and local.

© Copyright DDEX 2006