Additions needed for first release

[ajnyga]

Additions for the first release

• Plugin options to choose different ways of presenting the reviewed objects. 1) automatically replace the subtitle of the article with a list of objects 2) show a list of reviewed objects on the landing page

• Management options for editors to add/remove objects

• Public page for viewing a list of objects. See https://github.com/pkp/browseBySection/blob/master/BrowseBySectionPlugin.inc.php#L38-L40 for required hooks

• Possibility to choose available objects from a predefined list when submitting an article

• Validation for identifiers in forms (ISBN, ISSN, URL, URN, DOI)

Additions for a later release

• Consider if section settings needed to define which section is for reviews?

• Consider other ways of limiting the visibility of the ofr panel if user is not submitting a review

• possibility to choose/reserve an object before submitting. The submission process would suggest the reserved object for the author when the author returns to do the submission. ¨

• Advanced editorial controls: add object to a submission, remove object from a submission. release a reserved object from a user

• Consider injecting reviewed object data to Crossref/Datacite/OpenAIRE exports

• Create a visually more appealing listing style to the landing page

[ajnyga]

Instead of using the current list of available item types, which was generated from Zotero and JATS examples, I will use COAR Resource Types because they enable us to save an URI instead of a label. http://vocabularies.coar-repositories.org/documentation/resource_types/2.0.draft/

				'http://purl.org/coar/resource_type/c_2f33' => 'plugins.generic.objectsForReview.COAR.book',
				'http://purl.org/coar/resource_type/c_3248' => 'plugins.generic.objectsForReview.COAR.bookPart',
				'http://purl.org/coar/resource_type/c_6501' => 'plugins.generic.objectsForReview.COAR.journalArticle',
				'http://purl.org/coar/resource_type/c_5794' => 'plugins.generic.objectsForReview.COAR.conferencePaper',
				'http://purl.org/coar/resource_type/c_46ec' => 'plugins.generic.objectsForReview.COAR.thesis',
				'http://purl.org/coar/resource_type/c_816b' => 'plugins.generic.objectsForReview.COAR.preprint',
				'http://purl.org/coar/resource_type/c_7ad9' => 'plugins.generic.objectsForReview.COAR.website',
				'http://purl.org/coar/resource_type/c_ddb1' => 'plugins.generic.objectsForReview.COAR.dataset',
				'http://purl.org/coar/resource_type/c_ddb1' => 'plugins.generic.objectsForReview.COAR.software',
				'http://purl.org/coar/resource_type/c_12cc' => 'plugins.generic.objectsForReview.COAR.cartographicMaterial',
				'http://purl.org/coar/resource_type/c_18cc' => 'plugins.generic.objectsForReview.COAR.sound'

[jmacgreg]

Hi @ajnyga, just going through a review right now, and it's looking good. Three thoughts on the list of items needed for first release:

1. I'm not sure whether the identifier field should be a required field. Thoughts on that?
2. I don't know if identifier validation should be required for first release - I think that could come later. (IIRC, there are already some validator options for ISSNs and DOIs, but I could be wrong. Regardless, I think this isn't super required.)
3. Any thoughts on adding some TinyMCE functionality to the description feature? I'm not exactly sure how this should work, but if it's the place to add book title + author name + other info, it would be great to be able to bold/italicize things. It would also be a good place to be able to upload an image - e.g. a book cover. I would consider this more immediately valuable than the identifier validation option.

[ajnyga]

Hi,

1. I think there are two different ways of looking at a plugin like OFR. For me the original need comes from the national library where they would like to see what books/objects have been reviewed in review articles in OJS. Here persistent identifiers of course come into play.

Ideally we could even send DOI and ISBN pairs to places like Crossref and they would see that this article is a review of this book. I have not looked yet if that is supported in their schema currently. If it is, it would be fairly easy to add a hook in the OFR plugin to handle this.

Of course we could make the field optional in the settings, but after that the plugin does not really add much value when publishing reviews in OJS. You could just paste the same data to the abstract field or the subtitle.

2. I am thinking of some really simple validation like checking that DOIs are formed correctly, not that we would ever check if they actually work. I will look at this briefly and see how much it includes but agrees that it should not be a thing that would stop us releasing the first version.

3. I will see if tinymce is possible to enable. I think it should only involve adding one parameter to the tpl-file. Regarding images, I would prefer that images would be saved separately. This way we could have some cool layout models like Masonry. I will check how image uploads are handled.

I also got some comments from one of our journals. They would prefer if some of the item data would be saves separately. Namely the authors, title and year of release. We have been trying to avoid a database schema that is too complicated, but I think it would make sense to cover those. They would enable ordering the frontend list with for example the author name or year.

[jmacgreg]

Hi @ajnyga, thanks - your thoughts here make sense to me. A few quick responses:

1. This still doesn't quite make sense to me, but if it's something that will be built upon over time that sounds good.

2. Sounds good.

3. Maybe the larger question here, which is already partially answered by your other journal's comments, is how to represent (graphically, but also in the schema) content like title, author, publisher, year, cover, etc. If the plugin stays as-is, that is with one "description" field for all of that, I think TinyMCE will be necessary - not just for image uploads, but also for bolding titles, italicizing author names, etc. But I agree with your journal that having separate fields would make sense. I think the necessary ones would be: title; authors; publication date; publisher; and identifier (which is already available). Also, keep the general description field, but for a text blurb. (It could still use TinyMCE formatting controls.)

https://edrev.asu.edu/index.php/ER/objectsForReview provides an example of how the current plugin works. It displays a subset of object metadata on the listing page, and if you click through to the object page (eg. to https://edrev.asu.edu/index.php/ER/objectsForReview/viewObjectForReview/1161) you'll see a much richer metadata set. I don't think we need this full set - just a reasonable subset as your journal suggests would do, at least for now.

[ajnyga]

Hi,

Yes the original request was to make the plugin simpler than the last one. The old OFR plugin had a large schema which contributed to the fact that there was a lot of code to maintain.

But I am shortly uploading a new version with separate fields for authors, title, publishers and pub year. The title field has tinymce enabled.

The cover image request I did not have time to look at yet. I could not find any plugin enabling file uploads so it will take some time to figure out how to do that in a plugin.

[ajnyga]

@jmacgreg new 3.1.2 compatible version in the master branch: https://github.com/ajnyga/objectsForReview

It includes a new schema, so make sure you remove the old tables and make sure you run the upgrade process so that the new tables are created.

I also added email notifications when an object is reserved/cancelled. The recipient email can be given in the settings.

Still forgot to rename the tables to something new so that they will overwrite the old OFR plugin tables, but that is a small thing to add.