search

pkp / pkp-lib

The library used by PKP's applications OJS, OMP and OPS, open source software for scholarly publishing.
https://pkp.sfu.ca
GNU General Public License v3.0
306 stars 445 forks source link

Fix COUNTER plugin template references (and test plugin) #1791

Closed asmecher closed 7 years ago

asmecher commented 8 years ago

See CounterPlugin::logRequest near line 106:

// TODO: consider the effect of LOCKSS on COUNTER recording
assert(false); // Template names no longer apply (e.g. interstitial)
ctgraham commented 8 years ago

Watching this issue.... there's a ton of changes in 2.4.x which need to be brought forward to 3.x.

bozana commented 8 years ago

We don't have this plugin since 2.4.3, I believe -- since the Usage Statistics plugin came. Right? It seems that it has been there already before 2.4.3 and haven't been adapted since then i.e. after 2.4.3? As far as I understand it, it is not used any more for collecting and counting of the usage, just the report plugin is extracted and used further, in order to provide the same reports on the old data (collected and counted before 2.4.3).

bozana commented 8 years ago

@ctgraham, did/do you use this plugin?

ctgraham commented 8 years ago

If we are all talking about reports/counter in 2.4.x (https://github.com/pkp/ojs/tree/ojs-dev-2_4/plugins/reports/counter), yes, this plugin is critical for us. We updated the architecture of the plugin last year to better support multiple reports, updated the COUNTER release to 4.1, and added the AR1 report. This plugin serves as the foundation for the reports available via SUSHI-Lite.

bozana commented 7 years ago

@ctgraham, @asmecher: because the 3.0.1 should come in a few days, can we defer this to 3.0.2?

asmecher commented 7 years ago

Agreed!

asmecher commented 7 years ago

@bozana, gifting you this one!

bozana commented 7 years ago

How generous... I deeply appreciate it... :-)

bozana commented 7 years ago

@ctgraham, I would then just migrate the current Counter plugin from ojs-dev-2_4/ojs-stable-2_4_8 to master, correct? Or would you recommend any further changes?

bozana commented 7 years ago

I will write my comments here, the things I realize during the forwardporting to OJS 3: -- The old COUNTER reports (from OJS 2.4.x) were containing also the remote galleys counts. This will not be the case in the OJS 3. -- The supp files, that are uploaded as galleys in OJS 3 -- and everything (uploaded as galley) is ASSOC_TYPE_SUBMISSION_FILE -- will be considered in the report. EDIT: this will be change: either a new assoc type will be introduce (to still track those files) that will not be considered in UsageStatistics and COUNTER plugin, or those files will not be tracked at all.

bozana commented 7 years ago

From here: https://github.com/pkp/pkp-lib/issues/1314#issuecomment-254580745:

@ctgraham, what implication does it have for COUNTER, if we do not distinguish full text from supplementary/other material? I think it is currently not distinguished in the UsageStatistics plugin, but I will have to double check.

@ctgraham, do you maybe know? On the other side it is maybe similar as in OJS 2.4.x -- the supp files were not considered in OJS 2.4.x, but user could upload whatever he/she wants as a galley and that would be counted´/considered... In OJS 3 everything uploaded in the galley grid is considered as submission file and counted. So maybe it does not matter so much... :-)

ctgraham commented 7 years ago

COUNTER JR1 and AR1 statistics should be based on access to the article full text. The current JR1 report discriminates between full-text access via PDF, HTML, and Other.

If the "ojs::counter" metric continues to be the basis of the JR1 and AR1 reports, it should only include article fulltext views.

bozana commented 7 years ago

@asmecher, for COUNTER (and thus ojs internal ojs::counter statistics) we need to consider only article full text files. Could we do it by considering only submission files with the genre with category = 1, not dependent and not supplementary? Theoretically one could remove all the default components and have no such component (with category = 1, not dependent and not supplementary) that we could use to find out only article full text, but it would probably never be the case, or?

EDIT: I would then like to introduce a new ASSOC_TYPE_SUBMISSION_FILE_COUNTER_OTHER for all those files that are not full texts. Also, the supp files counts from OJS 2.4.x would then have this new assoc type. I would introduce that type in the PKPStatisticsHelper. OK? What number would be good to use for that, 0x0000213 or 0x0000300 or ?

ctgraham commented 7 years ago

I'm a little lost. When I upload a Galley in OJS master, I am prompted to select an "Article Component" for it. Limiting COUNTER JR1 and AR1 report output (and thus the ojs::counter metric) to only galleys with an "Article Component" of "Article Text" and splitting these out (for now) by mime type (pdf, html, other) should cover the use-case.

I don't see the benefit of adding the new association type.

As a note, why can't I later go back and update the "Article Component", or any of the other Galley metadata other than the label, without replacing the file?

bozana commented 7 years ago

@ctgraham, thanks a lot! -- I did something like you have suggested -- Because the users could create new components, I would consider all components that have $genre->getCategory() == 1 and do not have $genre->getSupplementary() and do not have $genre->getDependent(), like for example the default "Article Text".

I thought to keep the event logs and metrics of those other files for the future, e.g. if we would consider them for the COUNTER DB1 report sometime in the future. They would be saved with that other assoc type, just to be in the DB, but would not to be considered for now anywhere, neither in the usage statistics graph nor in the COUNTER reports AR1 and JR1. But, maybe there is no use in saving them like this -- I do not understand deeply that DB1 report :-\ So, do you think I should completely ignore them for now?

I also have another question: in the current COUNTER report plugin some site settings were used, e.g. site title, s. https://github.com/pkp/ojs/blob/ojs-dev-2_4/plugins/reports/counter/classes/CounterReport.inc.php#L270. In OJS 3 there are no site settings, so is there a possibility and does it make sense to use something else i.e. journal settings?

I also do not know the answer for your last question, maybe @asmecher does?

THANKS!!!

ctgraham commented 7 years ago

You mean the site settings are only shown for a multijournal install, correct?

According to the COUNTER 4.1 schema, the Vendor Name should be the "organizational name" of the "content provider". The Vendor Contact(s) should be the "details of a person to contact" at the "organization" which is the "content provider".

For single-journal site installs, this is probably the journal publisher and journal principal contact.

For multijournal installs, this is probably the site name and the site principal contact.

bozana commented 7 years ago

Thanks a lot @ctgraham, I'll take a look, how to adapt it... :-)

bozana commented 7 years ago

PRs: pkp-lib master: https://github.com/pkp/pkp-lib/pull/2489 ojs master: https://github.com/pkp/ojs/pull/1370

bozana commented 7 years ago

@asmecher and @ctgraham, could you take a look at the PRs above? -- Those PRs consider the new assoc type for other files (to log and save them in the DB) that will not be considered in UsageStatistics and COUNTER plugin. If this is not wished, I will change it i.e. totally remove them, so that they are not tracked at all. @ctgraham, it would be great if you would have a possibility to test it. If so, please take into account that remote galleys are now not counted/considered (as this was in the OJS 2.4.x, so that the numbers could differ). @asmecher, it would be great if you could take a look at the code -- I took the same code from ojs-dev-2_4 and adapted it for 3... THANKS A LOT!!!

asmecher commented 7 years ago

@bozana, I just took a skim over it, but I don't know much about this part of the system -- I'm hoping @ctgraham is able and willing to give it a review and test. That said, reading over it I don't see any problems jumping out at me.

asmecher commented 7 years ago

@ctgraham, regarding...

As a note, why can't I later go back and update the "Article Component", or any of the other Galley metadata other than the label, without replacing the file?

There's no particular reason -- it's something we could certainly improve.

bozana commented 7 years ago

I moved the new constant to the others in the PKPApplication and adapted the copyright year, as @asmecher suggested. @ctgraham, it would be great if you could take a look! THANKS!!!

bozana commented 7 years ago

@ctgraham, sorry to bother you :-\ Just to see if you will be able to take a look at this?

ctgraham commented 7 years ago

I am willing, but whether I have the ability is still to be seen! I don't have a real 3.x install with real statistics yet against which to do the testing. I've been struggling with staffing and project challenges which have demanded mostly administrative and support efforts recently, but I requested some dedicated time for development sprints this month. I'm not trying to ignore you!

bozana commented 7 years ago

@ctgraham, thanks a lot! It's good to know the situation... so to know what to do with this... :-)))

bozana commented 7 years ago

@asmecher, @ctgraham, what do you think about merging this and then, if there is a problem, I will fix... ? If OK so I will take a final look and test and rebase...

ctgraham commented 7 years ago

I'm just finishing deploying our first production 3.x journal, with the final steps of loading historic usage statistics from the old (non-OJS) system. I could spin up a quick 2.4.8 install of the journal, load the stats there, then perform an upgrade and compare statistics against a fresh load within of 3.0.2. Would that be a useful exercise? It would only be including fulltext downloads of articles; I don't have published supplementary files in my current migration.

bozana commented 7 years ago

@ctgraham, that could be great if you also do not have any remote galleys -- they were counted in OJS 2.4.x but not in 3.x. Also the other, embedded files like CSS, etc... THANKS A LOT! -- I would like to merge this for 3.1... :-)

bozana commented 7 years ago

I've just merged this, because of the locale freeze, but there is still some time to the release for testing and changes... :-)