Additional Requirements for the Blue Pages Data Collection & Maintenance System


The following requirements are set forth roughly in order of priority. The most important issue is recognition of the Blue Pages as a "geographic information system" (GIS) and thus the need to coordinate its design and use with the Federal Geographic Data Committee. Coordination with the FGDC is important to ensure that important opportunities are not missed and that needless inefficiencies are avoided. None of these requirements should be taken as cause to delay piloting of the Blue Pages data collection and maintenance E-forms application. However, to the greatest degree possible, these requirements should be taken into consideration and any action should be avoided that may complicate the need to address them in subsequent iterations of the application.

1. Geographic Coverages of the Directories - In order to determine which offices are located within the geographic coverage areas of the printed directories, it is necessary to know what those areas are. It is not sufficient merely to list the directories by name and expect the coordinators in each and every agency all to reinvent the solution to the very same problem, by independently determining the coverages of 2,000 directories nationwide. Instead, the Blue Pages data collection E-forms application should describe (in a lookup table within the form) the geographic coverage of each directory. Directory coverage areas should be described in terms - such as State, county, city, area code and local exchange, and zip code - that are commonly understood by the average person. In addition to the lookup table, users of the system should be able to query on any of those elements in order to determine which directories cover the areas where their facilities are located. That is, all they should be required to know is where their own offices are located, and they should be permitted to supply that information based upon any geographic descriptor that is most readily applicable.

Ideally, the directory coverage boundaries would be geocoded so that the process of locating agency offices within them could be fully automated (for those office locations and/or service area boundaries that have also been geocoded). That probably is not feasible in the immediate future and should not be permitted to delay the launch of the Blue Pages forms automation application. However, it should be established as an objective for pursuit in coordination with the FGDC. Indeed, any directory publisher who refuses or fails to cooperate in such an effort should be required to pay for someone else to do it for them, as a condition of receipt of Federal listings data. That is, they should not be permitted to foist the cost of their own inefficiency upon the taxpayers and thereby transform a public cost into a private benefit.

2. Geographic Service Areas of the Offices - Current policy permits functions to be listed in printed directories covering only those areas where agencies have a physical presence. However, that policy disenfranchises many citizens with respect to ready access to many public services via the telephone. The directory-by-directory focus also injects needless inefficiency into the data collection and maintenance process, since each office may be contacted repeatedly to provide the very same data each time another directory within their service areas is scheduled for publication.

Instead, the full service area of each office should be described in the on-line (X.500) directory - using the same geographic elements as for the directory coverages, plus some additional ones such as congressional district and ecoregion. (For U.S. Fish and Wildlife Service management purposes, 53 ecosystems circumscribe the U.S. and they are based upon the U.S. Geological Survey's Hydrologic Unit Map.) The Blue Pages data providers (generally administrative managers in each office) should be permitted to use whichever geographic data element is best suited to the description of their own functional service areas. Once those areas are described in terms of one of those elements, it should be possible to query the system on any of them and thereby retrieve the appropriate contact information for any function performed by any office within any of those areas. Performing such cross-walks is one of the essential features of relational databases and there is no reason to force any human to perform such drudgery that is so readily accommodated by the technology at hand.

Furthermore, it should be possible to associate different coverage areas with each function, in the event that a single office may be responsible for multiple functions in different geographic areas. The default should be a single coverage area for all functions performed by an office, but it should be easy to modify the default coverage area for each function according to the most applicable geographic element. Moreover, it may be appropriate in many instances to provide for the delineation of two or more service areas associated with each function. For example, the area within which drive-in or walk-in traffic might be anticipated may be different than that for which the office is responsible for "outreach" (visits to schools, service clubs, etc.) and/or receipt of inquiries by telephone, fax, and E-mail.

Also, it should be noted that multiple offices of the same agency may have responsibility for the same general function in the same geographic area. For example, in our agency there are three levels of offices responsible for endangered species protection: The headquarters office is responsible for national policy; our seven regional offices are responsible for regional policy, and our Ecological Services field offices are responsible for local species. The default would be to direct the public to the local office. However, if they know that it is a national policy issue about which they are concerned, there may be no reason to deny them the opportunity to contact that office directly - especially if URLs and/or E-mail addresses are provided along with the phone numbers. (See Requirements 4 and 6, below.)

3. Agency Functional Listing Templates - The first thing that Blue Pages data providers should see upon accessing the data collection system for the first time is a field prompting them to identify their agency, perhaps in conjunction with the logon process. The second thing they should see is the functional listing template for their agency. From the list of functions generally performed by their agency, they should be prompted to select those that are performed by their office and to provide the appropriate phone number(s) for use by the public.

(Ideally, they would also be given the opportunity to list an "unpublished" number for each function, for controlled access by selected individuals and groups. However, that may be beyond the scope of the current effort.)

Subsequently, whenever data providers log on to the system, they should be presented with the current data for their office and they should be able to supplement, edit, delete, or merely reconfirm the data, as appropriate.

If current capabilities do not accommodate the dynamic presentation of the data in the E-form presented to the user, at least it should be possible for them to access a validation/lookup table of functions filtered by agency. That is, they should not be forced to: a) sort through all functions performed by all agencies in order to select those performed by their office, nor b) rekey functional listing terms that are common across their agency. (It would also be helpful to filter functions by office type within each agency.) On the other hand, of course, they should be permitted to enter additional terms to describe locally applicable functions that they perform and which are not reflected in the national template for their agency.

(Agency data providers as well as any member of the public should also be permitted to suggest appropriate additions or changes to the functional listing terms, such as synonyms, cross-references, etc. See Requirement 4.)

4. Access Control and Authentication - It has been suggested that all Blue Pages data providers will need to have a user ID and logon password. However, the proliferation of IDs and passwords for myriad stovepipe applications has gone beyond aggravating; it is becoming unmanageable. Moreover, in most cases those called upon to provide Blue Pages data will be very sporadic users of the data collection/maintenance system, perhaps only once a year, with the possibility that a different person will be responsible for an office's submission from year to year. Further lessening the justification for requiring controlled IDs and passwords for data providers is the fact that all of their submissions will be subject to review and approval by an authorized user of the system. Thus, it would seem that IP filtering and/or user self-identification, including an E-mail address, might be sufficient qualification of the first-level data providers.

Also, since GSA plans to permit input from the public and to consider integrating State and local governmental listings into the system, it would be good to consider allowing such submissions on the basis of self-identification, with followup confirmation automatically (by system-generated response) or by an authorized Blue Pages data administrator, as appropriate. Note: It would be well to go beyond simply allowing the public to submit general comments by empowering them to propose actual functional listings that are not adequately addressed in the on-line directory. In some cases, such proposals may simply be a matter of establishing a thesaurus of equivalent functional terms already covered in the directory. However, the public should be able to identify as specifically as possible any inadequacies they perceive in the directory, and the system should be structured to facilitate the most direct and efficient possible resolution of their concerns. To that degree, the role of the public is not that much different than the role of the first-level data providers in the Federal offices themselves.

On the other hand, of course, GSA and the Federal agencies themselves do have a special obligation to identify and authenticate their own employees to networked applications. If the Blue Pages data collection process can be used to facilitate establishment of the X.500 White Pages and X.509 certificates for Federal employees, that would be a very worthwhile endeavor. However, the key (pun acknowledged) will be to ensure that other applications used by those employees are also available to take advantage of those capabilities. If not, this is likely to be perceived by employees as just another of myriad, unending make-work stovepipe applications thoughtlessly imposed upon them.

For example, Federal employees should be able use the system to authenticate themselves to any application that requires the submission of any Standard or Optional form, indeed to any form generated anywhere in Government. (Reference the Government Paperwork Elimination Act.)

5. URLs - Data providers will be given the opportunity to associate hypertext links (as well as phone numbers) with each function they identify for inclusion in the directory. Such links will be "live" so that users of the on-line directory will be able to jump directly to any documentation the office may be serving on the Web with respect to each of its functions. (Data providers will also be given the opportunity to indicate whether such URLs should appear in the printed directories or not.) Thus, the Blue Pages data collection/maintenance effort represents a tremendous opportunity not only to improve telephone access to Federal offices, but perhaps even more importantly to minimize needless and unproductive telephone contacts.

Many members of the public may prefer directly accessing the specific information they need, rather than being forced to go through a human intermediary to get it (and perhaps being forced to leave voice mail and play telephone tag). Moreover, agencies may not be able to afford the cost of providing sufficient human intermediation for many important functions. At the very least there are opportunity costs involved, both for the beneficiaries and providers of the service as well as for taxpayers at large. Furthermore, the opportunity to avoid needless interruptions may offer a real incentive for Blue Pages data providers not only to supply URLs for existing Web resources, but also to ensure that all of their functions are adequately addressed in such resources. For example, offices may wish to supply URLs for:

Note:  E-FOIA requires agencies to "make reasonable efforts" to maintain records in whatever format they may be requested, particularly those that are likely to be requested by more than a few people.  The complexities associated with digital signatures should not be used as an excuse to deny early access to E-forms for fill-and-print purposes (in any and all formats used by significant numbers of people) as well as for the on-line collection of data that is neither highly sensitive nor subject to strict legal authenticity requirements. Note: Guidance has been issued to the effect that regulations themselves should be written in a Q&A format. However, concerns have been raised about the legal enforceability of such regulations. Perhaps a cake-and-eat-it-too compromise would be to write the regulations themselves in appropriate legalese, while making the regulatory Q&As readily available through the Blue Pages (and citing each in the other). Obviously, this is not an immediate requirement for the Blue Pages per se, but it is an opportunity that should be kept in mind and which might immediately be made available to any office that may wish to take advantage of it.

(The X.500 planning documents compiled under contract by GSA contemplated a Green Pages component of the U.S. federal directory, for documents. Documentation that explains regulatory requirements in plain language readily comprehensible by the average citizen would be a high-value class of documents to be made readily accessible by this means.)

6. Frequently Misdirected/Referred Questions (FMQ/FRQ) - Blue Pages data providers should be encouraged to identify and provide contact information (functional terms, contact and agency names, phone numbers and E-mail addresses) for FMQ/FRQ. In some cases, it may not be appropriate to publish those listings without confirming them with the appropriate contacts. However, expressly providing this opportunity may create a what's-in-it-for-me incentive, particularly for office receptionists/managers, to supply Blue Pages data. Of course, it will also facilitate the overriding objective of the Blue Pages initiative, which is better service to the public.

In that respect, entering FRQ contact information into the directory will be functionally equivalent to providing hypertext links in Web pages, albeit in a way that is much more dynamic, queriable, and easier to maintain (via the Web E-forms interface). Indeed, if URLs are provided for FRQ, the actual effect will be to build a dynamic set of hypertext links that are queriable by commonly understood functional terms in combination with geographic service areas. The Web provides the means to make such documentation available, worldwide. Providing URLs for FRQ in the X.500 directory is one important means to make such documentation readily available to the American public, in accord with the requirements of E-FOIA as well as the public-service orientation of the Blue Pages initiative.

(The E-forms Blue Pages data collection interface, together with Internet-based workflow automation technology, provides the means to manage and maintain the directory in an efficient and appropriately distributed fashion, consistent with the imperative to move away from hierarchical, multilayered, choke-point processes and toward more "horizontal," networked organizations. A reciprocal benefit is the fact that the directory itself will help to support networked organizations as well as the formation of dynamic "ad hocracies" as appropriate to address specific needs and opportunities.)

7. Mail:to and Call:to Links - In addition to URLs, agencies should be encouraged to provide E-mail addresses for each function. They should be given the opportunity to designate those addresses as "published" for public access or "unpublished" for controlled access, and the system should automatically activate those addresses via mail:to hypertext links. Likewise, in anticipation of more widespread use of Web browsers to establish voice connections, telephone numbers should be activated in the on-line directory via call:to links.

8. 800 Service and Voice/Audio Interfaces - While it is beyond the scope of the current Blue Pages data collection/maintenance E-forms project, the right of every American to universal access to their Government should be kept foremost in mind. For those who are unable to access information and services through local phone or Internet connections, toll-free long-distance (800) service should be provided. Likewise, beyond the immediate effort, it should be recognized that telephones and directories are required for voice connections; however, printed directories are not. With improvements in voice recognition technology, a speak-interface to the directory should eventually be provided, thereby eliminating the need to print, distribute, and use voluminous and immediately outdated paper directories.

Finally, audio versions of FAQ and FAD should also be provided, not only for the benefit of the sight-impaired but also for the average citizen who prefers to use the telephone.  (Note again the E-FOIA requirement to take reasonable steps to make records available in whatever formats they are requested.)  Some of the local telephone companies are already providing "talking Yellow Pages". Incorporating such capabilities in a reasonably well-coordinated fashion into the X.500 directory via URLs for FAQ and FAD would be a logical means to the desired outcome of the Blue Pages effort. Lest we need to be reminded, the desired outcome is better service to the public - not merely more attractive phone books or even more telephone conversations, both of which are means rather than ends unto themselves.

Back to Home Page