Historical reconstructions can help us better understand important events. This is essential for bettering our knowledge on specific topics and this enables us to build coherent sequences of information. Knowledge graphs like Wikidata contain information about generic knowledge that includes historical events, but the information is often entity-centric rather than event-centric. This makes the analysis and understanding of events related to a same topic harder, since it is less easily accessible. In this demonstration paper, we developed a system to build a timeline about the French Revolution in the form of a graph of a sequence of events, also called a narrative in this work. The system comes with an interface, where a user can first select the types of events to be retrieved, and is then walked through the steps of the system. The output of the system is a timeline of the French Revolution.
We constantly create narratives to provide explana- A narrative is one way to understand or explain a
tions or justifications for why and how somethings series of related events. In this work, a narrative is
happens. This capability of creating such narratives technically defined as a sequence of events in the
is even suggested to be part of what makes us human form of a graph. A narrative in this context is thus
[
The system presented in this demonstration pa- Narratives are a means for better understanding
per builds a narrative in the form of a graph. A how a situation unfolds over time. The events are
narrative is defined here as a sequence of events. the atomic concepts underlying these narratives.
The main novelty of the paper is a system that walks Towards formally defining such structures, Bartalesi
the user through the diferent steps of the process and Meghini [
From an application perspective, the closest to with a description of each event as well as event
our work would be systems that use knowledge bases type and participants. The demonstrator currently
for timeline or hypothesis generation. The aim of outputs a timeline for the French Revolution only,
such systems is to help a user understand better one but could be extended to other types of revolutions
topic. For quality, Althof et al. [14] define three for instance. The code is publicly available1.
criteria for a timeline quality: relevance, tempo- The backend is written in Python 3.9.4, the
interrally diverse and content diverse. For applications, face was developed with Streamlit2. Wikidata was
Metilli et al. [
In the demonstration system, the user is walked through the diferent steps to build a narrative graph: 1) Collect events from Wikidata and select paths to extract nodes from 2) Extract features from Wikidata 3) Extract additional information from Wikipedia info boxes 4) Convert the data into RDF triples compatible with the Simple Event Model 5) Display the narrative graph as a timeline,
events from Wikidata. In the demonstrator, the user can select a collection of paths to extract events from, depicted in Figure 2. The user can then press the button “Collect events” to query the Wikidata knowledge graph.
Events and links to Wikidata and Wikipedia are stored in the backend, and the user is provided with some additional information, such as the number of events retrieved.
Once the events have been extracted from Wikidata depending on the user’s input paths, the next step is to extract narrative features for the events. A narrative feature for an event contains information about either a participant, a timestamp, a location, a type of event, or a temporal or causal link to another event. In Section 2. and 3. displayed in Figure 1, the user can press a button to extract these features.
In the demonstrator, the user can see the features that were extracted, as well as some additional statistics on the distribution of the types of features.
We found that features extracted from Wikidata contained mostly information about time and location, whereas features extracted from Wikipedia contained more information about participants and causal links.
Features in Wikipedia also contain hyper links to other Wikipedia pages, which can therefore be linked back to Wikidata. We use and retrieve these corresponding Wikidata pages to have consistent URIs for the final graph. 1https://github.com/SonyCSLParis/ building-fr-narrative-from-wikidata 2https://streamlit.io were therefore discarded from the timeline.
Figure 3 shows one event description for the 10 August. The user can read a summary of what hapFigure 2: Collecting events from Wikidata pened during this event, as well as some additional information retrieved from Wikidata and Wikipedia.
The user therefore understands that 10 August was 3.3. Building the network a riot implying diferent actors like Louis XVI of France as a commanding oficer, or the French First The next step is to build a narrative graph of Republic as a combatant. Figure 4 lastly displays the French Revolution events and their descrip- the interactive timeline overview. The user can tion, in the form of RDF triples. The rules manually slide events over time and click on each of to convert the extracted features for each event them to better understand what happened. On the to triples were designed manually. The ontol- bottom of the figure, one can see that it is also posogy used is the Simple Event Model [16]. The sible to see which events happened during a coarser four main classes of this model are: sem:Event period of time, like for example the Kingdom of (what), sem:Actor (who), sem:Place (where), France. and sem:Time (when). Further constraints classes sem:Role, sem:Temporary and sem:View can add information on the role of an actor, a temporal 4. Conclusion constraint or on a specific viewpoint respectively.
tem that is able to retrieve events and features of 3.4. Timeline output the French Revolution to construct a timeline of The final output in this demonstrator is an interac- ordered events and descriptions. During this protive timeline. This timeline contains ordered events cess, the user can choose how events can be selected extracted from Wikidata, as well as three addi- and is walked through the diferent steps of the tional components: (i) a brief description taken from process, that makes the system transparent. The Wikipedia (ii) event type information (iii) partici- user lastly has access to an interactive timeline to pant information. The events with no timestamps better understand the series of events during the
The system described in this paper furthermore helped to identify some first challenges for building narratives from knowledge graphs. These challenges are linked to the main steps described in Section 3: 1) collect data 2) extract features 3) build the network. The main challenge for collecting data is to assess how to best choose the set of events that optimally describe the coarser event. Should such a set contain all events that happened, or only the most relevant, or only the ones that are interesting for one user? When extracting features, there is the challenge of completing missing information, like participants or locations. What additional resources or algorithms are best to complete the narrative graph? Lastly, the challenge when building the graph network is to find or define the ontology that is best suited for the application, and to populate this ontology.
Takeaways from this paper are also about possible future work directions. One first direction could be to study the temporality of the narrative, to better understand how events unfold. In the demonstrator, the timeline output provides a sequence of events ordered in time, but it does not provide explanations for how one event might have triggered changes that in turn caused another event. One second challenge and direction is about the evaluation of the narrative. For instance, one assumption here is that Wikidata and Wikipedia contain objective noncontradictory facts, but one interesting track would be to compare diferent input resources, or to add confidence scores to each triple. Another direction would be to see how well the system would scale to other events such as other revolutions. Lastly, one direction could be linked to pattern identification and event forecasting, to generalise from instantiated examples.
funded by the European MUHAI project from the Horizon 2020 research and innovation programme under grant number 951846 and the Sony Computer Science Laboratories Paris.
We thank Ilaria Tiddi, Annette ten Teije, Frank van Harmelen and Remi van Trijp for their time and support. tic Technology Conference, Springer, 2019, pp. 18–34. [11] I. C. Dorobăt,, V. Posea, Enriching the cultural heritage metadata using historical events: a graph-based representation, in: International Conference on Theory and Practice of Digital Libraries, Springer, 2019, pp. 344–347. [12] K. Leetaru, P. A. Schrodt, Gdelt: Global data on events, location, and tone, 1979–2012, in: ISA annual convention, volume 2, Citeseer, 2013, pp. 1–49. [13] E. Boschee, J. Lautenschlager, S. O’Brien, S. Shellman, J. Starz, M. Ward, ICEWS Coded Event Data, 2015. URL: https://doi.org/10. 7910/DVN/28075. doi:10.7910/DVN/28075. [14] T. Althof, X. L. Dong, K. Murphy, S. Alai, V. Dang, W. Zhang, Timemachine: Timeline generation for knowledge-base entities, in: Proceedings of the 21th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, 2015, pp. 19–28. [15] H. Kroll, D. Nagel, W.-T. Balke, Modeling narrative structures in logical overlays on top of knowledge repositories, in: International Conference on Conceptual Modeling, Springer, 2020, pp. 250–260. [16] W. R. Van Hage, V. Malaisé, R. Segers, L. Hollink, G. Schreiber, Design and use of the simple event model (sem), Journal of Web Semantics 9 (2011) 128–136.