Table of Contents
This refines the use cases with a focus on user stories for each use case.
See also: Initial Use Case Definitions - Search API Best Practices for Authoritative Data Working Group
Use Case: User wants to find the URI of an entity from within a metadata editor
As a cataloger, I want to edit an entity (e.g. work, instance, etc.) and add metadata about the entity from authoritative sources (e.g. LCNAF, OCLC FAST, etc.).
As a cataloger, I know exactly the authoritative term I want to add as metadata about an entity.
As a cataloger, I know the start of the label of the authoritative term I want to add as metadata about an entity.
As a cataloger, I know some keywords that will help me locate and select an authoritative term to add as metadata about an entity.
As a cataloger, I want to see context about an authoritative term that increases the accuracy of selecting the correct authoritative term.
As a cataloger, I want to be able to filter search results to a specific date range for a field on the authoritative term (e.g. birth date, death date, etc.)
As a cataloger, I want to be able to filter search results to a specific class type (e.g. ???)
As a cataloger, I want to be able to filter search results to a specific language
As a cataloger, I want search results to be returned quickly, such that, performance times do not detract from the cataloging workflow.
As a developer, I want to provide a widget that enables a cataloger to select a term from an authoritative source using left anchored autocomplete.
As a developer, I want to provide a widget that enables a cataloger to type in keywords and see a list of terms sorted in rank order.
As a developer, I want to provide additional information about terms to facilitate the accuracy of selection.
As a developer, I want to quickly return search results (e.g. sub-second, specific threshold TBD)
As a provider, I want my data to be used.
As a provider, I want to support the creation of application widgets that provide access to our data.
As a provider, I want our API(s) to be performant (e.g. sub-second queries, specific threshold TBD)
As a provider, I want catalogers to be able to make an accurate selection.
As a user of a metadata editor application, I want to find an entity in an outside authority to use as metadata in a local record.
Share Key Concepts:
- primary label
- Authority entities are expected to have a primary label that is a human readable representation of the entity.
- relevant information
- This will include the primary label of the entity.
- This likely will include other information from the entity referred to as extended context.
- accurately select
- This relates to the user's ability to disambiguate similarly labeled entities based on the information provided in search results.
Sub-Use Case: User knows keywords related to an entity (aka Keyword Search)
As a user of a metadata editor application, I want to type in keywords and be presented with a list of relevant information that allows me to accurately select an entity to use as metadata in a local record. The entity is expected to be in the top X (e.g. 5, 8, 10, 20) results, but may be lower in results requiring the ability to access more results.
Sub-Use Case Key Concepts:
- accurately select
- This assumes that search results will be in rank order with the highest ranked search results appearing first for Keyword Search
- access more results
- When the desire entity is not in the set of results presented, there needs to be a way for the user to access more results (e.g. pagination)
Sub-Use Case: User knows the primary label and starts typing it from the first character (aka Left Anchored Search)
As a user of a metadata editor application, I want to type in the primary label and be presented with a list of relevant information that allows me to accurately select an entity to use as metadata in a local record. The entity is expected to be the top result in almost all cases.
Sub-Use Case Key Concepts:
- accurately select
- This assumes that search results will be in alphabetical order for Left Anchored Search
Example: Fill in $0 MARC field with LOC label search.
Influencing results
- Filter - limit by date ranges, class type, date of birth, language etc.
- Extended Context vs. Filter
- Language filtering can greatly change results
- Fields to search
Cache of entire or significant portion of dataset with updates via retrieve a known concept using a consistent format across datasets
- local search of cached data
- have the URI and want to get details about that term
- get most recent version of data for that URI
- go across multiple authorities
- consistent data access pattern across authorities to get the data
See also update of cached data
Update cached data
- LOC has ATOM feeds that indicate what has changed
Batch processing
Auto-fill with a batch process
- background process that occurs across data
Manual batch processing
- reconciliation through open refine - need to filter by date range
