Metadata Registry for Intelligent Transport Systems

1. Metadata Registry for Intelligent Transport Systems

2. Intelligent Transport Systems

3. Intelligent Transport Systems

4. Intelligent Transport Systems

5. Intelligent Transport Systems

6. 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. Registry is important to I.T.S.

7. Operational In discussion Research contribution English Highways Agency UK Travel Information Community Highways Agency ITS Metadata Registry metadata registry community ITS Community

8. ISO 14817 Process Structure Convert to UML (via MOF- based tool) & include Express in UML Foundation ITS Metadata Registry Registry Structure UML XML Schema

10. Submission Paths

11. 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 Registry Population

12. Registry Top Level

13. 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 Card/Draft Recorded Qualified Preferred Registry Process

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. 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! Harmonisation of overlapping concepts

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. 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. Don’t add or “fix” except when justified by existing models. Derive Core Componentsfrom specific models

20. Not strictly compliant with UN/CEFACT Core Components But using the basic idea, registry UML representation copes Variety across systems

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. 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 Value of Core Components

25. 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 Conclusions on Results

26. www.itsregistry.org.uk