OJS File Structure

[ramon]

Fellows,
I noticed that creating the layout galleys is not a job for a common user. And it seems that for someone unfamiliar with OJS will have terrible issues when uploading the images for an article, because of the addressing.

This brings a question I´ve sent to Kevin and John about the whole archiving of OJS. It seems to me a bit easier for maintenance and coding (not sure how easy it is to create directories..) to have a folder for each issue, with separate folders for each article, with an image folder in it... something like:

Code: Select all

issue>article>images

I realise that the current structure protects the content, so there are references to the articles and images. However, in the HTML code, the editor needs to change the HTML code of image tags to something like:

images/articleimages/+ojsarticlename+ojsimagename

Having a structured file system like the one suggested could allow to separate the Administration area from the Visualization/Reader area, which in turn allows for one Administration to control multiple journals, in different servers altogether.

Just wondering...

[kevin]

This component has not been developed yet, but are plans do include a filesystem layout similar to the one you've suggested.

[mj]

I think the natural structure, from what we've been doing on JMIR, would be something like: /volume/issue/article/

This would allow galleys and similar files to be stored on a per-article basis, within the same directory. While having sub-levels (like an /images subfolder) is helpful for things like a webserver, it also adds a level of complexity - which I think should be optional, at most. (eg. does one use /images, /img, /app, /supp, etc?)

Because JMIR does HTML rendering from XML, we store files in a /volume/article/ structure, with the .xml file and all images, appendices, etc. in the /article folder. With a standardized filenaming convention (and extension), it's easy to know what files are where.

Another alternative would be to store files in the database as BLOBs, but I think that's probably fairly heavy for something like OJS, especially if multiple journals are being hosted on the same database.

M

[kevin]

Current plan is for the file layout to be like files/<journal_id>/<article_id>/[submission | review | public] where submission, review, and public directories contain the original submission files, review/editing versions, and final published files.

Unless files are to be shuffled around upon publication, we can't really use the volume or issue, as those values are not known until the article is actually assigned to an issue.