The overwhelming majority of effort, as far as data capture was concerned, was to convert the records of the Convention into a timeline of specific events. This work involved a combination of data entry and an interpretation of the records, in two senses. Descriptions of a proposal to be debated needed to be converted into the precise change to the texts intended, and some inconsistency between the extant records (usually to do with the precise sequence of events) needed to be resolved. Those converting the records into this model read through the parallel records of each committee session (where multiple records existed), and decided how to reconcile any conflicts between the records. They recorded such decisions in a private “editors’ commentary” as part of the process. It was initially envisaged that reconciling the records in this way might be impossible—especially if competing forms of words were found recorded for the same proposal in different sources. The platform was therefore designed to allow for competing versions of the Convention timeline to be captured, and for the platform to be able to capture and display any uncertainty about the precise wording of the texts in question. However, it was found that in practice these features were not needed and that (where records existed at all) it was always possible to reconstruct the timeline of particular sessions if records were carefully reconciled by subject experts. An ability to read the records closely and to interpret them in a consistent and logical way was the key to making this part of the project a success. The advantage of designing a platform for ease of use by non-technical users was that that those recruited for data entry could be selected for their subject matter expertise. Due to the nature of the material and the model, an automated process for ensuring the accuracy of data entered into our system was not possible. We implemented a system that would allow the data entry for each session to be marked as verified and for those in charge of the project to view who had entered and who had checked each section of the data.
This data entry phase also involved a certain amount of formative evaluation. As data were entered, we continually assessed whether the model as designed (which had been developed principally from a study of parliamentary manuals) was capable of capturing the work of a process of negotiation from the records that survived in practice. The process of data entry provided multiple opportunities to consider how the model would be best used to most accurately capture the process of decision-making, and the decisions taken about how to use the model were documented to ensure consistency. Where appropriate, minor changes to the data entry dialogues were made to encourage proper use.
Experience proved that data entry was intuitive for non-technical users with a few hours of training and supervised practice. The most frequent type of event in our model of the Constitutional Convention debates is the “Document Amendment”. Those working to enter the data select the point in the timeline where they wish to insert an amendment. They then select the document they wish to amend, and whether they are amending the base document or one of the proposed amendments. Once they have made this choice, the platform presents them with the current state of the text at that moment, which they are invited to edit to reflect the state of the document as it would be if the new amendment were to be accepted. They also enter other information, such as the source from which this event is taken, a free-form description of the event, and any known proposers of the amendment. When they have finished, the platform calculates the difference between what the user was presented and what they returned, and associates that patch with the new event.
The next most frequent type of event is a “Decision Event”. This records a decision on a particular proposal, be it to alter the text of an amendment, to adopt a section of text into a document, or to accept or reject a document as a whole. There was considerable inconsistency in the records as to the level of detail with which such decisions were recorded. Sometimes the records note with certainty which delegations voted for or against particular motions; sometimes, only the totals on each side were known; sometimes, only the outcome was known. Again, it was feared that the extant records might provide conflicting accounts, and so the platform was designed to allow competing accounts of the votes on particular questions to be displayed, or simply to represent the uncertainty created by the records themselves.
It was sometimes necessary to infer from the records that a particular decision had been taken. For example, it was the practice of the Convention to debate and amend sections of text and then to approve or reject the amended section as a whole. Sometimes, this approval is not recorded in any of the extant sources. This may reflect the fact that the Convention was inconsistent in applying its own procedure, but it is equally likely that a unanimous consent to accept a section as amended and move on to the next order of business was simply not recorded by the secretary as such. Our interface, however, required the insertion of “Decision Events” to capture what the editors inferred to be a decision to agree text and move on. Such interpolated events are clearly marked within our platform. The need to include them highlights the fact that this project produces a model of negotiations, not a literal transcription of source material. It may be obvious from the sources that a particular piece of text has been agreed, even if there is nothing in them explicitly stating the fact.
The implicit rejection of text is a little more complicated. It will be the case in the course of a negotiation that particular suggestions that have been scheduled for debate have simply been overtaken by events—the section of the document to which they refer may have been altered in ways that make the suggestion redundant, or a similar suggestion may have been debated and agreed. In some cases, debate on an issue may simply be managed in such a way that a formal conclusion is never taken, perhaps to avoid the embarrassment of those involved. In these situations, there may never been a formal rejection of a proposal, and even to infer one at a specific point in the timeline may be misleading. For this reason, as well as marking proposals as “accepted” and “rejected”, the Quill platform’s model includes the ability to mark a proposal as “dropped”. From the point of view of the model, this has an identical effect to marking a proposal as rejected. It is removed from the list of pending proposals, along with any child amendments, and it is not incorporated into the document. However, including this as a specific type of event allows a more accurate representation of the process of negotiation than the simple binary choice of accepting or rejecting a proposal, and can be made visually distinct for users.
The most surprising aspect of the platform for new users is that most documents debated by the Convention need to be represented at least twice. Most committees do not work from a blank sheet of paper, but work from an initial base text, either suggested by one of their members or passed to them from another committee. Frequently, they work through this document line by line or paragraph by paragraph, and in so doing produce a new report. The Convention operated in the following way: a framework set of proposals, or suggested document (such as the famous “Virginia Plan”) would be offered to the Convention. This would be referred to a subcommittee—in the case of the Virginia Plan, the whole Convention sitting as a subordinate committee. This committee would work through the document section by section and clause by clause, and produce a report for the Convention to consider. The Convention would then work through this report, again amending section by section and clause by clause. In this way, everything would have been considered at least twice, once by each committee.
In a world of paper, quill, and ink, this process created a significant record-keeping challenge, which it would have been the task of the secretary to manage. As the Convention or subcommittees worked through the documents referred to them, he would have had to write out the new text on clean sheets of paper. No doubt these sheets of paper rapidly became untidy and even hard to follow, and perhaps, it is for this reason that they were not entrusted to Washington for safe-keeping but were instead deliberately destroyed, even though copies of the various base documents are extant.
When represented in the Quill platform, this process looks identical. If a committee is working through one document to create its own report, the initial document is not shown as amended, but rather the clauses of it are modelled as being gradually incorporated into a new document, which represents the report of the committee. The platform captures the relationship between these documents by allowing any document in the platform to be marked as having one or more “ancestor documents”. In visualizations currently under development, this allows readers to view the overall changes made by a committee through this process of revision.
We have found that training is required to help users to interpret the journals of negotiations in order to build successful models within the Quill platform. Modern users, even those with experience of research in political and legal history areas, are relatively unfamiliar with the details of parliamentary-style processes. It is important to emphasize to new users that the platform models negotiations, rather than demands a one-to-one relationship between the events we record and wording within the records of a negotiation. We record, for example, the decisions taken upon a proposal, even where those decisions must be inferred from the records rather than corresponding to a particular vote. In some cases, the best use of the model must show an understanding of the process as it was understood by participants, and requires editors to decide on a consistent way to represent particular situations. For example, where a committee works through a section of a proposed text clause by clause taking a vote on the section as a whole only once that section is complete, this is most accurately modelled as a blank amendment (or one containing only the section number) to represent the moment when the committee turns its attention to a particular section, followed by sub-amendments representing the consideration of each clause. This allows the committee’s sense of its own work to be accurately captured in our model, and groups correctly related proposals, but it requires those entering the data to be trained in its use and to apply it consistently. It is not possible (or desirable) to enforce such use in software. Another example is where a clause is “subdivided” for separate votes, as many parliamentary-style processes demand. Our data entry manual recommends that this be modelled as a proposal to reject the original wording and then the introduction of two new amendments representing each part of the divided clause. Our experience has been that where these modelling decisions are correctly explained to users during training, they rapidly become natural to those undertaking data entry tasks.
We were also concerned to make it easy to encourage precise commentary and accurate record-keeping. For users with appropriate permissions, a button to add commentary to any event within a timeline was presented, which presents the user with a pop-up form. Editors creating commentary collections use this button to add their comments. The data entry team used this same system to flag issues within the timeline which required review. Commentary collections serve two functions. The first is to display commentary relevant to particular events or other objects within the platform. The second is to provide a mechanism to guide users to points of interest within the timeline. Collections dealing with particular topics serve as both guides and bookmarks for readers, as well as providing explanatory notes. Since several authors may choose to comment on the same objects for different purposes or offering distinct interpretations, this also allows the platform to present multi-authored explanatory material while making clear the purpose and authorship of particular comments.
As we have worked with wider ranges of users and on different material, we discovered that the original data entry screen proved unnecessarily detailed for the vast majority of uses, and focused attention away from the texts under discussion at a particular moment. The ability to create events at arbitrary positions within a timeline is powerful, but frequently unnecessary. Teams of users entering data into the platform spend most of their time adding events sequentially as they work through particular journals of negotiations. These users spend most of their time adding events to the end of the timeline. For this reason, we have created two screens to assist them. The first of these displays, which we call the “document library”, shows the documents available to a committee at the end of its timeline, divided into documents that have been agreed, documents that are still being debated, and documents that have been referred to other committees for review. For each of these documents, a link to a single-page display of the current agreed text of the document is available, as is a link to the place in the timeline where the document was created and to the place in the timeline where the last decision about the status of the document was made. This allows users to quickly see the current state of negotiations. A second display, which we call the “Committee Secretary’s view”, again focuses on the state of the documents available to the committee at the end of the timeline (see Fig. 9). This screen combines elements of the original editing screen and the session visualization screens, allowing easy access to the list of documents and proposals currently before the committee, and easy access to the accepted, intermediate, and proposed texts of any proposal, including a view highlighting the specific changes that it would make. From this screen, it is possible to add events only to the end of the current timeline, rather than to make more arbitrary changes. This simplification allows the available space on the screen to be devoted to the most frequent tasks of data entry, while access to the more powerful tools remains available. This screen is also more useful when using the platform for record-keeping during live meetings.
A significant problem that we have encountered as we have expanded our work is the nature of the source material available to model various negotiations. In addition to the model of the Convention that is available online, we have a number of other projects in various states of development. We have observed that, although the process of debate within formal negotiations and legislative assemblies is frequently well documented and often formally published, the initial draft texts introduced for discussion are missing from the journals and formal publications, and require additional archival work to recover. The work of subcommittees is frequently not published at all, or published separately from the main journals. Counterintuitively, this suggests that the publication of the proceedings of legislative assemblies and other negotiations have been intended to record the fact that debate had taken place, and memorialize the fact that particular individuals had taken part, but provide in themselves even a careful and diligent reader with insufficient information to recover the details of the negotiations. If initial draft texts ever proved impossible to recover, our model could be adapted to work backwards from final texts rather than forwards from initial drafts, at the cost of significantly complicating both the user interface for data entry and the level of skill required to work with the records. In practice, having examined the records available for modelling the work of French assemblies after the French Revolution, American state-level constitutional conventions in the nineteenth century, the work of the Paris Peace Conference in 1919, the work of the United Nations, and the framing of India’s constitution, we assess that while the necessary records frequently need to be collated for the first time from a variety of sources, they are nevertheless likely to be available in most cases in sufficient detail and with sufficient providence to allow our model to work.