"Harmonisation" is the process producing convergence of data definitions used across different systems, leading to greater interoperability and reuse. Harmonisation is an important function of a registry process, one that is essential if the largest benefits are to be achieved. The most important harmonisation method used in the ITS Metadata Registry is the technique of "core components analysis".

Click here to view Core Components in the Registry

Core components background

"ebXML Core Components" is a UN/CEFACT specification used in e-business standardisation. The key idea that supports harmonisation is the separation of "core components", which have no specific business context, from the actual representations used in e-business systems for specific purposes. In terms of our registry, the registered models all have their individual business contexts, and they can be seen as context-specific instances of a single set of underlying core components. A simple example is shown below.

We use UML dependencies to show the association between registered items and core components, and the documentation for each dependency explains the business context and the justification for any differences between the registered items and their corresponding core components.

In some cases of particular importance we annotate the dependency with a statement that explains the precise mapping between the registered item and the core component.

Core components analysis

The ITS Metadata Registry project has developed a process of "core components analysis", in which a set of core components is derived through analysis of the existing registered models. The process is as objective as possible to avoid the possibility of the core components being yet another competing model. The core components are not introduced unless justified by existing models. The engineer resists the temptation of "fixing" undesirable qualities in registered models unless there are other registered models to justify the improvement.

The outputs of the analysis process are the set of core components plus the mappings from registered models to core components. Each dependency drawn between a registered item and a core component must have a justification for any differences. These justifications are then agreed with the submitters before publication on the registry website. The exercise of agreeing a mapping helps to expose the quality of the specific model. If there are legitimate justifications for the shape of the model, those will be declared, but if the model contains poor design or sloppy thinking, these should also be exposed because a good business justification cannot be agreed. This gives a powerful way to provide objective review feedback and improve the quality of submitted models, since there is often no genuine justification and the submitter can understand and agree this. Furthermore the improvements made through this process are in line with requirements brought by other models, and often the specific change brings the model closer to the others.

We also call the analysis process "simple ontology", because it is analogous to the agile programming practice of "simple design", where the design is only extended in response to incremental current requirements and not future requirements. New core components are created only in response to submitted models and never in response to the registrar's ideas about new subject matter concepts that might be useful in the future.

Core components analysis requires effort and is only performed for those areas of the registry in which the Highways Agency has current development or standardisation activity.

Core components can point out the most suitable models

One way to find out the most suitable model to suit a set of requirements is to start with the core components in that subject matter area, then find the related registered items with matching business purpose and with sound justifications.

Summary of value of core components analysis

• Makes similarities and differences explicit.
• Mappings process distinguishes justified design from flawed design.
• Generates objective feedback to submitters.
• Can use understanding when building translators.
• Signals recommended models for a specific business context.
• All the thinking is exposed to future system designers.