EventExtractionPapers is a dated reading list for the event extraction task

There is nothing to install, and that is the point

The repository contains two files, a LICENSE and a README.md, and the description is a list of NLP resources focused on the event extraction task. That is the entire artefact. There is no package to install, no script to run and no configuration, so the question of a first run does not arise. What a reader does instead is open the README, expand the table of contents and read. The value of a curated list is that it removes the work of discovering which paper belongs to which line of work, and for a task like event extraction, where the terminology shifts between event detection, event coreference and information extraction, that indexing is the harder part of the reading. The licence is MIT, the default branch is master, the repository is not archived, and the last push was on 2026-10-02. There are no GitHub releases, which is unsurprising for a document rather than a program, and the topics list names the field terms: event-coreference, event-detection, event-extraction, information-extraction, nlp and papers.

The taxonomy is by learning paradigm, not by task or dataset

The table of contents is the most informative part of the document, and it reveals what the author considered the useful axis of organisation. The sections are Pattern Matching, Machine Learning, Deep Learning, Semi-supervised Learning, Unsupervised Learning, Event Coreference, Surveys, Others, Linguistics, Data, Tools and Repos, and Other lists. Method first, application second, is an unusual ordering for a reading list and it tells you something about the field. The same task, say recognising that a merger happened, can be approached with hand-built patterns, with feature-based machine learning, with neural networks, with a fraction of labelled data or with none at all, and the reader who wants to know what has been tried in each of those directions is served better by paradigm groupings than by a flat chronological list. The linguistics section is the one that stands out, since it suggests the author wanted to include work on the linguistic side of event mentions rather than only systems. The Other lists section, pointing outward to other curated collections, is the usual courtesy in a list of this kind.

Entries carry the abstract, so the list can be skimmed offline

The formatting decision here is what makes the list usable. Each entry is a collapsible details block whose summary line is a numbered link with the paper title and the author names, and whose body is a blockquoted abstract taken from the original publication. The AutoSlog paper from 1993, by Ellen Riloff, is a representative example: the summary names the paper and links to the AAAI proceedings PDF, and the quoted abstract describes building a domain specific dictionary of concepts for extracting information from text, with a dictionary for the domain of terrorist event descriptions constructed in only five person hours and compared against a hand crafted dictionary that took two highly skilled graduate students approximately 1500 person hours, and the two evaluated on two blind test sets of 100 texts each. Because the abstract is in the file, a reader can decide whether a paper is worth opening from the search result page of the repository, without visiting a dozen publisher sites. That is a real convenience for a list with entries spanning three decades.

The early entries are knowledge based extraction, not neural methods

The visible portion of the list opens with pattern matching work from 1993, 1995, 1998 and beyond, and reading those first entries tells you how the field framed its problem before deep learning arrived. AutoSlog and its successor AutoSlog-TS by Riloff and Jay Shoen address the knowledge engineering bottleneck, where knowledge based systems need a domain specific dictionary that requires a great deal of manual work, with AutoSlog-TS acquiring conceptual patterns from a preclassified but unannotated corpus and achieving higher precision on one test set than the hand crafted dictionary. The PALKA system by Jun-Tae Kim and D.I. Moldovan acquires linguistic patterns in FP structures from training texts for the MUC-4 information extraction system. Scott B. Huffman's LIEP learns extraction patterns directly from examples of texts and events. And Dayne Freitag's multistrategy learning paper argues for combining several kinds of information in domains where much of the text is ungrammatical, such as bulletin board posts and web pages.

Where the data and tools sections matter for a practitioner

Two sections carry the practical weight for someone who wants to run the task rather than survey it. The Data section collects datasets, and the Tools and Repos section collects implementations. That is the part of a reading list that ages worst, because a paper URL tends to survive while a code repository moves, is rewritten in a new framework, or quietly stops working when an upstream dependency changes. The readme does not date individual entries, so a reader cannot tell from the list alone how current any given dataset or tool is, and a tool that was usable a year ago may not build now. The same applies to the surveys section, where a survey from five years ago describes a body of work that has moved. A researcher should treat the list as a map of where the work has been, verify each artefact at the source, and then check the surrounding discussion for anything published more recently, since the list itself is the artefact that has been maintained rather than the field it indexes.

Where this list is the wrong tool

Three situations argue against it. The first is a project that needs a working baseline, since a list of papers gives you a method to implement and an evaluation protocol to copy but no code to run, and a researcher with a deadline will spend more time reimplementing than reading. The second is someone who already knows the field, because the value of a curated list is highest at the entry point and drops sharply once you can already name the relevant authors, at which point a search over the literature indexes serves better. The third is a reader who wants the current state, since the list is organised by paradigm rather than by benchmark, and paradigm groupings hide the fact that a particular method is what currently wins on a particular dataset. The realistic alternative for the practical cases is a task specific benchmark with a leaderboard and a maintained implementation, and the alternative for the survey case is the most recent survey in the Surveys section, read for its structure rather than its conclusions. The list is still the right starting point for the first of those, because it tells you which methods exist and what problem each one framed.

Editorial conclusion

Adopt this list when you are entering the event extraction area and want a chronological map of the paradigms with the abstracts available locally, and look for a task specific benchmark or a maintained toolkit instead if you need running code. Verify first which sections the list actually covers, since the visible table of contents groups by learning approach rather than by dataset or application, and check the individual paper links before citing anything, because the list records what existed at the time each entry was added rather than tracking which results still hold.

Frequently asked questions

Official sources

1. BaptisteBlouin/EventExtractionPapers on GitHub
2. Issues
3. License: MIT
4. README