The following are my notes from the 4 February 1997 working group meeting held in
D.C. I am distributing them in this forum to serve as memory-joggers as you
prepare inputs and comments for the next meeting. They are NOT intended to
serve as official meeting minutes; those will be distributed by Charlie
Herget, IEEE ITS DD & MST Project Manager.
One of the initial tasks for which we are supporting IEEE as consultants
involves framing the major technical (architectural, process, etc.) issues
and approaches, as drivers for the development of the ITS DD standard and
guidelines. I recorded these notes to support that process. Additionally, I
see the notes as stimulating discussions in this electronic forum and
aiding in the development of inputs to the next WG meeting. If you have
comments, or feel that any point in the notes does not accurately reflect
the discussions at the meeting, please let me know and I will revise the
IEEE ITS DD & MST Contractor
Introduction - Valerie Shuman
IEEE ITS DD & MST Working Group Chair
IEEE ITS DD and MST Objectives, Preliminary Findings and Topics
for Discussion - Tony Sarris and Burt Parker
See copies of presentation handout.
EPA Data Registry- Bruce Bargmeyer and Joe Leahy
Currently 5000 legacy data elements. Not much work has been done to-date on
analyzing and reconciling those data elements, so they are not really data
concepts and the registry currently does not contain much of a conceptual
schema. There are ca. 100 data concepts such as Date, Longitude, etc.
Definitions are given only in natural language. Most of the meta data is of
a data administrative nature.
Mike Schagrin (DoT) emphasized DoT's interest in promoting harmonization
and reuse of data concepts. He wondered why reuse appeared to be noted as
'optional' on one of the slides. It was explained that the word 'optional'
referred not to the concept of reuse in general but rather to a specific
bullet point which stated that one objective for the ITS DD standard is to
enable any ITS subsystem data dictionary to "describe locally the nature
and structure of ITS subsystem data and processes and promote reuse". This
would be in addition to the reuse that would come inherently from the
description in any ITS data dictionary of common, globally-used data
concepts. This slide was based on the output of the kick-off workshop last
November, which noted a consensus position that information interchange
among ITS subsystems (via messages) was the primary objective of the DD
project, but that the various subsystem DDs might also want to use the same
approaches locally to enable easier harmonization across subsystems and
promote additional reuse.
There was considerable discussion of the issues surrounding the notion of a
'central registry'. Many of the attendees seemed at least willing to
consider the pros and cons of the idea. The most skeptical was the public
transit (APTS) subsystem representative. Later discussions indicated that
the primary concern of the APTS group was related to authority/control
issues; there was a strong desire on the part of APTS to retain control
over those data concepts for which they are the producer/owner or in which
they are at least a large stakeholder. Other subsystem groups expressed
concern about this, too, but not to as great a degree. There was also some
concern about the size of the effort if all ITS data elements/data concepts
have to be put into a registry.
1. Central Registry [Note: the word 'central' was found to be embed lots of
different notions such as physical implementation, control/authority, etc.,
and was dropped to avoid confusion at this point]
2. Common vs. specialized data: Common data include general concepts like
Vehicle, Customer and Link, and core data elements like Location,Color and
Identifier. Specialized data are related specifically to some subsystem
3. Global vs. local usage of data: Global data is used by at least two or
more subsystems (although one subsystem may be the primary or sole
originator of the actual data). Local data is used only within a single
subsystem/application context, or at least within a small number of
4. Authority (data ownership and stewardship): This deals with who has
ressponsibility for the data. It may be exclusively the originating party,
or other subsystems/applications may also have a role if they are important
stakeholders in the data (for example, if the data originates elsewhere,
but is used heavily in some other subsystem).
5. Distribution of physical aspects of a registry and related data
(database) management in a distributed DBMS environment
6. Enforced (mandatory) standardization
- format (syntax), including possible naming conventions
- meaning (semantics)
7. Nature of usage: What is the data used for, e.g., statistical analysis,
reporting, control, business/financial accounting or other related
Central Registry [Note: the word 'central' was found to be embed lots of
different notions such as physical implementation, control/authority, etc.,
and was dropped to avoid confusion at this point]
Q: Does it need to be a single, physical artifact?
A: No, it is possibly a 'central' logical rather physical registry, but
this brings up the distributed data mgmt. issues noted above.
1. What is this? [Is it an actual DD with all the meta data, perhaps
replicated, or an index into the actual DDs (perhaps with some meta data
directly residing here)?]
2. Where is it?
3. Who operates it?
4. Who pays for it?
5. Who decides the content and how (i.e., on what basis)?
6. What tool(s) might be used to support its creation and on-going
In any case, this registry must follow the ITS DD standard.
1. Common data and global usage: "I probably never really had control, but
if I thought I did, I give it up now." Things like geospatial meta data for
which there might be standards even outside the ITS domain. This category
could also include very general ITS domain concepts like Vehicle
2. Specialized and global usage: "I probably have control currently, but I
recognize my data is used by other subsystems, so I may be willing to give
up some control, in some cases at least." Examples might be emergency data
that gets used within the ATIS and APTS subsystems.
3. Specialized and local usage: "I have control, but no one else cares
normally anyway." The one notable exception is to promote reuse. When a
subsystem wants to add a new data concept, they should be able to check to
see if it, or something similar or related to it, is already in use in some
other subsystem. What might be local and specialized at one point in time,
might become global and common at some other time.
See also Bob Barrett's graphic.
Note: Of the TMDD, APTS and ATIS subsystems, no one felt like they had the
necessary supporting data to give 'guessimates' of the percentages for each
of these categories (although in the case of ATIS, Bob noted that they
produce very little data of their own; they basically repackage other data
into 'messages' that are useful to their domain's service/functional
VOTES [see Minutes for the official voting results]
1. Do we need a shared data dictionary: Yes.
2. How should that be physically realized (not at detailed level, but in
the sense of a general architectural approach)?
A. Interim: Do we want a single physical registry and should its structure
and guidelines for use (the later being its 'process' per Andy) be based on
IS 11179? Yes. The purpose is just to get some experience attempting this
sort of thing. It may help with the identification of requirements and the
testing of approaches. It may also help provide a better understanding of
the nature of ITS meta data and inter-relationships among that meta data.
Stratification/classification of the meta data was also noted as an
important requirement, and this effort may provide some insight into needs
in that area.
a. What tool should be used to support this? The goal is to be 'tool
neutral' in the sense of not appearing to favor a single vendor's tool, but
at the same time to make the existing meta data as visible and accessible
as possible, as quickly as possible, to help in this early analysis phase.
The analytical support tool should deal with: data structures, data
classification and the process of data analysis and registration. It was
noted that classification is not really part of the scope of the DD
standard or guidelines, although the DD meta structures should support
classification schemas, including various kinds of them (see also Paula
Okunieff's APTS presentation).
There was discussion of both the EPA Registry and MS Access. Bruce
Einsenhart and the Nat. Arch. team noted that they are using MS Access, as
are TMDD and APTS, and they have funding to support some work in this area.
Andy Schoka noted a strong preference for the EPA Registry over MS Access.
The group noted that both tools could support the application of 11179, and
both are based on COTS relational DBMS technology. MS Access is cheaper, as
the EPA Registry is built on a Oracle server and runs PowerBuilder as its
B. Longer-Run: Need more time to decide. Burt Parker noted that this
affects the guidelines of use, although it was flet that the same meta
structures should/could be used either way, so the DD standard itself would
likely be the same in either case. Burt agreed to draft a white-paper
discussing the issues and options related to this topic area. Questions
related to this include:
- Does it include all data (although some inclusion may be by reference,
e.g., spatial meta data might be handled by a listing of the data element
and a pointer to FGDC, rather than incorporating/replicating all the FGDC
material into this registry directly). What about all the local DD meta
data: could it be handled by a pointer, too, or should it be replicated?
This has an impact on the guidelines due to distribution and associated
procedural/administration issues as noted above.
Current DD effort encompasses about 500 data elements. They are using MS
Access. They have looked at IS 11179 and have noted for interim work a
subset of meta attributes that they feel are most applicable to their
current effort (see separate TMDD document).
The TMDD 'national' DD is a real DD with meta level attributes and
definitions (both based on IS 11179), whereas there are many specific
TM-related application DBMSs. Many or most of these claim to have their own
[albeit limited] data dictionaries. For example, if the application DBMS is
Oracle RDBMS-based, the Oracle schema serves as a limited data
Synonyms in the TMDD case are often not really referring to the exact same
data concepts; often several apparent synonyms are all slight variations on
the same [implicit] general data concept.
Some past or current efforts are addressing the Conceptual Schema: ISO
TC204 APTS component, the APTS NTGIS aspect, and the APTS portion of the
Some past or current efforts are addressing the Logical [External] Schema:
TCIP classification work and the APTS DD work. These address the
Some past or current efforts are addressing the Physical [Internal] Schema:
SAE J1587, Datax EDIFACT, TCIP, NTCI/Geospatial transfer. These address the
transfer, storage and/or implementation view.
Then there are specific applications, which deal with the instances of the
data: AVL, CAD, scheduling, etc.
There are two approaches to interchange:
- Translation, i.e., interchange which is based on a direct mapping.
Although specific criteria to identify what data is best suited to this
approach has not been developed yet, this would largely be common data. The
criteria could be stated in general as follows: fairly static; important
(i.e., where you can't afford any question of ambiguity and you are willing
to enforce standardization to ensure consistency; in other words, by
agreeing to deliberately reduce variability).
- Reconciliation, i.e., interchange which requires some reconciliation of
differences in the meaning/semantics.
They use multiple classification schemes for APTS data concepts and they
therefore need the IT S DD meta structures to be able to support this
ATIS may be unique among ITS subsystems in that few, if any, data
elements/data concepts are specialized to, and created and used locally
for, ATIS only. ATIS basically involves application of other subsystems'
data elements/data concepts (from their DDs) through repackaging of that
data into ATIS-specific messages. The exception might be algorithms for
statistical calculations against other subsystems' data (per Bob and Ray
Starsman). In a broad sense this is part of the packaging of other data
into ATIS messages, but the algorithms for the calculations are ATIS data
concepts that may need to be kept in the ATIS DD.
Refer also to Bob's graphic showing overlap of TMDD, APTS and
There are 20 core messages in the national architecture, supported at the
detailed level by some 2500 data elements contained in 80 major
Nat. Arch. and CVISN vs. TMC, TME, ATIS, APTS, EMERG, TMDD
- The National Architecture DD, and the CVISN subsystem DD (the one
subsystem DD which has been completed already), as well as some other more
general data sources (DSRC and NTCIP Object Defs) are being used as sources
for more specific DDs that are being developed or proposed for development.
For example, a number of specific standard EDI DDs are being produced
relating to commercial vehicles and associated electronic commerce. This is
at the level of DD content (i.e., data elements/data concepts in the DDs),
The next meeting will still be oriented to gathering requirements. It will
also begin to address MST issues. ASN.1 and related matters will be part of
discussions in this topic area (Tom Kurihara and Tony Sarris are to supply
some input for this discussion).
Andy Schoka (with input from Paul Hawes, Tom Kurihara and Allan Kirson and
anyone else who wants to provide input) is the focal point for terminology
and TC204 liaison issues.
Bruce Eisenhart (with input from Paula Okunieff and Tony Sarris) is the
focal point for classification/taxonomic inputs.
Back to Home Page E-mail to Sue Vogel, Staff