OJS et al's being decentralized is an obvious asset -- users have complete control over individual installations and there is no need for a difficult-to-maintain cloud infrastructure for hosting any of several thousand PKP suite instantiations. Despite this, there are innumerable opportunities for taking advantage of having a common platform which is so well-dispersed. Some of these are discussed in greater detail below.
Currently, PKP journals are only connected to one another by "traditional" bibliometrics (i.e. reference lists which may or may not contain doi links), and may or may not be indexed, at most, in DOAJ. Much has been made of open-access journals' greater research impact in terms of citation counts (Antelman 2004, JCRL; Hajjem et al. 2005, arxiv). Beyond this, however, there have been no real bibliometric innovations which are new and unique to open-access literature.
- Theoretically universal availability of HTML full text means that exact citation contexts could be fetched automatically when highlighted in an article. Cited articles could be hyperlinked to the point of reference via a single-click, and a snippet could be displayed in the current window (as marginalia, or using a "speech bubble" interface as in the FastestFox/FastestChrome browser plugin, which fetches dictionary definitions of highlighted words, with the option to use them as Google search criteria without needing to copy/paste).
Sharing research data is gaining popularity at the forefront of the open access movement (Piwowar, 2007), but is still relatively unpopular, owing to the reluctance of scholars to format and provide reusable data alongside research submissions.
- OJS provides a means for authors to attach raw data (not displayed in the text itself) to article submissions: authors are able to upload multiple supplementary files during the submission process (and enter keywords for them). Journal Managers decide whether these supplementary files should be made publicly available with the submission, through the Reading Tools, at a general level (ie. not on a per-submission basis).
- These materials could then be automatically ingested into searchable data repositories such as http://datadryad.org via plugin support, potentially removing the greatest obstacle to data sharing.
- There have also been ongoing discussions with The Dataverse Network developers on how their software could be supported within OJS: whether deposit into a DVN would happen during submission, or only on acceptance/publication, and how/whether the DVN display options would be integrated into the Reading Tools.
- treeBASE/GenBank probably less relevant as specialized repositories for OJS journal data?
Enabling annotation and sharing of marginalia in HTML open-access journals has been well-implemented into PLoS ONE, and the potential for integration into OJS has been well-researched (Kopak & Chiang, 2007).
- Although it makes sense to implement mechanism for the clustering and relevance-weighting of public annotations, and this has been relatively well-studied (see Han & Yan, 2009, JIS, for an excellent review and a novel algorithm), a manual "flag and approve" system has proven the most effective for PLoS.
- PLoS does not have a system for privately-viewable annotations; would be relatively easy to implement this.
- If we assume that PKP journals are used by a smaller, more intimate community, it may make sense to treat them as workspaces where all users' annotations would be visible -- but this could reconceptualize what is intended by a "journal." Could obviously have different user classes and privilege the visibility of some users' annotations over others. For example, easy to imagine an instructor providing a link to an OJS journal article with the directions for and space to complete an assignment included within the page, no external CMS required.
- Many OJS users still work exclusively with PDF, where HTML annotation breaks down (see a parallel example of this in Zotero). Advising users on best practices for Adobe Reader annotation is unideal -- features are poorly-documented and not well-used (try searching "adobe reader annotation" on Google), and can not be shared independently of the entire document. Foxit and PDF-XChange are no better until you get to the paid versions. Even if we provide the ability to re-upload commented PDFs and link versioned documents (as in Nature Precedings pre-print archive), this loses a lot of the convenience from annotation.
Scientists don't seem to be using social networks for research purposes (see http://scholarlykitchen.sspnet.org/2009/10/19/scientists-still-not-joining-social-networks/), and the market for such tools remains flooded.
- In the interest of not taking on an additional hosting burden for PKP (is a common theme emerging yet?) and not providing even more competing alternatives to what already exists, I'd advocate for looking into the available Zotero/Mendeley API for automatic ingestion of research networks data. Might be worth establishing a working relationship with Zotero development (afaik, PKP has support for COinS, but that's all), although worth noting that I strongly prefer working with Mendeley (not open-source) for the interface alone.
Paradigmatic case: on the freely-hosted WordPress.org network, users have a consistent username, profile, and avatar which loosely unifies activity across blog comments. Individual WordPress installations do not have this advantage, but perhaps benefit from the consistent interface of the former.
- Why was this judged not worth the trouble to harvest and maintain from a platform which is, like PKP, decentralized but relatively universal? Certainly less authority implicit in a blog versus an academic journal, although WP install is (barely) nontrivial enough that anybody going to the trouble must have some vested interest in its use. Is every WP commenter of value to the system? Every PKP author certainly would be.
- My instinct is that this would be (perhaps alone) doable in terms of a centralized repository -- it's unclear whether there is an effective method in place for crawling all public instantiations of OJS (there should be), but scraping this data would be relatively non-intensive.
- Strict opt-in privacy controls needed (probably wouldn't want to share e.g. author accept/reject information).
- Not clear whether tools for direct collaboration are necessary or valuable here (what can PKP offer beyond Google Docs?) -- however, potentially invaluable in terms of data mining and usage statistics. Looking at whether researchers want their reading behavior tracked is worth a study in its own right, but comes back to the original issue: they usually can't be bothered.