OJS OCS OMP OHS

You are viewing the PKP Support Forum | PKP Home Wiki



Extensions for derived galleys in OJS

Are you an Editor, Author, or Journal Manager in need of help? Want to talk to us about workflow issues? This is your forum.

Moderators: jmacgreg, michael, vgabler, John

Forum rules
This forum is meant for general questions about the usability of OJS from an everyday user's perspective: journal managers, authors, and editors are welcome to post questions here, as are librarians and other support staff. We welcome general questions about the role of OJS and how the workflow works, as well as specific function- or user-related questions.

What to do if you have general, workflow or usability questions about OJS:

1. Read the documentation. We've written documentation to cover from OJS basics to system administration and code development, and we encourage you to read it.

2. take a look at the tutorials. We will continue to add tutorials covering OJS basics as time goes on.

3. Post a question. Questions are always welcome here, but if it's a technical question you should probably post to the OJS Technical Support subforum; if you have a development question, try the OJS Development subforum.

Extensions for derived galleys in OJS

Postby mtrudel » Thu Aug 25, 2005 7:48 am

Hi all,

I'm working on re-implementing our existing journal on OJS 2 (we currently use OJS 1.x with a mishmash of mixins, and we wish to redo things cleanly the second time around), and I've come across something that I've think I/we can do better (and of course contribute back to the OJS community). Basically, it involves a way to dynamically generate viewable content from a source file, while still retaining the flexibility of galleys. Briefly:

Our Current Workflow:

- Documents are submitted to the journal in a variety of formats (typically Word). We convert them (mostly automatically) during the layout phase into NLM Journal Publishing DTD conforming XML. From this XML, we dynamically generate (via a custom XSL) an XHTML version of the paper, and also a PDF version (via XSL:FO and xep). We also submit metadata to several repositories (CrossRef, Medline, etc) based on XSL transforms.

It would seem that this approach is a common one (in spirit, at least), and I'm surprised OJS doesn't have better support for it.

My proposal:

- Currently, galleys represent an explicitly uploaded file. I propose to add another galley type which I'm calling a 'derived galley'. Derived galley types would be defined journal wide by the journal manager, and would describe a method (and associated XSL, or command pipes) of transforming an explicitly submitted source galley to a derived one.

- As part of the galley upload process, you would be able to define one or more derived galley types which would use the file you're uploading as a source. After upload, the derived galleys would go to work, generating their content based on what you just uploaded, and saving it back the same as galleys currently do.

- These derived galleys are 'read-only' (ie: you can see the derived document, but you cannot change / overwrite it without changing its source document). This ensures that there is only ever a single authoritative document for each article.

- Hooks would be in place so that, whenever the source doc changes, the derived galleys update automatically. Changing a derived galley's transformation method (by, for example associating a new XSL with the transform) would trigger a re-build of all derived galleys of that type (so the XSL change would be filtered through to all documents which use it).

- Galleys of all types (existing and derived) could be 'hidden', so that they show up in the journal staff's list of galleys, but do not appear to readers. This allows for two cool things:
- If desired, your source documents can stay private
- You can define 'galley types' which run scripts to publish metadata to various repositories. They are automatically updated when the source document is, but don't appear to users.

What are people's thoughts? Is there a better way to do this? Would the OJS team accept such a patch into their codebase?
mtrudel
 

Derived galleys

Postby mj » Fri Sep 09, 2005 1:38 pm

Hey Mat,

I'm posting here since it's probably beneficial for others to read/participate in our discussions (Kevin: would this be more appropriate for the developers' forum?).

I think your implementation of derived galleys is a great idea, especially the "hidden galleys" concept for syndicating content to various metadata repositories. While non-medical journals can't use Medline, and CrossRef requires membership, "open" repositories like DSpace-based archives (eg. TSpace, https://tspace.library.utoronto.ca/) or any other LOCKSS targets (even just a backup FTP server) could easily be added.

The biggest challenge I see is incorporating the data pipes as easily as possible; for example, with XSL, it reqiures a working XSL engine installation (eg. sablotron) and knowledge of configuration. PHP4 offers an extension for XSL, and PHP5 includes it natively, but these would increase the OJS2 requirements accordingly. I wonder what others think about this?

Perhaps a user-friendly way to do this would be to probe which PHP functions are available (ie. FTP commands, XSL commands), and then provide parameter-based dropdowns for the "kind" of derived galley to use when defining one, with a default "executable command" always available. More work, but it cleanly enumerates the options available on any given OJS2 install based on the PHP version, etc.

Something else I've been thinking about for a while is the ability to edit derived galley components (ie. the XSL stylesheet, or the XML source) directly from OJS, for example in a richtext editor. Obviously this is very difficult with current tools, but it would give greater control over versioning of both source and galleys from within OJS. Again, just an idea.

Also worth noting, since I've fielded the question several times in the past, is that even though we use the NLM-JP XML standard (and I happen to think it's the best DTD out there), there is no obligation to use it - any XML DTD (or W3C schema, even) is useable as long as your XSL path produces a valid output. For example, I know some were looking at the Erudit (http://www.erudit.org/en/) DTD, which is a completely valid alternative.

MJ
mj
Site Admin
 
Posts: 304
Joined: Fri Mar 26, 2004 9:32 am
Location: Toronto, Canada

Postby John » Tue Sep 13, 2005 9:14 pm

This strikes me as a very promising "OJS Development" discussion, and in that forum you'll find Alec's Development Guidelines for working with us on such ideas.
Thanks and looking forward to more on this...
John
 
Posts: 88
Joined: Tue Oct 14, 2003 9:15 pm
Location: University of British Columbia


Return to OJS Editorial Support and Discussion

Who is online

Users browsing this forum: No registered users and 2 guests