Metadata Registry for

1
Metadata Registry for Intelligent Transport
Systems
2
Intelligent Transport Systems
3
Intelligent Transport Systems
4
Intelligent Transport Systems
5
Intelligent Transport Systems
6
Registry is important to I.T.S.

• A goal of Intelligent Transport Systems
• seamless door-to-door services
• which needs
• integration of open systems from different
  organisations
• Without a registry this goal will be achieved
  later and at greater cost, as various
  organisations slowly find out how to integrate
  fragments of the overall service.

7
Highways Agency ITS Metadata Registry
metadata registry community
ITS Community
8
Registry Structure
UML
XML Schema
9
(No Transcript)
10
Submission Paths
11
Registry Population

• 14 major models with over 15,000 registered items
• 10 different submitting organisations
• 3 out of 14 submissions as XML Schema
• 7 out of 14 as XMI from different UML tools
• XMI versions can vary but can bridge via XSL

12
Registry Top Level
13
Registry Process

• Mapped ISO 14817 roles to existing bodies
• All status levels found to be useful
• Process drove up the quality of submissions
• Deeper refinement needed to achieve harmonisation

14
Harmonisation TacticsDealing with multiple
overlapping submissions
Top down ITS Architecture, indexing of subject
matter function
Middle Out Core Components
Bottom up Agree and build on common data types
15
Harmonisation of overlapping concepts

• Rely on submitters changing submissions?
• Make attributes the unit of re-use?
• Tag common attributes across classes?
• One union class with options context?
• Core Components!

16
UN/CEFACT ebXML Core Components
Independent of business context
Specific business context
Business Information Entity
Core Component
17
Core Components
18
Relate classes, attributes, associations
19
Derive Core Componentsfrom specific models

• Our Core Components are actually superset of
  concepts in specific models, in a common subject
  matter area.
• Process as objective as possible to avoid Core
  Components being yet another competing model.
• Dont add or fix except when justified by
  existing models.

20
Variety across systems

• Not strictly compliant with UN/CEFACT Core
  Components
• But using the basic idea, registry UML
  representation copes

21
Build Conceptual Schema first

• On the way to ontology
• In one case we started with taxonomy

22
add attribute detail
23
all built by considering mappings from existing
models
24
Value of Core Components

• Makes the similarities differences explicit
• Mappings process distinguishes justified design
  from flawed design
• Generates objective feedback to submitters
• Use understanding when building translators
• Use to identify candidates for recommendations
  (or preferred status), awarded in a specific
  business context.
• All the thinking exposed to future designers

25
Conclusions on Results

• UML/XMI has given a successful technical
  foundation
• Keeping costs low through alignment with standard
  tools
• Only 3 out of 14 submissions as XML Schema
• Harmonisation in a mature domain needs something
  more than published registry processes
• Core Components analysis evolving as a technique
  to fill this gap

26
www.itsregistry.org.uk