Moving the presented papers to OJS

[jamief]

I asked about this in the OJS, didn't get a bite, so I'll ask it again, in a different way.

If I have a conference that has say 100 papers presented, and I have decided to use OJS to make these available in published form, as I believe is one of the ideas behind the notion of integration, How do I go about doing that without duplicating the entire process of selection again?

Seems to me if the paper was reviewed and accepted for presentation in a conference, and now I the conference is over and I want to publish the Conference online, there must/should be a way to move them all into OJS where they can be manipulated according to types or their tracks or something. So I want to bypass the entire selection and approval process because they have already been approved onceand move 100 papers into OJS as approved papers.

Is there a quick way to do that?

P.S. In my case I already have dual login and account synchronization. Every new user account in OCS creates the same for OJS. Should I be looking at a mysql SQL insert script as the way? Can I do a mySQL dump of some tables and import them into OJS?

These are my musing about a quick move of data from one platform to another.

[mcrider]

Hi jamief,

No need to post twice; we read all the posts that come in, so just amend your first one. Though this post is clearer

I think this is a little too complicated to do any sort of DB dump transferal (not to mention that you risk data collisions). You'll probably want to look at the native import/export plugins. You can either export from OCS, clean up the XML so it conforms to the OJS native dtd, then import that into OJS. Or, to shorten the workload in the future, create an export plugin for OCS that exports the papers in a format that OJS can import right away. Using the XML import/export infrastructure is likely to be easier than wrangling the code to directly insert articles into OJS.

Cheers,
Matt

[jamief]

Okay, thanks for the reply.

So what I understand is the two platforms are not really "meant" for each other, they are two distinct instances of ways of dealing with "Knowledge" and it was not anticipated moving from conference to journal.

Ill look at the plugin concept. Especially since my users have accounts in both systems, the only thing would be to try to map conference tracks onto the OJS as Journal Sections, which, even if further along the editors choose not to use, would be a way of organising a massive import.

Alright. Ill investigate the costs of creating such a plugin.

Best regards

[jmacgreg]

Hi Jamie,

I'll weigh in on this too. I think our original usage scenario with OCS was that people would use *it* to publish all conference-related content (which it can obviously do), but over the past while I've seen a number of organizations want to do the same as what you're describing: publish conference proceedings, but in journal format. (Actually, we're more or less doing this ourselves, although it's not necessarily automatic: presentations from the PKP Scholarly Publishing Conferences are solicited for publication in the Journal of Scholarly Research and Publication, although in both cases they go through peer review.)

I think the best way to go about doing this in the short-term is to use the article/paper import/export plugins, as Matt describes: export the conference proceedings into OCS-compliant XML; munge the XML so that it is OJS-compliant; import into OJS. It's that middle step that's tricky, and I'm not entirely sure off the top of my head exactly how tricky. I'll try and give it a couple of test runs myself though, and let you know what I learn.

Long term: I think the plugins should have an interoperability function built in. I'm not sure of the best way to do so, since the underlying publishing structure *is* so different (eg. OCS doesn't really do much with vol/issue/year demarcations). Given that the most typical scenario is OCS->OJSj rather than OJS->OCS, maybe it would suit to extend the OCS export plugin to export to OJS-compliant XML? This would still require some user interaction to define vol/issue/number etc. information, but that could happen either at the plugin level by request, or at the hand-editing XML level (with the plugin providing helpful blank elements to fill out or something).

Any thoughts on this possible solution? Super-long-term, of course, we'd like for one "PKP system" to be able to handle both types of publication content (which is a goal of our ongoing modularization effort); but we're not to close to that yet. If the above solution looks workable, I can submit a bug report; and if you have any time or ability to work on the problem of course, we'd be happy to help any way we can.

Cheers,
James