Making a Home for a Family of Online Journals

The Living Reviews Publishing Platform

Robert Forkel

Heinz Nixdorf Center for Information Management
in the Max Planck Society

Overview

The Living Reviews Publishing Platform consists of

  • the Living Reviews concept - in particular the type of publication, i.e. solicited, peer refereed review articles (see http://www.livingreviews.org/faq.html)
  • the common technical infrastructure (production server, test server and journal hosting environment) and
  • the ePublishing Toolkit, a software package providing tools to help in publishing scientific content on the web. (see https://dev.livingreviews.org/projects/epubtk)

The full platform is offered to journals which are members of the Living Reviews consortium. But all parts except for the infrastructure and the brand can be used independently for free.

See also The Living Reviews Publishing Platform.

The Living Reviews Family

What do we publish?

Solicited, peer-refereed review articles.

A new journal startup needs approval by consortium of existing ones.

For the concept of a particular journal see the LRR concept.

How do we publish?

Take advantage of the web:

While we publish "online only", a printable high-quality PDF version of our publications is still deemed indispensable. The online HTML versions are considered the authoritative versions, though, since they reflect updates immediately.

Taking full advantage of the medium does also mean that publications can be updated and the changes being visible to all online readers immediately.

To make discovery of our content easy, we disseminate our metadata via

  • an OAI static repository gateway,
  • ADS,
  • RSS (i.e. make it available to feed crawlers),
  • RDF (i.e. make it available to semantic web applications).

For an example of how well Google works as disseminator, see the "Referring Site Report" and the "Search Query Report" in our web log analysis.

Infrastructure

The production and the development server are hosted at the RZG in Garching, the test server at the AEI.

More information about the technical infrastructure:

Using the Infrastructure

Again, more information is provided here.

The ePublishing Toolkit

Find more information on the ePubTk homepage. In particular, details about the components can be found here:

Publication Builder

HTML Output

Screenshot of a browser window displaying an article

Screenshot of a browser window displaying an article from Living Reviews in Relativity.

PDF Output

Screenshot of the PDF version of the same article snippet

Screenshot of the PDF version of the same article snippet displayed in Acrobat Reader.

Reference Database

Reference Database Import

Screenshot of import screen of the reference database management GUI

Screenshot of import screen of the reference database management GUI. Potential duplicates from a new set of references can be inspected and either be merged with existing records in the database or be marked as different.

BibTeX Import Filter

Screenshot of the BibTeX filter application for the reference database

Screenshot of the BibTeX filter application for the reference database. This application allows to

  • trigger various checks on a BibTeX database containing references of a publication,
  • edit the fields of records in the BibTeX database,
  • create an XML file from the BibTeX database which is valid for importing into the reference database.

Search Interface

Screenshot of the web-based search interface for the reference database

Screenshot of the web-based search interface for the reference database of Living Reviews in Relativity. Note the context dependent suggestions for the author input field.

Register

Register Management GUI

Screenshot of the management GUI for a journal's register data

Screenshot of the management GUI for a journal's register data.

Journal Builder

EIMS

Due to the special kind of publications, our workflow is special, too. Find the details here.

If interest is voiced, a test instance of EIMS to try out may be installed.

Task List

Screenshot of the Tasks screen of EIMS

Screenshot of the "Tasks" screen of EIMS.

Report List

Screenshot of a list of available reports in EIMS

Screenshot of a list of available reports in EIMS.

Detailed Report

Screenshot of the Report screen for a workflow item in EIMS

Screenshot of the "Report" screen for a workflow item (in this case a publication) in EIMS.

Future

Lessons Learnt

  1. Keep the tool zoo small.
    The central tools we use at Living Reviews are subversion, trac and ePubTk. While none of these three (except maybe trac) is particularly easy to use, the fact that each of them is used for multiple tasks helps getting up the learning curve. In particular the fact that different user groups use the same tools helps building up a common knowledge base. The prime example for this is subversion. Managing editors use it to maintain the web content, technical editors use it to handle the manuscripts, developpers use it for version control of the software.
  2. Don't reinvent the wheel unless ...
    While we try to make use of existing tools (possibly using them in a novel way), a big part of our toolset is the ePublishingToolkit, which does reinvent some wheels to make sure they fit.
  3. Embrace diversity.
    Very diverse people need to collaborate in our project: linux, mac and windows people; scientists and non-scientists; non-collocated people; developpers and users. While this demands a lot of attention, it also makes for good experiences: windows people attacking command lines, linux people looking for /etc/hosts on windows machines in general, tackling steep learning curves with a team. You better like communicating (digitally).
  4. Open Source
    simply is the way to go! It makes experimenting easy since you don't have to buy licenses first; it's fun and possible - to get involved; you can learn by examples and actually use what you learned. The prime example here is trac. We liked the user interface. So we just plucked it and put it on our EIMS thus keeping user experience uniform across applications.
  5. Technical staff is necessary...
    ... because software is never really finished, automation is always wanted, maintenance just has to be done (server updates, migration of legacy data). On the other hand, we found that people who want to start a journal and people who can support the technical infrastructure for an online journal are rarely the same. So to keep the barrier for new journals low, we provide a hosted solution.
  6. Plan for change.
    Migration issues have been a constant companion in our project: We migrated several GB of web content (where tidy proved very helpful, but xhtml or clean html4 from the outset would have been better). We are just in the middle of migrating the old editorial information database (and it turns out, that an API for the DB would be way better than dumping CSV files). The easiest migration task so far has been migrating the register. Since the data was already in XML it took only one XSL transform. Hence: put emphasis on portability/migratability of data, avoid any dead-end formats, put apis on applications or even better, store in format which is easy to export right away. Again, change would be a lot easier, if standards existed.
  7. Find a niche.
    For our journals so far, the niche created by our special form of content proved helpful. In particular, the advantage of online publishing with a mechanism to update publications seems more clear cut in the case of review articles, which follow the developments of a research field.

Summing Up

Well, we did what everybody seems to do:

What makes a wheel a wheel?

Towards interoperable epublishing components:

Interoperable Components

Find more information in the wiki pages.

Where next?

https://dev.livingreviews.org/projects/workshop2006/

Thank you for your attention!

Questions?

http://dev.livingreviews.org/presentations/elpub2006.html