Licenses (UXPROD-574)

[UXPROD-1755] Support display of license terms in discovery/patron facing interfaces Created: 28/May/19  Updated: 18/Dec/22  Resolved: 16/Dec/19

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q1 2020
Parent: Licenses

Type: New Feature Priority: P3
Reporter: Owen Stephens Assignee: Owen Stephens
Resolution: Done Votes: 0
Labels: erm, licenses, po-mvp, resourcemanagement, team-mvp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File image-2019-06-06-16-08-12-105.png     PNG File image-2019-06-06-16-10-37-239.png    
Issue links:
Defines
is defined by ERM-355 Manage public notes on license term v... Closed
is defined by ERM-356 Expose license terms over API Closed
is defined by ERM-357 Public and internal license term values Closed
Epic Link: Licenses
Development Team: Bienenvolk
PO Rank: 85.5
PO Ranking Note: This is a Chalmer's go-live requirement and is essential for them to be able to display information about the allowed use of e-resources to patrons
Rank: Chalmers (Impl Aut 2019): R1
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R4
Rank: 5Colleges (Full Jul 2021): R4
Rank: GBV (MVP Sum 2020): R1
Rank: Lehigh (MVP Summer 2020): R4
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R3

 Description   

In order that users of content can see what license terms apply to a specific resource, this feature is to allow the display of relevant data to users via the relevant discovery/A-Z/link resolver interfaces.

License app may require additional work to support.

  • the ability to indicate which terms of use can display to patrons
  • ensure that discovery/A-Z/link resolver provider can call a License API to display applicable terms of use
  • ensure a License API response includes the resources that are tied to the agreement which is tied to the license.

Note that this feature is only about planning to return a JSON representation of the information - any formatting for display and integration into the relevant interfaces is out of scope of this feature and would need to be done by the institution implementing this in their discovery/patron facing interface

Examples



 Comments   
Comment by Jag Goraya [ 14/Jun/19 ]

From phase 3 planning (Owen Stephens):

My current view is this has tasks:

  • Implement Control/config of public/non-public display of license terms
  • Define API for request of license terms (request/response)
  • Implement API
Comment by Owen Stephens [ 19/Jun/19 ]

From discussion at F2F meeting with Khalilah Gambrell Theodor Tolstoy (One-Group.se) Marie Widigson:

  • API call to an "edge API" (suggested by Theodor Tolstoy (One-Group.se)) service and get a license JSON representation back for public facing properties
    • eHoldings resource ID
    • License ID
    • Not required for Chalmers but also potentially Title identifier?
  • Should we support multiple IDs in a single call? What happens if this identifies multiple resources
  • Need to be able to:
    • Configure terms to be public or not - system wide default
    • Allow terms in a specific license to override the default
    • Need a Patron facing note as well as internal note
      • Internal note is the existing one? - needs to be unlimited length, but would be nice if didn't have scrolling problem!
      • Patron facing note - would need to translate internal characters to HTML (e.g. paragraph break, hyperlink). Possibly that could be post-processing at the display end
Comment by Marie Widigson [ 19/Jun/19 ]

As we need some parts of this as go-live, should the Jira be splitted? Owen Stephens Khalilah Gambrell Theodor Tolstoy (One-Group.se)

In order to be able to enter information by August 19th, we need to have in place:

  • Configure terms to be public or not - system wide default
  • Allow terms in a specific license to override the default
  • Need a Patron facing note as well as internal note
Comment by Owen Stephens [ 19/Jun/19 ]

Marie Widigson do you mean that being able to enter the data is higher priority than having the ability to display it in the patron facing system?

Comment by Marie Widigson [ 20/Jun/19 ]

Owen Stephens Yes. We plan to start entering license information the week starting with August19. In order to start working with the migration of current license terms (and not having to go through all licenses again later), we need to know which fields that will be publicly displayed and which fields are for internal use only.

Of course, we want to actually publicly display the terms entered in FOLIO as very soon as possible as well, to avoid having to maintain the terms in two places. I'd love to put the whole 1755 as go-live, but if you need us to prioritize hard, entering the info has higher prio.

Comment by Theodor Tolstoy (One-Group.se) [ 21/Jun/19 ]

Owen Stephens so I think all are to be considered as Go-live, but given the nature of Chalmers' go-live process, the Information adding-parts need to be there before the "patron-facing" APIs.

Comment by Martina.Schildt [ 02/Jul/19 ]

Owen Stephens Ian Ibbotson (Use this one) Jag Goraya This seems to describe the possibility to present license conditions in discovery. In addition to the display, the system should be able to manage access and make fully automated decisions for the patron. Please see document: https://drive.google.com/file/d/1nExribL9omUyut-zaRQOP3jpoFxEv2ZD/view?usp=sharing.

Comment by Theodor Tolstoy (One-Group.se) [ 12/Aug/19 ]

Good point Martina.Schildt That is an important long-term goal that I think we need to keep track of so we do not make decisions that prevent us from building that in the future. Machine-readability is key to that.

Reading your document, I am of the opinion that the scope for that document is to narrow, and that it should include other kinds of resources (local print, ILL, IR, Braille, Audio books...) for those scenarios to be conclusive and usable. I really like the approach of the Variable objects and how they interact.

Generated at Fri Feb 09 00:18:15 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.