OJS as a repository

[kosson]

I wonder if OJS is not waking the road of becoming a full blown repository in its own right?! It has all it needs even now but focus is on journal management. But, looking from the point of view of on who seeks a light repository solution; ignoring the wording of the application OJS looks just right. It has all it needs but for the workflow needs to be changed a bit?! Media support improved and there would emerge a powerful proven repo. Journal may become domain, journal sections may be sub-domain, issue may well become set and so on.
Are there any steps taken in this directions?

[ramon]

Hello Kosson,

I trust the PKP team will provide a more thorough point of view on this matter.
From my experience working with PKP, and the evolution proposed for the project, I believe that OJS will continue to be used specifically for journals, although creativity is your limit as to what OxS can do for you. I see a myriad of possibilities, for example, using it to manage projects, but there are always shortcomings due to the need to customize the translation and the process being very specific to blind peer-review.
This being said, since the coming of the PKP Web Application Library, where I trust the idea is to modularize all the functionalities, eventually anyone could develop an application using functionalities from OCS, OJS, OMP, OHS, for example, a custom Timeline for harvesting a collection of documents from similar institutions, creating a mashup and providing a full-text search on the documents, for use by Financial Agencies, for example.
In my opinion, there are a few of issues to discuss here:

1. How distant are these "creative" applications from the purpose and objectives of PKP? Hard to tell.
2. How much can PKP do without help from the community? Also very difficult to tell. However, we are discussing a stronger development and technology/knowledge transfer policy between PKP and IBICT, to be able to assist PKP in many fronts. Hopefully, more institutions will view this as an option when adopting PKP software.
3. How many people would be interested in how many new apps or functionalities? Without specific research on user and community needs, it's hard to decide on what road to take.
4. Regarding you specific list of features, these seem to fit more with Open Harvester Systems - OHS, although all of PKP Suite software is basically a repository.

[jmacgreg]

Hi Kosson,

Ramón has hit the nail on the head, so I won't repeat what he's said except to explain what we've already considered. We have in the past discussed creating a lightweight repository system, probably extended from the Harvester/PKP Library base, but a) we don't know what the demand for this is; b) existing repositories tend to be heavy-weight for a reason, and our/my suspicion is that a lightweight effort would lean towards complexity eventually; and c) (possibly the biggest reason right now) we just don't have the developer resources to add another project and maintain our commitments to existing projects at the moment. Of course, we do hope that our developing partnerships with Ramón's team, and others, will help us extend our efforts.

If you personally have any development expertise, and are interested in helping with the project or extending a current system (as Ramón suggests, the Harvester being the best bet) into a repository, please let us know. Any and all comments from you and others are most welcome in this regard. I personally think there's room for a comprehensive (not necessarily light-weight!) IR built as a simpler MySQL/PHP foundation, but again, we have only so many developer hours.

Cheers,
James