Under the auspices of the Entities Management Working Group, use cases have been developed to elucidate intended scope of work and provide a starting point for further discussion, refinement and development. Below are the use cases from this effort.
NOTE: use cases in the below table represent a first pass that was subsequently refined and imported into JIRA as issues UXPROD-2516 thru UXPROD-2526:
- - UXPROD-2516Getting issue details... STATUS
- - UXPROD-2517Getting issue details... STATUS
- - UXPROD-2518Getting issue details... STATUS
- - UXPROD-2519Getting issue details... STATUS
- - UXPROD-2520Getting issue details... STATUS
- - UXPROD-2521Getting issue details... STATUS
- - UXPROD-2522Getting issue details... STATUS
- - UXPROD-2523Getting issue details... STATUS
- - UXPROD-2524Getting issue details... STATUS
- - UXPROD-2525Getting issue details... STATUS
- - UXPROD-2526Getting issue details... STATUS
Currently, we are focused on the Metadata Management area of Entity Management. Other functional areas will be addressed in future iterations.
|Work Areas (brief)||Use case description|
FOLIO components affected
(notes with strikethrough text have been resolved or moved)
|Links to related material||Date added/Edited||2022 Review Notes from Use Case Group|
As a FOLIO user, I need tools that show changes, updates, deletes, non-matches within FOLIO in external datasets so that I can maintain information between systems and datasets in order to maintain accurate authorities.
Persona(s): User in metadata management role at a large research library.
Tracking changes in external data is critical for maintaining the currency and accuracy of locally stored data. The robustness of this feature and the kinds of workflows/queues it will support are dependent on the change information provided by data publishers. This feature would assist with maintaining labels and other data according to the expected data flows and indexing needs for for search and display of information in the FOLIO environment. (E.g. Assist with updating heading changes, deprecated entities, merges, splits in order to confidently search our collections)
External datasets are those such as LCSH; LCNAF, Wikidata, AAT, wikidata, etc.
Internal datasets are those that are stored in Inventory, SRS, LDP, etc. where data may be updated by external data changes, or simply be locally created and stored data.
|Inventory, SRS, Bibliographic editor (such as QuickMARC, future BibFrame editors, etc.)|
Not sure if this use case should be more granular, e.g. broken out into the separate actions like heading maintenance vs. deprecated headings. Or organized separately by data source since the information will be varied across the different APIs. (This note written in 2020; are there more granular use cases? Jacquie-2022)
Adjacent FOLIO systems/functions needed
To Do from 29Nov22 – need input from Steven and Christie. Need to look for where use cases need to be created for granularity.
Define assumptions, document various workflows, create granularity so that more/all types of scenarios can be related to specific workflows.
|9.||I need tools that show me where relationships have changed in a related external dataset. This is about the reports that are generated on local actions that may need to be taken, what watch recording for Christie's comment here||Persona(s): User in metadata management role at a large research library.|
Pulled from review of #1.
Adjacent FOLIO systems/functions needed
|2.||As FOLIO user I want entity lookups incorporated into data input forms (cataloging forms) to previously identified datasets so that I can easily reuse existing external descriptions.|
For fields in input forms that expect to refer to external entities/vocabularies, provide lookup services that allow searching and selecting existing entities. "Selection" in this context would mean storing an identifier/URI for the entity and any other information FOLIO would need to function.
To build out related features, we will need to ways configure which datasets are appropriate for specific fields.
|Inventory, Cataloging Tools|
CW: MARCcat already doing this when linking to authority data?
TP: UC seems less the ability to only look up the authority file but also external sources. Only internal or also external search during cataloging workflow?
WC: read use case as external. LM: agree. Also add a column for data source (re: internal, external)
JK: may include internal. Reading this as the QA use case.
|3.||Support BIBFRAME and other entity-based data models||Need to understand where to manage entity-based data models where, e.g.: Works, Instances, Items (in BF model) are managed.||Inventory, Entities Store, non-existent RDF-SRS, non-existent RDF-editor|
JS: important to include in a use case. Will need to break down into more granular use cases – but without framework it is difficult to say how to break into other use cases.
WS: need to be aware of differences moving from record-focused to entity-focused data models. JS: even though we dont have a flat-record, data exposing to patrons in discovery later is the data around entity that transfers. Need a work like record to convey concept.
CW: need to break into several use cases but also need to describe what kinds of tasks ahead of us. one of which is how are we modeling work in the existing Instance, Holdings, Items and Container structure in Inventory. Create new diagrams illustrating this better!!!
TP: there was an empty box in early FOLIO diagrams with an empty box for BF. IS that the intention here? OR something cross-FOLIO apps? JAK: take one-entity-at-a-time... Works may have different use cases than bf:Instance/bf:Item or other entities.
JH: in Voyager, have ItemID and HoldingID; surprised working on app dev that we don't have ItemIds in FOLIO. CW: we do; for Items and Holdings, UUIDs exist as well as HRID. These are being passed between apps.
SF: "support" is an interesting technology conversation
CT: specific needs: have book in hand and need to circulate. All i have is a Sinopia-created bib description. How do i circ that book in FOLIO? This is concrete way of thinking about this. Good to remind: not about specific data model, ontology or technology... management may need to be different based on institution. how do we enable flexibility in this area?
JS: make it possible to use various data models... and that the system does not write this off because it is different.
CW: this would is a proof-of-concept to demo how FOLIO's data model can support beyond MARC.
|4.||As a FOLIO user I would like to create entities locally when the entity is not available from an external source. I would like this locally created entity to be shareable.||An example of the need for locally created entities comes when institutions departments are identified in various collections such as institutional repositories and local digital collections. If FOLIO could provide at the least an institutional hub extending an API to various external systems used for collections outside of the library's traditional catalog, and perhaps further, it would help to unify these terms internally.||Inventory? Entities Store?, unspecified API|
LM: dream of organizing internal, locally-specific data to keep consistent within institution but also larger goal to have entities discoverable to other libraries. Might be two use cases.
JAK: like the external focus of this use case – publishing
WS: Fedora has a native LD publishing functionality. Are we talking about expanding scope of FOLIO to include that sort of functionality?
JAK: QA has some documentation for data producers; JS: NISO open data initiative guidelines - leverage that work
JAK: 2 use cases - managing internal data is one; publishing out is two.
|5.||IFLA Library Reference Model (LRM) User Tasks Support|
The IFLA Library Reference Model (LRM) : "defines five user tasks (Table 1) and lists the goals users want to reach when performing the tasks. The term resource is used in its broadest sense, meaning an instance of any entity defined in the model. The tasks are listed in an order that reflects typical user behaviour, which does not mean that all tasks need to be performed and that they cannot be repeated. Particularly identify and obtain often occur in parallel and in interaction."
JH: discovery focused as a lot of the other use cases are library staff focused. Interested in studying whether interfaces with LD elements are meeting LRM tasks. This is a baseline of why we need to model in the first place.
LM: happy discovery was raised as it is the essential point of this.
TP: when we speak about discovery, FOLIO is not interested in discovery functions. Is FOLIO starting to think of a discovery tool? Hard to consider the LRM model without first understanding the foundations of discovery in FOLIO
CW: early implementors are thinking of this and are testing what discovery will look like.
JS: when we say discovery, talking about patron discovery. but there is also discovery within FOLIO for staff. Should be explicit about distinction
CT: I think it is important to remember that though FOLIO will not have a UI for patron discovery, FOLIO will be the point that many of us use to manage the descriptive metadata that is sourced by our discovery layers and thus used for discovery. We can consider whether FOLIO can support the data as it is required by our discovery layers.
Discussion around discovery: the purpose has been blurred and FOLIO is indeed about discovery of our resources. Both for our staff as well as storing/operating data for discovery layers
|6.||Distributed storage of entities||Identify workflows and ecosystem when entity data exists both within and outside of FOLIO - with those outside manifesting purely as links|
JAK: change to "with those outside possibly manifesting purely as links"
LM: what is difference between #6 (storage) and #2 (lookups)? These are different but tie into the external and internal. CT: fine line but this is more expansive than #2
WS: #2 is focused on metadata entry; #6 encompasses where we go to get data for a contributor to display
CT: not sure if separate work area or nuanced aspect of #6... Chicago discussed Works and LCHubs and SHARE-VDE Opus, BF Work, LRM Work... lots of different types of works and they are different and allow diff functions. How do those ingesting these varied data know which kind of Work entity something is?
SF: interesting point about handling different data models. This is important to add as another use case (action item)
JH: proposed SHARE-VDE work entities use theoretic work modeling... entity work sets rather than just a Work entity. Not seeming to be pursued in SVDE now....
JS: Opus is the kinds of things we're talking about as superwork and hub...
JAK: abstraction within FOLIO... having a data model within FOLIO that facilitates maneuvering across these almost-kinda-like data models
TP: scope of this is concerned about recon of entities within FOLIO and outside. Is use case to reconcile the various kinds of models, e.g., or is this more concrete specifically how do we reconcile entities
|7.||Reporting of unmatched entities||Reports to identify which fields in whatever SRS are not 'controlled' - and look-up tools to facilitate remediation|
SF: this is definitely in the space of how imagine reporting features in #1. Anything that manages controlling headings/entities, updating them. Interested in this space. Will be important for data stored locally. Interesting question: will FOLIO assume control over all entities? Are we expecting a URI for every "thing"?
CT: interested in understanding what will happen as part of migration (e.g.: with MARCcat expecting a controlled heading, what happens to data without?). At Chicago: maintenance happens outside of cataloging workflows. How will this work with batch processes for assigning URIs and making those URIs available to discovery environment?
CW: interesting to have developer perspective in this conversation. Sebastian can speak on harvesting. Per-tenant discussion with each considering different sources.
JS: need ability to find all unmatched entities to facilitate matching them to the thesauri we want to match these to, per institution.
|8.||As a FOLIO User in Metadata Management, I would like to place a request on any instance of a work so that I can update/maintain metadata.||Requests are currently instance/item based when we have other instances that reflect materials that would satisfy a user request. If works are known to FOLIO, then it is possible that requests could be placed on a cluster of instances so that patrons receive their materials in a more timely manner.|
CT: use case served by having a work entity internal to FOLIO. discussed locally albeit not recently. There must be a better way to do requests. By nature of what requires a new record... and how records are related is not the best. Request is on a very particular title... and often the idea that something is paperback v. hardcover v. whatever... may not matter. This is an on-the-ground example of where Work entity may benefit patrons.
WS: gets at the distinction between areas of work in FOLIO governance structure... this is RA and MM. This group's purview expands metadata modeling... and not sure how it fits into our work. This is cross-SIG. If we're not going to silo ourselves, need to recognize that we have impact on others.
CW: from early on in inventory, had related instances thinking... with accordion to capture. We've been touching on this use case in the MM-SIG. Interesting thing is how can the system support how to capture and act on these data? Can have match algorithm to offer possible related instances.
LM: statistics based on item regardless of edition. Another reason to join works together.
SF: for this concern about diff parts of app, is it enough to add values to FOLIO components affected column?
TP: if we have multi-tenant, what we mean for work and related instances? is work for all tenants together? or is each tenant managing their own work? Thinking to services... single library or inter-library loan.
WS: resource sharing use cases TP just raised. ReShare group is doing some algorithmic mapping of instances from different instances from diff FOLIO installations. Problem needing to be solved.
JAK: HathiTrust... wanna use those data. CW: shareable Hathi-specific Inventory
CW: perpetua's use of codex search...! JAK: should this be a separate use case?
WS: work happening in RESHARE around shared Inventory harvesting. RESHARE harvests all data from participating institutions into a single "shared index". Could be prior work to leverage
JS: Shared Index work is based on TRLN shared index... ?