The EverVerse application consists of three main modules. The first module interfaces with the Fitbit device and its data through its Application Programming Interface (API). The activity data of the poet wearing the device is then sent, in JSON form to the NLG module referred to as the 'generator.’ This generator carries out a number of steps in order to generate and return a poetic couplet based on a conceptual model of states based on the activity information contained within the passed JSON data. The number of words and the frequency of the generated couplets correlate with the heart rate of the poet, whereas the textual content of the couplet is generated from the input corpus which is fed to the generator. The input corpus currently comprises fifty nine poems on the topic of the body; all are previously published and none is composed by the EverVerse poet; a separate, nocturnal corpus is deployed when sleep data is passed to the generator. In order to disassemble and reassemble the corpora for publication in EverVerse, they are arranged in a reverse ngram matrix and further shaped into a frequency lookup table by Poesy, a Markov Model-based Natural Language Poetry Generator. The lookup table is used to create verse lines and a python library is deployed to rhyme the verses. In short, our method takes a language model approach similar to Barbieri, et al. although we do exploit some semantics, specifically alignment of couplets with fitbit activity states. Future work will involve experimenting with exploiting language resources such as WordNet and SentiWordNet similar to previous work by Tobing and Oliveira.
The generator is written mainly in the Python programming language using the micro web framework, Flask. It consists of a web interface to display the generated poetry and an administrator interface that is used to define heart rate parameters for different zones and to determine the form and content of the verse that corresponds to these zones.
Multiple versions of this interface were created for deployment on the web, in a live performance environment, and for display in a standalone exhibition setting. Each interface was adapted to take into account the context in which it would be experienced, for example, differences in how, or if, user interaction was required, and addressing the differing requirements for text size, line spacing, and overall page layouts.