Contractor Name: Legal Information Institute
Contract Title: Modeling Legislative Information

Narrative Documentation for the Data Model

Thomas R. Bruce, Legal Information Institute (tom@liicornell.org)
Sara S. Frug, Legal Information Institute (sara@liicornell.org)
Diane Hillmann, Metadata Management Associates (metadata.maven@gmail.com)
John Joergensen, Rutgers Law School (Newark) (jjoerg41@gmail.com)
Jon Phipps, Metadata Management Associates (jon.phipps@gmail.com)

September 20, 2012

SECTION ONE
Introduction
This document has five major parts and several appendices.  The first is a summary of recommendations.  The second part, “Part Two - Approach”, discusses our goals for the project, the methods we decided on initially, and some self-imposed limits and constraints that we placed on our work.  The third, “Part Three - Overarching issues”,  talks about policy and data issues that informed our thinking about what to model and how to populate the model that we built.  The fourth, “Part Four - Modeling issues”, discusses modeling issues that we initially encountered across a number of corpora and later distilled into treatments of common challenges, such as the creation of identifier systems and the description of people, organizations, and events.   A final part — really a grab-bag of details that would not fit elsewhere -- deals with problems encountered in specific corpora that are not discussed in other parts of the report.

Two appendices consist of the original texts of white papers generated over the 18 months of active work on the project.  The first contains white papers related to phenomena that spanned the entire model; the second contains papers related to specific corpora (such as the Congressional Record).

We used this structure because it stresses the commonalities across corpora included in the model.  There are many.  We feel that all too often work on different types of legislative data — particularly in the US — stresses the exceptionalism of each part rather than bringing out what is shared by the whole:  everything the legislative corpora have in common with each other and with other models.  The structure we use here is, of course, a tradeoff. The reader who wants to know about all the ins and outs of a particular corpus — say, bills and resolutions — will have to look in several places.  If your goal is to focus on only one type of material, we recommend looking first at the papers in the appendix that deal with that material, and then reading the more cross-cutting discussions.

The use cases we considered, and some relevant support materials, appear in a third appendix.

Technical types will find the actual documentation of the model in a final appendix. It consists of some brief documentation of two spreadsheets that contain the model and examples related to it, and a manifest listing the spreadsheets and other documentation (such as binary image and mind-map files) that also help to document and explain the model.

PART ONE
Summary of Recommendations
The model described in these pages was nearly two years in the making.  The client has given us a terrific opportunity to delve deeply into legislative data, and we are grateful.  We think the result is the most solid model for Federal legislative data to date -- one that incorporates the latest approaches to information organization, and one that is strongly based in the techniques of the Semantic Web.  We’ve taken a carefully considered approach to the problems we encountered, and so have built a model that can be readily extended to meet new needs. 

Nevertheless, our work was necessarily limited, and will need review and extension in several areas.  Some things that will need to be considered:
	•	Our inventory of use cases should be carefully reviewed for comprehensiveness and balance, and if necessary extended.  While we covered the cases contained in the BAA, collected many that were implied by FAQs and other documentation of current systems, solicited further use cases from government-documents experts, and imagined many for ourselves, there were important stakeholders to whom we had no access.
	•	Legislative events are not modeled at a level of detail that takes in all the rules of each chamber or reflects all of the possible parliamentary maneuvers and outcomes.  That is partly because we felt that such a finely-detailed model would be both volatile and hard to maintain, and partly because we lack the detailed knowledge of procedures needed to build it.  There is, we believe, room for extension without adding too greatly to maintenance burdens.
	•	There are two areas for which the need to understand the procedures of each chamber was too great for us to do a good job, and while we have sketched them into the model we have not developed them fully.  Our understanding of the available avenues for reconciliation of bills between chambers is incomplete, and so is the model.  We have also done little to model the appropriations process, which we believe will present very complicated challenges requiring more domain expertise than we possess.

We have addressed such problems of stability and detail by assuming that others whose work and expertise bring them nearer the material are in a better position to extend the model and to determine what degree of detail is sustainable over the long run.   Accordingly, we built the model to be extensible.  As we do throughout these recommendations, we stress here that Semantic Web technology encourages distribution of these kinds of modeling and maintenance tasks across administrative boundaries and data stovepipes.  Modeling, and the population of the models, can be done simultaneously, in many places, by those who best understand the things being modeled.  In a passage we quote again later in this document,  Jeni Tennison of legislation.gov.uk remarks:

RDF has this balance between allowing individuals and organisations complete freedom in how they describe their information and the opportunity to share and reuse parts of vocabularies in a mix-and-match way. This is so important in a government context because (with all due respect to civil servants) we really want to avoid a situation where we have to get lots of civil servants from multiple agencies into the same room to come up with the single government-approved way of describing a school. We can all imagine how long that would take.
The other thing about RDF that really helps here is that it’s easy to align vocabularies if you want to, post-hoc. RDFS and OWL define properties that you can use to assert that this property is really the same as that property, or that anything with a value for this property has the same value for that other property. This lowers the risk for organisations who are starting to publish using RDF, because it means that if a new vocabulary comes along they can opportunistically match their existing vocabulary with the new one. It enables organisations to tweak existing vocabularies to suit their purposes, by creating specialised versions of established properties.

The Semantic Web technology Tennison describes has arrived at a time when it has become far more practical and inexpensive to build and manage very, very large datasets.  As has often happened in the world of computing, quantitative change ultimately brings qualitative change as well.  The ability to readily accumulate and manage huge numbers of descriptive assertions means that we are no longer forced into over-conciseness, overly-selective representation,  or over-standardization by limitations on storage, management, or search. That, in turn, means that we need no longer pre-coordinate or pre-interpret, or be afraid of reinterpretation of the mass of data by third parties who are now free to analyze, slice, dice and re-mix data as their needs demand.  For example, we need not establish whether or not an organization or group is “official”  -- we can simply model and collect descriptions of all factors that bear on that question, and leave it to others to apply their own standards to that evidence (see the “What to model” section of “Section 19 - People and organizations”) .   We can provide detailed records of votes, and metadata that provides a context for those votes, in a way that is neutral simply because the dataset provides large amounts of contextual information without subjective interpretation (see “Section 6 - Member sentiment and voting data”).

The Linked Data notions we put forward here can be characterized as a “distributed metadata technology” that allows the confederation of metadata models and collections across institutional and administrative boundaries.  For that reason, much that we recommend imagines distributed development of metadata collections that become federated through the model, encouraging cooperative work throughout and beyond the legislative branch to weave together the best sources of information.  Of course, that has implications for cost-sharing as well as for data quality. In a time of shrinking resources, cost-sharing may prove the most compelling argument for taking the course we have imagined in our work.

Because of our extensive work with data administered by other legislative-branch entities, we are more aware than most of the discontinuities, omissions and duplications that have naturally occurred over the years as different groups have developed different datasets.  Throughout the design and modeling process, we tried to look at what organizations inside and  outside the legislative branch were doing and collecting.  That process was necessarily incomplete, but we did gather enough information to suggest some courses of action that relate directly to a distributed approach to legislative metadata.  Our model can, with carefully- and cooperatively-planned extensions, create a reference model for metadata across the legislative branch.  We have suggested numerous strategies that might be used for this, but probably the most important is that such a model be allowed to grow and be populated from disparate data sources that become interlinked over time,  without excessive time or effort expended in pre-coordination.  Semantic Web technology allows a let-a-thousand-flowers-bloom approach to be integrated into comprehensive models as more data and new approaches become available.  Thinking about the finding aids currently offered by the House Office of the Law Revision Counsel, which track codification decisions, makes it easy to see how useful this kind of interoperability might be (see “Section 34 - Finding aids” ).  We think that re-modeling and linking those finding aids would be an excellent first step in a potentially valuable collaboration.

Throughout, we have given special attention to “future data” -- data that for various reasons is not yet ready for prime time, but soon will be, and must be thought through. That data falls into three categories.  Elements of all three show up later in these summary recommendations, and are explained fully in the main text (see “Section Seven - Future-proofing”),  but we list them here to underscore their importance:

	•	Data that exists as data, but is not published as Linked Data.  
	•	Data that exists within documents, and could be extracted by automated means. 
	•	Data that exists within documents whose architecture will need to be rethought before extraction is possible.  

Finally, we recognize that wherever there is novelty there will be both perceived institutional risk and a need to try, test, and experiment in a way that is minimally disruptive.  Technology companies in the private sector have, for at least 200 years, done this by creating “second brands” that are understood by consumers and critics to be different or innovative. That  technique is now most visible in the “beta site” approach taken by Google whenever it tries out a new technology or service.  There is nothing to prevent an innovative organization from doing the same.

SECTION TWO
Linked Data
“Linked Data” is, in one sense, a catchall term used to describe the coordinated use of a number of recommended practices for publishing structured data on the Web.  We recommend that, wherever possible, those practices be followed in modeling and publishing legislative data.  In another sense, “Linked Data” embodies a set of attitudes and practices around the consumption of data created by others.  That latter sense is likely to be the more controversial.

Linked Data practices are at the heart of our work. Two of the four basic principles of Linked Data practice, as originally set forth by Tim Berners-Lee, involve the consistent and universal use of HTTP URIs as identifiers for objects both on and off the Web.  Our more detailed thoughts about the design and use of identifiers, summarized below and described at length in the “Section 8 - Identifiers” section of “Part Four - Modeling issues”, follow that lead.  The model itself is expressible using the RDF standard that is the basis of the third principle of Linked Data, and incorporates the structure and relationships described by Berners-Lee’s fourth and final principle.   These recommended approaches bring with them a variety of related recommendations about metadata expression and management, covered in “Building out and beyond legacy data” and “The transition to a linked world”.    

As to the consumption and linking of data created by others, we recommend that to the greatest extent possible the client identify and make use of externally developed standards and data. In particular, we recommend the use of mapping strategies such as those described in a recent paper written by two members of the team. Other specific recommendations regarding standards are summarized below.  So far as data is concerned, we recommend that the client consider and adopt as many trustworthy sources of Linked Data as are applicable to its needs.  For example, we believe that Linked Data from sources such as the New York Times, Freebase, dbPedia, and VIAF has a role to play in improving and supplementing LCNAF (see, for example, the sections  “Use of external data sources”, “Legislative people”, and “Witnesses”) .  Many more such opportunities exist.

SECTION THREE
Identifiers
Data models are systems for describing things, and it is not surprising that data modeling in general and Linked Data practice in particular emphasize careful, systematic use of identifiers.  After all, it is important that we be able to say with certainty what we are talking about when we describe something.  The Linked Data practices we recommend require that we use URIs that link to descriptions in those places where, in the past, we might have placed pre-coordinated text strings.  

We have not done a comprehensive study of identifiers; it would have taken too long.  We make a general study of them in the “Section 8 - Identifiers” section.  We do provide illustrative examples for many of the collections we considered; see especially “Events that collect events”, “Worked example: committee hearings”, and “Worked example: the Congressional Record”.  Nevertheless, there are some practices we would recommend throughout:

	•	Everything should have a unique, dereferenceable identifier. There are particular areas and collections that currently have no useful identifier scheme. For example, a system of identifiers is needed for committee prints, and a unified and comprehensive system of identifiers is needed for committees and subcommittees in both chambers.
	•	Identifiers should be human-understandable to the extent possible. At the same time, we recognize that opaque identifiers can sometimes foster stability and precision,  and enforce care in application.
	•	Identifier granularity should, at a minimum, enable standard citation and cross-referencing practices.
	•	Identifiers should not necessarily be equated with a single stage of the legislative process, though in many cases they will be (as, for example, when the object being identified is a document-version that existed through only one legislative stage).  That said, it may be desirable to have a single identifier that represents a multi-versioned document as a single abstract “work”, after the manner of FRBR, or another that serves to identify “most current version of...” for a particular object.  The latter notion is a particularly slippery one at some stages, however, and the functionality it would bring is probably better accomplished through inferencing.
	•	It is not necessary for a single identifier to answer all needs, and in many cases more than one will be needed.  There must be one identifier that is unique and dereferenceable. More can be used to identify the object in different contexts that meet different use cases.   User-friendly, brain-compatible “accessor” identifiers (particularly those that indicate that an object is contained in a nested set of collections) are both common and desirable.  We give examples of such an approach in “Worked example: committee hearings”.
	•	Identifiers should exist for everything that needs to be identified, not just for those things currently marked up in XML.  As some collections are converted to XML, it will be important to keep identifier granularity in mind when creating schemas (here, we are thinking particularly of the Congressional Record, which we discuss in “Section 24 - The Congressional Record” and “Worked example: the Congressional Record”.

We would very much like to see a comprehensive approach taken to identifiers across the legislative branch, with URIs minted for anything and everything.  It is probably not possible to do this systematically in reasonable time.  We do believe that this particular client has a special responsibility to create and maintain mappings between those systems that are in use within the client’s own collections and elsewhere; this will not be an easy task, but it will bring great benefits to researchers.

SECTION FOUR
The model: design
Our model will need to be assessed and extended using a broader range of use cases than we were able to gather. We recommend that the client extend our pool of use cases by consulting with the full range of stakeholders, and (consistent with the methodology described in the Singapore Framework) develop a set of functional requirements from them.

For reasons we spell out in a later section (“Section Nine - Why not FRBR?”), we are not convinced that a strict FRBR-based approach to modeling is a good fit for American Federal legislation, and we have not depended on FRBR in our model.  We believe that for those desiring a FRBR-focused view of the data, mappings from our legislative elements to FRBR-based vocabularies (like RDA) can be built to serve any purpose that a FRBR-like model could deliver.

Instead, the heart of our model is dualistic. Many current systems conflate the description of legislative events (such as bill introduction, or hearings, or votes) with the description or tracking of the documents and document-versions to which those events are somehow related.  That is a natural confusion given that most libraries only consider legislative events insofar as they are reflected in the documentary record. However natural that viewpoint may be, it creates problems, particularly when communities that view the process from the perspective of legislative events (as most legislators would) use systems that are built from the document-centric perspective, or are asked to provide suggestions for their improvement.  We believe that there are tremendous advantages in maintaining distinct object classes and relationships for events and documents within the model, effectively creating two “sub-models” that are tied together at significant points -- for example, when a committee process results in a new version of a document, generates reports or amendments, and so on.  The resulting process-oriented model is described in “Section 16 - A process-oriented model for documents and versions”, and we strongly recommend its use.

As to more detailed recommendations regarding the model and the encodings it uses:
	•	We believe that some of the RDA concept vocabularies provide a good basis for building genre/type and encoding format vocabularies for legislative content, particularly insofar as they were designed in concert with the publishing industry’s ONIX standard, and thus provide built in relationships with both RDA and ONIX going forward (see “Use of vocabularies in descriptions”).  
	•	We recommend that the RDA work attempting to reconsider traditional usages of ‘extent’ be followed and reviewed for possible inclusion into the model. The goal of this work is to provide a better basis to describe physical characteristics of a variety of materials in a way that is more usable as data (see “The use of "extent" information”)
	•	For people and groups, we recommend the adoption of  a modified, extended version of the W3C governmental organizations model, such as we present in “Section 19 - People and organizations”.  In particular, we suggest that the model
	⁃	should not require the distinguishing of more and less formal groups; instead, the model should aggregate evidence from which users can make their own choices and interpretations about the “officialness” of groups and organizations (see “What to model” in the Section 19 - People and organizations” section).
	⁃	must  provide a more sophisticated approach to representing membership and roles within groups, which we describe in “Legislative groups”.
	⁃	should use Congressional Biographical directory as its centerpiece
	⁃	should be reviewed with an eye toward extending its coverage to congressional staff, with authorship data for reports and committee materials as the initial focus for review.
	•	We recommend that the client look carefully at a number of standards for geospatial data and decide on an approach.  In the model presented here, we have used the schema.org Place object (see “Geographic locations”), because it accommodates different expressions that address a wide variety of needs.  It will likely be impossible to settle on a single standard because
	⁃	Population of the model is likely to depend on automated extraction techniques, which in turn suggests that we accommodate whatever is parsable from the text, be it placenames, coordinates, street addresses, or what have you;
	⁃	No single system (ontologies, coordinates, or street addresses) deals with the entire population of things for which we need locations.
	•	For dates and times, we suggest the use of the W3CDTF standard (see “Dates and times”).
	•	The client should track (and hopefully use) the ongoing DCMI work on provenance. The field is still too chaotic for any one approach to “win”, but DCMI seems to be the most robust (see “Provenance”).

SECTION FIVE
Vocabularies and classification
First and foremost, the client should develop a strategy for the evaluation and adoption of multiple topical vocabularies, including the LCSH and THOMAS topical vocabularies, and possibly including a “classification” approach such as that used by LCC.  Candidate vocabularies need not be at the same conceptual level or granularity.  Where possible, consideration should be given to standard vocabularies in use across the Semantic Web.  We discuss these issues in detail in “Section 18 - Vocabularies”.

There are many vocabularies to develop.  We have taken some first steps, notably with the vocabulary of legislative events described in “Section 17 - Legislative events”.  Other needs include a genre vocabulary for committee prints (see “Section 30 - Committee prints”), and a system of vocabularies related to “snippets” found within the Congressional Record (for example, extensions of remarks, which fall into a number of genres; see “Extensions of remarks”).  The latter points out the need for vocabularies that are designed to work at the sub-document level, particularly topical (“about-ness”) vocabularies. Development of new vocabularies should not be a matter of once-and-for-all, top-down pre-coordination.  Instead, core vocabularies should be created with the understanding that they will be managed and extended over time (see “Vocabulary design and management”).

We believe that machine extraction and automated classification, as well as crowdsourcing, can be very useful in the creation, extension, and application of vocabularies.  While no technology will be 100% accurate for all of those purposes, accuracy may well reach that level for some, and less-than-accurate technologies can be employed in systems that triangulate to achieve greater accuracy, or support decisions made by humans.

SECTION SIX
Populating and expressing the model
Use of automated techniques to populate the model is not limited to applying vocabularies.  Machine extraction via pattern-matching can be used to extract descriptive data in well-known, parsable formats such as geographic coordinates or street addresses.  The branch of natural-language processing (NLP) known as “named entity recognition” (NER) is quite successful in detecting proper names, placenames, and the like.   Such techniques could be employed in practically any of the collections we examined to good effect, but we think they would be particularly useful with respect to the Congressional Record and its components.  

Given the availability of such approaches, we think that committee prints are ripe for re-examination. They are seen by many as a noisy and intractable collection of documents of highly variable worth to researchers.  That is true, but we believe that these newer technologies -- usable  for metadata extraction and for the creation and maintenance of ontologies --  might well lead to some good results in sorting the wheat from the chaff.

While it would be tempting to use newer NLP techniques such as sentiment detection to (e.g.) characterize statements by members during debates, or to combine voting records with topical classification to analyze the positions of members on broad legislative topics, we believe that there are both technical and intellectual problems with such approaches.  In some cases they are flatly unworkable, in some they are inaccurate, and in others they fail to provide adequate context (see “Section 6 - Member sentiment and voting data”).

The model has been designed to accommodate alternative data formats (see “Section 3 - Non-textual data”). It appears to us that there is much that can be done to include multimedia records (eg., of committee hearings), non-documentary materials presented by hearing witnesses, and so on (see “The multimedia record”).  Finally, there is considerable potential to link the model to non-documentary datasets (eg. relational databases of voting records), and for the client to publish data as data rather than as document-based representations of data.  

The collection of data represented by the model can be offered for access by a variety of means: 
	•	published as Linked Data embedded in web pages via RDFa or as schema.org or other microformats. Embedding of metadata in documents presents some metadata-management challenges, but it is in many cases justified by the utility of the result.
	•	offered via APIs
	•	offered as SPARQL endpoints
	•	offered as bulk XML

To be sure, embedding of metadata in documents presents some problems for metadata management, but it is important to consider what is gained for the end user and for those who may wish to create novel applications by republishing and remixing the electronic documents offered.

Any collection of data that third parties such as govtrack.us are scraping, parsing, and reprocessing Web-accessible dynamic databases, or electronic documents that are essentially database reports,  is a good candidate for publication in bulk, access via API, or both.  THOMAS is perhaps the most prominent, and controversial, of these.

Again, we are grateful to the client for the opportunity to work so carefully on the model, and we hope that others will find our detailed work both insightful and useful.

PART TWO
Approach
Traditionally, libraries have approached the question of incorporating specialized kinds of materials into their descriptive workflow by focusing on the similarities between the new materials and the materials for which they normally provide descriptive metadata. In the past, this worked well —materials in newer formats and those for use in special communities were able to be incorporated into existing tools with a minimum of fuss. In the area of legal materials, the treatises, standard monographic materials, and standard serial titles were in general easily incorporated, while loose-leaf services and other materials with updating services were not.  Primary legal materials were treated either as collections, as serials, or, in the case of most legislative materials, as standard monographs. Now that the digital revolution is well upon us, with full-text versions more available and users’ experience with search engines generating more pressure to look beyond simple access to printed materials, we’re starting to see more clearly how limiting our traditional approaches have been. 

There are several areas where traditional bibliographic approaches fail:
	
	•	They are insufficient to provide the functionality desired for specialized legal materials	
	•	Primary legal materials have traditionally been entered under jurisdiction with collective uniform titles that are often meaningless to users.
	•	Insufficient distinction is made between jurisdiction and place.
	•	The new bibliographic approaches, such as RDA, are based on a FRBR model of published works, which, while rich in relationships, provide neither element sets nor relationships particularly useful for American primary legal materials, in-process legislation in particular.  Legislative metadata projects in the United Kingdom, Italy, Brazil, and elsewhere have made extensive use of FRBR as a model, to be sure, but it is much better suited to legislative process in those countries than it is here. 

What is needed is a rich set of legislation-specific elements which, in combination with more general elements, will describe the nature of each document set as an entity linked to other entities, via the rich relations between them.  Furthermore, within most, if not all, of these documents are important structural elements, such as sections and subsections of bills, statutes and code sections, that benefit from special treatment and tagging when serving as targets for linkage.

Another goal we consider important is to structure any data model for American materials such that there can be easy and useful crosswalks between these descriptions and international standards created in other jurisdictions. Emerging international standards such as CEN/Metalex  (specifically designed for interchange) or AkomaNtoso (designed for use as a common standard to be used in many jurisdictions) may not provide ideal representations of American legislation, but they represent valuable alternative encodings and ways to achieve interoperability.  The aim here would be not to compromise functionality or the nuances of the description of American legislation, but to allow for future expansion of the system to include, for example, automatic cross-referencing to foreign statutory materials.  

SECTION SEVEN
Future-proofing
We felt strongly that the best measure of a model is how well it fits functional requirements — that is, the value of our data model would lie in what it would allow data consumers to do. Our work was thus rooted in careful consideration of use cases, which we discuss extensively in a later section.  But we have also tried to account for other environmental factors in the model’s design.  Most of those come under the general heading of “future-proofing”.  We have tried to identify important trends in the administrative and technological environment and ensure that the model will stand up to them well. The most significant are:

	•	The effects of exposure of legislative metadata  in a Linked Open Data environment. Nowadays, metadata models must be designed for exposure and recombinance. Exposure occurs as the metadata is published and repurposed outside its original environment of use -- and outside of its original institutional environment as well.  Recombinance occurs when metadata is combined with different sets of metadata drawn from disparate sources.  Most exposures and recombinant uses cannot be anticipated.  In such a world, it’s important that people talk about similar things in similar ways, and that to the degree possible all data carry with it some idea of where it was created, where it has been in the meantime, and what has been done to it.   Thus, standardized expressions for common data items like dates are important, and some standard way of describing the life history of a piece of data or of the collection in which it lives — the provenance of the metadata —  is desirable. We discuss these matters in a later section.
	•	Curation issues that arise from consuming data in a Linked Open Data environment.  We needed to think about the range of issues raised by using data that originates with others.
	•	The availability of data in nontraditional forms — that is,  forms other than those traditionally made available through the paper and electronic documentary record.  That takes in a wide range of issues, ranging from the description and use of multimedia records of events to the use of empirical data about processes like voting, which may be stored in relational databases and not as electronic documents.
	•	A developing push toward data-sharing within the legislative branch, accelerated by increasingly severe institutional constraints on resources.

So far as we have been able, we’ve chosen strategies that reflect the best understanding of what would be most conformant, most flexible, and easiest to implement, in roughly that order. In some cases, it is not so easy to know what will be best or how long it will remain so. The speed at which innovation and shifts in understanding happen in this realm make flexibility paramount.

There are places where we did not go in our explorations.  We have made suggestions about the creation of vocabularies that can then evolve at need, but have implemented only as many as we had direct need for.  Most significantly, we have avoided excessive detail in our treatment of legislative process.  House and Senate rules are complicated and volatile, and we have left their modeling and description to experts who are closer to the ground.  Similarly, our treatment of the reconciliation process and of anything related to appropriations is at best simplistic.  But we are confident that the model creates a strong foundation for extension by subject-matter experts, and that they will find it easy to build what they need.

While the immediate problem has been to model metadata that is currently collected and deployed by the client, our work has also been informed by what we have discovered about relevant practices and data that exist in other organizations, both in the legislative branch and in other communities.  That has been particularly relevant to our work on a model of legislative events, and to our thinking about identifiers.  While some of that work has arguably fallen outside our immediate charge, we believe that no data model can end at the bounds of a particular institution.  There is an urgent need for a reference data model throughout the legislative branch, and it is our hope that, in addition to fulfilling our charge, we have been able to contribute to that in some meaningful way.

SECTION EIGHT
Working methods
We turn now from “what and why” to “how”. As a way to think about the building of a process of analysis and the associated documentation, we took the Dublin Core Metadata Initiative’s Singapore Framework as our roadmap.

The Singapore Framework was developed as a way to look at the process of building an application profile, from the process of developing community consensus and documentation to the technical infrastructure supporting validation and quality control.  While the Singapore Framework is a relatively new approach in the world of libraries, it provides a useful way to look at the process of developing an application profile and its parts, as well as the relationships between the parts and the underlying applicable standards.  The work described here has consisted of understanding the functional requirements of several large corpora and integrating them into a useful domain model.  The corpora requested in the RFP were:

	•	Bills and resolutions
	•	Public laws
	•	Treaties and other international agreements
	•	Committee hearings
	•	Congressional debates and the Congressional Record
	•	Committee prints
	•	Serial set (House and Senate documents and the House and Senate reports)
	•	Presidential signing statements

Looking at the Framework, it seemed clear that the most appropriate place to start was with functional requirements and use cases, and from there to develop a domain model that would be able to support the requirements and use cases fully.  The next section discusses use cases in full.

Section 1 Using use cases
This section briefly describes the use of use cases -- succinct statements that capture user needs whose satisfaction rests on the availability of metadata -- as a foundation for building metadata models and systems.  People with software-development backgrounds will not be surprised that one might begin the design of a metadata regime by asking precisely what people want to do with the metadata; that’s how software has always been built.  But it’s not how metadata models actually have been built, for the most part, and more traditional librarians may be surprised at the way in which use-case methods value system functionality over the building of idealized models and descriptions.

In that way, the use of use cases is an intensely practical choice.  It is one part of the development of Dublin Core application profiles (DCAPs), which we also discuss here, and a foundation of the Singapore Framework,  a methodology that emphasizes the grounding of DCAP development in use cases and supporting documentation. It is an emerging standard that

… is a framework for designing metadata applications for maximum interoperability and for documenting such applications for maximum reusability. The framework defines a set of descriptive components that are necessary or useful for documenting an Application Profile and describes how how these documentary standards relate to standard domain models and Semantic Web foundation standards.

The Framework’s emphasis on methodology and documentation is in itself a bit unusual.  The world of the Semantic Web is most often described by narrow and slightly abstract technical standards that are (often erroneously) assumed to be both self-documenting and agnostic about sound design procedures beyond the technical apparatus they specify.  We liked the Singapore Framework because it addresses problems of documentation and design procedure in a way that we think well-suited to a project like this one, where we are attempting to harmonize metadata drawn from a number of administratively-independent sources in order to create a data model of maximum utility to a very diverse user community.

The use cases we actually employed in our analysis appear in an appendix to this document.

Use-case methodology
Use cases are simple structured narratives that describe what users want to do. In our context, they describe desirable user activities that can only be successfully performed if the right metadata is available and if the right relationships are built into the metadata model.  The collection of use cases thus provides a useful strategy for data model development, employing functional requirements that are gathered from data consumers.  Use-case methodology is very common in software engineering, where it is an important part of developing functional specifications for software systems.  It is also used for creating functional tests of work in progress.

One strength of the method is that it is particularly adaptable to collaborative, inter-organizational approaches in which use cases are collected from a wide range of institutional and individual actors.  For example, the World Wide Web Consortium’s Library Linked Data Incubator Group spent a fair amount of time early in its work gathering use cases. In fact, that use case document is one of the two deliverables described in their charter.  The general idea seems simple, and not at all controversial: begin the design process with a set of well-understood and documented notions about the users of the system and what we want the resulting model or system to do for those users.  But it runs counter to a well-known tendency to seek the model that is intellectually perfect rather than the one that addresses known, prioritized needs and system functionality.  

That focus on needs is its greatest strength. The most compelling reason to prefer a use case based approach is that it keeps us focused on the overall purpose of the system we are designing. In a recent blog post describing the development of a search engine site, Henri Sivonen writes pungently about the perils:

“An easy explanation for not using existing vocabularies is that communities doing metadata domain modeling are looking at the problem from the wrong perspective by considering what can be expressed about a topic while the search engine implementors care about what matters for consuming data for the purposes of search use cases and they just happened to care about different things than what the pre-existing communities had developed specs for.  

In my experience, metadata design efforts tend to fall into the trap of focusing more about what could be said about a topic rather than what needs to be said in order to support use cases of the consuming software.  I stopped believing in metadata when I spent a summer at the National Archives (of Finland) thinking about metadata and saw how many existing specs seemed to focus on recording inessential things and failing to record essential things as far as the use case I was tasked to think about was concerned.”  (http://hsivonen.iki.fi/schema-org-and-communities/) 

Those who find Sivonen’s remarks intemperate will be quick to say that designing on the basis of a few scattered, unrelated needs will result in the sort of elephant that could only be built by a committee of blind men, each of whom is focused on only one part.  There is that risk, particularly if the community of users who contribute use cases is in some way unrepresentative, if the collection of use cases is superficial or too small, or if designers are excessively biased toward the familiar needs of the past.  We ourselves have noted a certain skew toward end-user search applications in our own thinking.  But the fact remains that many, many projects have sought “perfect” descriptions of data, chasing the Holy Grail of meeting every conceivable need to the detriment of creating systems that work well for most people most of the time.  That is an expensive and time-consuming approach, and we need to get away from it.

In a 2004 book chapter on metadata quality, Bruce and Hillmann began to consider the practical effects of cultural differences between those who grew up in library-cataloger culture and those whose background lies primarily in software engineering.  A bias toward perfecting descriptions before practical uses are considered arises quite naturally from traditional cataloging practices, in which most materials are touched once and seldom if ever revisited.  By contrast, computer technologists generally apply evolving technologies iteratively to raise quality, widen collection scope, or address an expanded set of user needs, making good on whatever investment has been made in the extensibility of systems at the outset.   

We believe that iterative approaches are important to a legislative-metadata project, for three reasons:

	•	The user community surrounding legislative data is highly diverse, with a wide penumbra of possible uses surrounding a core set of needs.  That argues that scattered, small communities of specialists will require a model that can be extended. Too, as users and designers gain experience with systems built on the models, new needs will be articulated.
	•	The model is subject to changes needed to keep it synchronized with a legislative process that itself changes in ways both large and small.  Prior to 1975, for instance, when the Congress began to permit submission of proposed legislation to multiple committees, one might have relied on a much simpler model than would serve now.  While we cannot anticipate what the next epochal change in procedure might be, we can guess that there will probably be one.
	•	Models have to be populated with real metadata, and their scope is usually conditioned by metadata availability.   The economics and management of the model-population process are changing radically as natural-language processing techniques become more and more capable of accurately extracting metadata elements from large textual corpora.  That is especially significant in an environment where it is important to bring the same capabilities to retrospective collections as will be built into systems going forward. 

We couldn’t anticipate every need, nor treat every part of the process with all of the detail that a specialist who spends her life in that part might require.  We could, however, build a model that provides both core functionality and the means for specialists to extend it in an iterative, evolving manner.  Our foundational approach requires us to remain grounded in use cases that have been gathered from real users of legislative information, rather than seeking perfection.  In our view, balancing needs as expressed in documented use cases, especially within a context of realistic economic and managerial considerations, leads to an extensible model that will form the best basis for moving forward.  In general, the 80-20 rule applies: 20% of the cases will cover 80% of the need, and that is where we begin.  The long tail can be dealt with by specialized extensions to the model.

Pitfalls of use-case methodology
Use-case methodology is not magic pixie dust.  It has potential drawbacks and aspects that demand care:

Good designs require good use cases.  In this context, “good” might mean a number of things, but we will focus on two:  first, the use case pool needs to be representative, and second, it needs to be both balanced and sane in its level of detail.  

The second point is a direct response to the first: trying to make a use-case pool representative by making it hyper-inclusive is impractical.  It makes the perfect the enemy of the good in much the same way that pursuing perfect, abstract models does.  As to balance, focusing solely on the expressed needs of “most users” tends to create systems that answer only the needs that the largest numbers of consumers have in mind at the time they are asked.  

In our situation, that might result (for example) in a design that stresses present-day search scenarios over the needs of systems-builders or archivists.   There are two other forms of potential bias worth considering. One is the tendency of the use-case development process to focus only on those parts of precursor systems that seem most relevant to the new way of doing things.  But sometimes it can be important to look further back, and recapture functionality that has already been lost or made difficult to use in earlier technological transformations.  For example, certain highly useful print-based finding aids don’t have good analogs in current electronic systems, but could now be rethought effectively using newer technology.  Because those print artifacts aren’t represented in current electronic systems, it would be easy to miss them in the analysis process, or to plan less capable versions than are actually possible.  

A second form of bias can occur because it is often difficult to include -- or even to imagine -- all of the ultimate consumers of data in the collection process.  In a sense, this is just a very specific manifestation of the problem of keeping the pool of use cases representative, but it is worse for some data providers than for others.  Data providers whose material is aggregated, redistributed, or mashed up by others, and providers who issue bulk data for reuse by others, will need to be especially careful.  Experience proves that maintaining feedback mechanisms that extend from the ultimate user all the way back to the source of the data can be challenging to the point of impossibility.

Finally, it’s worth remembering that user “wish lists” are not use cases, though one wish list may embed or assume a great many use cases.  For example, a half-dozen examples of desirable system functions that were embedded in the proposal for this project yielded roughly 30 use cases, many of which were fundamental activities that duplicated use cases that were also surfaced by other scenarios submitted from multiple sources.  That leads to the next point.

Use case compilation is time-consuming.   Use-case gathering is in one sense simple: you just ask users what they do, or want to do, with data or data systems.  However, systematic compilation is important to making sense of the use-case collection.  That involves standardized documentation of each use case in a common, templated format designed to bring out the important facets of each case (we provide an illustration below).  Second, the collection of cases needs to be examined for commonalities and overlaps; this too should be systematically documented.  Depending on the size and diversity of the user community, all this can take a good bit of time.  That, in turn, brings us to the question of how we actually go about collecting cases.

Organizing use cases
Building models and profiles from use cases required a range of tasks:

	•	Collecting the cases from knowledgeable sources, identifying which were duplicative and which were irrelevant;
	•	Recording the use cases in ways that allowed them to fulfill a number of needs, preferably using a common template;
	•	Organizing and collating the use cases so they could be referenced later and shared effectively.
	
During the process of collecting, recording, and organizing, it was essential to keep in mind that the cases would be used later to test the functional requirements and model being developed for the project. Thus, the template we used as a standard recording method emphasizes activities that can be used as a basis for testing the model, to determine whether desired functionality is supported, and identify gaps to be addressed.

We collected our use cases from a variety of sources:
	•	Actively recruited sources, generally law librarians and researchers known to us and willing to participate;
	•	Existing documentary sources that can be gathered without outside help.  These include THOMAS FAQs and those from the House of Representatives site (which imply common use cases), law-library research guides, the RFP for our current project (and others), and feedback information from THOMAS supplied by knowledgeable sources;
	•	Outsiders--that is, people who are not law librarians or legal researchers but have specific needs for information, such as historians;
	•	Self-generated use cases, often discovered during internal discussions of the larger issues we discuss in this document.

Our recording and organizing of the developed use cases was based on prior experience of the principals and some research into use case templates used by other projects.  The agreed-upon template was encoded into the project wiki.  That was done to ensure that insofar as was possible the template was used, and used relatively rigorously by all.  The discovery and building of use cases has been critical, and iterative.  The trick was to achieve balance between the bottom-up, data-driven approach suggested by use cases, and the top-down approach of issue identification and discussion represented by the content of this document.

First steps
The first step was gathering all the use cases we had onto a spreadsheet for initial analysis of duplication, overlap, and relevance.  Analysis of overlaps was particularly interesting, because the overlaps were extensive; our final collection of cases was about a third the size of what we initially collected once we had removed “same-activity-different-data-element” cases from the collection.  From there it was relatively easy to begin writing up an initial assortment of use cases using our template. 
 
The template asked for these items:
	•	Use case name,  a descriptive name for the case;
	•	Use case number/identifier;
	•	Document type, identifying which of the BAA corpora is being used;
	•	Purpose, that is, what the user is trying to do;
	•	Actors, the types of user (eg. “legislative staff”) for whom the use case is most important or relevant;
	•	Prerequisites, items the user needs to have “in hand” for purposes of their task;
	•	Sequence of actions, the step-by-step process the user will follow to achieve her result;
	•	Results, what the user expects to retrieve or discover as a result of the process described.

In addition, we tracked versioning information, notes, and remarks about current practices as part of the use-case record.  At present, the template does not contain any designated slot for describing precursor datasets or datasets implied by the sequence of actions.  For example, many of the use case scenarios described by the client emphasize geodata-related retrievals for which the approach and underlying datasets to be used are unclear, and probably external to the client’s datasets.

Below is the page that ‘gathers’ the use cases for project members, and following it an example of a specific use case:

Application profiles
We employ use-case driven methodology to create documented Dublin Core  application profiles (DCAPs).  For those not familiar with them, DCAPs might be thought of as providing a new kind of framework for the very useful thefts that database designers always commit when they recycle their own schemas and combine them with those developed by others.  They allow the metadata designer to re-use vocabularies developed for other applications, in whole or in part, and combine them with newly-needed elements to create a purpose-built definition for the metadata records needed.  More formally put:

A DCAP defines metadata records which meet specific application needs while providing semantic interoperability with other applications on the basis of globally defined vocabularies and models.

We do not intend to thoroughly describe DCAPs or their uses here; a good introductory reference can be found in the “Guidelines for Dublin Core Application Profiles” referenced in the footnote above.  However,  a few remarks about them are in order.

If nothing else, the metadata needs of particular communities and applications are diverse. The past few decades have seen a great proliferation of new metadata ‘formats’, even across applications that have significant metadata needs in common, for example: 
	•	The visual culture community (primarily art and museum libraries) has developed a specification called ‘VRA Core’ now in version 4. 
	•	The Society of American Archivists (SAA) has developed a content standard for describing archives, personal papers and manuscript collections, called ‘Describing Archives: A Content Standard’ but popularly known by its acronym ‘DACS’ 
	•	The public broadcasting community has developed a metadata dictionary primarily for audiovisual media called PBCore.

The Dublin Core Metadata Initiative has attempted to address the proliferation of content standards by providing a framework for designing a Dublin Core Application Profile (DCAP). A DCAP defines metadata records which meet specific application needs while providing semantic interoperability with other applications on the basis of globally defined vocabularies and models. 

A DCAP is intended to be a generic construct for designing metadata records; one of its virtues is that it does not require the use of metadata terms defined in only one schema. A DCAP can use any terms that are defined on the basis of RDF, combining terms from multiple namespaces as needed. A DCAP follows the DCMI Abstract Model [DCAM], a generic model for metadata records. 

A fully compliant DCAP includes guidance for metadata creators and clear specifications for metadata developers and developers of applications. By articulating what is intended and can be expected from data, application profiles promote the sharing and linking of data within and between communities. The resulting metadata will integrate with a semantic web of linked data. A useful example of a fully documented DCAP is the Scholarly Works Application Profile (SWAP), developed for the sharing of eprints in institutional repositories.
	
The Singapore Framework was developed primarily as a way to look at the process of building such a DCAP through the lens of a community consensus-building process. It emphasizes full documentation at every stage, from consensus-building to the technical infrastructure supporting validation and quality control.  While the Singapore Framework is a relatively new approach (and still lacks some of the technical building blocks necessary for full realization of a DCAP), it provides a useful way to look at the process of developing the descriptive model at the core of an Application Profile, its component parts, and the relationships between the parts and the underlying applicable standards. In our context, the requirement for explicit documentation of the process of building the model as well as its supporting components has a lot to recommend it.  That documentation -- and the design process it represents -- is strongly rooted in use-case methodology.

Model development and testing
From the initial group of use cases, we began working on the model for the first document type: bills and resolutions. That starting point was crucial, providing us with a first set of documents that also represented the origin point in the legislative process. To begin this task, we built a spreadsheet that would allow us to see the general categories of data we would need, using Dublin Core  and FOAF as starting points, and expanding and extending beyond that to areas where more specificity would be needed.  This working document has ended up carrying the full set of properties and classes we will be working with for all the document types, and will provide the basis for loading these classes and properties into the Open Metadata Registry. 

A second spreadsheet was set up for the specific properties and classes for the bills and resolutions, including the data elements we needed to describe the documents and sub-documents we were working with, as well as the relationships between them.  Examples of data output (such as the THOMAS aggregations of information around bills) were used to build up prototypes of specific bills using our initial model elements, and to surface questions that needed to be answered as we moved forward. We took a similar approach with each new corpus.

One of our most important tasks in building the model has been to ensure that there are adequate relationship properties built in to support the kind of browsing between document types that will be the hallmark of this approach. For example: data about a bill can include relationships like ‘amendsLaw’ and ‘hasLaterVersion’ as well as things like ‘dateEnacted’.  The relationship properties are generally set up as reciprocal properties, which can ensure that relationships between two entities actually can be used--and managed--in either direction by compliant systems. 

That strategy continued to build as we moved on from bills and resolutions to committee publications.  We have circled back at various points as we saw gaps we needed to address, from places further down the road.  Initially, we focused on several needs that stuck out in our initial explorations:
	•	identifiers;
	•	subject-matter information, not particularly well addressed in current legislative systems
	•	people, for which sponsorship relationships seem to be among the few available in current systems
	•	popular names for bills whether explicit in the bill or assigned by media or other groups (eg. “Wild Horse Annie Act”,  “Obamacare”).

In general we found that the best approach was to begin with highly descriptive approach that described objects and relationships as faithfully as possible.  We initially made no attempt to consolidate or structure things into a hierarchy of classes and subclasses or properties and subproperties, nor did we initially borrow from other ontologies and vocabularies.  Our main concern was accuracy of description.  At a much later stage, we checked the flat collection of things and relationships for redundancies, and began to organize things into a hierarchy of classes. We also began to consider where we might borrow elements and relationships from other ontologies without loss of accuracy or meaning.  In general, we believe that this approach — describe things faithfully first, organize later —  has resulted in a model that is far simpler and more faithful to the data being modeled than it might have been otherwise.

PART THREE
Overarching issues
We turn now from methodology to consider some design issues that confronted us at the outset.

Modeling issues fall into two rough categories: data issues and policy issues.  Data issues involve questions about which information should be contained in a property or class.  They are related to the design of the data model itself. Policy issues, by contrast, involve decisions about how the model is to be populated: which sources are preferable, stable, and reliable. A related policy issue might be whether to use a controlled vocabulary as content, and if so, which one.  

Data issues often rely on an understanding of appropriate and ‘standard’ ways to build, expose, and maintain data from distributed providers, especially when that data is intended to be distributed to diverse applications for diverse purposes. Policy issues apply to decisions that rely on understanding of resource realities (and limitations), existing data and its fitness for the system, as well as short-term and long-term goals. It is important to choose those alternatives that will provide the most bang for the buck in the short term, while offering a useful improvement and extension strategy for the longer term. 

We encountered data and policy issues at many points in the project.  For example, we began our work by thinking about identifiers, discussing the ‘why’ of standard, web-friendly identifiers as well as a bit of the ‘how’ they might be built using existing identifier systems.  

Choices related to namespaces and properties provide further good examples. Not too long ago, re-used properties in well-managed schemas were considered the best choice by most sophisticated thinkers in the field,  because that choice left the responsibility for management and maintenance costs in the hands of someone else. However, opinion is now shifting, as designers have come to more fully understand how much is risked in that approach, and how difficult it can be to maintain the coherence of a schema under those circumstances.  Attention is now shifting from strategies of re-use toward mapping strategies.  Mapping strategies offer a way to reap the benefits of re-use without the disadvantages. Thus, building a model that embodies specialized understanding but which remains mindful of relationships to general, standardized properties keeps the mapping option open.  Our master list of properties and classes reflects the recommended new properties in a manner that makes mappings to Dublin Core (and potentially MARC21 and RDA) relatively easy. Also on the master list, under the new, proposed ‘legis’ namespace, are properties and/or subproperties that remain to be declared and published but are intended to provide the basis for increased functionality, while supporting extension as needed.

In this model we have chosen, when defining new property names under the ‘legis’ namespace, to use the ‘is/has’ convention to distinguish those properties which describe the resource itself from those included to link to other resources. This choice makes sense from the point of the creators of descriptions, but does not tie applications to use the same construction for human labels.

Determinations about how the client proceeds to implement some or all of those recommendations are, of course, well beyond our brief.  We do, however, offer some opinions about policies and mechanisms that might inform those decisions.

SECTION NINE
Why not FRBR?
FRBR has become the darling of legislative markup and metadata standards outside the US.  As we noted in an introductory section, legislative metadata projects in the United Kingdom, Italy, Brazil, and elsewhere have made extensive use of FRBR as a model. Why are we not explicitly building our model on that basis?  There are two reasons.  First, FRBR is primarily a post-hoc publication model, and is not as well-suited to legislative process as it is to the final product. More, it does not accommodate the Federal legislative process as comfortably as it does the process used by legislatures elsewhere.  In any event, the more complex model required by American Federal legislation can be coherently mapped into FRBR should we wish to do so.

João Alberto de Oliveira Lima lays out a good case for the adaptation of FRBR to legislation in Brazil;  the documentation for legislation.gov.uk shows a worked example in RDF/XML.  Each relies on a similar adaptation of FRBR ideas, namely that legislative acts (“Transport Act of 1985” in the UK example) are FRBR “works”, and that individual amended versions of them, existing as successive snapshots over time, are FRBR “expressions”.  That is an entirely reasonable view given the Act-centric nature of legislative process in European countries, most of which regularized their law-making processes in the period immediately after the Napoleonic Wars.  The European approach, and others that follow it, view the legislative process as almost entirely consisting of the creation of Acts and their continuous improvement.   They tend to take the old law, rewrite it to suit current needs and desires, and then pass it as a whole. The result is a clean, or at least clean-enough, line of legislation on a particular topic that works in procession, without post-passage codification.   

There are a number of reasons for us to prefer a more complex approach.  From an abstract perspective:
	•	The work-expression relationship rests, ultimately, on the idea that an individual Act is coherent in its subject matter, at least to the point where it is unlikely that it will be amended by anything other than a new version of itself.  It is not clear what happens when some sort of “omnibus” Act amends a number of existing Acts.  It seems likely, though, that what does happen dilutes the work-expression relationship sufficiently that some similar, but distinctively legislative, set of relationships would make more sense.  
	•	The work-expression relationship does not work well with post-passage codification of the sort that occurs in the US — especially in those positive-law Titles where the US Code is considered the ultimate authoritative source.  While some Acts do survive in their entirety as Chapters or other aggregations within the US Code (for example, the Social Security Act, which is 42 USC Chapter 7, and the Food, Drug and Cosmetic Act, which is Subchapter 1 of Chapter 9 of Title 21), many do not.  Outside the US, the Act remains the official source of law; in the US, the “expression” of an Act/work would be a series of very small bits potentially scattered throughout  positive and non-positive law Titles of the Code.

At a more pragmatic level, the FRBR model has some difficulty in accommodating some routine aspects of the American legislative process.  For example, FRBR would not easily model:
	•	Concurrent bills arising in different chambers, which are important to relate, but often sufficiently different to require different treatment. The determination of difference and equivalence is a huge open question in applying FRBR to standard bibliographic items, and legislative materials would present still more difficult challenges.  For example, the recent health-care legislation took the form of separate bills making their way through the House Health and Human Services and Ways and Means committees, and equally different bills making their way through the Senate, with a conference committee proceeding at the end. FRBR, as practiced on other legislative-information projects, would accommodate such a process, but only if it were applied only to the life of single bills — that is, if each concurrent bill were a distinct FRBR work.  The result would either ignore the context for each bill, or require the creation of a series of properties that would end up constituting a separate model.
	•	Concurrent drafts arising either within a committee process, or within parallel committee processes for bills that are assigned to multiple committees.
	•	The loss of  subject-matter coherence that occurs when topically unrelated provisions are introduced into a bill.  For example,  the Clinton administration’s last Omnibus Crime Control Act — among other things — funded and organized youth athletics programs, instituted several new death penalty provisions, included provisions on gun-related and drug crimes, and organized block grants to police departments.  All those are arguably thematically related; many other bills feature earmarks, sweeteners, poison pills, and other inducements that are distinctly unrelated but necessary to secure votes.
	•	An amendment process that often does not work directly on the Act, but is expressed as a series of changes to the US Code, sometimes in positive-law Titles and sometimes not.  This results in amendments that are targeted at larger and smaller fragments of two or more different documents.

The OASIS technical-committee process  around the Akoma Ntoso standard — which is strongly FRBR-based — has led to some discussion of these differences.  FRBR advocates feel that the standard can be bent to the task of modeling American legislation and legislative process.  For example:

Translation: new Acts are approved that further modify the Code, and may contain explicit or implicit modification instructions. Some of these directly address (the most recent expression of) the Code. These are easy to deal with: they simply generate a new expression of the Code. Others address the original Act that created a specific Expression of the Code. One must understand whether this is just a rhetorical device, a shorthand for a modification of the Code, or if it is really a modification of the Act. I don't know in the US, but in Italy it would be considered without a doubt a modification of the Act [emphasis ours]. This is a case of a modification of the modification.

Expression A(1) of Act A affects (modifies) Code X, creating expression X(n+1) from the previous expression X(n).
Expression B(1) of Act B modifies Act A, creating expression A(2) from the previous expression A(1).
This creates a chain reaction that indirectly creates a new expression X(n+2) of the previous expression X(n) ….

From my point of view, the Act transforms the Code, and each expression of the code is a revision of the previous expression. No problem here. Yet, if you feel that there are missing relationships, you are very welcome to add your own without breaking the model.

No doubt FRBR can be applied in such a complex and fragmentary manner; the application would grow hugely complex and confusing depending on the number and nature of related bills at different stages of the process.  Its application reminds us a bit of the use of apparent retrograde motion to protect the theories of Ptolemy from the observations of Copernicus; it’s possible to accommodate American legislative process using FRBR, but it results in some unnecessary and nonintuitive elaborations.  

We prefer our own approach, which is based on the use of parallel models of legislative events and of document versioning and other inter-document relationships.  Nevertheless, it is worth noting that the US Code itself can be expressed coherently in XML markup conforming to  both Akoma Ntoso and CEN/Metalex versions.  The final product is much easier to capture than the process and its intermediate byproducts.

SECTION TEN
Where to put the descriptions
Before reaching either data or policy issues, we should address a mechanical question that arises right off the bat:  Where should we put the descriptions? 

These days, we’re seeing a resurgence of the notion of ‘self-describing’ documents, where metadata is partially (or completely) embedded in the document itself, traveling with it wherever it is stored or cached and managed as part of its ‘content’. Interest in this idea surfaced in the early days of Dublin Core (and the Web), where some content providers embedded DC metadata directly into HTML documents. Interest in that approach faded, particularly as it became clearer that maintenance of such information within documents was far more difficult than for metadata managed in databases. 

The current interest in embedded metadata addresses two different needs: one for metadata that can be easily consumed by search engines or other third-party applications that only have access to the document itself; the other to support management of files in a preservation context. 

For many digital projects, perhaps most particularly those in the cultural heritage sector, success or failure is often measured by demonstrable usage of the materials.  The usual scenario is for users of search engines to be led to sites where content is available primarily by collection or individual item, often by a site-based search based on richer metadata. Although embedded metadata is not the only strategy used to provide better ‘search engine optimization’ (SEO), the recent development of standards such as microdata  and RDFa,  and the recently announced collaboration of the major search engines designed to develop and encourage widespread use of a new embedded vocabulary  has raised important issues for content providers and their metadata managers. Given the desire of many projects to provide richer metadata for better discovery and linking, and the surging interest in briefer metadata embedded in documents, there is no single choice that is clearly preferable. What seems to be emerging is a ‘plus’ solution, where brief, non-volatile metadata is embedded in documents, and richer metadata, needed for providing services to more specialized or knowledgeable users continues to be stored and maintained in databases. It’s important to note that use of embedded metadata also requires analysis and decision making, particularly given that the schema.org vocabularies are tilted toward the SEO needs of commercial sites and to those who pay for search engine advertising.

The other scenario, for metadata used for preservation management of content, can certainly re-use much of whatever embedded metadata exists to enhance preservation strategies, but preservation metadata, embedded or not, is generally designed not for discovery but to support long term workflow, management, refreshing, and other tasks across a variety of ‘versions’ of single or aggregated resources. Because our project is clearly not designed to address preservation (or indeed, most administrative) needs, the absence recommendations in this area should not be mistaken for lack of interest on our part.

Section 2 Data issues
Our overall perspective on the data is that of a document-based model that has been linked to a model of legislative process at certain significant points.  It is important to remember that the documentary record is itself a data model -- an old and somewhat lumpy one. It is already obsolescent in some areas and for some purposes.  For example, the voting data presented in tabular form in the Congressional Record exists also as electronic databases held within the Congress itself.  For many purposes, the electronic databases are far more useful than their fixed representation on electronic paper.  In general, we believe that the client should look carefully at the documentary record for other examples of places where legislative information might better be published as data in parallel with its encapsulation in published, print-like documents -- or where it is already being published by others within the legislative branch, and can be linked.  That includes, in particular, multimedia records of proceedings and multimedia objects (such as exhibits used by witnesses at committee hearings) that show up in the legislative process.

Licensing and other restrictions
Worries about licensure fall into two categories: licensure issues related to the reuse of metadata by others, and “inherited” licensure issues that relate to the rights of authors who have created the metadata used in the system. In general, US Government works are not copyrightable, and so we have not worried too much about metadata needed to describe licensing restrictions on the metadata itself.  It is possible that some data that is incorporated in the model (the CRS summaries associated with bills come to mind) may carry licensing or usage restrictions. It would be simple enough to extend the model to accommodate these.

In that context, it is worth noting that there is a certain amount of controversy in the library community about whether metadata should be covered by licenses at all or simply released into the public  domain.  The major questions revolve around whether or not contract-style licensing arrangements (as opposed to simple release into the public domain) are resolvable in situations where data that exists under a variety of licensing arrangements has been aggregated or recombined, and whether appropriate attribution (consistent with community norms around public-domain release) can be maintained in that environment or in one of open dedication to the public domain.  Many approaches to the problem exist.

One should keep in mind that most of these discussions have taken place around the reuse of library catalog records, and not legislative metadata. Our own belief is that reasonable systems for representing provenance would deal with any problems regarding origins.  However, we do think it useful to supply licensing information as part of the metadata, even if the licensing terms impose no restrictions.  Such an approach avoids confusion arising from default assumptions made by both publishers and users.

We have made no effort to understand or model any formal or unstated systems of access control, restrictions on viewing, or security that may relate to legislative data regarded as sensitive by various parties to the process.  We are well aware that there is great sensitivity to the use of legislative metadata (voting records, for example) for political ends. Any informal policies that arise from such concerns have necessarily remained invisible to us, and we have not considered them.

Future data
Where possible, we have made provisions for data that is not within our brief, but is closely related to it and may well come into scope in the foreseeable future.  That data falls into three categories:

	•	Data that exists as data, but is not published as Linked Data.  Tables I, II, III, and IV of the United States Code -- but especially Table III, which tracks codification decisions -- are probably the leading example of this that we have encountered.  The Legal Information Institute has already converted Table III to RDF triples, and will be offering a Linked Data version of Table III sometime during the 4th quarter of 2012, and we understand that the Office of the Law Revision Counsel is interested in doing the same.
	•	Data that exists within documents, and could be extracted by automated means. The most interesting examples found in our collection of use cases had to do with geographical information.  The extraction of place names and locations from (e.g.) bill text is well within the capabilities of the current natural-language processing technologies known generally as named entity recognition; those place names can be associated with geodata to allow new queries and presentations (such as maps).
	•	Data that exists within documents whose architecture will need to be rethought before extraction is possible.  That, unfortunately, is the case with the Congressional Record.  It is rich in data that might be of great interest. In order to make that data useful, however, the Congressional Record would need first to be published in a structured format with identifiers in place for many of the substructures within it, and subsequently disaggregated and stored as a collection of fine-grained data items that could be recombined to create a number of different products and publications.  We imagine that this will take place in the near future, but it has not yet.  Another common example is the absence (at least in publicly available versions) of sub-document structures and identifiers within XML-encoded bills, which might -- in contrast to a whole-document approach -- provide more accurate targets for subject-matter classification, geodata-referencing, and other processes supporting usefully faceted searches.

Section 3 Non-textual data

The multimedia record
Increasingly, legislative information is available in forms other than text on paper. For example, most committees routinely record hearings in both audio and video formats,  and many witnesses arrive with exhibits in the form of Powerpoint presentations or other visual displays. That poses interesting problems for creating descriptive relationships. Beginning with microforms and continuing through the digital publishing revolution to the present, the library community has struggled with similar issues. Microforms, as fairly simple reproductions, were simply added to print records, but this strategy came apart with the advent of digital ‘versions’ that were not strict reproductions, although they might appear to be at first blush.

Given that the proliferation of versions in libraries has again exploded with the advent of e-books, attempts to treat these kinds of multimedia versions by determining the ‘first’ (or most important) version as the one that all other records “follow” -- that is, are declared to be versions of -- have largely been abandoned.  That leaves treating each one as a separate resource, and creating appropriate links between them, as the only realistic option. 

Our model starts with the most common situation, where printed and digital versions of the same resource exist in parallel. Each is described according to what it is--with descriptive properties that may or may not be the same in each (pagination is often the same, format is not). In those situations, the relationships are simple, because the content is virtually identical. Less obvious (but still relatively simple since the content itself is still the same) are the situations where one digital version is embedded in the digital CR and referenced by page, and a third version, also text but stand-alone, is also provided.

That simple strategy breaks down when there are multitudes of formats to contend with, the relationships are not just between reproductions, and the contents are inherently different. For example, as noted above, committee hearings may be available in print, on video recordings, as well as audio recordings. Whether a user wants one or another of these often depends on their task: do they want to quote something in a written report of some kind, or do they want a video clip for a news report or a YouTube polemic, or do they wish to listen to the hearing while jogging or driving? To complicate things further, each of these ‘versions’ may contain additional material (say, written witness testimony) which is not reflected in the multimedia files. Under a strict interpretation, these separate items are not ‘versions’ at all, once the content has begun to diverge.  But in a discovery-oriented system, these ‘version-like’ relationships enable users to choose from among those available for the best fit with their tasks, without incurring, for the collection owner, the expense of creating detailed descriptions of the differences in every case. 

With the digital/print simple version strategy in mind, we’ve essentially created subproperties to dct:hasVersion by using hasDigitalVersion and hasPrintedVersion. We don’t use dct:isVersionOf (the reciprocal relationship to dct:hasVersion) in this scenario. A strategy where the version relationships do not carry the format of the version being linked to is likely to scale better as new kinds of resources become available. In that second possible scenario, we provide more generic links (hasVersion and isVersionOf) and rely on the type and format information of the resources at either end of the relationship to enable filtering and sorting.

Empirical/quantitative data
Until recently, most quantitative data associated with the legislative process — for example, vote tallies — has been recorded on paper  which was then stored, organized, and described like any other part of the documentary record.  Electronic documents were a slight improvement, in that the useful data could perhaps be parsed from them and loaded into a relational database, statistical software, or otherwise made available to analytic tools.  These days, though, the documentary record is created as a database report — which of course raises the question of why one would not simply get the data from the database in the first place, although so far as we know there is no direct public access to collected voting data available on any legislative-branch system. That is presumably because such data is considered politically sensitive, an issue we discuss in a later section.  Sites such as govtrack.us  scrape voting data from records in THOMAS, and offer the results as datasets and as RDF triples; it would make sense for the legislative branch to do so directly.

The use of "extent" information
Traditional library cataloging places high value on describing the “extent” of an item (size, number of pages, illustrations, and other physical characteristics).  Our model includes these items insofar as they are relevant to printed and print-like (eg., PDF) versions of the documents we are considering.  There is also an emerging push toward expanding RDA’s use of “extent” to make it more friendly toward data.   That would carry the following benefits:

	•	Easier matching for the purposes of determining differences in content.
	•	Sorting by size, dimension, or other criteria.
	•	More granular search-faceting  for media materials based on extent.
	•	A better path towards automated determination of extent.
	•	Provision of textual values and labels in a variety of languages.
	•	Ability to compress and itemize more complex extent information for particular users.

Should RDA be expanded in this way, the model will need to be reexamined for inclusion of properties and relationships for digital documents that run parallel to those we’ve included for print materials.

Who should build the bridges?
Legislative branch information connects to information outside the legislative branch.  Statutes produced by the Congress provide authority for regulations created by Executive Branch agencies.  Those regulations are described to the Congress by executive communications that substantially duplicate materials in the Federal Register.  Courts interpret statutes (and sometimes rule them unconstitutional). This poses an interesting problem:  who is responsible for modeling and archiving the connections and materials that “fall between the branches” in this way? 

We are more aware than most that metadata collection and maintenance carries costs.  Populating and maintaining any data model will consume time and money.  That is why all models carry (sometimes hidden) administrative boundaries that are important to their design and implementation.  We have tried to avoid approaches that will carry costs for the client that belong more properly to others. But at the same time, we see a need to provide points of connection in the model that cross over into administrative units outside the client itself.  That is particularly true of other legislative-branch entities; our discussion of post-passage materials, for example, heavily references finding aids created by the Office of the Law Revision Counsel in the House of Representatives.  We also refer to materials from the judicial branch, and to the Parallel Table of Authorities, which relates executive-branch regulations to statutes.  Should the client’s model include these?  Certainly the client understands that the needs of researchers do not stop at bureaucratic borders, even though budgets may.  Inevitably, the utility and extensibility of the data model will rest on cooperation across administrative boundaries.

Section 4 Policy issues
Policy issues — that is, issues about how the data model is to be populated, what sources it considers legitimate, and so on — are diverse, and difficult to organize into a coherent narrative.  What follows is a sampling of issues we encountered in building the model.

Vocabulary design and management
The design of vocabularies, including classification systems, can be a difficult and long-tailed endeavor.  That is particularly so at the outset of a project, when large parts of the corpus are unknown or unsurveyed. Vocabularies based on language concepts, and classification systems based on topical arrangement of those concepts exist in an environment where change is a constant. Poor design and management of these essential tools too often leads to frustrated users. 

Good design is intended to maintain a balance between ‘precision’ and ‘recall’, where a too precisely defined conceptual space can lead to searches with few or no results, and an excessively imprecise vocabulary leads to too many results for a user to review. Modern search engine designs often mix vocabularies with full text applications, to assist in disambiguation of synonyms, plus stemming and spelling strategies to expand the reach of term selection in a discovery environment. User profiles range widely -- from expert researchers to school children -- and in that diverse environment such strategies increase user success with discovery systems.

Under those circumstances, it is tempting to design a vocabulary that contains only the few terms that describe the majority of items, and to leave the remainder to some sort of “miscellaneous” category.  That is often done in the belief that the thinly-populated categories will never accumulate enough members to be a useful target for search or any other activity that would require their members to be distinguished.  But that is notably hard to predict; “environmental law” would have been a very slim category in 1972, but it is certainly not so now.  The “misc” category can become a harmful default that blocks the recording of “aboutness” information that will later become useful.  A better approach would be one in which a core vocabulary can be allowed to evolve as terms accumulate and are populated.  A vocabulary designed to reflect the full range of ‘aboutness’ to be found in legislative materials is something to be managed, not set in stone from the outset and left to age gracelessly. 

For example, the evolving-vocabulary problem arises in at least two important areas of the Congressional Record (CR): subject-matter classification for the general remarks of members, and the naming of the CR components themselves.  We discuss the first problem more extensively in a later section.  The second problem is much as we’ve described the general issue: while a good number of CR components can be sorted into a small group of recurring types, the remainder are so diverse as to elude classification.

Intelligent management of  evolving vocabularies such as these demands minimally that we distinguish between the sources from which terms are drawn. We may want to establish separate properties for subject classifications that are handmade by internal experts, harvested by machines, or created by crowdsourced free-tagging, that can be used in concert by an effective application.

Machine-constructed and crowdsourced tagging each have some appeal for this purpose.  As we discuss elsewhere, many textual features in legislative data (proper names, geographic locations, bill identifiers, and so on) are readily extractable using either simple textual pattern-matching or more sophisticated machine-learning techniques for recognizing named entities, yielding rich metadata for data discovery and search.  Crowdsourcing also has some appeal -- it would be a particularly good way to discover popular terms for legislation such as “Obamacare”, and for assigning “aboutness” terms to small snippets of the CR -- but it also poses dangers.  Unlike (for example) the Library of Congress’ earlier experience with free-tagging of images distributed by Flickr, civility and restraint are not likely to be the order of the day when the material to be tagged provokes partisan sentiment, or when tagging is seen as a means of announcing a personal position, casting a vote,  or as some other form of political speech.  That seems all too likely with discussions of current legislation.  Of course, crowdsourced tagging could be done using a prespecified vocabulary.  That would forestall abuses, but would destroy any potential for discovery of new terms. Almost inevitably, crowdsourcing in this arena will bring with it a need for policing. That is, of course, a well-known problem for online commercial entities depending on ranking and review by users.  That has led to an extensive literature on user-generated content, and the means for controlling and enhancing its quality.  That literature is too broad to survey here, but may prove useful in thinking about implementation in the future.

Use of external data sources
Great economies and improvements are made possible by the incorporation of metadata from outside sources. But questions about trust surround any contemplated use of external data. Traditional library data creation does not trust much, but verifies often. The Semantic Web will require a somewhat looser approach.  Data about persons other than legislators — for example, hearing witnesses or senior Congressional staff — provides a useful vantage point from which to think about the problem.  

Traditionally, the Library of Congress Name Authority File has provided reference data about persons. The LCNAF files are built and maintained on a distributed model where membership in the group of trusted maintainers is tightly controlled, and the costs are borne by the library community at large.  A world that is open to non-library organizations and agencies will rely more on what we might term a “best evidence” or “best quality” policy.  Such a policy would dictate use of the best source available; experience shows that that is usually (but not always) the source that is closest to the point of data creation.  In that respect, provided it does a decent job, the Congress itself is a better source for information on legislators than the Library of Congress, and the responsible news media should be employed as sources of reusable information on individuals who come to their attention.  

Sources that have come to our attention during this project include the Linked Data project at the New York Times, dbPedia, and FreeBase.  Voting data is collected by the House of Representatives, and scraped and offered externally by sources such as govtrack.us .  There are also useful metadata sources within the legislative branch, such as the variety of finding aids maintained by the Office of the Law Revision Counsel for tracking codification and other post-passage legislative information.  There are also external sources maintained by the National Archives. Any or all of these might be incorporated into extensions of the model, or used to populate it.

Section 5 Automated data extraction
We see two questions surrounding automated data extraction.  The first is, “What useful metadata can we extract?”.  The second is, “What automatically extracted data should we use?” .  The two are tied closely together, in that no data-extraction method is 100% reliable, and therefore no extracted data is guaranteed to be completely free from error.

Practical extraction: XML, pattern matching, and typography
Metadata extraction works best if the relevant data has been marked up in an XML-encoded version of the source document, or exists in an external, XML-encoded file or some other structured source such as a relational database.  Most, but not all, Congressional legislative data is available in this way (the notable exception is the Congressional Record).  Sometimes, the metadata of interest to us will occur naturally within the four corners of the document itself, as when the author’s name occurs in a byline within the document, and will be encoded in XML elements within the body of the text.  At other times, the metadata will be added by some other process, human or mechanical, and be encoded in a header that occurs within the computer file containing the document but is not part of the document body, or may exist in an external XML file containing only metadata (as is the case with the MODS files used by GPO to describe many of the materials we discuss in this document.  Either of these approaches creates computer files that are suitable targets for automated extraction of metadata that can be used to populate a model.  However, XML encoding alone is not a guarantee that extractions can be done completely reliably — after all, encodings can be misapplied, and particular care is needed if the encoding of a particular element contains any interpretive dimension.  For example, one would need to take some care that elements in the standard Congressional XML DTD set have been applied in the same way by the House and the Senate, that defaults have been applied consistently, and so on.

With texts that are not XML-encoded, and for which XML-encoded external metadata is not available,  quite a bit is still possible.  For example, here are some elements from the Congressional Record that would be relatively easy to extract.  Much of this has apparently been done by GPO in creating the MODS files that accompany the FD/SYS version of CR.  For example:

	•	Member statements contain: 
	◦	titles indicating subject matter
	◦	the name of the Member making the statement
	◦	often, but not always, a bill number indicating the subject of the remarks.

	•	Floor debates can be regarded as transcripts; it is possible to distinguish a number of elements automatically:
	◦	Who is speaking when
	◦	Bill text
	◦	Amendment text
	◦	Roll call votes, with 
	▪	Identifiers for each vote
	▪	“yea” and “nay” lists of members voting
	◦	Other incorporated materials, either read into the record or ordered to be printed with it.  These are extremely diverse; we have identified newspaper editorials, written correspondence, and a welter of other items in addition to bill and amendment text.

	•	Special sections exist for
	◦	Executive communications, containing
	▪	Numbered entries for executive communications, including
	▪	The party communicating
	▪	Applicable docket numbers, agency-created regulatory identification (RIN) numbers, and other identifiers indicating the rule or matter that is the subject of the document.
	◦	Additional sponsors, containing
	▪	Bill numbers with a list of added sponsors
	◦	Bills introduced, including
	▪	Bill number
	▪	Sponsorship information
	▪	Committee referral information
	◦	Bills enrolled

The “extractability” of data from free text generally depends on two things: how well-structured the text is, and how readily the data of interest can be matched to a recurring pattern.  Thus, things like formal citations, bill numbers, and other elements that consistently match a pattern can be done reliably.  Too, text that has been electronically typeset can frequently be treated as though the encoded typography is a kind of proxy for logical markup like XML.  The CR is available in such an electronically typeset format, as is most legislative branch information that has been published by USGPO.

Practical extraction: NLP
The last section made passing mention of the identification of legislators as speakers in debates and roll call votes. Member information is easy to identify and extract, largely because of the availability of authority files that tell us what to look for, and because Member names usually appear in a preferred consistent format.

Members are not the only named entities appearing the CR; the identification of people, organizations and places referred to in text is a subject that should be addressed.  In the absence of fine grained subject tagging of text (which is prohibitively costly and labor intensive), the identification of the subjects of remarks can go a long way to providing context to text, and greatly enhance the utility of any system that makes use of it.  There are many automated techniques that would allow us to identify things under discussion.  In general, named-entity recognition (NER) techniques are quite good at identifying people and places.  While there is not yet an off-the-rack application that has been optimized for the legislative domain, it seems likely that work done for the news domain -- which has been extensively studied and implemented -- would produce good results. 

 Again, it remains important to recognize the limitations of such approaches; while a computer program might very reliably identify “Weeping Water Conservation District” as a named entity needing attention or extraction, it would be hard pressed to determine whether it was an administrative organization or an actual geographic area that was being described.

Section 6 Member sentiment and voting data
Many of the use cases we collected express strong research interest in the positions of legislators with respect to particular legislation, their positions with respect to more broadly-stated issues, and in voting information.  These are all reported in the Congressional Record, in ways that might be automatically identified and extracted.  But again, there are questions about whether it would be appropriate to do so.

Member sentiment: technology constraints
In the annotations to the various use cases related to member sentiment (RFP S-2 UC-1,  and RFP S-7 UC-1), we express a pessimistic view of the potential for automated extraction of information about member sentiment as it emerges from  transcripts of floor debates.   It would, no doubt, be possible to segment floor debates by speaker, and to analyze the resulting segments as speaking either in favor of something or against it.  However, it would be extremely difficult to know whether the “something” being spoken about represented a position in favor of a given issue or even in favor of the bill under consideration in the debate.  That is because the statements involved are made in the context of a complex parliamentary process.  A statement in favor of an amendment might be supportive of the overall bill, if the amendment is a friendly one, or it might not be, if the amendment guts the bill.   And, given the procedural turns and twists of legislative process, it may be difficult to identify just what the statement relates to or what a speech about a particular procedural maneuver might mean with respect to the bill.   We are left, at best, with the very strong possibility that limited accuracy in both sentiment detection and in associating statements with larger positions and outcomes would accumulate error in a way that would render the overall project useless.

Voting data: policy issues and the problem of context
Along with records of statements and debates, records of votes comprise a key part of the contents of the Congressional Record.  Of course, the most significant of these are records of roll call votes.  Interestingly, the ability to evaluate the attitudes of legislators based on roll call votes cast on selected legislative measures was often cited as a desired feature of a legislative model by our use cases.  Technically, it would be easy to pull voting information out of the record and parse it separately; third-party services such as GovTrack now do this routinely. Given that the measures being voted upon will have defined topics, and that those votes are, ultimately, statements of approval or disapproval, the temptation to accommodate such requests is strong.  One could easily correlate the topics of measures with the votes of legislators to draw conclusions about legislator sentiment. 

We believe that such a function would be inherently flawed, and its adoption an error.   In contrast to such information as debate statements, where a legislator would be stating and defending his or her position on a topic, a vote record contains no information on why a vote was cast.   But this is politics. It regularly happens that a legislator will be in favor of the aims of a certain measure, but will, for a wide variety of reasons, be constrained to vote no.  Similarly, a “yea” vote may be cast for a wide variety of reasons that go against a legislator’s feelings about a particular measure.  For these reasons, any attempt to divine legislator sentiment from voting data will be inherently flawed. Voting records simply do not contain sufficient context to accurately measure sentiment.

That said, basic factual identification of legislators and their votes in all roll call votes can and should be done in a public, neutral manner.  As with any information provided by any source, it may be subject to misinterpretation or even intentional abuse by third parties.  Nevertheless, it remains vital data on the functioning of government.  

Access to voting data is essential, but voting data should not be presented  as indicating legislator sentiment by itself.  Misuse of voting data should come only through others.  Moreover, given the linked-data environment we contemplate in the design of our data model, the additional information needed to provide context to legislative votes will be available should anyone choose to look.  For example, within the CR itself, statements made by legislators during debate on a measure will include identifiers for both the measure under consideration as well as the legislator speaking.  Similarly, a subsequent roll call vote would identify the measure, each legislator voting, and their vote.  So while the individual’s vote should not, by itself,  be subject to interpretation, the ability to cross-link the debate statement with the subsequent vote via the measure and legislator identifiers would provide essential context for understanding that vote. That linkage is not, in and of itself, an interpretive act to be avoided. But linkage would go a long way towards providing the means for users to quickly and accurately make their own interpretations.  

Section 7 Linked Data considerations
This section is concerned with policy issues related to the transition to a Linked Data environment.  In the first part, we address a series of management considerations that might be involved in making the jump.  In the second section, we present a more technical view that leads to some conclusions about how the transition might be approached.

Linked Data (often termed ‘Linked Open Data’ or LOD) is an outgrowth of activities the Semantic Web community, inspired by Tim Berners-Lee’s 2009 assertion of four simple rules:

	1.	Use URIs as names for things
	2.	Use HTTP URIs so that people can look up those names.
	3.	When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
	4.	Include links to other URIs. so that they can discover more things.

This concept has taken the library world by storm, changing the conversation about the future of library data substantially. The emphasis on identifiers and providing useful information behind them as a support for interoperability has been taken up with enthusiasm. Beginning with the provision of LCSH, the service has continued to grow and expand, providing access to vocabularies and authority files built by the library community and managed by LC.

Building out and beyond legacy data
When Linked Data is discussed with creators and managers of legacy data, whether built in MARC, MODS, DC or any other standard element set or schema, the first questions have to do with costs. How can such changes possibly be contemplated in an environment of diminishing resources? But that response assumes that there are fewer costs in maintaining the extensive workarounds and bespoke applications currently underpinning traditional data. Such a response also denies the the potential for outsiders to provide sources of data that do not need to be re-created and managed by the library. Granted, such a shift will take considerable time and effort directed at planning, retooling, building new skills, and implementation. But the implications of failing to make these changes -- continuing to maintain data in our current silos without connecting to the vast amounts being created on the Web -- must be figured as a cost as well.

Future methodologies require attention to issues that do not occur in legacy data silos. Changing the ‘atomic’ level of concern in data from the ‘record’--the aggregated collection of attribute-value statements made about a particular resource--to the statements themselves (in the form of RDF triples, where the resource ID occurs in every statement), also requires attention to issues like ‘provenance’: the who, what, where, and when that tells us where each statement came from. These ideas are not new, but they are critical to managing data in a much less siloed environment, where the focus is not just local applications, but instead integrating web data in what we do, and making our data attractive to other communities doing the same thing.

But it’s usually not questions about how data is managed that raise the most concern. Rather, the most difficult issues are those that surround integration of new data sources into data streams originally built within limited definitions of trusted data. The infrastructure that now surrounds distribution of MARC data assumes that evaluation, quality control, harvesting and distribution will happen via a central node. Because such a central node for linked library data does not exist (and may never exist), those institutions that see value in the exploration of external sources are on their own. They need to think about how to manage those explorations in ways that inform policy, build skills and tools, manage and evaluate improvement strategies, and document results (and redistribution) in ways that can be replicated and adapted by other institutions. The past forty plus years of MARC database-building has taught us that data built collaboratively and distributed widely costs everyone less, and there’s every reason to believe that those lessons apply equally to the new environment.

The diagram below gives a broad view of the planning tasks involved in re-thinking metadata management within an organization, and how they relate. The four boxes at the second level represent the categories, and also a overview of the steps that metadata goes through at the organizational level. So, for instance, a ‘Harvest/Ingest Plan’ would include the sources of metadata to be collected, the technical environment for harvesting and managing the flow of metadata into the data stores the organization has built, and, most likely, a notification and logging system to allow a manager to view results of the process. The ‘Metadata Evaluation’ step is critical--it’s where the decisions about the suitability of the data are made, and where we determine what kinds of improvements need to be run on the data if it is to reach the level of quality required. If, as is likely, the same data will be reharvested as it changes, the improvement routines will need to become an integral part of the process. Because there may be more than one routine (improvement services are easier to manage in smaller chunks), there may be an optimal ordering that ultimately should an automated stack for production processing. 

Testing, monitoring and re-evaluation are always necessary, since the data providers may well change their strategy, their schema, or any other part of their data, without notice. In addition, as the data is used, different improvements might be substituted, or added to the stack.  And finally, in a linked data environment, data is always redistributed so that others may find new uses for it, apply different improvements, or combinations with other data, or experiments. Re-distribution requires that we inject our own provenance information, because downstream users of the data need to know what has been done to the data by each service that has handled it.  It is by understanding those processes that the essential trust between data providers and users is grown.

The transition to a linked world
An example of how the expression of metadata might change from current practices to those using a statement-based linked data model suggests some steps that might be taken to get from current usage to a more generally useful and efficient strategy.  In the example below — a snippet taken from FD/SYS —  there are two containers, the first for the Committee, the second for the member:

<congCommittee authorityId="hsed00" chamber="H" congress="112" type="S">
<name type="authority-standard">Committee on Education and the Workforce
</name>
<name type="authority-short">Education and the Workforce</name>
</congCommittee>
<congMember chamber="H" congress="112" quality="low" role="COMMMEMBER" state="AZ">
<name type="parsed">Raul M. Grijalva of Arizona</name>
</congMember>

In both cases the content between the brackets is text, in a particular display form, which is then transferred into a display page, presumably with some XSLT handling. Behind the scenes we can see efforts to provide ‘name types’ to ensure consistency, and it may be that the text is wrangled from some other database for efficiency and quality control reasons. If so, that database is primarily used as most library authority files are used: to provide consistent text strings to systems that ‘post’ those strings to end users. The XML data exposed within the system carries those same strings, as noted, and thus are of limited use for external users wishing to provide different services using data from a variety of sources.

For linked data applications, reliance on this sort of text wrangling is frowned upon, since in the Semantic Web world, text strings are considered ‘dead ends’, leading users nowhere and useful only for displays. Much preferred are URIs that reference information (in the case above legislator names and Congressional committees). With IDs for the Committee instead of display text, the user can access information about the Committee (its members, its history, etc.), and the description of the Committee itself will carry the various names used, whether it’s a House or Senate Committee, and any other relevant information. Similarly, the Legislator ID would lead to information about the member, when they were elected and from what district, their party and voting history, and other organizations with which they are affiliated. In the MODS example above, much of the data expressed is simultaneously too much and too little to be useful. In our model, a URI referring to a particular committee would lead to information stored once, containing the information that applications require for linking and display. 

While it is certainly true that THOMAS, creaky as it may be, provides some useful document-to-document linkages, they are quite shallow.  In addition, the context provided in the aggregated displays seems to be created ‘on the fly’ and cannot be referenced outside of THOMAS.  In most cases, when a document--a bill, for instance--is linked to, a user cannot expect links within the bill to take them further, but must instead construct an additional search to find answers to their questions. Linked data is expected to allow a user to follow their nose, no matter where they start their quest. 

Certainly, the most important reason for analysis of the legacy formats is that in a linked data environment, what’s already available can be reused and re-aggregated to increase the usefulness of the whole. For example, the listing of committee members in the MODS records become unnecessary, because committee membership is maintained in a separate structure, where the date of member comings and goings is managed, thus allowing a time-based roster to be available at any time. The listing of members present, however, is still important, although with linked URIs rather than text strings. In a linked data environment, it becomes possible to look at the data from two directions. For instance, with links one can not only see whether a particular member was present at a particular hearing, but also that member’s participation in an array of hearings over time, something that researchers would certainly find useful.

Beta Labs
We are in a transitional period, and these new approaches are not yet institutionalized. Recent experience at the LII shows that the price of relying on third-party Linked Data sources with differing priorities is that applications that are both authoritative and thorough in their coverage -- particularly in the realm of government data --  can be hard to build.  That happens in part because the Semantic Web is relatively new. It is also true that  -- as our section on “future data” above hints strongly -- the “authoritative” sources are not yet entirely comfortable with the technology.  And in any event, aggregation of data sources that were not designed with aggregation in mind can be quite difficult.  

That said, there is much to be gained by building on work done by others, and no good way to determine a realistic long-term approach without conducting public experiments that lead to informed policymaking.  Many organizations now experiment with new services under some sort of alternate corporate identity, either branding them as “beta” services or putting them slightly to the side under rubrics like “Google Labs”.  Such methods would provide a safe means to experiment with new approaches that do not yet meet core requirements for coverage and accuracy, including many that would rely on third-party data providers.

PART FOUR
Modeling issues
This section deals with modeling issues — challenges that we encountered as we looked at the various document corpora involved, and tried to resolve in a way that could deal consistently with all of them.  In that, we believe we were successful. Much of what we arrived at is unsurprising but also unfamiliar — for example, the approach we take to identifiers, and to vocabularies and their management. Other approaches will be quite new, especially the process-oriented approach that separates the modeling of legislative events from the modeling of documents and their version-chains, things that most earlier models conflate.  Other aspects — such as the description of provenance — have been left open-ended because they are active and highly changeable areas for investigation and experiment.

Throughout, the reader may wish to consult the diagram of the “Lilly Ledbetter Fair Pay Act”, which visually demonstrates many of the things we discuss here.

Section 8 Identifiers

Section 9 Identifiers generally
The legislative process described in How Our Laws Are Made (HOLAM) is a lot like the Mississippi River:  formed out of a zillion small tributaries, many of them nameless, joined into a stream that passes through a number of jurisdictions and has lots of side passages, loops and eddies, eventually breaking up again into a series of tiny streams passing through a delta.   There is a central part of the process  -- the mainstream -- that is fairly well mapped, with placenames and milestones that are pretty well understood.  There are hundreds of smaller streams and brooks at either end of the process that are not well understood or named at all, and a few places in the middle where the main stream branches unpredictably.  It is a complicated map, and it describes a territory where many people, places and things are named  -- but  many are not, and some are named in ways that are ambiguous, confusing, or conflicting.

This section is concerned with identifiers, and particularly with document identifiers : snippets of text that uniquely identify  documents that are either generated by the legislative process or are found in its vicinity.  That idea is simple enough. But well-thought-out, carefully constructed identifiers are an important foundation of any data model -- and are surprisingly difficult to design.  The data model we have built has (at least) two purposes:  first, it is a kind of specification that precisely describes data encountered in and around the legislative process, the precise relationships among the data items and elements, and (significantly) relationships between the data and the real-world people, groups, and processes that create and manipulate the data.  Second, it is a device to enable communication among system-builders, stakeholders, and users about what is to be collected, what is to be expressed or retrieved, and so on.   Before any of that can be built in a way that is both precise and communicative, we must be sure of what exactly we are talking about.  Identifiers should answer that question -- what are we talking about? -- unambiguously.   Or at least we would like them to.  Often, our legacy identifier systems don’t do that very well.  As we shall see,  many existing identifier schemes are burdened with competing constraints and conflicting expectations, with less-than-ideal results.

Identifier functions
In print, identifiers have worked differently than we really want them to in an electronic environment.  The conventions of printed books -- use of pagination, difficulty of recall once issued, relative stability of editions, and most of all the assumption that identifiers will be interpreted by human readers with some knowledge of their context and purpose -- result in identifiers that are less rigorous than what we need in a world of granular data processed by machines.  Some illustrations are found below. In reality our legacy "identifiers" are often less-rigorous monikers serving multiple functions, and in a digital environment we must unpack them into separate items with separate functions.  Here are some of the functions:

a) Unique naming.  The diverse monikers that document creators and administrators use in current practice are supposed to provide unique names for documents.  Sometimes they do; often they don’t.  Usually that is because a moniker that is unique within a particular scope loses uniqueness in some wider, unanticipated arena. That is especially likely to happen when a collection of objects is moved from its original, intended scope on to the open Web, but you can find examples closer to home.  A Congressional bill number is a good example: it is unique only within the Congress during which it was assigned.  There might be an “H.R. 1234” for several Congresses; “108 H.R. 1234” is made unique by the addition of the number of the Congress during which it was introduced.  Of course, human error is often at fault, as when (for one year in the mid-1990s), there were two very different section 512s in Title 17 of the US Code.   

b) Navigational reference.  Identifiers often serve as search terms or convenient handles for taking the reader to another document, or for retrieving it (we discuss retrieval next).  Standard caselaw citation practice is a special case of this, created specifically for printed books.  In this legacy context, unique identification and citation functions are often run together, usually because numbered pages are not sufficiently granular to uniquely identify individual items.   For example, two briefly-reported judicial opinions might well appear on the same page of a print reporter, and thus carry an identical citation.  The citation is then a perfectly good tool for navigating to each case within a series of printed volumes, but is not a unique name or identifier for either of them.   A look at http://bulk.resource.org/courts.gov/c/F3/173/ will show that numerous cases, each quite short, originally appeared on page 421 of Volume 173 of West’s Federal Reporter, 3rd Series.   A sample is here: http://liicr.nl/rimZJe .  Any of the cases listed might be cited as 173 F.3d 421.

c) Retrieval hook/container label.   Here, we distinguish use of a citation as a retrieval hook from its use as a navigational device. As we make our way around the Web, that distinction is usually blurred. Following a link to its destination puts a chunk of text in front of our eyes, and so it’s hard to remember that the link might refer to the contents of a container for which it also provides a label, rather than to a simple destination milestone.  

To make the distinction clear, it’s useful to think about incorporation-by-reference or other forms of embedding.  Suppose that we wish to present the current text of a subsection of a statute inside some other online document -- a citizen’s guide to Social Security benefits, for example.  We would likely do that via machine retrieval of the particular statutory subsection based on its identifier -- but our goal would be to summon up a chunk of text, not navigate to a particular destination.  Put another way, our current practice conflates the use of citation as a means of identifying a point, milestone, or destination in a document (a retrieval hook) with a means of identifying a labelled subdocument that can be referenced or retrieved for other purposes (a container label).

As an example, the THOMAS pages for individual bills and resolutions aggregate a great deal of information from the Congressional Record (CR), linking from the Bill Summary ‘Actions’ to both a textual representation of the CR page beginning with the desired text (but sometimes extending past the desired text into other information about unrelated issues) as well as a PDF representation of the page which shows the whole text (where the desired text may start towards the end, plus subsequent pages if the relevant section extends past the initial page). 

For a specific example of this, the Lilly Ledbetter Fair Pay Act of 2009 has a list of major actions on Thomas, one of which is a “motion to proceed to consideration of measure withdrawn in Senate” on Jan. 13, 2009.  The link for information on that motion is to CR S349: a specific page of the Congressional Record. Invoking that link leads to this display:

The Thomas page lists the four items on the particular Congressional Record page, the last of which is the item sought.  When that item is invoked a default page with the specific text of the motion is retrieved, but an additional link to the PDF version of that page can be viewed via a link at the head of the text, with the Lily Ledbetter motion at the bottom of the retrieved PDF.

d) Thread tag/associative marker.   Some monikers group related documents into threads -- aggregations whose internal arrangement is implicitly chronological.  An insurance company claim number is, in this way, a dual-purpose tool.  On the one hand, it refers uniquely to a document (a claim form) that you submit after your fender-bender.  On the other, the insurance company tells you that you must “use this claim number in all correspondence”  -- that is,  use it to prospectively tag related documents.  That creates a labelled group of documents. If we then sort the group chronologically, it becomes a kind of narrative thread.  

In this way, the moniker implies a relationship between the documents without explicitly naming or describing it, as well as being pressed into service as the identifier for one or more documents in the cluster. Regulatory docket numbers function in this manner. That is intentional, because dockets are meant to be gathering places for documents. What is confusing  -- and important to remember -- is that a moniker that uniquely identifies a process -- a regulatory rulemaking -- has been bent to identify a collection of items associated with that process, and neither the association nor the documents have been uniquely identified.

Another conceptually-related but distinct example of that is the use of “captive search” URIs to meet a user’s need to dynamically assemble a set of related documents. For instance, one can retrieve all the environmental law decisions of the Supreme Court at this link:

http://www.law.cornell.edu/supct/search/index.html?query=environment+or+environmental%20or%20EPA

Such URIs embed search terms (“environment”, “environmental”, “EPA”) and, when used in links, retrieve the set of documents found by searching on those terms.  Typically, they are used to deal with instability or growth in the underlying corpus of things being searched. They are “automatically” kept up to date as the collection changes, inasmuch as they just provoke a search of the changed collection. 

In that way, they are a great help to site designers. Problems can arise, however, if the user imagines that the URI somehow identifies the exact set of items retrieved for any time period other than the present moment. Precisely because the method is dynamic, the user may or may not retrieve the same document set at a later invocation.   As a low-cost, low-effort alternative to semantic tagging, however, the approach is irresistible. THOMAS, among many other systems, has not resisted it.  

e) Process milestone.  The grant of a moniker by an official body can be an acknowledgement that official notice must now be taken, or that some process has begun, ended, or reached some other important stage.  That is obviously the case with bills, where a single piece of legislation may receive a number of identifiers as it makes its way through the process, culminating in a Public Law number at the time of signing. The existence of such a PL number can be taken as evidence that the bill has been passed into law.

f) Proxy for provenance.  Again because monikers are often assigned by officials or organizations with special standing, they become proxies for provenance.  The existence of a bill number is evidence that the Clerk of the House has seen something and acted in a particular way with respect to it; it is valuable evidence in any attempt to establish authority.

g) Popular names, professional terms of art, and other vernacular uses.  Monikers notably find their way into popular and professional use, some in ways that are quite persistent.  News media frequently refer to legislation by a popular name created by Congress based on the names of sponsors (the “Taft-Hartley Act”) or by the press itself (“Obamacare”).  They can be politicized (“death tax”), or serve as a kind of marketing tool (“USA-PATRIOT Act”). Some labels and identifiers become very closely associated with the things they label, becoming terms of art in their own right.  Thus, it is common to refer to a “501(c)(3) nonprofit” or a “Subchapter K”  partnership.  Vernacular labels have particular importance for citizens, who often use them as input to search systems.  

Our remarks here demonstrate scoping problems of their own: most of our thinking and examples are primarily derived from government document collections.  It is important that we expand our thinking (for instance) to point-in-time references to multimedia objects, and other non-document resources.

Identifier granularity
How small a thing should we try to identify? It’s difficult to make general prescriptions about this, for needs vary from corpus to corpus.  For the most part, we assume that identifier granularity should follow common citation or cross-referencing practice -- that is, the smallest thing we identify or label should be the smallest thing that standard citation practice would allow a user to navigate to.  That will vary from collection to collection, and from context to context. For example, it’s quite common for citation to the US Code to refer to objects at a number of levels more granular than that of the section, each a labelled subdivision of the text.  On the other hand, references to the Code in the Parallel Table of Authorities and Rules generally refer to a full section.  Similarly, although cross-references within the Code of Federal Regulations can be very granular, external references typically occur at the Part level.  That is because CFR Parts broadly correspond to particular programs within a regulatory agency, and are therefore fairly stable over time.  By contrast, sections within those Parts come and go, changing numbering quite frequently.  In that sense, “standard” citation practice consists of citing to a destination that is most likely to persist over time.  That destination might be more or less granular, depending on the corpus.

But perhaps we should qualify that, for our citation and cross-referencing practices have evolved in the context of print, and we may be able to do better.  The move from print to digital overturns background assumptions about practicality.  For example, print typically makes different assumptions about identifier stability than you would find, say, in an online legislative drafting system.  Good examples of this are found in citation practice for the Code of Federal Regulations, which typically cites material at the Part level because (one imagines) changes in numbering and naming of sections are so frequent as to render identifiers tied to such fine divisions unstable -- at least in print, where the shelf life of such fine-grained identifiers is shorter than the shelf life of the edition by an order of magnitude. In a digital environment, it might be possible to manage identifiers more closely, permitting graceful failure of those that are no longer valid, and providing automated navigation to things that have moved. We look at some of the possibilities and implications in sections on granularity, fragmentation, and recombination below.  All of those capabilities carry costs, and overkill is possible.

Metadata, markup, and embedding
Thinking about granularity leads to notions about the linkages between metadata and the target object itself.  Often metadata applies to chunks of documents rather than whole documents.  Cross-referencing in statutes and legislation is usually done at the subdocument level, for instance, and subject-matter classification of a bill containing multiple unrelated provisions would be better if the subject classifications could be separately tied to specific provisions within the bill. That need becomes particularly acute when something important, but unrelated to the main purpose of the bill, has been “snuck in” to a much larger piece of legislation.  A stunning example of such a Frankenstein’s monster appears at  111 Pub. L. 226 . It is described in its preamble as modernizing the air-traffic control system, but its first major Title heading describes it as an “Education Jobs Fund”,  and its second major Title contemplates highly technical apparatus for providing fiscal relief to state governments.

We are aware that in many cases we will be thinking in terms that are not currently supported by the markup of documents in existing XML-creating systems.  However, we think it makes sense to design identifier systems that are more capable than some document collections will currently support via markup, in the expectation that  markup in those collections will evolve to the same granularity as current cross-referencing and citation practice, and that point-in-time systems supporting the full lifecycle of legislative drafting, passage, and codification will become the norm.  Right now,  divisions of statutory and regulatory text below the section level (“subsection containers”) are among the most prominent examples of “missing markup”; they are provided for in the legislative XML DTDs at (eg.) xml.house.gov, but do not survive into the FD/SYS versions from GPO.

Most often, we imagine that the flow of document processing leads from markup to metadata, since as a practical matter a lot of metadata is generated simply by extracting text features that have been tagged with some XML or HTML element.  Sometimes the flow is in the other direction; we may want to embed metadata in the documents for various purposes.  Use of microformats, microdata, and other such schemes can be useful for various applications; the use of research-management software like Zotero, or the embedding of information about document authenticity comes to mind.  These are not part of the model per se, but represent use cases worth thinking about.

Section 10 Stresses and strains

Semantics vs. purity
Some systems enforce notions of identifier purity -- often defined as some combination of uniqueness, orderliness, and ease of collation and sorting -- by rigorously stripping all semantics from identifiers.  That is an approach that can function reasonably well in back-end systems, but greatly reduces the usefulness of the identifiers to humans (because understanding what the identifier identifies requires database reflection), and introduces extra possibilities for error in application because (inter alia) errors caused by human transcription are hard to catch when the identifiers are meaningless strings of letters and numbers.  On the other hand, “pure” opaque identifiers counter a tendency that humans have to assume that they know what a semantically laden identifier means, when in fact they may not.  And sometimes opaque identifiers can be used to provide stability in situations where labels change frequently but the labelled objects do not.

At the other end of the spectrum, identifier systems that are heavily burdened with semantics have problems with uniqueness, length, persistence, and other issues arising from inherent ambiguity of labels and other home-brewed identifier components.  It is worth remembering, too, that one person’s helpful semantics are another’s mumbo-jumbo; if you need proof of this, just walk up to someone at random and ask them the dates of the 75th Congress. Useful systems find a middle ground between extremes of incomprehensible rigor and mindlessly verbose recitation of loosely-constructed labels. For example, the identifiers set up at http://marc21.rdf.info use a combination of numeric tags from MARC-plus indicators and subfield codes to provide extremely granular naming in ways that are human-readable by catalogers who understand the “language” of MARC.  Similarly, the URI systems in use at the LII for the US Code and the Code of Federal Regulations incorporate common citation practice to create identifiers readable by those familiar with the citation system.

It’s worth noting in passing that it can be very difficult to prevent the unwanted exposure of “back-end” identifier to end users.  For example, URIs constructed from back-end components often find their way into the browser bars of authors researching online, who then paste them into documents that would be better served by more brain-compatible, human-digestible versions.

Moniker type	Identifier	Notes	
Citation	18 USC 47	Standard citation ignores all but Title and section number; intermediate aggregations not needed, and confusing.	
Popular name	Wild Horse Annie Act		
LII URI, (“viewable” version) 	http://www.law.cornell.edu/uscode/18/47.html	Based on title and section number	
LII URI, “formal” version	http://www.law.cornell.edu/uscode/18/usc_sec_18_00000047----000-.html	Also title and section based, but padded and normalized to allow proper collation; “supersection” aggregations above the section level are similarly disambiguated.	
USGPO URI, GPOAccess	http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=browse_usc&docid=Cite:+18USC47	Parameterized search returning 1 result.	
FindLaw URI	http://codes.lp.findlaw.com/uscode/18/I/3/47	Seemingly mysterious, because it interjects subtitle and part numbering, which is not used in citation.  Note that this hierarchy would also vary from Title to Title of the Code -- not all have Subtitles, eg.	

The table above shows some “monikers in the wild” -- various real-world approaches to the problem of identifying a particular section of the US Code.  The “formal” LII identifier, highlighted in yellow, shows just how elaborate an identifier needs to be if it is to accommodate all the variation that is present in US Code section numbering (there is, for example, a 12 USC 1749bbb-10c).  The FindLaw URI demonstrates the fragility of hierarchical schemes; these would vary enormously from Title to Title, and occasionally lead to some confusion about structure, as intermediate levels of aggregation are called different things in different Titles.

Administration and control
Every identifier implies a zone of administrative control:  somebody has to assign it, somebody has to ensure its uniqueness, and somebody or something has to resolve it to an actual document location, physical or electronic.  Though it has taken years, the community has recognized that qualities of persistence and uniqueness are primarily created by administrative rather than technical apparatus.  That becomes a much more critical factor when dealing with government documents, which may be surrounded by legal restrictions on who may assign identifiers and when, and in some cases what the actual formats must be.  A legislative document may have its roots in ideas and policies formed well outside government, and pass through numerous internal zones of control as it makes its way through Congress. It may emerge at the other end via a somewhat mysterious intellectual process in which it is blown to bits and the fragments reassigned to a coherent, but altogether different, intellectual structure with its own system of identifiers (we call this ‘codification’).  There may be internal or external requirements that, at various points in the process,  cause the document to be expressed in a variety of publications and formats each carrying its own system of citations and identifiers.

The legacy process, then, is an accretive one in which an object acquires multiple monikers from multiple sources, each with its own requirements and rules.  Sometimes those requirements and rules are shaped by concerns that are outside, and perhaps at odds with, sound information-organization practice.  

For example, the House and Senate each have their own rules of procedure, in which bill numbering is specified.  Bill numbers are usually accession numbers that reset with each new Congress, but the rules of procedure create exceptions.  Under the rules of the House for  the 106th Congress, the first ten bill numbers were reserved for use by the Speaker of the House for a specified time period. During the 107th and 108th Congresses (at least), the time period was extended to the full first session.  We surmise that this may have represented an attempt to reserve “important” bill numbers for things important to the majority party’s legislative agenda.  Needless to say, this rendered any relationship between bill numbers and chronology or order of introduction questionable, at least in a limited number of cases. The important point is that identifier usage will be hostage to political considerations for as long as it is controlled by rules of procedure; that situation is not likely to change.  

But there are also virtues to the legacy process, primarily because close association with long-standing institutional practices lends long-term stability to identifier schemes.  Bill numbers have institutional advocates, are well-understood, and unlikely to change very much in deployment or format. They provide good service within their intended scope, however much they may lose when taken outside it.

So far as we are able to tell, no system of identifiers currently in public use extends over the entire lifecycle of legislation, though we believe that there are identifiers in use in each chamber’s legislation-management systems that fill this function at the back end. Such a system of identifiers is needed, and would be a “gold standard” that could be related to all of the various legacy identifier systems in use, creating interoperability between identifier schemes across the full lifespan of legislation.   

Status, tracing, versioning
It is useful to distinguish between tracing the evolution of a bill or other legislative document and recording the status of that document.  Status usually records a strong association between some version of the document and a particular, well-known stage in the process by which it is created, revised, or made binding.  That presents two problems.  There is a granularity problem, in that some legislative events that cause alteration of the document are so trivial that to distinguish all of them would be to create an unnecessarily fine-grained, burdensome, and unworkable system. There is a stability problem in that legislative processes change over time, sometimes in ways that are very significant, as when (in 1975) the House rules changed to allow bills to be considered by multiple committees, and sometimes in ways that are not, as when House procedural rules are revised in trivial, short-lived ways at the beginning of each new Congress.  Optimally, bill status would be a property drawn from a small vocabulary of documented legislative milestones or events that remains very stable over time.  Detailed tracing of the evolution of a bill would be enabled through a series of relationships among documents that would (for instance) identify predecessor and successor drafts as well as other inter-document relationships.  These properties would exist quite apart from the identifier scheme. Such a scheme might readily be extended to accommodate the existence of multiple, parallel drafts, as sometimes happens during committee process.

In this way, the model would answer questions about the “version” of a given document by making assertions either about its “status” -- that is, whether it is tied to some well-known milestone in legislative process -- or by some combination of properties that are chained back to such a milestone.  For example, a document might be described as a “committee draft from Committee X that succeeds at two removes the draft originally submitted to the committee, dated on such-and-such a date”.  The exact “version” of the document is given by a chain of relationships tied back to a draft that can be definitively associated with a stable milestone in the legislative process.  This idea is thoroughly discussed and illustrated in the later section, “Section 16 - A process-oriented model for documents and versions”.

It’s worth noting that while it would certainly be possible to identify versions using “version numbers” built out by extending the accession number of the root document with various semantically-derived text strings, it’s not necessary to do so.  The identifiers could, in fact, be anything at all.  All that is needed is for them to be linked to well-known “milestone” documents by a chain of relationships ( for example,  “isSuccessorVersionOf”) that link back to a well-known, numbered document.  This may be particularly important when the document-to-document relationship extends across boundaries between zones of administrative control, or outside government altogether.

More is said on this subject in the section on legislative events and versioning later in the document.

Granularity
Usually, the things that are being 'identified' by identifiers are discrete documents, traditionally rendered as discrete print works. There are, however, significant exceptions that should be accommodated. In addition, changes in the nature and structure of documents that may be issued in the future should be anticipated as well.

The issue of “granularity”, therefore, arises from the need to identify parts of a discrete document. For example, although a congressional hearing is published as a single document (sometimes in multi-volume form), it may be useful to make specific references to the testimony of individual witnesses. Even more significant would be mapping the relationships between the U.S. Code and the public laws from which it is derived. In these cases, the granularity of the identifiers available should be more fine-grained than the documents being identified. So, although a Public Law or slip law can be completely identified and described by a given set of identifiers, it is valuable to have additional identifiers available for sub-parts of these documents, so that mapping adequate relationships to sections of the U.S. Code can be described.

Of course, the danger of admitting such identifiers is that it is that it can be a slippery slope. The set of things which could be identified in legislative documents is fairly unbounded, and any identifiers will arguably be useful to someone. An attempt to label all possible things, however, is madness, and should be avoided. The result would be numbers of unused, or seldom used identifiers which would over-complicate entities and the overall structure of the identifier system.

Section 11 Fragmentation and recombination
Identifiers are used in ways that go well beyond slapping a unique label on a relatively static document.  They help us keep track of resources that can, in the electronic environment, be highly mobile.  Legislation is often fragmented and re-combined into new expressions, some official and some not.  Codification is the most important example of such fragmentary re-use, but there are others.  And in any event, identifier schemes are closely linked to granularity, the design element that designates the smallest addressable unit of the text. 

For many legal purposes, it is important for the fragments to be recognized as authentic, that is, carrying the same weight of authority as the work from which they were originally taken.  Current practice accommodates this through the use of a variety of officially-published finding aids, including significant ones associated with the US Code:  the Table of Popular Names, the “Short Title” notes, and Table III of the printed edition of the US Code, which is essentially a codification map. Elsewhere, Richards and Bruce refer to such a work as a “pont”, that is, something that bridges two isolated legal information resources.  Encoding  of ponts in engineered ways that facilitate use in retrieval systems is a particularly crucial function that should be supported by the identifier model

Bills and resolutions
The world of bills and resolutions contains some specifics worth mentioning, particularly in the way that the design of identifiers is tied to the granularity of the corpus:

	•	Granularity in document addressing. It is not obvious to us that the versions of bills and resolutions that are mounted in (say) THOMAS are encoded in a way that would permit sub-document addressing (perhaps at the level of a Title or Section) although they very well may be.  If so, a system of identifiers for subdocuments will be needed, at whatever level of granularity is supported by enumerated labels in the text.  Sub-section addressing of this kind is supported by the House XML standard, but it is not clear that those encodings survive into THOMAS.
	•	Targets for amendments.  Amending language in the statutes themselves implies at least two “addressing” standards.  Amendments may be expressed in terms of the statute being amended, generally with reference to the subdivisions in the Public Law version of the act, with the act referred to by popular name; or, they may be expressed in terms of the addressing system in use as codified in the US Code.  A third approach, which uses page and line numbers in a printed version, seems only to be in internal use within the Congress, where it poses significant challenges for XML-based document systems.  It may be that we require more than one relationship to model the different systems in use.
	
Indeed, alignment is the overarching issue here.  Different applications make use of seemingly different granularities, and it remains to be seen whether there is a single system that can support all of them simultaneously.  If not, properties will be needed for each and mapping strategies will need to be developed to support ongoing alignment as documentation evolves.  Interestingly, the classification tables that accompany the US Code provide an example of this, in which the original substructure of the Public Law version is related to labelled sections and subsections within the US Code, and to the much-less-granular structure of volumes and page numbers in the Statutes at Large.

Codification
Codification presents challenges, the more so because it can erect substantial barriers for inexperienced researchers.  Citizens often seek legislation by popular name (“Wild Horse Annie Act”). They don’t get far.  The problem is usually (though not always) more difficult than simply uncovering an association between the popular name of the act they’re seeking and some coherent chunk of the United States Code, or a fragment within a document that carries a Public Law number.  Often, the original legislation has been codified in ways that scatter fragments over multiple Titles of the US Code.

That is so because even a coherent piece of legislation -- and many are not --  typically addresses a bundle of issue-related concerns, or the needs of a particular constituency.  A “farm bill” might contain provisions related to tax, land use, regulation of commodities, water rights, and so on.  All of those belong in very different places under the system of topics used by the US Code.  Thus, legislation is fragmented and recombined during the process of codification.  While this results in much more coherent intellectual organization of statutes over the long term, it makes it difficult for users to exchange the tokens they have -- usually the popular name of an Act, or some other moniker  assigned by the press (“Obamacare”) -- for access to what they are seeking.

Table III of the United States Code provides a map from provisions of Public Laws to their eventual destination within the US Code, as the Code existed at the time of classification.  That is potentially very useful to a present-day audience, provided that the relationships expressed in it could be traced forward through time; changes to the Code from the time of classification forward  would need to be accounted for.  That would rest on two things:  an identifier system capable of tracking the fragments of the original Act as they are codified, and a series of relationships that account for both the process of codification and the processes by which the Code itself subsequently evolves.

Fragmentary re-use
Codification is really a special case of something we might call “fragmentary re-use” -- an application in which a document snippet, or other excerpt from an object, is reused outside its parent.  Later in this essay we discuss the problems of identifier exposure in a Linked Data context, noting that identifiers must carry their own context.  A noteworthy example of this is the legislative fragment that needs to carry some link back to its provenance, and specifically its legal status or authority.  Minimally, this would be an identifier resolvable to a data resource describing the provenance of the fragment.  Such an approach might fit well into a “layered” URI scheme such as that used by legislation.gov.uk.

Section 12 Identifiers in a Linked Data context
John Sheridan (of legislation.gov.uk) has written eloquently about the use of legislative Linked Data to support the development of “accountable systems”  The key idea is that exposing legislative data using Linked Data techniques has particular informational and economic value when that data defines real-world objects as the law sees them.  If we turn our attention from statutes to regulations, that value becomes even more obvious.

Section 13 Desirable features of Linked Data

Ability to reference real-world objects
“On the Semantic Web, URIs identify not just Web documents, but also real-world objects like people and cars, and even abstract ideas and non-existing things like a mythical unicorn. We call these real-world objects or things.”
						— Tim Berners-Lee

There are no unicorns in the United States Code. Nevertheless, legislative data describes and references many, many things.  More, it provides fundamental definitions of how those things are seen by Federal law.  It is valuable to be able to expose such definitions -- and other fundamental information -- in a way that allows it to be related to other collections of information for consumption by a global audience.

Avoidance of cumbersome standards-building processes
In a particularly insightful blog post that discusses the advantages of the Linked Data methods used in building legislation.gov.uk, Jeni Tennison points out the ability that RDF and Linked Data standards have to solve a longstanding problem in government information systems: the social problem of standard-setting and coordination:

RDF has this balance between allowing individuals and organisations complete freedom in how they describe their information and the opportunity to share and reuse parts of vocabularies in a mix-and-match way. This is so important in a government context because (with all due respect to civil servants) we really want to avoid a situation where we have to get lots of civil servants from multiple agencies into the same room to come up with the single government-approved way of describing a school. We can all imagine how long that would take.

The other thing about RDF that really helps here is that it’s easy to align vocabularies if you want to, post-hoc. RDFS and OWL define properties that you can use to assert that this property is really the same as that property, or that anything with a value for this property has the same value for that other property. This lowers the risk for organisations who are starting to publish using RDF, because it means that if a new vocabulary comes along they can opportunistically match their existing vocabulary with the new one. It enables organisations to tweak existing vocabularies to suit their purposes, by creating specialised versions of established properties.

While Tennison’s remarks here concentrate on vocabularies, a similar point can be made about identifier schemes; it is easy to relate multiple legacy identifiers to a “gold standard”.

Layering and API-building
Well-designed, URI-based identifier schemes create APIs for the underlying data.  At the moment, the leading example for legislative information is the scheme used by legislation.gov.uk, described in summary at http://data.gov.uk/blog/legislationgovuk-api  and in detail in a collection of developer documentation linked from that page.  Because a URI is resolvable, functioning as a sort of retrieval hook, it is also the basis of a well-organized scheme for accessing different facets of the underlying information.  legislation.gov.uk  uses a three-layer system to distinguish the abstract identity of a piece of legislation from its current online expression as a document and from a variety of format-specific representations.  

That is an inspiring approach, but we would want to extend it to encompass point-in-time as well as point-in-process identification (such as being able to retrieve all of the codified fragments of a piece of legislation as codified, using its original bill number, popular name, or what-have-you).  At the moment, legislation.gov.uk does this only via search, but the recently announced Dutch statutory collection at http://doc.metalex.eu/ does support some point-in-time features.   It is worth pointing out that the American system presents greater challenges than either of these,  because of our more chaotic legislative drafting practices, the complexity of the legislative process itself, and our approach to amendment and codification.

Section 14 Challenges

Uniqueness over wider scope
Many of the identifiers developed in the closed silo of the world of legal citation could be reused as URIs in a linked data context, exposing them to use and reuse in environments outside the world where legal citation has developed.  In the open world, identifiers need to carry their context with them, rather than have that context assumed or dependent on bespoke processes for resolution or access.   For the most part, citation of judicial opinions survives wide exposure in fair style.  Other identifiers used for government documents do not cope as well.   Above, we mentioned bill numbers as being limited in chronological scope; other identifiers (particularly those that rely heavily on document titles or dates as the sole means of distinction from other documents in the same corpus) may not fare well either.

Resolvability
The differences between URNs (Uniform Resource Names) and URLs (Uniform Resource Locations, the URIs based on the HTTP protocol) are significant.  Wikipedia notes that the URNs are similar to personal names, the URLs to street addresses--the first rely on resolution services to function.  In many cases, URNs can provide the basis for URLs, with resolution built into the http address, but in the world we’re now working in, URNs must be seen as insufficient for creating linked open data.

In reality, they have different goals.  URIs provide resolvability -- that is, the ability to actually find your way to an information resource,  or to information about a real-world thing that is not on the web.  As Jeni Tennison remarks in her blog, they do that at the expense of creating a certain amount of ambiguity.  Well-designed URN schemes, on the other hand, can be unambiguous in what they name, particularly if they are designed to be part of a global document identification scheme from the beginning, as they are in the emerging URN:Lex specification.   

For our purposes, we probably want to think primarily in terms of URIs, but (as with legacy identifier schemes) there will be advantages to creating sensible linkages between our system, which emphasizes reliability, and others that emphasize a lack of ambiguity and coordination with other datasets.

Things not on the Web 
Legislation is created by real people and it acts on real things.  It is incredibly valuable to be able to relate legislative documents to those things.  The challenge lies, as it always has,  in eliminating ambiguity about which object we are talking about.  A newer and more subtle need is the need to distinguish references to the real-world object itself from references to representations of the object on the web.  The problems of distinguishing one John Smith from another are already well understood in the library community.  URIs present a new set of challenges.  For instance, we might want to think about how we are to correctly interpret a URI that might refer to John Smith, the off-web object that is the person himself, and a URI that refers to the Wikipedia entry that is (possibly one of many) on-web representations of John Smith.  This presents a variety of technical challenges that are still being resolved.  

Manufacture and assignment
Thinking about the highly-granular approach needed to make legislative data usefully recombinant -- as suggested in the section on fragmentation and recombination above -- quickly leads to practical questions about where all those granular identifiers will come from. The problem becomes more acute when we begin to think about retrofitting such schemes to large bodies of legacy information.  For these reasons, among others, the ability to manufacture and assign high-quality identifiers by automated means has become the Philosopher’s Stone of digital legal publishers.  It is not that easy to do.  

The reasons are many, and some arise from design goals that may not be shared by everyone, or from misperceptions about the data.  For example, it’s reasonable to assume that a series of accession numbers represents a chronological sequence of some kind, but as we’ve already seen, that’s not always the case.  Legacy practices complicate this.  For example, it would be interesting to see how the sequence of Supreme Court cases for which we have an exact chronological record (via file date-stamping associated with electronic transmission) corresponds to their sequence as officially published in printed volumes.  It may well be that sequence in print has been dictated as much by page-layout considerations as by chronology.  Two organizations assigning sequential identifiers to the same corpus retrospectively could, conceivably,  come up with a different sequence.

Those are just the problems we encounter in an identifier scheme that is, theoretically, content-independent.  Content-dependent schemes can be even more challenging.  Automatic creation of identifiers typically rests on the automated extraction of strings derived from one or more document features that can, in turn,  be concatenated to make a unique identifier of wide scope.  There are some document collections where that may be difficult or impossible, either because there is no combination of extractable document features that will result in a unique identifier, or because legacy practices have somehow obliterated necessary information, or because it is not easy to extract the relevant features by automated means.  We imagine that retro-conversion of House Committee prints would present exactly this challenge.  

At the same time, it is worth remembering that the technologies available for extracting document features are improving dramatically, suggesting that a layered, incremental approach might be rewarded in the future.  While the idea of “graceful degradation” seems at first blush to be less applicable to identifiers than to other forms of metadata, it is possible to think about the problem a little differently in the context of corpus retro-conversion.  That is a complicated discussion, but it seems possible that the use of provisional, accession-based identifiers within a system of properties and relationships designed to accommodate incomplete knowledge about the document might yield good results.

Section 15 Common issues with identifier construction and use

Some observations about URIs
Most issues surrounding identifiers have already been raised in this section.  A few observations about URIs are in order, however.

Semantic Web techniques require the use of URIs as dereferenceable identifiers.  There are practical problems that come with that approach.  Most of them stem from (often unrecognized or  unacknowledged) conflict between two views of “path” information contained in the URI itself.  Consider this URI:
 
http://example.org/a/b/c/d

On one view, the entire URI might be one unbroken opaque string that identifies a single object and carries no other implications. In that world, the “slash” character is just another character, with no significance as a delimiter.   On another view, the division of the URI into path components separated by slashes might imply that “a” somehow collects “b” objects which in turn collect “c” objects which in turn collect “d” objects.  That is a convention that is often used on the Web, particularly for things that can be legitimately viewed as document trees (such as the US Code, for which the reader is invited to review the examples above). 

Our working approach is to acknowledge this tension by using each approach for the purpose to which it is best suited.  On the one hand, we imagine a very flat “identifier URI” space in which particular objects are identified as tersely as possible. We still have to come to agreement about what level of opacity is tolerable, but an approach that reflects current citation practice is obviously appealing.  Think of these as “mostly-opaque-identifier” URIs whose sole function is, in fact, to identify objects uniquely.   On the other hand, we imagine a number of patterns for “accessor” URIs, structured and presented in ways that modern Web audiences find intuitive, and with path components that are meaningful.  For example:

	•	http://example.org/H109-1234 
	•	http://example.org/house/bills/109/1234

would represent “identifier” and “accessor” forms for the same object.  The first example is the flattest possible URI that can be used to uniquely identify a House bill (imaginary in this case). The second represents a series of nested collections in which the bill is ultimately found.  It’s also an imaginary example, but it’s easy to see that all of the intermediate levels in the path represent useful collections of things.  It is also easy to imagine alternate “accessor” forms that would embody different useful nestings of collections, but ultimately lead to the same object.

Two worked examples of identifier schemes follow, one for committee hearings and the other for the Congressional Record.  A third example, which shows a more comprehensive attempt at assigning identifiers to collections of events, appears in the “Events that Collect Events” section below.

Worked example: committee hearings
Committee hearings provide a good example of the problem discussed in the previous section:  the need to separate the “unique identification and resolvability” functions of identifiers from their function as accessors under different usage scenarios.  Often, we mistakenly believe that objects can have only one identifier, and hence that it must serve both as a unique identifier and as a semantically-laden string that locates the object within a series of nested collections -- for example, http://congress.gov/house/committees/cha/reports/2012-05-09/whatever_report.pdf.  In reality, a completely opaque string  such as “4397pZ12x” could serve as the unique identifier, and as many accessor URIs as needed can be directed at that identifier -- for example, the more reader-friendly URI just given might resolve to http://congress.gov/house/committee_reports/4397pZ12x , and point to the same object.  The systems needed to do so are inexpensive, both computationally and in terms of effort.

For hearings, it makes sense to us to use some sort of accession number (probably derived from the number of the Congress, the year, and the committee identifier) as the basis of the “unique identifier” function.  Serialization of the numbers would be based on the order in which hearings are created (so to speak) rather than in the order in which they ultimately occur in calendar time, since we imagine that scheduling changes are frequent.   “Accessor”-type IDs might be designed to facilitate viewing by useful subcollections with different sorting orders, including collection by committee, subject, or date range.   Some examples appear in the table below.

http://loc.gov/112-2012-cha-007 	“opaque-ish” URI with enough semantic clues to allow sanity checking by inspection	
http://loc.gov/house/committees/cha/reports/2012-05-09/112-2012-cha-007		accessor URI, report collected by chamber, committee, document type, and date	
http://loc.gov/committees/billreports/111-456/house/cha/112-2012-cha-007		accessor URI, report collected by bill, chamber, and committee	
http://loc.gov/committees/reports/112/2/house/cha/112-2012-cha-007		accessor URI, report collected by congress, session, chamber, and committee

Worked example: the Congressional Record
The Congressional Record (CR) provides a set of complex challenges and solutions for identifier construction. Treating the CR as a collection of components requires identifiers for each component.  It may not be necessary for the client to create its own identifiers for each component; it is likely that any XML schema used to encode the CR would create individual, opaque identifiers for each component, either running sequentially from the start of each issue or within each structural division of the text (indeed, GPO appears to have done something very like this in preparing the MODS metadata found in FD/SYS).  These could be used to uniquely identify each component, but would probably not provide a good basis for “accessor” URIs used to create user-friendly browsing interfaces.  

For those, we would propose a system of date-based URIs for issues that could then be extended to create URIs for each component.  Component extensions would be, essentially, a system of nested accession numbers running to the smallest granular level within the text.  Some examples, all taken from the 23 April 2012 issue of the CR, follow.  They are meant to be illustrative rather than exhaustive.

URI	Identifies	
../CR/2012/04/23/	CR issue of 23 April, 2012	
../CR/2012/04/23/ExtRemarks/	Extended remarks section of that issue	
../CR/2012/04/23/Senate/9	Motion to proceed on the Violence Against Women Reauthorization Act of 2011, which is the 9th subdivision within the Senate section.	
../CR/2012/04/23/Senate/9/3	Remarks of Sen. Lieberman regarding postal reform, the third subheading within the section described above.	
../CR/2012/04/23/Digest/Senate/ChamberAction/Considered/1	Same as ../CR/2012/04/23/Senate/9	

Of course, the use of integer components in these identifiers is not at all reader-friendly, but doing better is probably not possible.  Any automated technique used to construct more readable URIs -- say, by extracting and  using the last name of the Member extending his remarks -- is likely to run into problems with naming collisions.  That suggests that these sorts of URIs are “accessors” -- primarily useful in constructing browsable, structure-based interfaces whose component labels could be pulled from other metadata associated with the component. 

As the last example in the table above suggests, there will be a need to match identifiers in the body of the Senate and House sections of the CR with their corresponding entries in the Daily Digest.  That will require some kind of mapping relationship between the two.

Page numbers provide the basis for many references to the CR, be they internal cross references or citations from other, external materials.  That is especially visible in the CR Daily Digest, which associates page ranges with its entries, but it is probably ubiquitous.  Much of the time -- depending on the user’s starting point --  this is a relationship that will need to be inferred.  For example, a reader interested in seeing a print-like manifestation of a component that they are reading in an online system would access it via a retrieval process that would (automatically) look first to the corresponding Daily Digest entry and then retrieve the range of pages that the Daily Digest entry suggests.

GPO has taken an interesting approach to the inclusion of page numbers in what is basically a structural model.  For each granule and sub-granule, GPO offers an “extent” description that includes start and end pages for the granule.  This can be a little misleading if one then takes the given extent as indicative of the real size of the element; a 20-word granule can “extend” over 2 pages if it falls on a page break, but it is certainly not two pages in length.

Some general recommendations
To make detailed recommendations for each corpus mentioned in the BAA would be too detailed and lengthy a task for us here.  The worked examples provided earlier in this section outline the issues involved in identifier design, and provide some useful approaches. We also discuss identifiers for events in a later section; they provide perhaps the greatest challenge of any in the model where variety and proliferation are concerned.   Here, we make broad recommendations based on the general principles stated throughout this document.  We start with some thoughts about how the process might be undertaken.  Although administrative recommendations go well beyond our brief, we do think that a consciously-arrived-at stance on identifier construction and administration is both fundamental and crucial.   

What, exactly, is the problem?  At our most ambitious, we would like to be able to relate every object identifier (say, for a bill) to every other identifier that has ever been used to refer to that object.  If we were talking only about documents, we might say that we would want to find, in every document or meaningful subdocument, some clue that would lead to us to its name in every system that has ever provided a representation of that document, or used one of its identifiers.  We would like to do that even when perfect alignment does not exist between systems, for example when translating identifiers for items in the Congressional Record to page numbers in the printed publication.

In our view, there are many possible ways to attempt this. We summarize two broad policy regimes here; earlier in this document, we say a great deal more about the detailed design issues involved, particularly those related to the use of legacy identifier systems in a Linked Data environment.

In a fully centralized standards-based approach , someone -- or a group representing a lot of someones --  would attempt to create an overarching standard for all useful identifiers that will in turn be respected by all stakeholders.  There is probably no process that could create such a standard in reasonable time, and no one in a position to enforce it.  Something similar to this was undertaken in the metadata design associated with regulations.gov, with very uneven results.  In that case, various attempts were made to enlist cooperation and compliance by relaxing the standard, with the result that the standard became so watered-down as to be useless.  No doubt there are many other ways to provide incentives for participation and compliance, or to ease the pain of adoption, but we are not optimistic about the outcome of any top-down approach.

The more likely course -- and certainly the one that is being played out in the Web of Data generally -- is a “thousand flowers blooming”  approach, in which different parties are free to mint whatever identifiers they need and expose them on the Web.  We might hope that data creators would also provide systems that relate their identifiers to those used by others to describe the same objects.  That would require in turn that all parties have a certain amount of expertise in identifier design, a certain amount of altruism in their approach to implementation, and awareness of the needs of others who might want to make use of their data.  Those are not universal qualities, and no doubt there would be gaps and missing links in the chain of relationships.  There will be a need for third parties with the necessary expertise to identify and fill gaps of expertise and implementation by building bridges between systems that would otherwise remain isolated --  a sensible role for a library.

Whatever approach is ultimately taken, it would seem that a census of all identifier systems in use, past and present, would provide a useful starting point.  Such a survey would require the cooperation of all data creators and republishers within the legislative branch.  It would yield information useful in formulating a practical policy, and might also usefully raise awareness of the issue throughout the various offices involved.  Our work on this project is a good start, but given our outsider status it is limited in what it can consider. 

Turning from policy to more practical aspects of implementation, it seems to us that the most practical strategy would involve the retention of legacy monikers in the foreground, related to a strengthened “gold standard” system that provides full functionality:

	•	At the most fundamental level, everything should have an identifier. It should be available for use by the public. For example, Congressional committee reports appear not to have any identifiers, but it would be reasonable to assume that some system is in use in the background, at least for their publication by GPO.
	•	Many legacy identifier systems will need to be extended  or modified to create a gold standard system, probably issued by a third party and not by the document creators themselves.  That is especially the case because there is nobody in a position to compel good practice by document creators over the long term.  Such a gold-standard will need to be:
	◦	Unambiguous. For example, existing bill and resolution numbers would need to be extended by, eg., a date of introduction.
	◦	Designed to resist tampering. When things are numbered and labelled, there is a temptation to alter numbers and labels to serve short-term interests.  The reservation of “important” bill numbers under House procedural rules is an example; another (from the executive branch) is the long-standing practice of manipulating RIN numbers to color outside assessments of agency activity.
	◦	Clear as to the separation of titling, dating, and identification functions.  Presidential documents provide a good example of something currently needing improvement in this respect.
	◦	Taking advantage of carefully designed relationships among identifiers to allow the retention of well-understood legacy monikers for foreground use, while making use of a well-structured “gold standard” from the beginning.  Those relationships should enable automated linkage that will allow retrieval across multiple, related identifier systems.
	•	Where possible, retain useful semantics in identifiers as a way of increasing access and reducing errors.  It is possible that different audiences will require different semantics, making this unlikely to happen in the background, but it should be possible to retain this functionality in the foreground.
	•	Maintain granularity at the level of common citation and crossreferencing practice, but with a distinction between identifiers and labels.  Identifiers should be assigned at the whole-document level, with the notion of “whole document” determined on a corpus-by-corpus basis.  Labels may be assigned to subdocuments (eg., a section of a bill) for purposes of navigation and retrieval.  This is similar in function and purpose to the distinction between HREF and NAME attributes in HTML anchor tags.
	•	Use a layered approach.  In our view, it is important not to hold future systems hostage to what is practicable in legacy document collections.  In general, it will be much harder to implement good practices over documents that were not “born digital”.  That is not a good reason to water down our prospective approach, but it is a good reason to design systems that degrade gracefully when it becomes difficult or impossible to deal with older collections. That is particularly true at a time when the technologies for extracting metadata from legacy documents are improving dramatically, suggesting that a layered, incremental approach might produce great gains in the future.

Section 16 A process-oriented model for documents and versions
Existing ways of modeling -- or even discussing -- what happens to a measure as it makes its way through Congress are characterized by some confusion between closely connected approaches that are, nevertheless, subtly different. Broadly, those approaches might be divided into three types:

	•	A process-aware model, in which documents are seen as artifacts produced by particular actions or processes within the legislature.  (On that view, a “measure” is something of an abstraction that groups a series of bill or resolution texts created during the legislative process,  as well as related documentary artifacts such as amendments, signing statements, and so on).  Such a model might be one of two types:
	◦	A model that identifies major stages and events of interest to both legislative insiders and the public.  Examples might include the THOMAS vocabulary for bill stages, or the steps represented in a simplified infographic created for public education.
	◦	Finer-grained, events-based models that divide the legislative process into minutely detailed steps needed by particular communities, for example those interested in the activities of Congressional committees.  These might be thought of (and designed) as extensions of the less granular model.

	•	A “legislative process” model containing parliamentary process detail. From a distance, this approach looks a lot like a very fine-grained version of the process-aware model just mentioned.  But this is a place where differences in detail become a real qualitative difference. Such a model is far more detailed in its treatment of parliamentary procedure, rules for debate, and other turns and twists primarily of short-term interest to Congressional insiders.  That is the type of story told, for example, by the CRS report on resolving differences between House and Senate bill versions. Pieces of such an approach show up in the bill-status attribute used by the House for its XML schemas and DTDs, which contains such status indicators as “held-at-desk-House” and “reengrossed-amendment-Senate”.  Because it is so detailed in matters that change at the will of Congress, it is also highly volatile.

	•	A “workflow” model, which focuses on the actual flow, versioning, and exchange of documents or other work product.  Such a document-centric model has obvious intersections (and points of confusion) with the “process-aware” model, in which major legislative events tend to produce important versions of documents.  It also intersects the “legislative process” model, in which certain parliamentary actions (such as amendment) provoke the production of particular documents.

Most of the existing vocabularies in use  -- which tend to use words like “status” or “stage” to describe their components -- use more than one of these approaches at the same time.  That leads to some subtle confusion. Each of the approaches views the world a little differently, and mixing them leads to inconsistencies.  An illustration  of such a mixed model is provided by the “bill stage” vocabulary from GPO, which contains aspects of the process-aware model (“Considered and Passed House”), the legislative process model (“Additional Sponsors House”), and the workflow model (“Amendment Ordered to be Printed Senate”) all at once.

We have taken a process-aware approach to create the spine of our model, for several reasons. We have tried to map as much useful detail as possible, while avoiding the many pitfalls inherent in trying to over-think and over-model.  An excessively detailed approach focussed on particular parts of the process tends to skew the usefulness of the resulting model in favor of a limited number of specialized users. Also, too much detail in any or all aspects of such a system inevitably results in a model too cumbersome to be used or maintained:
	•	Too-fine distinctions between identifiers will become confused and misapplied, both by maintainers and users.
	•	Many identifiers thought useful will end up being dismissed as over-specific, leading to inefficiency and eventually, further confusion.
	•	The level of technical expertise required to implement and maintain a too-highly-detailed model will become limited to far too few individuals to guarantee its proper use.
	•	Finally, the time and expense involved in too great a level of detail will, in the end, render it of limited usefulness.

Instead, we have tried to provide a model that is “just right” in its level of detail, while acknowledging that our decisions about the various trade-offs involved in such an approach would not be everyone’s. The model has been created with an inherent extensibility that ensures that others may later add any level of specialized detail that they need.  

Beyond avoiding problems with excessive detail, such an approach has a few virtues:

	•	Conformance with (and respect for) existing systems.  It will probably come as no surprise that most of the existing systems that track legislative information agree as to the major features of the process.  So do most of the helpful narratives -- such as HOLAM and a wide array of CRS reports -- that inform people about the process.  With such obvious landmarks in common view, it would be a mistake to suggest a map that ignores the landmarks that everyone sees and agrees on.
	•	Interoperability.  Using a coarser-grained, process-aware model requires a willingness to compromise the precision of  meaning that might be achieved through the use of more specialized objects, relationships, and identifiers at every stage of the process.  However, the compromises are not so great. The interoperability that results from making use of existing systems and standards more than compensates for them.  We believe that most of those who currently track legislative information will be able to find obvious points of correspondence and linkage for their own systems.
	•	Clarity.  Our process-aware approach provides a means of clearly tying the document model to the process model without creating confusion. Our bifurcated audience looks at events in quite different ways.  Researchers see events in the context of the legislative process, and focus on the aspects of the events that are of most interest to them, whether it be votes, committee activities, or some other point of interest. Librarians, on the other hand, think of events in the context of their documentary evidence, whether physical or digital, because their descriptive traditions are based on documents.  In a very real sense, we see our mission as bringing those two points of view closer together, by using the power of linking to make it possible for members of each audience to find what they need and relate the available resources together in various ways .

At the highest level, one could describe a process-aware model like ours as having two components:  a model for legislative events, which describes  successive steps in the legislative process, and a model for documents, which includes chains of version relationships (among others).  The two are linked together by associating important documents (or document versions) with legislative-process milestones (events).  Here is a partial illustration of the model as it would be used to represent an imaginary committee-hearing process:

The illustration shows a part of the network of descriptions surrounding a legislative event — in this case, a committee hearing (shown schematically in violet, at the center of the illustration) that is considering a bill (a LegislativeMeasure object).  The hearing is tied to the bill by reciprocal hasDocument/hasEvent relationships.  The hearing has other properties, shown in pink, and other documents, shown in light green.  The bill has other properties, shown in dark green.   A researcher, or an automated agent, can pick up the trail at any point — from the hearing-event, from the bill that is tied to the hearing, or from any of the other hearing documents, hearing participants, or what have you — and follow the chain of relationships to any of the other items.

The remainder of this section is divided into discussions of legislative events, and of versioning. We turn first to events.

Section 17 Legislative events
Legislative events -- things that take place as part of the legislative process -- seem straightforward to define.  They are those things that occur in the legislature: meetings, debates, parliamentary maneuvers, and so on.    But let’s stop for a minute and consider one of the more important words we associate with legislative events:   “vote”.   As a noun, it has two meanings:
	•	an occasion on which people announce their agreement or disagreement with some proposition or other;
	•	the documentary record of that occasion, expressed as a tally of yeas and nays.

That duality -- what happens, versus the record of what happens -- creates confusion.  We often talk about the documentary record as if it were the process, and vice versa.  That creates problems when a community that is primarily concerned with legislative process -- consumers of legislative information like staffers on Capitol Hill, members of Congress, and others who work with the process itself -- talks to information architects who are primarily concerned with the documentary record.  Subtle differences in understanding about what data models represent  can lead to real confusion about the capabilities of information retrieval systems, particularly during conversations about design and evaluation.

The accompanying figure illustrates the vocabulary of legislative event types we use in the model, and gives some idea of the breadth of the challenge.

It is admittedly hard to keep these things straight, the more so because as documentarians we are so accustomed to conflating the event and the record of the event.  Throughout this section, we have accordingly been at some pains to distinguish the two.  The next section discusses events as occasions.

Events as occasions
Events are things that occur at a time and place.  They might have duration, but they might also represent an action or change of state for which duration is irrelevant.  For example, one might describe the introduction of a bill as something that takes place during a measurable interval that extends over some milliseconds from the time an envelope leaves the hand of the Member introducing the bill until that envelope hits the bottom of the hopper.  But that would be silly; some events are simply process milestones or instants that have no duration we need worry about.  Most events have participants. Some groups of participants are recurring or somehow formalized;  it makes sense to tie events to our models for people and organizations, discussed in a later section.  Other participant groups may be ad hoc groups defined solely in terms of the event (“the people waiting for the 3 o’clock bus”).  Finally, events can result in things : notes produced by a musician playing an instrument, or a pie baked as part of a contest, or a legislative amendment produced in the course of a committee meeting.

Duration and timestamps
Events may have duration, or they may not.  “Bill introduction” and “adjournment” are in some sense physical processes that take place in the real world -- a piece of paper is placed in a hopper, or a gavel is struck and people gather up their papers and leave the room --  but we generally think of them as instantaneous abstractions that refer to a point in a process.  By the same token, events may have a duration that is defined with an uncommon use of common language.  A “legislative day” is an example of such a thing: it extends between one adjournment of the Senate and the next, which may occupy days or even months in calendar time.

In our model, events with duration have specific start and end times as properties.  Events without duration have a timestamp as the value of a separate property. Our model specifies time using the W3CDTF date format.

Participants and roles
We discuss people and organizations in a separate section of this document, and we discuss some aspects of organizational membership models in that section as well.  Participation in events raises a few other questions about our models for people.  In particular, we would stress that people can occupy particular roles with respect to an event, and that those roles may be quite separate from the role that the person occupies within the sponsoring or convening organization.  For example, two of the authors recently attended a workshop sponsored by the Committee on House Administration; the convenor was the Technology Policy Director for that organization, and the Committee Chairman was one of the speakers -- but he played no leadership role in the workshop itself.  Thus, it is necessary to have a set of role properties that adhere to the particular event.  This results in a proliferation of role-related properties that will need to be managed, but probably makes for less difficulty in extending the model when necessary. 

Location and location defaults
Many events take place somewhere in real space, and so event objects need to have attributes that tell us where the event occurs.   As with other data about places, we might choose to model these with geographic coordinates, locations drawn from geodata ontologies, or both; that is the approach we suggested in our earlier work on bills and resolutions.   But neither of those systems deal particularly well with things like office addresses (“1313 Longworth House Office Building”), which provide location information for the kinds of events we associate with legislative process.  Those tend to be expressed as office locations or postal addresses.  Examples of purpose-built systems for postal addresses include the Universal Postal Union S42 standard, the vCard ontology, and the W3C PIM standard.  Of these, the vCard standard seems to present the best balance of detail and workability, and is incorporated into the developing W3C standard for governmental organizations. 

Often, location information is not explicitly stated, but implicit in the nature of the event itself. “Meeting of the House Ways and Means Committee”, for example, embeds a reliable default assumption about where the meeting is to take place, because the meetings always take place in the hearing room that belongs to the committee.  It makes sense to model default assumptions about locations as something that is a property of the organization (e.g. “hasDefaultEventLocation”) rather than of the event. When information about the event itself is partially or totally incomplete, a location can be inferred via the organizational sponsorship of the event.

Events that collect events
Some events are primarily interesting as collections of other events -- for example, a “session” of Congress, which might be seen as a collection of various occurrences on the floor of the legislative chamber, committee meetings, and so on.  Moreover, we might want the same event to be visible in very different collections -- for example, a particular committee meeting might be part of a calendar, part of a history of meetings of that particular committee, or part of a collection of meetings that different committees have had with respect to a particular bill.

That has implications for identifier design.  As we have in other discussions, we would emphasize here the importance of distinguishing between identifiers (URIs) that provide unique, dereferenceable identification of an object (where that object may itself be a collection of other objects), and alternative URIs used solely for access purposes.  Event identifiers need to be short and opaque;  identifiers for collected events can have elaborate (and varied) semantics associated with path elements in the URI.   Here are some illustrative examples:
http://congress.gov/congresses/101/sessions	All sessions of the 101st Congress	
http://house.gov/congresses/101/sessions/2011/	First session of the 101st Congress. We believe that the use of the year is more helpful than misleading.	
http://congress.gov/congresses/101/sessions/2012/events/2012-04-23/votes 	All votes taken on 2012-04-23, House or Senate.  	
http://congress.gov/congresses/101/sessions/2012/events/2012-04-23/house/votes	A collection identifier that mirrors the organization of the Congressional Record (though other ordering of the hierarchy would also be sensible)	
http://congress.gov/congresses/101/house/sessions/2012/votes/[vote-number]	An individual identifier for a vote (House roll call vote numbering runs with the session)	
http://congress.gov/congresses/101/house/committees/events/hearings 	All hearings before House committees for the 101st Congress	

Even this limited set of examples shows that consistency and thorough coverage of imaginable use cases will require a lot of painstaking work if they are to be achieved simultaneously.  Different -- and possibly inconsistent -- orderings of the collection hierarchy make sense for different purposes.  For example, should the committee information come first in the path hierarchy, or the type of committee event?  For some users, ../events/hearings/committees/Judiciary makes more sense than ../committees/Judiciary/events/hearings , and so on.  Which of these pathways will be “real” unique identifiers, and which should just represent access pathways to the information?

Documents as event products
Events produce things.  Of greatest interest to us, legislative events tend to produce documents that were either themselves the “subject” of the event (as in floor debate over a particular bill) or its result (as when a committee markup session produces a new version of a bill).   

The role of the document (or the more abstract notion of a “bill” or “resolution” of which it is the expression) as a value for an “aboutness” property is problematic.  As we have remarked elsewhere, bills often have multiple provisions on widely different topics, and a bill’s identifier would be potentially confusing or unhelpful as the sole value offered as, say, the “subject” of a debate.  At the same time, it is quite legitimate to say that the bill is what the debate is “about”, in the sense that the bill number would no doubt appear in any headline or agenda entry used for a description of the event -- regardless of whether a single word of the discussion actually was about any part of the bill itself, or whether it was a more general discussion about an issue that the bill was meant to address, or was an occasion for a partisan attack on another party.  It might thus be wise to distinguish the “agenda item for the discussion” from “the subject of the discussion” in some way.

Modeling the proper relationships between a sequence of events and the documentary workflow that more-or-less tightly reflects it is a difficult thing.  The next section discusses that problem in some detail.

Versioning
Traditional library cataloging has developed different strategies to describe and track changes, whether in name, content, focus, or format. Those strategies embedded a number of assumptions,  and they had their own goals and implications that have proven more or less applicable to the digital world.  Nonetheless, they have something to teach as we approach the problems of change in legislative materials. It is particularly worthwhile to think about how these strategies have responded to a series of follow-on changes growing from the move to digital formats.

There have been several noteworthy types of change:
	•	Changes of title and issuing body in serial publications, which were sometimes accompanied by changes in frequency, content focus, and, more recently, format. In responding to these changes, libraries moved to strategies of ‘chaining’ versions rather than attempting to aggregate all changes together. This ‘chaining’ strategy has also used to relate various sequentially published editions of textbooks, reference books, and other types of materials.
	•	The proliferation of concurrent versions of the same content, primarily intended to soften the impact of format changes for libraries, publishers and users who were reeling from the uproar of the digital revolution. The inevitable direction of the changes -- from print to digital -- plus the inability of library computer systems to cope with the proliferation of catalog records, encouraged the cataloging community to try and establish an ‘original’ version from which to more efficiently ‘hang’ descriptions of equivalent versions. The result has been chaotic. It has effectively degraded the usefulness of library data going forward, given that such ‘mashups’ are very difficult to reverse.
	•	An accompanying (and sometimes unnoticed) diversification of the content itself, driven by format and bundling. The digital version proliferation problem gradually (and inevitably) morphed into what looked like equivalent versions of the same content in different formats, but were not.  The different versions were really becoming different content, with different distribution models, and different sorts of ‘containers’ allowing users to view or pay for the content at various levels, from aggregation (serial title) to separate article. 

Similar challenges have permeated the world of government documents as the Federal Depository Library Program -- the main distribution channel between the government and libraries -- responded to resource and other environmental pressures by shifting from print, to CD, to web-accessible publications.  In all these cases, the challenges are similar: how to describe things in the world that have one or another (or both) kinds of version relationships -- either horizontal, where the various versions can often be ‘chained’ together using some variation of predecessor/successor relationships, or vertical, where the same or similar content is issued in more than one ‘package’ and the challenge is to allow the end user to decide which version is of more use to them.
	
With legislative materials that are ‘event-aware’, as in our model, there are additional challenges. But there are also new ways to describe relationships that assist in discovering and using legislative materials. We are using two simultaneous approaches.  The first anchors some versions of documents to particularly important process events, via “hasDocument” and “hasEvent” relationships.  The other chains successive versions together via “isVersionOf”  relationships.  That allows any number of variations on the document to be linked to each other and to well-understood events in the legislative process.  Here is a simplified representation of a committee hearing,  that shows versioning of various types, linked to the hearing event:

Section 18 Vocabularies
This is a library-oriented section.  In it, we discuss the use of subject-matter vocabularies, and the use of vocabularies in descriptions, from the point of view of library standards and practices that are evolving in ways that are strongly informed by the new approaches that the Semantic Web brings to knowledge organization. Other discussions of vocabularies are found at other points in this document, including:
	•	A discussion of vocabulary design and management
	•	Vocabularies that relate to people and organizations
	•	A legislative-events vocabulary

Subjects and classification
Traditional library cataloging practice uses controlled vocabularies for a number of purposes, most commonly to express the ‘aboutness’ of a resource.  In libraries, this aspect of a description is most often called ‘subject’, and the assignment to resources called ‘subject cataloging’. It’s not entirely clear why librarians resist using ‘topic’ as a synonym, but  — perhaps because the Library of Congress Subject Headings (LCSH) have been used as the primary vocabulary in libraries for over a century — the connection is now probably hard-wired into librarians at birth. The use of ‘topic’ as an alternative is sometimes seen as the poor cousin at the table--small, without heritage or appropriate complexity. The use of ‘subject’ is so pervasive that the Dublin Core element expressing ‘aboutness’ is also called ‘subject’, most likely due to the presence of a significant number of librarians present at the birth of that now-pervasive Web vocabulary.

But ‘subject’, already an overloaded term, becomes even more problematic as RDF and linked data become more familiar in libraries.  The RDF triple consists of a ‘subject’, a ‘predicate’ and an ‘object’, and the definition of ‘subject’ in this context does not follow its use in library practice. If for no other reason, this confusing situation suggests that libraries start shifting from ‘subject’ to ‘topic’ where possible. This shift is likely to be welcomed by library users, whose affection for ‘subject’ over ‘topic’ has never been generally noted.

In the traditional library world, standardized vocabularies (whether for topic, genre, or role) are used primarily to provide approved text strings. In the case of LCSH, these text strings may contain different subdivisions-by-type (topical, geographic, genre) constructed according to complex rules intended for human use.  That approach is problematic in the digital world:

First, the ‘data’ version of LCSH available at http://id.loc.gov is widely used, but it has gaps that are not widely understood. It was built using the machine-readable version of LCSH -- long available from LC by purchase or subscription.  That version had built-in problems inherited from the printed version. Catalogers constructed text strings according to a prescribed order, sometimes using ‘pattern’ headings that defined how the subdivisions should be created, but without machine-readable evidence in the paper or digital files, except as text in instance data. The client has long understood this to be a problem, and determined that their preferred solution will be to provide an identifier for every complete string, with subdivisions included, to be added to the data file. 

That solution assumes, first, that the machines receiving these strings will be able to deconstruct them usefully for a variety of purposes, and, second, that this solution is sustainable in an environment of distributed creation and use that is also characterized by diminishing  resources. There is already a de-constructed version of LCSH, developed over the past 20 years by OCLC and LoC, called FAST (for Faceted Application of Subject Terminology) Because this version was built to support a faceted approach -- far more useful in data applications than strings built for card catalogs -- FAST has long been seen as a better fit for subject access in the digital world. The FAST data has been available in an ‘experimental’ mode for linked data applications since late last year but there are no promises that it will be available freely for production use when the ‘experiment’ is completed. Unfortunately, OCLC has a long history of making available ‘experimental’ data and services that never leave that status, sometimes for a decade or more.

Second, alternative topical schemes, such as the one used in THOMAS, are specifically developed for legislative materials, and tend not to be as complex as LCSH. The THOMAS subject terminology has two levels (and topics can potentially be assigned on either level) but seems to lack identifiers, distribution mechanisms, or maintenance and extension policies.  It also has a limited scope. Additional development and exposure of the THOMAS vocabularies would require time and money. It would also require a plan that recognizes both the strengths and weaknesses of the current strategy, as well as comprehending how the extensions might be accomplished using current vocabulary standards and evolving Semantic Web mapping techniques.

Third, classifications, such as the Library of Congress Classification (LCC) and the venerable Dewey Classification, provide a very different kind of topical approach. They each provide the kinds of linkages between topics, expressed hierarchically,  that support browsability far better than LCSH (with its somewhat limited thesaural structures) and the THOMAS vocabulary (with its simple two-level approach). LCC has been developed extensively over the past century, with most of the legal classifications the most recent. All of the schedules are available digitally via LC’s data-purchase programs, as well as in its subscription based ‘Classification Web’ and ‘Cataloger’s Desktop’ products, and, of course, on paper.  There has been a recent ‘beta’ implementation of the LCC in http://id.loc.gov, and two members of this team participated in an informal meeting at the Library where plans to mount the LCC classes for Law were discussed, pending installation of additional technical capacity for the service. That is definitely good news for the current effort. The Dewey classifications are available from OCLC, with the upper levels available freely and the detail by subscription. Dewey is not ordinarily used in law libraries but is often familiar to non-researchers, so it cannot be discounted .  The OCLC website includes a discussion of Dewey-as-linked-data (also an ‘experimental service’), which is also worth exploring.

Because there is solid precedent for usage of multiple topic schemes, there is no either/or requirement here, but policies are needed.  In particular, consideration needs to be given to how these topical vocabularies might be evaluated or developed sufficiently for use in the short-term, along with some longer-term strategies to improve topical access to legislation.  A particular issue is the increasing number of “Frankenbills”, in which provisions related to a wide variety of unrelated topics are found in the same bill; the application of topical information at a much more granular level is needed.

Use of vocabularies in descriptions
Semantic Web technologies and Linked Data methods are changing the way in which we view vocabularies. These new approaches hold that, as much as possible, standard descriptive terms should be referenced with URIs within a description, not by text.  That notion is gradually taking hold in the library world, where the preference for standard vocabularies has always been strong, but where specified vocabularies were primarily used to provide approved text strings (or codes that could be displayed as standardized text strings for use in a specific data silo). In a world where data must be read, parsed, and used by any number of machines, the requirements are changing. 

For this project, it made sense to adapt a few of the more extensive RDA vocabularies for content type and encoding format, especially insofar as they were designed to act in concert with the publishing industry’s ONIX standard.   We also needed to develop some specific legislative vocabularies for the specialized material itself. In all cases, because these vocabularies are built in standard ways, they can be extended as needed. The legislative vocabularies may be accompanied or extended by vocabularies being developed elsewhere, many of which are in active use in similar environments with similar needs.

That approach differs from the traditional document-centered approach of libraries by making the events primary but still including the description of documents and other ‘document-like objects’ such as videos of hearings, images of events, and other associated materials more familiar to librarians.  This approach provides a clearer solution for the versioning issues that have bedeviled libraries as digital versions of printed documents came on the scene. 

Adapting the RDA content type vocabulary allows both the ability to extend in directions that RDA might not travel, and also to easily map from the adapted vocabulary to the RDA one when and if necessary. The RDA vocabulary includes a richer set of content types, but many are not relevant in the legislative domain (covering maps and music, for instance).

It’s important, when viewing these vocabularies, to remember that the names of the terms used by the RDA Vocabularies in no way requires that those names be used as labels for user displays. For instance, “Two-dimensional moving image” is what most of us think of as video, and “Spoken word” a more specific term for non-musical audio.

In most applications, it’s usually not sufficient to describe what something ‘is’ at that level, because user choices when confronted with various versions of content are often predicated on what they can use most easily in their environment, which most often means a specific computer platform. More and more the browsers we use every day make those differences easier to bridge, but when a user is attempting to download something or use it with a specific non-browser platform, the distinctions remain important. In the vocabulary below, a selected number of the encoding formats available in the RDA Encoding Format vocabulary are shown, along with the upper level categorizations that indicate what kind of content is encoded. As in the content type vocabulary, the RDA original versions have more choices, but not all are relevant to this project.

	

Section 19 People and organizations
In today’s world, there is no need to settle on a single standard for describing people and organizations. The current environment, where the speed of change can be daunting, demands strategies that start with descriptive properties that meet local needs as expressed in use cases. Taking the further step of mapping these known needs to a variety of existing standards best provides both local flexibility and interoperability with the wider world. 

In the world of Web standards, most considerations of appropriate people and organization descriptions begin with the FOAF vocabulary , developed in 2000 as ‘Friend of a Friend’ and now used extensively on the web to describe people, groups, and organizations. FOAF is an RDF-based specification, and as such is poised to gain further in importance as the ideas behind Linked Data gain traction and more widespread implementation. FOAF is quite simple on its face, but as an RDF vocabulary it is easily extended to meet needs for richer and more complex information.  FOAF is now in a stable state, and its developers have recently entered into an agreement with the Dublin Core Metadata Initiative (DCMI), to provide improved persistence and sustainability for the website and the standard, as it moves into the future beyond its modest roots. That is a good match, given that the DCMI organization has provided a stable and persistent home for what may be the most widely used vocabulary on the web: Dublin Core.  

More recent standards efforts deserve attention as well. Several that address the building of descriptions for people and organizations are in working draft at the World Wide Web Consortium (W3C).  Although still in draft status, they offer several alternative methods for description that could be very useful in the current context. Because organizations in these standards are declared as subclasses of foaf:agent, the close association with the FOAF standard is built in. 

Legislative people
The Congress already manages and maintains a great deal of information -- both functional and historical --  about its members, its committees, and other entities.  No doubt there are many agreements that remain to be made within the legislative branch about use of this information in different contexts.  That said, we feel that, if only for resource scarcity reasons, we should avoid adding new data structures for data already being created and maintained.

Relevant information for persons and organizations outside the Congress (such as witnesses at Congressional hearings)  is provided by a great variety of sources, with no obvious strategies for choosing or using. That is the basic conundrum posed by an open web of data that we could, in theory, employ successfully with remarkably small investment of effort. The technical ‘how’ of such a strategy is not that difficult. Organizations like the New York Times have been breaking useful ground in this area. However, policy questions about which sources should be used and which should not are more complicated. Particularly in the government domain, such questions require careful attention to the implications inherent in the various alternatives.

The Library of Congress already uses authority files to manage the identities of some non-legislative actors.  However, inclusion of particular names in those files depends on the notion of “literary warrant”.  Thus, entries, or identifiers, for those who have neither written a book nor been the subject of one can rarely be found in traditional library authority files like the Library of Congress Name Authority File (LCNAF). Hearing witnesses -- probably the largest group of non-legislators for which standard identifiers would be needed -- are more likely to be present in media sources such as newspapers, or perhaps in general reference works. The more prominent and stable of these sources should be evaluated for their suitability for use within legislative data files. Only when no other appropriate source exists should the client consider providing the data files themselves.  Should the client choose to do so, their approach should be based on information provided in the documents they are describing, using a standard set of properties such as those we suggest later, with identifiers managed by the client.

Legislative groups
The legislative process involves many groups, organizations, and affiliations that vary greatly in their stability.  Most models for organizations and groups -- notably FOAF, but also the organization ontologies built by Epimorphics and Fujitsu -- make some distinction between clusters of people based on the stability of the cluster, dividing them into institutionalized “organizations” and ad-hoc “groups” with no bright line separating the two.  There is a spectrum that ranges from the completely ad-hoc to the fully institutionalized, and sometimes it is hard to know where  a particular cluster falls.   In the Congressional world, we might think about standing Congressional committees as being at the “fully institutionalized” end, Congressional caucuses being somewhere in the middle, and the churning group of sponsors associated with a particular bill at the other end.  After some trial and error, we have decided that we don’t really need the distinction.  Associating timespans with membership and with occupancy of particular roles eliminates any need to distinguish groups from organizations.  Eventually, we may need to add a typology of groups that somehow describes their level of institutional stability, but that would speak more to the status of the group with respect to Congress than to the stability of its membership.

Curiously, none of the ontologies mentioned above make any provision for assigning timespans to membership in a group; we have created “Sponsorship” and “Membership” entities in order to accommodate those very necessary ideas.  A further modeling problem is presented by continuous membership (say in a Congressional committee) where the member intermittently holds one or more offices (such as alternating, for some of the time, between committee chairmanship and the position of ranking minority member). 

In the first diagram shown above, the membership is temporally indistinguishable from the role, and so changing roles with respect to a particular group must be modeled as a chain of different roles.  In the second example, membership and role have their own temporal spans, allowing the idea of membership to be represented continuously, with roles having their own duration.  A membership is a thing that has its own duration, and can be related to roles whose timespans are recorded independently.  In terms of the actual model, it looks like this:

In our model, a membership takes a single role, but a single person may hold multiple memberships and thus multiple roles simultaneously with respect to a given group.  A person who had multiple roles within a group (such as the second one shown in the “colored-arrow” diagram above) would have three memberships - one for the committee itself, and the other two for the offices of chair and ranking member.

These temporal requirements are essential to any model used for describing relationships between legislation, legislators, and legislative groups or organizations, either retrospectively or prospectively.  The emerging W3C standard for modeling governmental organizational structures (which includes the modeling descriptions of people and organizations mentioned above),  contemplates extensions to FOAF designed to address this limitation.  Another emerging standard, the Society of American Archivists’ EAC-CPF, also includes provisions for temporal metadata, and seems to take a very broad view of what it models, making it a standard worth watching.

Standards encountered in libraries
One question that always arises in discussing standards like FOAF in a library context is what notice should be taken of the prevalence of the MARC model in most approaches to the description of people and organizations. Traditionally, libraries have used MARC name authority records as the basis for uniquely identifying people and organizations, providing unique text strings for both identification and display. Similar functionality has been attempted with the recent additions to the Library of Congress’s Metadata Authority Description Schema (MADS). MADS was originally developed as an XML expression of the traditional MARC authority data. Now, with the arrival of a public draft standard, focus is shifting toward an RDF expression to provide a path for migration of MADS data into the Semantic Web environment.  

MADS, like its parent the USMARC Authority Format, focuses on preferred names for people and organizations, including variants, rather than on describing the person or organization more fully. As such it provides a useful ‘hook’ into library data referencing the person or organization, but is not really designed to accommodate the broader uses required for this project. 

There is also a question about where this new RDF pathway for MADS might go, given the traditional boundaries of the MARC name authority world. In that tradition, names are added to the distributed file based on ‘literary warrant’.  That is not a particularly useful basis for describing legislators, hearing witnesses, or others who have not written books or been the subject of them. Control of names and name variants will surely be necessary in the new web environment, and the extensive data and experience with the inherent problems of change in names will be essential, but not sufficient, for more widely-scoped projects like this one.

What to model
Legislatures create myriad documents that must be identified and related to one another. For each of those documents, there are people and organizations fulfilling a variety of roles in the events the documents narrate, the creation of the documents themselves, or the endorsement  of their conclusions. Those people and organizations include not only legislators and the various committees and other sub-organizations of the legislature, but also the executive branch which, primarily through the President, exercises the final steps in the legislative process, as well as bearing responsibility for implementation. Finally, there are other parties, often outside government, who are involved in the legislative process as hearing witnesses or authors of committee prints, whose identity and organizational affiliations are essential to full description and interpretation.

When discussing organizations, it is sometimes useful to distinguish between more and less formal groupings.  In the FOAF specification, that is conceptualized in the categories “group” and “organisation”  Generally, FOAF imagines that an “organisation” is a more formalized entity with fairly well defined memberships and descriptions, whereas a “group” is a more informal concept, intended to capture collections of agents where a strict specification of membership may be problematic, or impossible.  In practice, the distinction tends to be a very blurry one, and seems to be a species of summary calculation done on a number of dimensions:

	•	the temporal stability of the group itself, for example “the people waiting for the 3 o’clock bus”, as opposed to “the House Judiciary Committee”;
	•	the temporal stability of the group’s membership, which may be relatively fixed or constantly churning ( “the Supreme Court” versus “the people waiting in the lobby” )
	•	the existence of institutional trappings such as office locations, meeting rooms and websites;
	•	the level of “institutionalization” or “officialness”.  In the case of government institutions in any branch, that may often rest on some legal authority that establishes the group and describes its scope of operations (as with the Federal courts). It may also take the form of a single, very narrow capability (as when an agency is said to have “gift authority”).  Finally, it may also be established through tradition.  For example, the Congressional Black Caucus has existed for over 40 years, and occupies offices in the Longworth House Office Building, but has no formal existence in law.

Because that distinction is so blurry, we have chosen to treat all organizations similarly, using common properties that allow users to determine how official the organization is by ‘following their noses’.  Thus, users of the model are free to draw their own conclusions about the “officialness” of any collection of people, although a statutory or constitutional mandate might well be interpreted as dispositive.

In this paper, we discuss various categories of people and organizations that contribute to legislative documents. Each category carries some important distinctions, and contains challenges in determining the requirements for useful descriptions and relationships. The broad categories are:
	•	legislative branch, 
	•	executive branch agencies and departments, 
	•	the Office of the President, 
	•	the Office of the Vice President
	•	the judicial branch, and 
	•	non-governmental entities. 

Although there is, inevitably, overlap and ambiguity involved in this categorization, each of these categories has a distinct if sometimes distant role with respect to the legislative process, with different levels of detail needed in their descriptions.  We will discuss the commonalities and distinctions between them, with recommendations for approaches to be taken. 

Despite our preference for data maintained authoritatively by the government entities themselves, incomplete and incompletely structured information is problematic, particularly for executive branch agencies. Currently, no definitive list of US governmental organizations exists, although the General Services Administration is said to be compiling one.  There are several incomplete attempts, most notably  the US Government Manual, which many believe to be comprehensive, although it is not.  

There is also a policy question to consider: who should build bridges between information collections that exist in separate administrative units or even in separate branches of government?  For example, in a later section, we consider generally the relationship -- or more properly, the several relationships -- between legislative process and the judiciary.  It is clear that judicial nominations are an important part of the legislature’s activities and need to be modeled as part of legislative process.  But in the case of Supreme Court cases related to legislation, who should build the model that relates them?  Arguably, the relationship between statutes and the court cases that cite and interpret them lies outside the strict purview of a model such as ours. The responsibility for modeling the citation relationship could equally well lie with the Court or with the Congress. 

Section 20 Legislative branch

The Legislature: People
Legislators fall, of course, into one of two main categories: Congressmen and Senators.  Describing these people adequately requires the inclusion of basic categories of information which factor significantly in the legislative process, and are often the basis for searching and sorting.  Those items include the state (Senators) or state and district represented (House members), party affiliation, membership in committees and caucuses, as well as leadership positions in the chamber, plus committees or caucuses in which they maintain membership. Most of these elements change over time, and those changes need to be reflected in descriptions of legislators.

Examples of time-based change abound. For instance, a Congressman may enter the House as a member of one party, but change party affiliation along the way.  Even more common are changes in committee assignments, assumption of leadership positions and chairmanships, and jumps from the House to the Senate.  Therefore, any data model that seeks to address the role of legislators in the legislative process needs to accommodate repeatable, date-sensitive data structures for all this information.  In that respect, our model follows some aspects of the evolving W3C standards, while diverging in some specific areas of modeling roles, memberships and affiliations.  For example, we agree with its use of temporal concepts in modeling memberships (which have duration), but disagree with the manner in which it represents continuous membership as an aggregation of “mini-memberships” that are tied to specific roles.  

We recognize that much of the work of describing legislators has already been completed in the form of the Biographical Directory of the United States Congress.  That resource already includes essential elements of an identifier scheme for all past and present members of Congress, as well as a unique alphanumeric identifier for each individual listed. The identifiers used in the Directory provide simple ways to link to external biographical information maintained by the members themselves as well as resources such as Wikipedia and the New York Times.

The Legislature: Groups
Congressional groupings and organizations need to be identified and described at a number of levels. At the topmost formal level are the House of Representatives and Senate;  below that there are several complex layers. All House and Senate members hold formal memberships in a variety of committees and sub-committees.  Each of these committees, moreover, has a well-defined charge, laying out its subject matter jurisdiction and ancillary responsibilities. These charges and the committee membership may change over time, and various committees will come into, and go out of existence, requiring time-based properties to be included in their descriptions.   

The relationship between legislators and committees are treated reciprocally in the model, allowing users to start with either and examine relationships from the organizational or individual viewpoint. Relationships with caucuses and political parties are described in a similar manner, as are the rarer but important sponsorship relationships between legislators and others, such as the sponsorship of young people to the service academies.

Caucus membership has some special challenges for descriptive practice.  Although there are several caucuses which have a long history and a formalized structure, they are all, by definition, at least somewhat ad hoc.  Similarly, although membership criteria for a caucus may be fairly well defined, it is not necessarily so. It is subject to change, and always voluntary.  Nonetheless, they are an important aspect of the functioning of Congress.
	
The one exception to the assumption of informality is the party caucuses.  Although the general strategy for description of other caucuses would apply well to a party caucus, the party caucuses themselves are more formal than other caucuses, written into the very structure of Congress and essential to its functions.  Also, membership, although voluntary, is far more structured than the rest of the groups that can be categorized as caucuses.

The information that pertains to a committee’s identifiers is available in the Legislative Calendars for each chamber and each committee (to the extent that such calendars are produced by each committee).  Unfortunately this information is only available in a page-description format,  and not in any encoded form designed for digital access. The Legislative Calendars are a prime candidate for such treatment since they consistently include listings of existing committees and their membership, and, unlike some other documents, they are produced by mandate.

Finally, some mention needs to be made of the myriad staffers and aides who do much of the daily work of Congress.  These people fall into one of three basic categories: staffers of a legislator, staffers of a committee, employees of a congressional support organization.  Such individuals could certainly be described using the same strategy, but the determination of whether or not to include them is primarily one of policy. 

Currently the most definitive listing of legislative employees of Congress is the GPO’s Congressional Directory.  However, like the Legislative Calendars, the directory is not currently structured in a manner that would lend it itself to machine readable access, although certainly there are many examples of directories in other parts of the government that have made that leap successfully.

Section 21 Executive branch

The President
For every law, there is a President who must sign, veto, or report, as well as various executive branch agencies charged with regularly submitting documentation and reports to Congress. Similarly, for most laws passed, there will be an executive branch agency that will be given the responsibility for applying the law.  Insofar as these responsibilities emanate from enabling law and date, they can be included in descriptions of agencies. 

The President is, of course, a key player in the legislative process.  The endorsement or veto of a bill is the last step in the process of creating a law.  Similarly, the recent phenomenon of the presidential signing statement also involves a document coming from the President which pertains directly to new legislation.  While the history of a bill may be considered complete with a record that it was signed on a given date, the identity of the President who did the signing is important as well, though the date of signing makes the identity of a statute’s signer easy to infer.  

In addition to these documents, there are any number of communications between Congress and the President that take place while legislation is being created, or are submitted to Congress for some other reason.  The most significant of these would be:

	•	a Presidential request for legislation;
	•	the President’s official State of the Union address;
	•	submission of various reports to Congress as mandated by statute;
	•	the transmission of treaties for ratification by the Senate.

Finally, as chief executive, Presidents do have a degree of quasi-legislative power that is all their own, in the form of Executive Orders, or even recess appointments, which are compiled in the first volume of the CFR as well as in the Statutes at Large. Traditional cataloging practice separates official activities (such as reports mandated by Congress) from those with a more personal stamp, and that separation seems useful in this model as well (though the boundary might be different). Nothing about of these activities, however, requires that the designation and identification of the President as a person or as an office change very much.  

The Office of the Vice President
The Office of the Vice President is not one that would naturally pop out as needing special treatment.  Indeed, most people pay it little heed at all.  In the context of legislation, however, the office occupies a unique place that needs to be accommodated in the model.  That is due to the fact that the Vice President is the presiding officer of the Senate, but is not himself a legislator.  As such, the Vice Presidents can and will be included in the floor debates in Congress, and occasionally cast a deciding vote on controversial legislation. Because of this, the Office of Vice President needs to be modeled in such a way that his activities on the floor of the Senate and his occasional votes can be recorded in a coherent manner.  

Agencies and Departments
Unlike the President or Vice President, who have personal roles in the legislative process, executive branch agencies typically appear in an institutional capacity.  The significant exception to this occurs when individuals representing an executive branch agency testify before Congressional committees.  Aside from testimony (to be discussed below), agency participation in legislation occurs:

	•	Through submission of mandated and non-mandated reports (committee prints) to Congress;
	•	As subjects of legislation, in that they will be created or designated to implement laws being passed;
	•	As creators of regulations that serve to implement legislation that has been passed, and as reporters of that activity to the legislature.

Mandated reports will typically include a reference to the law mandating the submission, facilitating the inclusion of an identifier establishing this relationship.  In addition, the legislative calendars of the chamber or committee designated to receive the document will have entries noting the document’s reception, which will include the date, department, mandating legislation, and subject.  These data items are not currently in any encoded form enabling digital access and separate identifier assignment.  Non-mandated reports come in the form of committee prints submitted to a committee considering new legislation or conducting an investigation.  For digital formats, GPO and/or Library of Congress records for the document are easily linked; print versions are less so but are still accommodated in the model.

The one significant exception to the non-personal nature of executive branch related legislative information is the nomination process.  U.S. Const. Art. II sect. 2 mandates that Ambassadors and public officers of the United States be nominated by the President, with the advice and consent of the Senate.  The “public officers” category, in particular, includes a surprisingly large number of Federal officials.  Although the vast majority (even in today’s uncooperative atmosphere) are handled in a routine manner, they are all are approved by a Senate committee on appointments, and are subject to a vote.

Given the large numbers of Federal officers who are subject to Senate approval, and the relative national importance of most individual appointments, identities of nominees are accommodated in the data model. Most of the individuals who are subject to the nomination process will not be subject to, or involved in the legislative process again.  Given that there is little possibility of a definitive pre-existing repository of information on these individuals, the same strategy as is used for identifying hearing witnesses should apply.

Section 22 Judicial branch

Subject of legislation
The judiciary is involved in the legislative process in two capacities: as a subject and arbiter. The judiciary is a subject of legislation in two ways, both of which are significant for legislation. First, all federal courts, save the Supreme Court are created by statute, as authorized in U.S. Const. Art. I Section 8. One of the larger sections of the U.S. Code is in fact, Title 42, The Judiciary. Next, pursuant to U.S. Const. Art. II Sect. 2, all nominations by the President for new members of the judiciary must be approved with the advice and consent of the Senate. Given the size of the judiciary, there is a considerable amount of legislative time and documentation devoted to the nomination process.

Nominations
Judicial nominations are similar to nominations to executive office, except that the relationship to the office nominated is judicial rather than executive.  The nomination process documents themselves should also supply the necessary additional information that would be useful for the identification of judicial nominees and members of the judiciary, as is the case with executive branch nominees.

Finally, a word needs to be said about the judiciary in its role as adjudicator.  It is, of course, elementary to state that the major role of the federal courts is to adjudicate disputes that arise under U.S. legislation.  Given this, the idea that a model of legislative information must include references to all federal court cases that interpret those laws would seem to be a step, or several steps, further than we should go.  There are, however, several reasonable and natural divisions of court cases that may allow intelligent decisions about what to include and what to disregard.  

On the one hand, there is the issue of court level. The judgments of the U.S. Supreme Court are the final word on the interpretation and constitutionality of legislation, and so are more significant to a definitive understanding of the meaning of our statutes.  Furthermore, the certiorari-granting process used by the Supreme Court to select the cases it will hear explicitly limits consideration to significant cases where a definitive interpretation by the court is necessary.  It is therefore entirely reasonable and useful to limit consideration to Supreme Court decisions, albeit with the understanding that inclusion could be extended to lower courts if, and when resources and a need were present.

Next is the issue of the type of judgment being asked for in a court case.  In the majority of cases that the Supreme Court hears concerning legislation, the question at bar is how that law should be interpreted.  That question may involve issues of constitutionality or it may not.  Even when it does, however, the overall constitutionality of the statute is not in question, only a particular interpretation of it.  Put another way, the majority of cases do not question the legitimacy of a law, only the details of its meaning: what things or behaviors it includes, for example. 

A small number of cases actually do question the constitutionality, and hence the legitimacy, of a piece of legislation.  Of those cases, a small percentage of them decide that a law is, in fact, unconstitutional and invalid.  These cases, though small in number, are of great importance to the legislative process, and essential in any accurate model of American legislation.  Should these  court cases be excluded from the model, it would allow invalid and unenforceable laws to remain not only as discoverable (which they always should be), but to appear as enforceable.  

We have previously stressed (in the context of legislative votes, etc.) that a model of legislation should avoid the interpretive and stick to identification and description.  In this case, the same principle applies.  Identification of a significant judicial decision, determined by explicit reference by the court via citation, is a fact that is important to the understanding of the law in question. Moreover, it is one easily found and extracted by automated means. The interpretation given by the court is something on which the mere act of linking is silent.

Non-governmental personnel
In committee prints and hearings, witnesses and organizations from the private sector play a major role. They are one of the most important sources of information used by Congress when formulating policy and legislation. For researchers, these people, and their organizational affiliations, are important.  

Additional detail about the various connections between people and the organizations involved in the legislative process is certainly available, but resources to include them may not exist. That said, the Linked Data strategy is inherently iterative, and as comfort levels with the aggregation of external data sources increase, such information may well be available without direct expenditure of scarce resources.

More detail on when and how external data sources could be mined for information on non-legislators is contained in the earlier section on use of external data sources.

Section 23 Data types needing discussion
Some data types are more problematic than others, either because there are many competing standards (as is the case with dates and times), because it is necessary to take different approaches to similar data to meet different use cases (as with geographic locations), or because the standards are as yet immature and not clearly on-point (as with provenance).  We discuss each of these in the sections that follow.

Dates and times
We recommend the use of the W3CDTF date format, which is a restricted subset of the ISO 8601 standard.  We also stress that dates can exist in our model independently of events. It is true that all events have one or more dates as properties. But “events”, in our model, represent a carefully selected subset of the things that can occur in and around legislative process and the document workflow associated with it.  Thus, not every date is necessarily an event, as that term is used in the model.

Geographic locations
There are many constraints on systems that represent geodata, as a look at a few prominent use cases shows. 

First, geodata raises two general policy issues discussed earlier:
 
	•	How and where geodata is used will depend on client policy regarding third-party data.
	•	Within the legislative documents themselves, geodata is very much in the category of “obtainable future data”.  

The extraction of place names via natural language processing techniques is both well-understood and accurate.  Of course, there are entities whose names create confusion; for example, it’s not clear to a machine whether the “Sheridan County Water District” is being referenced as a geographic area or as a political/administrative entity.  But for the most part, place names are easily extracted and understood, and could be associated with standard geographic ontologies or specified in a coordinate system.

As the last sentence suggests, geodata comes in more than one flavor.   One approach uses ontologies, making statements like “Ithaca is in Tompkins County” and “Tompkins County is in New York State”.  A second, coordinate-based system says “Ithaca is at this set of geographic coordinates” and “Tompkins County is an area whose boundaries are described by these geographic coordinates”; one can then calculate the fact that Ithaca is within Tompkins County.   A third set of approaches, mentioned in our earlier discussion of legislative events, is oriented toward postal addresses and, more generally, the sort of location information that would be found in address books, directories, and other everyday uses.  There are several of the latter, including FOAF, the vCard ontology, and the Universal Postal Union standard.

No one of those systems would, by itself, provide enough information to comprehensively answer the question, “What legislation affects my district?”.   There are a number of reasons for that.  First, not every place named in a legislative document will appear in an ontology (it happens that Congressional districts do not, at least not yet).  Second, there are “places” that are defined more by concepts than they are by lines on a map.  Ideas about “jurisdiction” often fall into that category.   Congressional districts are further complicated by being time-delimited, with boundaries that change relatively frequently and a need to accommodate history in order to support many common use cases.  One resource that does seem to manage the historical complications of ‘place’ is the Getty’s Thesaurus of Geographic Names (TGN) . However, the TGN on the web is available to “support limited research and cataloging efforts” and any other uses require licensing. That unfortunately makes the TGN inappropriate for use in a Linked Data context, but it could still be useful as a design pattern for a more open resource.

It would seem, then, that this is an area for some careful strategic thinking on the part of the client, as it is not immediately clear that those providing authoritative geodata are (yet) concerned with history, or with the geographic entities that most interest users of legislative data.  Our approach in the model has been to make use of the Place entity as described in the schema.org standard.  It incorporates the use of all the basic systems described above.

Provenance
Provenance is particularly important when data from outside entities is imported into the system.  The summaries furnished by CRS and others for use in THOMAS are a particular example; it is important to know where they came from, and what is done to them as they are aggregated into the system.

Right now, the representation of provenance is an area for active research.  There are a number of competing approaches. Most of them show some degree of subject-matter bias insofar as different disciplines work with different types of data and consider different aspects of their origin and treatment to be more or less important.  We recommend the use of the emerging DCMI approach to provenance.  Though not yet a standard, it is generally applicable, and those responsible seem to be taking the work of others (notably the W3C provenance group ) into account as the standard evolves; we expect that there will eventually be some convergence in approaches, but possibly not within the lifespan of this project.

PART FIVE
Notes on specific corpora
This section contains materials related to specific legislative-information corpora considered in the course of the project.  As we indicated at the beginning of  this report, our approach here has been to first present discussions of cross-cutting design questions and modeling approaches that affect multiple corpora.  Those appear in earlier sections.  Left to this section, then, are the things that were sufficiently corpus-specific to demand that they be distinguished.  It makes for a disjointed collection — first and foremost, what you’ll find here are things that would not fit anywhere else — but there are many important nuggets buried within.  

Not all corpora are addressed here; for example, everything we had to say about bills and resolutions has been said elsewhere, notably in the section that describes the process and versioning models.

Readers who have come directly here in the hope of finding out everything about a particular corpus will want to look first at earlier sections that discuss the events model, people and organizations, and matters related to vocabularies and their management.  To learn about each corpus in the way that we did as we encountered it, you may also wish to read the original white-paper materials in the relevant Appendix. They are reports of design problems as we encountered them during our corpus-by-corpus examination of the data.

Section 24 The Congressional Record
It is possible to think of the Congressional Record (CR) in two ways:  as a newspaper that can be cataloged and modeled just like any other serial publication, or as a document made up of many interesting snippets that should be modeled in their own right.  Many of the use cases we have developed require the latter. We have chosen to do both.

Currently, there is no electronic version of the CR that would support the latter approach.  We believe that one is imminent, or should be. It would be possible to create one fairly easily from the Microcomp (“locator” or “bell”) code currently in use at GPO, offering the possibility of converting the backfile from perhaps as early as 1984.  In any case, there is little doubt in our minds that the publication format of the CR will soon change, and that the client will be faced with a much more complex -- and rewarding --  metadata management task as a result.

The Congressional Record as a serial publication
In traditional cataloging, anything defined as a periodical or ‘serial’ publication (“a publication, usually regularly issued and consecutively numbered”) is cataloged under a collective title with a generalized description that applies to a specified run of issues or parts. Changes in title (and some other changes) require a separate description, and these are chained together with defined relationships.

In most respects, the serial record--in MARC or any other syntax--could be seen as the overview for the title, because it contains general information about the entire publication as a whole, links to various editions and formats, historical information, etc.  For instance, other views of specific parts having separate topics, identifiers and relationships -- whether originally published together or not -- still bear an important relationship to that overview, and that relationship can be expressed in the data. Such a notion of a collection enables browsable access to the entire corpus, regardless of whether the user begins to look from the top down, the bottom up, or via some other publication with a relationship to the CR data.  
As our focus shifts to the pieces and the new forms of information access that such a disaggregated model provides, we will still need to reference the collection level -- in this case, the CR description.  That will ensure that user of the data can make the leap from the past, when the CR was published in various paper editions, to the present, where the CR still exists as an important point of access to updated Congressional information.

Some MARC metadata is captured by the MODS file that GPO issues with each daily CR edition published via FD/SYS.  In addition, it appears that the MODS metadata includes a number of items that have been parsed from the text of the CR itself--whether as a separate digital version of a single information component or as a digital page view.  It also appears to model a granular structure very similar to the one we describe below.

Section 25 CR as a bundle of components
Sooner or later, the CR will be published in a format that makes it possible to disaggregate its components, consider them individually, and recombine them into new views of the underlying information.   We believe that little more would be required than to encode it in reasonably granular XML, and that such a move is imminent.  That leads us to consider what a model for legislative metadata at such a granular level might look like.   The balance of this paper, offered as a form of “future-proofing”, considers that problem.  After addressing some technology and policy issues raised by our collection of CR-related use cases, we go on to consider a model that is designed for each of the “granules” within the CR.  

As a practical matter, any deeper model for CR metadata could only be populated through automated extraction of metadata from XML text (it appears that GPO may already be doing some of this when it creates the MODS files that accompany the CR in FD/SYS).  Without having an XML version available to us as a point of common reference with the reader, it becomes difficult and confusing to draw the line between the design of an XML encoding scheme and the design of the metadata model that describes a document so encoded.  There are no doubt subtle questions about which features are best supported by document encoding versus what should be done using external metadata that we have missed, improperly conflated, or dodged.  But there are also many policy and design questions to be solved before we can reach those subtleties, and we describe them in the sections that follow.

Section 26 Components and structure
The remainder of this section is an inventory of structural features and elements contained within the CR.  Because typographers often take approaches that amount to visual proxies for logical markup, those features and elements are often defined by special typography visible in the printed edition. For our purposes, that visual arrangement  functions as a proxy for a logical markup scheme like XML, and we use it here as a way of detecting structure and features of interest.  

GPO metadata
It seems that GPO has been part of the way down this road.  A survey of the MODS metadata associated with the CR as it is found in FD/SYS shows that it is at least partly based on ideas about CR structure very similar to those we put forth here.  It also contains many of the metadata elements we describe; the model appears to be populated by parsing the text using locator codes as keys to the meaning of different text strings.   The general approach appears to have been to populate the model with data “as found” in the document -- for example, the names of Members making extended remarks are marked up,  but no attempt has been made to link them to the identifiers used in the Congressional Biographical Directory.  It takes the step of extracting many of the metadata elements that interest us, but falls short of providing a full basis for publication as Linked Data.

House and Senate sections
The House and Senate sections are daily reports of the floor action in their respective chambers.  They are essentially a narrative of events.  The bulk of the narrative consists of transcripts that in turn incorporate other blocks of information: the actual text of bills and amendments, records of votes, and so on.  Typically the incorporated blocks are set in a different, smaller typeface.  In addition to transcripts, a section may incorporate mini-reports of specific events (such as the “Prayer”) some of which have procedural significance (“Adjournment”), as well as many other things.

The transcript for each chamber is broken into a series of  sub-granules.  Each represents a change of topic.  Sub-granules are set off with a special horizontal rule, and are titled.  Subtitles within each sub-granule may identify motions, votes, and incorporated bill or amendment text among other things.  Some subtitles are simply set in a different typeface; others are surrounded by square brackets.   As the list just given indicates, many sub-granules contain identifiers for members, votes, amendments, and other things that can be linked to data elsewhere.

Extensions of remarks
An extension typically contains the following elements:
	•	A title or label
	•	The name of the legislator making the remark
	•	The legislator’s state (but not their district)
	•	Location and date, which will always be the same for a given day and chamber

The extensions are quite diverse, but some useful categories emerge:
	•	Remarks on pending legislation.  These usually contain extractable bill numbers, though not necessarily in the title.
	•	“Personal explanation” remarks, which state how the legislator would have voted had he been present for the vote.  These generally refer to votes by roll call vote number, but may also identify bills by number, and amendments by number and sponsoring legislator. Final votes seem to be noted as such.  They are always expressly titled “Personal Explanation”, at least in recent examples, making them easily identified for automatic extraction. 
	•	“Recognition” remarks, which make favorable comments about a (non-legislative) person, organization, or event. Generally these are in the legislator’s home state or district. Again, the targets of these remarks will, in general, be extractable by software using Named Entity Recognition (NER) techniques.
	•	Other, general remarks, which can be on virtually any topic.  See our comments on classification systems and vocabularies, above.

The multimedia record
Multimedia records can be difficult for researchers to work with.  Typically, they are only word-searchable if a closed-captioning track has been created. and even high-speed scanning by the user often proves a slow way of reaching a particular place in the record.  Algorithmic techniques for identifying changes of scene or breaks in the action are getting better, but they are far from perfect.  

It therefore seems likely that most researchers would want to search for items of interest in the full-text transcript provided by the CR, and then shift from the textual record to a multimedia recording in order to view moments or actions of particular interest.  Some means of doing so, supported by temporal metadata that can be synchronized or mapped between textual and multimedia versions, would be desirable.

Section 27 Committee documents
The documentary record of Congressional committee activity takes four main forms:
	•	reports of committee activity in the Congressional Record, which we discuss elsewhere;
	•	transcripts of Committee hearings, with supporting documentation.  This documentation may occur in text and multiple multimedia formats; for example, as audio and video recordings made by Congress itself, as well as by outsiders.  Hearings may be about a particular bill, or about more general issues within the committee’s purview.
	•	committee reports, which may contain the “reporting” (in the legislative sense) of a particular bill, provide general reports of committee activity, or relate to budgetary matters.
	•	committee prints, which are a grab-bag of materials that the committee has ordered to be printed for a stupefying range of reasons.

Section 28 Committee-specific metadata

Identifiers
A legacy system of committee identifiers is in use in FD/SYS MODS files.  It appears that committees are also classified into different types (see example below).  We have also seen examples of committee and subcommittee codes used by the House as part of the document identifier scheme in use on docs.house.gov.  We do not know whether the Senate has such a system in place.  Any or all of these might form a basis for a system of identifiers, or at least provide a census of what is needed.   

The identifier system seems to  extend to conference committees or other ad-hoc groups not chartered by the rules of the House or Senate, but it seems to do so incompletely and is in need of close, comprehensive examination.  While “special” or ad-hoc committees seem to be well identified,  conference committee documents are always identified using House identifiers, and joint committees take the identifier of the related House committee or else omit an identifier altogether.  In the latter case, the joint nature of the committee is indicated in the filename used for the document, so apparently more than one pair of hands is at work.

The problem, then, will be to compare and combine these different systems into one that takes the best qualities of each.

Chartering information and subject matter
Committees derive their power from grants of jurisdiction written into the rules of the House and Senate.  The rules are frequently changed, but in practice the jurisdiction of each standing committee does not vary much over time, with each committee having jurisdiction over multiple topics. Items of legislation, some of which are jurisdictionally ambiguous, are referred to committees by parliamentarians, who have considerable discretion.  That has led one observer to note that there is such a thing as “common law” committee jurisdiction, developed on the basis of how particular subject matter has been referred in the past.  Thus, it is possible that subject-matter jurisdiction of committees is a much more dynamic system than one might suspect from the rules, and in need of the same kind of evolutionary vocabulary management we have called for elsewhere.  It seems clear, then, that simple ownership of a particular bill by a committee only incompletely indicates its subject matter.  The fact of jurisdiction provides a valuable clue as to how the parliamentarians saw the subject-matter of a bill at the time, but the system of jurisdictions is in no way a system of classification for legislative measures.

Other information
Standing committees vary widely in the way that they conduct their business (for example, in the way that they issue subpoenas, take testimony, and hold hearings as part of investigations).  Detailed modeling of these differences lies well outside our scope, but could be accommodated as a natural extension of our model.  As with other metadata that stems from the (very changeable) rules of each chamber, stability is a concern, as is the cost of maintenance of the model as the level of complexity rises. 

A simple classification of committee meeting types is in use in the House (we do not know what the Senate does).  It is used primarily to characterize documents -- that is, to say what sort of meeting gave rise to a particular document.

Conference committees
Conference committees are more ad hoc in nature than standing committees.  They also give the conferees the title of “manager”, though this is really just a special term for any ordinary member of Congress appointed to a conference committee, and does not carry any special duties, status, or responsibility.  In general, conference committees differ significantly from others in that they have a short lifespan, extremely variable composition, and tend to represent both political parties and the committees responsible for the original legislation in different ways from committee to committee, and less consistently than standing committees do.  But none of these differences in composition would call for any difference in modeling strategy.

There are a surprising number of ways for the chambers to resolve differences over a particular bill, all with political ramifications, and conference committees are only one of them.  It is difficult to discover whether there is any consistent, reliable, machine-readable source of information about the exact matters a conference committee is meant to consider -- that is, whether there is ever any encoded document that expresses exactly which points within the legislation are in conflict between the two chambers and need to be considered by the committee, from which one might populate a detailed model.  Because researchers and observers have great interest in knowing what specific issues are meant to be resolved in the committee, there are good reasons for modelers to wish to go beyond simply attaching a list of identifiers for the conflicting bills, resolutions, or amendments under consideration without more granular detail. However, it may not be possible to do so if there is no parseable documentary record of a detailed committee charge.

In general, the best source of specific information about what the committee has done is the explanatory statement accompanying the conference report.  These do not appear to detail what was done in a way that would be amenable to automated extraction, which in any case would be a matter for XML markup rather than a metadata model.  As with the Congressional Record and some other corpora we have examined, it may be that improvements in document encoding need to be made before there is much that a metadata model can do to represent detailed subject matter.

Section 29 Hearings metadata
Hearings are a rich source of information about Congressional interests and activities. From our perspective, they are perhaps most interesting because they involve a hugely expansive range of actors and subject matter.

GPO metadata
GPO provides metadata for most government publications distributed via the Federal Depository Library Program (FDLP), including hearings, and has done so since printed document days, prior to the advent of digital resources. For traditional library records provided in the MARC format, separate records for print and digital forms are provided. The MARC records for the digital version include a link to a PDF from the GPO FDsys system (interestingly, the link in the record itself uses an FDLP domain, which redirects to FDsys).

When searching directly through FDsys, a user choosing a particular document is offered a choice between a text version of the hearing document, the aforementioned PDF, and a button for ‘MORE’. The ‘MORE’ button resolves to summary page featuring links to the text and PDF versions of the document, as well as MODS metadata (labeled ‘Descriptive Metadata’), PREMIS (labeled ‘Authenticity Metadata’), and an ‘all’ option (labeled ‘All Format & Metadata Files’).

Interestingly, the ‘All’ option does not include MARC information, which suggests that it is (correctly) considered specialized information.

The MODS data is used to create the summary page. Some of the information collapsed into the text block for Committee members is parsed separately in the MODS XML (for instance the information on Congressional members is included in the exact phrasing used in the Members block above). There is a separate portion of the record that explicitly lists those Members in attendance, and the text string used is the same as used for all committee members, whether present at the hearing being described or not (ex.: ‘Susan A. Davis of California’) but with different attributes. The separate containers use different roles for the Members: ‘COMMMember’ for all the committee members, and ‘committee member in attendance’ for those actually present for the hearing. The presence of these named roles, and the stark difference between how they’re expressed, suggest that the vocabulary used is internal, and not optimized for Semantic Web applications.

The MODS records contain substantial redundancies -- in addition to the two member containers, there are also two each for witnesses -- but most of the content of the metadata is text strings, albeit strings that could be parsed fairly easily for connections and correspondences to unique IDs maintained elsewhere. Bill numbers are also recorded redundantly, both as text appearing on the publication, and as more structured data. 

There are several interesting disparities between the MARC and MODS records: MODS has information about witnesses but lacks topical information; MARC includes topical information but lacks witnesses. Both describe the Committee as an ‘author’ (110 field in MARC) which probably reflects traditional library practice around something called ‘corporate authorship’, a notion that when considered objectively seems odd at best, and misleading at worst. One difference that seems minor but may have major implications in future is that the MODS record lists the first part of the title only, in all caps with the initial article retained (without an easy way to sort them without the article in lists), and the MARC records title (with the usual MARC second indicator method of ignoring initial articles) plus subtitle and responsibility information included on the title page, in ‘title case’. This explicitness in title expression in MARC has traditionally been designed to be transcribed exactly, both to limit the judgment required of a cataloger, and to make the information more unique, to differentiate the described document from similar documents. This is particularly important with government documents, where prescribed uniformity in title presentation means that the words that differentiate occur further down in the text string than is usual in non-governmental publications.

"Aboutness" vocabulary concerns
Concerns about the evolution of subject-matter vocabularies, discussed elsewhere, are particularly important for committees.  There are two reasons for this.  First, committees range widely in the subject matter they consider.  Second, the “aboutness” of committee hearings can be expressed in at least two ways, each quite different and having some tricky aspects.  

First, hearings are often “about” a bill or resolution. But simply referring to the identifier for a bill may not provide “aboutness” information that is very specific. As we have remarked elsewhere, bills themselves are often “about” a grab-bag of subjects.  Ideally, each hearing resource would carry its own topical information without the requirement that it ‘match’ other resources in a chain of resources linked by a “relatedness” property. That would furnish the optimal chance for a user to find resources, because a “hit” on a particular subject-matter keyword would place the user in a position to “follow her nose” to related resources that would then furnish other subject terms for investigation. Traditional subject cataloging limits the number of subject terms used, but in the current environment, with no requirements to print catalog cards, that limit makes little sense.

Second, hearings are not always about bills or resolutions; they may be about issues that the committee feels to be within its purview, but for which there is no bill or resolution under consideration.  And committees have responsibilities beyond bill-wrangling. In situations where the committee is exercising its oversight responsibilities, the hearings may be explicitly investigative.  Either way, the notion of a hearing ‘inheriting’ its topics from a related resource such as a bill, and therefore not requiring its own analysis and application of topics, is inherently dangerous, based at it is upon trust that the legislature has remained on-topic throughout.

Witnesses
Hearing witnesses are exceptionally interesting to members, staffers, and researchers of all descriptions.  Among our use cases are examples that involve researching the backgrounds and affiliations of hearing witnesses, tracking their appearances across time and across multiple committees and topics, and so on.  Elsewhere, we use them as a flagship example of a group for which linked data from an outside source such as the New York Times, dbPedia, Freebase, or other rich sources of biographical data would be desirable.  That would, of course, involve difficult policy decisions in deciding which databases are considered “linkworthy”, and perhaps some change in administrative procedures within the committees themselves.  On that point, we believe that definitive identifiers for non-Member witnesses would best be obtained or assigned as part of the process of assembling Truth in Testimony forms and written testimony in advance of the hearing.  Indeed, the Truth in Testimony forms and the CVs that accompany them provide rich information about witnesses, and should be provided with identifiers and publicly associated with both witness and hearing.

Witness information currently appears in the MODS files associated with hearing transcripts in FD/SYS, but it could be improved in a number of ways.  The most obvious two would be to separate witness affiliation information from the witnesses’ names, and to (where available) add URIs permitting linkage to outside data collections as described in the previous paragraph.

Documents submitted in testimony
Testimony that witnesses submit in advance of a hearing is invariably written, generally taking the form of word-processing documents or PDFs. These are readily described using familiar properties such as those in DCMI.  However, witnesses frequently introduce multimedia materials such as graphics, PowerPoint presentations, or videos as part of their “live” testimony during the hearing.  Such items become part of the committee’s permanent record of the hearing, and are often offered on the committee’s web site (it is not clear to us whether or how they are transmitted  for archiving).   The House specifies document naming conventions -- essentially, an identifier scheme -- for such items, categorized as “documents that may accompany a witness statement”.  At the moment, this entire collection of valuable documentation seems to be slightly obscure and difficult to locate; it appears ripe for examination.

Committee reports
Reports from standing committees of the House and Senate are, for the most part, reports of recommendations regarding bills and resolutions referred to the committee for consideration.  Reports from conference committees (as described above) often consist of a short explanatory statement accompanying merged legislative text that represents a reconciliation of issues between chambers.  Executive reports come from the Senate Foreign Relations Committee, and  concern themselves with matters involving treaties.  In addition, there are numerous other reports that come from committees -- for example, reports of actions taken by ethics committees with respect to particular individuals, or reports on the activity of the committee itself.  

Reports including recommendations regarding legislation are part of a package of documents that emerges from the committee process.  That package may include accompanying amendments and other documents, making it important to model that “relatedness” information along with the actual document that constitutes the report.  In the case of legislation with budgetary impacts, the accompanying documentation is both required and extensive.

As with other committee documents, GPO maintains extensive MODS metadata for committee reports.  Interestingly, it seems to be metadata only for the report itself, and not for the entire package that normally accompanies the report, which would include at a minimum any reported amendments.  The text of the recommendation may include a mention of (for example) an amendment that the committee wishes to adopt, but it does not contain any identifying reference for a document containing the amendment itself.  Other problems with MODS metadata were noted above in the section on committees in general.

Section 30 Committee prints
Committee prints are, for the most part, third-party information submitted as supporting material for the consideration of legislation.  They may include, but are not limited to
	•	draft reports and bills
	•	statistical information
	•	investigative reports
	•	historical reports
	•	situational studies
	•	confidential staff reports
	•	hearings
	•	legislative analyses
	•	reprints representing the current state of statutes, rules, and so on

Metadata issues
Committee prints are the work of staffers, researchers, and outsiders.  In that respect, the authors of committee prints -- like hearing witnesses --  fall outside the scope of traditional name-authority controls.  Once again, there are policy decisions to be made about how much authorship information is needed, and whether or not linked data from external sources represents a good bargain.

Senate committee prints have an existing system of identifiers.  House committee prints do not.  The Senate system appears to use per-Congress accession numbers, and no doubt a similar system could be put in place for House committee prints as well.  GPO appears to assign an “access ID” to all committee prints that would serve as an opaque identifier, somewhat strangely divided into subcollections for House, Senate, and joint committees with a fourth subcollection reserved for prints from the House Ways and Means Committee.  

We imagine the latter to be a proxy classification used to distinguish materials related to the budget. We find that approach inherently dangerous, given that it embeds assumptions about process and committee charge that may be more or less volatile, and that it might cause a user to assume that there is no need to look elsewhere. Where the current system in use by GPO represents budgetary/non-budgetary as a kind of binary choice, we believe that a more expansive vocabulary of non-exclusive genres (budgetary, investigative, specified-by-statute, for example) may be better.  The construction of such a system, we believe, is best left to analysts more familiar with the full range of materials than we are.

The subject-matter scope and possible number of genres for committee prints are both so large as to be stupefying.  There may, however, be some useful distinguishing criteria that could be built into an extended model at some future point.  For example:
	•	genre properties, along the lines of the list given above;
	•	whether the document is a mandatory or optional adjunct to the legislative process
and so on.  

A way forward
It seems to us as though this particular corpus is trapped in a bit of a Catch-22. Its size and diversity makes it appear so intractable that any attempts at categorization or organization would lose out in any cost-benefit analysis; in the past, it has been far too expensive to assign categories or other metadata using traditional techniques.  As a result, there’s a general belief that there are no use cases of interest that can realistically be fulfilled. That may not be true if newer technologies are brought into play.  It could simply be that this corpus is overdue for analysis using text-mining and categorization techniques. Its apparent (and intimidating) diversity may contain useful patterns worth capturing if less expensive methods can be found.  Even broad categorizations that enable the user to exclude large swaths of material from search results would be useful.

Section 31 Post-passage collections and finding aids
This section lays out some design criteria for metadata that applies to compilations of enacted legislation, and to the tools commonly used to conduct research with them.  Large corpora discussed here include Public Laws, the Statutes at Large, and the United States Code.  This “post-passage” category also takes in signing statements, and -- perhaps a surprise to some -- a variety of finding aids.  Finding aids receive particular attention from us because
	•	they are critically important to researchers and to the public;
	•	they are largely either paper-based,  or electronic transcriptions of paper-based aids. They provide an interesting illustration of a major design question: whether legacy data models should simply be re-cast in new technology, or rethought completely.  Our conclusion is that legacy models (especially those designed for consumption by humans) typically embody reductive design decisions that should be rethought.
	•	they illustrate particular problems with identifiers. In particular, confusion between volume/page-number citations as identifiers for a whole entity, versus their use as references to a particular page milestone, is a problem. So is alignment with labels or containers that identify granular, structural units like sections or provisions, because such units can occur multiple times within a single page.

We begin with a discussion of signing statements, which might be considered the “first stop” after legislation is passed.

Signing statements
Signing statements have been used by many presidents over the years as a way to record their position on new legislation. For most of our history, their use has been rare and noncontroversial. However, during the George W. Bush administration they were used to declare legal positions on the constitutionality of sections of laws being signed.
    
Since they had never previously been controversial, there had been little interest in collecting or indexing these documents in any systematic manner. With the change in their use, this attitude has changed, and there is a need to easily and quickly locate these documents, particularly within the context of the legislation to which they are linked.

Currently, Presidential signing statements are collected as part of the Weekly Compilation of Presidential Documents and Daily Compilation of Presidential Documents. These are collected and issued by the White House press secretary, and published by the Office of the Federal Register. As they are not technically required by law to be published, they do not appear in the Federal Register or in Title 3 of the Code of Federal Regulations.

Although they appear in the daily and weekly compilations, they are not marked or categorized in any particular manner. In FD/SYS, the included MODS files includes a subject topic “bill signings”, marking it as related to that category of event.  “Bill Signings” is also included in the MODS <category1> tag that exists in presidential documents. That designation, however, also will be used for remarks as well as formal signing statements. In addition, it is unclear whether that designation has been used with any consistency.  The MODS files for signing statements include no information designating the document as a signing statement, but only as a “PRESDOCU”. The MODS files do, however, have references to the public law to which they refer. They will also have a publication date that will match with the date on which the president signed the subject law.

In order to make signing statements findable, the existing links to relevant legislation which are already represented in the GPO MODS files should be built into the model, along with the publication date information, and designation of the president who is issuing the statement.  In addition to that, however, the categorization of a signing statement as a signing statement needs to be added in the same fashion in which we have categorized other documents, and implemented with consistency. If the implementation and study of signing statements continues as an important area of user inquiry, they will need to be identifiable.

Finally, as with all such documents, there always a desire to assist the researcher and the public by including evaluation aids.  It is tempting, for example, to indicate whether a statement includes a challenge to the constitutionality or enforceability of a law.  We believe, however, that it would be a mistake to build this into the model.  If interpretive aids of this kind are themselves properly linked to their related legislation, they will be easily found.

We have singled out signing statements because they appeared prominently among use cases we collected and in other conversations about the “post-passage” corpora.  In reality, many other presidential documents relate closely to legislative materials before and after passage.  We will consider them in later sections of this document as we encounter them in finding aids.

Section 32 Enacted legislation
Enacted Federal legislation is published by many groups in many formats, including (among versions published by the legislative branch) Public Laws, the Statutes at Large, and the United States Code. Privately published editions of the US Code are also common (and indeed prevalent), either in electronic or printed form, and it is likely that their use exceeds that of the officially published versions.

Section 33 Overarching issues
First, as to the necessity of tying our model to post-passage materials: research needs have no particular respect for administrative boundaries, and many will wish to trace the history of a law from the introduction of a bill through to its final resting place in the US Code.  As to means, we’ve incorporated a series of properties that describe the codification of particular legislative measures (or provisions); they might be applied at the whole-document or subdocument level; this essentially replicates what is found in Tables I, II and III as we describe them below.  This area of the model might, however, require extension in light of more detailed information about the codification process itself.  We are aware, for example, that current finding aids and the data in them make it far easier to find out what happened to a particular provision in a bill (forward tracing) than it is to find out where a particular provision in the US Code came from (reverse tracing), and that the finding aids do not support all common use cases with certainty.

Updating
Virtually every document we have encountered in our survey of legislative corpora becomes “frozen” at some point, either by being finalized, or by being captured as a series of sequential snapshots.  That is not the case with the US Code, which is continually revised as new legislation is passed.  This creates a series of updating problems that involve not only modeling the current state of the Code, but also: 
	•	tracking new codification decisions
	•	tracking changes in the state of material that has been changed, moved, or repealed,
	•	revising and archiving metadata that has been changed or rendered irrelevant by changes in the underlying material
and so on. 

It seems likely to us that there are both engineering and policy decisions involved here.  Certainly the legislative data model needs to have hooks that allow connection to more detailed models, maintained by others, that track codification decisions. Most use cases that look at statutes and ask, “what happened to that statute?” or “where did this come from?” will need those features.  The policy question simply involves deciding whether and how to connect to data developed by others (for example, if it were desirable to trace legislation from the pre-passage stage currently captured by  THOMAS  all the way into its final home(s) in  the US Code).  As to engineering, it may be simpler in the short run to simply model the finding aids that currently assist users in coping with the print-based stovepipes involved.  That has drawbacks that we describe in some detail later on, but has the advantage of being relatively simple to do at the level of functionality that the print-based aids currently provide.

Whatever approach is taken, maintenance will be an issue; most automated approaches will require the direct acceptance of data originated by others.  At this writing, the Office of the Law Revision Counsel has just solicited proposals for a system to track not only codified legislative text but to record the decisions taken.  Linking to such a system would extend, at low cost, the capabilities of existing systems in very useful ways.

Identifiers
Bills become Public Laws.  Often, they are then chopped into small bits and sprayed over the US Code.   Even the most coherent bill -- and many fall far short of that mark -- is a bundle of provisions that are related by common concern with a public policy issue  (eg. an “antitrust law”) or by their relationship to a particular constituency (eg. a “farm bill”).   The individual provisions might most properly relate to very different portions of the US Code;  a farm bill might contain provisions related to income tax, to land use, environmental regulation, and so on. Many will amend existing provisions in the Code. Mapping and recording of the codification decisions involved is thus a major concern in any model.

The extreme granularity of the changes involved can be seen (eg.) in the Note to 26 USC 1, which contains literally hundreds of entries like the following:

2004—Subsec. (f)(8). Pub. L. 108–311, §§ 101(c), 105, temporarily amended par. (8) generally, substituting provisions relating to elimination of marriage penalty in 15-percent bracket for provisions relating to phaseout of marriage penalty in 15-percent bracket. See Effective and Termination Dates of 2004 Amendments note below.

For our purposes here it is the mapping of the Public Law subsection to a named paragraph in the codified statute that is interesting. It proclaims the need for identifiers at a very fine-grained level.  The XML standard used by the House and Senate for legislation contains mechanisms for markup and identification down to the so-called “subitem” level, which is the lowest level of named container in bills and resolutions (the text in our example is actually at the “subsection” level of the Act).  It seems to us unlikely that mapping is consistently between particular levels of the substructure (that is, it seems unlikely that sublevel X in the Public Law always, in every case, maps to something at sublevel Y of the US Code).  Sanity checking, then, will be difficult.

Identifiers within the US Code provide some interestingly dysfunctional examples.  They can usefully be thought of as having three basic types:  “section” identifiers, which (sensibly) identify sections, “partial section” (psection) identifiers, which apply to named chunks within a section,  and “supersection” identifiers, which identify aggregations of materials above the section level but below the level of the Title:  subtitles, parts, subparts, chapters, and subchapters.   

Official citation takes no notice of supersection identifiers, but many topical references in other materials employ them as references. Chapters should get particular attention, because they are often containers for the codified version of an entire Act. Supersection identifiers are confusing and problematic when considered across the entire Code,  because identical levels are labelled differently from Title to Title.  For example, in most, the “Part” level occurs above “Chapter” in the hierarchy, but in some, that order is reversed.  It should also be noted that practically any supersection -- no matter how many other levels may exist beneath it in the hierarchy -- can have a section as its direct descendant.  There are also “anonymous” supersections that are implied by the existence of table-of-contents subheadings that have no official name; these appear in various places in the Code.

To our way of thinking, this suggests that the use of opaque identifiers for the intermediate supersections is the best approach for unique identification. Path-based accessors that use level-labels such as “subtitle” and “section” are obviously useful, too,  however confusing they might seem when accessors from different titles with different labelling hierarchies are compared side by side.

As to section identifiers, the main problem is that years of accumulated insertions have resulted in an identifier system that appears far from rational.  For example, “1749bbb-10c” is a valid section number in Title 12.  It may nevertheless make sense to use citation as the basis for identifier construction rather than making the identifiers fully opaque.  As to partial-section labeling, it is pretty consistent throughout the Code, and can be thought of as an extension to the system of section identifiers.

Public Laws, Statutes at Large, and the US Code
Traditional library approaches to these complex sets of materials have been very simple: they’ve been cataloged as ‘serials’ (open ended, continuing publications), with very little detail. That allows libraries to represent the materials in their catalogs, and to provide a bibliographic record that acts as a hook for check-in data, and is used to track receipt and inventory of individual physical volumes. In the law library context, where few users access these basic resources through a catalog, this approach has been sufficient, efficient and low-maintenance. 

However, as this information ‘goes digital’, that strategy breaks down in some predictable ways, many of which we’ve documented elsewhere in this document; the biggest is that much of the time we would like more detailed information about smaller granules than the “serial” approach contemplates. As we make a fuller transition to digital access of this information, these limited approaches no longer provide even minimal access to this critical material.

Section 34 Finding aids
There are a good many finding aids that can be used to trace Federal legislation through the codification process, and to follow authority relationships between legislative- and executive-branch materials, such as presidential documents and the Code of Federal Regulations.  All were originally designed for distribution in tabular form, at first on paper, and more recently on Web pages.  In the new environment we imagine, the approach they represent is problematic. It may be nevertheless be worthwhile to model the finding aids themselves for use in the short term, as better implementations require significant analysis and administrative coordination.

Deficiencies of print
A look at the Parallel Table of Authorities [PTOA] shows where such problems are likely to be found. Like all other tabular finding aids that originate in print, it was designed for consumption by human experts capable of fairly sophisticated interpretation of its contents.  It embeds a series of reductive design decisions that trade conciseness against the need for some “unpacking” by the reader.  Conciseness is a virtue in print, but it is at best unnecessary and at worst confusing when the data is to be consumed and processed by machines.  A couple of examples will illustrate:
	•	Some PTOA entries map ranges of US Code sections against ranges of CFR Parts, in what appears to be a many-to-many relationship.  It is unlikely that every pair that we could generate by simple combinatorial expansion represents a valid authority relationship. Indeed, as we shall see, the various finding aids differ considerably in the meaning they assign to a “range” of sections and  in the treatment that they intend for them.
	•	The table simply states that there is a relationship between each of the two cells in every row of the table, without saying what it is.  The name of the table would lead the reader to believe that the relationship is one of authorization, but in fact other language around the table suggests that there are as many as four different types of relationship possible.  These are not explicitly identified.

To model the finding aid, in this case, would be to perpetuate a less-than-accurate representation of the data.  As a practical matter of software project planning and management, it might be worth doing so anyway, in order to more quickly provide users with a semi-automated, electronic version of something familiar and useful. But that is not the best we could do.  Most of the finding aids associated with Federal statutes have similar re-modeling issues, and should be re-conceived for the Semantic Web environment in order to achieve better results.

Identifier granularity and alignment
Most of the finding aids make use of granular references; in the case of Public Laws, these are often at the section level or below, and in the case of the US Code they are often to named subsections.  The granularity of references may or may not be reflected in the granularity of the structural XML markup of any particular edition of those resources.

The Statutes at Large use a page-based citation system that creates two interesting modeling issues. First, on its own, a page-based citation is not a unique identifier for a statute in Stat. L., because more than one may appear on one page.   Second, it was not ever thus.  Stat. L. has used three different numbering schemes at various times, each containing ambiguities.  These would be extraordinarily difficult to resolve under any circumstances, and particularly so given the demands of codification we describe later in the section on the Table III finding aid. Taking these two things together, it seems that there is no way to accurately create a pinpoint link between a provision of an Act in its Public Law format and a specific location in the Statutes at Large; the finest resolution possible is at page granularity.  

It would thus seem that the most sensible approach would be to use a somewhat “loose and floppy” relationship like “isPublishedAt” to describe the relationship involved, since the information available from the Table does not really support pinpoint accuracy.   That is unfortunate, in that there are important use cases that need such links.  For example, statutes are frequently described in judicial opinions using citations that refer only to the Statutes at Large, sometimes because the case in question predates the US Code and no other reference can exist, and sometimes because the writer has omitted other citation.  It is effectively impossible to construct a pinpoint link if the cite contains a subsection reference; one has to cite to the nearest page, relying on the reader to find the relevant statute on the page somewhere.  It would be equally difficult to trace through a Stat.L. citation to the relevant provision of the US Code in situations where the USC citation has been omitted.

In short, identifiers in this part of the legislative jungle have two problems: first, they sometimes do not exist at a sufficiently granular resolution in the relevant XML versions, and second, granular identifiers do not resolve or map well to materials whose citation has traditionally been based on print volume and page numbers.

Some of the finding aids we describe below provide mappings between Presidential documents and the codified statutes in the US Code.  Identifiers for Presidential documents are assigned by the Office of the Federal Register, and are typically accession numbers.  It is worth noting that OFR provides a number of finding aids and subject-matter descriptions of Presidential documents, though these are beyond our scope here.  

As to GPO, it appears at first blush that the MODS metadata for the US Code as found in FD/SYS does not reflect associations with Executive Orders, although they are vaguely modeled in the MODS files associated with the Executive Orders themselves.  There would be some virtue in being able to find information in both directions.  That is especially true in situations where the state of the law cannot be fully understood without referring to both the Code and related Executive Orders simultaneously.  For example, 4 USC 1, in its most current version, claims that there are 48 stars on the flag of the United States; it is only possible to find out where the other two came from by referencing the Executive Orders that accompanied statehood for Alaska and Hawai’i.

The Table of Popular Names (TOPN)
For the general public, the TOPN is probably the single most useful finding aid for Federal legislation. That is because it bridges the gap between popular accounts of legislation -- for example, in the news media -- and the codified collections of laws that are in effect.  Where, exactly, do we find the Lily Ledbetter Fair Pay Act in the modern statute book?  The answer to that question isn’t obvious.

Broadly -- very broadly -- there are two ways in which an Act may be codified.  First, it could be moved into the Code wholesale, typically as a new Chapter containing numbered sections that reflect the section divisions in the Act.  Second, it could be disassembled into a bag of provisions and scattered all over the Code, with each section placed in a region of the Code dictated by its subject matter.   In such cases, the notes to the Code section that describes the “Short Title” of the Act generally contain a roadmap of what has been done with the rest of it.   That also happens when the Act contains language that consists entirely of instructions for amending existing statutes already codified.

For example, the TOPN entry for the Lily Ledbetter Fair Pay Act looks like this:

Lilly Ledbetter Fair Pay Act of 2009
Pub. L. 111-2, Jan. 29, 2009, 123 Stat. 5
Short title, see 42 U.S.C. 2000a note

It maps the identifier for the Public Law version of the Act to the Statutes at Large, with a page reference to the Stat. page on which the Act begins.  It also maps to the “Short Title” section of the USC, whose note contains information about what has been done with the Act.

Short Title of 2009 Amendment

Pub. L. 111–2, § 1,Jan. 29, 2009, 123 Stat. 5, provided that: “This Act [amending sections2000e–5 and 2000e–16 of this title and sections 626, 633a, and 794a of Title 29, Labor, and enacting provisions set out as notes under section 2000e–5 of this title] may be cited as the ‘Lilly Ledbetter Fair Pay Act of 2009’.”

This entry makes an important point about codified legislation.  While it is natural to believe that codification consists of taking something that contains entirely new legislative language, breaking it into pieces, and plugging the pieces into the Code (or substituting them for old ones), that is not exactly what happens much of the time.  Any Act could be, and often is, a laundry list of directives to amend existing codified statutes in some way or other.   In such cases, the text of the Act is not incorporated into the Code itself, but into the Notes, in a manner similar to the example just given.  That is a subtle difference, but an important one, as we shall see in the discussion of Table III below.  It introduces an extra layer of mapping into the process, in a way that is partially obscured by the fact that inclusion is in the Notes rather than in the text of the Code.  One result of this is that, in general, it is easier to look at a current provision and find out where it came from than it is to look at an historical provision and find out what happened to it.

From a data modeler’s perspective, the TOPN is useful but not necessary; the necessary finding aid can be constructed by aggregating data from other tables, or by simply referring to the short titles and popular names given in the text of the Act itself. The relationships modeled by TOPN aggregate information:
	•	from the Acts or bills themselves (House and Senate identifiers for bills, and the name of the Act as it’s found in either the bill or (better) in the Public Law version);
	•	from Table III, which describes where the Public Law is codified; and
	•	from Table I, which models an extra “change of address” that is applied in cases where codified legislation has been reorganized for passage into positive law.

US Code Table I
Table I describes the treatment of individual sections in Titles that have been revised for enactment as positive law.  The Table is a straightforward mapping of “old” section numbers in a Title to “new” section numbers that apply after the Title was made into positive law.  As such, Table I entries also have a temporal dimension -- the mappings need only be applied when tracing a citation to the Code as it existed before the date of positive law enactment to a location in the Code after that date.

A relational-database expert obsessed with normalization would say that Table I is, then, really two tables -- one that maps old sections to new sections within a Title, and a second, implied table that says whether or not each of the 51 Titles has been enacted into positive law, and if so, when.  The researcher wanting to trace a particular reference would follow this heuristic:
	•	Does my reference fall within a positive-law Title?
	•	If so, does my reference precede the date of enactment into positive law?
	•	If so, what is the number of the “new” section?
Thus, the model will need to reflect properties of the Title itself (“enactedAsPositiveLaw”) and of the mapping relationship of old to new (“hasPositiveLawSection”).

US Code Table II
The United States Code was preceded by an earlier attempt at regularized organization, the Revised Statutes of 1878 .  Citations to the Revised Statutes are to sequentially-numbered Sections, with “Rev.Stat.” as the series indicator.  Table II provides a map between Rev. Stat. cites and sections of the US Code, along with a number of status indicators; the two most important (and common) of these indicate that a statute has been repealed, or that Table I needs to be applied because the classification shown was done prior to positive-law enactment of the Title.

Unlike other finding aids we describe, where the meaning of mappings between ranges and lists of things can be both combinatorial and ambiguous, Table II appears straightforward. A list or range of items in the Rev. Stat. columns can be mapped one-to-one to the corresponding list or range in the USC column.  The first element in the list or range in Rev. Stat. maps to the first element in the list in USC, the second to the second, and so on.  Simple reciprocal relationships should obtain.

That is particularly important in light of the relationship between Table II and Table III.  In Table III, for all statutes passed before 1874, Table III references all refer to the Revised Statutes, and not to the US Code.  So, for those statutes, in order to determine where they may still exist as part of the US Code, reference needs to be made first to Table III, to obtain the R.S. section where it was first encoded, and then to Table II, to determine where that R.S. section was re-encoded in the US Code.  Without the straightforward, one-to-one relationship between the R.S. and US Code expressed in Table II, the connection between pre-1874 statutes and current US Code sections would not be possible.

US Code Table III
Table III, which maps individual provisions within Public Laws to pages in the Statutes at Large and to sections of the US Code, exhibits a number of interesting problems.  Here is how one such mapping appears in the LRC’s online tool:

In this case, we’re mapping the individual provisions of PL 110-108 (readable at http://www.gpo.gov/fdsys/pkg/PLAW-110publ108/html/PLAW-110publ108.htm )  to a range of pages in the Statutes at Large and to sections in the US Code (and their notes). The GPO version helpfully contains markers for the Stat. L. page breaks.  Some noteworthy observations:

	•	The Public Law needs section-level identifiers. Notes sections within the USC need their own identifiers, as do pages within the Statutes at Large.
	•	Since the Stat. L. citation for the Act always goes to the first page of the Act as it appears in Stat.L., there is ambiguity between
	◦	121 Stat. 1024, the citation/identifier indicating the whole Act for purposes of external citation, and
	◦	121 Stat. 1024, the single-page reference that describes where Section 1 of the Act can be found (and for that matter, supposedly, some of Sections 2-6 as well)
	•	For some time periods, chapter numbers would disambiguate individual laws where more than one statute appears on a single page, although as we have seen, chapter numbers have uniqueness problems of their own. Chapter numbers play no role in this example, as they were not used after 1957.
	•	The Act is classified to the notes in the relevant USC sections. 
	◦	In the case of section 1 of the Act, the notes simply state the name of the Act.
	◦	In the case of section 151, the entire text of the legislation appears in the notes for the Act.  It would appear that it is done this way because the legislation’s provisions amount to a series of instructions for amending existing statutes, and thus can’t be codified per se.  Rather, they are a description of what should be done to change things that have been codified already.
	•	GPO’s MODS file is evidently created by machine extraction of USC citations, because it incorrectly identifies the Act as modifying 26 USC 4251. It’s possible, though,  that the presence of a USC section in the MODS file might simply mean “found at the scene of the crime by our parser” rather than “changed by the Act”.  The relationship is unclear, and may be impossible to express clearly in XML.
	•	GPO’s MODS file for the Act treats the mapping implied by the second line of the example pretty loosely, describing small collections of US Code and Stat.L. pages associated with the Act, but not describing any particular relationship between the items in each collection or between collections.  This is, again, a place where XML falls short of what is possible in an RDF-based, machine-readable model.

The second line of the table entry is the most interesting.  At first glance, it appears to describe a many-to-many relationship between a range of sections in the Act and a range of pages in the Statutes at Large.  But it seems improbable that such a relationship would actually describe anything useful, and a quick side-by-side look at the Act and the Statute shows that that interpretation is incorrect.  The actual arrangement of page breaks in Stat. L. would indicate that the mapping should be otherwise:
	•	Section 2 appears in its entirety on 121 Stat 1024. 
	•	Section 3 spans the break between 1024 and 1025. 
	•	Section 4 spans 1025 and 1026
	•	Sections 5 and 6 appear in their entirety on 1026

Why is this?  The simplest explanation is that the entries in the table -- numbers separated by a dash -- do not represent lists of individual sections. Instead, they represent clusters of sections that are related to each other as clusters.  They seem to be saying, “somewhere in this clump of legislative language, you’ll find things that relate to things in this other clump of legislative language, and the clumps span multiple sections or provisions, possibly ordered differently in each document”.  

Looking at the text itself -- which is a series of detailed, interrelated amending instructions -- shows that indeed it would be a horrible (and likely very confusing) task to pick the provisions apart into a fully granular mapping, leaving “cluster-to-cluster” mapping as the only viable strategy for describing the relationship between the two texts.

A detailed model of Table III would then require:
	•	clarifying the distinction between a page reference to the first page of an Act as it appears in Stat.L. and the citation of the statute as a whole.
	•	describing each section or subsection (granule) within the Public Law as one that is either
	◦	new statutory language, or 
	◦	a set of instructions for amending existing language
	•	describing each target in the USC as either 
	◦	an actual statute, or
	◦	notes to the statute. It is worth remarking that, in any of the finding aids, the fact that something has been classified to the notes provides a clue as to what that thing is and what the nature of the classified relationship might be. This may indicate a need for subproperties that would be accommodated in some future extension.
	•	distinguishing between relationships that involve re-publication (as between Public Laws and Statutes at Large) from those that involve restatement or codification (as between either of those and the US Code)
	•	using different properties to describe provision-to-provision and cluster-to-cluster relationships
 
Taken together, these requirements would form an approach that would more accurately model the relationships the original Table was meant to describe.  In some sense this is an interpretive act -- any Table that records codification decisions does, after all, record a set of interpretations, and so will its model.  But in this case the interpretation is an official one, entrusted to the Law Revision Counsel and in any case practically unavoidable.

US Code Table IV
Table IV “lists the Executive Orders that implement general and permanent law as contained in the United States Code”.  Executive Orders are instructions from the President mandating an action, reorganization, or policy change in some part of the executive branch.  They are promulgated pursuant to statutory authority and as lawful orders of the chief executive, have force of law.  They are published in the Federal Register and appear in the annual Compilation of Presidential Documents.  They are sequentially numbered, but are also identified by date of signing, title, and the authoring president.  All four of these identifying attributes are specified in the GPO MODS files which accompany these documents in FD/SYS.  In addition, there exists a reference to the volume and issue number of the Weekly Compilation in which the order appears.  Finally, the MODS files typically include a reference to the enabling law as well.

The Table shows that:
	•	Executive Orders have identifiers, apparently accession numbers that run from the beginning of time.
	•	Nearly all refer to the “notes” attached to sections of the USC, since (as the description says) Executive Orders are typically implementation instructions independent of the language of the statute itself.
References to the notes have special features worth remarking.  Often, the mapping is given to the note preceding (“nt. prec.”) a particular section.  That distinctive language is rooted in the way that the LRC conceives of the Code’s structure.  In the minds of the LRC, the Code consists of Titles that are divided into sections.  Intermediate levels of aggregation -- subtitles, parts, subparts, chapters, and subchapters -- are convenient fictions used to organize the material in a manner similar to the tabs found in a card catalog.  Thus, the “note preceding” a section is most often a note that is attached to the chapter of which the section is a part (chapters are typically, but not always, the level that aggregates sections, and often correspond to an Act as a whole).  As modelers, we’re presented with a choice between fictions: either we join LRC in pretending that the intermediate levels of aggregation don’t exist, or we make use of them.  The latter presents other problems with representing parent-child relationships in the structure, but fortunately that is a concern for XML markup designers and not so much for us.

It would seem that the best approach might be to model both sets of relationships: a hierarchical structure based on aggregations, and a sequential structure suggested by the “insertion model” just described.  In terms of the model, this is just a matter of making sure that identifiers are in place that will facilitate both approaches.  The main issues raised by this approach have to do with XML markup and encoding; as with other corpora we have encountered (eg. the Congressional Record) user needs demand, and the model can accommodate, far more than the current publicly available XML encoding of the document will support.

Thus, we would end up with:
	•	a set of unique identifiers for sections, based on title and section numbers and thus reflecting current citation practice;
	•	a set of sub-section identifiers that extend section identifiers in a way that is based on nested subsection labeling. 
	•	a set of super-section identifiers that is based on human readable hierarchy, represented as paths, eg. “/uscode/title42/subtitle1/part3/subpart5/chapter7/subchapterA”
	•	a set of completely opaque identifiers for both section and supersection levels.  There is less need for this at the subsection level, but any such system could easily be extended;
	•	parent-child relationships between 
	◦	subsections and sections
	◦	sections and supersections
	◦	supersections and containing supersections
	•	next-previous relationships between sections.  These should take no account of supersection boundaries.
As we’ve said in other contexts, it is worthwhile to remember that nothing limits us to a single identifier for any object.

US Code Table V
Table V maps Presidential proclamations to the US Code.  Proclamations differ from Executive Orders in that they do not “legislate” as such.  Rather, they are issued to commemorate a significant event, or other similar occasion.  Like Executive Orders, they are published in the Federal Register, and appear in the Compilation of Presidential Documents. Like Executive Orders, they are sequentially numbered (without reference to year, president, etc.), and are also identified by date, title, issuing president, and the volume and issue number of the Weekly Compilation.  All these identifiers are typically present in the GPO MODS files in FD/SYS.

Before 1950 or so, the vast majority of proclamations establish national monuments. More recently, other topics as diverse as the maintenance of the Strategic Petroleum Reserve, tariff schedules, and the celebration of Armed Forces Day show up frequently.  As with Executive Orders and Table IV, the proclamations have accession numbers, and the vast majority of references are to notes attached to the Code and not the Code itself.

US Code Table VI
Table VI maps reorganization plans to the US Code.  Reorganization plans are essentially executive orders that describe major alterations to executive-branch agencies and organization, though they do not carry executive-order identifiers.  For example, Reorganization Plan 3 of 1970 establishes the Environmental Protection Agency and expands the structure of the National Oceanographic and Atmospheric Administration.  Generally they carry citations to the Statutes at Large and to the Federal Register (the FR cite does not appear in Table VI).   While no concise identifier exists for them in and of themselves, it appears that they could be identified by a year-number combination (eg. “RP-1970-3”).  These associations can readily be modeled by associating an identifier for the plan itself with the page references, through one or more “isPublishedAt” relationships.

The Parallel Table of Authorities
The Parallel Table of Authorities and Rules describes relationships between statutes in the US Code and the CFR Parts that they authorize. For the most part, the PTOA maps ranges of sections in the US Code to lists of Parts in the Code of Federal Regulations. It has limitations, described by GPO as follows:

Entries in the table are taken directly from the rulemaking authority citation provided by Federal agencies in their regulations. Federal agencies are responsible for keeping these citations current and accurate. Because Federal agencies sometimes present these citations in an inconsistent manner, the table cannot be considered all-inclusive. The portion of the table listing the United States Code citations is the most comprehensive, as these citations are entered into the table whenever they are given in the authority citations provided by the agencies. United States Statutes at Large and public law citations are carried in the table only when there are no corresponding United States Code citations given.

The suggestions made here, then, are not so much recommendations for the client as they are observations about a critically important finding aid, strongly related to legislative material, that is in need of some help.  Thinking about the PTOA and the various ways in which modeling techniques such as the ones we recommend might improve it provides an interesting overview of the problems of legislative finding aids in general.

Richards and Bruce have written extensively about its organization and improvement.  They note four major areas to address:
	•	Ambiguity in the description of the relationships themselves.  The Table supposedly models four different types of relationship: express authorization, implied authorization, interpretation, and application.  These are not distinguished in the PTOA entries.
	•	Ambiguity in relationship targeting.  Entries on both sides of the table are typically given as ranges or lists, implying many-to-many relationships that can be combinatorially expanded.  It is not clear whether, in fact, all the sections of the US Code that could be enumerated from a range on the left side of the table would relate to particular Parts of the CFR enumerated from the lists on the right side of the table.  It seems unlikely.
	•	Granularity problems related to citation of the CFR materials by Part.  In reality, the authorizing relationship would typically run from a statute to a particular section of the CFR, but the targeting in the PTOA is to the Part containing that section. It is likely that this is not a problem with granularity so much as it is an informed design decision driven by problems with the volatility of section-level identifiers as compared to printed finding aids.  Sections of the CFR come and go with some frequency, often moving around within an individual Part. Parts change infrequently.  In print, where updating is difficult and withdrawal of stale material even more so, identifier stability is a much bigger concern.  It is possible that a digital resource could track things much more closely.
	•	Directionality and reciprocity.  It is not clear which of the four possible relationships between entries are reciprocal and which are strictly directional, nor is the Table necessarily intended to be used bidirectionally.

Unfortunately, improvement is unlikely, as it would require the collection of improved information from each of the hundreds of agencies involved.  We would recommend that, because of its critical importance to those wanting to trace relationships between legislative- and executive-branch activity, the client use a simplified model to provide at least some useful information.  The LII currently models the PTOA as a single relationship between individual pairs of identifiers, asserting that each pair in a combinatorial expansion of entries on each side of the table has some such relationship.  That is undoubtedly imprecise, but it is as good as anything currently available and far better than nothing.

PART SIX
References

SECTION ELEVEN
Legislative process

	•	Amer, Mildred L. “The Congressional Record: Content, History, and Uses”. CRS Report 93-60, online at http://www.llsdc.org/sourcebook/docs/CRS-93-60.pdf
	•	Beth, Richard S. “The Discharge Rule in the House: Principal Features and Uses”. CRS Report 97-552, at http://democrats.rules.house.gov/archives/97-552.pdf .
	•	Davis, Christopher M. “Amendments in the House: Types and Forms”. CRS Report 98-613,  at http://wikileaks.org/wiki/CRS:_Amendments_in_the_House:_Types_and_Forms,_April_16,_2008
	•	Davis, Christopher M. “How Legislation is Brought to the House Floor: a Snapshot of Recent Parliamentary Practice”. CRS Report R40829, online at http://assets.opencrs.com/rpts/R40829_20110309.pdf 
	•	Heitshusen, Valerie. “The Legislative Process on the Senate Floor’. CRS Report 96-548, online at http://www.senate.gov/CRSReports/crs-publish.cfm?pid=%26*2D4Q%5CK3%0A 
	•	Lindblom, Derek. “The Budget Reconciliation Process”. Harvard Law School Federal Budget Policy Seminar Briefing Paper #35, online at http://www.law.harvard.edu/faculty/hjackson/ReconciliationByrd_35.pdf 
	•	Office of Congresswoman Louise Slaughter. “A Step-by-Step Guide to Committee Markups”, at http://democrats.rules.house.gov/archives/class3.htm 
	•	Oleszek, Walter J. “The House Amendment Tree”. CRS Report 98-777, online at http://democrats.rules.house.gov/archives/98-777.pdf 
	•	Oleszek, Walter J. “Senate Rules for Committee Markups”. CRS Report 98-711, online at http://lugar.senate.gov/services/pdf_crs/senate/committees/Senate_Rules_for_Committee_Markups.pdf 
	•	Palmer, Betsy. “Sponsorship and Cosponsorship of House Bills”. CRS Report RS22477, at http://democrats.rules.house.gov/CRS_Rpt/RS22477.pdf
	•	Palmer, Betsy. “The Senate’s Calendar of Business”. CRS Report 98-429, online at http://lugar.senate.gov/services/pdf_crs/congressional/The_Senate%27s_Calendar_of_Business.pdf 
	•	Rundquist, Paul. “Flow of Business: Typical Day on the Senate Floor”. CRS Report 98-865, at http://lugar.senate.gov/services/pdf_crs/senate/procedure/Flow_of_Business_Typical_Day_on_the_Senate_Floor.pdf 
	•	Rybicki, Elizabeth. “Conference Committee and Related Procedures: An Introduction”. CRS Report 96-708, online at http://assets.opencrs.com/rpts/96-708_20101202.pdf .
	•	Rybicki, Elizabeth. “Resolving Legislative Differences in Congress: Conference Committees and Amendments Between the Houses”.  CRS Report  98-696, at http://assets.opencrs.com/rpts/98-696_20081126.pdf 
	•	Saturno, James V. “Floor Consideration of Conference Reports in the House”, CRS Report 98-736, online at http://lugar.senate.gov/services/pdf_crs/house/Floor_Consideration_of_Conference_Reports_in_the_House.pdf 
	•	Schneider, Judy, “Committee Jurisdiction and Referral in the Senate”, CRS Report 98-242, at http://assets.opencrs.com/rpts/98-242_20080415.pdf  .
	•	Schneider, Judy, “House Committee Jurisdiction and Referral: Rules and Practice”, CRS Report 98-175, at http://assets.opencrs.com/rpts/98-175_20080415.pdf  .
	•	Schneider, Judy, “The Committee Markup Process in the House of Representatives”, CRS Report RL30244, online at http://assets.opencrs.com/rpts/RL30244_20061208.pdf 
	•	Sullivan, John V. “How Our Laws Are Made”. Online at:  http://thomas.loc.gov/home/lawsmade.toc.html
	•	Wirth, Mike. Infographic: How a Bill Becomes a Law. http://www.mikewirthart.com/wp-content/uploads/2010/05/howlawsmadeWIRTH2.jpg 

SECTION TWELVE
Legislative data projects
Brazil:  
	•	de Oliveira Lima, João Alberto. “An Adaptation of the FRBR Model to Legal Norms”, http://www.e-p-a-p.com/dlib/9788883980466/art4.pdf 
	•	de Oliveira Lima, João Alberto. “LexML Brazil Project” , http://blog.law.cornell.edu/voxpop/2010/10/15/lexml-brazil-project/

Italy: 
	•	Ciampi, Costantino. “Norme in Rete [Laws online]”, http://www.ittig.cnr.it/Ricerca/UnitaEng.php?Id=40

Netherlands:
	•	Hoekstra, Rinke. “The MetaLex Document Server”,  http://doc.metalex.eu/
	•	Hoekstra, Rinke. “The MetaLex Document Server”, narrative article at http://blog.law.cornell.edu/voxpop/2011/10/25/the-metalex-document-server/.

United Kingdom:
	•	Legislation.gov.uk 
	•	High-level API documentation http://data.gov.uk/blog/legislationgovuk-api
	•	Description of identifier scheme at http://www.legislation.gov.uk/developer/uris 
	•	Description and examples of FRBR use at http://www.legislation.gov.uk/developer/formats/rdf
	•	http://www.govloop.com/profiles/blogs/the-new-legislationgovuk
	•	Sheridan, John. “Legislation.gov.uk” , at http://blog.law.cornell.edu/voxpop/2010/08/15/legislationgovuk/ 

United States
	•	Advisory Committee on the Records of Congress. House Document 109-156. Online at http://www.gpo.gov/fdsys/pkg/CDOC-109hdoc156/pdf/CDOC-109hdoc156.pdf.

SECTION THIRTEEN
Legislative data standards
	•	Palmirani, Monica, Fabio Vitali, et al. “AkomaNtoso: XML for parliamentary, legislative, and judicial documents”.  Online at http://www.akomantoso.org 
	•	Spinosa, Pierluigi, Enrico Francesconi, and Caterina Lupo. “A Uniform Resource Name Namespace for Sources of Law (URN: Lex)’. Online at http://datatracker.ietf.org/doc/draft-spinosa-urn-lex/ 
	•	United States House of Representatives, Office of the Clerk, Legislative Data Systems. “Document Naming Conventions”. Online at http://cha.house.gov/sites/republicans.cha.house.gov/files/documents/committee_docs/CommitteeRepository-NamingConventions-v1-2-1.pdf 
	•	United States House of Representatives XML Working Group. “Legislative Documents in XML at the United States House of Representatives”.  Online at: http://xml.house.gov/ 
	•	Van Engers, Tom, et al. “CEN/Metalex: Open XML Interchange Format for Legislation and Legal Materials”, online at http://www.metalex.eu/ 

SECTION FOURTEEN
Modeling practice
	•	Berners-Lee, Tim. Cool URIs for the Semantic Web. Online at http://www.w3.org/TR/cooluris/#semweb
	•	Bruce, T.R. and Shetland, D.A. (2007). Resilience in Identifier Design.  Position paper for the JURIX 2007 workshop on legislative XML.  Online at http://liicr.nl/pzPQWx 
	•	Bruce, Thomas R., and Diane I. Hillmann, “The Continuum of Metadata Quality: Defining, Expressing, Exploiting”, in Metadata in Practice, D. Hillmann & E Westbrooks, eds., ALA Editions 2004. Available at http://liicr.nl/ssh9km . 
	•	Campbell, D.. Identifying the Identifiers. International Conference on Dublin Core and Metadata Applications, North America. Available at: http://dcpapers.dublincore.org/ojs/pubs/article/view/868/864.
	•	Hillmann, Diane, Naomi Dushay and Jon Phipps. Improving Metadata Quality: Augmentation and Recombination, available at: http://dcpapers.dublincore.org/index.php/pubs/article/view/770
	•	NISO collection of resources on name identifiers.  Online at Name identifiers: http://www.niso.org/news/events/2010/nameid/resources/
	•	Phipps, Jon,  Diane I. Hillmann, and Gordon Paynter. Orchestrating metadata enhancement services: Introducing Lenny, available at: http://dcpapers.dublincore.org/index.php/pubs/article/view/803
	•	Tennison, Jeni. What do URIs Mean Anyway. Jeni’s Musings blog, July 5, 2011. Available at: http://www.jenitennison.com/blog/node/159  .  Many of Tennison’s other blog posts are useful as well.
	•	W3C Library Linked Data Group. Use cases and case studies. http://www.w3.org/2005/Incubator/lld/wiki/UseCases

SECTION FIFTEEN
Standards and ontologies
	•	Coyle, Karen, Thomas Baker. Dublin Core Guidelines for Application Profiles.  At http://dublincore.org/documents/profile-guidelines/ .
	•	DCMI Provenance Group.  The public face of the DCMI provenance work is at http://dublincore.org/groups/provenance/ , but the bulk of the relevant information is in the wiki at http://wiki.bib.uni-mannheim.de/dc-provenance/doku.php .
	•	Dunsire, Gordon. “Distinguishing Content from Carrier: The RDA/ONIX Framework for Resource Categorization”, DLib Magazine, v. 13, no. ½, Jan./Feb. 2007. Available at: http://dlib.org/dlib/january07/dunsire/01dunsire.html
	•	Friend of a Friend (FOAF): http://xmlns.com/foaf/0.1/ , narrative documentation at  http://www.foaf-project.org/ 
	•	The Getty Research Institute. “Getty Thesaurus of Geographic Names Online”. Documentation at http://www.getty.edu/research/tools/vocabularies/tgn/index.html .
	•	Halpin, Harry et al., “Representing vCard Objects in RDF”.  Online at http://www.w3.org/Submission/vcard-rdf/ . A useful table for comparing competing personal-information standards is at http://www.ibiblio.org/hhalpin/homepage/notes/vcardtable.html 
	•	LegalXML work on transcripts, at http://www.legalxml.org/workgroups/substantive/transcripts/wd_10002.shtml
	•	Nilsson, Mikael, Thomas Baker, Pete Johnston. The Singapore Framework for Dublin Core Application Profiles. Documented at http://dublincore.org/documents/singapore-framework/ 
	•	OCLC, FAST (Faceted Application of Subject Terminology), documented at http://www.oclc.org/research/activities/fast/default.htm
	•	Powell, Andy, Mikael Nilsson, Ambjoern Naeve, Pete Johnston and Thomas Baker. DCMI Abstract Model. DCMI Recommendation. June 2007. Online at http://dublincore.org/documents/2007/06/04/abstract-model/>
	•	Raimond, Yves, and Samer Abdallah. “The Events Ontology”. Online at http://motools.sourceforge.net/event/event.html 
	•	Raimond, Yves, and Samer Abdallah.  “The Timeline Ontology”.  Online at http://motools.sourceforge.net/timeline/timeline.html 
	•	Schema.org (a collection of schemas for marking up entities in web pages). Online at http://schema.org .
	•	Spinosa, P., Francesconi, E., and Lupo, C. A Uniform Resource Name (URN) Namespace for Sources of Law (LEX).  IETF informational draft online at  http://tools.ietf.org/html/draft-spinosa-urn-lex-01
	•	Text Encoding Initiative, “Transcriptions of Speech”, at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TS.html
	•	Uniform Resource Names (wikipedia: http://en.wikipedia.org/wiki/Uniform_Resource_Name) 
	•	Universal Postal Union.  Addressing Standards.  Online at: http://www.upu.int/en/activities/addressing/standards.html
	•	W3C proposed organizations standard: http://www.w3.org/2011/gld/wiki/Organizational_Structures
	•	W3C Library Linked Data Incubator group wiki, Recommendation on URIs: http://www.w3.org/2005/Incubator/lld/wiki/Draft_recommendations_page#Create_URIs_for_library_resources_in_good_time_.5BGD.5D  
	•	W3C Provenance Incubator Group.  At http://www.w3.org/2011/prov/wiki/Main_Page
	•	W3C Provenance Incubator Group. “Provenance Vocabulary Mappings”. At http://www.w3.org/2005/Incubator/prov/wiki/Provenance_Vocabulary_Mappings 
	•	W3C Technical Architecture Group. URNS, Namespaces, and Registries.  Online at http://www.w3.org/2001/tag/doc/URNsAndRegistries-50 
	•	Wolf, Misha, and Charles Wicksteed. “Date and Time Formats”. Online at http://www.w3.org/TR/NOTE-datetime

SECTION SIXTEEN
Legislative corpora
	•	Law Librarian’s Society of Washington, DC.  “An Overview of the Congressional Record and its Predecessor Publications”.  http://www.llsdc.org/cong-record/
	•	Law Librarian’s Society of Washington DC, “United States Statutes and the United States Code: Historical Outlines, Notes, Lists, Tables, and Sources”. At http://www.llsdc.org/statutes-code/ .
	•	Richards, Robert and Thomas R. Bruce. Examples of Specialized Legal Metadata Adapted to the Digital Environment, from the US Code of Federal Regulations. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1865329
	•	“United States Code”, Wikipedia article, at http://en.wikipedia.org/wiki/United_states_code 

SECTION SEVENTEEN
Related technologies
	•	Bizer, Christian, Tom Heath, and Tim Berners-Lee, “Linked Data: The Story So Far”, online at http://tomheath.com/papers/bizer-heath-berners-lee-ijswis-linked-data.pdf .
	•	Nadeau, David, and Satoshi Sekine, “A survey of named entity recognition and classification”. Available at http://liicr.nl/IkzHJ0 .
	•	Pang, Bo, and Lillian Lee. “Opinion Mining and Sentiment Analysis”, online at http://www.cs.cornell.edu/home/llee/opinion-mining-sentiment-analysis-survey.html 
	•	Springer, Michelle, Beth Dulabahn, Phil Michel, Barbara Natanson, David Reser, David Woodward, and Helena Zinkham, “For the Common Good: The Library of Congress Flickr Pilot Project”, online at http://www.loc.gov/rr/print/flickr_report_final.pdf .

This section contains four white papers that were written in the course of our investigation.  They make up the source material for much of what is presented in earlier sections on modeling.  The papers deal with:
	•	Identifiers
	•	Use cases and our methodology
	•	The model of legislative events
	•	People and organizations

Musings on Document Identifiers for Legislative Data
Thomas Bruce, Legal Information Institute, Cornell Law School
Diane Hillmann, Metadata Management Associates
John Joergensen, Rutgers-Camden Law School
Robert Richards, Pennsylvania State University
David Shetland, Legal Information Institute, Cornell Law School

An aerial view of the process.

The process described in How Our Laws Are Made (HOLAM) is a lot like the Mississippi River:  formed out of a zillion small tributaries, many of them nameless, joined into a stream that passes through a number of jurisdictions and has lots of side passages, loops and eddies, eventually breaking up again into a series of tiny streams passing through a delta.   There is a central part of the process  -- the mainstream -- that is fairly well mapped, with placenames and milestones that are pretty well understood.  There are hundreds of smaller streams and brooks at either end of the process that are not well understood or named at all, and a few places in the middle where the main stream branches unpredictably.  It is a complicated map, and it describes a territory where many people, places and things are named  -- but  many are not, and some are named in ways that are ambiguous, confusing, or conflicting.

This paper is concerned with identifiers, and particularly with document identifiers : snippets of text that uniquely identify  documents that are either generated by the legislative process or are found in its vicinity.  That idea is simple enough. But good, bulletproof identifier schemes are surprisingly difficult to design -- and are an important foundation of any data model .  

The data model we are building has (at least) two purposes:  first, it is a kind of specification that precisely describes data encountered in and around the legislative process, the precise relationships among the data items and elements, and (significantly) relationships between the data and the real-world people, groups, and processes that create and manipulate the data.  Second, it is a device to enable communication among system-builders, stakeholders, and users about what is to be collected, what is to be expressed or retrieved, and so on.   Before any of that can be built in a way that is both precise and communicative, we must be sure of what exactly we are talking about.  Identifiers should answer that question -- what are we talking about? -- unambiguously.   Or at least we would like them to.  Often, our legacy identifier systems don’t do that very well.  As we shall see,  many existing identifier schemes are burdened with competing constraints and conflicting expectations, with less-than-ideal results.

What we have done 
We began by thinking that one white paper on identifiers would do.  At this point, we’ve realized that it’s a massive task, maybe the most important one in the data-modeling effort, and one where our thinking may well change as we encounter more of the data.  Those and other reasons have led us to divide the task into a number of smaller presentations:
●	this paper, which is an essay spelling out general notions that have formed our thinking about identifiers, and focuses primarily on document identifiers;
●	a paper on the evaluation of different existing identifier schemes, both inside and outside of US legislative materials;
●	a paper on non-document identifiers, including people, places, and off-web things, which also incorporates some thoughts about multimedia materials;
●	a set of corpus-by-corpus recommendations that looks at each major document collection in the Federal legislative corpus:
○	Bills and resolutions
○	Public Laws
○	Treaties and other International Agreements
○	Committee Hearings
○	Congressional debates and the Congressional Record
○	Committee Prints
○	Serial Set (House and Senate Documents and Reports)
○	Presidential Signing Statements
The work is very preliminary and incomplete; there is much more to come.  We welcome any and all feedback, both as to existing content and on future directions and subject matter.
What do identifiers do?

In print, identifiers have worked differently than we really want them to in an electronic environment.  The conventions of printed books -- use of pagination, difficulty of recalling a document once issued, relative stability of editions, and most of all the assumption that identifiers will be interpreted by human readers with some knowledge of their context and purpose -- result in identifiers that are less rigorous than what we need in a world of granular data processed by machines.  Some illustrations are found below. In reality our legacy "identifiers" are often less-rigorous monikers serving multiple functions, and in a digital environment we must unpack them into separate items with separate functions.  Here are some of the functions:

a) Unique naming.  The diverse monikers that document creators and administrators use in current practice are supposed to provide unique names for documents.  Sometimes they do; often they don’t.  Usually that is because a moniker that is unique within a particular scope loses uniqueness in some wider, unanticipated arena. That is especially likely to happen when a collection of objects is moved from its original, intended scope on to the open Web, but you can find examples closer to home.  A Congressional bill number is a good example: it is unique only within the Congress during which it was assigned.  There might be an “H.R. 1234” for several Congresses; “108 H.R. 1234” is made unique by the addition of the number of the Congress during which it was introduced.  Human error can sometimes play a role, as when (for one year in the mid-1990s), there were two very different section 512s in Title 17 of the US Code.   

b) Navigational reference.  Identifiers often serve as search terms or convenient handles for taking the reader to another document, or for retrieving it (we discuss retrieval in the next section).  Standard caselaw citation practice is a special case of this, created specifically for printed books.  In legacy applications, unique identification and citation functions are often run together, usually because numbered pages are not sufficiently granular to uniquely identify individual items.   
A familiar example comes not from legislative data, but from the courts. Two briefly-reported judicial opinions might well appear on the same page of a print reporter, and thus carry an identical citation.  The citation is then a perfectly good tool for navigating to each case within a series of printed volumes, but is not a unique name or identifier for either case.   A look at http://bulk.resource.org/courts.gov/c/F3/173/ will show that numerous cases, each quite short, originally appeared on page 421 of Volume 173 of West’s Federal Reporter, 3rd Series.   A sample is here: http://liicr.nl/rimZJe .  Any of the cases listed might be cited as 173 F.3d 421.

c) Retrieval hook/container label.   Here, we distinguish use of a citation as a retrieval hook from its use as a navigational device. As we make our way around the Web, that distinction is usually blurred. Following a link to its destination puts a chunk of text in front of our eyes; that familiar action blurs the distinction between navigation to a particular point in a document with retrieval of a chunk of that document. Thus, it’s hard to remember that the link might refer to the contents of a labelled container, rather than to a simple destination milestone, and that containers and milestones are really quite different things.  

To make the distinction clear, it’s useful to think about incorporation-by-reference or other forms of embedding.  Suppose that we wish to present the current text of a subsection of a statute inside some other online document -- a citizen’s guide to Social Security benefits, for example.  We would likely do that via machine retrieval of the particular statutory subsection based on its identifier -- but our goal would be to summon up a chunk of text, not navigate to a particular destination.  Put another way, our current practice conflates the use of citation as a means of identifying a point, milestone, or destination in a document (a retrieval hook) with a means of identifying a labelled subdocument that can be referenced or retrieved for other purposes ( a container label).

As an example, the THOMAS pages for individual bills and resolutions aggregate a great deal of information from the Congressional Record (CR), linking from the Bill Summary ‘Actions’ to both a textual representation of the CR page beginning with the desired text (but sometimes extending past the desired text into other information about unrelated issues) as well as a PDF representation of the page which shows the whole page (where the desired text may start towards the end, plus subsequent pages if the relevant section extends past the initial page). 

For a specific example of this, the Lily Ledbetter Fair Pay Act of 2009 has a list of major actions on Thomas, one of which is a “motion to proceed to consideration of measure withdrawn in Senate” on Jan. 13, 2009.  The link for information on that motion is to CR S349: a specific page of the Congressional Record. Invoking that link leads to this display:

The Thomas page lists the four items on the particular Congressional Record page, the last of which is the item sought.  When that item is invoked a default page with the specific text of the motion is retrieved, but an additional link to the PDF version of that page can be viewed via a link at the head of the text, with the Lily Ledbetter motion at the bottom of the retrieved PDF.

d) Thread tag/associative marker.   Some monikers group related documents into threads -- aggregations whose internal arrangement is implicitly chronological.  An insurance company claim number is, in this way, a dual-purpose tool.  On the one hand, it refers uniquely to a document (a claim form) that you submit after your fender-bender.  On the other, the insurance company tells you that you must “use this claim number in all correspondence”  -- that is,  use it to prospectively tag related documents.  That creates a labelled group of documents. If we then sort the group chronologically, it becomes a kind of narrative thread.  

In this way, the moniker implies a relationship between the documents without explicitly naming or describing it, as well as being pressed into service as the identifier for one or more documents in the cluster. Regulatory docket numbers function in this manner. That is intentional, because dockets are meant to be gathering places for documents. What is confusing  -- and important to remember -- is that a moniker that uniquely identifies a process -- a regulatory rulemaking -- has been bent to identify a collection of items associated with that process, and neither the association nor the documents have been uniquely identified.

Another conceptually-related but distinct example of this is the use of “captive search” URIs to meet a user’s need to dynamically assemble a set of related documents. For instance, one can retrieve all the environmental law decisions of the Supreme Court at this link:

http://www.law.cornell.edu/supct/search/index.html?query=environment+or+environmental%20or%20EPA

Such URIs embed search terms (“environment”, “environmental”, “EPA”) and, when used in links, retrieve the set of documents found by searching on those terms.  Typically, they are used to deal with instability or growth in the underlying corpus of things being searched. They are “automatically” kept up to date as the collection changes, inasmuch as they just provoke a search of the changed collection. 

In that way, they are a great help to site designers. Problems can arise, however, if the user imagines that the URI somehow identifies the exact set of items retrieved for any time period other than the present moment. Precisely because the method is dynamic, the user may or may not retrieve the same document set at a later invocation.   As a low-cost, low-effort alternative to semantic tagging, however, the approach is irresistible.  

Some newer systems,  such as VIAF, do allow the ad-hoc construction of URIs for dynamically assembled sets of objects that are then fixed as a permanent group identified by the newly-minted URI. Assuming that an appropriate search could be designed, one might thus construct URIs for any useful group of items found in an authority file, for example a list of all subcommittees of the House Armed Services Committee that have existed up to the present:

http://viaf.org/viaf/search?query=local.names+all+%22house%20armed%20services%20committee%20subcommittee%22+and+local.sources+any+%22lc%22

e) Process milestone.  The grant of a moniker by an official body can be an acknowledgement that official notice must now be taken, or that some process has begun, ended, or reached some other important stage.  That is obviously the case with bills, where a single piece of legislation may receive a number of identifiers as it makes its way through the process, culminating in a Public Law number at the time of signing. The existence of such a PL number can be taken as evidence that the bill has been passed into law.

f) Proxy for provenance.  Again because monikers are often assigned by officials or organizations with special standing, they become proxies for provenance.  The existence of a bill number is evidence that the Clerk of the House has seen something and acted in a particular way with respect to it; it is valuable evidence in any attempt to establish authority.

g) Popular names, professional terms of art, and other vernacular uses.  Monikers notably find their way into popular and professional use, some in ways that are quite persistent.  News media frequently refer to legislation by a popular name created by Congress based on the names of sponsors (the “Taft-Hartley Act”) or by the press itself (“Obamacare”).  They can be politicized (“death tax”), or serve as a kind of marketing tool (“USA-PATRIOT Act”). Some labels and identifiers become very closely associated with the things they label, becoming terms of art in their own right.  Thus, it is common to refer to a “501(c)(3) nonprofit” or a “Subchapter K”  partnership.  Vernacular labels have particular importance for citizens, who often use them as input to search systems.  

Our remarks here demonstrate scoping problems of their own: most of our thinking and examples are primarily derived from government document collections.  It is important that we expand our thinking (for instance) to point-in-time references to multimedia objects, and other non-document resources.
Identifier granularity

How small a thing should we try to identify? It’s difficult to make general prescriptions about this, for needs vary from corpus to corpus.  For the most part, we assume that identifier granularity should follow common citation or cross-referencing practice -- that is, the smallest thing we identify or label should be the smallest thing that standard citation practice would allow a user to navigate to.  That will vary from collection to collection, and from context to context. For example, it’s quite common for citation to the US Code to refer to objects at the subsection level, sometimes right down to the paragraph level.  On the other hand, references to the Code in the Parallel Table of Authorities and Rules generally refer to a full section.  Similarly, although cross-references within the Code of Federal Regulations can be very granular, external references typically occur at the Part level.  That is because CFR Parts broadly correspond to particular programs within a regulatory agency, and are therefore fairly stable over time.  By contrast, sections within those Parts come and go, changing numbering quite frequently.  In that sense, “standard” citation practice consists of citing to a destination that is most likely to persist over time.  That destination might be more or less granular, depending on the corpus.

But perhaps we should qualify that, for our citation and cross-referencing practices have evolved in the context of print, and we may be able to do better.  The move from print to digital overturns background assumptions about practicality.  For example, print typically makes different assumptions about identifier stability than you would find, say, in an online legislative drafting system.  Good examples of this are found in citation practice for the Code of Federal Regulations, which typically cites material at the Part level because (one imagines) changes in numbering and naming of sections are so frequent as to render identifiers tied to such fine divisions unstable -- at least in print, where the shelf life of such fine-grained identifiers is shorter than the shelf life of the edition by an order of magnitude. In a digital environment, it might be possible to manage identifiers more closely, permitting graceful failure of those that are no longer valid, and providing automated navigation to things that have moved. We look at some of the possibilities and implications in sections on granularity, fragmentation, and recombination below.  All of those capabilities carry costs, and overkill is possible.
Metadata, markup, and embedding

Thinking about granularity leads to notions about how the metadata and the target object itself are connected.  Often metadata applies to chunks of documents rather than whole documents.  Cross-referencing in statutes and legislation is usually done at the subdocument level, for instance, and subject-matter classification of a bill containing multiple unrelated provisions would be better if the subject classifications could be separately tied to specific provisions within the bill. That need becomes particularly acute when something important, but unrelated to the main purpose of the bill, has been “snuck in” to a much larger piece of legislation.  A stunning example of such a Frankenstein’s monster appears at  111 Pub. L. 226 . It is described in its preamble as modernizing the air-traffic control system, but its first major Title heading describes it as an “Education Jobs Fund”,  and its second major Title contemplates highly technical apparatus for providing fiscal relief to state governments.

We are aware that in many cases we will be thinking in terms that are not currently supported by the markup of documents in existing XML-creating systems.  However, we think it makes sense to design identifier systems that are more capable than some document collections will currently support via markup, in the expectation that  markup in those collections will evolve to the same granularity as current cross-referencing and citation practice, and that point-in-time systems supporting the full lifecycle of legislative drafting, passage, and codification will become the norm.  Right now,  divisions of statutory and regulatory text below the section level (“subsection containers”) are among the most prominent examples of “missing markup”; they are provided for in the legislative XML DTDs at (eg.) xml.house.gov, but do not survive into the FD/SYS versions from GPO.

Most often, we imagine that the flow of document processing leads from markup to metadata, since as a practical matter a lot of metadata is generated simply by extracting text features that have been tagged with some XML or HTML element.  Sometimes the flow is in the other direction; we may want to embed metadata in the documents for various purposes.  Use of microformats, microdata, and other such schemes can be useful for various applications; the use of research-management software like Zotero, or the embedding of information about document authenticity comes to mind.  These are not part of the model per se, but represent use cases worth thinking about.

Stresses and strains
This section considers things that affect the design of real-world identifier systems, perhaps rendering them less “pure” in information-design terms than we might like.
Semantics versus purity

Some systems enforce notions of identifier purity -- often defined as some combination of uniqueness, orderliness, and ease of collation and sorting -- by rigorously stripping all semantics from identifiers.  That is an approach that can function reasonably well in back-end systems, but greatly reduces the usefulness of the identifiers to humans (because understanding what the identifier identifies requires database reflection), and introduces extra possibilities for error in application because (among other reasons) errors caused by human transcription are hard to catch when the identifiers are meaningless strings of letters and numbers.  On the other hand, “pure” opaque identifiers counter a tendency to assume that one knows what a semantically laden identifier means, when in fact one might not.  And sometimes opaque identifiers can be used to provide stability in situations where labels change frequently but the labelled objects do not.  

At the other end of the spectrum, identifier systems that are heavily burdened with semantics have problems with uniqueness, length, persistence, and other issues arising from inherent ambiguity of labels and other home-brewed identifier components.  It is worth remembering, too, that one person’s helpful semantics are another’s mumbo-jumbo; just walk up to someone at random and ask them the dates of the 75th Congress. Useful systems find a middle ground between extremes of incomprehensible rigor and mindlessly verbose recitation of loosely-constructed labels. 

It’s worth noting in passing that it can be very  difficult to prevent the unwanted exposure of “back-end” identifier to end users.  For example, URIs constructed from back-end components often find their way into the browser bars of authors researching online, who then paste them into documents that would be better served by more brain-compatible, human-digestible versions. 

Moniker type	Identifier	Notes	
Citation	18 USC 47	Standard citation ignores all but Title and section number; intermediate aggregations not needed, and confusing.	
Popular name	Wild Horse Annie Act		
LII URI, (“presentable” version) 	http://www.law.cornell.edu/uscode/18/47.html	Based on title and section number	
LII URI, “formal” version	http://www.law.cornell.edu/uscode/18/usc_sec_18_00000047----000-.html	Also title and section based, but padded and normalized to allow proper collation; “supersection” aggregations above the section level are similarly disambiguated.	
USGPO URI, GPOAccess	http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=browse_usc&docid=Cite:+18USC47	Parameterized search returning 1 result.	
FindLaw URI	http://codes.lp.findlaw.com/uscode/18/I/3/47	Seemingly mysterious, because it interjects subtitle and part numbering, which is not used in citation.  Note that this hierarchy would also vary from Title to Title of the Code -- not all have Subtitles, eg.	

The table above shows some “monikers in the wild” -- various real-world approaches to the problem of identifying a particular section of the US Code.  The “formal” LII identifier, highlighted in yellow, shows just how elaborate an identifier needs to be if it is to accommodate all the variation that is present in US Code section numbering (there is, for example, a 12 USC 1749bbb-10c).  The FindLaw URI demonstrates the fragility of hierarchical schemes; these would vary enormously from Title to Title, and occasionally lead to some confusion about structure, as intermediate levels of aggregation are called different things in different Titles.
Administrative zones of control and procedural rules

Every identifier implies a zone of administrative control:  somebody has to assign it, somebody has to ensure its uniqueness, and somebody or something has to resolve it to an actual document location, physical or electronic.  Though it has taken years, the community has recognized that qualities of persistence and uniqueness are primarily created by administrative rather than technical apparatus.  That becomes a much more critical factor when dealing with government documents, which may be surrounded by legal restrictions on who may assign identifiers and when, and in some cases what the actual formats must be.  A legislative document may have its roots in ideas and policies formed well outside government, pass through numerous internal zones of control as it makes its way through Congress. It may emerge at the other end via a somewhat mysterious intellectual process in which it is blown to bits and the fragments reassigned to a coherent, but altogether different, intellectual structure with its own system of identifiers (we call this ‘codification’).  There may be internal or external requirements that, at various points in the process,  cause the document to be expressed in a variety of publications and formats each carrying its own system of citations and identifiers.

The legacy process, then, is an accretive one in which an object acquires multiple monikers from multiple sources, each with its own requirements and rules.  Sometimes those requirements and rules are shaped by concerns that are outside, and perhaps at odds with, sound information-organization practice.  

For example, the House and Senate each have their own rules of procedure, in which bill numbering is specified.  Bill numbers are usually accession numbers that reset with each new Congress, but the rules of procedure create exceptions.  Under the rules of the House for  the 106th Congress, the first ten bill numbers were reserved for use by the Speaker of the House for a specified time period. During the 107th and 108th Congresses (at least), the time period was extended to the full first session.  We surmise that this may have represented an attempt to reserve “important” bill numbers for things important to the majority party’s legislative agenda.  Needless to say, this rendered any relationship between bill numbers and chronology or order of introduction questionable, at least in a limited number of cases. The important point is that identifier usage will be hostage to political considerations for as long as it is controlled by rules of procedure; that situation is not likely to change.  

But there are also virtues to the legacy process, primarily because close association with long-standing institutional practices lends long-term stability to identifier schemes.  Bill numbers have institutional advocates, are well-understood, and unlikely to change very much in deployment or format. They provide good service within their intended scope, however much they may lose when taken outside it.

So far as we are able to tell, no system of identifiers currently in public use extends over the entire lifecycle of legislation, though it is possible that there are identifiers in use in each chamber’s legislation-management systems that fill this function at the back end. Such a system of identifiers is needed, and would be a “gold standard” that could be related to all of the various legacy identifier systems in use, creating interoperability between identifier schemes across the full lifespan of legislation.   

Status, tracing, versioning and parallel activity

It is useful to distinguish between tracing the evolution of a bill or other legislative document and recording the status of that document.  Status usually records a strong association between some version of the document and a particular, well-known stage in the process by which it is created, revised, or made binding.  That presents two problems.  There is a granularity problem, in that some legislative events that cause alteration of the document are so trivial that to distinguish all of them would be to create an unnecessarily fine-grained, burdensome, and unworkable system. There is a stability problem in that legislative processes change over time, sometimes in ways that are very significant, as when (in 1975) the House rules changed to allow bills to be considered by multiple committees, and sometimes in ways that are not, as when House procedural rules are revised in trivial, short-lived ways at the beginning of each new Congress.  Optimally, bill status would be a property drawn from a small vocabulary of documented legislative milestones or events that remains very stable over time.  Detailed tracing of the evolution of a bill would be enabled through a series of relationships among documents that would (for instance) identify predecessor and successor drafts as well as other inter-document relationships.  These properties would exist quite apart from the identifier scheme. Such a scheme might readily be extended to accommodate the existence of multiple, parallel drafts, as sometimes happens during committee process.

In this way, the model would answer questions about the “version” of a given document by making assertions either about its “status” -- that is, whether it is tied to some well-known milestone in legislative process -- or by some combination of properties that are chained back to such a milestone.  For example, a document might be described as a “committee draft from Committee X that is a direct revision of the document submitted to the committee, dated on such-and-such a date”.  The exact “version” of the document is given by a chain of relationships tied back to a draft that can be definitively associated with a stable milestone in the legislative process.

It’s worth noting that while it would certainly be possible to identify versions using “version numbers” built out by extending the accession number of the root document with various semantically-derived text strings, it’s not necessary to do so.  The identifiers could, in fact, be anything at all.  All that is needed is for them to be linked to well-known “milestone” documents by a chain of relationships ( for example,  “isSuccessorVersionOf”) that link back to a well-known, numbered document.  This may be particularly important when the document-to-document relationship extends across boundaries between zones of administrative control, or outside government altogether.
Granularity
To a great extent, the things that are being 'identified' by identifiers are discrete documents, traditionally rendered as discrete print works. There are, however, significant exceptions that should be accommodated. In addition, changes in the nature and structure of documents that may be issued in the future should be anticipated as well.

The issue of “granularity”, therefore, arises from the need to identify parts of a discrete document. For example, although a congressional hearing is published as a single document (sometimes in multi-volume form), it may be useful to make specific references to the testimony of individual witnesses. Even more significant would be mapping the relationships between the U.S. Code and the public laws from which it is derived. In these cases, the granularity of the identifiers available should be more fine-grained than the documents being identified. So, although a Public Law or slip law can be completely identified and described by a given set of identifiers, it is valuable to have additional identifiers available for sub-parts of these documents, so that mapping adequate relationships to sections of the U.S. Code can be described.

Of course, the danger of admitting such identifiers is that it is that it can be a slippery slope. The set of things which could be identified in legislative documents is fairly unbounded, and any identifiers will arguably be useful to someone. An attempt to label all possible things, however, is madness, and should be avoided. The result would be numbers of unused, or seldom used identifiers which would over-complicate entities and the overall structure of the identifier system.

Fragmentation and recombination

Identifiers are used in ways that go well beyond slapping a unique label on a relatively static document.  They help us keep track of resources that can, in the electronic environment, be highly mobile.  Legislation is often fragmented and re-combined into new expressions, some official and some not.  For many legal purposes, it is important for the fragments to be recognized as authentic, that is, carrying the same weight of authority as the work from which they were originally taken.  Current practice accommodates this through the use of a variety of officially-published finding aids, including significant ones associated with the US Code:  the Table of Popular Names, the “Short Title” notes, and Table III of the printed edition of the US Code, which is essentially a codification map. Elsewhere, Richards and Bruce refer to such a work as a “pont”, that is, something that bridges two isolated legal information resources.  Encoding  of ponts in engineered ways that facilitate use in retrieval systems is a particularly crucial function that should be supported by the identifier model.
  
Codification

Codification presents challenges, the more so because it can erect substantial barriers for inexperienced researchers.  Citizens often seek legislation by popular name (“Wild Horse Annie Act”). They don’t get far.  The problem is usually (though not always) more difficult than simply uncovering an association between the popular name of the act they’re seeking and some coherent chunk of the United States Code, or a fragment within a document that carries a Public Law number.  Often, the original legislation has been codified in ways that scatter fragments over multiple Titles of the US Code.

That is so because even a coherent piece of legislation -- and many are not --  typically addresses a bundle of issue-related concerns, or the needs of a particular constituency.  A “farm bill” might contain provisions related to tax, land use, regulation of commodities, water rights, and so on.  All of those belong in very different places under the system of topics used by the US Code.  Thus, legislation is fragmented and recombined during the process of codification.  While this results in much more coherent intellectual organization of statutes over the long term, it makes it difficult for users to exchange the tokens they have -- usually the popular name of an Act, or some other moniker (“Obamacare”) assigned by the press -- for access to what they are seeking.

Table III of the United States Code provides a map from provisions of Public Laws to their eventual destination within the US Code, as the Code existed at the time of classification.  That is potentially very useful to a present-day audience, provided that the relationships expressed in it could be traced forward through time; changes to the Code from the time of classification forward  would need to be accounted for.  That would rest on two things:  an identifier system capable of tracking the fragments of the original Act as they are codified, and a series of relationships that account for both the process of codification and the processes by which the Code itself subsequently evolves.

Fragmentary re-use
Codification is really a special case of something we might call “fragmentary re-use” -- an application in which a document snippet, or other excerpt from an object, is reused outside its parent.  Later in this essay we discuss the problems of identifier exposure in a Linked Data context, noting that identifiers must carry their own context.  A noteworthy example of this is the legislative fragment that needs to carry some link back to its provenance, and specifically its legal status or authority.  Minimally, this would be an identifier resolvable to a data resource describing the provenance of the fragment.  Such an approach might fit well into a “layered” URI scheme such as that used by legislation.gov.uk. 

How well does current practice measure up?

To judge by the examples presented so far, current practice might best be described as “coping”, and specifically “coping in a way that was largely designed to deal with the problems of print”. Current practice presents a welter of "identifiers", monikers, names, and titles, all believed by those who create and use them to be sufficiently rigorous to qualify as identifiers whether they are or not.  It might be useful to divide these into four categories:

●	Well-understood monikers, issued in predetermined ways as part of the legislative process by known actors.  Their administrative stability may well be the product of statutory requirement or of requirements embedded in House or Senate rules. Many of these will also correspond to definite stages in the legislative process. House and Senate Bill numbers are a good example of this.
●	Monikers arising from need and possibly semi-formalized, or possibly “bent” versions of monikers created for a purpose other than that they end up serving.   Monikers of this kind are widely relied-on,  but nobody is really responsible for them.  Some end up being embedded in retrieval systems because they’re all there is.  A variety of such approaches are on display in the world of House committee prints.
●	Monikers imposed after the fact by the Library of Congress or by other actors in an effort to systematize things or otherwise compensate for any deficiencies of monikers issued at earlier stages of the process.  Certainly internal database identifiers would fit this description; so would most official citation.
●	All other monikers external to the Congress. These might be created within government ( as with GPO’s SuDoc numbers), or outside government altogether (as with accession numbers or other schemes that identify historical papers held in other libraries).  Here, a good model would provide a set of properties enabling others to relate their schemes to ours.
A detailed critique of identifiers in each of these categories would take far longer than anyone is willing to read.

Identifiers in a Linked Data context

John Sheridan (of legislation.gov.uk) has written eloquently about the use of legislative Linked Data to support the development of “accountable systems”  The key idea is that exposing legislative data using Linked Data techniques has particular informational and economic value when that data defines real-world objects for legal purposes.  If we turn our attention from statutes to regulations, that value becomes even more obvious.

Valuable features of Linked Data approaches to legislative information
Ability to reference real-world objects
“On the Semantic Web, URIs identify not just Web documents, but also real-world objects like people and cars, and even abstract ideas and non-existing things like a mythical unicorn. We call these real-world objects or things.”

There are no unicorns in the United States Code. Nevertheless, legislative data describes and references many, many things.  More, it provides fundamental definitions of how those things are seen by Federal law.  It is valuable to be able to expose such definitions -- and other fundamental information -- in a way that allows it to be related to other collections of information for consumption by a global audience.
Avoiding cumbersome standards-building processes

In a particularly insightful blog post that discusses the advantages of the Linked Data methods used in building legislation.gov.uk, Jeni Tennison points out the ability that RDF and Linked Data standards have to solve a longstanding problem in government information systems: the social problem of standard-setting and coordination:

RDF has this balance between allowing individuals and organisations complete freedom in how they describe their information and the opportunity to share and reuse parts of vocabularies in a mix-and-match way. This is so important in a government context because (with all due respect to civil servants) we really want to avoid a situation where we have to get lots of civil servants from multiple agencies into the same room to come up with the single government-approved way of describing a school. We can all imagine how long that would take.

The other thing about RDF that really helps here is that it’s easy to align vocabularies if you want to, post-hoc. RDFS and OWL define properties that you can use to assert that this property is really the same as that property, or that anything with a value for this property has the same value for that other property. This lowers the risk for organisations who are starting to publish using RDF, because it means that if a new vocabulary comes along they can opportunistically match their existing vocabulary with the new one. It enables organisations to tweak existing vocabularies to suit their purposes, by creating specialised versions of established properties.

While Tennison’s remarks here concentrate on vocabularies, a similar point can be made about identifier schemes; it is easy to relate multiple legacy identifiers to a “gold standard”.
Layering and API-building

Well-designed, URI-based identifier schemes create APIs for the underlying data.  At the moment, the leading example for legislative information is the scheme used by legislation.gov.uk, described in summary at http://data.gov.uk/blog/legislationgovuk-api  and in detail in a collection of developer documentation linked from that page.  Because a URI is resolvable, functioning as a sort of retrieval hook, it is also the basis of a well-organized scheme for accessing different facets of the underlying information.  legislation.gov.uk  uses a three-layer system to distinguish the abstract identity of a piece of legislation from its current online expression as a document and from a variety of format-specific representations.  

That is an inspiring approach, but we would want to extend it to encompass point-in-time as well as point-in-process identification (such as being able to retrieve all of the codified fragments of a piece of legislation as codified, using its original bill number, popular name, or what-have-you).  At the moment, legislation.gov.uk does this only via search, but the recently announced Dutch statutory collection at http://doc.metalex.eu/ does support some point-in-time features.   It is worth pointing out that the American system presents greater challenges than either of these,  because of our more chaotic legislative drafting practices, the complexity of the legislative process itself, and our approach to amendment and codification.

Identifier challenges arising from Linked Data (and Web exposure generally)

The idea that we would publish legislative information using Linked Data approaches has obvious granularity implications (see above), but there are others that may prove more difficult.  Here we discuss three:  uniqueness over wider scope, resolvability, and the practical needs of “identifier manufacturing”:

Uniqueness over wider scope

Many of the identifiers developed in the closed silo of the world of legal citation could be reused as URIs in a linked data context, exposing them to use and reuse in environments outside the world where legal citation has developed.  In the open world, identifiers need to carry their context with them, rather than have that context assumed or dependent on bespoke processes for resolution or access.   For the most part, citation of judicial opinions survives wide exposure in fair style.  Other identifiers used for government documents do not cope as well.   Above, we mentioned bill numbers as being limited in chronological scope; other identifiers (particularly those that rely heavily on document titles or dates as the sole means of distinction from other documents in the same corpus) may not fare well either.

Resolvability

The differences between URNs (Uniform Resource Names) and URLs (Uniform Resource Locations, the URIs based on the HTTP protocol) are significant.  Wikipedia notes that the URNs are similar to personal names, the URLs to street addresses--the first rely on resolution services to function.  In many cases, URNs can provide the basis for URLs, with resolution built into the http address, but in the world we’re now working in, URNs must be seen as insufficient for creating linked open data.

In reality, they have different goals.  URIs provide resolvability -- that is, the ability to actually find your way to an information resource,  or to information about a real-world thing that is not on the web.  As Jeni Tennison remarks in her blog, they do that at the expense of creating a certain amount of ambiguity.  Well-designed URN schemes, on the other hand, can be unambiguous in what they name, particularly if they are designed to be part of a global document identification scheme from the beginning, as they are in the emerging URN:Lex specification .   

For our purposes, we probably want to think primarily in terms of URIs, but (as with legacy identifier schemes) there will be advantages to creating sensible linkages between our system, which emphasizes reliability, and others that emphasize a lack of ambiguity and coordination with other datasets.  

Things not on the Web

Legislation is created by real people and it acts on real things.  It is incredibly valuable to be able to relate legislative documents to those things.  The challenge lies, as it always has,  in eliminating ambiguity about which object we are talking about.  A newer and more subtle need is the need to distinguish references to the real-world object itself from references to representations of the object on the web.  The problems of distinguishing one John Smith from another are already well understood in the library community.  URIs present a new set of challenges.  For instance, we might want to think about how we are to correctly interpret a URI that might refer to John Smith, the off-web object that is the person himself, and a URI that refers to the Wikipedia entry that is (possibly one of many) on-web representations of John Smith.  This presents a variety of technical challenges that are still being resolved.  
Practical manufacturing and assignment of Web-oriented identifiers

Thinking about the highly-granular approach needed to make legislative data usefully recombinant -- as suggested in the section on fragmentation and recombination above -- quickly leads to practical questions about where all those granular identifiers will come from. The problem becomes more acute when we being to think about retrofitting such schemes to large bodies of legacy information.  For these among other reasons, the ability to manufacture and assign high-quality identifiers by automated means has become the Philosopher’s Stone of digital legal publishers.  It is not that easy to do.  

The reasons are many, and some arise from design goals that may not be shared by everyone, or from misperceptions about the data.  For example, it’s reasonable to assume that a sequence of accession numbers represents a chronological sequence of some kind, but as we’ve already seen, that’s not always the case.  Legacy practices complicate this.  For example, it would be interesting to see how the sequence of Supreme Court cases for which we have an exact chronological record (via file datestamping associated with electronic transmission) corresponds to their sequence as officially published in printed volumes.  It may well be that sequence in print has been dictated as much by page-layout considerations as by chronology.  It might well be that two organizations assigning sequential identifiers to the same corpus retrospectively would come up with a different sequence.

Those are the problems we encounter in an identifier scheme that is, theoretically, content-independent.  Content-dependent schemes can be even more challenging.  Automatic creation of identifiers typically rests on the automated extraction of one or more document features that can be concatenated to make a unique identifier of wide scope.  There are some document collections where that may be difficult or impossible, either because there is no combination of extractable document features that will result in a unique identifier, or because legacy practices have somehow obliterated necessary information, or because it is not easy to extract the relevant features by automated means.  We imagine that retroconversion of House Committee prints would present exactly this challenge.  

At the same time, it is worth remembering that the technologies available for extracting document features are improving dramatically, suggesting that a layered, incremental approach might be rewarded in the future.  While the idea of “graceful degradation” seems at first blush to be less applicable to identifiers than to other forms of metadata, it is possible to think about the problem a little differently in the context of corpus retroconversion.  That is a complicated discussion, but it seems possible that the use of provisional, accession-based identifiers within a system of properties and relationships designed to accomodate incomplete knowledge about the document might yield good results.

A final note on economics

Identifiers have special value in an information domain where authority is as important as it is for legal information.  In the event of disputes, parties need to be able to definitively identify a dispositive, authoritative version of a statute, regulation, or other legal document.  There is, then, a temptation toward a soft monopoly in identifiers: the idea that there should be a definitive, authoritative copy somewhere leads to the idea of a definitive, authoritative identifier administered by a single organization. Very often, challenges of scale and scope have dictated that that be a commercial publisher.  Such a scheme was followed for many years in the citation of judicial opinions, resulting in an effective monopoly for one publisher.  That is proving remarkably difficult and expensive to undo, even though it has had serious cost implications and other detrimental effects on the legal profession and for the public.  Care is needed to ensure that the soft, natural monopoly that arises from the creation of authoritative documents by authoritative sources does not harden into real impediments to the free flow of public information, as it did in the case of judicial opinions.
What we recommend

Detailed recommendations for each corpus mentioned in the BAA will appear in  a separate document.  These are broad recommendations based on the general principles stated in each paper.  At this preliminary stage, it seems to us that the most practical strategy would involve the retention of legacy monikers in the foreground, related to a strengthened “gold standard” system that provides full functionality:

●	At the most fundamental level, everything should have an identifier. It should be available for use by the public. For example, Congressional committee reports appear not to have any identifiers, but it would be reasonable to assume that some system is in use in the background, at least for their publication by GPO.
●	Many legacy identifier systems will need to be extended  or modified to create a gold standard system, probably issued by a third party (like the Library of Congress) and not by the document creators themselves.  This is especially the case because there is nobody in a position to compel good practice by document creators over the long term.  Such a gold-standard will need to be:
○	Unambiguous. For example, existing bill and resolution numbers would need to be extended by, eg., a date of introduction.
○	Designed to resist tampering. When things are numbered and labelled, there is a temptation to alter numbers and labels to serve short-term interests.  The reservation of “important” bill numbers under House procedural rules is an example; another (from the executive branch) is the long-standing practice of manipulating RIN numbers to color assessments of agency activity.
○	Clear as to the separation of titling, dating, and identification functions.  Presidential documents provide a good example of something currently needing improvement in this respect.
○	Taking advantage of carefully designed relationships among identifiers to allow the retention of well-understood legacy monikers for foreground use, while making use of a well-structured “gold standard” from the beginning.  Those relationships should enable automated linkage that will allow retrieval across multiple, related identifier systems.
●	Where possible, retain useful semantics in identifiers as a way of increasing access and reducing errors.  It is possible that different audiences will require different semantics, making this unlikely to happen in the background, but it should be possible to retain this functionality in the foreground.
●	Maintain granularity at the level of common citation and crossreferencing practice, but with a distinction between identifiers and labels.  Identifiers should be assigned at the whole-document level, with the notion of “whole document” determined on a corpus-by-corpus basis.  Labels may be assigned to subdocuments (eg., a section of a bill) for purposes of navigation and retrieval.  This is similar in function and purpose to the distinction between HREF and NAME attributes in HTML anchor tags.
●	Use a layered approach.  In our view, it is important not to hold future systems hostage to what is practicable in legacy document collections.  In general, it will be much harder to implement good practices over documents that were not “born digital”.  That is not a good reason to water down our prospective approach, but it is a good reason to design systems that degrade gracefully when it becomes difficult or impossible to deal with older collections. That is particularly true at a time when the technologies for extracting metadata from legacy documents are improving dramatically, suggesting that a layered, incremental approach might produce great gains in the future.

Resources

Berners-Lee, Tim. Cool URIs for the Semantic Web. Online at http://www.w3.org/TR/cooluris/#semweb

Bruce, T.R. and Shetland, D.A. (2007). Resilience in Identifier Design.  Position paper for the JURIX 2007 workshop on legislative XML.  Online at http://liicr.nl/pzPQWx

Bruce, T. R., and Richards, R. C. (2011). Adapting Specialized Legal Metadata to the Digital Environment: The Code of Federal Regulations Parallel Table of Authorities and Rules. Paper presented at ICAIL 2011: The 13th International Conference on Artificial Intelligence and Law. Slides at http://liicr.nl/qdWBWi .  Full text available from the authors.

Campbell, D.. Identifying the Identifiers. International Conference on Dublin Core and Metadata Applications, North America. Available at: http://dcpapers.dublincore.org/ojs/pubs/article/view/868/864. 

legislation.gov.uk : high-level API documentation at http://data.gov.uk/blog/legislationgovuk-api

Netherlands statutes online: http://doc.metalex.eu/

NISO collection of resources on name identifiers.  Online at Name identifiers: http://www.niso.org/news/events/2010/nameid/resources/ 

Spinosa, P., Francesconi, E., and Lupo, C. A Uniform Resource Name (URN) Namespace for Sources of Law (LEX).  IETF informational draft online at  http://tools.ietf.org/html/draft-spinosa-urn-lex-01

Tennison, Jeni. What do URIs Mean Anyway. Jeni’s Musings blog, July 5, 2011. Available at: http://www.jenitennison.com/blog/node/159  .  Many of Tennison’s other blog posts are useful as well.

Uniform Resource Names (wikipedia: http://en.wikipedia.org/wiki/Uniform_Resource_Name) 

W3C Library Linked Data Incubator group wiki, Recommendation on URIs: http://www.w3.org/2005/Incubator/lld/wiki/Draft_recommendations_page#Create_URIs_for_library_resources_in_good_time_.5BGD.5D  

W3C Technical Architecture Group. URNS, Namespaces, and Registries.  Online at http://www.w3.org/2001/tag/doc/URNsAndRegistries-50

Use Cases and Their Uses 
Thomas R. Bruce, Legal Information Institute
Diane Hillmann, Metadata Management Associates
John Joergensen, Rutgers-Camden
Jon Phipps, Metadata Management Associates

Introduction
This paper briefly describes the use of use cases -- succinct statements that capture what users want to do with metadata -- as a foundation for building metadata models and systems.  People with software-development backgrounds will not be surprised that one might begin the design of a metadata regime by asking precisely what people want to do with the metadata; that’s how software has always been built.  But it’s not how metadata models actually have been built, for the most part, and more traditional librarians may be surprised at the way in which use-case methods value system functionality over the building of idealized models and descriptions.

In that way, the use of use cases is an intensely practical choice.  It is one part of the development of Dublin Core application profiles (DCAPs), which we also discuss here, and a foundation of the Singapore Framework,  a methodology that emphasizes the grounding of DCAP development in use cases and supporting documentation. It is an emerging standard that

… is a framework for designing metadata applications for maximum interoperability and for documenting such applications for maximum reusability. The framework defines a set of descriptive components that are necessary or useful for documenting an Application Profile and describes how how these documentary standards relate to standard domain models and Semantic Web foundation standards.

The Framework’s emphasis on methodology and documentation is in itself a bit unusual.  The world of the Semantic Web is most often described by narrow and slightly abstract technical standards that are (often erroneously) assumed to be both self-documenting and agnostic about sound design procedures beyond the technical apparatus they specify.  We like the Singapore Framework because it addresses problems of documentation and design procedure in a way that we think well-suited to a project like ours, where we are attempting to harmonize metadata drawn from a number of administratively-independent sources in order to create a data model of maximum utility to a very diverse user community.
Use-case methodology

Use cases are simple structured narratives that describe what users want to do with metadata.  The collection of use cases thus provides a useful strategy for data model development using functional requirements that are gathered from data consumers.  Use-case methodology is very common in software engineering, where it is an important part of developing functional specifications for software systems.  It is also used for creating functional tests of work in progress.

One strength of the method is that it is particularly adaptable to collaborative, inter-organizational approaches in which use cases are collected from a wide range of institutional and individual actors.  For example, the World Wide Web Consortium’s Library Linked Data Incubator Group spent a fair amount of time early in its work gathering use cases . In fact, that use case document is one of the two deliverables described in their charter .  The general idea seems simple, and not at all controversial: begin the design process with a set of well-understood and documented notions about the users of the system and what we want the resulting model or system to do for those users.  But it runs counter to a well-known tendency to seek the model that is intellectually perfect rather than the one that addresses known, prioritized needs and system functionality.  

That focus on needs is its greatest strength. The most compelling reason to prefer a use case based approach is that it keeps us focused on the overall purpose of the system we are designing. In a recent blog post describing the development of a search engine site, Henri Sivonen writes pungently about the perils:

“An easy explanation for not using existing vocabularies is that communities doing metadata domain modeling are looking at the problem from the wrong perspective by considering what can be expressed about a topic while the search engine implementors care about what matters for consuming data for the purposes of search use cases and they just happened to care about different things than what the pre-existing communities had developed specs for.  

In my experience, metadata design efforts tend to fall into the trap of focusing more about what could be said about a topic rather than what needs to be said in order to support use cases of the consuming software.  I stopped believing in metadata when I spent a summer at the National Archives (of Finland) thinking about metadata and saw how many existing specs seemed to focus on recording inessential things and failing to record essential things as far as the use case I was tasked to think about was concerned.”  (http://hsivonen.iki.fi/schema-org-and-communities/) 

Those who find Sivonen’s remarks intemperate will quickly point out that designing on the basis of a few scattered, unrelated needs will result in the sort of elephant that could only be built by a committee of blind men, each of whom is focused on only one part of the elephant.  There is that risk, particularly if the community of users who contribute use cases is in some way unrepresentative, if the collection of use cases is superficial or too small, or if designers are excessively biased toward the familiar needs of the past.  We ourselves have noted a certain skew toward end-user search applications in our own thinking.  But the fact remains that many, many projects have sought “perfect” descriptions of data, chasing the Holy Grail of meeting every conceivable need to the detriment of creating systems that work well for most people most of the time.  That is an expensive and time-consuming approach, and we need to get away from it.

In a 2004 book chapter on metadata quality, Bruce and Hillmann began to consider the practical effects of cultural differences between those who grew up in library-cataloger culture and those whose background lies primarily in software engineering.  A bias toward perfecting descriptions before practical uses are considered arises quite naturally from traditional cataloging practices, in which most materials are touched once and seldom if ever revisited.  By contrast, computer technologists generally apply evolving technologies iteratively to raise quality, widen collection scope, or address an expanded set of user needs, making good on whatever investment has been made in the extensibility of systems at the outset.   

We believe that iterative approaches are important to a legislative-metadata project, for three reasons:

●	The user community surrounding legislative data is highly diverse, with a wide penumbra of possible uses surrounding a core set of needs.  That argues that scattered, small communities of specialists will require a model that can be extended. Too, as users and designers gain experience with systems built on the models, new needs will be articulated.
●	The model is subject to changes needed to keep it synchronized with a legislative process that itself changes in ways both large and small.  Prior to 1975, for instance, when the Congress began to permit submission of proposed legislation to multiple committees, one might have relied on a much simpler model than would serve now.  While we cannot anticipate what the next epochal change in procedure might be, we can guess that there will probably be one.
●	Models have to be populated with real metadata, and their scope is usually conditioned by metadata availability.   The economics and management of the population process are changing radically as natural-language processing techniques become more and more capable of accurately extracting metadata elements from large textual corpora.  That is especially significant in an environment where it is important to bring the same capabilities to retrospective collections as will be built into systems going forward. 

We can’t anticipate every need, nor treat every part of the process with all of the detail that a specialist who spends her life in that part might require.  We can, however, build a model that provides both core functionality and the means for specialists to extend it in an iterative, evolving manner.  Our foundational approach requires us to remain grounded in use cases that have been gathered from real users of legislative information, rather than seeking perfection.  In our view, balancing needs as expressed in documented use cases, especially within a context of realistic economic and managerial considerations, leads to an extensible model that will form the best basis for moving forward.  In general, the 80-20 rule applies: 20% of the cases will cover 80% of the need, and that is where we begin.  The long tail can be dealt with by specialized extensions to the model.

Pitfalls of use-case methodology
Use-case methodology is not magic pixie dust.  It has potential drawbacks and aspects that demand care:

Good designs require good use cases.  In this context, “good” might mean a number of things, but we will focus on two:  first, the use case pool needs to be representative, and second, it needs to be both balanced and sane in its level of detail.  

The second point is a direct response to the first: trying to make a use-case pool representative by making it hyper-inclusive is impractical.  It makes the perfect the enemy of the good in much the same way that pursuing perfect, abstract models does.  As to balance, focusing solely on the expressed needs of “most users” tends to create systems that answer only the needs that the largest numbers of consumers are focused on at the time they are asked.  

In our situation, that might result (for example) in a design that stresses present-day search scenarios over the needs of systems-builders or archivists.   There are two other forms of potential bias worth considering. One is the tendency of the use-case development process to focus only on those parts of precursor systems that seem most relevant to the new way of doing things.  But sometimes it can be important to look further back, and recapture functionality that has already been lost or made difficult to use in earlier technological transformations.  For example, certain highly useful print-based finding aids don’t have good analogs in current electronic systems, but could now be rethought using newer technology.  Because those print artifacts aren’t represented in current electronic systems, it would be easy to miss them in the analysis process, or to plan less capable versions than are actually possible.  

A second form of bias can occur because it is often difficult to include -- or even to imagine -- all of the ultimate consumers of data in the collection process.  In a sense, this is just a very specific manifestation of the problem of keeping the pool of use cases representative, but it is worse for some data providers than for others.  Data providers whose material is aggregated, redistributed, or mashed up by others, and providers who issue bulk data for reuse by others, will need to be especially careful.  Experience proves that maintaining feedback mechanisms that extend from the ultimate user all the way back to the source of the data can be challenging to the point of impossibility.

Finally, it’s worth remembering that user “wish lists” are not use cases, though one wish list may embed or assume a great many use cases.  For example, a half-dozen examples of desirable system functions that were embedded in the proposal for this project yielded roughly 30 use cases, many of which were fundamental activities that duplicated use cases that were also surfaced by other scenarios submitted from multiple sources.  That leads to the next point.

Use case compilation is time-consuming.   Use-case gathering is in one sense simple: you just ask users what they do, or want to do, with data or data systems.  However, systematic compilation is important to making sense of the use-case collection.  That involves standardized documentation of each use case in a common, templated format designed to bring out the important facets of each case (we provide an illustration below).  Second, the collection of cases needs to be examined for commonalities and overlaps; this too should be systematically documented.  Depending on the size and diversity of the user community, all this can take a good bit of time.  That, in turn, brings us to the question of how we actually go about collecting cases.

How are we using use cases?

Building models and profiles from use cases requires a range of tasks:

●	Collecting the cases from knowledgeable sources, identifying which are duplicative and which are irrelevant for our project;
●	Recording the use cases in ways that allow them to fulfill a number of needs, preferably using a common template;
●	Organizing and collating the use cases so they can be referenced later and shared effectively.
	
During the process of collecting, recording, and organizing, it’s essential to keep in mind that the cases will be used later to test the functional requirements and model being developed for the project. Thus, the template we use as a standard recording method emphasizes activities that can be used as a basis for testing the model, to determine whether desired functionality is supported, and identify gaps to be addressed.

Collecting and Organizing Use Cases

We have been collecting our use cases from a variety of sources:
●	Actively recruited sources, generally law librarians and researchers known to us and willing to participate;
●	Existing documentary sources that can be gathered without outside help.  These include THOMAS FAQs and those from the House of Representatives site (which imply common use cases), law-library research guides, the RFP for our current project (and others), and feedback information from THOMAS supplied by knowledgeable sources;
●	Outsiders--that is, people who are not law librarians or legal researchers but have specific needs for information, such as historians;
●	Self-generated use cases, often discovered during internal discussions of the larger issues we discuss in the white-paper series.

Our recording and organizing of the developed use cases is based on prior experience of the principals and some research into use case templates used by other projects.  The agreed-upon template was encoded into the project wiki.  That has been done to ensure that insofar as was possible the template was used, and used relatively rigorously by all.  We consider that the discovery and building of use cases will be critical as we continue working, and not something that will be fully populated and “checked off” early in the process.  The trick, we believe, is to achieve balance between the bottom-up, data-driven approach suggested by use cases, and the top-down approach of issue identification and discussion represented by the white-paper series of which this document is a part.

The process so far

The first step was gathering all the use cases we had onto a spreadsheet for initial analysis of duplication, overlap, and relevance.  From there it was relatively easy to begin writing up an initial assortment of use cases using our template.  
The use-case template

The template asks for these items:
●	Use case name,  a descriptive name for the case;
●	Use case number/identifier;
●	Document type, identifying which of the BAA corpora is being used;
●	Purpose, that is, what the user is trying to do;
●	Actors, the types of user (eg. “legislative staff”) for whom the use case is most important or relevant;
●	Prerequisites, items the user needs to have “in hand” for purposes of their task;
●	Sequence of actions, the step-by-step process the user will follow to achieve her result;
●	Results, what the user expects to retrieve or discover as a result of the process described.

In addition, we track versioning information, notes, and remarks about current practices as part of the use-case record.  At present, the template does not contain any designated slot for describing precursor datasets or datasets implied by the sequence of actions.  

Below is the page that ‘gathers’ the use cases for project members, and following it an example of a specific use case:

Application profiles

We employ use-case driven methodology to create documented Dublin Core  application profiles (DCAPs).  For those not familiar with them, DCAPs might be thought of as providing a new kind of framework for the very useful thefts that database designers always commit when they recycle their own schemas and combine them with those developed by others.  They allow the metadata designer to re-use vocabularies developed for other applications, in whole or in part, and combine them with newly-needed elements to create a purpose-built definition for the metadata records needed.  More formally put:

A DCAP defines metadata records which meet specific application needs while providing semantic interoperability with other applications on the basis of globally defined vocabularies and models.

We do not intend to thoroughly describe DCAPs or their uses here; a good introductory reference can be found in the Guidelines for Dublin Core Application Profiles referenced in the footnote above.  However,  a few remarks about them are in order.

If nothing else, the metadata needs of particular communities and applications are diverse. The past few decades have seen a great proliferation of new metadata ‘formats’, even across applications that have significant metadata needs in common, for example: 
●	The visual culture community (primarily art and museum libraries) has developed a specification called ‘VRA Core’ now in version 4, housed at http://www.vraweb.org/projects/vracore4/ 
●	The Society of American Archivists (SAA) has developed a content standard for describing archives, personal papers and manuscript collections, called ‘Describing Archives: A Content Standard’ but popularly known by its acronym ‘DACS’ (http://www.archivists.org/governance/standards/dacs.asp)
●	The public broadcasting community has developed a metadata dictionary primarily for audiovisual media called PBCore (http://pbcore.org/)

The Dublin Core Metadata Initiative has attempted to address the proliferation of content standards by providing a framework for designing a Dublin Core Application Profile (DCAP). A DCAP defines metadata records which meet specific application needs while providing semantic interoperability with other applications on the basis of globally defined vocabularies and models. 

A DCAP is intended to be a generic construct for designing metadata records; one of its virtues is that it does not require the use of metadata terms defined in only one schema. A DCAP can use any terms that are defined on the basis of RDF, combining terms from multiple namespaces as needed. A DCAP follows the DCMI Abstract Model [DCAM], a generic model for metadata records (http://dublincore.org/documents/abstract-model/).

A fully compliant DCAP includes guidance for metadata creators and clear specifications for metadata developers and developers of applications. By articulating what is intended and can be expected from data, application profiles promote the sharing and linking of data within and between communities. The resulting metadata will integrate with a semantic web of linked data. A useful example of a fully documented DCAP is the Scholarly Works Application Profile (SWAP), developed for the sharing of eprints in institutional repositories (http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile)
	
The Singapore Framework was developed primarily as a way to look at the process of building such a DCAP through the lens of a community consensus-building process. It emphasizes full documentation at every stage, from consensus-building to the technical infrastructure supporting validation and quality control.  While the Singapore Framework is a relatively new approach (and still lacks some of the technical building blocks necessary for full realization of a DCAP), it provides a useful way to look at the process of developing the descriptive model at the core of an Application Profile, its component parts, and the relationships between the parts and the underlying applicable standards. In our context, the requirement for explicit documentation of the process of building the model as well as its supporting components has a lot to recommend it.  That documentation -- and the design process it represents -- is strongly rooted in use-case methodology.

Vocabularies

We determined early in the game that we wanted to use some simple controlled vocabularies to make the cases easy to find and manage as the corpus grew.  Our two vocabularies were developed in the context of the Open Metadata Registry (OMR) (http://metadataregistry.org) and consist of a list of actors (http://metadataregistry.org/vocabulary/show/id/125.html), both human and machine.  It currently contains only general actors, which may be augmented as we move along by more detailed notions of 'actors.'  The second vocabulary is for Document Types (http://metadataregistry.org/vocabulary/show/id/126.html) and has been populated with the document types listed in the proposal. We have yet to add definitions to that vocabulary, but will as we gain more experience and move beyond our initial focus on Bills and resolutions.

Model Development and Testing

Properties and classes

From the initial group of use cases, we began working on the model for the first document type: bills and resolutions. That starting point was crucial, providing us with a first set of documents that also represented the origin point in the legislative process. To begin this task, we built a spreadsheet that would allow us to see the general categories of data we would need, using Dublin Core  and FOAF as starting points, and expanding and extending beyond that to areas where more specificity would be needed.  This first spreadsheet will carry the full set of properties and classes we will be working with for all the document types, and can provide the basis for loading these classes and properties into the Open Metadata Registry towards the end of the project. 

A second spreadsheet was set up for the specific properties and classes for the bills and resolutions, including the data elements we needed to describe the documents and sub-documents we were working with, as well as the relationships between them.  Examples of data output (such as the THOMAS aggregations of information around bills) were used to build up prototypes of specific bills using our initial model elements, and to surface questions that needed to be answered as we moved forward. We’re capturing those questions and issues for incorporation into later white papers, as our challenges become clearer, and our understanding of the options and trade offs firmer.

Relationship properties

One of our most important tasks in building the models is to ensure that there are adequate relationship properties built in to support the kind of browsing between document types that will be the hallmark of this approach. For example: data about a bill will include relationships like ‘amendsLaw’ and ‘hasLaterVersion’ as well as things like ‘dateEnacted’.  The relationship properties are generally set up as reciprocal properties, which can ensure that relationships between two entities actually can be used--and managed--in either direction by compliant systems. 

This strategy will continue to build as we move on from bills and resolutions to committee publications.  We expect that we will need to circle back at various points as we see gaps we need to address, from places further down the road.  Initially, we will be focusing on several needs that stuck out in our initial explorations:
●	identifiers, addressed in our first paper;
●	subject-matter information, not particularly well addressed in current legislative systems
●	people, for which sponsorship relationships seem to be among the few available.
●	popular names for bills whether explicit in the bill or assigned by media or other groups (eg. “Wild Horse Annie Act”,  “Obamacare”).

Where the use cases and models meet is during the testing phase, where the strategy of using actual examples will allow us to determine whether our use case goals can be met using the data we’ve built. It won’t require us to build a system, but will require us to think during the testing period as a machine ‘thinks’, answering questions like ‘Will a user be able to gather information about Congressperson X, and see the bills they’ve sponsored and the votes they’ve made?’
Ponts

Use-case compilation and collation is particularly good at identifying documents or other apparatus that provide dense linkage between document collections.  Some examples of these are:
●	the Parallel Table of Authorities and Rules,  which describes enabling-authority and other relationships between the United States Code and the Code of Federal Regulations;
●	the Table of Popular Names, which maps popular names of legislation (eg. the “Omnibus Crime Control Act of 1997”) to particular sections of the US Code;
●	Table III of the United States Code, which provides a highly granular mapping between provisions in legislation (as recorded in the Statutes at Large) and particular sections of the United States Code;
Such “ponts” -- so called because they bridge collections -- generally figure prominently in user descriptions of their present information-seeking activities, because the bridging action they perform stands out in users’ narrations about what they do.   They are very rich sources of information about properties that relate one document to another, particularly across corpus boundaries; indeed, these properties are often so densely encoded, and the encoding so dependent on human judgement for unpacking, that they present significant modeling challenges.  Since, however, they are of such importance to the facilitation of information seeking, they are central to the modeling process.  In a recent paper on the Parallel Table of Authorities and Rules, Bruce and Richards give a detailed illustration of how and why this might be done.   Because of their role in linking separated pools of data together, ponts also represent very high-value targets for encoding and modeling work, and managers may want to move them to the front of the queue in any ongoing plan of work.

Conclusion
The Singapore Framework, with its emphasis on use cases and documentation, provides a sound methodology for the development of a legislative data model. Use cases are easy to gather, and only slightly more difficult to collate and organize.  Above all, use of use cases avoids the customary pitfall of making the perfect the enemy of the good.  Keeping the design very close to expressed user needs avoids analysis paralysis -- the striving for a model that can never be sufficiently perfected.

Resources/References
Coyle, Karen, Thomas Baker. Dublin Core Guidelines for Application Profiles.  At http://dublincore.org/documents/profile-guidelines/ .

Nilsson, Mikael, Thomas Baker, Pete Johnston. The Singapore Framework for Dublin Core Application Profiles. Documented at http://dublincore.org/documents/singapore-framework/

Powell, Andy, Mikael Nilsson, Ambjoern Naeve, Pete Johnston and Thomas Baker. DCMI Abstract Model. DCMI Recommendation. June 2007.
<http://dublincore.org/documents/2007/06/04/abstract-model/>

Richards, Robert and Thomas R. Bruce. Examples of Specialized Legal Metadata Adapted to the Digital Environment, from the US Code of Federal Regulations. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1865329

W3C Library Linked Data Group. Use cases and case studies. http://www.w3.org/2005/Incubator/lld/wiki/UseCases 

Legislative Events: Design Considerations for a Data Model
Thomas R. Bruce, Legal Information Institute (tom@liicornell.org)
Diane Hillmann, Metadata Management Associates (metadata.maven@gmail.com)
John Joergensen, Rutgers University School of Law (jjoerg41@gmail.com)
Jon Phipps, Metadata Management Associates (jonphipps@gmail.com)

DRAFT OF 2012-05-01. NOT FOR CIRCULATION.
[..] events are primarily linguistic or cognitive in nature. That is, the world does not really contain events. Rather, events are the way by which agents classify certain useful and relevant patterns of change.
What do we mean by events?
Legislative events -- things that take place as part of the legislative process -- seem straightforward to define.  They are those things that occur in the legislature: meetings, debates, parliamentary maneuvers, and so on.    But let’s stop for a minute and consider one of the more important words we associate with legislative events:   “vote”.   As a noun, it has two meanings:
●	an occasion on which people announce their agreement or disagreement with some proposition or other;
●	the documentary record of that occasion, expressed as a tally of yeas and nays.

That duality -- what happens, versus the record of what happens -- creates confusion.  We often talk about the documentary record as if it were the process, and vice versa.  That creates problems when a community that is primarily concerned with legislative process -- consumers of legislative information like staffers on Capitol Hill, members of Congress, and others who work with the process itself -- talks to information architects who are primarily concerned with the documentary record.  Subtle differences in understanding about what data models represent  can lead to real confusion about the capabilities of information retrieval systems, particularly during conversations about design and evaluation.

In this paper, we have tried to be explicit about when we are speaking about what.  We begin with a discussion of modeling problems that pertain to events-as-occasions.  A second section treats identifiers for events and how they might be collected and dereferenced.  Finally, we discuss the incorporation of events into a model of legislative process.

Events as occasions: modeling problems

Events are things that occur at a time and place.  They might have duration, but they might also represent an action or change of state for which duration is irrelevant.  For example, one might describe the introduction of a bill as something that takes place during a measurable interval that extends over some milliseconds from the time an envelope leaves the hand of the Member introducing the bill until that envelope hits the bottom of the hopper.  But that would be silly; some events are simply process milestones or instants that have no duration we need worry about.  Most events have participants. Some groups of participants are recurring or somehow formalized;  it makes sense to tie events to our models for people and organizations.  Other participant groups may be ad hoc groups defined solely in terms of the event (“the people waiting for the 3 o’clock bus”).  Finally, events can result in things : notes produced by a musician playing an instrument, or a pie baked as part of a contest, or a legislative amendment produced in the course of a committee meeting.
Duration and timestamps
Events may have duration, or they may not.  “Bill introduction” and “adjournment” are in some sense physical processes that take place in the real world -- a piece of paper is placed in a hopper, or a gavel is struck and people gather up their papers and leave the room --  but we generally think of them as instantaneous abstractions that refer to a point in a process.  By the same token, events may have a duration that is defined with an uncommon use of common language.  A “legislative day” is an example of such a thing: it extends between one adjournment of the Senate and the next, which may occupy days or even months in calendar time.

In our model, events with duration have specific start and end times as properties.  Events without duration have a timestamp as the value of a separate property. Our model specifies time using the W3CDTF date format.  
Participants and their roles
We discuss people and organizations in a separate paper, and have already mentioned some aspects of organizational membership models in our paper on design issues for bills and resolutions.  Participation in events raises a few other questions about our models for people.  In particular, we would stress that people can occupy particular roles with respect to an event, and that those roles may be quite separate from the role that the person occupies within the sponsoring or convening organization.  For example, two of the authors recently attended a workshop sponsored by the Committee on House Administration; the convenor was the Technology Policy Director for that organization, and the Committee Chairman was one of the speakers -- but he played no leadership role in the workshop itself.  Thus, it is necessary to have a set of role properties that adhere to the individual in the context of particular events, separately from their role in a sponsoring organization.
Location and location defaults
Many events take place somewhere in real space, and so event objects need to have attributes that tell us where the event occurs.   As with other data about places, we might choose to model these with geographic coordinates, locations drawn from geodata ontologies, or both; that is the approach we suggested in our earlier work on bills and resolutions.   But neither of those systems deal particularly well with things like office addresses (“1313 Longworth House Office Building”), which provide location information for the kinds of events we associate with legislative process.  Those tend to be expressed as office locations or postal addresses.  Examples of purpose-built systems for postal addresses include the Universal Postal Union S42 standard, the vCard ontology, and the W3C PIM standard.  Of these, the vCard standard seems to present the best balance of detail and workability, and is incorporated into the developing W3C standard for governmental organizations. 

Often, location information is not explicitly stated, but implicit in the nature of the event itself. “Meeting of the House Ways and Means Committee”, for example, embeds a reliable default assumption about where the meeting is to take place, because the meetings always take place in the hearing room that belongs to the committee.  It makes sense to model default assumptions about locations as something that is a property of the organization (e.g. “hasDefaultEventLocation”) rather than of the event. When information about the event itself is partially or totally incomplete, a location can be inferred via the organizational sponsorship of the event. 
Events that collect other events; identifier design
Some events are primarily interesting as collections of other events -- for example, a “session” of Congress, which might be seen as a collection of various occurrences on the floor of the legislative chamber, committee meetings, and so on.  Moreover, we might want the same event to be visible in very different collections -- for example, a particular committee meeting might be part of a calendar, part of a history of meetings of that particular committee, or part of a collection of meetings that different committees have had with respect to a particular bill.

That has implications for identifier design.  As we have in other discussions, we would emphasize here the importance of distinguishing between identifiers (URIs) that provide unique, dereferenceable identification of an object (where that object may itself be a collection of other objects), and alternative URIs used solely for access purposes.  Event identifiers need to be short and opaque;  identifiers for collected events can have elaborate (and varied) semantics associated with path elements in the URI.   Here are some illustrative examples:

http://congress.gov/congresses/101/sessions	All sessions of the 101st Congress	
http://house.gov/congresses/101/sessions/2011/	First session of the 101st Congress. We believe that the use of the year is more helpful than misleading.	
http://congress.gov/congresses/101/sessions/2012/events/2012-04-23/votes 	All votes taken on 2012-04-23, House or Senate.  	
http://congress.gov/congresses/101/sessions/2012/events/2012-04-23/house/votes	A collection identifier that mirrors the organization of the Congressional Record (though other ordering of the hierarchy would also be sensible)	
http://congress.gov/congresses/101/house/sessions/2012/votes/[vote-number]		
An individual identifier for a vote (House roll call vote numbering runs with the session)http://congress.gov/congresses/101/house/committees/events/hearings 	All hearings before House committees for the 101st Congress	

Even this limited set of examples shows that consistency and thorough coverage of imaginable use cases will require a lot of painstaking work if they are to be achieved simultaneously.  Different -- and possibly inconsistent -- orderings of the collection hierarchy make sense for different purposes.  For example, should the committee information come first in the path hierarchy, or the type of committee event?  For some users, ../events/hearings/committees/Judiciary makes more sense than ../committees/Judiciary/events/hearings , and so on.  Which of these pathways will be “real” unique identifiers, and which should just represent access pathways to the information?
Documentary products
Events produce things.  Of greatest interest to us, legislative events tend to produce documents that were either themselves the “subject” of the event (as in floor debate over a particular bill) or its result (as when a committee markup session produces a new version of a bill).   

The role of the document (or the more abstract notion of a “bill” or “resolution” of which it is the expression) as a value for an “aboutness” property is problematic.  As we have remarked elsewhere, bills often have multiple provisions on widely different topics, and a bill’s identifier would be potentially confusing or unhelpful as the sole value offered as, say, the “subject” of a debate.  At the same time, it is quite legitimate to say that the bill is what the debate is “about”, in the sense that the bill number would no doubt appear in any headline or agenda entry used for a description of the event -- regardless of whether a single word of the discussion actually was about any part of the bill itself, or whether it was a more general discussion about an issue that the bill was meant to address, or was an occasion for a partisan attack on another party.  It might thus be wise to distinguish the “agenda item for the discussion” from “the subject of the discussion” in some way.

Modeling the proper relationships between a sequence of events and the documentary workflow that more-or-less tightly reflects it is a difficult thing.  The next section discusses that problem in some detail.
Events, legislative process, and documentary workflow

Events are components of any legislative process model. It is important to think about the ways events form narratives about the legislative process, and the ways in which events can be tied to the documents that the legislative process creates.  Prior attempts to integrate an events model with legislative documentation have primarily been concerned with problems of versioning and of legislative applicability or effect.  We are concerned the process of creation.

Existing ways of modeling -- or even discussing -- what happens to a measure as it makes its way through Congress are characterized by some confusion between closely connected approaches that are, nevertheless, subtly different.  Broadly, those approaches might be divided into three types:
●	A process-aware model, in which documents are seen as artifacts produced by particular actions or processes within the legislature.  (On that view, a “measure” is something of an abstraction that groups a series of bill or resolution texts created during the legislative process,  as well as related documentary artifacts such as amendments, signing statements, and so on).  Such a model might be one of two types:
○	A model that identifies major stages and events of interest to both legislative insiders and the public.  Examples might include the THOMAS vocabulary for bill stages, or the steps represented in a simplified infographic created for public education.
○	Finer-grained, events-based models that divide the legislative process into minutely detailed steps needed by particular communities, for example those interested in the activities of Congressional committees.
●	A “legislative process” model containing parliamentary process detail. From a distance, this approach looks a lot like a fine-grained version of the process-aware model just mentioned.  But it is far more detailed in its treatment of parliamentary procedure, rules for debate, and other turns and twists primarily of short-term interest to Congressional insiders. That is the type of story told, for example, by the CRS report on resolving differences between House and Senate bill versions. Pieces of such an approach show up in the bill-status attribute used by the House for its XML schemas and DTDs, which contains such status indicators as “held-at-desk-House” and “reengrossed-amendment-Senate”.
●	A “workflow” model, which focuses on the actual flow, versioning, and exchange of documents or other work product.  Such a document-centric model has obvious intersections (and points of confusion) with a “process-aware” model, in which major legislative events tend to produce important versions of documents.  It also intersects the “legislative process” model, in which certain parliamentary actions (such as amendment) provoke the production of particular documents.

Most of the existing vocabularies in use  -- which tend to use words like “status” or “stage” to describe their components -- use more than one of these approaches at the same time.  That leads to some subtle confusion. Each of the approaches views the world a little differently, and mixing them leads to some inconsistencies.  An illustration  of such a mixed model is provided by the “bill stage” vocabulary from GPO, which contains aspects of the process-aware model (“Considered and Passed House”), the legislative process model (“Additional Sponsors House”), and the workflow model (“Amendment Ordered to be Printed Senate”) all at once.

We have taken a process-aware approach to create the spine of our model, for several reasons. We have tried to map as much useful detail as possible, while avoiding the many pitfalls inherent in trying to over-think and over-model. An excessively detailed approach focussed on particular parts of the process tends to skew the usefulness of the resulting model in favor of a limited number of specialized users. Also, excessive detail in any or all aspects of such a system inevitably results in a model too cumbersome to be used or maintained:
●	Too-fine distinctions between identifiers will become confused and misapplied, both by maintainers and users.
●	Many identifiers thought useful will end up being dismissed as over-specific, leading to inefficiency and eventually, further confusion.
●	The level of technical expertise required to implement and maintain a too-highly-detailed model will become limited to far too few individuals to guarantee its proper use.
●	Finally, the time and expense involved in too great a level of detail will, in the end, render it of limited usefulness.

Instead, we have tried to provide a model that is “just right” in its level of detail, while acknowledging that our decisions about the various trade-offs involved in such an approach  would not be everyone’s.    The model has been created with an inherent extensibility that ensures that others may later add any level of specialized detail that they need.  

Beyond avoiding problems with excessive detail, such an approach has a few virtues:
●	Conformance with (and respect for) existing systems.  It will probably come as no surprise that most of the existing systems that track legislative information agree as to the major features of the process.  So do most of the helpful narratives -- such as HOLAM and a wide array of CRS reports -- that inform people about the process.  With such obvious landmarks in common view, it would be a mistake to suggest a map that ignores the landmarks that everyone sees and agrees on.
●	Interoperability.  Using a coarser-grained, process-aware model requires a willingness to compromise a level of specialized meaning that might be achieved through the use of more specialized objects, relationships, and identifiers at every stage of the process.  However, the compromises are not so great. The interoperability that results from making use of existing systems and standards more than compensates for them.  We believe that most of those who currently track legislative information will be able to find obvious points of correspondence and linkage for their own systems.
●	Clarity.  Our process-aware approach provides a means of clearly tying the document model to the process model without creating confusion. Our bifurcated audience looks at events in quite different ways.  Researchers see events in the context of the legislative process, and focus on the aspects of the events that are of most interest to them, whether it be votes, committee activities, or some other point of interest. Librarians, on the other hand, think of events in the context of their documentary evidence, whether physical or digital, because their descriptive traditions are based on documents.  In a very real sense, we see our mission as bringing those two points of view closer together, by using the power of linking to make it possible for members of each audience to find what they need and relate the available resources together in various ways.

Sources
●	Useful ontologies and standards
○	Wolf, Misha, and Charles Wicksteed. “Date and Time Formats”. Online at http://www.w3.org/TR/NOTE-datetime
○	Halpin, Harry et al., “Representing vCard Objects in RDF”.  Online at http://www.w3.org/Submission/vcard-rdf/ .
○	Raimond, Yves, and Samer Abdallah. “The Events Ontology”. Online at http://motools.sourceforge.net/event/event.html 
○	Raimond, Yves, and Samer Abdallah.  “The Timeline Ontology”.  Online at http://motools.sourceforge.net/timeline/timeline.html 
●	Approaches to Legislative Data
○	Boer, Winkels, van Engers, and De Maat, “A Content Management System based on an Event-based Model of Version Management Information in Legislation”, available at http://liicr.nl/IkuT6c .

People and Organizations in a Legislative Data Model
Thomas R. Bruce, Legal Information Institute (tom@liicornell.org)
Diane Hillmann, Metadata Management Associates (metadata.maven@gmail.com)
John Joergensen, Rutgers University School of Law (jjoerg41@gmail.com)
Jon Phipps, Metadata Management Associates (jonphipps@gmail.com)

DRAFT OF 2012-05-01 - NOT FOR CIRCULATION
Introduction
In today’s world, there is no need to settle on a single answer to the question of what standard to reference in describing people and organizations. The current environment, where the speed of change can be daunting, demands strategies that start with descriptive properties that meet local needs as expressed in use cases. Taking the further step of mapping these known needs to a variety of existing standards best provides both local flexibility and interoperability with the wider world. 

In the world of Web standards, most considerations of appropriate people and organization descriptions begin with the FOAF vocabulary (http://xmlns.com/foaf/spec/), developed in 2000 as ‘Friend of a Friend’ and now used extensively on the web to describe people, groups, and organizations. FOAF is an RDF-based specification, and as such is poised to gain further in importance as the ideas behind Linked Data gain traction and more widespread implementation. FOAF is quite simple on its face, but as an RDF vocabulary it is easily extended to meet needs for richer and more complex information.  FOAF is now in a stable state, and its developers have recently entered into an agreement with the Dublin Core Metadata Initiative (DCMI), to provide improved persistence and sustainability for the website and the standard, as it moves into the future beyond its modest roots. That is a good match, given that the DCMI organization has provided a stable and persistent home for what may be the most widely used vocabulary on the web: Dublin Core.  

More recent standards efforts are emerging and deserve attention as well. Several that address the building of descriptions for people and organizations are in working draft at the World Wide Web Consortium (W3C).  Although still in draft status, they offer several alternative methods for description that could be very useful in the current context. Because organizations in these standards are declared as subclasses of foaf:agent, the close association with the FOAF standard is built in. 

What may be most useful about FOAF -- and more recent standards that seek to extend it --  is both its simple and unambiguous method of providing identification of people and groups, as well as its recommendations for minting URIs for significant information about the person or group identified. 

But despite its wide adoption, there are some limitations to basic FOAF that weigh on any assessment of its capacity to describe the diversity of people and organizations involved in the legislative process.  Critically, FOAF lacks a method for assigning a temporal dimension to roles, membership, or affiliations.  That temporal requirement is essential to any model used for describing relationships between legislation, legislators, and legislative groups or organizations, both retrospectively and prospectively.  The emerging W3C standard for modeling governmental organizational structures (which includes the modeling descriptions of people and organizations mentioned above),  contemplates extensions to FOAF designed to address this limitation.  Another emerging standard, the Society of American Archivists’ EAC-CPF, also includes provisions for temporal metadata, and seems to take a very broad view of what it models, making it a standard worth watching.

Standards encountered in libraries

One question that always arises in discussing standards like FOAF in a library context is the prevalence of the MARC model in most discussions of description of people and organizations. Traditionally, libraries have used MARC name authority records as the basis for uniquely identifying people and organizations, providing text strings for both identification and display. Similar functionality has been attempted with the recent additions to the Library of Congress’s Metadata Authority Description Schema (MADS). MADS was originally developed as an XML expression of the traditional MARC authority data. Now, with the arrival of a public draft standard, focus is shifting toward an RDF expression to provide a path for migration of MADS data into the Semantic Web environment.  

MADS, like its parent the USMARC Authority Format, focuses on preferred names for people and organizations, including variants, rather than on describing the person or organization more fully. As such it provides a useful ‘hook’ into library data referencing the person or organization, but is not really designed to accommodate the broader uses required for this project. 

There is also a question about where this new RDF pathway for MADS might go, given the traditional boundaries of the MARC name authority world. In that tradition, names are added to the distributed file based on ‘literary warrant’, requiring that there be an object of descriptive interest which is by or about the person or organization that is a candidate for inclusion.  That is not a particularly useful basis for describing legislators, hearing witnesses, or others who have not written books or been the subject of them. Control of names and name variants will surely be necessary in the new web environment, and the extensive data and experience with the inherent problems of change in names will be essential, but not sufficient, for more widely-scoped projects like this one.

What to model: People and Organizations 	
Legislatures create myriad documents that must be identified and related to one another. For each of those documents, there are people and organizations fulfilling a variety of roles in the events the documents narrate, the creation of the documents themselves, or the endorsement  of their conclusions. Those people and organizations include not only legislators and the various committees and other sub-organizations of the legislature, but also the executive branch which, primarily through the President, exercises the final steps in the legislative process, as well as bearing responsibility for implementation. Finally, there are other parties, often outside government, who are involved in the legislative process as hearing witnesses or authors of committee prints, whose identity and organizational affiliations are essential to full description and interpretation.

When discussing organizations, it is sometimes useful to distinguish between more and less formal groupings.  In the FOAF specification, that is conceptualized in the categories “group” and “organisation”  Generally, FOAF imagines that an “organisation” is a more formalized entity with fairly well defined memberships and descriptions, whereas a “group” is a more informal concept, intended to capture collections of agents where a strict specification of membership may be problematic, or impossible.  In practice, the distinction tends to be a very blurry one, and seems to be a species of summary calculation done on a number of dimensions:

●	the temporal stability of the group itself, for example “the people waiting for the 3 o’clock bus”, as opposed to “the House Judiciary Committee”;
●	the temporal stability of the group’s membership, which may be relatively fixed or constantly churning ( “the Supreme Court” versus “the people waiting in the lobby” )
●	the existence of institutional trappings such as office locations, meeting rooms and websites;
●	the level of “institutionalization” or “officialness”.  In the case of government institutions in any branch, that may often rest on some legal authority that establishes the group and describes its scope of operations (as with the Federal courts). It may also take the form of a single, very narrow capability (as when an agency is said to have “gift authority”).  Finally, it may also be established through tradition.  For example, the Congressional Black Caucus has existed for over 40 years, and occupies offices in the Longworth House Office Building, but has no formal existence in law.

Because that distinction is so blurry, we have chosen to treat all organizations similarly, using common properties that allow users to determine how official the organization is by ‘following their noses’.  Thus, users of the model are free to draw their own conclusions about the “officialness” of any collection of people, although a statutory or constitutional mandate might well be interpreted as dispositive.  
Scope and data policy

In this paper, we discuss various categories of people and organizations that contribute to legislative documents. Each category carries some important distinctions, and contains challenges in determining the requirements for useful descriptions and relationships. The broad categories are:
●	legislative branch, 
●	executive branch, 
●	the Office of the President, 
●	the Office of the Vice President
●	the judicial branch, and 
●	non-governmental entities. 

Although there is, inevitably, overlap and ambiguity involved in this categorization, each of these categories has a distinct if sometimes distant role with respect to the legislative process, with different levels of detail needed in their descriptions.  We will then discuss the commonalities and distinctions between them, with recommendations on the approaches that should be taken to these entities. 

Despite our preference for data maintained authoritatively by the government entities themselves, incomplete and incompletely structured information is problematic, particularly for executive branch agencies. Currently, no definitive list of US governmental organizations exists, although the General Services Administration is said to be compiling one.  There are several incomplete attempts, most notably  the US Government Manual, which many believe to be comprehensive, although it is not.  

There is also a policy question to consider: who should build bridges between information collections that exist in separate administrative units or even in separate branches of government?  For example, in a later section, we consider generally the relationship -- or more properly, the several relationships -- between legislative process and the judiciary.  It is clear that judicial nominations are an important part of the legislature’s activities and need to be modeled as part of legislative process.  But in the case of Supreme Court cases related to legislation, who should build the model that relates them?  Arguably, the relationship between statutes and the court cases that cite and interpret them lies outside the strict purview of a model such as ours. The responsibility for modeling the citation relationship could equally well lie with the Court or with the Congress. 

The Legislative Branch: People and Organizations
Of all the categories of people and organizations to be addressed, the legislative branch is the primary focus for our efforts.  The people and organizations that make up the Congress each have several layers to them.
The Legislature: People

Legislators fall, of course, into one of two main categories: Congressmen and Senators.  Describing these people adequately requires the inclusion of basic categories of information which factor significantly in the legislative process, and are often the basis for searching and sorting.  Those items include the state (Senators) or district represented (House members), party affiliation, membership in committees and caucuses, as well as leadership positions in the chamber, plus committees or caucus in which they maintain membership. Most of these elements change over time, and those changes need to be reflected in descriptions of legislators.

Examples of time-based change abound. For instance, a Congressman may enter the House as a member of one party, but change party affiliation along the way.  Even more common are changes in committee assignments, assumption of leadership positions and chairmanships, and jumps from the House to the Senate.  Therefore, any data model that seeks to address the role of legislators in the legislative process needs to accommodate repeatable, date-sensitive data structures for all this information.  In that respect, our model follows some aspects of the evolving W3C standards, while diverging in some specific areas of modeling roles, memberships and affiliations.  For example, we agree with its use of temporal concepts in modeling memberships (which have duration), but disagree with the manner in which it represents continuous membership as an aggregation of “mini-memberships” that are tied to specific roles.  

We recognize that much of the work of describing legislators has already been completed in the form of the Biographical Directory of the United States Congress.  That resource already includes essential elements of an identifier scheme for all past and present members of Congress, as well as a unique alphanumeric identifier for each individual listed. The identifiers used in the Directory provide simple ways to link to external biographical information maintained by the members themselves as well as resources such as Wikipedia and the New York Times.
The Legislature: Organizations and Groups

Congressional groupings and organizations need to be identified and described at a number of levels. At the topmost formal level are the House of Representatives and Senate;  below that there are several complex layers. All House and Senate members hold formal memberships in a variety of committees and sub-committees.  Each of these committees, moreover, has a well-defined charge, laying out its subject matter jurisdiction and ancillary responsibilities. These charges and the committee membership may change over time, and various committees will come into, and go out of existence, requiring durational and change properties to be included in their descriptions.   

The relationship between legislators and committees are treated reciprocally in the model, allowing users to start with either and examine relationships from the organizational or individual viewpoint. Relationships with caucuses and political parties are described in a similar manner, as are the rarer but important sponsorship relationships between legislators and others, such as the sponsorship of young people to the service academies.

Caucus membership has some special challenges for descriptive practice.  Although there are several caucuses which have a long history and a formalized structure, they are all, by definition, ad hoc.  Similarly, although membership criteria for a caucus may be fairly well defined, it is not necessarily so. It is subject to change, and always voluntary.  Nonetheless, they are an important aspect of the functioning of Congress.
	
The one exception to the assumption of informality is the party caucuses.  Although the general strategy for description of other caucuses would apply well to a party caucus, the party caucuses themselves are more formal than other caucuses, written into the very structure of Congress and essential to its functions.  Also, membership, although voluntary, is far more structured than the rest of the groups that can be categorized as caucuses.

The information that pertains to a committee’s identifiers is available in the Legislative Calendars for each chamber and each committee (to the extent that such calendars are produced by each committee).  Unfortunately this information is only available in a page-description format,  and not in any encoded form designed for digital access. The Legislative Calendars are a prime candidate for such treatment since they consistently include listings of existing committees and their membership, and, unlike some other documents, they are produced by mandate.

Finally, some mention needs to be made of the myriad staffers and aides who do much of the daily work of Congress.  These people fall into one of three basic categories: staffers of a legislator, staffers of a committee, employees of a congressional support organization.  Such individuals could certainly be described using the same strategy, but the determination of whether or not to include them is primarily one of policy. 

Currently the most definitive listing of legislative employee of Congress is the GPO’s Congressional Directory.  However, like the Legislative Calendars, the directory is not currently structured in a manner that would lend it itself to machine readable access, although certainly there are many examples of directories in other parts of the government that have made that leap successfully.
The Executive Branch: People and Organizations
For every law, there is a President who must sign, veto, or report, as well as various executive branch agencies charged with regularly submitting documentation and reports to Congress. Similarly, for most laws passed, there will be an executive branch agency that will be given the responsibility for applying the law.  Insofar as these responsibilities emanate from enabling law and date, they can be included in descriptions of agencies. 

The President is, of course, a key player in the legislative process.  The endorsement or veto of a bill is the last step in the process of creating a law.  Similarly, the recent phenomenon of the presidential signing statement also involves a document coming from the President which pertains directly to new legislation.  While the history of a bill may be considered complete with a record that it was signed on a given date, the identity of the President who did the signing is important as well, though the date of signing makes the identity of a statute’s signer easy to infer.  

In addition to these documents, there are any number of communications between Congress and the President that take place while legislation is being created, or are submitted to Congress for some other reason.  The most significant of these would be:

●	a Presidential request for legislation;
●	the President’s official State of the Union address;
●	submission of various reports to Congress as mandated by statute;
●	the transmission of treaties for ratification by the Senate.

Finally, as chief executive, Presidents do have a degree of quasi-legislative power that is all their own, in the form of Executive Orders, or even recess appointments, which are compiled in the first volume of the CFR as well as in the Statutes at Large. Traditional cataloging practice separates official activities (such as reports mandated by Congress) from those with a more personal stamp, and that separation seems useful in this model as well (though the boundary might be different). Nothing about of these activities, however, requires that the designation and identification of the President as a person or as an office change very much.  

The Office of the Vice President

The Office of the Vice President is not one that would naturally pop out as needing special treatment.  Indeed, most people pay it little heed at all.  In the context of legislation, however, the office occupies a unique place that needs to be accommodated in the model.  That is due to the fact that the Vice President is the presiding officer of the Senate, but is not himself a legislator.  As such, the Vice Presidents can and will be included in the floor debates in Congress, and occasionally cast a deciding vote on controversial legislation. Because of this, the Office of Vice President needs to be modeled in such a way that his activities on the floor of the Senate and his occasional votes can be recorded in a coherent manner.  

Executive Branch Agencies and Departments

Unlike the President or Vice President, who have personal roles in the legislative process, executive branch agencies typically appear in an institutional capacity.  The significant exception to this occurs when individuals representing an executive branch agency testify before Congressional committees.  Aside from testimony (to be discussed below), agency participation in legislation occurs:

●	Through submission of mandated and non-mandated reports (committee prints) to Congress;
●	As subjects of legislation, in that they will be created or designated to implement laws being passed;
●	As creators of regulations that serve to implement legislation that has been passed, and as reporters of that activity to the legislature.

Mandated reports will typically include a reference to the law mandating the submission, facilitating the inclusion of an identifier establishing this relationship.  In addition, the legislative calendars of the chamber or committee designated to receive the document will have entries noting the document’s reception, which will include the date, department, mandating legislation, and subject.  These data items are not currently in any encoded form enabling digital access and separate identifier assignment.  Non-mandated reports come in the form of committee prints submitted to a committee considering new legislation or conducting an investigation.  For digital formats, GPO and/or LOC records for the document are easily linked; print versions are less so but are still accommodated in the model.

The one significant exception to the non-personal nature of executive branch related legislative information is the nomination process.  U.S. Const. Art. II sect. 2 mandates that Ambassadors and public officers of the United States be nominated by the President, with the advice and consent of the Senate.  The “public officers” category, in particular, includes a surprisingly large number of Federal officials.  Although the vast majority (even in today’s uncooperative atmosphere) are handled in a routine manner, they are all are approved by a Senate committee on appointments, and are subject to a vote.

Given the large numbers of Federal officers who are subject to Senate approval, and the relative national importance of most individual appointments, identities of nominees are accommodated in the data model. Most of the individuals who are subject to the nomination process will not be subject to, or involved in the legislative process again.  Given that there is little possibility of a definitive pre-existing repository of information on these individuals, the same strategy as is used for identifying hearing witnesses should apply.  
The Judiciary	 	 	 	
The judiciary is involved in the legislative process in two capacities: as a subject and arbiter. The judiciary is a subject of legislation in two ways, both of which are significant for legislation. First, all federal courts, save the Supreme Court are created by statute, as authorized in U.S. Const. Art. I Section 8. One of the larger sections of the U.S. Code is in fact, Title 42, The Judiciary. Next, pursuant to U.S. Const. Art. II Sect. 2, all nominations by the President for new members of the judiciary must be approved with the advice and consent of the Senate. Given the size of the judiciary, there is a considerable amount of legislative time and documentation devoted to the nomination process.
Nominations

Judicial nominations are similar to nominations to executive office, except that the relationship to the office nominated is judicial rather than executive.  The nomination process documents themselves should also supply the necessary additional information that would be useful for the identification of judicial nominees and members of the judiciary, as is the case with executive branch nominees.

Finally, a word needs to be said about the judiciary in its role as adjudicator.  It is, of course, elementary to state that the major role of the federal courts is to adjudicate disputes that arise under U.S. legislation.  Given this, the idea that a model of legislative information must include references to all federal court cases that interpret those laws would seem to be a step, or several steps, further than we should go.  There are, however, several reasonable and natural divisions of court cases that may allow intelligent decisions about what to include and what to disregard.  

On the one hand, there is the issue of court level. The judgments of the U.S. Supreme Court are the final word on the interpretation and constitutionality of legislation, and so are more significant to a definitive understanding of the meaning of our statutes.  Furthermore, the certiorari-granting process used by the Supreme Court to select the cases it will hear explicitly limits consideration to significant cases where a definitive interpretation by the court is necessary.  It is therefore entirely reasonable and useful to limit consideration to Supreme Court decisions, albeit with the understanding that inclusion could be extended to lower courts if, and when resources and a need were present.

Next is the issue of the type of judgment being asked for in a court case.  In the majority of cases that the Supreme Court hears concerning legislation, the question at bar is how that law should be interpreted.  That question may involve issues of constitutionality or it may not.  Even when it does, however, the overall constitutionality of the statute is not in question, only a particular interpretation of it.  Put another way, the majority of cases do not question the legitimacy of a law, only the details of its meaning: what things or behaviors it includes, for example. 

A small number of cases actually do question the constitutionality, and hence the legitimacy, of a piece of legislation.  Of those cases, a small percentage of them decide that a law is, in fact, unconstitutional and invalid.  These cases, though small in number, are of great importance to the legislative process, and essential in any accurate model of American legislation.  Should these  court cases be excluded from the model, it would allow invalid and unenforceable laws to remain not only as discoverable (which they always should be), but to appear as enforceable.  

We have previously stressed (in the context of legislative votes, etc.) that a model of legislation should avoid the interpretive and stick to identification and description.  In this case, the same principle applies.  Identification of a significant judicial decision, determined by explicit reference by the court via citation, is a fact that is important to the understanding of the law in question. Moreover, it is one easily found and extracted by automated means. The interpretation given by the court is something on which the mere act of linking is silent.
Non-Governmental People and Organizations
In committee prints and hearings, witnesses and organizations from the private sector play a major role. They are one of the most important sources of information used by Congress when formulating policy and legislation. For researchers, these people, and their organizational affiliations, are important.  

Additional detail about the various connections between people and the organizations involved in the legislative process is certainly available, but resources to include them may not exist. That said, the Linked Data strategy is inherently iterative, and as comfort levels with the aggregation of external data sources increase, such information may well be available without direct expenditure of scarce resources.

More detail on when and how external data sources could be mined for information on non-legislators is included in the previous paper “Design issues for a legislative data model” (https://docs.google.com/document/d/127KYbiX1gaxibgqCwgnpUlj43FJzFXgYXNp6WDN7n_g/)

Sources:

●	People and organizations
○	W3C proposed organizations standard: http://www.w3.org/2011/gld/wiki/Organizational_Structures
●	Useful third-party datasets
○	New York Times Linked Open Data effort, described at http://data.nytimes.com/
○	Freebase: http://wiki.freebase.com/wiki/Main_Page
○	dbPedia: http://dbpedia.org/About
●	Supreme Court Rules: http://www.supremecourt.gov/ctrules/ctrules.aspx
●	Friend of a Friend (FOAF): http://xmlns.com/foaf/0.1/
●	Resource Description Standards
○	USMARC: http://www.loc.gov/marc/
○	MODS: http://www.loc.gov/standards/mods/
○	MADS: http://www.loc.gov/standards/mads/
○	EAC-CPF: http://eac.staatsbibliothek-berlin.de/ 
●	Dublin Core Metadata Standard:  http://www.dublincore.org

The materials in this section are drafts of white papers we created and submitted as we were making our way through the model. They are all incomplete, at least in the sense that we had not finished thinking through the entire corpus at the time of initial release to the client.  It’s possible that they contain errors, and they almost certainly contain gaps that we later filled during our more formal checks on the model, in drafting the final prose that appears elsewhere in this document, or in preparing visual documentation.  They are, however, a valuable record of what we thought as we were making our way through the weeds.  This particular set contains work on specific corpora of interest: 
	•	Bills and resolutions
	•	The Congressional Record
	•	Committee documents
	•	Post-passage materials

Design issues for a legislative data model

Thomas R. Bruce, Legal Information Institute, Cornell Law School
Diane Hillmann, Metadata Management Associates
John Joergensen, Rutgers-Camden Law School
Jon Phipps, Metadata Management Associates
Contents
●	The context of the model
●	Data and policy issues
○	Data formats and delivery systems
○	Licensing
○	Not-currently-linkable data
●	Namespaces and properties
●	Events, legislative process, and workflow
●	Use of vocabularies in descriptions
●	A metadata bestiary
○	People and organizations
○	Dates and provenance
○	Geographic data
○	Identifiers
○	Subjects
○	Granularity
○	Versions
○	Descriptions

About this document
This document considers a variety of issues encountered while creating a legislative metadata model for bills and resolutions.  Because bills and resolutions are central to all of the corpora within the project scope, we believe we have encountered (and have at least sketched solutions for) most of the more difficult design issues involved in the project as a whole.  We would not, however, claim that this document or any aspect of the current model is complete.  There is much more to be done, and no doubt many more problems to solve as each new corpus comes into focus.

Some of the issues and aspects raised here (notably Events, People, and Organizations) will be much more thoroughly explored in future documents.  Some (Identifiers) have already been considered at length in other papers, but have not yet received a concrete set of recommendations.  For the most part, concrete recommendations await thorough examination of all the corpora involved in the project; the data-modeling process is characterized by a need to look at everything before much can be said about anything.  Nevertheless, we consider this to be a good running start.

The model itself, with worked examples, is presented in the “Legislative Properties and Classes” spreadsheet, along with illustrative examples.  That spreadsheet (along with a second spreadsheet providing supporting material and notes) is described in the “Field Guide” that accompanies this document. Visual documentation will follow in a later package.

Throughout this document, we’ve used the term “data” somewhat loosely to include both legislative metadata and, occasionally, the data contained in the corpora themselves.  This can, we admit, get a little confusing when considering items like the Congressional Record, whose substantive data is sometimes metadata from other parts of the forest.  We think the meaning will be clear in most contexts, but we’ll be grateful to have any lapses pointed out to us.
The context of the model

The design of our legislative metadata model has been driven by use cases we have developed and collated.  We have also tried to account for other environmental factors in the model’s design.  Most of those come under the general heading of “future-proofing”.  We have tried to identify important trends in the administrative and technological environment and ensure that the model will stand up to them well. The most significant of these are:

●	The effects of exposure of legislative metadata  in a Linked Open Data environment.
●	Curation issues that arise from consuming data in a Linked Open Data environment.
●	The availability of data in forms other than those traditionally made available through the paper and electronic documentary record.
●	A developing push toward data-sharing within the legislative branch, accelerated by increasingly severe resource constraints.

So far as we have been able, we’ve chosen strategies that reflect the best understanding of what would be most conformant, most flexible, and easiest to implement, in roughly that order. In some cases, it is not so easy to know what will be best or how long it will remain so. The speed at which innovation and shifts in understanding happen in this realm make flexibility paramount.

This paper offers only brief treatment of these issues as they pertain to our work product at this writing. Most will be treated in more depth in future pieces.

Data and policy issues

Modeling issues fall into two rough categories: data issues and policy issues.  Data issues involve questions about which information should be contained in a property or class.  They are related to the design of the data model itself. Policy issues, by contrast, involve decisions about how the model is to be populated: which sources are preferable, stable, reliable. A related policy issue might be whether to use a controlled vocabulary as content, and if so, which one.  

Data issues often rely on an understanding of appropriate and ‘standard’ ways to build, expose, and maintain data from distributed providers, especially when that data is intended to be distributed to diverse applications for diverse purposes. Policy issues apply to decisions that rely on understanding of resource realities (and limitations), existing data and its fitness for the system, as well as short-term and long-term goals. It is important to choose those alternatives that will provide the most bang for the buck in the short term, while offering a useful improvement and extension strategy for the longer term. 

We have already discussed data and policy issues in papers developed for this project. For example , the paper on identifiers discussed the ‘why’ of standard, web-friendly identifiers as well as a bit of the ‘how’ they might be built using existing identifiers.  We have more work on recommendations ahead of us, but are holding back on much of it until we have thoroughly modeled all of the different corpora involved.  Determinations about how the client proceeds to implement some or all of those recommendations are, of course, well beyond our brief.  We do, however, offer some opinions about policies and mechanisms that might inform those decisions.
Data formats and delivery systems
Our overall perspective on the data is that of a document-based model that has been linked to a model of legislative process at certain significant points.  It is important to remember that the documentary record is itself a data model -- an old and somewhat lumpy one. It is already obsolescent in some areas and for some purposes.  For example, the voting data presented in tabular form in the Congressional Record exists also as electronic databases held in the Congress itself.  For many purposes, the electronic databases are far more useful than their fixed representation on electronic paper.  In general, we believe that the client should look carefully at the documentary record for other examples of places where legislative information might better be published as data in parallel with its encapsulation in published, print-like documents -- or where it is already being published by others within the legislative branch, and can be linked.
Licensing and other restrictions
In general, US Government works are not copyrightable, and so we have not worried too much about metadata needed to describe licensing restrictions on the data itself.  It is possible that some data (the summaries associated with bills come to mind) may carry licensing or usage restrictions. It would be simple enough to extend the model to accommodate these, possibly using Creative Commons licenses.  

We have made no effort to understand or model any formal or unstated systems of access control, restrictions on viewing, or security that may relate to legislative data regarded as sensitive by various parties to the process.
Future data
Where possible, we have made provisions for data that is not within our brief, but is closely related to it and may well come into scope in the foreseeable future.  That data falls into three categories:

●	Data that exists as data, but is not published as Linked Data.  Tables I, II, III, and IV of the United States Code -- but especially Table III, which tracks codification decisions -- are probably the leading example of this that we have encountered.  The Legal Information Institute has already converted Table III to RDF triples, and will be offering a Linked Data version of Table III within the month, and we understand that the Office of the Law Revision Counsel is interested in doing the same.
●	Data that exists within documents, and could be extracted by automated means. The most interesting examples found in our collection of use cases had to do with geographical information.  The extraction of place names and locations from (e.g.) bill text is well within the capabilities of current natural-language processing technologies; those place names can be associated with geodata to allow new queries and presentations (such as maps).
●	Data that exists within documents whose architecture will need to be rethought before extraction is possible.  That, unfortunately, is the case with the Congressional Record.  It is rich in data that might be of great interest. In order to make that data useful, however, the Congressional Record would need first to be published in a structured format with identifiers in place for many of the substructures within it, and subsequently disaggregated and stored as a collection of fine-grained data items that could be recombined to create a number of different products and publications.  We imagine that this will take place in the near future, but it has not yet.  Another common example is the absence of sub-document structures and identifiers within XML-encoded bills, which might -- in contrast to a whole-document approach -- provide more accurate targets for subject-matter classification, geodata-referencing, and other processes supporting usefully faceted searches.

Namespaces and properties

Choices related to namespaces and properties provide good examples of the data and policy issues discussed earlier. Not too long ago, re-used properties in well-managed schemas were considered the best choice by most sophisticated thinkers in the field,  because that choice left the responsibility for management and maintenance costs in the hands of someone else. However, opinion is now shifting, as designers have come to more fully understand how much is risked in that approach, and how difficult it can be to maintain the coherence of a schema under those circumstances.  Attention is now shifting from strategies of re-use toward mapping strategies.  Mapping strategies offer a way to reap the benefits of re-use without the disadvantages. Thus, building a model that embodies specialized understanding but which remains mindful of relationships to general, standardized properties keeps the mapping option open.  Our master list of properties and classes reflects the recommended new properties in a manner that makes mappings to Dublin Core (and potentially MARC21 and RDA) relatively easy. Also on the master list, under the new, proposed ‘legis’ namespace, are properties and/or subproperties that remain to be declared and published but are intended to provide the basis for increased functionality, while supporting extension as needed.

In this model we have chosen, when defining new property names under the ‘legis’ namespace, to use the ‘is/has’ convention to distinguish those properties which describe the resource itself from those included to link to other resources. This choice makes sense from the point of the creators of descriptions, but does not tie applications to use the same construction for human labels. 
Clarifying events, legislative process, and documentary workflow

Existing ways of modeling -- or even discussing -- what happens to a measure as it makes its way through Congress are characterized by some confusion between closely connected approaches that are, nevertheless, subtly different.  Broadly, those approaches might be divided into three types:

●	A process-aware model, in which documents are seen as artifacts produced by particular actions or processes within the legislature.  (On that view, a “measure” is something of an abstraction that groups a series of bill or resolution texts created during the legislative process,  as well as related documentary artifacts such as amendments, signing statements, and so on).  Such a model might be one of two types:
○	A model that identifies major stages and events of interest to both legislative insiders and the public.  Examples might include the THOMAS vocabulary for bill stages, or the steps represented in a simplified infographic created for public education.
○	Finer-grained, events-based models that divide the legislative process into minutely detailed steps needed by particular communities, for example those interested in the activities of Congressional committees.

●	A “legislative process” model containing parliamentary process detail. From a distance, this approach looks a lot like a fine-grained version of the process-aware model just mentioned.  But it is far more detailed in its treatment of parliamentary procedure, rules for debate, and other turns and twists primarily of short-term interest to Congressional insiders. That is the type of story told, for example, by the CRS report on resolving differences between House and Senate bill versions. Pieces of such an approach show up in the bill-status attribute used by the House for its XML schemas and DTDs, which contains such status indicators as “held-at-desk-House” and “reengrossed-amendment-Senate”.

●	A “workflow” model, which focuses on the actual flow, versioning, and exchange of documents or other work product.  Such a document-centric model has obvious intersections (and points of confusion) with a “process-aware” model, in which major legislative events tend to produce important versions of documents.  It also intersects the “legislative process” model, in which certain parliamentary actions (such as amendment) provoke the production of particular documents.

Most of the existing vocabularies in use  -- which tend to use words like “status” or “stage” to describe their components -- use more than one of these approaches at the same time.  That leads to some subtle confusion. Each of the approaches views the world a little differently, and mixing them leads to some inconsistencies.  An illustration  of such a mixed model is provided by the “bill stage” vocabulary from GPO, which contains aspects of the process-aware model (“Considered and Passed House”), the legislative process model (“Additional Sponsors House”), and the workflow model (“Amendment Ordered to be Printed Senate”) all at once.

We have taken a process-aware approach to create the spine of our model, for several reasons. We have tried to map as much useful detail as possible, while avoiding the many pitfalls inherent in trying to over-think and over-model. An excessively detailed approach focussed on particular parts of the process tends to skew the usefulness of the resulting model in favor of a limited number of specialized users. Also, excessive detail in any or all aspects of such a system inevitably results in a model too cumbersome to be used or maintained:
●	Too-fine distinctions between identifiers will become confused and misapplied, both by maintainers and users.
●	Many identifiers thought useful will end up being dismissed as over-specific, leading to inefficiency and eventually, further confusion.
●	The level of technical expertise required to implement and maintain a too-highly-detailed model will become limited to far too few individuals to guarantee its proper use.
●	Finally, the time and expense involved in too great a level of detail will, in the end, render it of limited usefulness.

Instead, we have tried to provide a model that is “just right” in its level of detail, while acknowledging that our decisions about the various trade-offs involved in such an approach  would not be everyone’s. The model has been created with an inherent extensibility that ensures that others may later add any level of specialized detail that they need.  

Beyond avoiding problems with excessive detail, such an approach has a few virtues:

●	Conformance with (and respect for) existing systems.  It will probably come as no surprise that most of the existing systems that track legislative information agree as to the major features of the process.  So do most of the helpful narratives -- such as HOLAM and a wide array of CRS reports -- that inform people about the process.  With such obvious landmarks in common view, it would be a mistake to suggest a map that ignores the landmarks that everyone sees and agrees on.
●	Interoperability.  Using a coarser-grained, process-aware model requires a willingness to compromise a level of specialized meaning that might be achieved through the use of more specialized objects, relationships, and identifiers at every stage of the process.  However, the compromises are not so great. The interoperability that results from making use of existing systems and standards more than compensates for them.  We believe that most of those who currently track legislative information will be able to find obvious points of correspondence and linkage for their own systems.
●	Clarity.  Our process-aware approach provides a means of clearly tying the document model to the process model without creating confusion. Our bifurcated audience looks at events in quite different ways.  Researchers see events in the context of the legislative process, and focus on the aspects of the events that are of most interest to them, whether it be votes, committee activities, or some other point of interest. Librarians, on the other hand, think of events in the context of their documentary evidence, whether physical or digital, because their descriptive traditions are based on documents.  In a very real sense, we see our mission as bringing those two points of view closer together, by using the power of linking to make it possible for members of each audience to find what they need and relate the available resources together in various ways.

Finally, the model is, as of this writing, a very flat one.  There is little class hierarchy, nor do we have complicated systems of subproperties.  In general, we use a lot of very specific properties; for example, we’ve provided “House” and “Senate” versions of identical properties.  That approach is intended to aid identification and use (especially by outside parties), and tends to work better in a Linked Data context.  It is also an acknowledgement that differences of policy and practice may exist between the two chambers.  Over time, and with experience gained as we continue building the model, we will resolve some of this detail into a model with more levels to its structure.

People and organizations

The Congress already manages and maintains a great deal of information -- both functional and historical --  about its members, its committees, and other entities.  No doubt there are many agreements that remain to be made within the legislative branch about use of this information in different contexts.  That said, we feel that, if only for resource scarcity reasons, we should avoid adding new data structures for data already being created and maintained.

Relevant information for persons and organizations outside the Congress (such as witnesses at Congressional hearings)  is provided by a great variety of sources, with no obvious strategies for choosing or using. That is the basic conundrum posed by an open web of data that we could, in theory, employ successfully with remarkably small investment of effort. The technical ‘how’ of such a strategy is not that difficult. Organizations like the New York Times have been breaking useful ground in this area . However, policy questions about which sources should be used and which should not are more complicated. Particularly in the government domain, such questions require careful attention to the implications inherent in the various alternatives.

The Library of Congress already uses authority files to manage the identities of some non-legislative actors.  However, inclusion of particular names in those files depends on the notion of “literary warrant”.  Thus, entries, or identifiers, for those who have neither written a book nor been the subject of one can rarely be found in traditional library authority files like the Library of Congress Name Authority File (LCNAF). Hearing witnesses -- probably the largest group of non-legislators for which standard identifiers would be needed -- are more likely to be present in media sources such as newspapers, or perhaps in general reference works. The more prominent and stable of these sources should be evaluated for their suitability for use within legislative data files. Only when no other appropriate source exists should the client consider providing the data files themselves.  Should the client choose to do so, their approach should be based on information provided in the documents they are describing, using a standard set of properties such as those we suggest later, with identifiers managed internally.

Questions about trust surround all these discussions. Traditional library data creation does not trust much, but verifies often. The Semantic Web will require a somewhat looser approach. The LCNAF files are built and maintained on a distributed model where membership in the group of trusted maintainers is tightly controlled, and the costs are borne by the library community at large.  A world that is open to non-library organizations and agencies will rely more on what we might term a “best evidence” or “best quality” policy.  Such a policy would dictate use of the best source available; experience shows that that is usually (but not always) the source that is closest to the point of data creation.  In that respect, provided it does a decent job, the Congress itself is a better source for information on legislators than the Library of Congress, and the responsible news media should be employed as sources of reusable information on individuals who come to their attention.  

Beta Labs

We are in a transitional period, and these new approaches are not yet institutionalized. Recent experience at the LII shows that the price of relying on third-party Linked Data sources with differing priorities is that applications that are both authoritative and thorough in their coverage -- particularly in the realm of government data --  can be hard to build.  That happens in part because the Semantic Web is relatively new. It is also true that  -- as our section on “future data” above hints strongly -- the “authoritative” sources are not yet entirely comfortable with the technology.  And in any event, aggregation of data sources that were not designed with aggregation in mind can be quite difficult.  

That said, there is much to be gained by building on work done by others, and no good way to determine a realistic long-term approach without conducting public experiments that lead to informed policymaking.  Many organizations now experiment with new services under some sort of alternate corporate identity, either branding them as “beta” services or putting them slightly to the side under rubrics like “Google Labs”.  Such methods would provide a safe means  to experiment with new approaches that do not yet meet core requirements for coverage and accuracy, including many that would rely on third-party data providers.

A few specifics about collections of people
		
The legislative process involves many groups, organizations, and affiliations that vary greatly in their stability.  Most models for organizations and groups -- notably FOAF, but also the organization ontologies built by Epimorphics and Fujitsu -- make some distinction between clusters of people based on the stability of the cluster, dividing them into institutionalized “organizations” and ad-hoc “groups” with no bright line separating the two.  There is a spectrum that ranges from the completely ad-hoc to the fully institutionalized, and sometimes it is hard to know where  a particular cluster falls.   In the Congressional world, we might think about standing Congressional committees as being at the “fully institutionalized” end, Congressional caucuses being somewhere in the middle, and the churning group of sponsors associated with a particular bill at the other end.  After some trial and error, we have decided that we don’t really need the distinction.  Associating timespans with membership and with occupancy of particular roles eliminates any need to distinguish groups from organizations.  Eventually, we may need to add a typology of groups that somehow describes their level of institutional stability, but that would speak more to the status of the group with respect to Congress than to the stability of its membership.

Curiously, none of the ontologies mentioned above make any provision for assigning timespans to membership in a group; we have created “Sponsorship” and “Membership” entities in order to accommodate those very necessary ideas.  A further modeling problem is presented by continuous membership (say in a Congressional committee) where the member intermittently holds one or more offices (such as alternating, for some of the time, between committee chairmanship and the position of ranking minority member).

Dates and provenance

Nowadays, metadata models must be designed for exposure and recombinance. Exposure occurs as the metadata is published and repurposed outside its original environment of use -- and probably outside of its original institutional environment as well.  Recombinance occurs when metadata is combined with different sets of metadata drawn from disparate sources.  Most exposures and recombinant uses cannot be anticipated.  In such a world, it’s important that people talk about similar things in similar ways, and that to the degree possible all data carry with it some idea of where it was created, where it has been in the meantime, and what has been done to it.   Thus, standardized expressions for common data items like dates are important, and some standard way of describing the life history of a piece of data or of the collection in which it lives is desirable.

Dates

We recommend the use of the W3CDTF date format, which is a restricted subset of the ISO 8601 standard.  We also stress that dates can exist in our model independently of events. It is true that all events have one or more dates as properties. But “events”, in our model, represent a carefully selected subset of the things that can occur in and around legislative process and the document workflow associated with it.  Thus, not every date is necessarily an event, as that term is used in the model.

Provenance 

Provenance is particularly important when data from outside entities is imported into the system.  The summaries furnished by CRS and others for use in THOMAS are a particular example; it is important to know where they came from, and what is done to them as they are aggregated into the system.

Right now, the representation of provenance is an area for active research.  There are a number of competing approaches. Most of them show some degree of subject-matter bias insofar as different disciplines work with different types of data and consider different aspects of their origin and treatment to be more or less important.  We recommend the use of the emerging DCMI approach to provenance  .  Though not yet a standard, it is generally applicable, and those responsible seem to be taking the work of others (notably the W3C provenance group ) into account as the standard evolves; we expect that there will eventually be some convergence in approaches, but possibly not within the lifespan of this project.

Use of Vocabularies in Descriptions

Semantic Web technologies and Linked Data methods are changing the way in which we view vocabularies. These new approaches hold that, as much as possible, standard descriptive terms should be referenced with URIs within a description, not by text.  That notion is gradually taking hold in the library world, where the preference for standard vocabularies has always been strong, but where specified vocabularies were primarily used to provide approved text strings (or codes that could be displayed as standardized text strings for use in a specific data silo). In a world where data must be read, parsed, and used by any number of machines, the requirements are changing. 

For this project, it made sense to adapt a few of the more extensive RDA vocabularies for content type and encoding format, and develop some specific legislative vocabularies for the specialized material itself. In all cases, because these vocabularies are built in standard ways, they can be extended as needed. The legislative vocabularies may be accompanied or extended by vocabularies being developed elsewhere, many of which are in active use in similar environments with similar needs.

That approach differs from the traditional document-centered approach of libraries by making the events primary but still including the description of documents and other ‘document-like objects’ such as videos of hearings, images of events, and other associated materials more familiar to librarians.  This approach provides a clearer solution for the versioning issues that have bedeviled libraries as digital versions of printed documents came on the scene. 

Adapting the RDA content type vocabulary allows both the ability to extend in directions that RDA might not travel, and also to easily map from the adapted vocabulary to the RDA one when and if necessary. The RDA vocabulary includes a richer set of content types, but many are not relevant in the legislative domain (covering maps and music, for instance).

It’s important, when viewing these vocabularies, to remember that the names of the terms used by the RDA Vocabularies in no way requires that those names be used as labels for user displays. For instance, “Two-dimensional moving image” is what most of us think of as video, and “Spoken word” a more specific term for non-musical audio.

In most applications, it’s usually not sufficient to describe what something ‘is’ at that level, because user choices when confronted with various versions of content are often predicated on what they can use most easily in their environment, which most often means a specific computer platform. More and more the browsers we use every day make those differences easier to bridge, but when a user is attempting to download something or use it with a specific non-browser platform, the distinctions remain important. In the vocabulary below, a selected number of the encoding formats available in the RDA Encoding Format vocabulary are shown, along with the upper level categorizations that indicate what kind of content is encoded. As in the content type vocabulary, the RDA original versions have more choices, but not all are relevant to this project.

	
Geographic entities

At this writing, we are not completely sure of our approach to  geographic entities, but we can make a few preliminary observations about constraints. 

First, geodata raises two general policy issues discussed earlier:
 
●	How and where geodata is used will depend on policy regarding third-party data.
●	Within the legislative documents themselves, geodata is very much in the category of “obtainable future data”.  

The extraction of place names via natural language processing techniques is both well-understood and accurate.  Of course, there are entities whose names create confusion; for example, it’s not clear to a machine whether the “Sheridan County Water District” is being referenced as a geographic area or as a political/administrative entity.  But for the most part, place names are easily extracted and understood, and could be associated with standard geographic ontologies or specified in a coordinate system.

As the last sentence suggests, geodata comes in two flavors.   One approach uses ontologies, making statements like “Ithaca is in Tompkins County” and “Tompkins County is in New York State”.  A second, coordinate-based system says “Ithaca is at this set of geographic coordinates” and “Tompkins County is an area whose boundaries are described by these geographic coordinates”; one can then calculate the fact that Ithaca is within Tompkins County.   

Neither of those systems would, by itself, provide enough information to comprehensively answer the question, “What legislation affects my district?”.   There are a number of reasons for that.  First, not every place named in a legislative document will appear in an ontology (it happens that Congressional districts do not, at least not yet).  Second, there are “places” that are defined more by concepts than they are by lines on a map.  Ideas about “jurisdiction” often fall into that category.   Congressional districts are further complicated by being time-delimited, with boundaries that change relatively frequently and a need to accommodate history in order to support many common use cases.  It would seem, then, that this is an area for some careful strategic thinking, as it is not immediately clear that those providing authoritative geodata are (yet) concerned with history, or with the geographic entities that most interest users of legislative data.

One resource that does seem to manage the historical complications of ‘place’ is the Getty’s Thesaurus of Geographic Names (TGN) [http://www.getty.edu/research/tools/vocabularies/tgn/index.html]. However, the TGN on the web is available to “support limited research and cataloging efforts” and any other uses require licensing. This unfortunately makes the TGN inappropriate for use in a linked data context, but does not obviate its usefulness as a design pattern for a more open resource.  #### fix this so it doesn’t look spliced in
Identifiers
Most issues surrounding identifiers have already been raised in our paper on that subject, and we will be revising and extending it in light of experience with the model design at a point when the model is complete or nearly so.  That will include making recommendations with respect to particular document sets.  A few preliminary observations about URIs are in order, however.

Semantic Web techniques require the use of URIs as dereferenceable identifiers.  There are practical problems that come with that approach.  Most of them stem from (often unrecognized or  unacknowledged) conflict between two views of “path” information contained in the URI itself.  Consider this URI:
 
http://example.org/a/b/c/d

On one view, the entire URI might be one unbroken opaque string that identifies a single object and carries no other implications. In that world, the “slash” character is just another character, with no significance as a delimiter.   On another view, the division of the URI into path components separated by slashes might imply that “a” somehow collects “b” objects which in turn collect “c” objects which in turn collect “d” objects.  That is a convention that is often used on the Web, particularly for things that can be legitimately viewed as document trees (such as the US Code, for which we provide numerous illustrations in the identifier paper). 

Our working approach -- yet to be fully thought through for all materials needing identifiers -- is to acknowledge this tension by using each approach for the purpose to which it is best suited.  On the one hand, we imagine a very flat “identifier URI” space in which particular objects are identified as tersely as possible. We still have to come to agreement about what level of opacity is tolerable, but an approach that reflects current citation practice is obviously appealing.  Think of these as “mostly-opaque-identifier” URIs whose sole function is, in fact, to identify objects uniquely.   On the other hand, we imagine a number of patterns for “accessor” URIs, structured and presented in ways that modern Web audiences find intuitive, and with path components that are meaningful.  For example:

●	http://example.org/H109-1234 
●	http://example.org/house/bills/109/1234

would represent “identifier” and “accessor” forms for the same object.  The first example is the flattest possible URI that can be used to uniquely identify a House bill (imaginary in this case). The second represents a series of nested collections in which the bill is ultimately found.  It’s also an imaginary example, but it’s easy to see that all of the intermediate levels in the path represent useful collections of things.  It is also easy to imagine alternate “accessor” forms that would embody different useful nestings of collections, but ultimately lead to the same object.

A spreadsheet included as part of this package, and described in the accompanying “Field Guide to Legislative Metadata Model Spreadsheets”, includes (among other things) a partial census of identifiers used in different parts of the legislative process.  It will be refined and extended as we move through the remaining document corpora.  Ultimately, our recommendations will try to account for all identifier needs encountered.
Subjects and Classification

Traditional library cataloging practice uses controlled vocabularies for a number of purposes, most commonly to express the ‘aboutness’ of a resource.  In libraries, this aspect of a description is most often called ‘subject’, and the assignment to resources called ‘subject cataloging’. It’s not entirely clear why librarians resist using ‘topic’ as a synonym, but it might be speculated that because the Library of Congress Subject Headings (LCSH) have been used as the primary vocabulary in libraries for over a century, the connection is now probably hard-wired into librarians at birth. The use of ‘topic’ as an alternative is sometimes seen as the poor cousin at the table--small, without heritage or appropriate complexity. The use of ‘subject’ is so pervasive that the Dublin Core element expressing ‘aboutness’ is also called ‘subject’, most likely due to the presence of a significant number of librarians present at the birth of that standard vocabulary, now pervasive on the Web.

But ‘subject’, already an overloaded term, becomes even more problematic as RDF and linked data become more familiar in libraries.  The RDF triple consists of a ‘subject’, a ‘predicate’ and an ‘object’, and the definition of ‘subject’ in this context does not follow its use in library practice. If for no other reason, this confusing situation suggests that libraries start shifting from ‘subject’ to ‘topic’ where possible. This shift is likely to be welcomed by library users, whose affection for ‘subject’ over ‘topic’ has never been generally noted.

In the traditional library world, standardized vocabularies (whether for topic, genre, or role) are used primarily to provide approved text strings. In the case of LCSH, these text strings may contain different subdivisions-by-type (topical, geographic, genre) constructed according to complex rules intended for human use.  For a number of reasons, that approach is problematic in the digital world.

First, the ‘data’ version of LCSH available at http://id.loc.gov is widely used, but its gaps are not widely understood. It was built using the machine-readable version of LCSH -- long available from LC by purchase or subscription.  That version had built-in problems inherited from the printed version. Catalogers constructed text strings according to a prescribed order, sometimes using ‘pattern’ headings that defined how the subdivisions should be created, but without machine-readable evidence in the paper or digital files, except as text in instance data. The LoC has long understood this to be a problem, and determined that their preferred solution will be to provide an identifier for every complete string, with subdivisions included, to be added to the data file. 

That solution assumes, first, that the machines receiving these strings will be able to deconstruct them usefully for a variety of purposes, and, second, that this solution is sustainable in an environment of distributed creation and use that is also characterized by diminishing  resources. There is already a de-constructed version of LCSH, developed over the past 20 years by OCLC and LoC, called FAST (for Faceted Application of Subject Terminology) Because this version was built to support a faceted approach -- far more useful in data applications than strings built for card catalogs -- FAST has long been seen as a better fit for subject access in the digital world. The FAST data has been available in an ‘experimental’ mode for linked data applications since late last year but there are no promises that it will be available freely for production use when the ‘experiment’ is completed. Unfortunately, OCLC has a long history of making available ‘experimental’ data and services that never leave that status, sometimes for a decade or more.

Second, alternative topical schemes, such as the one used in THOMAS, are specifically developed for legislative materials, and tend not to be as complex as LCSH. The THOMAS subject terminology has two levels (and topics can potentially be assigned on either level) but seems to lack identifiers, distribution mechanisms, or maintenance and extension policies.  It also has a limited scope. Additional development and exposure of the THOMAS vocabularies would require time and money. It would also require a plan that recognizes both the strengths and weaknesses of the current strategy, as well as comprehending how the extensions might be accomplished using current vocabulary standards and evolving Semantic Web mapping techniques [Linked Data Vocabulary Management: Infrastructure Support, Data Integration & Interoperability, Information Standards Quarterly, 2012, no. 2 (in press)].

Third, classifications, such as the Library of Congress Classification (LCC) and the venerable Dewey Classification, provide a very different kind of topical approach. They each provide the kinds of linkages between topics, expressed hierarchically,  that support browsability far better than LCSH (with its somewhat limited thesaural structures) and the THOMAS vocabulary (with its simple two-level approach). LCC has been developed extensively over the past century, with most of the legal classifications the most recent . All of the schedules are available digitally via LC’s data-purchase programs, as well as in its subscription based ‘Classification Web’ and ‘Cataloger’s Desktop’ products, and, of course, on paper.  Recent discussion on the LoC Law Library blog suggests that discussions have begun around making the classifications available on the http://id.loc.gov service. That is definitely good news for this effort. The Dewey classifications are available from OCLC, with the upper levels available freely and the detail by subscription. Dewey is not ordinarily used in law libraries but is often familiar to non-researchers, so it cannot be discounted .  The OCLC website includes a discussion of Dewey-as-linked-data (also an ‘experimental service’), which is also worth exploring.

Because there is solid precedent for usage of multiple topic schemes, there is no either/or requirement here, but policies are needed.  In particular, consideration needs to be given to how these topical vocabularies might be evaluated or developed sufficiently for use in the short-term, along with some longer-term strategies to improve topical access to legislation.  A particular issue is the increasing number of “Frankenbills”, in which provisions related to a wide variety of unrelated topics are found in the same bill; the application of topical information at a much more granular level is needed.
Granularity

We explored the issue of granularity in our paper on identifiers, but the world of bills and resolutions contains some specifics worth mentioning:

●	Granularity in document addressing. It is not obvious to us that the versions of bills and resolutions mounted in (say) THOMAS are encoded in a way that would permit sub-document addressing (say at the level of a Title or Section) although they very well may be.  If so, a system of identifiers for subdocuments will be needed, at whatever level of granularity is supported by enumerated labels in the text.
●	Targets for amendments.  Amending language in the statutes themselves implies at least two “addressing” standards.  Amendments may be expressed in terms of the statute being amended, generally with reference to the subdivisions in the Public Law version of the act, with the act referred to by popular name; or, they may be expressed in terms of the addressing system in use as codified in the US Code.  A third approach, which uses page and line numbers in a printed version, seems only to be in internal use within the Congress, where it poses significant challenges for XML-based document systems.  It may be that we require more than one relationship to model the different systems in use.
●	Granularity for codification.  An important question, not yet fully explored, is how closely the granularity suggested by each of the above relates to the granularity at which codification takes place.  We have yet to look closely at the US Code Classification Tables in detail to see how and if the methods used there align with other granularity concerns.

Indeed, alignment is the overarching issue here.  Different applications make use of seemingly different granularities, and it remains to be seen whether there is a single system that can support all of them simultaneously.  If not, properties will be needed for each and mapping strategies will need to be developed to support ongoing alignment as documentation evolves.  Interestingly, the classification tables provide an example of this, in which the original substructure of the Public Law version is related to labelled sections and subsections within the US Code, and to the much-less-granular structure of volumes and page numbers in the Statutes at Large.	
Versions

Traditional library cataloging has developed different strategies to describe and track changes, whether in name, content or focus, or format. Those strategies embedded a number of assumptions,  and they had their own goals and implications that have proven more or less applicable to the digital world.  Nonetheless, they have something to teach as we approach the problems of change in legislative materials. It is particularly worthwhile to think about how these strategies have responded to a series of follow-on changes growing from the move to digital formats.

There have been several noteworthy types of change:
●	Changes of title and issuing body in serial publications, which were sometimes accompanied by changes in frequency, content focus, and, more recently, format. In responding to these changes, libraries moved to strategies of ‘chaining’ versions rather than attempting to aggregate all changes together. This ‘chaining’ strategy has also used to relate various sequentially published editions of textbooks, reference books, and other types of materials.
●	The proliferation of concurrent versions of the same content, primarily intended to soften the impact of format changes for libraries, publishers and users who were reeling from the uproar of the digital revolution. The inevitable direction of the changes -- from print to digital -- plus the inability of library computer systems to cope with the proliferation of catalog records, encouraged the cataloging community to try and establish an ‘original’ version from which to more efficiently ‘hang’ descriptions of equivalent versions. The result has been chaotic. It has effectively degraded the usefulness of library data going forward, given that such ‘mashups’ are very difficult to reverse.
●	An accompanying (and sometimes unnoticed) diversification of the content itself, driven by format and bundling. The digital version proliferation problem gradually (and inevitably) morphed into what looked like equivalent versions of the same content in different formats, but were not.  The different versions were really becoming different content, with different distribution models, and different sorts of ‘containers’ allowing users to view or pay for the content at various levels, from aggregation (serial title) to separate article. 

Similar challenges have permeated the world of government documents as the Federal Depository Library Program -- the main distribution channel between the government and libraries -- responded to resource and other environmental pressures by shifting from print, to CD, to web-accessible publications.  In all these cases, the challenges are similar: how to describe things in the world that have one or another (or both) kinds of version relationships -- either horizontal, where the various versions can often be ‘chained’ together using some variation of predecessor/successor relationships, or vertical, where the same content is issued in more than one ‘package’ and the challenge is to allow the end user to decide which version is of more use to them.
	
With legislative materials that are ‘event-aware’, as in our model, there are additional challenges. But there are also new ways to describe relationships that assist in discovering and using legislative materials. We are using two simultaneous approaches.  The first anchors some versions of documents to particularly important process events, via “hasGeneratedDocument” and “isGeneratedBy” relationships.  The other chains successive versions together via “hasPredecessorVersion” and “hasSuccessorVersion” relationships.  That allows any number of variations on the document to be linked to each other and to well-understood events in the legislative process.	
Description Issues
Currently we’re seeing a resurgence of the notion of ‘self-describing’ documents, where metadata is partially (or completely) embedded in the document itself, traveling with it wherever it is stored or cached and managed as part of its ‘content’. Earlier interest in this idea surfaced in the early days of Dublin Core (and the Web), where some content providers embedded DC metadata directly into HTML documents. Interest in that approach faded, particularly as it became clearer that maintenance of such information within documents was far more difficult than for metadata managed in databases. 

The current interest in embedded metadata is addressing two different needs: one for metadata that can be easily consumed by search engines; the other to support management of files in a preservation context. 

For many digital projects, perhaps most particularly those in the cultural heritage sector, success or failure is often measured by demonstrable usage of the materials.  The usual scenario is for users of search engines to be led to sites where content is available primarily by collection or individual item, often by a site-based search based on richer metadata. Although embedded metadata is not the only strategy used to provide better ‘search engine optimization’ (SEO), the recent development of standards such as microdata [http://en.wikipedia.org/wiki/Microdata_(HTML)] and RDFa, [http://www.w3.org/TR/rdfa-syntax/] and the recently announced collaboration of the major search engines designed to develop and encourage widespread use of a new embedded vocabulary [http://schema.org] has raised important issues for content providers and their metadata managers. Given the desire of many projects to provide richer metadata for better discovery and linking, and the surging interest in briefer metadata embedded in documents, clearly there is no either/or direction possible. What seems to be emerging is a ‘plus’ solution, where brief, non-volatile metadata is embedded in documents, and richer metadata, needed for providing services to more specialized or knowledgeable users continues to be stored and maintained in databases. It’s important to note that use of embedded metadata also requires analysis and decision making, particularly given that the schema.org vocabularies are tilted in the SEO needs of commercial sites, those who pay for advertising on search engine sites.

The other scenario, for metadata used for preservation management of content, can certainly re-use much of whatever embedded metadata exists to enhance preservation strategies, but preservation metadata, embedded or not, is generally designed not for discovery but to support long term workflow, management, refreshing, and other tasks across a variety of ‘versions’ of single or aggregated resources. Because our project is clearly not designed to address preservation (or indeed, most administrative) needs, our lack of recommendations in this area should not be mistaken for lack of interest.

Traditional library cataloging places high value on describing the “extent” of an item (size, number of pages, illustrations, and other physical characteristics).  Our model includes these items to the extent that they are relevant to printed and print-like (eg., PDF) versions of the documents we are considering.  There is also an emerging push toward expanding RDA’s use of “extent” to make it more friendly toward data.   That would carry the following benefits:

●	Easier matching for the purposes of determining differences in content.
●	Sorting by size, dimension, or other criteria.
●	More granular search-faceting  for media materials based on extent.
●	A better path towards automated determination of extent.
●	Provision of textual values and labels in a variety of languages.
●	Ability to compress and itemize more complex extent information for particular users.

At this juncture, no well-documented recommendation has emerged, but we will no doubt revise our treatment of extent descriptions once one becomes available.		
Sources and standards referenced in this document

●	Provenance
○	W3C Provenance Working Group, “Provenance Vocabulary Mappings”: http://www.w3.org/2005/Incubator/prov/wiki/Provenance_Vocabulary_Mappings 
○	DCMI Provenance Task Group Wiki: http://wiki.bib.uni-mannheim.de/dc-provenance/doku.php
●	Dates
○	W3C W3CDTF Date/Time Standard: http://www.w3.org/TR/NOTE-datetime
●	People and organizations
○	“Friend of a Friend” (FOAF) Project: http://www.foaf-project.org/
○	Epimorphics Organization Ontology: http://www.epimorphics.com/public/vocabulary/org.html
○	Fujitsu Ontology for Knowledge Activity Resources (OKAR): http://jp.fujitsu.com/group/labs/en/techinfo/technote/okar/documents/
●	URIs and identifiers generally
○	Berners-Lee, “Cool URIs for the Semantic Web” : http://www.w3.org/TR/cooluris/
○	Bruce, Hillmann, Joergensen, and Phipps, “Musings on Document Identifiers” : http://liicr.nl/Hdl8WB
●	Subject-matter classification
○	OCLC Faceted Application of Subject Terminology (FAST) : http://www.oclc.org/research/activities/fast/default.htm
○	FAST for Linked Data : http://www.oclc.org/research/activities/fast/default.htm
○	Library of Congress Cataloging Data Service : http://www.loc.gov/cds/
○	OCLC Dewey Decimal Services: http://www.oclc.org/dewey/

A Data Model for the Congressional Record: Overview and Analysis
Thomas R. Bruce, Legal Information Institute (tom@liicornell.org)
Diane Hillmann, Metadata Management Associates (metadata.maven@gmail.com)
John Joergensen, Rutgers University School of Law (jjoerg41@gmail.com)
Jon Phipps, Metadata Management Associates (jon.phipps@gmail.com)

Introduction
It is possible to think of the Congressional Record (CR) in two ways:  as a newspaper that can be cataloged and modeled just like any other serial publication, or as a document made up of many interesting snippets that should be modeled in their own right.  Many of the use cases we have developed require the latter. We have chosen to do both.

Currently, there is no electronic version of the CR that would support the latter approach.  We believe that one is imminent, or should be. It would be possible to create one fairly easily from the Microcomp (“locator” or “bell”) code currently in use at GPO, offering the possibility of converting the backfile from perhaps as early as 1984.  In any case, there is little doubt in our minds that the publication format of the CR will soon change, and that the client will be faced with a much more complex -- and rewarding --  metadata management task as a result.
The CR as a serial like any other serial
In traditional cataloging, anything defined as a periodical or ‘serial’ publication (“a publication, usually regularly issued and consecutively numbered”) is cataloged under a collective title with a generalized description that applies to a specified run of issues or parts. Changes in title (and some other changes) require a separate description, and these are chained together with defined relationships.
In most respects, the serial record--in MARC or any other syntax--could be seen as the overview for the title, because it contains general information about the entire publication as a whole, links to various editions and formats, historical information, etc.  For instance, other views of specific parts having separate topics, identifiers and relationships -- whether originally published together or not -- still bear an important relationship to that overview, and that relationship can be expressed in the data. Such a notion of a collection enables browsable access to the entire corpus, regardless of whether the user begins to look from the top down, the bottom up, or via some other publication with a relationship to the CR data.  A guide to such a record -- the MARC21 entry for the Congressional Record -- is provided in Appendix A.

As our focus shifts to the pieces and the new forms of information access that such a disaggregated model provides, we will still need to reference the collection level -- in this case, the CR description.  That will ensure that user of the data can make the leap from the past, when the CR was published in various paper editions, to the present, where the CR still exists as an important point of access to updated Congressional information.

Some MARC metadata is captured by the MODS file that GPO issues with each daily CR edition published via FD/SYS.  In addition, it appears that the MODS metadata includes a number of items that have been parsed from the text of the CR itself--whether as a separate digital version of a single information component or as a digital page view.  It also appears to model a granular structure very similar to the one we describe below.
The CR as a collection of interesting components
Sooner or later, the CR will be published in a format that makes it possible to disaggregate its components, consider them individually, and recombine them into new views of the underlying information.   We believe that little more would be required than to encode it in reasonably granular XML, and that such a move is imminent.  That leads us to consider what a model for legislative metadata at such a granular level might look like.   The balance of this paper, offered as a form of “future-proofing”, considers that problem.  After addressing some technology and policy issues raised by our collection of CR-related use cases, we go on to consider a model that is designed for each of the “granules” within the CR.  

As a practical matter, any deeper model for CR metadata could only be populated through automated extraction of metadata from XML text (it appears that GPO may already be doing some of this when it creates the MODS files that accompany the CR in FD/SYS).  Without having an XML version available to us as a point of common reference with the reader, it becomes difficult and confusing to draw the line between the design of an XML encoding scheme and the design of the metadata model that describes a document so encoded.  There are no doubt subtle questions about which features are best supported by document encoding versus what should be done using external metadata that we have missed, improperly conflated, or dodged.  But there are also many policy and design questions to be solved before we can reach those subtleties, and we describe them in the sections that follow.

Some policy and technology issues
Member sentiment and voting

Many of the use cases we collected express strong research interest in the positions of legislators with respect to particular legislation, their positions with respect to more broadly-stated issues, and in voting information.  These are all reported in the CR, and a more granular approach would create new capabilities for research in these areas.

Member sentiment: technology constraints

In the annotations to the various use cases related to member sentiment (RFP S-2 UC-1,  and RFP S-7 UC-1), we express a pessimistic view of the potential for automated extraction of information about member sentiment as it emerges from  transcripts of floor debates.   It would, no doubt, be possible to segment floor debates by speaker, and to analyze the resulting segments as speaking either in favor of something or against it.  However, it would be extremely difficult to know whether the “something” being spoken about represented a position in favor of a given issue or even in favor of the bill under consideration in the debate.  That is because the statements involved are made in the context of a complex parliamentary process.  A statement in favor of an amendment might be supportive of the overall bill, if the amendment is a friendly one, or it might not be, if the amendment guts the bill.   And, given the procedural turns and twists of legislative process, it may be difficult to identify just what the statement relates to or what a speech about a particular procedural maneuver might mean with respect to the bill.   We are left, at best, with the very strong possibility that limited accuracy in both sentiment detection and in associating statements with larger positions and outcomes would accumulate error in a way that would render the overall project useless.

Voting data: policy issues and the problem of context

Along with records of statements and debates, records of votes comprise a key part of the contents of the CR.  Of course, the most significant of these are records of roll call votes.  Interestingly, the ability to evaluate the attitudes of legislators based on roll call votes cast on selected legislative measures was often cited as a desired feature of a legislative model by our use cases.  Technically, it would be easy to pull voting information out of the record and parse it separately; third-party services such as GovTrack now do this routinely. Given that the measures being voted upon will have defined topics, and that those votes are, ultimately, statements of approval or disapproval, the temptation to accommodate such requests is strong.  One could easily correlate the topics of measures with the votes of legislators to draw conclusions about legislator sentiment. 

We believe that such a function would be inherently flawed, and its adoption an error.   In contrast to such information as debate statements, where a legislator would be stating and defending his or her position on a topic, a vote record contains no information on why a vote was cast.   But this is politics. It regularly happens that a legislator will be in favor of the aims of a certain measure, but will, for a wide variety of reasons, be constrained to vote no.  Similarly, a “yea” vote may be cast for a wide variety of reasons that go against a legislator’s feelings about a particular measure.  For these reasons, any attempt to divine legislator sentiment from voting data will be inherently flawed. Voting records simply do not contain sufficient context to accurately measure sentiment.

That said, basic factual identification of legislators and their votes in all roll call votes can and should be done in a public, neutral manner.  As with any information provided by any source, it may be subject to misinterpretation or even intentional abuse by third parties.  Nevertheless, it remains vital data on the functioning of government.  

Access to voting data is essential, but voting data should not be presented by the client (or any other source) as indicating legislator sentiment by itself.  Misuse of voting data should come only through others.  Moreover, given the linked-data environment we contemplate in the design of our data model, the additional information needed to provide context to legislative votes will be available should anyone choose to look.  For example, within the CR itself, statements made by legislators during debate on a measure will include identifiers for both the measure under consideration as well as the legislator speaking.  Similarly, a subsequent roll call vote would identify the measure, each legislator voting, and their vote.  So while the individual’s vote should not, by itself,  be subject to interpretation, the ability to cross-link the debate statement with the subsequent vote via the measure and legislator identifiers would provide essential context for understanding that vote. That linkage is not, in and of itself, an interpretive act to be avoided by the client. But linkage would go a long way towards providing the means for users to quickly and accurately make their own interpretations.  
Vocabulary usage and design: “misc” considered harmful
The design of vocabularies, including classification systems, can be a difficult and long-tailed endeavor.  That is particularly so at the outset of a project, when large parts of the corpus are unknown or unsurveyed. Vocabularies based on language concepts, and classification systems based on topical arrangement of those concepts exist in an environment where change is a constant. Poor design and management of these essential tools too often leads to frustrated users. 

Good design is intended to maintain a balance between ‘precision’ and ‘recall’, where a too precisely defined conceptual space can lead to searches with few or no results, and an excessively imprecise vocabulary leads to too many results for a user to review. Modern search engine designs often mix vocabularies with full text applications, to assist in disambiguation of synonyms, plus stemming and spelling strategies to expand the reach of term selection in a discovery environment. User profiles range widely -- from expert researchers to school children -- and in that diverse environment such strategies increase user success with discovery systems.

Under those circumstances, it is tempting to design a vocabulary that contains only the few terms that describe the majority of items, and to leave the remainder to some sort of “miscellaneous” category.  That is often done in the belief that the thinly-populated categories will never accumulate enough members to be a useful target for search or any other activity that would require their members to be distinguished.  But that is notably hard to predict; “environmental law” would have been a very slim category in 1972, but it is certainly not so now.  The “misc” category can become a harmful default that blocks the recording of “aboutness” information that will later become useful.  A better approach would be one in which a core vocabulary can be allowed to evolve as terms accumulate and are populated.  A vocabulary designed to reflect the full range of ‘aboutness’ to be found in legislative materials is something to be managed, not set in stone from the outset and left to age gracelessly. 

Within the CR, the evolving-vocabulary problem arises in at least two important areas: subject-matter classification for the general remarks of members, and the naming of the CR components themselves.  We discuss the first problem more extensively in a later section.  The second problem is much as we’ve described the general issue: while a good number of CR components can be sorted into a small group of recurring types, the remainder are so diverse as to elude classification.

Intelligent management of these evolving vocabularies demands minimally that we distinguish between the sources from which terms are drawn. We may want to establish separate properties for subject classifications that are handmade by internal experts, harvested by machines, or created by crowdsourced free-tagging, that can be used in concert by an effective application.

Machine-constructed and crowdsourced tagging each have some appeal for this purpose.  As we discuss elsewhere, many textual features in the CR (proper names, geographic locations, bill identifiers, and so on) are readily extractable using either simple textual pattern-matching or more sophisticated machine-learning techniques for recognizing named entities, yielding rich metadata for data discovery and search.  Crowdsourcing also has some appeal -- it would be a particularly good way to discover popular terms for legislation such as “Obamacare”, and for assigning “aboutness” terms to small snippets of the CR -- but it also poses dangers.  Unlike the Library of Congress’ earlier experience with free-tagging of images distributed by Flickr, civility and restraint are not likely to be the order of the day when the material to be tagged provokes partisan sentiment, or when tagging is seen as a means of announcing a personal position, casting a vote,  or as some other form of political speech.  That seems all too likely with discussions of current legislation.  Of course, crowdsourced tagging could be done using a prespecified vocabulary.  That would forestall abuses, but would destroy any potential for discovery of new terms. Almost inevitably, crowdsourcing in this arena will bring with it a need for policing. That is, of course, a well-known problem for online commercial entities depending on ranking and review by users.  That has led to an extensive literature on user-generated content, and the means for controlling and enhancing its quality.  That literature is too broad to survey here, but may prove useful in thinking about implementation in the future.
Creation and management of identifiers
Because it surveys so much Congressional activity, because it contains so many components, and because so many are involved in its publication and distribution, the CR provides an interesting point from which to view problems of legislative identifier management  and policy in general.   

What, exactly, is the problem?  At our most ambitious, we would like to be able to relate every object identifier to every other identifier that has ever been used to refer to that object.  If we were talking only about documents, we might say that we would want to find, in every document or meaningful subdocument, some clue that would lead to us to its name in every system that has ever provided a representation of that document, or used one of its identifiers.  We would like to do that even when perfect alignment does not exist between systems, for example when translating identifiers for items in the CR to page numbers in the printed publication.

In our view, there are many possible ways to attempt this. We summarize two broad policy regimes here; our paper on identifiers says a great deal more about the detailed design issues involved, particularly those related to the use of legacy identifier systems in a Linked Data environment.

In a fully centralized standards-based approach , someone -- or a group representing a lot of someones --  would attempt to create an overarching standard for all useful identifiers that will in turn be respected by all stakeholders, including Congress itself, the Library of Congress, and GPO.  There is probably no process that could create such a standard in reasonable time, and no one in a position to enforce it.  Something similar to this was undertaken in the metadata design associated with regulations.gov, with very uneven results.  In that case, various attempts were made to enlist cooperation and compliance by relaxing the standard, with the result that the standard became so watered-down as to be useless.  No doubt there are many other ways to provide incentives for participation and compliance, or to ease the pain of adoption, but we are not optimistic about the outcome of any top-down approach.

The more likely course -- and certainly the one that is being played out in the Web of Data generally -- is a “thousand flowers blooming”  approach, in which different parties are free to mint whatever identifiers they need and expose them on the Web.  We might hope that data creators would also provide systems that relate their identifiers to those used by others to describe the same objects.  That would require in turn that all parties have a certain amount of expertise in identifier design, a certain amount of altruism in their approach to implementation, and awareness of the needs of others who might want to make use of their data.  Those are not universal qualities, and no doubt there would be gaps and missing links in the chain of relationships.  There will be a need for third parties with the necessary expertise to identify and fill gaps of expertise and implementation by building bridges between systems that would otherwise remain isolated.

Whatever approach is ultimately taken, it would seem that a census of all identifier systems in use, past and present, would provide a useful starting point.  Such a survey would require the cooperation of all data creators and republishers within the legislative branch.  It would yield information useful in formulating a practical policy, and might also usefully raise awareness of the issue throughout the various offices involved.  Our work on this project is a good start, but given our outsider status it is limited in what it can consider.
Other policy and data issues touched on elsewhere

As our paper on design issues for Bills and Resolutions states, we have also tried to account for other environmental factors in the model’s design.  Most of those come under the general heading of “future-proofing”.  We have tried to identify important trends in the administrative and technological environment and ensure that the model will stand up to them well. The most significant of these are:

●	The effects of exposure of legislative metadata  in a Linked Open Data environment.
●	Curation issues that arise from consuming data in a Linked Open Data environment.
●	The availability of data in forms other than those traditionally made available through the paper and electronic documentary record.
●	A developing push toward data-sharing within the legislative branch, accelerated by increasingly severe resource constraints.

So far as we have been able, we’ve chosen strategies that reflect the best understanding of what would be most conformant, most flexible, and easiest to implement, in roughly that order. In some cases, it is not so easy to know what will be best or how long it will remain so. The speed at which innovation and shifts in understanding happen in this realm make flexibility paramount.

As we said at the outset, the most significant “future proofing” consideration for the CR is its potential availability in much more granular form.  There are other problems treated in the bills and resolutions issue paper that are germane here, and we would refer you in particular to its discussion of people and organizations,  and of subjects and classifications.
CR components and structure
The remainder of the paper is an inventory of structural features and elements contained within the CR.  Because typographers often take approaches that amount to visual proxies for logical markup, these features and elements are often defined by special typography visible in the printed edition. For our purposes, that visual arrangement  functions as a proxy for a logical markup scheme like XML, and we use it here as a way of detecting structure and features of interest.  
GPO MODS metadata
It seems that GPO has been part of the way down this road.  A survey of the MODS metadata associated with the CR as it is found in FD/SYS shows that it is at least partly based on ideas about CR structure very similar to those we put forth here.  It also contains many of the metadata elements we describe; the model appears to be populated by parsing the text using locator codes as keys to the meaning of different text strings.   The general approach appears to have been to populate the model with data “as found” in the document -- for example, the names of Members making extended remarks are marked up,  but no attempt has been made to link them to the identifiers used in the Congressional Biographical Directory.  It takes the step of extracting many of the metadata elements that interest us, but falls short of providing a full basis for publication as Linked Data.

Major structures
Each daily edition of the CR is divided into sections:

●	House
●	Senate
●	Extensions of Remarks
●	Daily Digest

We consider each in turn.
House and Senate Sections
The House and Senate sections are daily reports of the floor action in their respective chambers.  They are essentially a narrative of events.  The bulk of the narrative consists of transcripts that in turn incorporate other blocks of information: the actual text of bills and amendments, records of votes, and so on.  Typically the incorporated blocks are set in a different, smaller typeface.  In addition to transcripts, a section may incorporate mini-reports of specific events (such as the “Prayer”) some of which have procedural significance (“Adjournment”), as well as many other things.

The transcript for each chamber is broken into a series of  sub-granules.  Each represents a change of topic.  Sub-granules are set off with a special horizontal rule, and are titled.  Subtitles within each sub-granule may identify motions, votes, and incorporated bill or amendment text among other things.  Some subtitles are simply set in a different typeface; others are surrounded by square brackets.   As the list just given indicates, many sub-granules contain identifiers for members, votes, amendments, and other things that can be linked to data elsewhere. 
Extensions of remarks (House only)

An extension typically contains the following elements:
●	A title or label
●	The name of the legislator making the remark
●	The legislator’s state (but, significantly, not their district)
●	Location and date, which will always be the same for a given day and chamber

The extensions are quite diverse, but some useful categories emerge:
●	Remarks on pending legislation.  These usually contain extractable bill numbers, though not necessarily in the title.
●	“Personal explanation” remarks, which state how the legislator would have voted had he been present for the vote.  These generally refer to votes by roll call vote number, but may also identify bills by number, and amendments by number and sponsoring legislator. Final votes seem to be noted as such.  They are always titled “Personal Explanation”, at least in recent examples. All of these items seem amenable to automated extraction.
●	“Recognition” remarks, which make favorable comments about a (non-legislative) person, organization, or event. Generally these are in the legislator’s home state or district. Again, the targets of these remarks will, in general, be extractable by software using Named Entity Recognition (NER) techniques.
●	Other, general remarks, which can be on virtually any topic.  See our comments on classification systems and vocabularies, above.
Daily Digest
The Daily Digest is just that -- a digest whose purpose is concise summary of the day’s activity. As a result, it contains all of the interesting textual features we have already found to be both interesting and easily extracted and linked.  Like the rest of the CR, it also has internal structural divisions defined by (and easily detected through) typography.  Because of its summary nature, it is particularly rich in cross-references that make use of identifiers, and it contains many references to page numbers and page ranges.
Identifiers and accessors: methods

Treating the CR as a collection of components requires identifiers for each component.  It may not be necessary for the client to create its own identifiers for each component; it is likely that any XML schema used to encode the CR would create individual, opaque identifiers for each component, either running sequentially from the start of each issue or within each structural division of the text (indeed, GPO appears to have done something very like this in preparing the MODS metadata found in FD/SYS).  These could be used to uniquely identify each component, but would probably not provide a good basis for “accessor” URIs used to create user-friendly browsing interfaces.  

For those, we would propose a system of date-based URIs for issues that could then be extended to create URIs for each component.  Component extensions would be, essentially, a system of nested accession numbers running to the smallest granular level within the text.  Some examples, all taken from the 23 April 2012 issue of the CR, follow.  They are meant to be illustrative rather than exhaustive:

URI	Identifies	
../CR/2012/04/23/	CR issue of 23 April, 2012	
../CR/2012/04/23/ExtRemarks/	Extended remarks section of that issue	
../CR/2012/04/23/Senate/9	Motion to proceed on the Violence Against Women Reauthorization Act of 2011, which is the 9th subdivision within the Senate section.	
../CR/2012/04/23/Senate/9/3	Remarks of Sen. Lieberman regarding postal reform, the third subheading within the section described above.	
../CR/2012/04/23/Digest/Senate/ChamberAction/Considered/1	Same as ../CR/2012/04/23/Senate/9	
 
Of course, the use of integer components in these identifiers is not at all reader-friendly, but doing better is probably not possible.  Any automated technique used to construct more readable URIs -- say, by extracting and  using the last name of the Member extending his remarks -- is likely to run into problems with naming collisions.  That suggests that these sorts of URIs are “accessors” -- primarily useful in constructing browsable, structure-based interfaces whose component labels could be pulled from other metadata associated with the component.  
Synchronizing component identifiers with identifiers for Daily Digest entries and page numbers

As the last example in the table above suggests, there will be a need to match identifiers in the body of the Senate and House sections of the CR with their corresponding entries in the Daily Digest.  That will require some kind of mapping relationship between the two.

Page numbers provide the basis for many references to the CR, be they internal cross references or citations from other, external materials.  That is particularly visible in the CR Daily Digest, which associates page ranges with its entries, but it is probably ubiquitous.  Much of the time -- depending on the user’s starting point --  this is a relationship that will need to be inferred.  For example, a reader interested in seeing a print-like manifestation of a component that they are reading in an online system would access it via a retrieval process that would (automatically) look first to the corresponding Daily Digest entry and then retrieve the range of pages that the Daily Digest entry suggests.

GPO has taken an interesting approach to the inclusion of page numbers in what is basically a structural model.  For each granule and sub-granule, GPO offers an “extent” description that includes start and end pages for the granule.  This can be a little misleading if one then takes the given extent as indicative of the real size of the element; a 20-word granule can “extend” over 2 pages if it falls on a page break, but it is certainly not two pages in length.
Other metadata issues for CR components and structures
Our earlier paper on modeling issues for bills and resolutions distinguished between data and policy issues for metadata models.  Many of those same concerns also apply to the Congressional Record, and we will not go into them in detail.  
Low-hanging fruit and automated extraction
The components that make up the CR contain a great deal of metadata that can be easily and usefully extracted and used to populate a model.  Much of this has apparently been done by GPO in creating the MODS files that accompany the FD/SYS version of CR.  For example:

●	Member statements contain: 
○	titles indicating subject matter
○	the name of the Member making the statement
○	often, but not always, a bill number indicating the subject of the remarks.

●	Floor debates can be regarded as transcripts; it is possible to distinguish a number of elements automatically:
○	Who is speaking when
○	Bill text
○	Amendment text
○	Roll call votes, with 
■	Identifiers for each vote
■	“yea” and “nay” lists of members voting
○	Other incorporated materials, either read into the record or ordered to be printed with it.  These are extremely diverse; we have identified newspaper editorials, written correspondence, and a welter of other items in addition to bill and amendment text.

●	Special sections exist for
○	Executive communications, containing
■	Numbered entries for executive communications, including
●	The party communicating
●	Applicable docket numbers, RIN numbers, and other identifiers indicating the rule or matter that is the subject of the document.
○	Additional sponsors, containing
■	Bill numbers with a list of added sponsors
○	Bills introduced, including
■	Bill number
■	Sponsorship information
■	Committee referral information
○	Bills enrolled

People, organizations, and places

Our earlier discussion of the policy issues involved in voting data made passing mention of the identification of legislators as speakers in debates and roll call votes. Member information is easy to identify and extract, largely because of the availability of authority files that tell us what to look for, and because Member names usually appear in a preferred consistent format.

Members are not the only named entities appearing the CR; the identification of people, organizations and places referred to in text is a subject that should be addressed.  In the absence of fine grained subject tagging of text (which is prohibitively costly and labor intensive), the identification of the subjects of remarks can go a long way to providing context to text, and greatly enhance the utility of any system that makes use of it.  There are many automated techniques that would allow us to identify things under discussion.

First, many components will have a bill as their subject, and that bill will be identified by bill number; sometimes, too, it will be referred to by its title or popular name.  Either is easily extracted and referenced to the bill itself.  The bill, in turn, has subject-matter assignments that can be inferred to apply to the remarks about the bill as well.  Second, named-entity recognition (NER) techniques are quite good at identifying people and places.  While there is not yet an off-the-rack application that has been optimized for the legislative domain, it seems likely that work done for the news domain -- which has been extensively studied and implemented -- would produce good results.

Synchronization between textual and multimedia records

Multimedia records can be difficult for researchers to work with.  Typically, they are only word-searchable if a closed-captioning track has been created. and even high-speed scanning by the user often proves a slow way of reaching a particular place in the record.  Algorithmic techniques for identifying changes of scene or breaks in the action are getting better, but they are far from perfect.  

It therefore seems likely that most researchers would want to search for items of interest in the full-text transcript provided by the CR, and then shift from the textual record to a multimedia recording in order to view moments or actions of particular interest.  Some means of doing so, supported by temporal metadata that can be synchronized or mapped between textual and multimedia versions, seems desirable.

Sources
●	General descriptions
○	Law Librarian’s Society of Washington, DC.  “An Overview of the Congressional Record and its Predecessor Publications”.  http://www.llsdc.org/cong-record/
●	People and organizations
○	W3C proposed organizations standard:  
○	Springer, Michelle, Beth Dulabahn, Phil Michel, Barbara Natanson, David Reser, David Woodward, and Helena Zinkham, “For the Common Good: The Library of Congress Flickr Pilot Project”, online at http://www.loc.gov/rr/print/flickr_report_final.pdf .
●	Encoding of transcripts
○	LegalXML work on transcripts, at http://www.legalxml.org/workgroups/substantive/transcripts/wd_10002.shtml
○	Text Encoding Initiative, “Transcriptions of Speech”, at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TS.html
●	Technology
○	Nadeau, David, and Satoshi Sekine, “A survey of named entity recognition and classification”. Available at http://liicr.nl/IkzHJ0 .
○	
Appendix: MARC data for the Congressional Record

Below we see a tabular version of the MARC 21 record for the daily edition (compiled editions generally are described separately) from Cornell University Library’s Voyager catalog. MARC 21 is elderly, complex and hard to understand.  For the uninitiated, the easiest approach is to describe the numeric tags as blocks of data:

	00X-0XX carry numbers, identifiers, dates, codes, etc. For government documents there are extra numbers, representing the GPO identifiers, and those show the GPO as the source of those numbers. Each tag has a separate definition, each combination of tag/subfield code has a definition as well .
 	1XX-3XX are variable length descriptive fields, denoting the responsible body (110), the various title and edition statements (2XX), and extent, frequency plus start/stop information descirbing the duration for which the publication is available (3XX). Some of the titles are related to other fields: the key title 222 is tied to the 022 ISSN (the International Standard Serial Number).
	5XX are various note fields, with 500 being a general note and the other tags specially defined notes. 
	6XX fields carry information on the ‘aboutness’ of the record, whether that might be a topic, a person, an organization, etc. Each of these carries a separate tag, the second and third integer giving its ‘category’ (e.g., a 600 identifies the record as about a person). This record also has a 651 field, which is geographic, though it may have topical, geographic, or genre subdivisions as well.
	7XX fields carry a variety of information, in this record a number of parallel editions (‘permanent ed.’, ‘biweekly ed.’) as well as preceding or succeeding titles. These kinds of fields generally imply a ‘linkage’ (expressed by a text string) between multiple editions or titles. In many cases there may be strings of alphanumeric values in subfield w, which are not identifiers of actual resources in the sense that we’ve been discussing linked data, but instead identifiers of a related descriptive record within a particular library system. The subfield x data in one of the 787 fields is the International Standard Serial Number [http://www.issn.org/2-22635-What-is-an-ISSN.php], assigned by an the international ISSN agencies, is the only one in this record that could be treated as an identifier in a linked data environment.  
	8XX includes information on specific library holdings of a serial title, plus things like URLs for web access of various kinds, for a digital title itself. The 8XX block overlaps between the bibliographic description and the MARC Holdings Format, which includes specific holdings information paired with captions, as well as indexes and supplementary materials. This area has been particularly volatile in the context of the switch from paper to digital publishing.

000	03745cas a2200697 a 450	
001	1610613	
005	20111107132355.0	
008	790612c18739999dcudn1p f0 a0eng	
010	__ |a 80646573 |z sn 80012446	
022	0_ |a 0363-7239	
030	__ |a CGLRB3	
032	__ |a 087390 |b USPS	
035	__ |a 1610613	
035	__ |a (OCoLC)2437919	
037	__ |a 752-002-00000-2 |b Supt. of Docs., U.S. Govt. Print. Off., Washington, D.C. 20402 |f paper	
037	__ |a 752-029-00000-8 |b Supt. of Docs., U.S. Govt. Print. Off., Washington, D.C. 20402 |f MF	
040	__ |a DLC |c COO |d NSD |d COO |d NSD |d OCL |d GPO |d DLC |d SER |d GPO |d OCL |d NSD |d OCL |d GPO |d NSD |d HUL |d GPO |d NSD |d GPO |dNST |d DLC |d GPA |d NST |d DLC |d GPO |d DLC |d IUL |d GPO |d DLC |d GPO |d OCLCQ |d GPO |d MvI	
042	__ |a nsdp |a lc	
043	__ |a n-us---	
050	00 |a KF35	
074	__ |a 0994-B	
074	__ |a 0994-C (MF)	
074	__ |a 0994-B (online)	
074	__ |a 0994-C (online)	
082	__ |a 328.73/02	
086	0_ |a X/A.	
086	0_ |a X 1.1/A:	
110	1_ |a United States. |b Congress.	
210	0_ |a Congr. rec. |b (Dly. ed.)	
222	_0 |a Congressional record |b (Daily ed.)	
240	10 |a Congressional record (Daily ed.)	
245	10 |a Congressional record : |b proceedings and debates of the ... Congress.	
250	__ |a [Daily ed.].	
260	__ |a Washington : |b [Supt. of Docs., U.S. G.P.O., distributor,	
300	__ |a v. ; |c 30 cm.	
310	__ |a Daily (when Congress is in session)	
362	1_ |a Began with 43d Congress, Special session of the Senate of the United States (Mar. 4, 1873).	
500	__ |a Beginning with the 80th Congress, 2nd session (Mar. 1947) includes section called: Daily digest.	
500	__ |a Description based on: 96th Congress, 1st session, v. 125, no. 1 (Jan. 15, 1979); title from caption.	
500	__ |a Vols. for <1986- > distributed to some depository libraries in microfiche.	
525	__ |a Appendices issued for the 43d Congress (1873)-83d Congress, 1st session (1953).	
530	__ |a Available on microfilm from University Microfilm Library Services. Some issues also available via the Internet on searchable database from GPO Access with title: Congressional record main page. Address as of 9/27/96: http://www.access.gpo.gov/su%5Fdocs/aces/aces150.html; current access is available via PURL.	
580	__ |a Indexed in: Congressional record index, issued in print and in an online version.	
580	__ |a Issued in "Permanent edition" (red bound) and "Biweekly edition" (green bound); "Biweekly edition" discontinued with the 98th Congress. Also available from FD, Inc. on CD-ROM with title: Congressional record on CD-ROM.	
650	_0 |a Law |z United States |v Periodicals.	
651	_0 |a United States |x Politics and government |v Periodicals.	
775	1_ |a United States. Congress. |s Congressional record (Permanent ed.) |x 0883-1947 |w (DLC) 12036438 |w (OCoLC)5058415	
775	1_ |a United States. Congress. |s Congressional record (Biweekly edition)	
775	1_ |a United States. Congress. |t Congressional record. |c Microfilm ed.	
780	00 |a United States. Congress. |s Congressional globe (Permanent ed.) |w (DLC) 12036437 |w (OCoLC)1716190	
787	1_ |a United States. Congress. |t Congressional record on CD-ROM |x 1068-5448 |w (DLC) 93644293 |w (OCoLC)27697752	
787	1_ |t Congressional record index |w (DLC)sn 85008544 |w (OCoLC)2428236	
787	1_ |t Congressional record index (Online) |w (DLC) 2001230907 |w (OCoLC)45743824	
850	__ |a AU |a DLC |a InU |a MH-L |a MoKU |a NN |a OU |a PU	
856	41 |3 Searchable database: |u http://purl.access.gpo.gov/GPO/LPS1671	

Committee Documents: Modeling Concerns
Thomas R. Bruce, Legal Information Institute (tom@liicornell.org)
Diane Hillmann, Metadata Management Associates (metadata.maven@gmail.com)
John Joergensen, Rutgers University School of Law (jjoerg41@gmail.com)
Jon Phipps, Metadata Management Associates (jonphipps@gmail.com)

Introduction

The documentary record of Congressional committee activity takes four main forms:
●	reports of committee activity in the Congressional Record, which we discuss elsewhere;
●	transcripts of Committee hearings, with supporting documentation.  This documentation may occur in text and multiple multimedia formats; for example, as audio and video recordings made by Congress itself, as well as by outsiders.  Hearings may be about a particular bill, or about more general issues within the committee’s purview.
●	committee reports, which may contain the “reporting” (in the legislative sense) of a particular bill, provide general reports of committee activity, or relate to budgetary matters.
●	committee prints, which are a grab-bag of materials that the committee has ordered to be printed for a stupefying range of reasons.

This document discusses committee hearings, committee reports, and committee prints. We begin with discussion of a few modeling concerns related to the committees themselves.
The Committees 

Most modeling issues related to committees have already been discussed in our paper on people and organizations.  Some specifics related to Congressional committees need discussion here.
Identifiers
A legacy system of committee identifiers is in use in FD/SYS MODS files.  It appears that committees are also classified into different types (see example below).  We have also seen examples of committee and subcommittee codes used by the House as part of the document identifier scheme in use on docs.house.gov.  We do not know whether the Senate has such a system in place.  Any or all of these might form a basis for a system of identifiers, or at least provide a census of what is needed.   The identifier system seems to  extend to conference committees or other ad-hoc groups not chartered by the rules of the House or Senate, but it seems to do so incompletely and is in need of close, comprehensive examination.  While “special” or ad-hoc committees seem to be well identified,  conference committee documents are always identified using House identifiers, and joint committees take the identifier of the related House committee or else omit an identifier altogether.  In the latter case, the joint nature of the committee is indicated in the filename used for the document, so apparently more than one pair of hands is at work.
“Chartering” information and subject matter classification
Committees derive their power from grants of jurisdiction written into the rules of the House and Senate.  The rules are frequently changed, but in practice the jurisdiction of each standing committee does not vary much over time, with each committee having jurisdiction over an average of 15 topics. Items of legislation, some of which are jurisdictionally ambiguous, are referred to committees by parliamentarians, who have considerable discretion.  That has led one observer to note that there is such a thing as “common law” committee jurisdiction, developed on the basis of how particular subject matter has been referred in the past.  Thus, it is possible that subject-matter jurisdiction of committees is a much more dynamic system than one might suspect from the rules, and in need of the same kind of evolutionary vocabulary management we have called for elsewhere.  ### clarify difference between topics on the one hand and charge-text on the other
Other information about committees
Standing committees vary widely in the way that they conduct their business (for example, in the way that they issue subpoenas, take testimony, and hold hearings as part of investigations).  Detailed modelling of these differences lies well outside our scope, but could be accommodated as a natural extension of our model.  As with other metadata that stems from the (very changeable) rules of each chamber, stability is a concern, as is the cost of maintenance of the model as the level of complexity rises. 

A simple classification of committee meeting types is in use in the House (we do not know what the Senate does).  It is used primarily to characterize documents -- that is, to say what sort of meeting gave rise to a particular document.
Conference committees
Conference committees are more ad hoc in nature than standing committees.  They also give the conferees the title of “manager”, though this is really just a special term for any ordinary member of Congress appointed to a conference committee, and does not carry any special duties, status, or responsibility.  In general, conference committees differ significantly from others in that they have a short lifespan, extremely variable composition, and tend to represent both political parties and the committees responsible for the original legislation in different ways from committee to committee, and less consistently than standing committees do.  But none of these differences in composition would call for any difference in modeling strategy.
Modeling of issues in disagreement; discovering the committee charge

There are a surprising number of ways for the chambers to resolve differences over a particular bill, all with political ramifications, and conference committees are only one of them.  It is difficult to discover whether there is any consistent, reliable, machine-readable source of information about the exact matters a conference committee is meant to consider -- that is, whether there is ever any encoded document that expresses exactly which points within the legislation are in conflict between the two chambers and need to be considered by the committee, from which one might populate a detailed model.  Because researchers and observers have great interest in knowing what specific issues are meant to be resolved in the committee, there are good reasons for modelers to wish to go beyond simply attaching a list of identifiers for the conflicting bills, resolutions, or amendments under consideration without more granular detail. However, it may not be possible to do so if there is no parseable documentary record of a detailed committee charge.

In general, the best source of specific information about what the committee has done is the explanatory statement accompanying the conference report.  These do not appear to detail what was done in a way that would be amenable to automated extraction, which in any case would be a matter for XML markup rather than a metadata model.  As with the Congressional Record and some other corpora we have examined, it may be that improvements in document encoding need to be made before there is much that a metadata model can do to represent detailed subject matter. 
Committee hearings
Hearings are a rich source of information about Congressional interests and activities. From our perspective, they are perhaps most interesting because they involve a hugely expansive range of actors and subject matter.
Existing metadata sources
GPO provides metadata for most government publications distributed via the Federal Depository Library Program (FDLP), including hearings, and has done so since printed document days, prior to the advent of digital resources. For traditional library records provided in the MARC format, separate records for print and digital forms are provided. The MARC records for the digital version include a link to a PDF from the GPO FDsys system (interestingly, the link in the record itself uses an FDLP domain, which redirects to FDsys).

When searching directly through FDsys, a user choosing a particular document is offered a choice between a text version of the hearing document, the aforementioned PDF, and a button for ‘MORE’. The ‘MORE’ button resolves to summary page featuring links to the text and PDF versions of the document, as well as MODS metadata (labeled ‘Descriptive Metadata’), PREMIS (labeled ‘Authenticity Metadata’), and an ‘all’ option (labeled ‘All Format & Metadata Files’).

Interestingly, the ‘All’ option does not include MARC information, which suggests that it is (correctly) considered specialized information.

The MODS data is used to create the summary page. Some of the information collapsed into the text block for Committee members is parsed separately in the MODS XML (for instance the information on Congressional members is included in the exact phrasing used in the Members block above). There is a separate portion of the record that explicitly lists those Members in attendance, and the text string used is the same as used for all committee members, whether present at the hearing being described or not (ex.: ‘Susan A. Davis of California’) but with different attributes. The separate containers use different roles for the Members: ‘COMMMember’ for all the committee members, and ‘committee member in attendance’ for those actually present for the hearing. The presence of these named roles, and the stark difference between how they’re expressed, suggest that the vocabulary used is internal, and not optimized for Semantic Web applications.

The MODS records contain substantial redundancies -- in addition to the two member containers, there are also two each for witnesses -- but most of the content of the metadata is text strings, albeit strings that could be parsed fairly easily for connections and correspondences to unique IDs maintained elsewhere. Bill numbers are also recorded redundantly, both as text appearing on the publication, and as more structured data. 

There are several interesting disparities between the MARC and MODS records: MODS has information about witnesses but lacks topical information; MARC includes topical information but lacks witnesses. Both describe the Committee as an ‘author’ (110 field in MARC) which probably reflects traditional library practice around something called ‘corporate authorship’, a notion that when considered objectively seems odd at best, and misleading at worst. One difference that seems minor but may have major implications in future is that the MODS record lists the first part of the title only, in all caps with the initial article retained (without an easy way to sort them without the article in lists), and the MARC records title (with the usual MARC second indicator method of ignoring initial articles) plus subtitle and responsibility information included on the title page, in ‘title case’. This explicitness in title expression in MARC has traditionally been designed to be transcribed exactly, both to limit the judgment required of a cataloger, and to make the information more unique, to differentiate the described document from similar documents. This is particularly important with government documents, where prescribed uniformity in title presentation means that the words that differentiate occur further down in the text string than is usual in non-governmental publications.

An example of how the expression of this data might change using a statement-based linked data model suggests some steps that might be taken to get from current usage to a more generally useful and efficient strategy.  In the example below, there are two containers, the first for the Committee, the second for the member:

<congCommittee authorityId="hsed00" chamber="H" congress="112" type="S">
<name type="authority-standard">Committee on Education and the Workforce</name>
<name type="authority-short">Education and the Workforce</name>
</congCommittee>
<congMember chamber="H" congress="112" quality="low" role="COMMMEMBER" state="AZ">
<name type="parsed">Raul M. Grijalva of Arizona</name>
</congMember>

In both cases the content between the brackets is text, in a particular display form, which is then transferred into a display page, presumably with some XSLT handling. Behind the scenes we can see efforts to provide ‘name types’ to ensure consistency, and it may be that the text is wrangled from some other database for efficiency and quality control reasons. If so, that database is primarily used as most library authority files are used: to provide consistent text strings to systems that ‘post’ those strings to end users. The XML data exposed within the system carries those same strings, as noted, and thus are of limited use for external users wishing to provide different services using data from a variety of sources.

For linked data applications, reliance on this sort of text wrangling is frowned upon, since in the Semantic Web world, text strings are considered ‘dead ends’, leading users nowhere and useful only for displays. Much preferred are URIs that reference information (in the case above legislator names and Congressional committees). With IDs for the Committee instead of display text, the user can access information about the Committee (its members, its history, etc.), and the description of the Committee itself will carry the various names used, whether it’s a House or Senate Committee, and any other relevant information. Similarly, the Legislator ID would lead to information about the member, when they were elected and from what district, their party and voting history, and other organizations with which they are affiliated. In the MODS example above, much of the data expressed is simultaneously too much and too little to be useful. In our model, a URI referring to a particular committee would lead to information stored once, containing the information that applications require for linking and display. 

While it is certainly true that THOMAS, creaky as it may be, provides some useful document-to-document linkages, they are quite shallow.  In addition, the context provided in the aggregated displays seems to be created ‘on the fly’ and cannot be referenced outside of THOMAS.  In most cases, when a document--a bill, for instance--is linked to, a user cannot expect links within the bill to take them further, but must instead construct an additional search to find answers to their questions. Linked data is expected to allow a user to follow their nose, no matter where they start their quest. 

Certainly, the most important reason for analysis of the legacy formats is that in a linked data environment, what’s already available can be reused and re-aggregated to increase the usefulness of the whole. For example, the listing of committee members in the MODS records become unnecessary, because committee membership is maintained in a separate structure, where the date of member comings and goings is managed, thus allowing a time-based roster to be available at any time. The listing of members present, however, is still important, although with linked URIs rather than text strings. In a linked data environment, it becomes possible to look at the data from two directions. For instance, with links one can not only see whether a particular member was present at a particular hearing, but also that member’s participation in an array of hearings over time, something that researchers would certainly find useful. 

Building Out and Beyond Legacy Data

When Linked Data is discussed with creators and managers of legacy data, whether built in MARC, MODS, DC or any other standard element set or schema, the first questions have to do with costs. How can such changes possibly be contemplated in an environment of diminishing resources? But that response assumes that there are fewer costs in maintaining the extensive workarounds and bespoke applications currently underpinning traditional data. Such a response also denies the the potential for outsiders to provide sources of data that do not need to be re-created and managed by the library. Granted, such a shift will take considerable time and effort directed at planning, retooling, re-skilling, and implementation. But the implications of failing to make these changes -- continuing to maintain data in our current silos without connecting to the vast amounts being created on the Web -- must be figured as a cost as well.

Future methodologies require attention to issues that do not occur in legacy data silos. Changing the ‘atomic’ level of concern in data from the ‘record’--the aggregated collection of attribute-value statements made about a particular resource--to the statements themselves (in the form of RDF triples, where the resource ID occurs in every statement), also requires attention to issues like ‘provenance’: the who, what, where, and when that tells us where each statement came from. These ideas are not new, but they are critical to managing data in a much less siloed environment, where the focus is not just local applications, but instead integrating web data in what we do, and making our data attractive to other communities doing the same thing.

But it’s usually not questions about how data is managed that raise the most concern. Rather, the most difficult issues are those that surround integration of new data sources into data streams originally built within limited definitions of trusted data. The infrastructure that now surrounds distribution of MARC data assumes that evaluation, quality control, harvesting and distribution will happen via a central node. Because such a central node for linked library data does not exist (and may never exist), those institutions that see value in the exploration of external sources are on their own. They need to think about how to manage those explorations in ways that inform policy, build skills and tools, manage and evaluate improvement strategies, and document results (and redistribution) in ways that can be replicated and adapted by other institutions. The past forty plus years of MARC database-building has taught us that data built collaboratively and distributed widely costs everyone less, and there’s every reason to believe that those lessons apply equally to the new environment.

The diagram below gives a broad view of the planning tasks involved in re-thinking metadata management within an organization, and how they relate. The four boxes at the second level represent the categories, and also a overview of the steps that metadata goes through at the organizational level. So, for instance, a ‘Harvest/Ingest Plan’ would include the sources of metadata to be collected, the technical environment for harvesting and managing the flow of metadata into the data stores the organization has built, and, most likely, a notification and logging system to allow a manager to view results of the process. The ‘Metadata Evaluation’ step is critical--it’s where the decisions about the suitability of the data are made, and where we determine what kinds of improvements need to be run on the data if it is to reach the level of quality required. If, as is likely, the same data will be reharvested as it changes, the improvement routines will need to become an integral part of the process. Because there may be more than one routine (improvement services are easier to manage in smaller chunks), there may be an optimal ordering that ultimately should an automated stack for production processing. 

Testing, monitoring and re-evaluation are always necessary, since the data providers may well change their strategy, their schema, or any other part of their data, without notice. In addition, as the data is used, different improvements might be substituted, or added to the stack.  And finally, in a linked data environment, data is always redistributed so that others may find new uses for it, apply different improvements, or combinations with other data, or experiments. Re-distribution requires that we inject our own provenance information, because downstream users of the data need to know what has been done to the data by each service that has handled it.  It is by understanding those processes that the essential trust between data providers and users is grown.

Issues in the modeling of committee hearings
Certain modeling problems, for the most part discussed elsewhere in our work, become more prominent in the context of committee hearings.
Identifiers
Hearings provide a good example of a problem we discuss more extensively elsewhere:  the need to separate the “unique identification and resolvability” functions of identifiers from their function as accessors under different usage scenarios.  Often, we mistakenly believe that objects can have only one identifier, and hence that it must serve both as a unique identifier and as a semantically-laden string that locates the object within a series of nested collections -- for example, http://congress.gov/house/committees/cha/reports/2012-05-09/whatever_report.pdf.  In reality, a completely opaque string  such as “4397pZ12x” can serve as the unique identifier, and as many accessor URIs as needed can be directed at that identifier -- for example, the more reader-friendly URI just given might resolve to http://congress.gov/house/committee_reports/4397pZ12x , and point to the same object.  The systems needed to do so are inexpensive, both computationally and in terms of effort.

It makes sense to us to use some sort of accession number (probably derived from the number of the Congress, the year, and the committee identifier) as the basis of the “unique identifier” function.  Serialization of the numbers would be based on the order in which hearings are created (so to speak) rather than in the order in which they ultimately occur in calendar time, since we imagine that scheduling changes are frequent.   “Accessor”-type IDs might be designed to facilitate viewing by useful subcollections with different sorting orders, including collection by committee, subject, or date range.   Some examples appear in the table below.

http://example.gov/112-2012-cha-007 	“opaque-ish” URI with enough semantic clues to allow sanity checking by inspection	
http://example.gov/house/committees/cha/reports/2012-05-09/112-2012-cha-007		accessor URI, report collected by chamber, committee, document type, and date	
http://example.gov/committees/billreports/111-456/house/cha/112-2012-cha-007		accessor URI, report collected by bill, chamber, and committee	
http://example.gov/committees/reports/112/2/house/cha/112-2012-cha-007		accessor URI, report collected by congress, session, chamber, and committee	

“Aboutness” vocabulary concerns
Concerns about the evolution of subject-matter vocabularies, discussed elsewhere, are particularly important for committees.  There are two reasons for this.  First, committees range widely in the subject matter they consider.  Second, the “aboutness” of committee hearings can be expressed in at least two ways, each quite different and having some tricky aspects.  

First, hearings are often “about” a bill or resolution. But simply referring to the identifier for a bill may not provide “aboutness” information that is very specific. As we have remarked elsewhere, bills themselves are often “about” a grab-bag of subjects.  Ideally, each hearing resource would carry its own topical information without the requirement that it ‘match’ other resources in a chain of resources linked by a “relatedness” property. That would furnish the optimal chance for a user to find resources, because a “hit” on a particular subject-matter keyword would place the user in a position to “follow her nose” to related resources that would then furnish other subject terms for investigation. Traditional subject cataloging limits the number of subject terms used, but in the current environment, with no requirements to print catalog cards, that limit makes little sense.

Second, hearings are not always about bills or resolutions; they may be about issues that the committee feels to be within its purview, but for which there is no bill or resolution under consideration.  And committees have responsibilities beyond bill-wrangling. In situations where the committee is exercising its oversight responsibilities, the hearings may be explicitly investigative.  Either way, the notion of a hearing ‘inheriting’ its topics from a related resource such as a bill, and therefore not requiring its own analysis and application of topics, is inherently dangerous, based at it is upon trust that the legislature has remained on-topic throughout.
“People” problems
Hearing witnesses are exceptionally interesting to members, staffers, and researchers of all descriptions.  Among our use cases are examples that involve researching the backgrounds and affiliations of hearing witnesses, tracking their appearances across time and across multiple committees and topics, and so on.  Elsewhere, we use them as a flagship example of a group for which linked data from an outside source such as the New York Times, dbPedia, Freebase, or other rich sources of biographical data would be desirable.  That would, of course, involve difficult policy decisions in deciding which databases are considered “linkworthy”, and perhaps some change in procedures within the committees themselves.  On that point, we believe that definitive identifiers for non-Member witnesses would best be obtained or assigned as part of the process of assembling Truth in Testimony forms and written testimony in advance of the hearing.  Indeed, the Truth in Testimony forms and the CVs that accompany them provide rich information about witnesses, and should be provided with identifiers and publicly associated with both witness and hearing.

Witness information currently appears in the MODS files associated with hearing transcripts in FD/SYS, but it could be improved in a number of ways.  The most obvious two would be to separate witness affiliation information from the witnesses’ names, and to (where available) add URIs permitting linkage to outside data collections as described in the previous paragraph.
“Documents” submitted in testimony
Testimony that witnesses submit in advance of a hearing is invariably written, generally taking the form of word-processing documents or PDFs. These are readily described using familiar properties such as those in DCMI.  However, witnesses frequently introduce multimedia materials such as graphics, PowerPoint presentations, or videos as part of their “live” testimony during the hearing.  Such items become part of the committee’s permanent record of the hearing, and are often offered on the committee’s web site (it is not clear to us whether or how they are transmitted for archiving).   The House specifies document naming conventions -- essentially, an identifier scheme -- for such items, categorized as “documents that may accompany a witness statement”.  
Multimedia recordings of hearings
Most committees routinely record hearings in both audio and video formats, which poses interesting problems for creating descriptive relationships. Beginning with microforms and continuing through the digital publishing revolution to the present, the library community has struggled with similar issues. Microforms, as fairly simple reproductions, were simply added to print records, but this strategy came apart with the advent of digital ‘versions’ that were not strict reproductions, although they might appear to be at first blush.

Given that the proliferation of versions in libraries has again exploded with the advent of e-books, attempts to treat these kinds of multimedia versions by determining the ‘first’ (or most important) version as the one that all other records “follow” -- that is, are declared to be versions of -- have largely been abandoned.  That leaves treating each one as a separate resource, and creating appropriate links between them, as the only realistic option. 

Our model starts with the most common situation, where printed and digital versions of the same resource exist in parallel. Each is described according to what it is--with descriptive properties that may or may not be the same in each (pagination is often the same, format is not). In those situations, the relationships are simple, because the content is virtually identical. Less obvious (but still relatively simple since the content itself is still the same) are the situations where one digital version is embedded in the digital CR and referenced by page, and a third version, also text but stand-alone, is also provided.

That simple strategy breaks down when there are multitudes of formats to contend with, the relationships are not just between reproductions, and the contents are inherently different. For example, as noted above, committee hearings may be available in print, on video recordings, as well as audio recordings. Whether a user wants one or another of these often depends on their task: do they want to quote something in a written report of some kind, or do they want a video clip for a news report or a YouTube polemic, or do they wish to listen to the hearing while jogging or driving? To complicate things further, each of these ‘versions’ may contain additional material (say, written witness testimony) which is not reflected in the multimedia files. Under a strict interpretation, these separate items are not ‘versions’ at all, once the content has begun to diverge.  But in a discovery-oriented system, these ‘version-like’ relationships enable users to choose from among those available for the best fit with their tasks, without incurring, for the collection owner, the expense of creating detailed descriptions of the differences in every case. 

With the digital/print simple version strategy in mind, we’ve essentially created subproperties to dct:hasVersion by using hasDigitalVersion and hasPrintedVersion. We don’t use dct:isVersionOf (the reciprocal relationship to dct:hasVersion) in this scenario. A strategy where the version relationships do not carry the format of the version being linked to is likely to scale better as new kinds of resources become available. In that second possible scenario, we provide more generic links (hasVersion and isVersionOf) and rely on the type and format information of the resources at either end of the relationship to enable filtering and sorting.
Committee reports
Reports from standing committees of the House and Senate are, for the most part, reports of recommendations regarding bills and resolutions referred to the committee for consideration.  Reports from conference committees (as described above) often consist of a short explanatory statement accompanying merged legislative text that represents a reconciliation of issues between chambers.  Executive reports come from the Senate Foreign Relations Committee, and  concern themselves with matters involving treaties.  In addition, there are numerous other reports that come from committees -- for example, reports of actions taken by ethics committees with respect to particular individuals, or reports on the activity of the committee itself.  

Reports including recommendations regarding legislation are part of a package of documents that emerges from the committee process.  That package may include accompanying amendments and other documents, making it important to model that “relatedness” information along with the actual document that constitutes the report.  In the case of legislation with budgetary impacts, the accompanying documentation is both required and extensive.
Existing metadata sources
As with other committee documents, GPO maintains extensive MODS metadata for committee reports.  Interestingly, it seems to be metadata only for the report itself, and not for the entire package that normally accompanies the report, which would include at a minimum any reported amendments.  The text of the recommendation may include a mention of (for example) an amendment that the committee wishes to adopt, but it does not contain any identifying reference for a document containing the amendment itself.  Other problems with MODS metadata were noted above in the section on committees in general.
Committee prints
Committee prints are, for the most part, third-party information submitted as supporting material for the consideration of legislation.  They may include, but are not limited to
●	draft reports and bills
●	statistical information
●	investigative reports
●	historical reports
●	situational studies
●	confidential staff reports
●	hearings
●	legislative analyses
●	reprints representing the current state of statutes, rules, and so on

Generally they represent the work of staffers, CRS researchers, or other persons who are not themselves committee members.  

Metadata issues
People
As was just stated, committee prints are the work of staffers, researchers, and outsiders.  In that respect, the authors of committee prints -- like hearing witnesses --  fall outside the scope of traditional name-authority controls.  Once again, there are policy decisions to be made about how much authorship information is needed, and whether or not linked data from external sources represents a good bargain.
Identifiers
Senate committee prints have an existing system of identifiers.  House committee prints do not.  The Senate system appears to use per-Congress accession numbers, and no doubt a similar system could be put in place for House committee prints as well.  GPO appears to assign an “access ID” to all committee prints that would serve as an opaque identifier, somewhat strangely divided into subcollections for House, Senate, and joint committees with a fourth subcollection reserved for prints from the House Ways and Means Committee.  

We imagine the latter to be a proxy classification used to distinguish materials related to the budget. We find that approach inherently dangerous, given that it embeds assumptions about process and committee charge that may be more or less volatile, and that it might cause a user to assume that there is no need to look elsewhere. Where the current system in use by GPO represents budgetary/non-budgetary as a kind of binary choice, we believe that a more expansive vocabulary of non-exclusive genres (budgetary, investigative, specified-by-statute, for example) may be better ### add language indicating that we’re not competent to do it.
Categorization and subject matter
The subject-matter scope and possible number of genres for committee prints are both so large as to be stupefying.  There may, however, be some useful distinguishing criteria that could be built into an extended model at some future point.  For example:
●	genre properties, along the lines of the list given above;
●	whether the document is a mandatory or optional adjunct to the legislative process
and so on.  
It seems to us as though this particular corpus is trapped in a bit of a Catch-22. Its size and diversity makes it appear so intractable that any attempts at categorization or organization would lose out in any cost-benefit analysis; it would be far too expensive to assign categories or other metadata using traditional techniques.  As a result, there’s a general belief that there is no use case that can realistically be fulfilled, reinforcing the idea that somehow the game is not worth the candle. That may not be true if newer technologies are brought into play.  It could simply be that this corpus is overdue for analysis using text-mining and categorization techniques. Its apparent (and intimidating) diversity may contain useful patterns worth capturing if less expensive methods can be found.  Even broad categorizations that enable the user to exclude large swaths of material from search results would be useful.
References
Conference committees
●	Rybicki, Elizabeth. Resolving Legislative Differences in Congress: Conference Committees and Amendments Between the Houses.  CRS report at http://assets.opencrs.com/rpts/98-696_20081126.pdf 
Metadata management
●	Hillmann, Diane, Naomi Dushay and Jon Phipps. Improving Metadata Quality: Augmentation and Recombination, available at: http://dcpapers.dublincore.org/index.php/pubs/article/view/770
●	Phipps, Jon,  Diane I. Hillmann, and Gordon Paynter. Orchestrating metadata enhancement services: Introducing Lenny, available at: http://dcpapers.dublincore.org/index.php/pubs/article/view/803

Other legislative metadata work from the LII
●	A Data Model for the Congressional Record: Overview and Analysis, at http://liicr.nl/Mq2fTu
●	Design Issues for a Legislative Data Model, at http://liicr.nl/A2l8sa
●	People and Organizations in a Legislative Data Model, at http://liicr.nl/IDdY4i 

Modeling Legislative Information Post-Passage
Thomas R. Bruce, Legal Information Institute (tom@liicornell.org)
Diane Hillmann, Metadata Management Associates (metadata.maven@gmail.com)
John Joergensen, Rutgers University School of Law (jjoerg41@gmail.com)
Jon Phipps, Metadata Management Associates (jonphipps@gmail.com)
Introduction
This document lays out some design criteria for metadata that applies to compilations of enacted legislation, and to the tools commonly used to conduct research with them.  Large corpora discussed here include Public Laws, the Statutes at Large, and the United States Code.  This “post-passage” category also takes in signing statements, and -- perhaps a surprise to some -- a variety of finding aids.  Finding aids receive particular attention from us because
●	they are critically important to researchers and to the public;
●	they are largely either paper-based,  or electronic transcriptions of paper-based aids. They provide an interesting illustration of a major design question: whether legacy data models should simply be re-cast in new technology, or rethought completely.  Our conclusion is that legacy models (especially those designed for consumption by humans) typically embody reductive design decisions that should be rethought.
●	they illustrate particular problems with identifiers. In particular, confusion between volume/page-number citations as identifiers for a whole entity, versus their use as references to a particular page milestone, is a problem. So is alignment with labels or containers that identify granular, structural units like sections or provisions, because such units can occur multiple times within a single page.

We begin with a discussion of signing statements, which might be considered the “first stop” after legislation is passed.
Signing statements
Overarching issues
Existing metadata
Signing statements have been used by many presidents over the years as a way to record their position on new legislation. For most of our history, their use has been rare and noncontroversial. However, during the George W. Bush administration they were used to declare legal positions on the constitutionality of sections of laws being signed.
    
Since they had never previously been controversial, there had been little interest in collecting or indexing these documents in any systematic manner. With the change in their use, this attitude has changed, and there is a need to easily and quickly locate these documents, particularly within the context of the legislation to which they are linked.

Currently, Presidential signing statements are collected as part of the Weekly Compilation of Presidential Documents and Daily Compilation of Presidential Documents. These are collected and issued by the White House press secretary, and published by the Office of the Federal Register. As they are not technically required by law to be published, they do not appear in the Federal Register or in Title 3 of the Code of Federal Regulations.

Although they appear in the daily and weekly compilations, they are not marked or categorized in any particular manner. In FD/SYS, the included MODS files includes a subject topic “bill signings”, marking it as related to that category of event.  “Bill Signings” is also included in the MODS <category1> tag that exists in presidential documents. That designation, however, also will be used for remarks as well as formal signing statements. In addition, it is unclear whether that designation has been used with any consistency.  The MODS files for signing statements include no information designating the document as a signing statement, but only as a “PRESDOCU”. The MODS files do, however, have references to the public law to which they refer. They will also have a publication date that will match with the date on which the president signed the subject law.

In order to make signing statements findable, the existing links to relevant legislation which are already represented in the GPO MODS files should be built into the model, along with the publication date information, and designation of the president who is issuing the statement.  In addition to that, however, the categorization of a signing statement as a signing statement needs to be added in the same fashion in which we have categorized other documents, and implemented with consistency. If the implementation and study of signing statements continues as an important area of user inquiry, they will need to be identifiable.

Finally, as with all such documents, there always a desire to assist the researcher and the public by including evaluation aids.  It is tempting, for example, to indicate whether a statement includes a challenge to the constitutionality or enforceability of a law.  We believe, however, that it would be a mistake to build this into the model.  If interpretive aids of this kind are themselves properly linked to their related legislation, they will be easily found.

We have singled out signing statements because they appeared prominently among use cases we collected and in other conversations about the “post-passage” corpora.  In reality, many other presidential documents relate closely to legislative materials before and after passage.  We will consider them in later sections of this document as we encounter them in finding aids.
Forms of enacted Federal legislation
Enacted Federal legislation is published by many groups in many formats, including (among versions published by the legislative branch) Public Laws, the Statutes at Large, and the United States Code.   Privately published editions of the US Code are also common (and indeed prevalent), either in electronic or printed form, and it is likely that their use exceeds that of the officially published versions.
Overarching issues
How do post-passage materials relate to our model?
First, as to necessity: research needs have no particular respect for administrative boundaries, and many will wish to trace the history of a law from the introduction of a bill through to its final resting place in the US Code.  As to means, we’ve incorporated a series of properties that describe the codification of particular legislative measures (or provisions); they might be applied at the whole-document or subdocument level; this essentially replicates what is found in Tables I, II and III as we describe them below.  This area of the model might, however, require extension in light of more detailed information about the codification process itself.  We are aware, for example, that current finding aids and the data in them make it far easier to find out what happened to a particular provision in a bill (forward tracing) than it is to find out where a particular provision in the US Code came from (reverse tracing), and that the finding aids do not support all common use cases with certainty.
Updating
Virtually every document we have encountered in our survey of legislative corpora becomes “frozen” at some point, either by being finalized, or by being captured as a series of sequential snapshots.  That is not the case with the US Code, which is continually revised as new legislation is passed.  This creates a series of updating problems that involve not only modeling the current state of the Code, but also: 
●	tracking new codification decisions
●	tracking changes in the state of material that has been changed, moved, or repealed,
●	revising and archiving metadata that has been changed or rendered irrelevant by changes in the underlying material
and so on. 

It seems likely to us that there are both engineering and policy decisions involved here.  Certainly the legislative data model needs to have hooks that allow connection to more detailed models, maintained by others, that track codification decisions. Most use cases that look at statutes and ask, “what happened to that statute?” or “where did this come from?” will need those features.  The policy question simply involves deciding whether and how to connect to data developed by others (for example, if it were desirable to trace legislation from THOMAS into the US Code).  As to engineering, it may be simpler in the short run to simply model the finding aids that currently assist users in coping with the print-based stovepipes involved.  That has drawbacks that we describe in some detail later on, but has the advantage of being relatively simple to do at the level of functionality that the print-based aids currently provide.

Whatever approach is taken, maintenance will be an issue; most automated approaches will require the direct acceptance of data originated by others.  At this writing, the Office of the Law Revision Counsel has just solicited proposals for a system to track not only codified legislative text but to record the decisions taken.  Linking to such a system would extend, at low cost, the capabilities of existing systems in very useful ways.
Identifiers and identifier granularity
Bills become Public Laws.  Often, they are then chopped into small bits and sprayed over the US Code.   Even the most coherent bill -- and many fall far short of that mark -- is a bundle of provisions that are related by common concern with a public policy issue  (eg. an “antitrust law”) or by their relationship to a particular constituency (eg. a “farm bill”).   The individual provisions might most properly relate to very different portions of the US Code;  a farm bill might contain provisions related to income tax, to land use, environmental regulation, and so on; many will amend existing provisions in the Code. Mapping and recording of the codification decisions involved is thus a major concern in any model.

The extreme granularity of the changes involved can be seen (eg.) in the Note to 26 USC 1, which contains literally hundreds of entries like the following:

2004—Subsec. (f)(8). Pub. L. 108–311, §§ 101(c), 105, temporarily amended par. (8) generally, substituting provisions relating to elimination of marriage penalty in 15-percent bracket for provisions relating to phaseout of marriage penalty in 15-percent bracket. See Effective and Termination Dates of 2004 Amendments note below.

For our purposes here it is the mapping of the Public Law subsection to a named paragraph in the codified statute that is interesting. It proclaims the need for identifiers at a very fine-grained level.  The XML standard used by the House and Senate for legislation contains mechanisms for markup and identification down to the so-called “subitem” level, which is the lowest level of named container in bills and resolutions (the text in our example is actually at the “subsection” level of the Act).  It seems to us unlikely that mapping is consistently between particular levels of the substructure (that is, it seems unlikely that sublevel X in the Public Law always maps to something at sublevel Y of the US Code).  Sanity checking, then, will be difficult.
US Code identifiers
Identifiers within the US Code provide some interestingly dysfunctional examples.  They can usefully be thought of as having three basic types:  “section” identifiers, which (sensibly) identify sections, “subsection” identifiers, which apply to named chunks within a section,  and “supersection” identifiers, which identify aggregations of materials above the section level but below the level of the Title:  subtitles, parts, subparts, chapters, and subchapters.   

Official citation takes no notice of supersection identifiers, but many topical references in other materials do. Chapters should get particular attention, because they are often containers for the codified version of an entire Act. Supersection identifiers are confusing and problematic when considered across the entire Code,  because identical levels are labelled differently from Title to Title.  For example, in most, the “Part” level occurs above “Chapter” in the hierarchy, and in some, that order is reversed.  It should also be noted that practically any supersection -- no matter how many other levels may exist beneath it in the hierarchy -- can have a section as its direct descendant.  There are also “anonymous” supersections that are implied by the existence of table-of-contents subheadings that have no official name; these appear in various places in the Code.

To our way of thinking, this suggests that the use of opaque identifiers for the intermediate supersections is the best approach for unique identification. Path-based accessors that use level-labels such as “subtitle” and “section” are obviously useful, too,  however confusing they might seem when accessors from different titles with different labelling hierarchies are compared side by side.

As to section identifiers, the main problem is that years of accumulated insertions have resulted in an identifier system that appears far from rational.  For example, “1749bbb-10c” is a valid section number in Title 12.  It may nevertheless make sense to use citation as the basis for identifier construction rather than making the identifiers fully opaque.  As to subsection labeling, it is pretty consistent throughout the Code, and can be thought of as an extension to the system of section identifiers.
Public Laws, Statutes at Large,  and the United States Code
Existing metadata

Traditional library approaches to these complex sets of materials have been very simple: they’ve been cataloged as ‘serials’ (open ended, continuing publications), with very little detail. That allows libraries to represent the materials in their catalogs, and to provide a bibliographic record that acts as a hook for check-in data, and is used to track receipt and inventory of individual physical volumes. In the law library context, where few users access these basic resources through a catalog, this approach has been sufficient, efficient and low-maintenance. 

However, as this information ‘goes digital’, that strategy breaks down in some predictable ways, many of which we’ve documented elsewhere in this project’s papers; the biggest is that much of the time we would like more detailed information about smaller granules than the “serial” approach contemplates. As we make a fuller transition to digital access of this information, these limited approaches no longer provide even minimal access to this critical material.
Finding aids
There are a good many finding aids that can be used to trace Federal legislation through the codification process, and to follow authority relationships between legislative- and executive-branch materials, such as presidential documents and the Code of Federal Regulations.  All were originally designed for distribution in tabular form, at first  on paper, and more recently on Web pages.  In the new environment we imagine, the approach they represent is problematic. It may be nevertheless be worthwhile to model the finding aids themselves for use in the short term, as better implementations require significant analysis and administrative coordination.
General problems
Deficiencies of print representations
A look at the Parallel Table of Authorities [PTOA] shows where the problems are likely to be found.   Like all other tabular finding aids that originate in print, it was designed for consumption by human experts capable of fairly sophisticated interpretation of its contents.  It embeds a series of reductive design decisions that trade conciseness against the need for some “unpacking” by the reader.  Conciseness is a virtue in print, but it is at best unnecessary and at worst confusing when the data is to be consumed and processed by machines.  A couple of examples will illustrate:
●	Some PTOA entries map ranges of US Code sections against ranges of CFR Parts, in what appears to be a many-to-many relationship.  It is unlikely that every pair that we could generate by simple combinatorial expansion represents a valid authority relationship. Indeed, as we shall see, the various finding aids differ considerably in the meaning they assign to a “range” of sections and  in the treatment that they intend for them.
●	The table simply states that there is a relationship between each of the two cells in every row of the table, without saying what it is.  The name of the table would lead the reader to believe that the relationship is one of authorization, but in fact other language around the table suggests that there are as many as four different types of relationship possible.  These are not explicitly identified.

To model the finding aid, in this case, would be to perpetuate a less-than-accurate representation of the data.  As a practical matter of software project planning and management, it might be worth doing so anyway, in order to more quickly provide users with a semi-automated, electronic version of something familiar and useful. But that is not the best we could do.  Most of the finding aids associated with Federal statutes have similar re-modeling issues, and should be reconceived for the Semantic Web environment in order to achieve better results.
Identifier granularity and alignment
Most of the finding aids make use of granular references; in the case of Public Laws, these are often at the section level or below, and in the case of the US Code they are often to named subsections.  The granularity of references may or may not be reflected in the granularity of the structural XML markup of any particular edition of those resources.

The Statutes at Large use a page-based citation system that creates two interesting modeling issues.  First, on its own, a page-based citation is not a unique identifier for a statute in Stat. L., because more than one may appear on one page.   Second, it was not ever thus.  Stat. L. has used three different numbering schemes at various times, each containing ambiguities.  These would be extraordinarily difficult to resolve under any circumstances, and particularly so given the demands of codification we describe later in the section on the Table III finding aid. Taking these two things together, it seems that there is no way to accurately create a pinpoint link between a provision of an Act in its Public Law format and a specific location in the Statutes at Large; the finest resolution possible is at page granularity.  

It would thus seem that the most sensible approach would be to use a somewhat “loose and floppy” relationship like “isPublishedAt” to describe the relationship involved, since the information available from the Table does not really support pinpoint accuracy.   That is unfortunate, in that there are important use cases that need such links.  For example, statutes are frequently described in judicial opinions using citations that refer only to the Statutes at Large, sometimes because the case in question predates the US Code and no other reference can exist, and sometimes because the writer has omitted other citation.  It is effectively impossible to construct a pinpoint link if the cite contains a subsection reference; one has to cite to the nearest page, relying on the reader to find the relevant statute on the page somewhere.  It would be equally difficult to trace through a Stat.L. citation to the relevant provision of the US Code in situations where the USC citation has been omitted.

In short, identifiers in this part of the legislative jungle have two problems: first, they sometimes do not exist at a sufficiently granular resolution in the relevant XML versions, and second, granular identifiers do not resolve or map well to materials whose citation has traditionally been based on print volume and page numbers.
Identifiers for Presidential documents: general characteristics
Some of the finding aids we describe below provide mappings between Presidential documents and the codified statutes in the US Code.  Identifiers for Presidential documents are assigned by the Office of the Federal Register, and are typically accession numbers.  It is worth noting that OFR provides a number of finding aids and subject-matter descriptions of Presidential documents, though these are beyond our scope here.  

As to GPO, it appears at first blush that the MODS metadata for the US Code as found in FD/SYS does not reflect associations with Executive Orders, although they are vaguely modeled in the MODS files associated with the Executive Orders themselves.  There would be some virtue in being able to find information in both directions.  That is especially true in situations where the state of the law cannot be fully understood without referring to both the Code and related Executive Orders simultaneously.  For example, 4 USC 1, in its most current version, claims that there are 48 stars on the flag of the United States; it is only possible to find out where the other two came from by referencing the Executive Orders that accompanied statehood for Alaska and Hawai’i. 
The Table of Popular Names (TOPN)
For the general public, the TOPN is probably the single most useful finding aid for Federal legislation. That is because it bridges the gap between popular accounts of legislation -- for example, in the news media -- and the codified collections of laws that are in effect.  Where, exactly, do we find the Lily Ledbetter Fair Pay Act in the modern statute book?  The answer to that question isn’t obvious.

Broadly -- very broadly -- there are two ways in which an Act may be codified.  First, it could be moved into the Code wholesale, typically as a new Chapter containing numbered sections that reflect the section divisions in the Act.  Second, it could be disassembled into a bag of provisions and scattered all over the Code, with each section placed in a region of the Code dictated by its subject matter.   In such cases, the notes to the Code section that describes the “Short Title” of the Act generally contain a roadmap of what has been done with the rest of it.   That also happens when the Act contains language that consists entirely of instructions for amending existing statutes already codified.

For example, the TOPN entry for the Lily Ledbetter Fair Pay Act looks like this:

Lilly Ledbetter Fair Pay Act of 2009
Pub. L. 111-2, Jan. 29, 2009, 123 Stat. 5
Short title, see 42 U.S.C. 2000a note

It maps the identifier for the Public Law version of the Act to the Statutes at Large, with a page reference to the Stat. page on which the Act begins.  It also maps to the “Short Title” section of the USC, whose note contains information about what has been done with the Act.

Short Title of 2009 Amendment

Pub. L. 111–2, § 1,Jan. 29, 2009, 123 Stat. 5, provided that: “This Act [amending sections2000e–5 and 2000e–16 of this title and sections 626, 633a, and 794a of Title 29, Labor, and enacting provisions set out as notes under section 2000e–5 of this title] may be cited as the ‘Lilly Ledbetter Fair Pay Act of 2009’.”

This entry makes an important point about codified legislation.  While it is natural to believe that codification consists of taking something that contains entirely new legislative language, breaking it into pieces, and plugging the pieces into the Code (or substituting them for old ones), that is not exactly what happens much of the time.  Any Act could be, and often is, a laundry list of directives to amend existing codified statutes in some way or other.   In such cases, the text of the Act is not incorporated into the Code itself, but into the Notes, in a manner similar to the example just given.  That is a subtle difference, but an important one, as we shall see in the discussion of Table III below.  It introduces an extra layer of mapping into the process, in a way that is partially obscured by the fact that inclusion is in the Notes rather than in the text of the Code.  One result of this is that, in general, it is easier to look at a current provision and find out where it came from than it is to look at an historical provision and find out what happened to it.

From a data modeler’s perspective, the TOPN is useful but not necessary; the necessary finding aid can be constructed by aggregating data from other tables, or by simply referring to the short titles and popular names given in the text of the Act itself. The relationships modeled by TOPN aggregate information:
●	from the Acts or bills themselves (House and Senate identifiers for bills, and the name of the Act as it’s found in either the bill or (better) in the Public Law version);
●	from Table 3, which describes where the Public Law is codified; and
●	from Table 1, which models an extra “change of address” that is applied in cases where codified legislation has been reorganized for passage into positive law.
US Code Table I
Table I describes the treatment of individual sections in Titles that have been revised for enactment as positive law.  The Table is a straightforward mapping of “old” section numbers in a Title to “new” section numbers that apply after the Title was made into positive law.  As such, Table I entries also have a temporal dimension -- the mappings need only be applied when tracing a citation to the Code as it existed before the date of positive law enactment to a location in the Code after that date.

A relational-database expert obsessed with normalization would say that Table I is, then, really two tables -- one that maps old sections to new sections within a Title, and a second, implied table that says whether or not each of the 51 Titles has been enacted into positive law, and if so, when.  The researcher wanting to trace a particular reference would follow this heuristic:
●	Does my reference fall within a positive-law Title?
●	If so, does my reference precede the date of enactment into positive law?
●	If so, what is the number of the “new” section?
Thus, the model will need to reflect properties of the Title itself (“enactedAsPositiveLaw”) and of the mapping relationship of old to new (“hasPositiveLawSection”).
US Code Table II
The United States Code was preceded by an earlier attempt at regularized organization, the Revised Statutes of 1878 .  Citations to the Revised Statutes are to sequentially-numbered Sections, with “Rev.Stat.” as the series indicator.  Table II provides a map between Rev. Stat. cites and sections of the US Code, along with a number of status indicators; the two most important (and common) of these indicate that a statute has been repealed, or that Table I needs to be applied because the classification shown was done prior to positive-law enactment of the Title.

Unlike other finding aids we describe, where the meaning of mappings between ranges and lists of things can be both combinatorial and ambiguous, Table II appears straightforward. A list or range of items in the Rev. Stat. columns can be mapped one-to-one to the corresponding list or range in the USC column.  The first element in the list or range in Rev. Stat. maps to the first element in the list in USC, the second to the second, and so on.  Simple reciprocal relationships should obtain.

That is particularly important in light of the relationship between Table II and Table III.  In Table III, for all statutes passed before 1874, Table III references all refer to the Revised Statutes, and not to the US Code.  So, for those statutes, in order to determine where they may still exist as part of the US Code, reference needs to be made first to Table III, to obtain the R.S. section where it was first encoded, and then to Table II, to determine where that R.S. section was re-encoded in the US Code.  Without the straightforward, one-to-one relationship between the R.S. and US Code expressed in Table II, the connection between pre-1874 statutes and current US Code sections would not be possible.
US Code Table III
Table III, which maps individual provisions within Public Laws to pages in the Statutes at Large and to sections of the US Code, exhibits a number of interesting problems.  Here is how one such mapping appears in the LRC’s online tool:

In this case, we’re mapping the individual provisions of PL 110-108 (readable at http://www.gpo.gov/fdsys/pkg/PLAW-110publ108/html/PLAW-110publ108.htm )  to a range of pages in the Statutes at Large and to sections in the US Code (and their notes). The GPO version helpfully contains markers for the Stat. L. page breaks.  Some noteworthy observations:
●	The Public Law needs section-level identifiers. Notes sections within the USC need their own identifiers, as do pages within the Statutes at Large.
●	Since the Stat. L. citation for the Act always goes to the first page of the Act as it appears in Stat.L., there is ambiguity between
○	121 Stat. 1024, the citation/identifier indicating the whole Act for purposes of external citation, and
○	121 Stat. 1024, the single-page reference that describes where Section 1 of the Act can be found (and for that matter, supposedly, some of Sections 2-6 as well)
●	For some time periods, chapter numbers would disambiguate individual laws where more than one statute appears on a single page, although as we have seen, chapter numbers have uniqueness problems of their own. Chapter numbers play no role in this example, as they were not used after 1957.
●	The Act is classified to the notes in the relevant USC sections. 
○	In the case of section 1 of the Act, the notes simply state the name of the Act.
○	In the case of section 151, the entire text of the legislation appears in the notes for the Act.  It would appear that it is done this way because the legislation’s provisions amount to a series of instructions for amending existing statutes, and thus can’t be codified per se.  Rather, they are a description of what should be done to change things that have been codified already.
●	GPO’s MODS file is evidently created by machine extraction of USC citations, because it incorrectly identifies the Act as modifying 26 USC 4251. It’s possible, though,  that the presence of a USC section in the MODS file might simply mean “found at the scene of the crime by our parser” rather than “changed by the Act”.  The relationship is unclear, and may be impossible to express clearly in XML.
●	GPO’s MODS file for the Act treats the mapping implied by the second line of the example pretty loosely, describing small collections of US Code and Stat.L. pages associated with the Act, but not describing any particular relationship between the items in each collection or between collections.  This is, again, a place where XML falls short of what is possible in an RDF-based, machine-readable model.

The second line of the table entry is the most interesting.  At first glance, it appears to describe a many-to-many relationship between a range of sections in the Act and a range of pages in the Statutes at Large.  But it seems improbable that such a relationship would actually describe anything useful, and a quick side-by-side look at the Act and the Statute shows that that interpretation is incorrect.  The actual arrangement of page breaks in Stat. L. would indicate that the mapping should be otherwise:
●	Section 2 appears in its entirety on 121 Stat 1024. 
●	Section 3 spans the break between 1024 and 1025. 
●	Section 4 spans 1025 and 1026
●	Sections 5 and 6 appear in their entirety on 1026

Why is this?  The simplest explanation is that the entries in the table -- numbers separated by a dash -- do not represent lists of individual sections. Instead, they represent clusters of sections that are related to each other as clusters.  They seem to be saying, “somewhere in this clump of legislative language, you’ll find things that relate to things in this other clump of legislative language, and the clumps span multiple sections or provisions, possibly ordered differently in each document”.  

Looking at the text itself -- which is a series of detailed, interrelated amending instructions -- shows that indeed it would be a horrible (and likely very confusing) task to pick the provisions apart into a fully granular mapping, leaving “cluster-to-cluster” mapping as the only viable strategy for describing the relationship between the two texts.

A detailed model of Table III would then require:
●	clarifying the distinction between a page reference to the first page of an Act as it appears in Stat.L. and the citation of the statute as a whole.
●	describing each section or subsection (granule) within the Public Law as one that is either
○	new statutory language, or 
○	a set of instructions for amending existing language
●	describing each target in the USC as either 
○	an actual statute, or
○	notes to the statute. It is worth remarking that, in any of the finding aids, the fact that something has been classified to the notes provides a clue as to what that thing is and what the nature of the classified relationship might be. This may indicate a need for subproperties that would be accommodated in some future extension.
●	distinguishing between relationships that involve re-publication (as between Public Laws and Statutes at Large) from those that involve restatement or codification (as between either of those and the US Code)
●	using different properties to describe provision-to-provision and cluster-to-cluster relationships
 
Taken together, these requirements would form an approach that would more accurately model the relationships the original Table was meant to model.  In some sense this is an interpretive act -- any Table that records codification decisions does, after all, record a set of interpretations, and so will its model.  But in this case the interpretation is an official one, entrusted to the Law Revision Counsel and in any case practically unavoidable.
US Code Table IV
Table IV “lists the Executive Orders that implement general and permanent law as contained in the United States Code” .  Executive Orders are instructions from the President mandating an action, reorganization, or policy change in some part of the executive branch.  They are promulgated pursuant to statutory authority and as lawful orders of the chief executive, have force of law.  They are published in the Federal Register and appear in the annual Compilation of Presidential Documents.  They are sequentially numbered, but are also identified by date of signing, title, and the authoring president.  All four of these identifying attributes are specified in the GPO MODS files which accompany these documents in FD/SYS.  In addition, there exists a reference to the volume and issue number of the Weekly Compilation in which the order appears.  Finally, the MODS files typically include a reference to the enabling law as well.

The Table shows that:
●	Executive Orders have identifiers, apparently accession numbers that run from the beginning of time.
●	Nearly all refer to the “notes” attached to sections of the USC, since (as the description says) Executive Orders are typically implementation instructions independent of the language of the statute itself.
References to the notes have special features worth remarking.  Often, the mapping is given to the note preceding (“nt. prec.”) a particular section.  That distinctive language is rooted in the way that the LRC conceives of the Code’s structure.  In the minds of the LRC, the Code consists of Titles that are divided into sections.  Intermediate levels of aggregation -- subtitles, parts, subparts, chapters, and subchapters -- are convenient fictions used to organize the material in a manner similar to the tabs found in a card catalog.  Thus, the “note preceding” a section is most often a note that is attached to the chapter of which the section is a part (chapters are typically, but not always, the level that aggregates sections, and often correspond to an Act as a whole).  As modelers, we’re presented with a choice between fictions: either we join LRC in pretending that the intermediate levels of aggregation don’t exist, or we make use of them.  The latter presents other problems with representing parent-child relationships in the structure, but fortunately that is a concern for XML markup designers and not so much for us.

It would seem that the best approach might be to model both sets of relationships: a hierarchical structure based on aggregations, and a sequential structure suggested by the “insertion model” just described.  Thus, we would end up with:
●	a set of unique identifiers for sections, based on title and section numbers and thus reflecting current citation practice;
●	a set of sub-section identifiers that extend section identifiers in a way that is based on nested subsection labeling. 
●	a set of super-section identifiers that is based on human readable hierarchy, represented as paths, eg. “/uscode/title42/subtitle1/part3/subpart5/chapter7/subchapterA”
●	a set of completely opaque identifiers for both section and supersection levels.  There is less need for this at the subsection level, but any such system could easily be extended;
●	parent-child relationships between 
○	subsections and sections
○	sections and supersections
○	supersections and containing supersections
●	next-previous relationships between sections.  These should take no account of supersection boundaries.
As we’ve said in other contexts, it is worthwhile to remember that nothing limits us to a single identifier for any object.
US Code Table V
Table V maps Presidential proclamations to the US Code.  Proclamations differ from Executive Orders in that they do not “legislate” as such.  Rather, they are issued to commemorate a significant event, or other similar occasion.  Like Executive Orders, they are published in the Federal Register, and appear in the Compilation of Presidential Documents. Like Executive Orders, they are sequentially numbered (without reference to year, president, etc.), and are also identified by date, title, issuing president, and the volume and issue number of the Weekly Compilation.  All these identifiers are typically present in the GPO MODS files in FD/SYS.

Before 1950 or so, the vast majority of proclamations establish national monuments. More recently, other topics as diverse as the maintenance of the Strategic Petroleum Reserve, tariff schedules, and the celebration of Armed Forces Day show up frequently.  As with Executive Orders and Table IV, the proclamations have accession numbers, and the vast majority of references are to notes attached to the Code and not the Code itself.
US Code Table VI
Table VI maps reorganization plans to the US Code.  Reorganization plans are essentially executive orders that describe major alterations to executive-branch agencies and organization, though they do not carry executive-order identifiers.  For example, Reorganization Plan 3 of 1970 establishes the Environmental Protection Agency and expands the structure of the National Oceanographic and Atmospheric Administration.  Generally they carry citations to the Statutes at Large and to the Federal Register (the FR cite does not appear in Table VI).   While no concise identifier exists for them in and of themselves, it appears that they could be identified by a year-number combination (eg. “RP-1970-3”).  These associations can readily be modeled by associating an identifier for the plan itself with the page references, through one or more “isPublishedAt” relationships.
The Parallel Table of Authorities (PTOA)
The Parallel Table of Authorities and Rules describes relationships between statutes in the US Code and the CFR Parts that they authorize. For the most part, the PTOA maps ranges of sections in the US Code to lists of Parts in the Code of Federal Regulations. It has limitations, described by GPO as follows:

Entries in the table are taken directly from the rulemaking authority citation provided by Federal agencies in their regulations. Federal agencies are responsible for keeping these citations current and accurate. Because Federal agencies sometimes present these citations in an inconsistent manner, the table cannot be considered all-inclusive. The portion of the table listing the United States Code citations is the most comprehensive, as these citations are entered into the table whenever they are given in the authority citations provided by the agencies. United States Statutes at Large and public law citations are carried in the table only when there are no corresponding United States Code citations given.

The suggestions made here, then, are not so much recommendations as they are observations about a critically important finding aid, strongly related to legislative material, that is in need of some help.  Thinking about the PTOA and the various ways in which modeling techniques such as the ones we recommend might improve it provides an interesting overview of the problems of legislative finding aids in general.

Richards and Bruce have written extensively about its organization and improvement.  They note four major areas to address:
●	Ambiguity in the description of the relationships themselves.  The Table supposedly models four different types of relationship: express authorization, implied authorization, interpretation, and application.  These are not distinguished in the PTOA entries.
●	Ambiguity in relationship targeting.  Entries on both sides of the table are typically given as ranges or lists, implying many-to-many relationships that can be combinatorially expanded.  It is not clear whether, in fact, all the sections of the US Code that could be enumerated from a range on the left side of the table would relate to particular Parts of the CFR enumerated from the lists on the right side of the table.  It seems unlikely.
●	Granularity problems related to citation of the CFR materials by Part.  In reality, the authorizing relationship would typically run from a statute to a particular section of the CFR, but the targeting in the PTOA is to the Part containing that section. It is likely that this is not a problem with granularity so much as it is an informed design decision driven by problems with the volatility of section-level identifiers as compared to printed finding aids.  Sections of the CFR come and go with some frequency, often moving around within an individual Part. Parts change infrequently.  In print, where updating is difficult and withdrawal of stale material even more so, identifier stability is a much bigger concern.  It is possible that a digital resource could track things much more closely.
●	Directionality and reciprocity.  It is not clear which of the four possible relationships between entries are reciprocal and which are strictly directional, nor is the Table necessarily intended to be used bidirectionally.

Unfortunately, improvement is unlikely, as it would require the collection of improved information from each of the hundreds of agencies involved.  We would recommend that, because of its critical importance to those wanting to trace relationships between legislative- and executive-branch activity, the client use a simplified model to provide at least some useful information.  The LII currently models the PTOA as a single relationship between individual pairs of identifiers, asserting that each pair in a combinatorial expansion of entries on each side of the table has some such relationship.  That is undoubtedly imprecise, but it is as good as anything currently available and far better than nothing.
References
General
●	Law Librarian’s Society of Washington DC, “United States Statutes and the United States Code: Historical Outlines, Notes, Lists, Tables, and Sources”. At http://www.llsdc.org/statutes-code/ .
●	Wikipedia article on the US Code, at http://en.wikipedia.org/wiki/United_states_code 
Other papers
●	Richards, Robert, and Thomas Bruce, “Adapting Specialized Legal Material to the Digital Environment: The Code of Federal Regulations Parallel Table of Authorities and Rules”, in ICAIL ‘11: Proceedings of the 13th International Conference on Artificial Intelligence and Law. A slide deck based on the presentation is at http://liicr.nl/M7QyTG .
●	Bruce, Thomas, and David Shetland, “Remarks on Identifiers for Legislation”, at http://www.law.cornell.edu/wiki/lexcraft/lii_remarks_on_identifiers_for_legislation .
Finding aids
●	Table of Popular Names, online at http://uscode.house.gov/popularnames/popularnames.htm 
●	Table I , online at http://uscode.house.gov/tables/usctable1.htm 
●	Table II, online at http://uscode.house.gov/tables/usctable2.htm 
●	Table III, online at http://uscode.house.gov/tables/usctable3.htm 
●	Table IV, online at http://uscode.house.gov/tables/usctable4.htm
●	Table V, online at http://uscode.house.gov/tables/usctable5.htm 
●	Table VI, online at http://uscode.house.gov/tables/usctable6.htm 
●	Parallel Table of Authorities and Rules, online at http://www.gpo.gov/help/parallel_table.pdf 

PART SEVEN
Use cases
This appendix contains all of the use cases we collected and employed.  This collection is the distillation of just under 100 “raw” use cases that were analyzed, and then condensed to reconcile overlaps and eliminate duplication.  It is by no means every use case there could be, and no doubt other portions of this document imply the existence of others that were at the back of our minds but not formally documented.

Bills, reports, and hearings by entity (MD S-1 UC-2)
From LII Legislative Metadata Project

Use case name	Bills, reports, and hearings by entity	
Use case number	MD S-1 UC-2	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2011/08/21	
Last modified by	DH	
Purpose	Search and browse bills, reports, and hearings using named entities such as Members of Congress, witnesses, Congressional committees, subcommittees, etc. as a starting point.	
Actors	Public User, Service, Specialist User, Visitor	
System Prerequisite		
Prerequisite	The name of a member of Congress, a witness, a specific Congressional Committee or Subcommittee. In general, personal names should be properly spelled, but for corporate names (particularly committee names) the least common words present in the name should be sufficient.	
Sequence	1. User enters name of entity in the simple or advanced search box offered
2. The service returns n results, with initial ranking by date or relevance (however defined by service). User may modify result sort using a limited number of options.	
Results	User may choose a specific item and view its detail, or choose to browse all relevant items linked to it.	
UML diagram		
Similar to	JJ S-1 UC-1, JJ S-2 UC-2, JJ S-2 UC-3, JJ S-2, UC-4	
Current practice		
Notes	Is this really a 'search by entities' or is it indeed only 'identify'? If 'identify', it's hard to understand what a sequence might look like, and how we would test for compliance? [Diane] I don't know how you'd 'identify' what you wanted without starting with a search of some kind, which is why I've modified this one a bit to reflect that.

Bills, reports, and hearings by geographical location (MD S-1 UC-3)
From LII Legislative Metadata Project

Use case name	Bills, reports, and hearings by geographical location	
Use case number	MD S-1 UC-3	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2011/08/21	
Last modified by	DH	
Purpose	Find bills, reports, and hearings based on a known geographical location relevant to the legislation itself.	
Actors	Public User, Service, Specialist User, Visitor	
System Prerequisite		
Prerequisite	User knows a specific geographic location by its geographic name or geographic coordinates	
Sequence	1. User searches for a specific geographic location using its name, coordinates, or by using locating it on a map
2. User refines search based on search results or modifies map placement	
Results	User builds a list of geographically relevant bills, reports, or hearings	
UML diagram		
Similar to	MD S-12 UC-1, MD S-13 UC-1, MD S-13 UC-2	
Current practice	Geographic information may be buried in LCSH strings, with different forms when the topic is specifically about a geographic area or a particular jurisdiction. Current data generally does not carry coordinates, so any mapping applications have had to build that capability in other ways.	
Notes	How to embed relevant geolocation data? [Diane] I'm not sure we need to. What we need is to encourage use of other geographic services that would link to the data we're building.

Bills, reports, and hearings by topic (MD S-1 UC-1)
From LII Legislative Metadata Project

Use case name	Bills, reports, and hearings by topic	
Use case number	MD S-1 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2011/08/29	
Last modified by	DH	
Purpose	Find bills, reports, and hearings by topic.	
Actors	Public User, Service, Specialist User, Visitor	
System Prerequisite		
Prerequisite	User is assumed NOT to have a bill name or number, or to know of the existence of a relevant bill.	
Sequence	1. User approaches search portal and enters a topical term
2. User is presented with a large search result, and determines that a filter is available to refine the search 3. User refines the search (or re-searches under a different, less common term) 4. User selects a possibility, and goes further into the description; or (preferably) 5. User navigates through links to a relevant result	
Results	User identifies a satisfactory result.	
UML diagram		
Similar to	JJ S-2 UC-2, JJ S-2 UC-3, MD S-7 UC-1, MD S-7 UC-2, RFP S-5 UC-1	
Current practice		
Notes	Known item searches by topic should be a separate use case. There should be an option, particularly for expert users, to identify search terms and their thesaural relationships prior to selecting a search term.

Bills by bill number (BK S-1 UC-1)
From LII Legislative Metadata Project

Use case name	Retrieve bill by bill number	
Use case number	BK S-1 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2011/09/22	
Last modified by	RR	
Purpose	Obtain access to the full text of a bill, the bill number of which the Actor knows	
Actors	Specialist User	
System Prerequisite		
Prerequisite	1. Web browser
2. Bill number of bill 3. Number of Congress in which bill was introduced	
Sequence	1. User selects known number of Congress
2. User enters known bill number 3. User clicks search button 4. Result set returned 5. User selects first results	
Results	User determines retrieved bill is the desired bill	
UML diagram		
Similar to		
Current practice		
Notes	If user is dissatisfied with results, click back and check next result.

Committee hearings by participant (JJ S-3 UC-3)
From LII Legislative Metadata Project

Use case name	Committee Hearing Extension	
Use case number	JJ S-3 UC-3	
Document type	Committee Hearings	
Specify other document type:		
Last modified	2011/10/04	
Last modified by	JJ	
Purpose	To allow for the linking of hearings to biographical or other identifying information concerning witnesses testifying at said hearings.	
Actors	Public User, Service, Specialist User, Visitor	
System Prerequisite		
Prerequisite	1. A hearing in which witnesses testify.
2. Biographical, and/or other identifying information concerning the witnesses testifying. 3. The locations within the document wherein the witnesses testify.	
Sequence	1. Within each hearing document, the testimony of each witness, typically marked by an announcement in the text, is tagged with an identifier which uniquely identifies the person.
2. Metadata records of the document have the unique identification for each witness included (which is already done, for the most part, in the GPO MODS.xml files that are generated for congressional hearings. The GPO identifiers, however, are simply a statement of name and affiliation, with no unique identifier.)	
Results	Application builders will be able to make use of the identifiers to create applications which can facilitate such activities as:
1. The reader of a hearing being able to click on a witness' name to retrieve detailed information about the witness.
2. A searcher being able to use the name of a witness as an entrypoint: searching for hearings in which the witness has testified.	
UML diagram		
Similar to		
Current practice	Searchers typically search by topic or (via CIS indicies or other finding aid) by public law to locate hearings by subject. The names and affiliations of witnesses are obtained by reading the text. Information about the witnesses is then obtained through unlinked and unrelated sources.	
Notes	

Compare attributes of debates on particular topics at different time periods (RFP S-3 UC-1)
From LII Legislative Metadata Project

Use case name	Compare attributes of debates on particular topics at different time periods	
Use case number	RFP S-3 UC-1	
Document type	Congressional Debates and Congressional Record	
Specify other document type:		
Last modified	2012/02/05	
Last modified by	TB	
Purpose	To compare attributes (length,type,level of participation) of debates about legislation on a particular topic during different time periods.	
Actors	Public User, Specialist User, Visitor	
System Prerequisite		
Prerequisite	1. A well-understood set of retrievable "debate attributes".
2. Topically-classified set of debates	
Sequence	1. User chooses debate topic
2. User chooses a set of useful attributes. 3. User selects one or more time periods.	
Results	A tabular comparison of the attributes of two lists of debates (one from each time period). A summary comparison of the attributes as summarized for each time period as a whole.	
UML diagram		
Similar to	MD S-11 UC-1	
Current practice		
Notes	It's not clear at this stage which attributes of the debates would be considered useful. Nor do we know how to derive meaningful summary statistics for an entire time period. For example, if debate length (as measured by the number of characters in the transcript, say) is significant, then would we choose the average, the mean, or the median length of the debates within a particular time period in order to compare that time period with another?

Compare statistics for Congressional actions in different time periods (MD S-17 UC-1)
From LII Legislative Metadata Project

Use case name	Compare statistics for Congressional actions in different time periods	
Use case number	MD S-17 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/02/16	
Last modified by	TB	
Purpose	For a given type of congressional action (e.g., a special rule to restrict amendments), in each of two or more specified time periods, calculate how often the action succeeds and how often the action fails, then compare the statistics for the different time periods	
Actors	Public User, Service, Specialist User	
System Prerequisite		
Prerequisite	1) A standardized list of Congressional actions
2) Database of votes that includes the action-type and date	
Sequence	1) User specifies the action of interest, from a pick list
2) User specifies two date ranges	
Results	List of pass/fail statistics for the action in question during each of the two time periods.	
UML diagram		
Similar to	MD S-21 UC-1, RFP S-4 UC-1	
Current practice		
Notes	Granularity and stability of the list of Congressional actions is an issue here, particularly given the effects of (eg.) procedural rules changes from Congress to Congress.

CSPAN witnesses (MD S-2 UC-2)
From LII Legislative Metadata Project

Use case name	Named witnesses	
Use case number	MD S-2 UC-2	
Document type	Committee Hearings	
Specify other document type:		
Last modified	2011/08/29	
Last modified by	DH	
Purpose	Find where individual persons appear as witnesses in text documents or available CSPAN video.	
Actors	Public User, Specialist User	
System Prerequisite		
Prerequisite	User should know the name of the individual they're looking for, preferably correctly spelled.	
Sequence	1. User approaches search portal and enters the surname (or the forename and surname, in any order) of the witness
2. User is presented with a list of names meeting the search criteria, including close spellings, and a numeric count of the number of places the name is found 3. User selects a name, and is presented with a list of appearances associated with the name, including the date of appearance and committee/subcommittee 4. User selects one or more instances of hearings where the witness has appeared	
Results	The user is presented with all instances where the selected name appears. If the user is searching for one particular hearing, the dates and committees should assist in finding the particular one. If looking for more than one, the user should be given the option to sort so that a range of appearances can be identified.	
UML diagram		
Similar to		
Current practice	Named witnesses do not appear in current bibliographic data for hearings.	
Notes	

Determine member stances on particular topics, grouped geographically by district of member (RFP S-7 UC-1)
From LII Legislative Metadata Project

Use case name	Determine member stances by geography	
Use case number	RFP S-7 UC-1	
Document type	Congressional Debates and Congressional Record	
Specify other document type:		
Last modified	2012/02/05	
Last modified by	TB	
Purpose	To identify stances taken by Members of Congress on particular topics, faceted by the location of the member's district.	
Actors	Public User, Specialist User, Visitor	
System Prerequisite		
Prerequisite	See notes	
Sequence	See notes	
Results	See notes	
UML diagram		
Similar to		
Current practice	See notes	
Notes	Substantially the same as -- and having the same problems as -- RFP S-2 and S-7.

Determine Member stances on particular topics during particular time periods (RFP S-2 UC-1)
From LII Legislative Metadata Project

Use case name	Determine member stances during particular time periods	
Use case number	RFP S-2 UC-1	
Document type	Committee Hearings	
Specify other document type:		
Last modified	2012/02/05	
Last modified by	TB	
Purpose	Retrieve the "stances" taken by members about particular topics at particular times, or during particular timeframes.	
Actors	Public User, Specialist User, Visitor	
System Prerequisite		
Prerequisite	A collection of bills, hearing documents, roll call votes, and other documentation of member activity that has been classified in terms of its stance on an issue. Records indicative of member sentiment on the materials at hand. Better technology than we now have.	
Sequence	See notes below.	
Results	See notes below.	
UML diagram		
Similar to	DH S-1 , JJ S-2, MD S-14 UC-1, RFP S-6 UC-1, RFP S-7 UC-1	
Current practice	1.Search available databases (THOMAS, FDSYS) for bills by topic.
2. Examine each for list of sponsors, to see if a particular legislator sponsored. 3. Look up vote on bill to determine legislator's vote. 4. Look up bill in Congressional Record to locate records of debates to see if the legislator made any statement. 5. Look up committee which worked on the bill, determine of the legislator was on the committee. If yes, look up related hearings to see if further statements were made.	
Notes	Note that this use case draws on a wide variety of materials, including roll call votes, sponsorship of bills, statements in debates, etc.
A particular problem is identifying a "stance" in retrievable terms; it is not clear how one translates the statements of a member opposing a significant amendment to a bill that may have multiple subjects into a retrievable encoding of their feelings on the subject matter, nor how consistently that can be done for a particular member over time. In TB's view this is a very sophisticated NLP problem that will need a good deal of research before it is possible. It is not just a matter of tying member sentiment to a particular bill (or part of a bill, or amendment to a bill), but of recognizing how the particular chunk of the bill, or amendment under discussion, or procedural vote about which the member is expressing herself relates to the bill as a whole and to the subject matter of the bill and its components. This is a rather complicated business.
It may be more useful at this stage to concentrate on simpler use cases that support individual components of this kind of analysis.

Discover legislative intent of a statute (JJ S-4 UC-3)
From LII Legislative Metadata Project

Use case name	Legislative Intent of a Statute	
Use case number	JJ S-4 UC-3	
Document type	Public Laws	
Specify other document type:		
Last modified	2011/08/09	
Last modified by	JJ	
Purpose	To determine the stated purposes and expectations of legislators concerning a statute.	
Actors	Public User, Service, Specialist User, Visitor	
System Prerequisite		
Prerequisite	A public law.	
Sequence	1. User looks up the public law, and clicks on "legislative history documents".
2. The result lists, inter alia, committee reports, votes, and relevant parts of the Congressional Record. 3. User can examine these documents.	
Results	Given any law, all relevant legislative history documents are linked and available, and legislative intent analysis can be completed with just a few clicks.	
UML diagram		
Similar to		
Current practice		
Notes	

Display definitions for legislative procedural terms (MD S-9 UC-1)
From LII Legislative Metadata Project

Use case name	Display definitions for legislative procedural terms	
Use case number	MD S-9 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/02/15	
Last modified by	TB	
Purpose	To display definitions of procedural terms inline, where they are encountered.	
Actors	Service	
System Prerequisite		
Prerequisite	A vocabulary of defined legislative terms. Something along these lines appears at http://www.senate.gov/pagelayout/reference/b_three_sections_with_teasers/glossary.htm , but this application probably needs a merger of several existing resources. Specialized legislation may need its own glossaries -- NCSL has done some work along these lines.
Markup of the relevant documents, or a browser add-on similar to the LII's Jureeka	
Sequence	1. User hovers mouse over defined term	
Results	Definition appears.	
UML diagram		
Similar to		
Current practice	None.	
Notes	This is primarily a user-interface action, though it does require building of a vocabulary of defined procedural terms (or the integration of an existing dictionary of this type,

Earliest use of language in legislative history related to a topic (MD S-7 UC-3)
From LII Legislative Metadata Project

Use case name	Earliest use of language in legislative history related to a topic	
Use case number	MD S-7 UC-3	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2011/08/07	
Last modified by	TB	
Purpose	Identify the earliest use of particular language in legislative history resources on a particular topic.	
Actors	Public User, Service, Specialist User, Visitor	
System Prerequisite		
Prerequisite		
Sequence	1.	
Results	Retrieval of a particular document (with some kind of KWIC indication, or highlighting) that contains the input phrase.	
UML diagram		
Similar to		
Current practice		
Notes	Implies ability to narrow search by topic, sort by date, search by phrase.

Embedding of current statutory language (TB S-1 UC-1)
From LII Legislative Metadata Project

Use case name	Embedding of current statutory language	
Use case number	TB S-1 UC-1	
Document type	Public Laws	
Specify other document type:		
Last modified	2011/08/27	
Last modified by	TB	
Purpose	The author of an online document wishes to embed language from a current statute into the text of another document. For example, the writer of a citizen's guide to Social Security benefits might wish to incorporate the most current version of the language describing a benefit calculation into her guide. Other forms of incorporation-by-reference like this are easy to imagine.	
Actors	Service	
System Prerequisite		
Prerequisite	Existence of a suitably marked-up electronic version of the statute (that is, one that has labelled XML container elements, with identifiers, at the appropriate level of granularity)	
Sequence	1. User selects appropriate URI for text to be embedded.
2. User generates sample code for inclusion into electronic document.	
Results	Text from target document/subcontainer is presented as part of the containing document upon Web retrieval	
UML diagram		
Similar to		
Current practice	Not currently possible.	
Notes	This raises a lot of issues vis a vis identifier granularity, metadata vs. markup, and so on.

Faceted search of floor debates and voting records (RR S-2 UC-1)
From LII Legislative Metadata Project

Use case name	Search for voting records and statements in floor debates, of all Representatives and Senators from New Jersey, about consumer bankruptcy legislation	
Use case number	RR S-2 UC-2	
Document type	Congressional Debates and Congressional Record	
Specify other document type:		
Last modified	2011/09/22	
Last modified by	RR	
Purpose	Learn how US Senators and Representatives have voted, and spoken publicly in congressional debate, about consumer bankruptcy legislation	
Actors	Specialist User	
System Prerequisite		
Prerequisite	1. Web Browser
2. Controlled vocabulary terms for "consumer bankruptcy" and related concepts; keywords for "consumer bankruptcy" and related concepts. 3. Short titles or bill numbers for major consumer bankruptcy legislation	
Sequence	1. User enters controlled vocabulary terms, keywords, short titles, or bill numbers in search box.
2. User pushes 'search' button 3. Initial results list is returned, with facets, and automatically generated suggestions of possibly relevant documents or relevant search terms or facets.	
Results	User examines initial results list for relevant documents, controlled vocabulary terms, bill title/bill numbers, names of bill sponsors, etc. User also identifies facets (such as dates, state names, document types, etc.) that may help to narrow or expand the search. User clicks on relevant items in the search list, saves relevant documents, notes access points that may lead to further relevant documents. User clicks on facets that seem likely to narrow the search (if the result set is large) or expand the search (if the results set is small). User examines the automatically generated suggested documents, search terms, and facets, and identifies those that seem relevant or potentially useful; saves relevant documents; makes note of relevant access points or facets. Then, user conducts another search, using relevant access points identified from the initial search results and/or from the automatically generated documents/ search terms, and facets. User also may limit this second search using relevant facets identified from the initial results list or from automatically generated facets.	
UML diagram		
Similar to	(Finding Voting records on Thomas) (Jj uc:4)	
Current practice		
Notes	All Document Types sought in this use case: Roll call votes; Congressional Record

Find bills having particular attributes (MD S-22 UC-1 )
From LII Legislative Metadata Project

Use case name	Find bills having particular attributes	
Use case number	MD S-22 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/02/16	
Last modified by	TB	
Purpose	Find bills by multifaceted search on particular data items such as topics, actions taken with respect to the bill, and so on.	
Actors	Public User, Service, Specialist User	
System Prerequisite		
Prerequisite	A database of bill metadata, preferably in a format that facilitates the kind of search/filtering typically done by users doing empirical research.	
Sequence	Varies; basically:
1. User fills in values for various supported search criteria/facets	
Results	A list of bills	
UML diagram		
Similar to		
Current practice		
Notes	This is the most general case of a faceted bill search. It implies that searches on more than one facet will be the norm. It would appear that this would be best facilitated by use of a database format better suited to empirical research than a full-text database would be (eg. something like STATA or even a relational). This would not be difficult to create for documents already in XML, but would pose significant problems for the backfile. In other words, the use case is a simple one but the prerequisites may prove difficult.

Find cited secondary sources by subject matter (RR S-1 UC-1)
From LII Legislative Metadata Project

Use case name	Find all secondary legal works cited in legislative history materials related to U.S. federal treaties and legislation governing Native Americans	
Use case number	RR S-1 UC-1	
Document type	Committee Hearings	
Specify other document type:		
Last modified	2011/09/22	
Last modified by	RR	
Purpose	Learn what secondary legal works (e.g., treatises, law journal articles, annotations, etc.) have been cited to support arguments in congressional legislative history respecting statutes and treaties governing Native Americans.	
Actors	Specialist User	
System Prerequisite		
Prerequisite	1. Web Browser

2. Controlled vocabulary terms for "Indians of North America" and related concepts; keywords for “Native Americans" and related concepts.

3.Titles and authors of major secondary legal works on U.S. law governing Native Americans; e.g., Cohen's Handbook of Federal Indian Law.	
Sequence	1. In search box, user enters controlled vocabulary terms, keywords, titles, or
names of authors of works

2. User pushes 'search' button

3.Initial results list is returned, with facets, and automatically generated suggestions of possibly relevant documents or relevant search terms or facets.	
Results	User examines initial results list for relevant documents, controlled vocabulary terms, citations to particular treaties or bills, etc. User also identifies facets (such as dates, state names, document types, document segment [such as “footnotes” or “References”], etc.) that may help to narrow or expand the search. User clicks on relevant items in the search list, saves relevant documents, notes access points that may lead to further relevant documents.
User clicks on facets that seem likely to narrow the search (if the result set is large) or expand the search (if the results set is small).
User examines the automatically generated suggested documents, search terms, and facets, and identifies those that seem relevant or potentially useful; saves relevant documents; makes note of relevant access points or facets. Then, user conducts another search, using relevant access points identified from the initial search results and/or from the automatically generated documents/ search terms, and facets. User also may limit this second search using relevant facets (especially “document segment”)identified from the initial results list or from automatically generated facets.	
UML diagram		
Similar to		
Current practice		
Notes	All Document Types sought for this use case: Hearings; Committee Prints; Congressional Record & its predecessors; Serial Set; Senate Executive Reports and Documents

Find effects of an amendment on a statute (MD S-10 UC-1)
From LII Legislative Metadata Project

Use case name	Find effects of an amendment on a statute	
Use case number	MD S-10 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/02/15	
Last modified by	TB	
Purpose	To display information to the user showing the effects of amending language on an existing statute.	
Actors	Service	
System Prerequisite		
Prerequisite	Either the USC cite of the amended statute, or automated means (via Table 3 and the Table of Popular Names) to discover the USC cite of what's being amended.	
Sequence	1. User clicks on toolbar link or text of amending language.	
Results	Either (as feasible):
a) user is supplied with a link from the amending language to a pinpoint destination in the statute being amended, or b) user is provided with a list of links leading to all the pinpoint destinations in any statute being amended by the document they are currently viewing, or c) user is provided with a diff showing the amending language in the context of the current statute	
UML diagram		
Similar to		
Current practice		
Notes	This may be more or less feasible depending on the result desired. A "list of affected snippets" result will be the easiest to achieve, and might be accomplished by linking popular-name-plus-section-cite references to acts to the relevant statutory sections via the LRC "table of popular names", and via Table 3. Diffs are more complicated, as they involve machine choice of the most logical scope of text being amended (plus diffs don't work all that well). Anything involving amending language that boils down to a set of instructions for how to amend the existing text is not likely to work.

Find organizations with which Members of Congress are affiliated (MD S-18 UC-1)
From LII Legislative Metadata Project

Use case name	FInd affiliations of Members of Congress	
Use case number	MD S-18 UC-1	
Document type	Biographical Dictionary	
Specify other document type:		
Last modified	2012/02/16	
Last modified by	TB	
Purpose	To identify outside organizations with which Members of Congress are affiliated.	
Actors	Public User, Service, Specialist User	
System Prerequisite		
Prerequisite	1) Association between Congressional Bio directory identifiers and URIs from one or more "definitive" outside databases, probably DBPedia, VIAF, and the NYT
2) Curated selection of outside databases of memberships	
Sequence	1. User specifies Member
2. System uses associated URI(s) to discover linked data about member	
Results	A list of affiliations for the Member.	
UML diagram		
Similar to		
Current practice		
Notes	This use case rests on knowing what is meant by affiliation -- for example, simple membership in an organization versus (eg) serving on its board of directors -- and probably would need refinement by time period as well. It must also be "salted" with URIs from outside databases of people that have minted URIs that are in widespread use -- DBPedia, VIAF, the New York Times, and LinkedIn come to mind. That provides a starting point for retrievals; limiting may be necessary

Find witnesses in hearings (MP S-1 UC-1)
From LII Legislative Metadata Project

Use case name	Search for people testifying in Congressional hearings	
Use case number	MP S-1 UC-1	
Document type	Committee Hearings	
Specify other document type:		
Last modified	2011/09/22	
Last modified by	RR	
Purpose	Obtain hearings in which a particular person testified	
Actors	Specialist User	
System Prerequisite		
Prerequisite	1. Web browser
2. Name of witness	
Sequence	1. Users enter name of witness in search box.
2. User pushes search button 3. Result set returned with name of hearing, committee name, date and reference to any related bill number visible.	
Results	User decides at least one of results is relevant.	
UML diagram		
Similar to	(MD S-2 UC-2) (MD S-2 UC-1) (jj UC:2)	
Current practice		
Notes	User should be able to set additional limits or revise results set and see enough data to evaluate on initial results screen.
Bill number should be linked to any bill tracking information.

Finding legislation from hearing records (JJ S-3 UC-2)
From LII Legislative Metadata Project

Use case name	Finding legislation from hearing records	
Use case number	JJ S-3 UC-2	
Document type	Committee Hearings	
Specify other document type:		
Last modified	2011/08/09	
Last modified by	JJ	
Purpose	Recall and trace non-governmental and governmental parties who testify in congressional hearings and author committee prints	
Actors	Public User, Service, Specialist User	
System Prerequisite		
Prerequisite	1. The record of a hearing	
Sequence	User clicks on "related legislation" to get more topical legislation and identify hearing witnesses in those pieces of legislation.	
Results	The user will be able to identify all stakeholders who have participated in the legislative process by appearing before congress.	
UML diagram		
Similar to		
Current practice	User compiles a legislative history, including all hearings and committee prints. User then looks in each for lists of participants and compiles lists.	
Notes	This case was reworked from an earlier use case with multiple retrieval elements. The other elements are treated elsewhere.

Finding voting records on THOMAS (DH S-1 UC-2)
From LII Legislative Metadata Project

Use case name	Finding Voting records on Thomas	
Use case number	DH S-1 UC-2	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2011/08/07	
Last modified by	DH	
Purpose	Defining what can't be done easily with current system	
Actors	Public User	
System Prerequisite		
Prerequisite	Browser; basic expertise	
Sequence	 !. Searched for candidate House member
2. Find only items for which member was sponsor or had another role.	
Results	Cannot find all voting record associated with particular member	
UML diagram		
Similar to		
Current practice	http://thomas.loc.gov/home/faqlist.html#5	
Notes	

Follow topics by geography (MD S-13 UC-1)
From LII Legislative Metadata Project

Use case name	Follow topics by geography	
Use case number	MD S-13 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/02/16	
Last modified by	TB	
Purpose	Allow researchers to see how Members from a particular (multidistrict) geographical area have voted on a particular topic	
Actors	Service	
System Prerequisite		
Prerequisite	Geographic database with Congressional district information (or alternatively a geographic ontology, which in TB's view is much less useful). Topically-classified set of bills. Voting records.	
Sequence	1. User chooses geographic area.
2. System finds "relevant" members based on their districts 3. System retrieves bills for which those members are sponsors or cosponsors	
Results	A list of "geographically relevant" bills.	
UML diagram		
Similar to	MD S-1 UC-3, MD S-12 UC-1	
Current practice		
Notes	Original use case called for bills that the geo-selected Congresspeople voted on. That would seem to me to be overinclusive -- sponsorship or cosponsorship is a much better indicator of geographic interest in play. Although one could also do this analysis using any voting criterion -- all yeas, all nays, etc. This could also be done on the basis of placenames occurring in the bills.

Functions of legislative actions (RFP S-4 UC-1)
From LII Legislative Metadata Project

Use case name	Functions of legislative actions	
Use case number	RFP S-4 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/02/16	
Last modified by	TB	
Purpose	Identify and compare different functions served by a particular type of legislative action (e.g., the filibuster), within a particular time period, or in different time periods	
Actors	Public User, Service, Specialist User, Visitor	
System Prerequisite		
Prerequisite		
Sequence	Unknown	
Results	Unknown	
UML diagram		
Similar to		
Current practice		
Notes	It is unclear what exactly is meant by "functions" here.e

Hearings by witness (MD S-2 UC-1)
From LII Legislative Metadata Project

Use case name	Hearings by witness	
Use case number	MD S-2 UC-1	
Document type	Committee Hearings	
Specify other document type:		
Last modified	2012/01/28	
Last modified by	TB	
Purpose	Identify all hearings containing testimony by a particular witness.	
Actors	Public User, Service, Specialist User	
System Prerequisite		
Prerequisite	The name of a witness, preferably surname, first name, and middle initial.	
Sequence	1. User enters name of witness, or as much of it as she has
2. User is presented with "disambiguation" screen listing all known names with search characteristics 3. User selects disambiguated name 4. Hearings are searched for this witness	
Results	Receive list of all hearings in which the individual appeared as a witness.	
UML diagram		
Similar to	JJ S-3 UC-3	
Current practice		
Notes	How will the master "persons of interest" list be compiled? Does it exist?

Identify legislation related to a pending bill, by citation (MD S-6 UC-1)
From LII Legislative Metadata Project

Use case name	Identify legislation related to a pending bill, by citation	
Use case number	MD S-6 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/01/27	
Last modified by	TB	
Purpose	Identify statutes in force related to a bill, eg. statutes cited by, amended by, or otherwise related to a bill under consideration.	
Actors	Service	
System Prerequisite		
Prerequisite	Text of a pending bill.	
Sequence	1. Parse pending bill for references to existing legislation. These may take the form of USC citations of various kinds, Stat.L. citations, or references to chunks within Acts identified by popular name.
2. Resolve/relate citations to current statutes by USC cite	
Results	A list of "related" statutes, identified by US Code or Stat L. cite.	
UML diagram		
Similar to	JJ S-3 UC-1, JJ S-4 UC-1, JJ S-4 UC-2, JJ S-6 UC-2	
Current practice	Paper, basically, using finding aids from House Law Revision Counsel's office.	
Notes	Not clear from LoC's specification whether "related by" might involve a more expansive definition -- that is, something that is topically related without involving amendment or citation. If this is a simple matter of formal citation, it's easy; covered by properties related to citation or amendment. If it's topical, that's more difficult. In any case, it depends on the existence of (possibly external) data sources that relate all forms of citation to one another (essentially encoding TOPN, Tables I, II, and III, and possibly PTOA).

Identify legislation related to a pending bill, by subject (MD S-6 UC-2)
From LII Legislative Metadata Project

Use case name	Identify legislation related to a pending bill, by subject	
Use case number	MD S-6 UC-2	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/01/28	
Last modified by	TB	
Purpose	Find all legislation related to a pending bill, by subject matter	
Actors	Public User, Service, Specialist User, Visitor	
System Prerequisite		
Prerequisite	Subject-matter classification of the bill under study	
Sequence	1. User activates search-by-subject matter	
Results	A list of all similarly-classified legislation, by USC cite	
UML diagram		
Similar to	MD S-6 UC-1 and related	
Current practice		
Notes	It may be wise to ask the user to preselect which of a number of relevant subjects she wishes to search, since a given bill may be multiply classified.

Identify monikers for bills (MD S-8 UC-2)
From LII Legislative Metadata Project

Use case name	Identify monikers for bills	
Use case number	MD S-8 UC-2	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/02/15	
Last modified by	TB	
Purpose	To identify popular names, acronyms, or other monikers (eg "Obamacare") associated with a bill.	
Actors	Service, Specialist User	
System Prerequisite		
Prerequisite	A bill number, sponsor name, or other element that might be used in searching a bill.
A Google Custom Search Engine restricted to desirable public media sources (eg. CNN, the NYT, etc.)	
Sequence	1. Make Google CSE search based on either the title or number of a bill.
2. Retrieve top X results 3. Aggregate results into word cloud representing retrieved results 4. Human-select most relevant or popular usages	
Results	1. a word-cloud representing popular terms associated with the legislation
2. a human selected term or terms	
UML diagram		
Similar to		
Current practice		
Notes	This is an interesting example of a system that should present intermediate results for human review. Can be approximated by going to http://www.sensebot.net/sense6.aspx and searching on (eg.) "affordable care act" or on "HR 3590" produces interesting results.

Identify statements about legislation in public media ( MD S-8 UC-1)
From LII Legislative Metadata Project

Use case name	Identify statements about legislation in public media	
Use case number	MD S-8 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/02/15	
Last modified by	TB	
Purpose	Find statements about a particular piece of legislation in the public media	
Actors	Service	
System Prerequisite		
Prerequisite	See MD S-8 UC-2	
Sequence	See notes below	
Results	A set of search results from the public media	
UML diagram		
Similar to	MD S-8 UC-2	
Current practice		
Notes	This is a form of activity that closely resembles commercial "competitive intelligence" applications. In general, the provider assembles a list of desirable online sources and crawls them for indexing in a customized search engine. Services can then be built via search on these "important" sources. Usefulness is primarily a result of source selection and of user interface. See examples in MD S-8 UC-2, which is really a prerequisite for this case.

Legislator voting records (JJ S-5 UC-1)
From LII Legislative Metadata Project

Use case name	Legislator Voting Records	
Use case number	JJ S-5 UC-1	
Document type	Congressional Debates and Congressional Record	
Specify other document type:		
Last modified	2011/08/09	
Last modified by	JJ	
Purpose	To track voting records of legislators with minimal effort	
Actors	Service, Specialist User	
System Prerequisite		
Prerequisite	Name of the legislator.	
Sequence	1. A legislator is looked up in the biographical dictionary or directory of the House or Senate.
2. A link "Prior Votes" is clicked on, resulting in a list of bills and resolutions on which the legislator has voted, and what the vote was.	
Results	The legislator's voting record is quickly and easily determined.	
UML diagram		
Similar to		
Current practice	1. User compiles a list of bills based on subject, using random full-text search.
2. User looks of records for each bill in the relevant chamber journal and looks up legislators vote.	
Notes	

Links from legislation to Congressional Record debates (MD S-5 UC-2)
From LII Legislative Metadata Project

Use case name	Links from legislation to Congressional Record debates	
Use case number	MD S-5 UC-2	
Document type	Congressional Debates and Congressional Record	
Specify other document type:		
Last modified	2012/01/27	
Last modified by	TB	
Purpose	Create links from the text of a bill or statute to introductory remarks or debates regarding that bill or statute in the Congressional Record	
Actors	Public User, Service, Specialist User, Visitor	
System Prerequisite		
Prerequisite	Requires system that resolves bill numbers to USC citations and bill numbers to debate records in CR. Might also require resolution of Table of Popular Names to bill numbers.
User needs bill number.	
Sequence	1. Bill number or popular name of act is submitted.
2. Bill number is resolved to list of debates, hearings and so on.	
Results	The creation of such a link	
UML diagram		
Similar to	JJ S-4 UC-3, MD S-5 UC-1	
Current practice		
Notes	See related UC in this scenario. Again, raises versioning questions.

Links from legislation to the Congressional Record (MD S-5 UC-1)
From LII Legislative Metadata Project

Use case name	Links from legislation to the Congressional Record	
Use case number	MD S-5 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2011/08/07	
Last modified by	TB	
Purpose	Create links from the text of a bill or statute to versions of that bill or statute in the Congressional Record.	
Actors	Public User, Service, Specialist User	
System Prerequisite		
Prerequisite	A bill or statute with a unique identifier	
Sequence	1. User initiates search using the identifier (either explicitly or by clicking a link that forwards the bill number to a search apparatus without it being shown to the user).	
Results	A list of prior versions is retrieved.	
UML diagram		
Similar to		
Current practice		
Notes	This seems to be simply a case of creating and assigning the appropriate identifiers. Versioning presents an issue.

Map member stances by geography (MD S-14 UC-1)
From LII Legislative Metadata Project

Use case name	Map member stances by geography	
Use case number	MD S-14 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/02/16	
Last modified by	TB	
Purpose	Identify Members of Congress’s stances—inferred from roll call votes, sponsorship of bills, statements in debates and hearings, etc.—on particular topics (issues) (i.e., “member positions”), based on the state or intrastate region (e.g., congressional district, or multi-district area) represented by the Members of Congress	
Actors	Public User, Service, Specialist User	
System Prerequisite		
Prerequisite	1) Topically classified database of bills
2) Sentiment metadata for each bill, by Member, as inferred from other databases 3) Geographic database of member districts	
Sequence	1) User chooses single district or aggregate region, and topic
2) System retrieves relevant bills 3) System maps sentiments of "geographically relevant" members	
Results	Map of member support/opposition for a particular topic, by region.	
UML diagram		
Similar to		
Current practice		
Notes	Sentiment analysis presents a number of problems; it may be possible to infer it from (eg) a hearing record but voting behavior is probably a more certain indicator of a Member's ultimate position (though it lacks nuance).

Retrieve topical discussions from a particular time frame (RFP S-1 UC-1)
From LII Legislative Metadata Project

Use case name	Retrieve topical discussions from a particular time frame	
Use case number	RFP S-1 UC-1	
Document type	Congressional Debates and Congressional Record	
Specify other document type:		
Last modified	2012/02/05	
Last modified by	TB	
Purpose	Retrieve discussions of particular subjects that occurred during a particular timeframe, eg. discussions of slavery during the Continental Congress or the Reconstruction period.	
Actors	Public User, Specialist User, Visitor	
System Prerequisite		
Prerequisite	Dated documents that transcribe or otherwise report the discussions; subject-matter taxonomy that has been used to tag the documents. User needs to have some idea how their imagined time frame ("the Reconstruction Period") can be translated into calendar dates. It may be that some standard "calendar definitions" for frequently-used timeframes might be useful in guaranteeing uniform results for different users, or for the same user at different times.	
Sequence	1. User chooses time period, by dates, or by selecting predetermined "standard" timeframes.
2. User chooses subject.	
Results	A retrieved list of relevant Congressional debates, hearings, etc.	
UML diagram		
Similar to	MD S-7 UC-1, RFP S-5 UC-1	
Current practice		
Notes	Almost certainly also involves hearings and other discussion materials. It is not clear to what extent the materials have already been tagged for subject matter; there may be an NLP component to this.

Roll call vote analysis (MD S-3 UC-1)
From LII Legislative Metadata Project

Use case name	Roll call vote analyis	
Use case number	MD S-3 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/01/27	
Last modified by	TB	
Purpose	Identify roll call votes with particular characteristics, eg. all votes having between 50 and 60 yeas.	
Actors	Public User, Service, Specialist User	
System Prerequisite		
Prerequisite	See notes	
Sequence	See notes	
Results	Filtered list of roll call votes.	
UML diagram		
Similar to	JJ S-7 (included)	
Current practice		
Notes	a/k/a "the political scientist's dream", this use case imagines something a little different from what we are constructing. It does not call on metadata so much as it does the tabulation of voting information into a relational database that is optimized for statistical work or queries that result in compilations. It needs further analysis as to what the relevant characteristics might be.

Search for legislative history documents related to bill number (MP S-2 UC-2)
From LII Legislative Metadata Project

Use case name	Search for legislative history documents related to bill number.	
Use case number	MP S-2 UC-2	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2011/09/22	
Last modified by	RR	
Purpose	Find legislative documents related to a particular bill (i.e. legislative history).	
Actors	Specialist User	
System Prerequisite		
Prerequisite	1. Web browser
2. Bill number and number of Congress. 3. Sufficient metadata in legislative document records to connect to particular bills/legislation. 4. Relationship to or harvesting data from bill-tracking service	
Sequence	1. User enters bill number and Congress number.
2. User pushes search button. 3. Result set returned that has records that representing compilations/listings of relevant documents.	
Results	User selects relevant record/result.	
UML diagram		
Similar to	(MD S-6 UC-1) (MD S-5 UC-2) (MD S-5 UC-1) (jj UC:3)	
Current practice		
Notes	Document types for this use case include: Bill and references to related committee prints, hearings, reports (Serial Set), presidential signing statements, related bill versions, etc.
Other notes: Results could be comprised of records with compiled data (i.e. record compiles listing of documents). If not possible, search results would consist of individual documents related to bill number/Congress queried based on metadata for individual records (i.e. bill number/Congress reference should appear in metadata for individual documents).

Search for recurring subjects in legislation (JJ S-1 UC-1)
From LII Legislative Metadata Project

Use case name	Search for information historically in bills	
Use case number	jj uc:1-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2011/08/09	
Last modified by	JJ	
Purpose	Allow a user to trace a recurring subject of legislation over time.	
Actors	Specialist User	
System Prerequisite		
Prerequisite	1. browser
2. subject	
Sequence	1. User enters a subject into a search form which will search for bills where the subject is entered as subject metadata.
2. User clicks "search" and examines the results and selects a bill. 3. From a relevant result, user then clicks on "related bills" to see older and newer related material.	
Results	The user is able to use a subject to retrieve all relevant legislation, both current and past.	
UML diagram		
Similar to	MD S-1	
Current practice	1. User accesses the limited range of historical bills data in THOMAS or fdsys.gov.
2. User searches those services via random full-text search for relevant terms.	
Notes	Requires subject tagging of all bills and legislation using a controlled-language vocabulary, such as LC subject headings. A useful data model will include provision for such tagging, as which point interfaces can be programmed to allow searching on the controlled-language entries rather than via full text search. The result will be greatly superior precision and recall of relevant text.

Short titles (MD S-4 UC-1)
From LII Legislative Metadata Project

Use case name	Short titles	
Use case number	MD S-4 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2011/08/05	
Last modified by	TB	
Purpose	This is less a use case than it is a feature request; they want to be able to associate short titles with particular bills and resolutions, and must discover them by extracting them from the text	
Actors	Service	
System Prerequisite		
Prerequisite		
Sequence	1.	
Results	Presumably a list of short titles for the given document (the list might only be one item long)	
UML diagram		
Similar to		
Current practice		
Notes	

Study votes by geography (MD S-13 UC-2)
From LII Legislative Metadata Project

Use case name	Study votes by geography	
Use case number	MD S-13 UC-2	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/02/16	
Last modified by	TB	
Purpose	Retrieve metadata concerning bills addressing particular topics, based on the state or intrastate region (e.g., congressional district, or multi-district area) represented by Members of Congress who voted on the bills; correlate the geographic areas with vote categories (i.e., yea, nay, and abstain) and vote counts within each category; and, in the user interface, represent the correlations in a visualization (e.g., a “heat map”)	
Actors	Public User, Service, Specialist User	
System Prerequisite		
Prerequisite	Geographic database of Congressional districts; voting data; database of bills classified by topic	
Sequence	1. Retrieve set of bills by topic
2. Retrieve votes for each bill 3. Correlate categories of vote with home districts of those voting in each category	
Results	Heat map or other representation of aggregate voting behavior applied to districts.	
UML diagram		
Similar to		
Current practice		
Notes	Like many other use cases involving voting data, this would be much better handled with a database of votes created from the documentary record but stored in a format better suited for empirical analysis.

Topical legislative history, with intent (MD S-7 UC-2)
From LII Legislative Metadata Project

Use case name	Topical legislative history, with intent	
Use case number	MD S-7 UC-2	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2011/01/27	
Last modified by	TB	
Purpose	Identify legislative history resources on a particular topic that contain evidence of intent, for example respecting an annual appropriations statute.	
Actors	Public User, Service, Specialist User, Visitor	
System Prerequisite		
Prerequisite	A topic selected from a controlled vocabulary.	
Sequence	1. User searches corpus by topic
2. User applies the "intent" filter, whatever it may be.	
Results	A list of "resources"	
UML diagram		
Similar to	JJ S-4 UC-1, JJ S-4 UC-2, JJ S-4 UC-3, MD S-1 UC-1	
Current practice		
Notes	This assumes some kind of semantic tagging of the resources that show "intent", whatever than may mean. It is not clear how this would be discovered, though NLP techniques might suffice, or perhaps capture of analysis by (eg) CRS.
Document types for this use case include: Bill and references to related committee prints, hearings, reports (Serial Set), presidential signing statements, related bill versions, etc.

Topical legislative history (MD S-7 UC-1)
From LII Legislative Metadata Project

Use case name	Topical legislative history	
Use case number	MD S-7 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/01/27	
Last modified by	TB	
Purpose	Identify legislative history resources related to a particular topic.	
Actors	Public User, Service, Specialist User, Visitor	
System Prerequisite		
Prerequisite	User selects topic from a controlled vocabulary.	
Sequence	1. User searches for bills by subject. (see JJ S-1 UC-1, and MD S6)
2. User selects a particular bill. 3. User pulls legislative-history materials related to bill. ( see MP S-2 UC-2)	
Results	A list of documents dealing with the topic.	
UML diagram		
Similar to	JJ S-1 UC-1, MD S-1 UC-1, RFP S-1 UC-1, RFP S-5 UC-1	
Current practice		
Notes	Document types for this use case include: Bill and references to related committee prints, hearings, reports (Serial Set), presidential signing statements, related bill versions, etc.

Track bill and determine its status (MD S-20 UC-1)
From LII Legislative Metadata Project

Use case name	Track bill and determine its status	
Use case number	MD S-20 UC-1	
Document type	Bills and resolutions	
Specify other document type:		
Last modified	2012/02/16	
Last modified by	TB	
Purpose	Track the progress of a bill and determine its status	
Actors	Public User, Service, Specialist User	
System Prerequisite		
Prerequisite	Database of bills with procedural information
A bill number	
Sequence	User submits bill number	
Results	either:
1) A simple response indicating the status of the bill 2) A docket-like logbook of all actions on the bill thus far	
UML diagram		
Similar to		
Current practice		
Notes	As the results specification indicates, tracking a bill and determining its status can be thought of as two different things -- one (status) uses a limited vocabulary of well-known process milestones to say "here's where we are now". The other - more like a logbook -- would describe all actions taken on the bill thus far, possibly using a much finer-grained vocabulary of transactions. Each would be useful under different circumstances and each meets a slightly different user need.

PART EIGHT
Model spreadsheets and documentation
We used two spreadsheets to collect and document our work. The first, “Legislative Process Stages, Identifiers, and Documentation”, collects a great deal of related information in a structure organized around the steps of the legislative process. The second and more important of the two, “Legislative Properties and Classes”, documents the classes and properties that form the data model.  The “Classes” spreadsheet represents our thinking about the model, as well as analyses of representative examples.  The “Stages” spreadsheet is more in the nature of working notes that supported our design process by looking at the whole problem from the perspective of legislative process.  Indeed, we have left our working notes in place throughout the spreadsheet, believing that a view of the (sometimes amusing) underpinnings of our thinking and design process may be helpful in understanding the result.

We recognize that using spreadsheets for this kind of ontology presentation is not optimal in some respects, but it is more easily accessible for reviewers and makes collaborative editing of a model-in-process somewhat simpler.  Other sheets in the spreadsheet are more-or-less completely filled examples of the various corpora we were asked to consider as part of the BAA. Because the examples were done early in the modeling process, and not re-edited to reflect changes in the Master List, some of the example properties reflect earlier versions of the model before the technical testing was completed, but the examples still provide a useful view of our thinking. These are meant to be illustrative rather than complete representations of worked examples, but they do contain a considerable amount of illustrative actual data and our working notes.

Finally, we include expressions of the model in various OWL dialects, and visual representations of portions of the model.

SECTION EIGHTEEN
Legislative Process Stages, Identifiers, and Documentation
The “stages” spreadsheet (Legislative Process Stages.xlsx) is an attempt to organize a wide variety of information in a way that reflects the steps of the legislative process; it is a set of working notes that greatly increased our understanding of the legislative process and of the relationships between various systems of identifiers and metadata in use across the legislative branch, and may prove useful to others.   It includes, among other things:

●	A breakdown of legislative process into major and minor steps (columns A-D)
●	An event typology based on process steps (column E)
●	An attempt to align process/bill-status models from other systems
○	House and Senate XML (column F)
○	THOMAS and GPO bill status codes (column G)
●	A census of identifier systems in use throughout the process (column H)
●	Data-format flow and changes (column I)
●	Available documentation on each stage of the process, largely taken from CRS reports that have been publicly released. (column K)
●	Relevant document schemas (column L)

The spreadsheet does not take in much information about either the appropriations process or the process of reconciling measures once they have been through both chambers.   Also, we feel that our understanding of the  “asynchronous” parts of the process -- special procedures or events (such as tabling or committee discharge) that interrupt or alter the regular flow of legislative process -- was probably incomplete.  As we mention in our introductory remarks, these are both areas ripe for review and extension by others closer to the process.	

SECTION NINETEEN
Guide to the Legislative Properties and Classes Spreadsheet
This spreadsheet ()  contains our master list of classes and the properties that pertain to them, along with explanatory comments and information. It is divided into several tabs: a master list with a listing of all classes, followed by a series of spreadsheets, each dedicated to a major individual class. This part of the guide will walk through each of the sheets, with short explanations of the contents of each.
Master List:

A key to the columns in the master list is as follows:
	
●	A list of all Superclasses we identified for the classes we needed (column A)
●	Classes related to the Superclasses in Column A (column B) [Note that not all classes are related to a Superclass]
●	SubSubClasses where they occur (column C)
●	Properties identified to describe the chosen classes in Column B (column D)
●	Subproperty relationships with external property vocabularies available for the properties in Column C (column E) 
●	Ranges (also known as value classes) to identify specifically the datatype expected for those properties in Column C (column F)
●	Inverse properties as identified for the properties in Column D (column G) [Note that not all properties will have an inverse relationship]
●	The range of the inverse properties in Column G (column H)
●	Document occurrences within the groups of properties (column I)
●	Value vocabularies identified for use with properties in Column C (column J)
●	Use cases related to the classes and properties (column K)
 
We recognize that better understanding of all of these Classes and Properties would be achieved if we’d had the time to develop definitions, but time ran out before we could do that. Any effort to extend this work into a mapping phase would require the completion of those definitions, so that mapping relationships were based on the definitions rather than the labels. 

After the project is concluded we plan to add the Superclasses, Classes, Properties and Value vocabularies to the Open Metadata Registry, and to seek comments from outside reviewers on the usefulness of what we have done.  We’re particularly seeking reviewers with interests in legislative information or government information on the web.

Some of the properties have property/subproperty relationships visible in the spreadsheet. For example, the property “hasTitle” contains a subpropertyOf relationship to “dc:title”. Other related title properties, such as “hasShortTitle” shows a subpropertyOf relationship with “hasTitle”, and “hasShortTitle”, has itself several sub-properties under it. Each of these relationships is listed individually. Most of the properties listed do not have as many levels of relationships, but the spreadsheet accommodates them without too much confusion.

A few more comments on Column F might be helpful here. The column identifies the Range (also known as Value Class or datatype) to guide the assignment of values for that property. Note that the values in this column include basic datatypes, such as “Text” and “Date” as well as references to classes. For example, “hasShortTitle” expects a simple text string, whereas “hasOpeningStatementBy” has the class “Person” as it's value class.

During testing, we created an OWL representation of the model, which helped us identify gaps, relationship issues, as well as some places where more restrictions on the possible range of values within that datatype were needed. Because the OWL file has different capabilities than the spreadsheet, they are not an exact match, but should contain few if any conflicts. We’re planning on making the OWL file available as soon as practicable. 

Columns H and I contain any reciprocal properties that may be implied. Column I lists the kinds of documents in which the property may occur. If there is a special vocabulary which is intended to supply the values that the property will accept, that will be mentioned in Column J. Finally, Column K allows mention of related use cases.
Events		
The Events spreadsheet consists of three columns, each containing a level of event concepts gathered into the Event Type Vocabulary. This vocabulary is expressed in the OMR Sandbox as well: http://sandbox.metadataregistry.org/concept/list/vocabulary_id/336.html. It is important to note that the top level concepts are general categories (but can be assigned as they do have a URI), and only at the most specific level are they divided into into separate House, Senate, or combined chamber activities.
Bills and Resolutions
Bills and resolutions are described in separate spreadsheets, but since the columns in those sheets are identical, they can be explained together. Each spreadsheet starts with the major object class being described (a House bill or resolution, or a Senate bill or resolution). For each example, Classes or properties are then listed, and each class or property is also represented on the master spreadsheet (possibly in an earlier form), with relationships to other classes and properties. The next three columns define object restrictions (datatypes) and cardinality constraints, indicating whether properties are mandatory, optional, and/or repeatable,  Finally, example content and general comments are included. In the case of bills, House and Senate bills are both included. In the case of resolutions, concurrent resolutions are included as well as those of the House and Senate.

These spreadsheets may be color-coded (with some structural additions) so that they can eventually be the basis for ingest into the OMR, thus enabling their use by other applications. 
Bill and Resolution Amendments
Bill and Resolution amendments are two spreadsheets, but they have a similar structure, although columns are more condensed and each example is separated with a yellow bar.  
Committee Hearings, Prints, and Reports
Finally, all three of the above categories of documents have similar structure and labels.  Each consists of one or more examples of the document category, denoted in Row 1 of each sheet.  There are then three columns, Class/Property, Example Content, and Comment.  These list the attributes of the document, show and example of the attribute, and include explanatory comments. As in the other corpora, the model spreadsheet expands on many of the examples, and the final decisions on classes, properties, ranges and relationships were not transferred to the examples.

SECTION TWENTY
Visual and other documentation; model expressions
In addition to the spreadsheets, we have included other forms of visual documentation.  Some of these are in the form of “concept maps”, offered as binary files in the XMind format. These are readable with the XMind application itself (http://www.xmind.net/ ), or by a variety of other “mind-mapping” programs. The diagram of the “Lilly Ledbetter Fair Pay Act” will prove most helpful in gaining an overview of how the model is populated and applied.

We have also expressed the concept maps, fully expanded, as image files in a number of formats.  These are large and somewhat unwieldy, but should be readable with standard computer-graphics viewing software. 

Formal expressions of the model in RDF/OWL are also included, along with a class diagram.

SECTION TWENTY-ONE
Endnotes