Networked Events
Entities
Verbs
»Verb List
»Verb Groups
Events
Dates & Time
Nanohistory might appear fairly complex, but you will find it is quite simple in its construction. The networking of historical interactions between agents and objects, over time, and in distinct places, lie at its heart. These interactions - or as we call them 'events' - naturally come together as Networks because the agents and objects in these interactions are shared across any number of interactions. This 'networked event model' allows Nanohistory to document and create representations of complex interactions as series of temporally limited networks of historical activity.

Say an historical scholar wanted to document the interactions within a text that described an altercation in a city square, and its description. A good working example would be:

On May 1, 1658 Chad told Abe he saw Ben kill Dean in Leicester Square

Nanohistory's networked event model provides a way of breaking this complex interaction down into a series of events, following the sentences syntactical structure, in order to create data that can be referenced in other contexts, and visualized in a number of ways. Because the event is documented with a fine (nano-level) granularity, users can then refer to and note other historical texts or evidence with corroborating or contesting data. Square brackets ([]) contain a separate event with arrows denoting agency from left to right (->).

[May 1, 1658]->[Chad->spokeTo->Abe]->content->[[Chad->witnessed->[Ben->killed->Dean]]->in->Leicester Square]

Breaking this down we find several separate events, and we can assign each a unique identifier, allowing them to be referenced in subsequent events. Note, each event is a named graph, or quad, and that we've altered the verbs and their tenses slightly. You can find out more on why on our events and Verbs pages.

1: Ben killed Dean
2: Chad witnessed {1}
3: {1} in Leicester Square
4: Chad spokeTo Abe
5: {4} content {3}
6: {5} hasDate May 1, 1658

Nanohistory makes these events available to all users to corroborate or contest, or even complicate. Say an additional source noted the same altercation between Ben and Dean:

Peter noted in his letter to Thomas that Ben had killed Dean out of anger for stealing his ox.

Another source may document Ben's trial and conviction for murder.

Ben was accused and found guilty of murdering Dean in Leicester Square. He was convicted and sentenced on May 29, 1658.

We now have more events, but the initial event involving Ben and Dean overlaps between the three sources. Here is a clear case of a networked event - an interaction that is documented in a variety of sources, and involved a multiplicity of agents and contexts, but all refer to the same initial event: a murder in Leicester Square.

Here's the full list of events in all three documents:

Source 1

1: Ben killed Dean
2: Chad witnessed {1}
3: {1} in Leicester Square
4: Chad spokeTo Abe
5: {4} content {3}
6: {5} hasDate May 1, 1658
7: Source 1 mentioned {6}

Source 2

8: Peter wrote Letter
9: {8} to Thomas
10: {8} mentioned {1}
11: Ben owned Ox
12: Dean stole {11}
13: {8} mentioned {12}
14: Source 2 mentioned {8}

Source 3

15: Court accused Ben
16: {15} of murder
17: Court convicted Ben
18: {17} of murder
19: {17} content {1}
20: Court sentenced Ben
21: {20} for murder
22: {17} hasDate May 29, 1658
23: {21} hasDate May 29, 1658
24: Source 3 mentioned {22}
25: Source 3 mentioned {23}
26: Source 3 mentioned {16}

This seems like quite a bit of data and complex. But it is. It's what historians do all the time, even if only mentally. We now know that Ben owned an ox - we can refer to that elsewhere, and perhaps trace more events, like its purchase, and movement from one estate to another. We also have reference to six separate individuals, and the Court, as well as Leicester Square. Nanohistory's event building tools help scholars assemble and note events quickly and easily. The platform does much of the breaking down of individual events, and connecting them to one another, meaning you'll never see lists like this in practice - it's how the data is stored. We're also working on tools that will use Natural Language Processing and Entity Resolution to help automate these tasks, allowing users to upload a text, sit back and edit the results once they come in.

This is only one example of a fairly limited event. Imagine the complexity - and the utility - of being able to document and account for complex events and happenings like migrations, correspondence networks, manuscript trees, a battle, or a community. Since we're using RDF principles, we can ask questions of this data using semantic web methods like "who killed Dean in May 1658?" Or we can ask historioraphical questions like "Which sources mention Dean's murder?". Perhaps even, it might emerge that in some cultures or communities Dean's murder has a particular significance: it was, in fact, an assasination, and has been named as "The Assasination of The Oxen Driver". As rudimentary as this example is, it illustrates Nanohistory's approach to documenting historical interactions as a new kind of data-driven historical writing. It also allows us to think about what sources, events, and evidence one user (an historical scholar) might assign and describe as part of the assasination, and what another may not.