...
Use Case: User wants to find the URI of an external entity from within a metadata editor
The Metadata Editor Use Case assumes that all users are English speakers and that searching they are searching for items written in English. See Language Processing Use Case below for language specific user stories.
| Required? | User Story | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Catalogers | |||||||||
| NOTE: The following user stories are related to creating or editing resource descriptions typically within a metadata editor or similar application. | |||||||||
| MUST HAVE | As a cataloger, I want to edit an entity (e.g. work, instance, etc.) and add a link to an external URI from an external authoritative sources (e.g. LCNAF, OCLC FAST, etc.). | ||||||||
| MUST HAVE | As a cataloger, I want to edit an entity (e.g. work, instance, etc.) and display a label from an external authoritative sources (e.g. LCNAF, OCLC FAST, etc.). | ||||||||
| MUST HAVE | As a cataloger, I want to be able to enter the exact external authoritative label and get the URI from the external authority linked to the entity being edited. This applies when there is a unique authoritative term. | ||||||||
| MUST HAVE | As a cataloger, I want to start typing a known external authoritative label and get the URI from the external authority linked to the entity being edited. This is left anchored type-ahead. | ||||||||
| MUST HAVE | As a cataloger, I want to start typing a known variant external authoritative label and get the URI of the authoritative label linked to the entity being edited. | ||||||||
| MUST HAVE | As a cataloger, I want additional information in the search that indicates that the term listed has a variant that matches the keyword typed. | ||||||||
| MUST HAVE | As a cataloger, I want to type in the alternate identifier (e.g. Q label in wikidata, ISNI label, organization code etc.) and get the URI for those entities. | ||||||||
| OPTIONAL | As a cataloger, I want to be able to search for a broader term in a hierarchy and get a list of narrower terms from which to select. NOTE: Some systems have seen performance issues in actual implementations. Catalogers generally know what they are looking for. | ||||||||
| OPTIONAL | As a cataloger, I want to be able to see broader and narrower terms when the authority is hierarchical. | ||||||||
| OPTIONAL | As a cataloger, I want to be able to step into broader or narrower terms when the authority is hierarchical. | ||||||||
| As a cataloger, when I am unable to find what I'm looking for in an authority lookup, I want to be able to search an authority source in an external site by clicking on a link to its native search UI. | |||||||||
| As a cataloger, I know some keywords, other attributes related to the entity that are not in the primary or variant label (e.g. occupation, resource type, etc.), that will help me locate and select an authoritative entity. | |||||||||
As a cataloger, I want search results to contain highly relevant terms for my keyword search based on standard indexing approaches. Actual relevancy is subjective. | |||||||||
| As a cataloger, I want transparency in the approach for indexing to be clear. (e.g. exact match on primary label, stemming, which fields are searched, etc.) May vary between authorities. | |||||||||
| As a cataloger, I want search results listed in rank order as determined by standard indexing approaches. | |||||||||
| As a cataloger, I want to choose how search results are returned (e.g. left anchored, keyword indexing rank, or as yet unknown approach) | |||||||||
| As a cataloger, I want to see, for each entity that appears in results of my keyword search, which of the fields that were searched triggered its inclusion in those results. (e.g. keyword was in the variant label, occupation, or descriptions instead of the primary label) | |||||||||
| As a cataloger, I want to see contextual information (e.g. variant labels, occupation, birth date, etc.) about the search results that distinguishes it from other, similar-looking results, to help me to select the correct authoritative entity and to recognize false positives. The context may be drawn from authoritative entities and real world object entities based on what is available in the authoritative data. | |||||||||
| As a cataloger, I want to be able to filter search results to a specific date range for a field on the authoritative entity (e.g. birth date, death date, floruit, etc.). | |||||||||
| As a cataloger, I want to be able to filter search results to a specific class type (e.g. a corporate name, person name, meeting name, etc.; manifestation, item, expression, etc.). | |||||||||
| As a cataloger, I want to be able to filter on specific fields in the search results | to the language of the resource(e.g. | The book is written in Greek and I want to see the information displayed in Greek.) The user types in Greek and expects to find the Greek version of the title. May type non-Greek, but still want to have access to the Greek terms. This is complex and may need UI mockups that capture potential cases. Part of the results for this may be described by identifying which field triggered the results. May be good to have a UI widget that allows for filtering after the results are returned. May need User Studies to determine how best to do this. Want to lookup in a language I know but need to include a label in a language I do not know well. While cataloging works, the work may be in another language and need to be sure I've cataloged the one in the correct language. It would be good to collaborate with non-roman script working group to see what their use case is for this. For LOC, if the user searches in Greek, they will get Greek results back. Nearly all subject headings, names, lookups in general, they are all in English. The suggest search does not search variant labels. This can limit results that are returned.As a cataloger, I want to type in a keyword in French, the authority only searches values in French, and get results back in French. This may impact stop words and other indexing implementations. | As a cataloger, I want to see search results in my preferred language generally set through browser's preferred language settings, application settings, or passed as a parameter (e.g. I speak German and want to see results in my native language.) This is dependent on the authority having data in that language. | As a cataloger, I want to be able to filter on specific fields in the search results (e.g. occupation, resource format, agent, etc.) This is a filter of results after they are returned similar to a facet. | As a cataloger, I want to be able to specify in the search limiting results to a keyword in a particular field (e.g. an advanced search that passes in 'occupation includes humorist'). | As a cataloger, I want search results to be returned quickly, so that I can catalog efficiently, generally seen as sub-second results or some indicator that a longer search is being processed. | As a cataloger, I want to be able to request additional search results if what I am looking for isn't visible in the current set of results displayed, e.g. I didn't get it in the first 10, so give me 10 more results (aka pagination). | As a cataloger, I want to determine whether the entity I'm searching for doesn't exist in the authoritative source that I'm searching. Perhaps stating No Result Found indicating the search completed and there were no results, or No Exact Match Found when this was an exact match? Christine Fernsebner Eslao Can you confirm this is an adequate description? It may not be possible to definitively state that the entity doesn't exist. May need to redirect to the source authority to do a search there to confirm whether or not the desired entity exists. | |
| Developers of Application UIs | As a developer, I want to be able to display the human readable label in the end user's native language (e.g. the user speaks Korean and want to display label in Korean). How does this differ from the cataloger's user case? As a developer, we need to be able to distinguish between how to display this to the user. How to allow user to select different languages? These seem more user interface oriented than API access by developers. Perhaps, this is more of a cataloger user story. The user story for the developer is that I want to be able to pass additional data in a parameter to the API that allows the authority provider to act on requests that limit the language of results returned. There may be other parameters passed through to the API that control results. As an API developer, I want a consistent way to specify parameters that is the same for all authorities. Want to avoid one off code requiring if-then-else processing. As an API developer, I want data returned in a consistent way across all authorities. | As a developer, I want to be able to facilitate a user searching for things that are stored in a different language as the primary language. (e.g. book was written in Greek) | As a developer, I want to receive a permanent URI for each entity to uniquely identify the entity. | As a UI developer, I want to provide a widget that enables a cataloger to select an entity from an authoritative source using left anchored autocomplete. As a UI developer, I want to be able to query the authority provider to determine if it supports a left anchored autocomplete. (e.g. LOC has an SRU explain document that lists what is supported) As an API developer, I want to programmatically request how the API supports data to be searched as an exact match on preferred label with results returned in alphabetical order. As an API developer, I want to have documentation describing the capabilities of an authority and how to access it. This will be nice, but not required. Not all data makes sense as to have left anchored. For applications, this might not be the same for all authorities. Are we confusing a UI widget with API requirements? What are we asking for in the API? . State a number of approaches we want the UI to be able to support. | As a UI developer, I want to provide a selection widget that enables a cataloger to type in keywords and see a list of entities sorted in rank order. As a backend developer, I want to call a provider API passing keywords in a parameter and receive results sorted by rank order. As a backend developer, I want to receive search results in the same format for all authorities (e.g. json-ld) | As a UI developer, I want to provide additional information in the selection widget about entities to improve the accuracy of selection. As a backend developer, I want to receive additional information about an entity in the same predictable format for all authorities (e.g. json) | As a developer, I want to quickly show search results to users (e.g. sub-second, specific threshold TBD) | As a UI developer, I want the selection widget to allow the user to ask for more results (i.e., page through results). As a backend developer, I want to receive pagination information with search results, such that, I can request the next page of results. As a backend developer, I want to receive pagination information following a standard (e.g. | As a developer, I want data to be returned as linked data allowing for configurations that map ontologies to a normalized json format. | As a developer, I want data to be returned in the same format from all authorities (e.g. normalized json, json-ld, or something else) | As a developer, I want to be able to fulfill all search requests. (e.g. source authorities respond to all requests with excellent uptime) |
| Developers of Backend API Access | As a developer, I want to update cached labels and URIs as changes are made to the authoritative source data. | As a developer, I want to receive search results with a filter applied. (e.g. date range, class type, language, arbitrary field) | |||||||
| Providers | As a provider, I want my data to be used. | As a provider, I want my data to be used accurately. | 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 access to our data to be available 24-7 with occasional outages for maintenance that will be announced in advance. | As a provider, I want to provide data for download facilitating local caching. | As a provider, I want to keep download files up to date. Need to define and publish expectations of reasonably up to date: quarterly, monthly, weekly, or daily | As a provider, I want to be able to provide partial downloads with only modifications since last download update. | As a provider, I want to provide notifications of changes to data (e.g. new, deleted, deprecated, moved, split, and merged entities)|
| occupation, resource format, agent, etc.) This is a filter of results after they are returned similar to a facet. | |||||||||
| As a cataloger, I want to be able to specify in the search limiting results to a keyword in a particular field (e.g. an advanced search that passes in 'occupation includes humorist'). | |||||||||
| As a cataloger, I want search results to be returned quickly, so that I can catalog efficiently, generally seen as sub-second results or some indicator that a longer search is being processed. | |||||||||
As a cataloger, I want to be able to request additional search results if what I am looking for isn't visible in the current set of results displayed, e.g. I didn't get it in the first 10, so give me 10 more results (aka pagination). | |||||||||
As a cataloger, I want to determine whether the entity I'm searching for doesn't exist in the authoritative source that I'm searching. Perhaps stating No Result Found indicating the search completed and there were no results, or No Exact Match Found when this was an exact match? Christine Fernsebner Eslao Can you confirm this is an adequate description? It may not be possible to definitively state that the entity doesn't exist. May need to redirect to the source authority to do a search there to confirm whether or not the desired entity exists. | |||||||||
| Developers of Application UIs | |||||||||
As a developer, I want one field in the authoritative entity to be a human readable, meaningful representation of the entity that can be displayed to users to identify the entity for selection. The challenge here may be the difference between an authoritative source and an identity management system. For example, ISNI does not provide a display label. The question is who is responsible for creating a meaningful label. Do we need "a" label or "the" label? Example, VIAF has multiple labels in varying scripts. Do you request label in a particular script? Example, label for a work that identifies that work may need to include contributors in addition to the title. One way to address the need for additional data to be able to make a decision is to include additional context along with the identified human readable label that are displayed in separate fields as opposed to a single joined data field. The label likely won't be unique. Are we making a distinction between authority management system where there is an authorized access point that has a preferred unique label and other approach where data may not be standardized? This includes some of the discussions from last time around language issues where the user's native language may be different (e.g. speaking Korean). How to support switching languages? | |||||||||
As a developer, I want to be able to display the human readable label in the end user's native language (e.g. the user speaks Korean and want to display label in Korean). How does this differ from the cataloger's user case? As a developer, we need to be able to distinguish between how to display this to the user. How to allow user to select different languages? These seem more user interface oriented than API access by developers. Perhaps, this is more of a cataloger user story. The user story for the developer is that I want to be able to pass additional data in a parameter to the API that allows the authority provider to act on requests that limit the language of results returned. There may be other parameters passed through to the API that control results. As an API developer, I want a consistent way to specify parameters that is the same for all authorities. Want to avoid one off code requiring if-then-else processing. As an API developer, I want data returned in a consistent way across all authorities. | |||||||||
| As a developer, I want to be able to facilitate a user searching for things that are stored in a different language as the primary language. (e.g. book was written in Greek) | |||||||||
| As a developer, I want to receive a permanent URI for each entity to uniquely identify the entity. | |||||||||
As a UI developer, I want to provide a widget that enables a cataloger to select an entity from an authoritative source using left anchored autocomplete. As a UI developer, I want to be able to query the authority provider to determine if it supports a left anchored autocomplete. (e.g. LOC has an SRU explain document that lists what is supported) As an API developer, I want to programmatically request how the API supports data to be searched as an exact match on preferred label with results returned in alphabetical order. As an API developer, I want to have documentation describing the capabilities of an authority and how to access it. This will be nice, but not required. Not all data makes sense as to have left anchored. For applications, this might not be the same for all authorities. Are we confusing a UI widget with API requirements? What are we asking for in the API? . State a number of approaches we want the UI to be able to support. | |||||||||
As a UI developer, I want to provide a selection widget that enables a cataloger to type in keywords and see a list of entities sorted in rank order. As a backend developer, I want to call a provider API passing keywords in a parameter and receive results sorted by rank order. As a backend developer, I want data to be returned in the same format from all authorities (e.g. normalized json, json-ld, or something else) As a backend developer, I want data to be returned as linked data allowing for configurations that map ontologies to a normalized json format. | |||||||||
As a UI developer, I want to provide additional information in the selection widget about entities to improve the accuracy of selection. As a backend developer, I want to receive additional information about an entity in the same predictable format for all authorities (e.g. json) | |||||||||
As a backend developer, I want to pass filtering requests to provider API and receive search results with the filter applied. (e.g. date range, class type, language, arbitrary field) As a backend developer, I want to receive enough data from the provider to be able to apply a filter in the application layer. (e.g. date range, class type, language, arbitrary field) | |||||||||
As a UI developer, I want the selection widget to allow the user to ask for more results (i.e., page through results). As a backend developer, I want to receive pagination information with search results, such that, I can request the next page of results. As a backend developer, I want to receive pagination information following a standard (e.g. JSON-API Pagination) | |||||||||
| Developers of Backend API Access | |||||||||
| As a backend developer, I want to be able to fulfill all search requests. (i.e. source authorities respond to all requests with excellent uptime) | |||||||||
| As a backend developer, I want to quickly show search results to users (e.g. sub-second, specific threshold TBD) | |||||||||
| As a backend developer, I want to update cached labels and URIs as changes are made to the authoritative source data. | |||||||||
| Providers | |||||||||
| As a provider, I want my data to be used. | |||||||||
| As a provider, I want my data to be used accurately. | |||||||||
| 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 access to our data to be available 24-7 with occasional outages for maintenance that will be announced in advance. | |||||||||
| As a provider, I want to provide data for download facilitating local caching. | |||||||||
| As a provider, I want to keep download files up to date. Need to define and publish expectations of reasonably up to date: quarterly, monthly, weekly, or daily | |||||||||
| As a provider, I want to be able to provide partial downloads with only modifications since last download update. | |||||||||
| As a provider, I want to provide notifications of changes to data (e.g. new, deleted, deprecated, moved, split, and merged entities) | |||||||||
Language processing for Metadata Editor Use Case
Processing of language is complex. It has been extracted out into a separate use case. These user stories still relate to user stores for a Metadata Editor.
| Required? | User Story |
|---|---|
| Catalogers | |
| As a cataloger, I want to be able to filter search results to the language of the resource (e.g. The book is written in Greek and I want to see the information displayed in Greek.) The user types in Greek and expects to find the Greek version of the title. May type non-Greek, but still want to have access to the Greek terms. This is complex and may need UI mockups that capture potential cases. Part of the results for this may be described by identifying which field triggered the results. May be good to have a UI widget that allows for filtering after the results are returned. May need User Studies to determine how best to do this. Want to lookup in a language I know but need to include a label in a language I do not know well. While cataloging works, the work may be in another language and need to be sure I've cataloged the one in the correct language. It would be good to collaborate with non-roman script working group to see what their use case is for this. For LOC, if the user searches in Greek, they will get Greek results back. Nearly all subject headings, names, lookups in general, they are all in English. The suggest search does not search variant labels. This can limit results that are returned. | |
| As a cataloger, I want to type in a keyword in French, the authority only searches values in French, and get results back in French. This may impact stop words and other indexing implementations. | |
| As a cataloger, I want to see search results in my preferred language generally set through browser's preferred language settings, application settings, or passed as a parameter (e.g. I speak German and want to see results in my native language.) This is dependent on the authority having data in that language. | |
| Developers | |
| Providers | |
Cache of entire or significant portion of dataset with updates via retrieve a known concept using a consistent format across datasets
...