Spike - Platform Report

[labradford]

Story

Create a list of all items that should be included in the Platform report and understand how the items align with Hyku

Acceptance Criteria

• [ ] List all of the items that will be a part of the Platform report
• [ ] Each item should have a description of what it is and how it is related to Hyku

  Testing Instructions

  Not end user testable

  Notes

  There are two Platform Reports: the Platform Report and the Platform Usage Report

[labradford]

https://cop5.projectcounter.org/en/5.1/_downloads/ffdce08b0c5f611cd6ed2702cf86fd3e/PR_sample_r51.xlsx

https://cop5.projectcounter.org/en/5.1/_downloads/6fe1c7c64f9709df5cbbb8a7710d36e9/PRP1_sample_r51.xlsx

[labradford]

Platform Report Headers

• Report_name => Platform Report
• Report_ID => PR
• Release => 5.1
• Institution_Name => Name of the institution the usage is attributed to > Is this Institution Name or Application Name?
• Institution_ID => Blank unless they provide us with this info
• Metric_Types => Semicolon-space delimited list of Metric_Types included in the report (Total_Item_Requests; Unique_Items_Requests; Limit_Exceeded; No_License)
• Report_Filters => Semicolon-space delimited list of filters applied to the data to generate the report.
• Report_Attributes => Semicolon-space delimited list of report attributes applied to the data to generate the report.
• Exceptions => Any exceptions that occurred in generating the report, in the format “{Exception Code}: {Exception Message} ({Data})” with multiple exceptions separated by semicolon-space (“; ”).
• Reporting_Period => Date range requested for the report in the form of “Begin_Date=yyyy-mm-dd; End_Date=yyyy-mm-dd”. The “dd” of the Begin_Date is 01. The “dd” of the End_Date is the last day of the month.
• Created => ate and time the report was run in RFC3339 date-time format (yyyy-mm-ddThh:mm:ssZ).
• Created_By => Name of organization or system that generated the report. <institution_name???>
• Registry_Record => blank
• BLANK LINE

Platform Report Columns/Elements

Mandatory

• Platform => not sure what this would be, maybe tenant?
• Data_Type => <resource_type>
• Metric_Type => Total_Item_Requests; Unique_Items_Requests (listed in header)
• Reporting_Period_Total => Count of Total items
• Mmm-yyyy (Jan-2022) => Count of monthly items

only if Called for

• Access_Method => Regular or TDM

Platform Report Filter Items

• Data_Type => <resource_type>
• Access_Method => Regular; TDM
• Metric_Type => Searches_Platform; Total_Item_Investigations; Total_Item_Requests; Unique_Item_Investigations; Unique_Item_Requests; Unique_Title_Investigations; Unique_Title_Requests
• Exclude_Monthly_Details (defaults to False)

[labradford]

Platform Usage Report Headers

• Report_name => Platform Usage
• Report_ID => PR_P1
• Release => 5.1
• Institution_Name => Name of the institution the usage is attributed to > Is this Institution Name or Application Name?
• Institution_ID => Blank unless they provide us with this info
• Metric_Types => Searches_Platform; Total_Item_Requests; Unique_Item_Requests; Unique_Title_Requests
• Report_Filters => Access_Method=Regular
• Report_Attributes => blank
• Exceptions => Any exceptions that occurred in generating the report, in the format “{Exception Code}: {Exception Message} ({Data})” with multiple exceptions separated by semicolon-space (“; ”).
• Reporting_Period => Date range requested for the report in the form of “Begin_Date=yyyy-mm-dd; End_Date=yyyy-mm-dd”. The “dd” of the Begin_Date is 01. The “dd” of the End_Date is the last day of the month.
• Created => ate and time the report was run in RFC3339 date-time format (yyyy-mm-ddThh:mm:ssZ).
• Created_By => Name of organization or system that generated the report. <institution_name???>
• Registry_Record => blank
• BLANK LINE

Platform Usage Report Columns/Elements

Mandatory

• Platform => not sure what this would be, maybe tenant?
• Data_Type => <resource_type>
• Metric_Type => Total_Item_Requests; Unique_Items_Requests (listed in header)
• Reporting_Period_Total => Count of Total items
• Mmm-yyyy (Jan-2022) => Count of monthly items

Platform Usage Report Filter Items

• Data_Type => <resource_type>
• Access_Method => Regular
• Metric_Type => Searches_Platform; Total_Item_Requests; Unique_Item_Requests; Unique_Title_Requests
• Exclude_Monthly_Details (defaults to False)

[labradford]

Sample JSON for platform report is located here: https://countermetrics.stoplight.io/docs/counter-sushi-api/e98e9f5cab5ed-pr-platform-report

Sample JSON for the platform usage report is located here: https://countermetrics.stoplight.io/docs/counter-sushi-api/82bd896d1dd60-pr-p1-platform-usage

[ctgraham]

Platform => not sure what this would be, maybe tenant?

I would lean toward interpreting the Platform as the Hyku tenant.

Another viable interpretation would see the Platform report available at the consortial level, and the Platform is H4C itself. Compare, for example, EBSCO as a platform hosting multiple databases, journals, etc. I think this interpretation breaks down for H4C in that tenants would presumably want their usage metric aggregated to the tenancy, as opposed to the consortia at large.

[crisr15]

What host type would you be / which counter reports do you need?

• Certainly for Pitt's usage both of our tenants would fall in the "Repository" host type (one institutional repository, and one subject repository). Within broader H4C usage, I wonder if there could be cause to support the "Multimedia" and/or "Data_Repository" host types. If host types beyond "Repository" were needed, might this be a configurable setting in the "Account" or "Labels"?
• The primary reports of interest are the PR Platform Master Report and the IR "Item Master Report", as this would be used to share and aggregate usage metrics. Database Reports and Title reports do not apply to the Repository host type.

Investigation vs. Request: If the PDF is viewable on the page, should any time the page loads it count as an Investigation or a Request?

• Yes, the view of a PDF on page is considered an Investigation and a Request. See figure 3.e here: https://cop5.projectcounter.org/en/5.0.2/03-specifications/03-counter-report-common-attributes-and-elements.html#metric-types

Will you have any access restrictions? (do we need to record no_license or limit_exceeded? )

• Pitt does not have nor anticipate subscription-based access controls. We do have a few dark archive materials which we will need to decide how to handle, but these don't even display in search currently, so it is not possible to get a No_License or Limit_Exceeded condition for these items. If other H4C clients have license-restricted materials we can chat about that, but our funding and scope would prioritize OA materials. (N.b. embargoed material access would fall under the "Controlled" access type).

For searches, will you only have one database? (ie, will we need to support searches on shared search, and in different tenants differently for the counts?)

• I believe metrics should be aggregated to the tenant. I would interpret a "shared search" implementation across multiple tenants to actually be a different COUNTER Host Type, specifically A&I_Database or Aggregated_Full_Content. Pitt does not have a specific requirement for implementing shared search across the two planned tenants and does not propose a requirement for reporting these searches. Searches can be limited to the Searches_Platform metric type.

How would the Data_type attribute be determined on a work? (resource_type?)

• I concur that the Data Type most directly maps to a Resource Type. How is the list of Resource Types managed? If static, I hope we can assume that the mapping from Resource Type to Data Type can be set for all tenants, but if tenants can add/edit Resource Types, this may become more complex. Is there any implication for future changes to the Work Type / Resource Type relationship?

How would sections be determined? Would it be based off of a metadata field? Off of relationships? What would this look like?

• Sections only apply eJournal, eBook, and similar host types, so I don't believe this will apply to H4C clients unless others are using H4C for journal or ebook publishing.

What access types will you have? How would we determine what was what?

• For Access Types, our use case would be entirely within Other_Free_To_Read (and maybe OA_Gold). If others implement access restrictions, content which requires a login would be categorized as Controlled. There should be metadata backing to distinguish open resources between Other_Free_To_Read and OA_Gold, but quite honestly, a simpler approach might be to classify all open repository deposits as Other_Free_To_Read, as the OA_Gold version is unlikely to be the deposit.

[summer-cook]

questions: how often/when would reports be generated?

potential tickets

• create general "reports" model
• create subclass models for each report type
  • [ ] platform report
  • [ ] platform usage report
• create general reports controller - create, read, update, probably not delete (unless we need to delete to generate new reports?)
• create controllers for each report type (?)
  • [ ] platform report
  • [ ] platform usage report
• create /reports page and view partials for each report type (?)
  • [ ] platform report
  • [ ] platform usage report

[labradford]

Next step is to investigate the JSON structure #622