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