Partners in science: OJS, a collaborative researchers' workbench and an open repository
First Monday

Partners in science: OJS, a collaborative researchers' workbench and an open repository by Astrid van Wesenbeeck and Martin van Luijt



Contents

Time for a change
Partner in Science at Utrecht University
Web services
Scenarios of integration
Conclusion

 


 

Time for a change

After more than seven years of experience in electronic publishing and hosting and managing the University’s digital repository, the Utrecht University Library recently shifted its focus strongly to the development of Virtual Knowledge Centers for her scientific field; virtual workbenches where different facets of the research process find a solid digital environment.

A Virtual Knowledge Center (VKC) can be defined as a digital office where group activities and personal activities can take place and will be hosted. The centers will be used as academic work benches where members can save and share information online, communicate with each other, work in one document at the same time, build wikis, make use of Web logs, discussion forums, create document libraries, project libraries, virtual project areas and so on. Certain work spaces can be given a public status and others may only be entered after invitation or by membership.

Supporting and hosting these virtual environments imply that the library has to move out of its classical field once again. Earlier we did it by starting to publish easily accessible electronic journals, now we realize that just to act as an open access publisher isn’t enough. The academic field is asking for a more encompassing support from the library and the publication phase covers just a small part of its whole workflow.

A publishing protocol will have to be part of the VKCs, though. The tailor–made VKCs will support research projects from the very beginning (for example an idea bounced around among some colleagues) to the very end. The final result of a research project can be a research paper ready to be archived, or even better, a formal reviewed publication. This implies that the final publishing phase definitely deserves a place in the VKC. So, OJS needs to be integrated in the VKCs.

 

++++++++++

Partner in Science at Utrecht University

The development of VKCs at the Utrecht University Library started in a program that aims to develop next–generation collaboration services for scientists. In this program, started in 2006 and aptly named Partners in Science the university library and research groups will create the so–called VKCs. The research groups of the University are the target audience for these VKCs. Scientists, alumni and researchers in the field (e.g. pharmacists, veterinarians) can become VKC members to collaborate in research projects that are being carried out by one of the University’s research groups. Over time, the University Library expects to build up to 100 VKCs.

The basic principles concern all possible VKCs for the whole University so there will be overlap in functionality, but the real benefit will come from tying in the specific systems and procedures that scientists use in their research.

Overlap will be found in general Library programs that facilitate the research process and that facilitate the work environment. The Library catalogue ALEPH and the Library’s full–text search engine Omega are examples of programs that will be of use for any user. Besides these aspects a lot of similarity will of course be found in the main structure and architecture of the centers; every VKC contains wikis, document libraries, discussion, etc.

The specific needs became clear when The Partner Project started in September 2006 with the cooperation, input and support of three research groups from the Pharmacy, Medicine and Veterinary Medicine faculties. Each group has different needs and different aims regarding the architecture, structure and organization of the VKC. Pharmacy for example wishes to organize their internships in the VKC and Medicine and Veterinary medicine want support for following the Evidence Based Medicine Practices protocols in their research projects.

As mentioned before, the final result of science is very often a publication. To use the publishing software in a VKC properly, we are talking about real integration of different systems. Independent from the publishing software that is actually being used, the software has to be integrated so the researcher does not have to leave his environment, the VKC, when for example submitting his article to the publishing tool.

In other words, VKCs require an invisible integration with other software programs. This can be done with open standards. In the next section we will elaborate on how we see this.

 

++++++++++

Web services

In the Utrecht institutional academic landscape we deal with a number of software programs (hosted all over the University) from whose functionality we want to use small pieces in our VKCs. The basic premise for success will be to accept and embrace the existence of these separate software programs and to find a way to integrate a few relevant pieces of their functionality into the VKC.

Completely rebuilding existing software to make it operate within a VKC is not an option. The cost of writing new software would be enormous, not to mention the cost of write–offs of perfectly good systems. Secondly, the systems we want to integrate in the VKC do most of their work outside of the VKC. We don’t want to touch those work processes. And third, collaboration and integration should never lead to loss of freedom in selecting the best software for the job. No lock–ins!

Today integration is usually done with APIs (API = Application Programming Interface) or plug–ins. When using APIs or plug–ins to integrate two software programs, we create strong ties between the programs, one program directly addresses the other program. This type of integration tends to become very hard as soon as both systems use a different programming language, run on different operating systems or are situated in physically different locations. So, APIs and plug–ins are fine for a limited number of integrations for one organization, but do not scale to a large number of integrations between systems of different faculties. Another common issue is identity management. Users often have different account names in different systems, something that has to be dealt with when integrating systems. This is best done at the level of the organization, for reasons of security and reasons of scalability.

To realize an integration independent from specific systems we have to focus on Web services. Web services are designed to run over the Internet. Systems communicate via (XML–)messages that travel from one machine to the other. The mechanism of Web services includes facilities for describing a service (this is what I offer/this is what I want), discovery of service providers (who can do this for me?) and it also handles identity management (who am I?). And most importantly, it is a world standard that is rapidly gaining traction amongst users and software providers. The Web services standard, or more precisely, the suite of Web services standards is governed by the OASIS organization [1].

Just like many institutions the University of Utrecht is currently developing a Services Oriented Architecture, using the OASIS reference model for Service Oriented Architectures.

In the now emerging service–oriented world, software systems offer relevant parts of their functionality for use in other systems. A simple example of such functionality would be the ability to see my e–mail inbox in my virtual workbench, irrespective of the actual e–mail system and the software used for the workbench.

The Service Oriented Architecture will allow systems to use each other’s functionality securely, across system boundaries and across platform boundaries. Service providers and users are not directly connected and therefore not dependent on each other which brings us freedom of choice. This model respects the existence of vertical software solutions that support a specific user groups (OJS is an example of such a system) and at the same time supports the trend that for more and more people parts of these systems need to be integrated in workflow–oriented workbenches like our VKCs [2].

The availability of standards is not enough, unfortunately. Two issues remain.

The first one addresses definitions of services which need to be standardized yet. We want services to give us freedom of choice and if — for example — every e–mail program uses a different service definition for accessing its in–box, we will not get plug and play compatibility in services. Luckily, vendors do understand this and cooperate more and more to define truly globally standardized services.

Secondly, software manufacturers need to add these services to their products. Both of these will take time, but we believe this is de direction the world is moving. And we are not alone.

Is the above just theory? No. We are already building and using these concepts. So far we have built a prototype that we use to discuss our ideas with three research groups (one in pharmacy, one in medicine and one in veterinary science), to help them formulate their needs. Our approach seems to be spot–on, the feedback we get is encouraging and constructive. By the end of 2007 we expect the first VKCs to be up and running.

In our VKCs we want to use Web sevices to integrate tools like OJS. Unfortunately, right now OJS does not expose Web services. To help out with deciding what services should be offered by OJS we will now offer a few scenarios to illustrate the role of a publishing tool such as OJS in our VKC.

 

++++++++++

Scenarios of integration

To visualize the integration of different programs with VKCs we will give three different scenarios of the desired situation. Three programs/environments play the lead role: The VKC, the publishing tool and the Digital Repository. The tools our University has chosen are Microsoft Sharepoint for the VKC, OJS for publishing and DSpace as our digital repository.

In the current situation without integration the user switches between different systems, he has to log on again and again, and he has to get used to work with different commands, different interfaces, all for completing one task concerning his research.

End of project, research paper
Once a project has ended one of the results can be a research paper or a report. At the University of Utrecht many research papers and reports are published in series that have small or no distribution. We call this non–reviewed academic output, known as grey literature [3]. Ever since the uptake of the digital repository the Library receives an increasing demand for depositing these papers and making them available via its institutional repository [4].

When final, the paper can be stored in the repository by using a submit button available in the VKC. Metadata belonging to the paper, such as title, authors, affiliation authors, abstract, keywords, are sent to the repository immediately and the submitter receives a Web form in the VKC which can be filled out right away for possible lacking data.

Currently the researcher has to logon to the repository, enter all of the metadata by hand and upload his document. Since the researcher usually lacks experience in doing this (research projects take a lot of time and that’s why the user experience will stay low), it is often quite a hassle coming up with the correct metadata, both in quality and in quantity. The context and (meta)data contained in the VKC will greatly reduce the complexity of the described self–archiving tasks so users can complete this task without the urge of throwing their computers out of the window.

Overlay journal
Although the visibility of items in a digital repository on the Internet has been taken care of pretty well, mainly because of the OAI principle, items in one collection can get more attention by being published in an overlay journal created by OJS. The overlay journal offers more than the series page in the repository as it has been enhanced with reading tools, more formats and other services. Once a new paper has been stored in the research group collection in the archive, the metadata will be retrieved by OJS and the index page of the journal will be updated automatically. OJS also retrieves the text, creates the desired output formats (PDF, HTML and in the future XML). As soon as the issue is updated all registered users receive a notification. In this scenario no human hands have to click on any button at all.

In the current situation someone has to create the several issues and manage the publication process.

Submit to journal
If we stick with the story we have created so far, the author(s) might wish to submit the archived submission to an independent peer–reviewed journal. For this we will integrate a publication tool in the VKC. Similar to the earlier deposit situation now the author can click on a “submit” button and the metadata and the file of the paper will be sent to (in our case) OJS. Again, if necessary, a Web form will be loaded for data not available in the VKC. The author does not have to log on to OJS nor will he be lead to another environment. Of course he will be able to view the data of his author’s page in his VKC by retrieving it, so the status of his submission can be viewed at any time. (And an RSS feed on this page would be heaven!)

The current situation versus this scenario will be familiar for most readers who work with OJS. As an author you will have to register for the appropriate journal, you will have to fill out requested data fields and follow the ‘five steps’.

All described actions in our scenarios will take place within the virtual environment and for the author, the user, different systems with different lay outs and different user interfaces will be of no more interest (and bother). Logging on takes place only once. As a cruel compliment towards software developers: your system will be made invisible and can be replaced easily by another system. The user will take no direct notice of your work; he will use it without getting to know it.

 

++++++++++

Conclusion

In this paper we have aimed to illustrate the future work environments for scholars. The University of Utrecht Library is facilitating and supporting the development of virtual workbenches and we hope the upcoming months and the year of 2008 will give us more practical experiences to share.

A program such as OJS is very much needed to support the research process from the beginning until the very end. Currently, OJS and the rest of the PKP software suite offer plug–ins as a means for both integration and extensibility. We would like to encourage the PKP team to consider what parts of the functionality of their systems lend themselves for integration by means of Web services. We expect that over the next three to five years many organizations will start to implement the services oriented architecture they are now designing and experimenting with. End of article

 

About the authors

Astrid van Wesenbeeck is Publishing Advisor for Igitur (http://www.igitur.nl), Utrecht Publishing & Archiving Services, University of Utrecht Library.
E–mail: A [dot] vanwesenbeeck [at] uu [dot] nl

Martin van Luijt is Head of Innovation and Development, University of Utrecht Library.

 

Notes

1. See http://www.oasis-open.org/home/index.php.

2. For more information on the OASIS standards see http://www.oasis-open.org/specs/index.php.

3. For information on grey literature see http://library.brooklyn.cuny.edu/access/greyliter.htm.

4. The University’s Board of Directors has even made depositing in the digital archive mandatory.

 


 

Contents Index

Copyright ©2007, First Monday.

Copyright ©2007, Astrid van Wesenbeeck and Martin van Luijt.

Partners in science: OJS, a collaborative researchers’ workbench and an open repository by Astrid van Wesenbeeck and Martin van Luijt
First Monday, Volume 12 Number 10 - 1 October 2007
http://firstmonday.org/ojs/index.php/fm/article/view/2001/1876





A Great Cities Initiative of the University of Illinois at Chicago University Library.

© First Monday, 1995-2017. ISSN 1396-0466.