|
Few questions that we want to answer as part of this spike:
1. What will Orders app have as part of its PO/POL? Will it have package name/title name? What will it use for searching eHoldings/Codex?
2. Does Orders need CQL for its search?
3. Do we want Orders to integrate with Codex app or eHoldings? This is kind of dependent on answer to question 2.
4. Based on 1 and 2, what will Orders app need from eHoldings to be able to integrate with eHoldings/Codex apps?
|
|
Meeting held on 12/18 -
Answers to the questions above:
1. Orders app as part of its POL -> E-resources details -> will have "Access Provider" which is equivalent to "Provider" in eHoldings. POL -> Item Details -> will have "Title" which could either be name of package or a title in eHoldings. An approach was discussed to add a field indicating if it is a package/title in "Item Details". Orders can send a combination of "Provider" + "Package/Title Name" in order to search for the specific item in eHoldings.
2. Orders app would like to use CQL for its search since its the norm across FOLIO.
3. Decision has been made to integrate Orders with Codex instead of eHoldings since users will be able to - search multiple sources and Codex supports CQL parsing as well. What needs to be done for Orders to integrate with Codex is to enhance Codex/eHoldings by providing an endpoint which takes "Provider Name" and "package/title name" from Orders and gives back a list of results from Ebsco KB. Whether we want to leverage existing code in mod-kb-ebsco-java and tweak it there/add support in Codex itself needs more thought and discussion.
4. For now, from the above, it looks like there are a couple of things that need to happen. In the UI of Orders, when user is about to "Create a POL" -> "Add Item Details" -> they will have ability to click on a "+" (Add) button that should open up a plugin for Codex Search app, when users search in Codex, an endpoint the either Codex/eHoldings should be able to provide Orders app with the accurate result of the item based on information provided by Orders(Provider Name + Package/Title Name), user should be able to select the item and add it to their POL in Orders. This is one workflow that has been discussed.
Next Steps are for Khalilah Gambrell to think through more use-cases and discuss them in a follow-up meeting.
Sobha Duvvuri and Carole Godfrey to think through enhancements to be made to Codex/eHoldings, discuss technical approach with Craig McNally, VBar and Codex/Multiplexer team.
|
|
Codex Search would be a good option for searching for KB packages/titles since it provides a general purpose interface (supported by inventory/kb/agreements(entitlements)) and could provide a common lookup/interaction for Orders.
Backend modules support cql – https://dev.folio.org/reference/glossary/#cql
Codex would need to be enhanced in that it ONLY supports GET Instances and GET Instances by Id. More detailed information about the instance (for example the packages in which the instance is available) is currently only available within eHoldings application.
Reference for details of instance lookup
https://s3.amazonaws.com/foliodocs/api/mod-codex-ekb/p/codex.html#codex_instances__id__get
There are currently some outstanding questions/concerns with Codex Search UI - ie search from codex ui vs search from eHoldings
(1) https://folio-org.atlassian.net/projects/UISE/issues/UISE-91?filter=allopenissues - an * gets appended to all searches – this is problematic for KB searching and we would like users to be able to control whether an * is appended to search as needed
(2) https://folio-org.atlassian.net/browse/UISE-98 - specific issue with appended * when looking up title by folio id. This currently fails due to added *
(3) Closed issued – https://folio-org.atlassian.net/projects/MODCXMUX/issues/MODCXMUX-27?filter=allissues – quotes are not supported when entering search term in ui. There are concerns with supporting quotes within a CQL term. This limits capability currently available https://developer.ebsco.com/guides/advancedsearch
(4) Support of Boolean operators (https://folio-org.atlassian.net/browse/MODCXEKB-64) – operators can be entered in the text box from ui (this translates to operators in term itself) – does this need to be revisited?
For example – when entering `spring OR summer` in search box
Current generated CQL is query=title+=+"spring+OR+summer*"+sortby+title
Discussions around generated CQL being query=title="spring"+OR+title="summer*"+sortby+title
https://folio-org.atlassian.net/browse/UXPROD-1015
(5) When selecting a title from the result list, we are redirected to either eHoldings or Inventory app. Look into Helper App for 3rd pane of codex search to avoid going directly to individual applications and losing search context.
Notes/Refs
https://github.com/folio-org/stripes/blob/master/doc/dev-guide.md#plugins
https://github.com/folio-org/ui-plugin-find-instance (Current inventory plug in)
|
|
We would very much like to add a test case for GOKb as a source of truth - EG I would like to order bentham science complete - but as defined in GOKb - happy to provide a codex implementation that will do this as the interface is developed.Mod-agreements currently implements codex and will allow searching of any package data in GOKb.
|
|
To follow is an outline of high level tasks to implement Codex Search for Orders lookup of KB packages and titles:
List of Modules requiring changes for implementation:
- ui-search (Codex UI)
- mod-codex-mux
- mod-codex-ekb
- mod-codex-inventory
- mod-agreements (entitlements)
- new ui-plugin-codex-find-resource (* New plugin to support searching for packages or title packages in Codex)
#1 Use Case — Look up a package to associate with a PO line
- Define and agree upon Codex package definition (normalized fields for package)
- Define and agree upon Codex Interface to search for packages (eholdings supports package name, selected, content type)
- Define Codex Interface to get package by package id (eholdings unique package id is `vendorid-packageid`)
- Create common RAML for agreed upon definitions
- Implement GET Package and GET Package by Id Codex API (implement in 2 modules - not yet in inventory)
- Updates to Mux to support packages
- UI Design to support package search
- UI Design - define fields to display in result list list for packages
- UI-Search Implement changes for packages (search and result list as per UI Design)
- Implement 3rd pane details as helper app vs going directly to separate UI modules for package details
- Create Codex find-resources plug in app to be used by Orders
#2 Use Case - Look up a title package to associate with a PO Line
- Define and agree upon Codex resource (title/package) definition (normalized fields for title/package) - current codex title + array of containing package details
- Define and agree upon Codex Interface to search for title/packages (assume search would be same as current Codex search as starting point to locate titles)
- Define Codex Interface to get resource by resource id - (for eholdings this is `providerid-packageid-titleid`)
- Create common RAML for agreed upon definitions
- Implement GET Title/Package and GET Title/Package by Id Codex API (implement in 3 modules)
- Updates to Mux to support title/packages?
- UI Design to support title/package search (similar to instance search – some considerations if 1 UI will handle both packages and title packages)
- UI Design - fields to displayed in result list list (main title row + subrows with package information) blended results supporting multiple sources could be difficult
- UI-Search Implement changes for title packages (based on UI Design search and result list)
- 3rd pane details as helper app vs going directly to separate UI module for title details — title details to include list of packages
- Additional Codex endpoint — given an individual title id, get all the packages which contain this title
|
|
To follow is a list of preliminary fields for Packages and Title Packages that need to be considered for normalization:
Package
- package id — unique
- package name
- isCustom
- providerId
- providerName
- title count
- isSelected
- VisibilityData (isHidden, reason)
- selected count
- custom coverage (begin, end)
- content type
- package type
Title Package
This is the title element + array of details (each detail element providing details about the title within a package). Title element can use same fields that are used by instance
- titleId
- titleName
- publisherName
- identifiersList (array of identifiers)
(id, type)
- subjectsList (array of subjects)
(type, value)
- isTitleCustom
- pubType
- contributorsList (array of contributors)
(type, name)
- Package Details (array – each element provides details of the title within a package)
packageId
packageName
packageType
isPackageCustom
providerId
providerName
locationId
isSelected
visibilityData (isHidden, reason)
managedCoverageList (array of beginCoverage, endCoverage dates)
customCoverageList (array of beginCoverage, endCoverage dates)
coverageStatement
managedEmbargoPeriod (embargoUnit, embargoValue)
customEmbargoPeriod (embargoUnit, embargoValue)
url
|
|
This issue seems to relate to searching Orders.
Search by package ID / TitlePackage ID must be opaque - IE for EKB it's nn-nnnn, but for other KBs structured differently this makes sense. Mod-Agreements will be using a UUID rather than a composite hyphenated or compound key. In some cases, titles we manage may not have a vendor. We will want to search for orders by POLs used in mod-agreements and they will have package identifiers structured differently.
Similarly, would like to be able to approve the definitions of codes types (Instance, Package, PackageTitle) at the community level - so as to ensure they are not tightly bound to the EKB structures – OR – at the very least, make fields optional and allow extensibility points - so other codex implementations can specify the fields they need.
If these are OK, then I think we can sign this off.
|
|
Ian Ibbotson (Use this one) – On your first point – I think as long as the UUID will uniquely define the entity (Package or TitlePackage) we should be good. I just noted that EKB's unique identifiers were structured as a composite string - but we shouldn't impose that as a requirement.
On defining codex types - absolutely agree that these should be defined and agreed upon at community level. There is 1 story for packages definition https://folio-org.atlassian.net/browse/MODCXEKB-72 and a separate story for title packages
|
Generated at Fri Feb 09 00:14:23 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.