UI for searching both print and e-resources (local and KB). This narrative is intended to cover goals for alpha.
The initial (alpha) scope for the Codex Search App is to prove the concept of searching across electronic and print knowledge bases, and to provide practical experience with the Codex in general. It is to inform further inquiry and UX exploration by the SIGs and their subgroups, and to illuminate technical and usability issues. It is a candidate first version of a global title-level (instance) search function for FOLIO, but it is not intended to be the 'final' version. It is a stepping stone.
The Codex Search app will initially search across physical and electronic resources through a broadcast search technique. Queries will be broadcast in parallel to X different sources, all of which are required to comply with a common contract (data models and a set of traits). This common contract must be defined. It comprises initially:
o Schemas o Traits (searchable, pageable) o A set of required search fields, i.e. title, author, publication-date, identifiers, publisher o A set of required facets, ie title, author, date of publication. o A set of required sort options (specified as primary, secondary, tertiary sort field) o Description of search behaviors and options, i.e. keyword vs. substring search, left-anchored or full-field match options, truncation/pattern options, phrase vs AND-list behaviors. These should be described in terms of CQL capabilities. Boolean operations supported. A pragmatic initial set of functions for alpha would be AND/OR/NOT booleans, keyword searching including un-anchored phrase searching, simple word-level truncation.
The function of the codex search app is to issue searches to multiple sources, and to combine the results into a single display. Initially, the display will be limited to instance level metadata as per the codex data model.
Merging
Two kinds of 'merging' are potentially in scope for the search app as incoming results are processed: Instance level and work level. For alpha, the focus should be on instance-level merging – i.e. if instance-level records from different sources can be reasonably determined to represent the same instance, they should be combined for summary display purposes. The rules for doing this should ultimately be configurable and may include looking at identifiers and/or combinations of other fields (material type, title, author, publication dates).
Display of related information
When displaying instances, it is meaningful to display related entities in the context of the detailed display, specifically packages and holdings/items.
Display of more detailed information pertaining to an instance
For alpha, it should be acceptable to direct the user to the app whence the metadata originated, if the user asks to 'see more' or to 'edit' the instance or related entities. As further refinement, richer inline displays or edit functions may in some cases be possible through widgets, but this is out of scope for alpha.
The app should display related entities (similar to how the users app shows loans and permissions), SPECIFICALLY related packages and holdings/items.
PRIORITY CONSIDERATIONS
In terms of timing, simple keyword searching can be implemented for the first sprint, but sorting is fairly important. Displaying instance information is the first priority, but the display of related information (holdings/packages) should be included as early as possible, as should links to the resource-specific app. Merging can be left to a later sprint, and can be progressed incrementally.
UI for searching both print and e-resources (local and KB). This narrative is intended to cover goals for alpha.
The initial (alpha) scope for the Codex Search App is to prove the concept of searching across electronic and print knowledge bases, and to provide practical experience with the Codex in general. It is to inform further inquiry and UX exploration by the SIGs and their subgroups, and to illuminate technical and usability issues. It is a candidate first version of a global title-level (instance) search function for FOLIO, but it is not intended to be the 'final' version. It is a stepping stone.
The Codex Search app will initially search across physical and electronic resources through a broadcast search technique. Queries will be broadcast in parallel to X different sources, all of which are required to comply with a common contract (data models and a set of traits). This common contract must be defined. It comprises initially:
o Schemas
o Traits (searchable, pageable)
o A set of required search fields, i.e. title, author, publication-date, identifiers, publisher
o A set of required facets, ie title, author, date of publication.
o A set of required sort options (specified as primary, secondary, tertiary sort field)
o Description of search behaviors and options, i.e. keyword vs. substring search, left-anchored or full-field match options, truncation/pattern options, phrase vs AND-list behaviors. These should be described in terms of CQL capabilities. Boolean operations supported. A pragmatic initial set of functions for alpha would be AND/OR/NOT booleans, keyword searching including un-anchored phrase searching, simple word-level truncation.
The function of the codex search app is to issue searches to multiple sources, and to combine the results into a single display. Initially, the display will be limited to instance level metadata as per the codex data model.
Merging
Two kinds of 'merging' are potentially in scope for the search app as incoming results are processed: Instance level and work level. For alpha, the focus should be on instance-level merging – i.e. if instance-level records from different sources can be reasonably determined to represent the same instance, they should be combined for summary display purposes. The rules for doing this should ultimately be configurable and may include looking at identifiers and/or combinations of other fields (material type, title, author, publication dates).
Display of related information
When displaying instances, it is meaningful to display related entities in the context of the detailed display, specifically packages and holdings/items.
Display of more detailed information pertaining to an instance
For alpha, it should be acceptable to direct the user to the app whence the metadata originated, if the user asks to 'see more' or to 'edit' the instance or related entities. As further refinement, richer inline displays or edit functions may in some cases be possible through widgets, but this is out of scope for alpha.
The app should display related entities (similar to how the users app shows loans and permissions), SPECIFICALLY related packages and holdings/items.
PRIORITY CONSIDERATIONS
In terms of timing, simple keyword searching can be implemented for the first sprint, but sorting is fairly important. Displaying instance information is the first priority, but the display of related information (holdings/packages) should be included as early as possible, as should links to the resource-specific app. Merging can be left to a later sprint, and can be progressed incrementally.