Page History

Refined to:  As a cataloger, I want to be able to search for a term and then make another search using a broader or narrower term for the original term as a new search term.

Original wording: 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.

Reason for change: It was felt by the group that the intent of the two statements is the same, but the wording of the refined version provided more clarity.

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 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 information displayed in the editor UI to match the information in the authoritative source.  This primarily impacts editing and displaying of entities where the data in the authoritative data has changed (e.g. split, merged, renamed, deleted) to be sure that cataloged data remains accurate over time.

As a UI developer, I want to provide a widget that shows search results that the end user can understand by displaying a representative label.  This is typically the preferred label of the resources in the search results, but not necessarily, notably in the case of identify management systems (e.g. ISNI, VIAF, etc.)

DISCUSSION: If, for example in ISNI, the representative label is the ISNI number, you would need additional context to be able to distinguish between entities.  As a UI developer, I want to show the user something and the user wants this to be understandable.  I don't want to have to create this differently for each authority.  In general, the response from the service should have not just the representative label, but also additional information.  Ex. if the user does a search and the search hits a variant, from the UI perspective, you want to help the user why they are seeing the results and how it came from the variant.

As a UI developer, I want to show users additional information (aka extended context) to help them make an accurate selection.

DISCUSSION: Not sure that authority provider can give rank order results, that it may be more appropriate for the application to allow the user to decide based on the extended context.

As a developer, I don't want to have to understand the extended context, I just want to display it to the end user.  I don't want to have to treat each service uniquely.

One way of handling differences between authority ontologies is to provide configurations identifying ldpath to each piece of extended context in the result graph.

As a UI developer, I want to provide the end user with a search interface based on the authority's ontology and allow the user to select which field they want to search.  (aka advanced search)

DISCUSSION: This implies some understanding of the unique aspects of each authority.  Perhaps a better approach would be to define what fields you want to search and connecting the fields of the ontology to the search fields.  This doesn't take advantage of the linked data aspect where the data could be more variable.  Are we asking for consensus at the data model level? Maybe we can abstract out some by mapping at the service level some common fields to the ontology of the authority.  ISNI approached this by using general ontologies (e.g. schema, skos) that allow for an easier way to come to common understanding of fields across multiple authorities.

As a backend developer, I want a consistent way to specify parameters that is the same for all authorities (i.e. standardized API request).  Want to avoid one off code requiring if-then-else processing.

As a backend developer, I want data returned in a consistent way across all authorities.  Minimally the data structure of extended context (e.g. lists, nested lists).  Are there non-textual data like images or

DISCUSSION: Having fields be structured the same is what is important.  We want to be able to display the results without needing to interpret them.  One exception would be to handle by datatype (e.g. image).

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) to allow for one processing approach for all authorities

There is a request for normalized json preferred over json-ld.

DISCUSSION: The last thing the developer wants is json-ld.  It is very difficult to work with.  Not always consistent json.  Querying RDF data is complicated.  A normal json structure is easily processed by most developers without special knowledge.  Inconsistent or bad libraries for dealing with json-ld.  Json-ld is not always constructed consistently making it difficult to process as simple json.

As a backend developer, I want to identify the search depth to follow in the broader graph in the authority (e.g. follow links up to 3 levels deep).  This has implications for performance if the levels are too deep.  The goal of this user story is to have authorities provide enough data to help the end-user make an accurate selection.

Ex. ldpath:  (madsrdf:hasAffiliation/madsrdf:organization/skos:prefLabel) | (madsrdf:hasAffiliation/madsrdf:organization/rdfs:label) | (madsrdf:hasAffiliation/madsrdf:organization/madsrdf:authoritativeLabel) :: xsd:string

As a backend developer, I want to receive results marked with a ranked order.  There are various approaches to do this in RDF (e.g. RDF sequence, identified by predicate, etc.)  This is typically driven by keyword search and produced by the provider's indexing approach.

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 pass the type (e.g. class, entity, or other type of classification field) to the provider API to filter search results.

As a backend developer, I want to receive pagination information with search results (e.g. first result position, last result position, current retrieved results count, total count in full result set), such that, I can request the next page of results.

As a developer, I (optionally) want to cache the display label of the selected entity to facilitate performant display of data later without having to retrieve it from the authoritative data source based on the URI.

As a UI developer, I want to return control of the application to the user in a reasonable amount of time when a search fails to return a result.

p-18

As a provider, I want to provide a representative label for each entity returned in search results.

DISCUSSION: 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?

DISCUSSION: 

• ISNI
  • Would not like to have a single representative label.  Would prefer provider to provide all information and the application would highlight relevant information returned from the API.  Example, if searching for author, know you want the author name from the ISNI response.
  • Language can complicate this.  And context can also complicate results.  Some names may be counter intuitive.
  • Searching at ISNI has a preference list that shows a label.  Challenge is very many optional elements in the data structure.
  • Potential solutions that impact provider API - 1) Have different views into ISNI with different configurations on the QA level (e.g. name focused)
  • Two types: person, organization
  • Field is easy to determine, but it may be repeated many times primarily in different languages.  The 'primary' is generally selected as English version.  Prefer LOC first, then VIAF.
  • Multiple contributors for a single entity.
  • Looking at API receiving a parameter that identifies a preferred language.
• Wikidata
  • Preferred label is selected in terms of language.  When you create something, you can specify a preferred label.  Otherwise all labels are equal.
  • By language labels.
  • In sparql queries can define language fallback chains.
  • There is a primary label for most entities, but there are a few that do not have labels in any language.  In that case, it defaults to the id.
  • Search - based on keyword search of label and aliases (alt label)
  • Display - label + fallback (language specific label or ID if not label)
• ShareVDE - preferred label is identified.  
• MeSH
  • NLM available in English only.  Others support in other languages, but not supported by NLM.
  • Has variant labels.
  • Have one preferred label and can have several variant labels.
• LOC
  • ID has both situations where in most situations there is a clearly defined preferred label in English.  Also has names which at not language tagged.  Some encode script, but not language.
  • In BF works and instances, there isn't a preferred label.  LOC does a constructed label for their own convenience so they don't have to compute the label downstream.  Created for their own use.
  • RWO may not have an unambiguous preferred label.
  • Suggest service provides label + URI.
  • Editor lookup shows multiple results from suggest server.  Hovering over a result shows a context modal with more information gathered with a second request.

As a provider, I may not be able to provide a human understandable label and will provide the URI instead in search results.  (See also p-18.)

As a provider, I want to supply the number of matching results (or possibly pages of results) (e.g. numFound=74 specified under meta when using json-api standard).