Included below is a white paper on the data registry options. Following the

white paper are the substantive comments I've received to date, together

with my responses to them.

Per Valerie's agenda at the DD Working Group meeting on 4 February 1997, I will give a summary report on the white paper issues/comments at our WG meeting.

Please address any further comments, questions, suggestions, etc. as soon as

possible directly to me at parkerbg@idsonline.com.

Regards,

Burt

===================================

Background

A standard will be prepared for ITS data dictionaries. This standard will

specify the underlying metadata schema to be used in identifying, defining,

and documenting ITS data.

Guidelines will also be prepared, based upon the ITS data dictionary

(ITS-DD) standard, for the development and use of ITS data dictionaries.

The ITS-DD working group has determined that registration of ITS data

elements is desired. Such registration will facilitate meaningful exchange

of data and information within the ITS community. Thus, the ITS-DD

standard, and associated guidelines document, will extend traditional data

dictionary concepts. One such extension will include registration concepts

similar to those of ISO/IEC 11179 standard, Part 6.

Agreement on a basic concept of operations for ITS data dictionaries and

registration activities is necessary to most effectively prepare the ITS

data dictionaries guidelines document.

OPTIONS

Three options exist for registering ITS data:

1. Register data in a physically singular central ITS data registry

(Option name: 'One') .

[Note: This option implies that the data dictionaries of each functional area would, ideally, a subset of the metadata schema of the central dataregistry. The metadata schema of the central registry will be specified in the ITS-DD standard. The guidelines document would recommend the subset of metadata appropriate for the functional areas data dictionaries. Presumably, for example, the functional area data dictionary schemas would NOT require ALL the registration-oriented metadata of the ITS-DD standard. Nor would the functional areas accomplish INDEPENDENT data registration activities. This option assumes that there is one ITS enterprise with multiple 'responsible organizations' (e.g., functional areas). Further, it assumes that a common data registry is useful to identify shared data and

data that can be reused within the ITS enterprise. The Guidelines document would specify and elaborate.]

2. Register data in multiple physical data registries, e.g., one 'standard' registry for each ITS functional area (Option name: 'Many'). [Note: This option implies that each functionally oriented standard data dictionary uses the COMPLETE metadata schema of the ITS-DD standard. This metadata includes ALL registration metadata. Thus, each functional area would accomplish independent data registration activities for some specified

set of data. In effect, the functionally oriented standard data dictionaries become independent data element registries. The Guidelines document would specify and elaborate.]

3. Register data in multiple (functional area) physical data registries AND in a physically singular central ITS data registry. (Option name: 'One/Many'). [Note: This option implies that each functional area has its own data registry and registration activities. It also implies that an ITS 'corporate' data registry is established with overarching registration responsibility. This option assumes each functional area in ITS is an independent enterprise. Further, each such functional area finds it useful to establish a 'higher level' 'corporate' data registry to register data from their functional area which they have standardized within the functional area. The intent of such registratiion would be to propose functionally standardized data for standardization at the ITS 'corporate'

level for use across all functional areas. The contents of the functional area data registeries and that of the central ITS data registry may, or may not, be fully redundant, depending upon the needs of the ITS community. However, the 11179 mindset is that such 'higher level' registries would NOT contain all registered data from the functional area data registries. It would contain only candidate data elements for standardization at the ITS

'corporate' level that are already 'standardized' in a lower level (functional area) data registry. The Guidelines document would specify and elaborate the choices among these options.]

Pros and cons of data registration options:

Option One

PROS

All descriptive metadata about all data elements is in one place

Eases identification of common data

Maximizes information access & sharing

Facilitates standardization of ITS data

(Valid distinctions in data concept meanings among the functional

areas can be retained. However, the variations are all registered in

one central registry. This makes comparisions among data concepts

easier. This MAY result in agreement on one or more standard data

concepts that encompass those of the functional areas.)

Can completely identify what data is where

Simplified functional area data dictionary metadata standards

Minimum registration activities burden

Permits registration of any data per functional area authority

Consistent with ISO/IEC 11179 data registry concepts

CONS

Potential developmental bottleneck

(i.e., may slow development of functionally oriented standard

data dictionaries and/or systems development)

Perception of loss of control of data element concepts

Requires standardization of data at ITS community level

(A single organizational focal point is required to maintain

the registry itself. Update authority may be distributed among

the functional areas)

Option: Many

PROS

Each functional area is independent of others

(e.g., each standardizes its own data elements)

No developmental bottlenecks

Permits registration of any data per functional area authority

CONS

Descriptive metadata about data elements is in multiple places

Difficult to understand what data is where

Difficult to identify common data

Information sharing requires bundling of metadata with data in information

interchanges

Potential duplication of registry efforts & expenses

Increased risk of different/incompatible metadata among registries

Impedes standardization of ITS data

Permits independent standardization of data by functional area

(In the ISO 11179 mindset, the 'responsible organization'[e.g., each

ITS functional area) has update authority to independently update

the status of data elements all the way through the quality level

of 'certified'. Typically, the registrar confirms such status updates

after administrative review for procedural correctness. Update of the

status to 'standardized', requires community buy-in [i.e., by all ITS

functional areas]. Thus, individual ITS functional areas cannot

unilaterally establish standard ITS data elements. They establish

functional area 'certified' data elements (that is, data elements

for which all mandatory attributes are present and all such attributes

meet ISO 11179 quality standards.)

Inconsistent with ISO/IEC 11179 data registry concepts

(ISO 11179 assumes an intent to share data/information among

participants. It prescribes and 'overarching' or 'higher level' data

registry as the mechanism to achieve this. In other words, 11179

does not contemplate bundling of metadata or metadata pointers with

data elements as a means for resolution of semantics among information

exchange partners. It assumes a central registry within a domain of

discourse in order to permit 'blind' transfers of 'standard' data.

A recipient of a data + metadata packet may STILL have no clue what

to do with it because of an inability to map it into their data

environment. Thus, since this option is inconsistent with ISO 11179

registry concepts, a wholely new mechanism is required to specify how

ITS level data interchange and standardization is to be accomplished.)

Option One/Many

PROS

Each functional area is independent of others

No developmental bottlenecks

All descriptive metadata about data elements can be found in one place

Permits registration of any data per functional area authority

Not inconsistent with ISO/IEC 11179 data registry concepts

CONS

Descriptive metadata about data elements is in multiple places

Duplicate data element information

Duplication of registry efforts & expenses

Synchronization of registries' contents is complicated

Risk of different/incompatible metadata among registries

Risk of missing data information in the central registry

Maximum registration activities burden (local and central)

Slows standardization of ITS data

Requires independent standardization of data by functional area and

're-standardization' at ITS level

=====================================

Email responses received to date:

>Date: Wed, 12 Feb 1997 18:00:13 -0500

>To: ieeestds-its-dd@majordomo.ieee.org

>From: Tom Kurihara <tkurihara@vax.ite.org>

>Subject: Re: DD White paper

>

>Burt: Very well done and quickly, too.

>

>Is it feasible to consider a client-server architecture with the metadata

>scheme based on an ITS-wide categorization scheme (taxonomy, data

>architecture, data model, et al.) or ownership hierarchy (functional,

>component, and local) where physical central (single) or distributed

>(multiple) becomes a more efficient way of managing data for which

>organizations have ownership or stewardship? Similar to the charts of

>accounts for financial systems. As long as there is a centrally controlled

>chart of accounts, any number of special accounts, etc., can be operated at

>the local level. Integrity is maintained through the roll-up process based

>on the chart of accounts and account subclasses. It does not address

>financial integrity or efficiency in daily operations, just for roll-up to

>arrive at an enterprise financial statement.

>

>What appeals to me is the centrally controlled categorization scheme and

>associated naming conventions that provides the flexibility for synonyms,

>alias, legacy, deprecated, and obsolescent terms, plus bridging mechanisms

>that permit traceability to deprecated or obsolescent terms for

>interoperability among several generations of systems.

>

>I am comfortable with your alternatives. Well done. TomK

>

-----------------------------------------

At 02:57 PM 2/13/97, you wrote:

>Date: 13 Feb 1997 11:28:41 -0800

>From: Robert M Barrett <Robert.M.Barrett@jpl.nasa.gov>

>To: parkerbg@idsonline.com (Return requested) (Receipt notification requested)

>Subject: Re: DD White Paper

>

> Burt,

>

> Appreciate the fast response - helps when discussions are in close

> temporal relation to the issues.

>

> Conceptually I like the 'One' option. Not sure if it can be

> implemented in ITS.

I truly believe any other option is ill-advised, at least in the long run.

Either the ITS community wants to share and REUSE data, or they don't.

There's no halfway because members of the ITS community cannot know today

what data they will want to share tomorrow. It comes down to 'what is the

ITS enterprise'? Perhaps you have a view on that question?

> Of the three options you discuss, one/many option comes closest to

> meeting the needs expressed during the last meeting. The "corporate"

> data registry would ease the idea of reuse of data elements among the

> various systems; while the functional data dictionaries would retain

> the control that some believe is necessary for their data elements.

> The idea that there are no developmental bottle necks is important as

> well, given the short fuse on some of these projects.

What I haven't been able to get across is that the corporate registry can

serve both 'corporate' and functional needs, at the same time, without

delaying anything or relinquishing any control. The functional areas will

still have their unencumbered local data dictionaries; they just won't have

a 'full blown' registry; nor do they need it (at least in my view). The

basic problem with option three is that it assumes that functional data

elements are 'standardized' first at the functional level and then

're-standardized' at the ITS level. Do we really have the time to take such

a hands-off, leisurely approach to 'standardizing' ITS data? If so, OK...

I have no way to know. That's sort of like negotiating after the fact as to

what the Interstate Highway standard data is. It'll be MUCH more expensive

to 're-negotiate' standard ITS data than to throw all data into 'the hopper'and have everyone have a look at what might/could be standard (without

holding up functional area activities).

The other aspect is that I would be loath to saddle the functional area data

dictionaries with the registration chore, even just for their data (and that

assumes that the functional areas can agree as to which data is whose..., I

doubt they can).

> I would challenge the concepts that:

>

> Synchronization of registries' content is complicated

> Risk of differing/incompatible metadata among registries

> Slows standardization of ITS data

>

> or perhaps these are challenges that the Standard for ITS data

> dictionaries and the other data dictionaries should deal with and

> overcome?

Well, sorta. The standard is the standard..., end of discussion. It says

'what'; it does NOT say who and how, except in a generic sense (responsible

organization, submitting organization, registrar, etc.!!! The issue is

really the 'guidelines'; this is where the who and how is specified.

Moreover, since they are guidelines, they have NO enforceability vis a vie

the 'standard'. Thus, assuming a guidelines perspective, the above issues

are very germane.

> Please let me see the other responses you receive on the white paper.

> Saw Tom K's response, looked good, but need a chance to absorb some of

> what he suggests.

Will do, as I respond to them. I'm responding to yours first merely because

it was the last one in at the moment and I have been tied up on other stuff

and not able to respond to other comments to date (though I certainly will!).

Thanx for your remarks....

Regards,

Burt

----------------------------------------

Bruce, Tom,..

I agree with Bruce, Tom. My understanding is that the IEEE ITS-DD standard

is to applicable to any data dictionary under the ITS umbrella. However, I

suspect that not all of the ITS DD standard would be applicable to all ITS

data dictionaries; some would only be relevant to data registry(ies). The

guidelines document would say which are relevant to which type of 'data

dictionary'.

Tom, I have to say that I'm totally lost in your discourse on 'levels' of

data dictionary. I haven't a sense, YET, of what the NA nd CVISN DDa. or

other 'higher level' ones are. And, I don't have a clear understanding what

'higher level' means in relation to the NA data dictionary, for example. My

sense to date is that these have conceptual or logical level of detail data

element contents and not the physical or 'application' level content that,

for example Lyle's has. This is a non-problem since a based upon

ISO11179/ANSI X3L8metamodel/ISO 3-schema concepts can contain both at the

same time..., and MORE IMPORTANTLY, map each to each other.

Anyway, as I see it (thru the glass darkly) at this point, there are

basically three potential 'levels' of data dictionairies within the ITS

umbrella. First, at the most basic, would be the application-level data

dictionaries associated with the DBMSs hosting actual application databases.

[These are, in my mind, what Lyle refers to as 'all the data dictionaries

out there that his data dictionary is pulling in or together] Next, are

the, I'll call them, 'functional area standard data dictionaries'. [One

example of this level is Lyle's data dictionary, and also, for that matter,

the architectural data dictionary.] The third level is the 'ITS-corporate'

or 'ITS-enterprise' data REGISTRY. Here is where, ideally, ALL ITS data,

from whatever functional area (to include architectural functional area) is

poured into, AS IS!! From there folks can work on commonalities, overlaps,

standardization, OR NOT! Any, or all, of these levels may contain the

conceptual/logical/physical 'level' of detail or not, as may be appropriate.

Regards,

Burt

-----------------------------------

Date: Thu, 13 Feb 1997 14:20:00 -0600

From: "Allan Kirson-G10260" <Allan_Kirson-G10260@email.mot.com>

Subject: Re[2]: DD White paper

To: parkerbg@idsonline.com

Cc: tkurihara@vax.ite.org

Burt,

I agree with Tom's comments - a client-server or distributed dbms seems to

me to

be the optimum. Stewardship can be handled through read/write access

permissions

Regards,

Allan

---------------------------------------

>Date: Fri, 14 Feb 1997 08:48:38 -0700

>To: Tom Kurihara <tkurihara@vax.ite.org>

>From: "Anthony K. Sarris" <tony@ontek.com>

>Subject: Re: DD White Paper

>Cc: "Burton G. Parker" <parkerbg@idsonline.com>, lsaxton@crosslink.net,

> bruce.eisenhart@lmco.com

>

>Tom,

>

>Some thoughts on what you wrote, none of which seems 'left field' to me;

>they seem like reasonable questions.

>

>>Burt: Again, it's good work. In reading my ITS DD meeting notes, I had

>>recorded that Bruce Eisenhart, ITS National Architecture (NA) Team,

>>mentioned that the NA and CVISN DDs are at a level higher or a higher level

>>then what is being developed by TMDD, and it may also be true to some degree

>>for ATIS and TCIP DDs.

>>

>>My passing thought is that if it is likely that there are different levels

>>of detail for ITS DDs, then we would be best served if the levels were

>>categorized. (Categorization could contribute to the naming conventions and

>>conformance checking.)

>

>This is the issue I was trying to tease out when noting such criteria for

>differentiation as:

>

>1. Common vs. specialized data

>2. Global vs. local usage

>

>during the meeting (see my meeting notes). I think any of the ITS DDs being

>talked about could have elements and combinations of each, but the relative

>weight would be skewed somewhat by the purpose and associated perspective

>of the DD. For example, yes, I would expect the Nat. Arch. DD to contain

>'higher level' data concepts where higher level means things that are

>common across a number of application areas like all the geospatial data

>concepts and general ITS concepts like Vehicle, Transport (the verb),

>Customer, etc. I would expect the CVISN DD to contain a large number of

>commercial business data concepts that might not be found in the other ITS

>DDs. TMDD would contain traffic management data concepts, some of which

>might be used locally only to TM applications, but others which might feed

>other applications or be fed from other applications (like emergency data).

>

>Knowing the nature of data in any particular DD would be helpful, as would

>understanding the differences among data in various DDs. The ITS DD

>standard and guidelines need to be applicable across the whole spectrum, or

>if something is simply too unique, then to at least note those exceptions.

>I feel that the underlying meta data structures in the ITS DD standard

>should be the same in any case. They *should* be basically content-neutral.

>However, some of the guidelines (processes and procedures) would differ.

>Burt's work on IS 11179 Part 6 Registration is based largely on presuming a

>uniform way to treat all data for some 'enterprise', where the whole of ITS

>would be the most likely notion of enterprise (here again, things could be

>excluded by exception). Therefore the interest in a central registry that

>treats all data concepts under the same umbrella and ensures easy access

>and visbility across the various ITS applications. This would not preclude

>some low-level (say application-specific) DDs, but would in any case place

>the main thrust at an ITS central registry. The more separate DDs you

>introduce, and the higher their reach, the more you get into the option

>where you need a mixed environment. That may be what is needed, but as Burt

>has pointed out, it introduces some additional, and substantial, data

>administration procedural burdens and there are costs associated with those.

>

>>As I read it, your white paper addresses the physical

>>instance of an interim DD for the TMDD-equivalent level of DD not one that

>>is at the NA-equivalent level of DD.

>

>No. The idea would be that regardless of which option is chosen, all DDs

>are covered. The question is the relative role and position of each kind or

>category of DD (or at least the data concepts associated with them) in the

>overall ITS framework. 'Logically' they are all accounted for the same, but

>physically and in terms of conops, there are major differences among the

>three options. Again, I think the meta-structures are quite neutral to all

>three. There is also the question of to what degree the data concepts would

>be standardized, in the sense of having them harmonized across applications

>and have update authority reside in some central authority (which could

>well be a committee comprised of representatives from all ITS stakeholders,

>not one group that dictates to the others -- but procedurally it would act

>as the single focal point for authority). The more data concepts are

>standardized, the 'dumber' the messages among DDs can be, as there will be

>inherently less ambiguity in meaning. Polly noted this point in her

>presentation quite well. I was impressed that that point came up.

>

>>Following-on to that thought, the IEEE ITS DD effort is intended to provide

>>guidelines for the ITS NA-level DD, not TMDD-level DD. If so, then would

>>your white paper perspective change from what you have written or would

>>there be another set of alternatives to look at if a metadata directory were

>>to be developed and operated for the NA-level DD (metadata DD) and that

>>there be distributed TMDD-level DDs and even local application system

>>implementation and programming language specific DDs operating at local,

>>regional, cross-cutting domain specific instances, e.g., ORNL location

>>reference datum and LRMS, and financial transaction and smart-card TAG

>>registration; and non-cross-cutting domain specific instances such as bus

>>stop naming and identifying nomenclature?

>

>See above. Each of the options in Burt's white-paper is targeted at

>supporting many levels and categories of 'logical' ITS DDs. Their physical

>manifestation and procedural conops would change based on which option is

>selected.

>

>>>Is this getting too deep? Or is it my depth of confusion? Lacking a

>>ConOps or succinct statement of operational and performance requirements to

>>relate to, I feel adrift most of the time.

>

>Agreed. That's what the white-paper is the tip of the iceberg for, but Burt

>can't write the 'conops' (part of the guidelines) until it has been decided

>how the ITS participants want to operate. That's the purpose of this

>initial phase of the WG.

>

>>>Bruce: Did I miss the explanation in the SRD or about system management

>>because I did not take the time to read all of the NA documents looking for

>>registration responsibilities at the institutional level of the NA? TomK

>

>That's a good question: I also could not find a place where these sorts of

>procedural issues were specified. I don't believe that was the focus or

>intent of the initial work. But earlier DD/strike force meetings and the

>kick-off meeting tended to lean toward more local (application) autonomy

>and less centralization. Was that just a natural result of the global nat.

>arch. being largely completed and the work proceeding then at more local,

>functional/application-oriented levels?

>

>Tony Sarris

>tony@ontek.com

---------------------------------

-----------------------------------------

Regards,

Burt

Warms my heart, Bruce!

Regards,

Burt

>From: bruce.eisenhart@lmco.com

>Date: Fri, 14 Feb 97 11:07:14 EST

>To: parkerbg%idsonline.com@inetgw.fs.lmco.com

>Subject: (U)Comments to DD White Paper

>

>Burt, I think that option 1 is the only way to go- for several reasons.

>

>1.It has such important PROS- particularly maximizing of information access

>and sharing. I think that is critical in the next year.

>

>2. I dont think the CONS are significant- I dont believe the registry will be

>a bottleneck to development because the focus initially is having a place for

>data interchange and analysis- the only impact I forsee initially is to allow

>a wider group to point out disconnects and overlaps. Conceivably that could

>causean functional DD effort to have to expend more effort to resolve issues,

>but that is a critical function of all the DD efforts. These DDs are not being

>created in a functional vacuum. They need to coordinate with each other. I

>also dont think each functional area losses any control while we are in the

>developmental stage. The idea of the interim registry is to hold draft data

>elements. At some time in the future the draft elements will become

>standardized, but that will be with the full participation of each functional

>consensus group.

>

>3.The individual SDO efforts are not currently funded to perform individual

>data registries. Amendments to each Project Plan (or new project plans) would

>be required to support this. And I agree this is a lot of duplication of

>effort.

>

>You asked a question in the response to Bob Barrett about :"what is the ITS

>enterprise?" While it is true that each functional area has a set of

>stakeholders, the days when each group can operate in isolation are over. The

>essence of ITS (and the ITI) is the integration of systems. This requires an

>overall ITS view, and was in fact one of the key reasons the DOT created a

>National Architecture.So while there will be functional differences in the wa

>y data is defined (based on legacies and differences in how the data is used) w

>e need to minimize these differences, and develop a set of data element definit

>ions which can be used (or at least understood) by all segments of ITS.

>

>Regards

>Bruce

-----------------------------------

>Date: 18 Feb 1997 09:44:58 -0800

>From: Robert M Barrett <Robert.M.Barrett@jpl.nasa.gov>

>To: parkerbg@idsonline.com (Return requested) (Receipt notification requested)

>Subject: Re[2]: your comments

>

> Burt,

>

> After considerable thought on the idea of data dictionaries and

> registration over the weekend, I concur with the "one" option. There

> is supposed to be a single ITS so we only need a single CENTRALIZED

> data dictionary and registry. I am convinced the 'functional needs'

> can be accommodated.

I agree completely, of course....

> As to "what is the ITS enterprise"? Very good question. Perhaps some

> what akin to the three blind men trying to describe an elephant. In

> the past each function has tried to optimize their system at the cost

> of others. The national architecture leveled the playing field, and

> in my opinion optimizing the System provides synergistic benefits to

> the various functions they could not achieve by themselves.

>

> ITS enterprise is the Intelligent Transportation System. (Ok guys,

> its rock throwing time - maybe we should start a separate thread on

> this.)

Interesting insights on what the ITS enterprise is..., or could be.

> Still trying to figure out Tom's material - seems to be over my head,

> but I admit to a handicap, I ain't that smart.

>

Regards,

Burt

------------------------------

End, 4 March 1997

Back to Home Page E-mail to Staff - Sue Vogel