Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 75
Findings of Data-Management Policies and Issues 75
No
Monitor
Monitor Needs
Needs
Stakeholder
Stakeholder Changing?
Changing?
Needs
Needs
Yes
Establish
Establish Data
Data Identify
Identify Data
Data Assign
Assign Access
Access Modify
Modify Data
Data
Policy
Policy for
for Types
Types Rights
Rights Policy
Policy
Participants
Participants
Analyze
Analyze Define
Define Roles
Roles
Identify
Identify Stakeholder
Stakeholder and
and
Stakeholders
Stakeholders Needs
Needs Responsibilities
Responsibilities
Figure 15. Data-management policy development and maintenance process.
6.2 Definition of the Data Types
Smartcard systems capture detailed transaction and revenue data. Rules must be established
for governing who has access to what data, particularly in environments where multiple private
operators compete for ridership, because this type of data is generally considered confidential.
The data sharing and information access policies also drive the security architecture of the inter-
operable smartcard system.
Two categories of data are associated with a smartcard fare payment system:
· Transaction Data-Consists of the transactions generated as the smartcard system is used for
payment or validation of ride privileges or when value is loaded to cards and
· Operations Data-Consists of all non-transaction data collected while the smartcard system is
operating.
As discussed in Chapter 1, transit agencies take ownership of the service levels offered to rid-
ers. This situation precipitates an environment of defending control of all data generated for a
specific agency's operations.
6.2.1 Data Location
In a multi-agency environment, most operational data associated with each agency will be
stored separately, primarily because of the differences in operations. Certain data, such as card
holder identity on personalized cards, may be shared by multiple agencies because such data are
loaded after card issuance. For example, a card issued by a university for identification purposes
may contain a transit application that uses the identity information collected and encoded on
the card by the university; this is used for transit-balance protection services. Given the current
state of the technology, the fields and format of such data must, however, be established and
coded at the time of card manufacture.
Long-term goals of transit agencies in cities such as Washington, San Francisco, Seattle, and
London include the future integration of other applications onto cards issued initially for transit
service. Although development efforts are under way for card-operating systems (i.e., applications
