{"id":93,"date":"2013-10-29T09:37:26","date_gmt":"2013-10-29T14:37:26","guid":{"rendered":"http:\/\/blog.law.cornell.edu\/metasausage\/?p=93"},"modified":"2013-10-29T09:58:31","modified_gmt":"2013-10-29T14:58:31","slug":"events-and-legislative-documents","status":"publish","type":"post","link":"https:\/\/blog.law.cornell.edu\/metasausage\/2013\/10\/29\/events-and-legislative-documents\/","title":{"rendered":"Events and legislative documents"},"content":{"rendered":"
\u00a0[..] 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.<\/em><\/p>\n — Allen and Ferguson, \u201cActions and Events in Interval Temporal Logic\u201d<\/a><\/em><\/p>\n Legislative events — things that take place as part of the legislative process — seem straightforward to define. \u00a0They are those things that occur in the legislature: \u00a0meetings, debates, parliamentary maneuvers, and so on. \u00a0\u00a0But let\u2019s look at one of the more important words we associate with legislative events: \u00a0\u00a0\u201cvote\u201d.<\/p>\n As a noun, it has two meanings:<\/p>\n an occasion on which people announce their agreement or disagreement with some proposition;<\/p>\n<\/li>\n the documentary record of that occasion, expressed as a tally of yeas and nays.<\/p>\n<\/li>\n<\/ul>\n That duality — what happens, versus the record of what happens — creates confusion. \u00a0We often talk about the documentary record as if it were the process, and vice versa. \u00a0That 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. \u00a0Subtle differences in understanding about what data models represent \u00a0can lead to real confusion about the capabilities of information retrieval systems. That is particularly true during conversations about design and evaluation.<\/p>\n Here, we have tried to be explicit about when we are speaking about what. \u00a0Let\u2019s begin with a discussion of modeling problems that pertain to events-as-occasions. \u00a0A second section treats identifiers for events and how they might be collected and dereferenced. \u00a0Finally, I\u2019ll look at the incorporation of events into a model of legislative process.<\/p>\n Useful work on events is found in strange places that, after a moment\u2019s thought, turn out not to be so strange after all. \u00a0Much of what follows was derived from the event ontology developed at the Center for Digital Music at the University of London<\/a> — musicians spend a lot of time thinking about things that are embedded in a time-stream, so it\u2019s not surprising that their events model is both detailed and useful. \u00a0In their world, and ours, events are things that occur at a time and place. \u00a0They might have duration, but they might also represent an action or change of state for which duration is irrelevant. \u00a0For example, you could 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. \u00a0But that would be silly; some events are simply process milestones or instants that have no duration we need worry about. \u00a0Most events have participants. Some groups of participants are recurring or somehow formalized; \u00a0it makes sense to tie events to our models for people and organizations<\/a>. \u00a0Other participant groups may be ad hoc groups defined solely in terms of the event (\u201cthe people waiting for the 3 o\u2019clock bus\u201d). \u00a0Finally, \u00a0things are often products of events : 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.<\/p>\n Events may have duration, or they may not. \u00a0\u201cBill introduction\u201d and \u201cadjournment\u201d 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. \u00a0Usually, though, we think of them as instantaneous abstractions that refer to a point in a process. \u00a0By the same token, events may have a duration that is defined with an uncommon use of common language. \u00a0A \u201clegislative day\u201d is an example of such a thing<\/a>: it extends between one adjournment of the Senate and the next, which may occupy days or even months in real time.<\/p>\n We\u2019ve \u00a0discussed people and organizations in a separate blog post<\/a>. \u00a0Participation in events raises a few other questions about our models for people. \u00a0In 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. \u00a0For 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. \u00a0Thus, it is necessary to have a set of role properties that describe the individual as that person appears in the context of particular events, perhaps in a way that is different from other roles that that person might play with respect to groups or organizations that are somehow associated with the event.<\/p>\n Many events take place somewhere in real space, so event objects need to have attributes that tell us where the event occurs. \u00a0\u00a0As with other data about places, we might choose to model these with geographic coordinates, locations drawn from geodata ontologies, or both. \u00a0\u00a0But neither of those systems deal particularly well with things like office addresses (\u201c1313 Longworth House Office Building\u201d), which provide location information for the kinds of events we associate with legislative process. \u00a0Those tend to be expressed as office locations or postal addresses. \u00a0Examples of purpose-built systems for postal addresses include the Universal Postal Union S42 standard<\/a>, the vCard ontology<\/a>, and the W3C PIM standard. \u00a0Of these, the vCard standard seems to present the best balance of detail and workability<\/a>, and is incorporated into the http:\/\/dvcs.w3.org\/hg\/gld\/raw-file\/default\/org\/index.html<\/a> .<\/p>\n Often, location information is not explicitly stated, but implicit in the nature of the event itself. \u201cMeeting of the House Ways and Means Committee\u201d, for example, embeds a reliable default assumption about where the meeting is to take place. \u00a0That is because the meetings always take place in the hearing room that belongs to the committee. \u00a0It makes sense to model default assumptions about locations as something that is a property of the organization (e.g. \u201chasDefaultEventLocation\u201d) rather than of any particular event. When information about the event itself is partially or totally incomplete, a location can be inferred via the organizational sponsorship of the event.<\/p>\n Some events are primarily interesting as collections of other events — for example, a \u201csession\u201d of Congress, which might be seen as a collection of various occurrences on the floor of the legislative chamber, committee meetings, and so on. \u00a0Moreover, 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.<\/p>\n That has implications for identifier design. \u00a0As 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 convenience of access or for setting up alternative groupings of things. \u00a0Event identifiers need to be short and opaque; \u00a0identifiers for collected events can have elaborate (and varied) semantics associated with path elements in the URI. \u00a0\u00a0Here are some illustrative examples:<\/p>\nWhat\u2019s an event?<\/h2>\n
\n
Events as occasions: modeling problems<\/h2>\n
Duration and timestamps<\/h3>\n
Participants and their roles<\/h3>\n
Location and location defaults<\/h3>\n
Events that collect other events; identifier design<\/h3>\n