Making Metasausage
[ Special thanks to Mohammad AL-Asswad, Stevan Gostojic, Sara Frug, Rob Sukol, and of course to Ralph Seep, who contributed many ideas to this.]
This may be the geekiest blog post ever on any subject to do with American legislation, and I would not blame you if you fell asleep before reaching the end. I nearly did. But references to runs of sections are actually elusive creatures that can be important both to legal research and data modeling, and I suspect that there is more than a little folklore attached to them. Indeed, we’d developed some of our own, and part of this post is about how we learned better.
A few days ago, we released a feature — based on data from Cato’s Deepbills Project — that permits us to link pending legislation in Congress to the US Code sections it discusses. It makes a kind of early-warning system for people who what to know what Congress might change sometime soon. While we were working on it, we were reminded that legislative references to the US Code very often take the form of runs of sections such as “54 USC Secs.123-456” or the even more open-ended “54 USC 123 et seq”.
Such references can be far from clear, both as to what might be contained in them, and as to what the meaning of such a reference might actually be. Sometimes, it isn’t clear whether they are meant to be considered as a sort of totality or blob, or (instead) as a list of sections that should be individually associated with whatever the reference to the run is asserting. We could imagine that data modelers, programmers, and even law librarians might be as confused as we were. Hence this post.
What’s inside a run?
Long ago, we realized that you cannot calculate the contents of a run of sections using its endpoints and an algorithm — you must query an inventory of all the sections in the Code. Runs of sections are not translatable to ordered lists of sections with integer numbers. If you doubt this, spend a little time clicking around in 12 USC Chapter 13 , where you’ll find a chamber of numbering horrors that includes Section 1749bbb-10c and other such delights. And if you were to enumerate all the sections in the run 12 USC 1748-49, you’d come up with more than 2. A lot more than 2, in fact. There are easily dozens, maybe a hundred. Our solution has been to build a database of section numbers encountered while processing each Title of the Code, and when we need to determine which sections fall between the endpoints of a run, we query the database.
“Et seq.” references, which have a lower bound and leave the upper bound to float, are obviously harder to handle – so much so that a separate section describing them appears below.
Blob, or list with unique members?
Another question is whether a run of sections is meant to be a list of sections, each of which is being referenced as an individual, or whether it is meant to be a blob to which the reference applies generally. A good example of the “blob” approach is found in Table 3 of the US Code, where Stat. L pages are mapped to section runs in the Code. When I talk about a “blob”, I mean that provisions found somewhere in the run of Stat. L. pages map to provisions found somewhere in the run of US Code sections listed in a sort of general way — each blob is a container that has in it the same ideas or provisions, but not in any particular order and not in any way that can be easily mapped to named units within each blob. It is not the case that stuff found on the first Stat.L. page is found in the first US Code section listed, and so on — the Table is only claiming that the stuff discussed in this run over here is also discussed in that run over there. Of course, it could also be that the list is meant to be enumerated, and that the reference is meant to apply equally to all individual sections. I have a suspicion that that is rare (for reasons that may become clear later), but it does happen.
For data modelers, this raises some important questions. For example, when we encounter a run “in the wild” — say, when we’re extracting stuff from a legislative document — should we note it as a run, with its own URI, or should we enumerate it out somehow and assign some property to each section individually? Often, there is no way to tell, and our conclusion is that it is safer to create a URI for the run as a blob, and let applications decide whether it is safe, dangerous, or even necessary to assign properties to the individual items within each blob.
Ghost stories
One theory — fairly difficult to verify, but plausible based on observation — is that most section-runs are ghosts. They had a life, once, as a named chunk of an Act or of some other document, but they lost that name when they were codified, or moved into positive law, or otherwise assimilated into the Code. And in fact it is much easier to dereference something that refers to a precise run of sections than it is to figure out where to find a chunk of stuff named in an Act that has long since been absorbed by the Code. There may be value in knowing what the original name was — in fact, as a practical matter, we’re wrestling with the question of how far that should be pursued. But we do know that such “ghost stories” are important when you try to unravel the meaning of an et-seq reference.
The joy of et seq.
An “et seq” reference is a reference to a run of sections that states a lower bound but no upper bound. There are practical reasons for this that have to do with updating (see below for an example). Many, if not most, et-seqs have a lower bound that corresponds to the start of a named unit of the Code. For example, the section named as the lower bound of an et-seq is often the first section in a US Code Chapter, in Titles where the Chapter is the first level that aggregates sections. In such a setting it is reasonable to assume that the implied upper bound of the et-seq is the last section of the Chapter.
For many years, we assumed that was all there was to it. But while we were working with the Cato Deepbills data, we found a few things that made us question our assumptions. So we asked our friends at the Office of the Law Revision Counsel, the guys who do all the codification, and we got this very helpful reply from Ralph Seep, the Law Revision Counsel (lightly edited here):
The most important principle which informs the use of “et seq.”, as well as many other features in the Code, is that when possible, the Code should somehow be a reflection of statutory structure. Elements that are grouped together in some logical way in a statute should ideally be grouped together in the same way in the Code. As a result, when these elements are referred to as a group (such as a reference to an act or a title of an act) that reference will be relatively easy to carry over into the Code.
In general, the preference is to take such a logical grouping and classify it as a discrete unit in the Code, such as classifying an act containing multiple titles to a new chapter containing multiple subchapters. Therefore, when there is a reference to the act or to one of its titles, the Code can easily refer to that chapter or to the relevant subchapter. Since every section in that unit is being referred to, naturally the reference would be to the first section in the unit and all the ones following it.
It is highly doubtful that “et seq.” would be used at the sub- or supra-section levels not so much because Code practice disfavors it, but simply because statutes tend not to group elements together in that way. Although theoretically possible, of course, it is somewhat unlikely that subsections (d) to the end of the section form some logical unit that would be referred to, thus necessitating a reference to “section 101(d) et seq.”
By the same token, if a run of act sections goes together closely enough to constitute a logical grouping, chances are it would comprise a discrete unit of that act rather than just a random run of sections. So, just as it would be rather unlikely for there to be a reference just to the last 4 sections of an act title (and potentially any future sections later added at the end), there would be no Code equivalent to referring to those last 4 sections using “et seq.”
Here is where the background discussion becomes especially important. In current practice, the preference is to take an act or discrete unit of an act and classify it as a similarly discrete unit of the Code. However, there are numerous instances in the past where this did not happen. For example, prior to its editorial reclassification, the Central Intelligence Agency Act of 1949 was classified to sections 403a to 403w of Title 50, which constituted a run of sections neither starting nor ending subchapter I of chapter 15 of that title. We consistently referred to that act as classified to “50 U.S.C. 403a et seq.”, which means that “et seq.” was being used when the first section was not the first section of the unit and the last section was not the last section of the unit. There are other such instances when an act is classified to a run of sections not constituting a discrete unit of the Code (Pub. L. 92-300, 16 U.S.C. 558a et seq.; act Mar. 2, 1887, ch. 314, 7 U.S.C. 361a et seq.) Such acts have sometimes been referred to by the range of the first to last section (such as 7 U.S.C. 361a to 361i), but such practice has been abandoned in favor of using “et seq.” so that if new sections are added to the end of the act later, the references do not need to be updated.
And there you have it. For the researcher, the upshot is that all references to runs of sections need to be looked at carefully, first to determine exactly what their extent is, second to see what falls within that extent, and third whether the run is meant to be considered as a totality, or as a list of things to which some assertion or quality applies.
Speaking formally
Data modelers who are working with models that contemplate section-runs may be interested in the collections ontology discussed in this paper and documented further at https://code.google.com/p/collections-ontology/. Unfortunately, it does not seem to contain a class for an ordered list of unique objects, so we extended it to contain a UniqueList class (we think we might equally well have done an OrderedSet class). As mentioned above, we’re initially modeling all runs as collection objects and leaving it to particular applications to decide whether they should be enumerated as individuals or treated as blobs.
As is traditional, we end with a musical selection.
