New projects: Discovery and LiquidPub

The first of the new projects is the Discovery Project. It is a cooperation between six partners with different competencies, among which the French ITEM, Italian ILIESI and the Wittgenstein Archives in Bergen, and it is funded by the EU (2006-2009). It is headed towards classical academic research and intends to make philosophical source-texts available, and to provide a publishing framework for philosophical writings. It is based on Semantic Web technologies and consists of two parts. The first part is Philosource, which is is a webplatform whose instances form a network of repositories, each of which stores documents (identified with unique, stable names, so called URIs, referable also when working offline) and is interoperable with databases (via so called SQL queries). Each node is intended to aggregate the community of scholars on a single topic or philosopher. Texts can be original writings with different editions. They are organized by means of several domain ontologies (one per node), which organize knowledge inside the node, and by an upper ontology which eases the search for relationships among documents.

Philospace is the second part of the Discovery project. It is a desktop application that allows users to browse Philosource nodes, to annotate documents with personal notes, and to work offline. Later versions of Philospace will also allow direct submissions to Philosource, and the creation of channels to share comments and opinions on philosophical work. On Philospace and its channels, the reliability of sources and other circulating material are delegated to each user, who can decide what to use or filter out. Contrary, each Philosource node has an editorial board, consisting of invited experts nominated by Discovery's content partners, who have to assess the quality of all texts. Works submitted to a node are published only after positive review. Recently the first Philosource node (on Nietzsche) has gone on-line, providing valuable expert-annotated source-texts. But so far there is no trace of inter-activity. Also with their use of traditional editorial boards, they do not seem to be using web-technology to its fullest extent, as in ratings-based peer-review. It thus remains to be seen how successful and lasting the project will be.

Then there is LiquidPub, which is being developed by the University of Trente, and Springer Verlag, among others. It has a (computer-)science audience in mind, but it also wants to be useful for academic philosophers. First of all it leaves the limiting nature of static texts behind by allowing publications to be composed of parts of other publications, and for them to be continuously updated. They also want to separate publication from review, and diversify the review-process. Parts of papers can be reviewed separately, and review can be done both by traditional peer-review, and/or by communities. They can even be based on implicit behaviour, such as to which authors many people subscribed (e.g. telling: give me anything new written by author $X$). More generally they want to turn journals into dynamic filters - make them liquid as they call it - so they can either be composed in the classical way, or be filled based on a set of filtering-rules (for example: rated above $Y$, and not excluded by a reviewer). In addition they can be continuous, monitoring papers as they are finished and improved, or optionally still be static issues that are released at (fixed) time-intervals.

While LiquidPub has great potential, its architecture is quite complex. Not only does it consist of 3 separate tiers, but it also is intended to deal with many media types, and to handle liquid articles, liquid journals, prestige metrics/indices, and conference review processes too. Both Discovery and LiquidPub have complexity in common. They are by large consortia of partners and funded with one or more formal grants. This probably required them to to boast comprehensiveness, and to include everyone's pet-features. First of all comprehensiveness, and trying to surpass the functionality of existing systems/sites is increasingly difficult, and will in addition bring a project on a collision course with more existing practices and/or software than might be necessary. Secondly the result is always a complex system. And until projects begin to be implemented it is often missed that complexity grows more or less exponentially in large software systems, leading to delays upon delays. And even where the complexity turns out to be manageable by the designers/programmers, a multitude of features leads to poor usability, which then kills the project off in terms of the user-base it can gather anyway.