Beginning his work which was to be the first called a “history”, the Greek author Herodotus describes his task in simple terms: “to preserve the memory of the past by putting on record the astonishing achievements both of our own and of other peoples”  (line 1.0). Within the first few chapters, though, it becomes clear that, to Herodotus, this entails something more multivalent than mere story-telling. His very next sentence buttresses the narrative with references to its various, even conflicting, sources 1.1; not much later, he corroborates his stories by referring to physical artifacts and providing careful genealogies 1.7, 1.14; and throughout he attempts to place the notable events of the past within the available chronological outlines (e.g, 16.1). From its origins, then, history has been conducted across a framework of argumentation, evidence, chronology and prosopography.

This intellectual approach, begun by Herodotus and his rough contemporaries around the world, has proved a durable and useful way of thinking. Moreover, as the global Internet expands, and the common software technologies of the World Wide Web provide us with unprecedented means of communication, humanity has greater access to more historical statements and more of the raw materials of history than ever before. Indeed, it might be said that today's Web has the makings of an historian's fantasy: it provides worthy encyclopedia entries on a vast array of topics; its textual editions are rapidly improving in quality and amassing in quantity; and it offers historical source material ranging from argumentation in on-line editions of the best journals to the first-hand accounts appearing in blog entries. Scholarly historical projects published uniquely on the Web are common, supported by academic centres whose purpose is to communicate history effectively in new media, and who are also addressing the general problems of adopting best standards of scholarship to the Web in projects such as Zotero. Behind the scene, data formats such as the CIDOC-CRM aim to make it possible to interchange and reconcile vast cultural archives.

However what today's Web offers in historical content, it lacks in organization. The multivalent nature of historical thought that we noted in one of its earliest practitioners eludes the keyword-indexed approach to the Web today on offer through Google and other search engines. Though we can summon up an exhaustive list of Web resources that contain the words “Gallipoli” and “sources”, today's Web cannot effectively respond to a basic historical question such as, “which sources attest the Gallipoli Campaign of World War I?” much less a more advanced one such as, “what evidence is there for major architectural projects undertaken in the U.K. during the period of the Boer War, and does anyone think that these projects are influenced by the conflict?” If it were possible to conduct such a query, of course the result would not itself qualify as “history” any more than the results of a Google search constitute knowledge. However, the results of such a hypothetical search would offer a considerable aid to historical research and thinking, just as the indices, maps and, occasionally, tables that appear at the end of most monographs allow the reader rapidly to access matters of interest. Applying this analogy, what is needed in the Web is “universal back-matter”, a Web-wide equivalent to the traditional print monograph's helpful conventions.[1]

Herodotus and his successors have given us a template for such a project. Minimally, it will need to express associations between words describing the event through chronology, geography and prosopography. It will need to provide references to diverse sources and evidence, and it will need to traverse, as much as possible, the boundaries of local language and even local time-keeping techniques.[2] Indeed, over fifteen years ago, the prescient Historian's Workstation Project employed the same basic types of data [Thaller 1991]; however, the Internet has added the challenge of working with a more heterogeneous set of data sources and today's possibilities for the visualization of historical data go far beyond the Workstation's.[3]

The Historical Event Markup and Linking Project (Heml) has pursued the vision of a system such as this since 2001, when it began to explore the markup and transformation of historical materials on the Internet using XML tools. All schemas and code developed by this project are available at its website, http://www.heml.org/ and complete revision history is provided in an SVN repository. This paper explains Heml's next step toward the goal of an historical Web. It outlines the data format used by the project, shows the shortcomings of our previous XML-based approach to historical markup and describes the potential of an historical markup scheme based around the W3C's Resource Description Framework, or RDF, to interchange historical concepts widely and to express them in a more nuanced manner.

It is a pleasure to be able to offer this paper in the collection of works celebrating the achievements of Ross Scaife. Like so many efforts in computing and the Classics, this one has been nurtured by Ross' kind support and encouragement. Furthermore, I have always hoped that Heml would attain the level of openness and helpfulness that are the hallmarks of Ross' work and of his character.

The goal of a searchable network of historical information can only be reached through a clear separation between the model of the data being searched, the parameters of the search and the resulting visualization of the data. Since the project intends that these visualizations be generated dynamically in response to users' queries, the data model must be specific enough that the visualization can generated quickly; likewise, since the results of users' queries could result in no events, one event, or thousands of events, and the range of values represented in these encoded events could be quite wide, the visualization processes must be written so as to generate useful views without regard for the number of events visualized or how close or far they are in time and space. For this reason, the Heml project has attempted to steer a middle path between pragmatism and markup idealism, especially regarding chronology. Thus, its data schema, on one hand, is not a complete abstraction of any way in which a person might think of the past, since this would make the task of visualization too daunting. In particular, its schema requires machine-readable data for all defined geographical and chronological data. (As shown below, this does not preclude the schema representing uncertainty.) On the other hand, the schema is not merely an API for the various visualizations offered by Heml; it is abstract enough that many other visualizations and uses could be discovered.

At its inception, the Heml server software transformed XML documents one-by-one [Robertson 2002]; in versions 0.4 to 0.7.2 the project adopted a distributed XML model, backed up by the eXist XML database [Robertson 2004], an approach that worked well in a collaboration with Tom Costa's project, Geography of Slavery in Virginia, where a Heml Web application backed by eXist transforms events pertaining to slaves into hundreds of dynamically generated maps and timelines. In either case, the project's data model has remained the same for the past four years, and the following describes the model labelled 2003-09-17.

The Heml data format contains a collection of modelled events, each tagged with heml:Event. At their most simple, events bind an event label with a machine-readable span of time and a reference to evidence, which could be as simple as a single URN. Optionally, a heml:Event may also comprise any number of keywords, and a single location, which in turn is defined as a labelled pair of latitude and longitude coordinates. heml:Person elements may be added to events in order to represent those people who were in some way involved in the event. If the nature of this participation is known, the heml:Person element may be bound to a heml:Role element within the context of the event. Persons, roles, locations, and keywords are assigned mandatory URIs so that they may be referred to in multiple events. Finally, one or more heml:Evidence elements must be attributed to each event, and within these there is a means by which different editions and linguistic representations of the same text may be grouped together for the researcher's benefit.

The most complex part of Heml's data model is the heml:Chronology element. Its model is intended to express uncertainty and ranges of time without requiring the visualization engine to have access to all data.[4] In Heml markup, chronological concepts are always built using one of the following four elements: heml:DateTime, heml:Date, heml:Year or IntCalDate. The first three of these encapsulate data encoded in the corresponding XML Schemas format; the last permits the user to encode with a non-Gregorian calendar. When used alone, these elements are meant to indicating a corresponding span of time: for instance the <heml:Year>-31<heml:Year> indicates an event that began on the first second of the first day of 31 BC and ended on the last second of its last day. To express a more expanded range of time, the heml:DateRange element is used, and within it mandatory heml:StartingDate and heml:EndingDate elements. This construct is parsed as indicating a span of time beginning at the beginning of the first element and ending at the ending of the last one. To express uncertainty, the heml:BoundedDate element is used. It comprises a heml:TerminusPostQuem and a heml:TerminusAnteQuem element; these express the earliest possible and latest possible time respectively of a span of uncertain time. Use alone, heml:BoundedDate makes no claim about the duration of the encoded event. However, it is permitted to use a heml:BoundedDate within the heml:StartingDate or heml:EndingDate of a heml:DateRange. Thus the XML in Example 1 encodes as an event beginning at exactly 21:03 UTC on May the twenty-first 1995 and ending at some time on March the twenty-first 2005.

There are other schemas from other fields that encode representations of labelled spans of time and place. Dublin Core Metadata standard includes date and location tags that, in certain uses, encode certain kinds of historical events, but these naturally revolve around the documents themselves, such as publication information; they cannot, for instance, encode the battle described therein. Similarly, the P5 edition of the TEI includes a welcomed set of biographical and prosopographical tags, including one for events. However, at present, all such P5 event elements must appear within a person or place element, expressing that the event information serves to further our information about a given person or place: events that pertain to neither at present cannot be encoded.

Finally, the CIDOC-CRM encodes descriptions of cultural artifacts in terms of the events they undergo — their creation, change of custody, and so forth. Though not the primary focus of this schema, historical events are quite broadly modelled in this schema. Indeed, as is shown below, the unmodified CIDOC-CRM model is too liberal for the Heml Project's purposes of generating historical visualizations, especially with reference to what entities and datatypes it accepts as chronological predicates. Nevertheless, it is likely that most of the goals of the Heml project can be fulfilled through RDFS subclassing of the the CIDOC-CRM model, ensuring more carefully data-typed chronological classes. In any case, the discussion and examples below would apply as well to such a constrained CIDOC-CRM model or to any future schema with similar properties. Indeed, the purpose of the Heml project is decidedly not to promote a particular schema; instead, its schema is intended as a tool which enables us to explore the process of combining all material encoded in all these well-entrenched and widely-adopted schemas so as to increase the pool of inter-related historical data on the Internet.

Technologically, there is little challenge in transferring data from one of these representations to Heml. XML representations can be exchanged through XSLT. In RDF, the SPARQL CONSTRUCT query form produces transformations from one graph to another. For example, [Robertson 2006] shows how useful a simple Heml and Dublin Core mash-up conducted in XSLT could be.

Heml data is encoded in order that resources pertaining to a certain historical event may be found in response to a user's query. The query might be expressed with regard to any one of the facets of historical expression encoded by the schema above, or on some combination of these. The software discovers the corresponding materials, then generates a visualization of these data according to the user's wishes. Visualizations range from simple chronological text lists in HTML to complex animated maps. Of course, since the data has been prepared without reference to any given visualization, not all visualizations are informative representations of all query results. For instance, an animated map would not be helpful if the set of events in the query response all had the same location or did not have locations encoded at all.

In the most recently-published version of Heml's server software (v. 0.7.2), visualizations are generated through a Java Web application based on the Cocoon Web service engine. Instructions for building and running this software locally are available at http://www.heml.org. Using this approach on locally-stored data takes full advantage of Cocoon's ability to cache server-side processes. However, it is also possible to use the server at http://www.heml.org to transform any conforming document published on the Web without building or installing software. Instructions are provided online.

As described above, all the visualization tools developed by the project operate fully automatically: they provide sensible chronological and geographical boundaries based only on the conforming data on their input and layout the appropriate text without clipping or abbreviation, regardless of the number of events being presented.

The graphical timeline view, of which Figure 2 and Figure 3 are examples, lays out event labels at a vertical distance from each other corresponding to their separation in time. It indicates spans of time through vertical coloured lines. This view was designed to be legible and to require as little user interaction as possible, emulating a graphical timeline in print. In fact, the rendering software iterates through layout scenarios in order to find one that is appropriately compact but whose text is still possible to read. It ensures that the entire text labelling an event is always visible to the user, and scrolling is not necessary to read the event label. The software also selects an appropriate range of dates or times for the events; these can range from a seconds to millennia.[5] Rendered in SVG, this view's event labels are linked to popups that lead the reader to the resources pertaining to the event.

This approach to timeline-generation differs from other online graphical timeline-drawing, perhaps best represented by the the Simile timeline widget. At present, the Simile timeline is not auto-ranging, and does not attempt to optimize layout. Rather, its documentation encourages users to identify so-called “hot zones”, temporal ranges comprising unusually large numbers of events so that the drawing routine can alter the scale in these ranges, thereby producing a more legible layout. The goals of the Heml project, requiring a fully automated rendering, do not make such hand-tweaking possible. However, Simile timeline's excellent use of client-side rendering and DHTML are certainly preferable to the Heml timeline approach. We hope that by modify the open-source code for Simile timelines we can adopt that project more closely to our needs, perhaps by identifying “hot zones” computationally.

Another event-visualization system pioneered by the Heml Project is the animated map illustrated in Figure 1. (1) is a set of user-operated controls familiar from audio-visual apparatus. With these, the user can stop, play pause, rewind and speed up the animation. Item (2) is a slider control that sets the length of the animation in seconds. Item (3) is a moving marker that runs along the line above the animation from left to right, thereby indicating the moment in time currently represented on the map. Above the small triangle a constantly updating text appears recording the current animation time. The event labels at (4) appear in red text as long as the animation is representing a date during which the labelled event is encoded as having taken place. In order that the user be able to read them, event labels do not necessarily disappear as soon as the corresponding event ends in the animated time; rather they remain on the screen in black text until the text has appeared for at least two seconds. The system designates an appropriate chronological scale to the process, as well as the geographical range of the map.

Although these visualizations have fulfilled some of our goals, they have also pointed out some deficiencies in the underlying data model. Figure 1, for example, presents an apparent mishmash of events. Perhaps the user undertook a too-broad query, but when dealing with any large dataset this sort of result is common because the XML schema puts all events, no matter how trivial, on the same footing. It has therefore been suggested that events should be ranked, or should nest, with large scale events such as “The Persian Wars” expressed as parents of their composite events, like “The Battle of Thermopylae.” In response to publications and presentations of the Heml/XML model, others have expressed a desire for more complex historical relations between events to be encoded. Should not Heml express something as simple as causality, such as the fact that Ephialtes' treachery led to the defeat of the Three Hundred? Finally, it has been noted that with Heml/XML markup it is not possible to encode the variations in opinions regarding historical events. When scholars debate the date of the arrival of the Greek-speaking ancestors of the Mycenaeans, what date should be encoded for this event?

Some of these issues have been tackled recently by [Nakahira 2007], but in the Heml XML Schema they were intentionally left unaddressed for both theoretical and practical reasons. First, it has been this project's experience that resolving such relations with a language such as XQuery or XSLT was difficult and computationally expensive. Secondly, since the XML Schema expresses matters pertaining to an event by nested elements, it was unclear where a statement linking two elements should appear. Pertaining no more to one element than the other, ideally it should stand outside the heml:Event elements, but this raised the prospect of always new schemas required to provide metadata for previous schemas. Finally, a XML schema through which scholarly debate could be encoded for any facet of an event seemed likely to be unmanageably complex.

Our work of the past year shows that these problems can be addressed by using the W3C's Resource Description Framework (RDF) as our means of encoding Heml events and related information.[6] As a collection of statements expressed through URIs, RDF is well suited to define metadata that expresses associations between events. Because these statements are unordered, these associations can be asserted in any source of data, anywhere. Moreover, RDF defines a method known as “reification” whereby a statement comprising Subject Verb and Object can itself play the role of subject or object in another, encompassing statement. Example 2 illustrates the process with an example from Greek prehistory. The first line makes a simple statement, without attribution, that the ancestors of the Mycenaeans arrived in the Greek mainland in 1600 BC. The second line indicates the reification of that statement with parentheses, and attributes this chronology to Drewes with the hemlRDF:asserts predicate. The third line refers to the same <#Arrival_of_the_Greeks> subject, but it shows that Renfrew assigns that subject a much earlier date. The URI corresponding to a scholar then becomes a part of the query, and it is possible to encode, and later summon up, an entire body of knowledge with reference to the scholar asserting it. For example, the chronology of fifth-century Athens could be encoded with reference to the arguments of Badian or those of Pritchett. This technique becomes all the more important when even more tendentious predicates are applied, such as causation. [7]