📄 An English Reading Tool as a NLP Showcase

Summary

People reading English as a second language run into unknown words, characters whose names they no longer recall, tangled sentences, and lost context between reading sessions. This demo paper describes the server design behind SmartReader, a browser-based assistant that turns a plain document into an interactive text.

Each document is processed once, ahead of time:

• the orthography is normalized;
• Stanford CoreNLP splits sentences, tokenizes and assigns POS tags;
• the Stanford Dependency Parser, Stanford NER and Stanford coreference add syntactic and entity layers;
• a WordNet annotator picks a sense, and a compound annotator detects phrasal verbs and compound nouns;
• Heilman and Smith's question generator produces questions, which are then tied to entity mentions.

All layers sit in a UIMA document library. When the reader clicks or selects text, the system converts the action into a character offset and fetches the overlapping annotations. An intention-detection step then decides which response to show first.

No quantitative evaluation is given. The contribution is the integration architecture, which the authors claim could move to other languages if comparable tools exist.

Key points

• The architecture is client–server. The client is any standard browser on a PC or tablet, and the server runs under Tomcat, so readers install nothing.
• The pipeline is built on UIMA. Shared annotations such as segmentation, tokens and POS are reused by every later component, and all layers live in one document repository.
• Word senses are assigned without real disambiguation. After morphological and POS filtering, the annotator takes the most frequent Princeton WordNet sense, and a WSD annotator is still in development.
• Question answering inside the text works in two stages. Heilman's tool first generates and ranks questions for each sentence, and those questions are then attached to each mention in the matching coreference chain.
• Clicking any piece of a discontinuous phrasal verb or compound noun highlights the entire compound and shows its meaning.

Interesting ideas

• I1. Every user request is reduced to a character offset, and the answer is whatever annotations overlap it, so a single generic lookup serves all features.
• I2. The response type is not chosen by the user but inferred from which annotation layers sit under the click and around it.
• I3. Questions are generated sentence by sentence and then spread to every coreferent mention, so a later pronoun inherits questions about its entity.
• I4. The sense annotator is a deliberately simple baseline (POS and morphology filter plus most frequent WordNet sense), with a slot left open for proper WSD later.
• I5. Phrasal verbs and compound nouns are recognized even when split by other words, and treated as one unit for meaning.

For Mova

How these ideas could serve Mova, our small open language model — its files, stages and tests:

• I1 (answer): an explanation interface could fetch the token, UD arc, frame and world entity under any offset, showing why an answer was given at that exact spot.
• I2 (answer): a reader could pick its explanation mode (word gloss, frame, entity history) from the layers present at a position instead of using a fixed menu.
• I3 (learn): self-play could produce questions from source sentences and route them through coreference chains, testing whether the world model resolves "he" to the right referent.
• I4 (world): the WordNet ontology lookup could start from a POS-filtered most-frequent sense and log each choice, serving as an explainable fallback and as a control against which a disambiguator is measured.
• I5 (tree): compound:prt and compound arcs in the UD tree could merge discontinuous multiword predicates before frame lookup, so "picked the book up" maps to a single VerbNet entry.