I have been thinking about freeing books from their containers, & how it could work for poetry publishers (as poems, & their individual publication in magazines & anthologies as well as in collections, are an obviously separate unit within a book). I have been thinking about a hypothetical model for how a C21st poetry publisher could work, based on database-driven websites — i.e., content management systems — which gives more control to the reader, enables greater content discovery, brings readers & writers closer together, & reduces risk in the investment of publication.

(Please bear in mind that this post is a work in progress. Feedback will help!)

1. The Model

For this explanation, let’s pretend we have a dedicated poetry publisher called Electio. (They will soon perhaps become something that we would not immediately recognise as a ‘publisher’.)

Up until this point, Electio has operated typically. On its list Electio has a hundred poets, some of whom having only published a pamphlet, some of whom having published several collections. One of its poets is called Mary. Electio has also published a couple of anthologies.

At this point Electio decides to think differently.

In Electio’s list the smallest, fundamental discrete unit is the poem. Electio holds the rights to everything they have published from their one hundred poets, which amounts to some twenty-five thousand poems. All of these poems are then stored on a database. In having been added to this database, each poem has already passed the ‘gatekeeper’; each poem has been selected for its quality, albeit as part of book-bound thinking. All of these poems are stored digitally, along with considerable metadata (e.g., the title; how long it is; when it was added to the database; what form, if any, it is written in; what genre; what themes it relates to, best thought of as tags; which other poets it might relate to; etc.). The poems are also linked to a database of the Electio poets, with all sorts of biographical data (e.g.: name; age; nationality; place(s) of residence; influences; etc.). This is not too different from how one would structure a database-driven website. (This model essentially already exists: a WordPress website such as this one, for instance, with the capability to ‘export’ its posts into an ebook — Anthologize being one way of doing this — is halfway there.)

From this point, if the workflow observes the separation of content & presentation — if it is based upon templates — any publication by Electio can then be generated from the database on any given criteria.

Badly drawn diagram of publication with this model (note the cold, vacant eyes of the poets)

A reader, or the publisher, queries the database based on certain criteria, which presents the results of that query using a template into any format, digital or print (with print-on-demand). (Any new ebook formats can be easily added in with the templates.) In theory, creating a book of sonnets is as simple as (in dummy SQL):

SELECT * FROM Poems WHERE Form='sonnet'

The more comprehensive the metadata, the greater the number of functional queries, & so the mission of this sort of publisher would be to accumulate as much (useful) metadata as possible. Since all poetry books are inherently criteria-bound, & both reader’s preferences & how they discover new content are also criteria-bound, it makes sense to connect the two. By automating the workflow & then putting it partially under the control of the reader, the publisher is opening up its assets as ‘content’ that is accessible to the reader. In this way, supply & demand can be  matched, rather than having poetry publishers who (because of low sales) are unable to invest in putting out books for which there may not be a demand. (You can think of this model as a sort of immediate subscription model.) That said, it’s likely that in practice the biggest-selling books from Electio would be publisher-query (because of their added value), & that reader-query publications will instead make up the long tail of sales. & even if publisher-query publications (i.e., traditional books) make up for sixty percent of Electio’s sales, reader-query publications will allow them to scoop up the other forty percent which would otherwise have been missed.

The most obvious application of this is anthologies, which most obviously take the form of criteria-based selection. (We can take our cue here from typical anthology titles.) The Electio Book of Short Poems, for instance, only requires defining ‘short’ in numerical terms (in number of lines), & then generating a book based on the result of that query to the database. We can do the same for poems on any publication date , any theme (if we tagged them), or indeed anything else included in the metadata. Since the poems are linked to biographical data of their authors, we can generate books based on those criteria too; e.g., The Electio Book of Young Female Poets, The Electio New London Poets, etc. Our hypothetical poet, Mary, who is young & lives in London, would feature in both of these anthologies. (A complication with anthologies is with ‘intra-system’ selection; see 2.a.) Ultimately, a reader could also create a multi-poet publication by individually choosing the poets they like, rather than trying to catch them with a single query.

So far this is based on a static database of poems, but the model doesn’t have to be only a way of opening up the backlist. Electio have decided to change their entire business model to fit this system. Submissions will change in this model, as poets are, after all, not necessarily submitting a manuscript of poems for a pamphlet or a collection; they are just submitting individual poems for inclusion in the database, & publication whenever a reader decides on a ‘book’ which selects them. However, this does not necessarily mean that poets will only submit individual poems, as to a magazine. ( Although, poetry magazines have something to teach this model. Paying a poet by submission is one example of magazine practice that Electio could adopt.) Mary, who may otherwise have only been trickling the odd poem into the database, now adds fifty new ones. (To borrow more terminology, this time from Git, it is best to think of adding poems to the database as ‘committing’ them; that is to say, poems are drafted, redrafted, & edited before they see the database, & are then added when they are at a point similar to when a traditional model would publish them.) Electio may announce this & present a new query: that which resembles Mary’s new collection, & which produces all the poems written by Mary added after a certain date. Electio can produce a special template for this particular query, with a specific cover & maybe a foreword about Mary’s work. This book is, in result, not much different from what publishers & readers are used to.

At this point you may be thinking that the Electio model actually takes out, or needlessly complicates, the role of the publisher, since the reader/consumer is creating the books they purchase, but this isn’t true. First of all, in result if not in process, publisher-query books are essentially identical to traditional model books, as mentioned above. Additionally, as also mentioned above, the process up until poems are added to the database is much the same as the process up until poems go into production in the traditional model. But even overall, the role of the publisher (divided departmentally as editorial, production & marketing) is not greatly different:

• Editorial work is pre-system (& intra-system), & in acquisition to add poems to the system, so: editing poems before they are committed, reading submissions to find new talent, & even commissioning or seeking out new poets. The editors at Electio are also curators of the database of poems.
• Production work is much the same, for general templates & even more so in creating publisher-query publications. There is also responsibility in managing the workflow, even if the books are generated automatically.
• Marketing is also essentially the same, although the Electio model puts greater focus on the publisher’s stable of poets as their main asset (as well as the brand of the publisher). Promotion of the poets, through readings etc., & enabling greater contact between readers & writers, is perhaps more important than it is in traditional model publishers

This model is very firmly consumer-, rather than retailer-, centric. The main value for readers from this model comes from control over what they consume, but also, crucially, in content discovery. (Of course, by making it easier for readers to find & purchase poetry that they like, Electio & its poets benefit too.) The final database which Electio can create, & possibly the most important one, is that of its customers. Interaction with the Electio online bookstore allows the system can create & work from knowledge of not just that reader’s book-level preferences (as Amazon does), but their specific poem-level preferences. Electio can suggest new content for the reader based on this information. Furthermore, since, as mentioned above, content discovery by the reader comes from extrapolating out from a certain attribute into a selection criteria (e.g., “I like this poem by Mary; I would like to read more poems by Mary”, etc.), Electio directly enables this form of exploration & discovery by working in the same way. Visitors to the Electio bookstore will be able to see their poets, read sample poems, watch videos of or listen to readings, & then, to get to the serious part, either buy a publisher-query publication, or assemble one of their own. Generating books on-the-spot means generating a price for these books on-the-spot, especially if poets are paid by a royalty-based system. Beyond this, if their publication is a digital one, they should then (although this is dependent on the technology) be able to interact with the bookstore from within the publication; e.g., click a new poet to go to their page & then order a ten poem sampler,  right from within the ebook. Readers will also be able to personalise their books: as well as having freedom with the query, they could choose from a number of templates & customise various aspects within the template they decide on (e.g., cover image, title, a message within the book, etc.). The reader could have some degree of customisation in the template of publisher-query publications, if they are being generated. With selection down to the poem level, readers could also share their books, like mixtapes.

The value for poets in this model is that it is in the interest of the publisher to promote their stable of writers, rather than just their publications. There is also the possibility of a greater engagement with readers who are seeking out their work, as this model minimises the presence of the publisher (or even of the bookseller) as the middle-man. Also, poets are accustomed to working at the poem-level, rather than the book-level, from magazine publication, competitions, etc., & so may prefer a system where they can submit & earn from single poems. As a side note, it should also be very easy to introduce a crow-funding element to this model, like Unbound, as it deliberately encourages a direct engagement between readers & their favourite writers, & the work their writers are producing in relation to the readers’ tastes. Readers who are accustomed to extrapolating their tastes sideways across a database of poems to explore what they like will be more willing to extrapolate their tastes forwards in time, & pay for poems that haven’t been written yet.

2. Fiddly bits

For the model to work as sketched out above, there are some complex issues which I haven’t mentioned for the sake of simplicity. It is unlikely that these are interesting to most readers of this piece as we are beyond the conceptual space of the thought experiment & into how the actual application could work. There are also some vague potential ideas for how the model could expand beyond how it is mapped above.

a. Discoverability

So far, metadata has been thought of only as open criteria for generating publications. However, it is likely that some metadata will be required for internal use by the system to add discrimination to the results returned from each query.

One example of this is a value, either as a binary yes/no or as a numerical value assigned meaning by the system, of ‘discoverability’ (I wish I could think of a better word) , as either ‘is this discoverable?’ or ‘how discoverable is this?’. This is to solve the problem of intra-system selection in anthologies, mentioned briefly above.  The Electio model generates anthologies or collections, so multi-poet or single-poet texts. In multi-poet queries, if no discrimination is imposed within the response, the results will return too many poems. For example, if Fred wishes to have all poems on ‘love’ from a given year, & in that year Mary added a twenty poem sequence on the theme, his anthology will contain all of these poems. It is only in a single-poet query (on Mary) that he is likely to want all of these poems, & it would instead be better if the multi-poet query only brought back a selection of this sequence, being those marked as discoverable (assuming discoverability was a binary value). A numerical value of discoverability (say, from one to five, with one being the most discoverable, & every poem being at least five), would allow the choice, in multi-poet queries, of how wide one wishes to cast one’s net. (It would also allow for selection in single-poet queries, rather than the option of simply ‘restrict the results or don’t restrict them at all’. This would mean that it would be easy for a reader to buy a small ‘sampler’ of a poet’s work, like buying that poet’s chapter in an anthology.) Discoverability (as a numerical value) need not necessarily be assigned by an editor, as it could also be adjusted as a rank of its popularity (meaning how many times it had been brought out by queries).

b. Online access

Considering how Electio would require a strong online presence & user registration/integration, it seems a logical extension to allow online access to poems, either as part of the package the customer buys alongside a publication, or as a separate service. The reader is, after all, buying access to the content (as the format is their choice). Online access (via subscription, perhaps) also allows Electio to include more content (that wouldn’t be able to be added to some, or all, of the publication formats), & suggests that perhaps subscription might be a better way of payment for the whole model.

c. Audio

One of the biggest opportunities presented to poetry publishers by ebooks is the capacity to incorporate audio within publications. I’ve written quite a bit on this, as it’s something I’m quite sure about. This functionality, as part of the Electio model, would complicate the system (in a technical sense), but could quite easily work in the current model.

d. Crowd-sourced metadata

With online access, it could be possible to allow users, separately, to ‘tag’ the poems. The wisdom of the crowds could at the least suggest useful metadata to be added to Electio’s database.

e. Book-grouping poems

It might seem like a complication & a concession back towards book-bound publishing, but it would make sense to be able to group poems by a single poet (as a collection), as a way of putting something like publisher-query publications into the system before the production phase.

f. Collaborative authorship/editing

Drafting does not take place outside of the system, as content within the database does not need to be static. Poems could be collaboratively authored & edited within the system, between the poet & editorial staff, so as to reduce drafting conflicts. The system would only need to know when a poem has been ‘published’ (i.e., determined to be finished), & even the idea of a finished poem in an all-digital workflow seems anachronistic.

g. Cloud-based content

It is possible that the system should be jealous of its content, & remain on the web (to keep publications viewed by browsers) wherever possible. As long as publications (in this web-only form, so in HTML5/CSS3) were aware of the device which was viewing them, it would transfer work to web browsers (which most mobile devices have). This would also give all the advantages of the cloud.

h. ‘Social reading’

This system should be leaning towards using digital marginalia as a space for interaction with other readers & with the poet.

3. Conclusions

It is interesting to think about how Electio could work, & whether or not it is better (whatever that may mean) that a traditional model poetry publisher. Even if it is not, it is no bad thing for traditional publishers to need to justify their practice in the face of the new thinking that all-digital workflows promote.

One of the advantages of having the book as the discrete unit is that it is easier for the reader to know what they are getting. A book is promoted as a book, can be sampled online, & can even read in its entirety in a library or a bookshop. The smaller units of the poems are given away as independent advertisements for the pamphlet/collection from which they come. It is harder, in a model where the poem is the discrete unit, to justify giving poems away. It is also important to point out again that publisher-query books in the Electio model need not be any different in result from traditional model books.

~~~~

I hope this is interesting. I would work on a prototype system with public domain poems, but the time commitment is a bit beyond me. I do hope that no one steals it. Please email me if you have any suggestions or thoughts, using this form or at my first name @charleswhalley.co.uk. Would you buy books from Electio? Would you want to publish your poems with Electio? Have I missed any obvious implications/drawbacks with this model? I don’t have comments on, but I would very much like to add interesting responses to this post.