How Data.gov connects the dots of the federal data reference model
Connecting state and local government leaders
The Data.gov concept of operations document sets out an evolutionary path for accessing federal datasets, involving both outward improvements for consumers of the site and inward improvements to agency processes.
The day after Sept. 11 this year, I reviewed a draft of the Data.gov concept of operations document for a public-facing government agency. It presented an interesting juxtaposition, considering that the event associated with the date motivated me to help solve the information sharing-problem and the draft is motivated to solve the transparency problem. Are information sharing and transparency different problems or two sides of the same coin? I believe they are different aspects of the same problem, and it is good to see that the current administration agrees and is using the concepts espoused in the Federal Enterprise Architecture Data Reference Model Version 2.0 to evolve Data.gov.
The Office of Management and Budget released the FEA DRM V2.0 in December 2005. I led an interagency working group of more than 100 data architects from across the federal government in achieving consensus and creating the document on this complex subject. The primary purpose of the FEA DRM was to promote and improve information sharing across the federal government by providing a data architecture pattern that departments and agencies were then to implement.
Admittedly, it was only partially successful because many agencies did not understand how to implement the pattern we provided. One part of the FEA DRM that did take off was the notion of creating exchange packages, and my contribution to that was initiating the National Information Exchange Model. I initiated NIEM with James Feagans, formerly of the Justice Department. Kshemendra Paul, now the federal chief architect, led the NIEM initiative after me and brought the concept to fruition. This just proves that the right idea combined with the right people builds momentum and eventually achieves its objectives. The same will be true with Data.gov. Paul and others are now shepherding Data.gov to implement the other concepts we espoused in the FEA DRM and bringing those concepts to fruition.
The Data.gov concept of operations document, which has not yet been released to the public, sets out an evolutionary path for the government’s new Web portal for accessing federal datasets. That path involves outward improvements for consumers of the site and inward improvements to agency processes for producing and publishing the datasets. There are three specific areas where the Data.gov concept of operations brings FEA DRM concepts to fruition: context (via metadata), enhanced description (via the Semantic Web) and access (via query points). Let’s discuss each in turn.
- Context. Data.gov takes a practical approach to metadata by using a core set of attributes based on the Dublin Core and an extension set of attributes for specific data types, such as statistical or geospatial data. In the future, Data.gov will evolve and expand the collection, standardization and precision of Data.gov metadata. It is good to see a willingness to examine new techniques, including semantic Web techniques to increase the precision of the collected metadata.
- Description. The Data.gov concept of operations considers taking advantage of Semantic Web techniques to enhance the linkages (via robust relationships), discovery (via uniquely identified concepts) and meaning (via set theory) of federal data.
- Access. The FEA DRM introduced a concept called query points to federal data architectures to encourage the development of what is now known as part of a service-oriented architecture data services layer. Data.gov plans to evolve to allow direct querying and retrieval of data sets from exposed query points.
NEXT STORY: Is PDF hurting transparency?