Codex (UXPROD-833)

[UXPROD-148] Allow the integration of multiple knowledgebases for e.g. reference cataloging. Some will support holdings such as EPKB. Created: 18/Jan/18  Updated: 16/Sep/20  Resolved: 09/Apr/19

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Codex

Type: New Feature Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Charlotte Whitt
Resolution: Won't Do Votes: 0
Labels: crossrmapps, erm, metadatamanagement
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to UXPROD-833 Codex Closed
relates to UXPROD-920 Codex App Closed
Epic Link: Codex
Analysis Estimate: Medium < 5 days
Analysis Estimator: Charlotte Whitt
Front End Estimate: Large < 10 days
Front End Estimator: Mike Taylor
Front-End Confidence factor: Low
Back End Estimate: Large < 10 days
Back End Estimator: Ian Ibbotson (Use this one)
Development Team: Prokopovych
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: 5Colleges (Full Jul 2021): R1
Rank: GBV (MVP Sum 2020): R1
Rank: Lehigh (MVP Summer 2020): R3
Rank: TAMU (MVP Jan 2021): R2
Rank: U of AL (MVP Oct 2020): R2

 Description   

This feature was created before the ERM subgroup was formed. This may eventually become a feature or set of stories related to 589
---------------------------------------------------------
Allow the integration of multiple knowledgebases for e.g. reference cataloging.� Some will support holdings such as EPKB.

Do we have any plans for expanding the Codex Search beyond the present two sources (Inventory and EBSCO KB), eg. GoKB for v1? We need to avoid allowing the design and specifiction of the Codex to be too dominated by the two sources we happen to have right now. If we can add a at least one more source, then the use case for Codex Search will be more evident for SMEs and testers, and we can ensure both the UX and implementation won't get any surprises down the line.



 Comments   
Comment by Mike Taylor [ 02/Mar/18 ]

I am 100% on board with "We need to avoid allowing the design and specification of the Codex to be too dominated by the two sources we happen to have right now. If we can add a at least one more source, then the use case for Codex Search will be more evident for SMEs and testers, and we can ensure both the UX and implementation won't get any surprises down the line."

But my understanding had been that we were not planning to do this for v1. If we did so it, it would be a non-trivial bit of work, involving new UX elements and their implementation down the stack through stripes-components, stripes-smart-components and ui-users. But I think it's important work.

Also, the back-end component would be entirely dependent on what the additional resource (or resources) to be integrated was.

Comment by Mike Taylor [ 02/Mar/18 ]

On the UI side, the complication is that having two Codex sources of the same kind ("KB") introduces a new notion into the mix, and we'd need UX work, which would then of course need to be realised in the UI. Would we want the ability to select "all sources of type KB", for example?

If not – if we just treat it as an opaque third source, with no classification of sources – then it's much simpler to handle.

Comment by Cate Boerema (Inactive) [ 04/Apr/18 ]

I think Owen Stephens seems like the natural PO for this feature. Owen, if that doesn't make sense, let me know.

Comment by Khalilah Gambrell [ 30/May/18 ]

Owen Stephens - I think we should discuss how the work done for mod-kb-ebsco ties into this effort. And also my only concern with codex at this time is there is no way to search for packages and it does not provide any titles in the context of a package.

Comment by Mike Taylor [ 30/May/18 ]

As I understand it, the absence of support for packages is not limited to the Codex, but comes from the fact that they are not recognised in Inventory either – isn't that right? If so, then there's probably not much point putting too much effort into them on the Codex side before that's fixed.

Comment by Charlotte Whitt [ 30/May/18 ]

Mike Taylor - Packages in Inventory is definitely considered A small working group with participants from MM-SIG and RM-SIG is established around this work. First meeting is expected to happen next week - see: https://wiki.folio.org/pages/resumedraft.action?draftId=14452087&draftShareId=0a8491a2-dcf4-4e48-b26d-b38b1e88c584

Comment by Cate Boerema (Inactive) [ 10/Jun/18 ]

Owen Stephens, I know that as part of your ERM project you will be working to integrate GoKB. Given that, I would like to keep this old feature with your work. Not sure where it belongs specifically so I just put it with Agreements ( UXPROD-573 In Progress ) for now.

Comment by Holly Mistlebauer [ 20/Jun/18 ]

In the gap analysis Chicago indicated that they need this feature within the first quarter of their "go live" date:
"Integration with Ex Libris KBs: SFX and 360 knowledge base, and all of the functionality available currently for EBSCO KB.
Work would be dependent upon legal agreement of Ex Libris."

Comment by Owen Stephens [ 20/Jun/18 ]

"all of the functionality available currently for EBSCO KB" would be an eHoldings question I think Khalilah Gambrell
That's not to say it is out of scope for ERM to work with these KB it's just in terms of how this is phrased makes me think that what they are looking for is the eHoldings functionality right now?

Comment by Khalilah Gambrell [ 20/Jun/18 ]

Holly Mistlebauer - My guess is Charlotte outlined this feature to support the Codex. There is another feature that pertains to integration of KB providers to support eholdings and ERM (https://folio-org.atlassian.net/browse/UXPROD-166). It might be helpful to breakdown the feature into multiple features represent integration per KB provider for prioritization

Comment by Cate Boerema (Inactive) [ 25/Jul/18 ]

Per discussion with Owen Stephens, the ERM features will interact with multiple KBs (GOKb and EPKB to start), but that capability is included in the (other) ERM features Owen created.

This feature was originally created by Charlotte (perhaps based on something in the v1 roadmap).

Based on the description here and the people who estimated it (Mike Taylor and Ian Ibbotson (Use this one)), this feature seems to be about incorporating GoKB into the Codex app. This is a worthwhile endeavor, but not in scope for Owen. Charlotte Whitt, I am turning this back over to you and putting in the Codex epic. I am also renaming this, as the current feature name (Allow the integration of multiple knowledgebases for e.g. reference cataloging. Some will support holdings such as EPKB) is confusing.

If I am misunderstanding the intended purpose of this feature, please let me know. I don't want to change the name of the feature in such a way that it no longer represents what was estimated. Thanks!

Comment by Cate Boerema (Inactive) [ 25/Jul/18 ]

If everyone is okay with the changes I've made to the title and epic of this issue, I think the next step is to follow up with Chalmers to see if they really need GOKb integrated into the Codex for go-live if it will be integrated into ERM.

Comment by Charlotte Whitt [ 25/Jul/18 ]

Cate Boerema - okay. I'll reach out to Chalmers. Both Theodor and Lisa is away on vacation this week. But as soon one of them are back, I'll talk to them about Chalmers expectations.

Comment by Mike Taylor [ 25/Jul/18 ]

Cate Boerema, you wrote "(GOKb and EPKB to start)". Is EPKB the same thing as the ESSCO KB we've been using up till now (and usually abbreviating EKB)?

Comment by Khalilah Gambrell [ 25/Jul/18 ]

Mike Taylor - Yes EPKB is the same as EBSCO KB. We should probably stick with EBSCO KB for Folio purposes. Charlotte Whitt, I scheduled a meeting with Theodor for 7/31. Do you want to be a part of that meeting?

Comment by Cate Boerema (Inactive) [ 25/Jul/18 ]

Sorry - will use "EBSCO KB" from now on!

Comment by Charlotte Whitt [ 25/Jul/18 ]

> I scheduled a meeting with Theodor for 7/31. Do you want to be a part of that meeting?
Hi Khalilah Gambrell, yes that would be great. Thanks

Comment by Charlotte Whitt [ 31/Jul/18 ]

Follow-up:
Chalmers expectation is that EBSCO KB is integrated in Codex. Theodor Tolstoy (One-Group.se) confirmed that it would be okay with Chalmers that the integration of GOKb into Codex, can wait with 1 year. I'll change the ranking accordingly.

Comment by Owen Stephens [ 25/Jan/19 ]

My feeling is that we’ve now gone past this in terms of the ERM work, and that as a feature it is probably a bit broad to be useful going forward - as we probably want to look at integration of specific knowledgebases rather than just generally allow for integration

We already have:

https://folio-org.atlassian.net/browse/UXPROD-589 (GOKb integration)
https://folio-org.atlassian.net/browse/UXPROD-1465 (KBART integration)

as well as work under way to ensure eHoldings title-packages or packages can relate to Agreements, Licenses, POLs etc.

Unless there are objections I'll close this as "won't do" with a comment that we need to describe specific integrations where required

Comment by Charlotte Whitt [ 25/Jan/19 ]

Hi Owen Stephens - as we discussed on Slack, this UXPROD is from the original roadmap spreadsheet by Hkaplanian, and the ERM work has moved in a new direction, and things have changed since the initial roadmap was defined.
I definitely support what you suggest in the comment above. So please go ahead and close this UXPROD-148 Closed .

Comment by Hkaplanian [ 25/Jan/19 ]

IS the assumption that the eHoldings app can handle KBs outside of GOKb for libraries that want a direct connection to KB data? This is specifically about references and not copying or importing records which is very different from UXPROD-589 Closed & 1465.
I would just remove the "ERM" tag since that has come to represent the GVB/OLE effort. I would not close it as there will still be work ongoing in this area.

Comment by Owen Stephens [ 25/Jan/19 ]

Hkaplanian the assumption is that eHoldings app can handle KBs that support the necessary API(s) to interact with eHoldings.

In terms of the rankings from early adopters presumably they are looking for specific integrations rather than a general ability? Wouldn't expressing those requirements give us a clearer set of priorities to work towards?

I'm just not clear on the value of having this open as an issue - how will we know when it is complete?

Comment by Hkaplanian [ 25/Jan/19 ]

Owen Stephens, I can live with that. Lets close it.

Comment by Cate Boerema (Inactive) [ 22/Mar/19 ]

Removing all but the essential features from the Q2 2019 Core Functional team backlog. After we've run the estimates through the cap plan, we may find we can pull in more.

Comment by Cate Boerema (Inactive) [ 09/Apr/19 ]

Switching the resolution from done to won't do so this doesn't clutter up our reports. See comments from Owen and Harry above for why this issue was closed.

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