9th Open Forum on Metadata RegistriesHarmonization of Terminology, Ontology
and Metadata20th – 22nd March, 2006 , Kobe Japan.Day: 3 Slot No. P20
Name: Ian Cornwell
Organization: Mott MacDonald
Metadata Registry forIntelligent Transport Systems
9th Open Forum for Metadata Registry, Kobe, 2006
Intelligent Transport Systems
9th Open Forum for Metadata Registry, Kobe, 2006
Intelligent Transport Systems
9th Open Forum for Metadata Registry, Kobe, 2006
Intelligent Transport Systems
9th Open Forum for Metadata Registry, Kobe, 2006
Intelligent Transport Systems
9th Open Forum for Metadata Registry, Kobe, 2006
A goal of Intelligent Transport Systems: seamless door-to-door serviceswhich needs: integration of open systems from different
organisationsWithout 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.
9th Open Forum for Metadata Registry, Kobe, 2006
OperationalIn discussionResearch contribution
Highways Agency ITS Metadata Registry
ITS Communitymetadata registry community
EnglishHighways Agency
UK TravelInformationCommunity
9th Open Forum for Metadata Registry, Kobe, 2006
ISO 14817
Process
Structure
Registry Structure
UMLXML
Schema
ITS Metadata Registry
FoundationExpressin UML
Convertto UML(via MOF-based tool)& include
9th Open Forum for Metadata Registry, Kobe, 2006
9th Open Forum for Metadata Registry, Kobe, 2006
Submission Paths
9th Open Forum for Metadata Registry, Kobe, 2006
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
9th Open Forum for Metadata Registry, Kobe, 2006
Registry Top LevelSystem Interface IndexSubject Matter Index
Core Components
Registered Items
Functional Index
Meta Attributes
One of the most useful ways to access the registry if you are interested in a particular kind of content, rather than a particular system.
For users thinking in terms of the function to be performed rather than the subject matter area, this index contains functions from the European ITS framework architectire
The home of all registered items, organised by the registry status level achieved (card, draft, recorded, qualified, preferred).
A partially populated research area which explains the similarities and differences between models.
Supplementary information which can occasionally be useful as an index e.g. to see items by submitter.
Use this index if you want to examine a specific system , interface or model.
supplements
indexesindexes
indexes
9th Open Forum for Metadata Registry, Kobe, 2006
Card/Draft Recorded Qualified Preferred
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
9th Open Forum for Metadata Registry, Kobe, 2006
-OrigIncidentTime : Numeric [0..1]-OrigIncidentDate : Numeric [0..1]
-DestinOrganisation : string [0..1]
-OrigIncidentNum : string [0..1]
-OrigOrganisation : string-OrigIncidentURN : string
-Description : string [0..1]
-SubType : string [0..1]
-Northing : string [0..1]-Easting : string [0..1]
-Priority : string [0..1]
-MessageId : string
-CallOrigin : string
-Location : string
-Type : string
<<Message>>IncidentCreation
<<Message>>IncidentCreationAcknowledgement
-OrigIncidentDate : Numeric [0..1]-DestinIncidentURN : string [0..1]
-OrigIncidentURN : string [0..1]-OrigIncidentNum : string [0..1]
-ErrorDescription : string [0..1]
-OrigOrganisation : string-MessageId : string
-Successful : string
Person
-PersonDateOfBirth : Numeric [0..1]-PersonInvolvement : string [0..1]
-PersonForename : string [0..1]
-PersonComment : string [0..1]
-PersonSurname : string [0..1]
-PersonAddress : string [0..1]-PersonNumber : string [0..1]
-PersonSex : string [0..1]
Vehicle
-VehicleInvolvement : string [0..1]-VehicleComment : string [0..1]
-VehicleColour : string [0..1]-VehicleModel : string [0..1]-VehicleMake : string [0..1]
-VRM : string [0..1]-VIN : string [0..1]
CallerDetails
-CallerForename : string [0..1]-CallerSurname : string [0..1]
-CallerAddress : string [0..1]-CallerNumber : string [0..1]
-CallerMobile : string [0..1]
-CallerTitle : string [0..1]
1
0..1
PersonsInvolved
1
0..*
VehiclesInvolved1 0..*
<<0..1>>+elementVersionTime : DateTime [1]<<0..1>>+confirmationTime : DateTime [1]<<0..1>>+expiryTime : DateTime [1]<<0..1>>+stopTime : DateTime [1]
+inputTime : DateTime [1]+startTime : DateTime [1]
ElementTimestamps
<<0..1>>+probabilityCoded : PhqEnum [1]
<<0..1>>+messageReference : String [1]
<<0..1>>+codedDuration : DurEnum [1]
<<0..1>>+probabilityValue : Decimal [1]
<<0..1>>+durationValue : Duration [1]<<0..1>>+dayOfWeek : DowEnum [1]
<<0..1>>+qualityIndex : QinEnum [1]
<<0..1>>+dayUntil : DowEnum [1]
<<0..1>>+severity : SevEnum [1]<<0..1>>+forecast : Boolean [1]
<<0..1>>+cause : PhcEnum [1]
<<0..1>>+nature : NatEnum [1]
<<0..1>>+comment : String [1]
ElementQualification
SituationElement
<<0..1>>+sourceIdentification : String [1]
<<0..1>>+sourceType : SotEnum [1]<<0..1>>+sourceName : String [1]
SituationElementKeyType
...
ElementLocation
Consequence
Situation
Impact
+situation1..*
1
+impact0..1
1
+consequence0..1
1
+elementQualification0..1
1
+elementTimestamps1
1
1
+key1
1
1
+motoringConditions : MotoringConditionTypeEnum [0..1]Impact<<identifiable>>
SituationRecord
+situationRecordVersionTimestamp : DateTime [0..1]+situationRecordVersion : PositiveWholeNumber+situationRecordReference : String [0..1]
+forecast : ForecastEnum [0..1]+inputTime : DateTime [0..1]
+startTime : DateTime [0..1]+stopTime : DateTime [0..1]
+comment : String [0..1]
NonManagedCause
+causeType : CauseTypeEnum [0..1]+causeDescription : String [0..1]
<<identity>>SituationIdentifier
+keySituation : GUID
<<identifiable>>Situation
+TMCMessageReference : String [0..1]+situationSeverity : SeverityEnum [0..1]
SourceInformation
+sourceType : SourceTypeEnum [0..1]
+sourceIdentification : String [0..1]+sourceName : String [0..1]
<<identity>>RecordIdentifier
+keyRecord : GUID
RepeatingPeriod{}
Advice
-identity1
1
-cause0..1-consequence1
-relatedSituation0..*1
-identity11
0..1
1
0..1
1 0..1
1
0..*
1
1..*
1
{}0..1
1
Bottom upAgree and build on common data types
Top downITS Architecture, indexing of subject matter & function
Middle OutCore Components
Harmonisation TacticsDealing with multiple overlapping submissions
9th Open Forum for Metadata Registry, Kobe, 2006
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!
9th Open Forum for Metadata Registry, Kobe, 2006
Core ComponentBusinessInformation Entity
Specific business context Independent of business context
UN/CEFACT ebXML Core Components
9th Open Forum for Metadata Registry, Kobe, 2006
Core Components
Another specific model
Specific Model Item
A specific model
Specific Model Item
Core Component
Dependencies with justification through business context.
9th Open Forum for Metadata Registry, Kobe, 2006
Relate classes, attributes, associations
<<FK>>+MidasGoldAddress
+VehicleFlowCategory1+VehicleFlowCategory2+VehicleFlowCategory3+VehicleFlowCategory4
+TotalVehicleFlow
+NumberofLanes
+AverageSpeed
<<PK>>+rowID
+dtGenerated+dtReceived
+MidasCoId
+timestamp+dtInserted
MidasGoldData
MeasurementCharacteristics
-computationMethod : ComputationMethod-measurementAreaLength : LengthMetres
-measurementTime : dateTime
-smoothingFactor : decimal
-accuracy : percentage-period : duration
Flow
-percentageLongVehicles : percentage
-totalVehicles : nonNegativeInteger-totalPCU : nonNegativeInteger-axleFlow : nonNegativeInteger
CategoryFlow-categoryNumber : positiveInteger-totalVehicles : positiveInteger
AverageSpeed-averageSpeedKpH : SpeedKpH
MidasGoldLocation MeasurementSite
MeasuredValue
Measurement
publication-system specific
Not further refined
1
0..1
-FK_MidasGoldAddress1
0..*
9th Open Forum for Metadata Registry, Kobe, 2006
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.– Don’t add or “fix” except when justified by
existing models.
9th Open Forum for Metadata Registry, Kobe, 2006
Variety across systems
RoadsidePoint
Section_LRP
RoadSection
Section
Link
Not strictly compliant with UN/CEFACT Core Components
But using the basic idea, registry UML representation copes
9th Open Forum for Metadata Registry, Kobe, 2006
Build Conceptual Schema first…
MeasurementCharacteristics
IndividualVehicleSpeed
IndividualHeadway
MeasurementSite
AverageHeadway
MeasuredValue
AverageSpeed DetectionTime
Measurement
CategoryFlow
OccupancyFlow
Queue
* 1
10..1
1 0..1
1
1..*
1
0..*
• On the way to ontology• In one case we started with taxonomy
9th Open Forum for Metadata Registry, Kobe, 2006
…add attribute detail…
Occupancy
-concentration : ConcentrationVehiclesPerKm-occupancy : percentage
MeasurementCharacteristics
-computationMethod : ComputationMethod-measurementAreaLength : LengthMetres
-measurementTime : dateTime
-smoothingFactor : decimal
-accuracy : percentage-period : duration
Flow
-percentageLongVehicles : percentage
-totalVehicles : nonNegativeInteger-totalPCU : nonNegativeInteger-axleFlow : nonNegativeInteger
CategoryFlow-categoryNumber : positiveInteger-totalVehicles : positiveInteger
AverageSpeed-averageSpeedKpH : SpeedKpH
DetectionTime
-presenceTime : dateTime-passageTime : dateTime
-timeHeadway : duration
-arrivalTime : dateTime-exitTime : dateTime
-timeGap : duration
AverageHeadway-headway : LengthMetres
IndividualHeadway-headway : LengthMetres-gap : LengthMetres
Queue-queuePresent : boolean
IndividualVehicleSpeed-speedKpH : SpeedKpH
MeasurementSite
MeasuredValue
Measurement * 1
1
1..*
1
0..1
1
0..1
1
0..*
9th Open Forum for Metadata Registry, Kobe, 2006
…all built by considering mappings from existing models
Occupancy
-concentration : ConcentrationVehiclesPerKm-occupancy : percentage
MeasurementCharacteristics
-computationMethod : ComputationMethod-measurementAreaLength : LengthMetres
-measurementTime : dateTime
-smoothingFactor : decimal
-accuracy : percentage-period : duration
CategoryFlow-categoryNumber : positiveInteger-totalVehicles : positiveInteger
AverageSpeed-averageSpeedKpH : SpeedKpH
TrafficConditions+DelayAgainstExpected+DelayAgainstIdeal+J ourneyTime
+Occupancy+Speed
+Link
+Minute+Month
+Hour
+Year
+DayTimestamp
MeasurementSite
ClassifiedFlow+Category1+Category2+Category3+Category4
Measurement
Derived values out of scope at present
1
0..1
9th Open Forum for Metadata Registry, Kobe, 2006
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
9th Open Forum for Metadata Registry, Kobe, 2006
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
9th Open Forum for Metadata Registry, Kobe, 2006
www.itsregistry.org.uk