Use Cases - EMWG 2020, 2022

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.

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)

TP: what is meant by external datasets? Which data are considered internal v. external? Dangerous if not defined. What about the various data stores within FOLIO? Is external out of FOLIO or out of the current store?

JS: thesauri and authorized heading stores not maintained inside of FOLIO or by our community (e.g.: LCAuths, AAT, etc.).

LM: internal data store adjusted based on external data?

WS: underlying assumptions of use case is interesting. 1. there is a local dataset. 2. how are identifiers resolved in FOLIO? pointing to local dataset thats reconciled against external set?

JS: is this heading or dataset maintenance?

WS: is this about reporting? OR is this about authority/vocab maintenance? Probably this is not about reporting itself... that is a separate use case.

TP: passive reporting v. active reporting - should be clear when creating use cases around reporting.

UXPROD (s)? 

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.

Pulled from review of #1.  

Adjacent FOLIO systems/functions needed

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.

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.

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.

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.

Special Collections and Archives (SC&A) Home

National Strategy for Shareable Local
Name Authorities National Forum :
White Paper

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

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

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.  

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... ?