Athena Developer Guide

Athena Chapter 9 Data dictionary Version/Issue: 2.0.0
might be programmatic entity or construct (which could denote components, structs,
common blocks, streams, files, etc.). However, since it is almost certain that most, if
not all, such entities in Athena will in fact correspond to real objects, we will not dwell
on this distinction.
NB: The term data dictionary connotes a certain technical implementation which we do
not (necessarily) advocate. This term implies a central repository containing the
information about those objects being described. This is one possible implementation
of some of the concepts in this paper. However, it is also possible (perhaps even
desirable for some purposes) that the information resides internal to the object (for
example). In this Chapter we use the term Data Dictionary as a generic term denoting
the broad concept and not as an indication of where the object description resides.
9.1.2 Roles of a Data Dictionary (DD)
The motivation for implementing a DD in Athena can be illustrated by listing the potential roles
that a DD can play within the Architecture. These roles include:
• Data Tools Integration
Tools needed to perform many tasks within the overall system` which are not specific to a
particular data object type, including browsing and editing, visualization, simple or standard
transformations, etc.
• Interactive Data Queries
The ability to interrogate a data object as to its shape and content from the interactive user
interface (e.g. scripting language interface).
• Automatic/Semiautomatic Persistency
The ability to apply generic converters and/or to automatically generate specialized converters
and/or to generate converter skeletons for subsequent, manual customization.
• Schema Evolution (Version-Safe Persistency)
Most data objects in the Event Data Model (EDM) typically change multiple times throughout
their lifecycle within a HEP experiment. Support for evolution of the EDM schema is critical.
• Multi-Language Support
Components written in multiple programming languages (e.g. C++, Java, FORTRAN) will be
used in the context of the Athena framework. These components need to exchange data in a
language independent interchange representation.
• Component Independence, Stability, & Robustness
The ability to write code to a reflection API such that changes external to a component do not
necessitate any code changes within the component leads naturally to code stability and,
consequently, code robustness. Architectural attention to physical interdependencies of
framework components also benefits from the use of such an API.
page 70