Metadata Registry for Intelligent Transport Systems

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








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.


OperationalIn discussionResearch contribution

Highways Agency ITS Metadata Registry

ITS Communitymetadata registry community

EnglishHighways Agency

UK TravelInformationCommunity


ISO 14817

Process

Structure

Registry Structure

UMLXML

Schema

ITS Metadata Registry

FoundationExpressin UML

Convertto UML(via MOF-based tool)& include



Submission Paths


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


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


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


-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


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!


Core ComponentBusinessInformation Entity

Specific business context Independent of business context

UN/CEFACT ebXML Core Components


Core Components

Another specific model

Specific Model Item

A specific model

Specific Model Item

Core Component

Dependencies with justification through business context.


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..*


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.


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


Build Conceptual Schema first…


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


…add attribute detail…

Occupancy

-concentration : ConcentrationVehiclesPerKm-occupancy : percentage






Flow

-percentageLongVehicles : percentage

-totalVehicles : nonNegativeInteger-totalPCU : nonNegativeInteger-axleFlow : nonNegativeInteger



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..*


…all built by considering mappings from existing models

Occupancy

-concentration : ConcentrationVehiclesPerKm-occupancy : percentage








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


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


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


www.itsregistry.org.uk

Date post:	08-Feb-2016
Category:	Documents
Upload:	zona
View:	40 times
Download:	0 times

Metadata Registry for Intelligent Transport Systems

Documents