Skip to end of metadata
Go to start of metadata

Overview of "Advanced Resource Search-Deprecated" Use Case

Search data and other resources using meaning, along multiple user-ordered axes Moved to R3, not in R2 scope

Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All


Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Actors OOI Science User
Is Used By  
Extends UC.R2.24 Search for Resource
Is Extended By  
Technical Notes Moved to R3. This use case will demonstrate the capability, but for data sets it will need robust vocabularies, which will be limited at the end of the release.
Lead Team DM
Primary Service Search & Navigation Services
Version 2.0
UC Priority 3
UC Status Detail +
UX Exposure EUC


This information summarizes the Use Case functionality.

Moved to R3, not in R2 scope.
Allow user to search along multiple axes simultaneously, in user-selected order, with rapid, intuitive feedback on quantity and nature of search results. Semantic (textual) content should be searched based on term meanings, not just match patterns (at least for science and instrument parameters and ION system concepts available in R2). User is prompted for appropriate search terms, either according to the repository content, or using specific controlled vocabularies (possibly chosen by the user).


  • Capabilities for notification registration and registration of output processor outlined in UC.R2.24 Search for Resource are also available here.
  • Domain vocabularies and supporting framework (a vocabulary or RDF repository, possibly a semantic engine) are available.
  • Simple hierarchical links between semantic concepts (kept internally and externally) have been generated by internal and external means.

Initial State

A user is interested in certain broad class(es) of resource, and wants to find resources that match his or her interest, but does not know all the applicable terms on which to search.

Scenario for "Advanced Resource Search-Deprecated" Use Case

  1. (Prompted search) User begins to type query terms into UI
    1. User does not necessarily need to specify/limit types of entities to include
    2. Google-suggestion-style functionality prompts with common search terms
  2. (Responsive search) As search is defined, as keywords and filters are entered, iterative searches are performed based on available criteria.
    1. Searching should initiate, and initial results display, as soon as any filter attribute is provided. The display of search results may be suspended while additional filters are being specified, then resume with new parameters. (This UI display should continue even if results are directed to another output, as it serves as a preview.)
    2. How to construct query strategy and what granularity to re-search (after each letter, at a space to delineate a word, etc) is to be determined.
  3. (Hierarchical search) If enabled, high-level search concepts (e.g., 'nutrients') incorporate instance terms (phosphorous, nitrogen, silicon, iron).
    1. In this release, to be achieved with just a few concepts — parameters, platforms (mobile = AUVs + gliders...), instrument classes, and observatories are possibilities.
    2. Requires vocabularies that explicitly delineate the hierarchies.
    3. Though semantic strategies are the obvious approach, a manual approach is also possible (but unlikely to scale).
  4. (Faceted search) As each attribute is constrained, the number of available resources is indicated, and remaining viable attributes and their values are highlighted.
    1. The sequence with which attributes were entered is maintained — the number of available resources after applying each attribute is shown, in order. This enables the impact of each filter to be assessed at any time.
    2. (Desired) The user changes the order of search facets to see the impact on data availability at that refinement step.
    3. The remaining viable attributes are determined based on the data sets still available in the search. (A way to quickly assess this information in real time is necessary.)
    4. The possible values for attributes likewise reflect the data sets still available.
    5. See faceted browser interfaces for examples: Flamenco Fine Arts Search ; British History Museum timeline
  5. (Constrained search) The user selects one or more controlled vocabularies from which to enter criteria, and chooses specific terms from those vocabularies.
    1. This is a more narrow way of prompting the user to choose good, meaningful, or common search terms.
    2. Vocabularies that already exist (GCMD, BODC, CF) may be used to give the user comfortable terms that are used by others in the community.
    3. This feature may be used to more easily provide 'Prompted search' above, since the vocabularies are controlled.

Final State

The user has found data beyond that which could be found just using the initial search concepts and string matching.


These comments provide additional context (usually quite technical) for editors of the use case.

Other advanced resource search features could allow negation of a filter, logical expressions and grouping for combining filters, and filtering on data values. These seem unlikely to be achievable in R2.

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B


usecase usecase Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Oct 14, 2011

    Michael Meisinger says:

    Suggest this to be pushed to R3. This makes use of extensive semantics, associat...

    Suggest this to be pushed to R3. This makes use of extensive semantics, associates and aggregations. This is what R3 is about