Reading the data dictionary

The different editions of the DDEX data dictionary contain the descriptions of every data element used in each DDEX standards, organised into a hierarchical structure 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:

• Headword (1)

• Term status information (1)

• Description (1)

• Synonym(s) (0-n)

• Comments (0-n)

• Component structure (0-n)

• Relationships (1-n)

Elements are linked in a hierarchical ("parent-child") structure, with other links shown where appropriate. The whole dictionary is also presented with headwords and descriptions only in a single alphabetical list.

Navigation

A user can enter a data dictionary at any point and navigate by hyperlinks.

For example, 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 data 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

Each edition of the DDEX data dictionary contains every data element used in all the messages specified in an individual standard. These elements are of two kinds:

• Simple Elements
  Simple Elements (e.g. PartyId, ISWC, DistributionChannelType, NumberOfFreeUnits or Broadcast) have values or are values. These form the bulk of the data dictionary and are the basic building blocks of messages and other specifications.

• Composites
  Composites are groups of two or more data elements combined for any purpose. For example, a Message, a set of ReferenceDescriptiveMetadata, or a group of elements within a message such as Titles are all composites. A composite does not represent anything in its own right but is only a collection of elements which normally have some kind of relationship with one another. It does not have an element value of its own. Composites may contain other composites, to any level of granularity.

Composites are all message terms, i.e. elements used in messages. Simple elements are of two kinds:

• Message Terms ("MT")
  Message Terms are elements used in messages. They hence occur in the XSD files. Message terms are tagged as "MT" on the index pages and their use is indicated on their data dictionary page.

• Supporting Elements
  Apart from the message terms, another group of elements has been included in the data dictionary. these are Supporting Elements. Supporting elements are those which have been added to create a complete and logical hierarchy for the data dictionary, but are not (or not yet) being used in any messages or specifications. For example, at the top level the term entity has been introduced as a parent for all terms, and below that a group of other elements have been added to provide infrastructure to support more specialised groupings.
  Supporting elements are also those elements which are implied in other elements but are not, or not yet, used in messages or other specifications. For example, the element VersionId is included in a message, but the thing it identifies, a Version, does not appear in a message, so it has been added to the data dictionary as a supporting element.
  Supporting elements are otherwise no different from other simple elements, and may be used in future messages or specifications, so no formal distinction is made. Supporting elements are not tagged on the index pages, but their status is indicated on their dictionary page.

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: NumberOfWorks). Words are normally spelled out in full (for example, CatalogNumber not CatalogNo). Exceptions are Id for identifier and Ref for reference.

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 data dictionaries is US English.

Namespaces

All elements in the data dictionary belong to a namespace. This references the 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 specific message.

Element description

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”. In this context CreationId clearly inherits or derives meaning from the elements, 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.

Component structure

The structure of the composites is shown under the heading "Components" as a list of the contained elements, including their name and description as well as their cardinality and their data type. There is also a section entitled "Is Member of Composites" showing a list of composites that contain the current composite.

Element relationships

The underlying structure of the data dictionaries 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. These relators or “linking terms” are not used in any DDEX messages, but some of them are included in the data dictionaries as supporting elements.

Relatives of each element are shown as a simple set of lists under the headings below.

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 data 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 meanings.