User enters filtering metadata (including associations) and gets matching resources.
|Actors||Any OOI user (Anonymous Guest)|
|References||UC.R1.07 Subscribe To Data|
|Is Used By|
|Is Extended By||UC.R2.25 Advanced Resource Search-Deprecated|
|In Acceptance Scenarios||AS.R2.01A Operate Marine Observatory, AS.R2.02C Instrument Life Cycle Support, AS.R2.03A Modelers Integrate External Model with OOI, AS.R2.04A Data Product Leads Drive Core Data Product Creation, AS.R2.04B Curate Data Products|
|Technical Notes||Searched resources can be of any type, not just data.|
|Primary Service||Search & Navigation Services|
|UC Status||Mapped + Ready|
This information summarizes the Use Case functionality.
Enter constraint information into the Integrated Observatory to find data product or other resource of interest. Searching can occur with respect to both static and dynamic information about resource. Queries that can be defined should provide reasonably complete coverage for the types of resource metadata that are available for different resource types. (One field to search on is the resource type.) Set multiple query constraints simultaneously and execute. Set up and execute a complex manual query.
- Search (this use case) refers to specifying constraints to be satisfied (whether back-end query constraints, or filters applied at the UI); browsing refers to choosing (not down-selecting) among resources already presented on the screen
- Default constraint for resource type should be data products.
- The default constraints (when searching data products) should exclude intermediate data products and deprecated versions.
- The default constraints should exclude resources that are not in the Deployed life cycle state.
- The UX implementation for the search constraints will be as responsive as possible given time constraints (see scenario).
- This use case refers to searching both existing data products, and newly arriving or updated data products. It is not meant to optimize for the latter; that may come in Release 3. The results should be presented similarly regardless of whether data product is closed (no longer being updated), except as that is used as a constraint or ordering capability.
- Optimization of search will be performed in a limited way for the delivered Release 2. The information collected from use of Release 2 will strongly inform search optimization in Release 3.
A user is interested in certain class(es) of resource, and wants to find resources that match his or her criteria.
- User accesses the search capability in the user interface
- User determines resource characteristics of interest and specifies associated constraint values
- In simple search, users identify 'types' of resources they are interested in (the user types are not the same as the internal 'resource types' or internal representation types).
- Once a type is selected, the list of constraint options offered is appropriate to the type (for example, provide a lat/lon constraint for search of data products).
- If multiple types are selected, some constraints may not apply to all types; these should be de-emphasized.
- Ideally searching initiates, and initial results are displayed, as soon as any constraint is completely provided. (See [UC.R2.25 Advanced Resource Search], though that is no longer in R2.).
- <4> User optionally specifies the content and format of the result records.
- Can exclude fields that are part of the default, or include fields not part of the default response.
- Field contents should be presented so as to support linked open data principles.
- Formats supported may include HTML (i.e., attractive view in a browser), XML (for computer processing of search results), and text (e.g., for pasting into a spreadsheet or email).
- Content and format specification is overridden by certain selections in the next specification.
- Search takes place according to the specifications above.
- The result list for data products will include updating data products, as well as historical data (that is, closed data products, those that are no longer being updated with new data) by default.
- The search service receives constraints, creates a search strategy and executes it. For the search strategy, the system will need to identify the catalogs, link repositories, and content queries that are possible.
- OGC's Filter Expression Standard may be a communication technique (http://www.opengeospatial.org/standards/filter)
- Search results are processed and organized, and potentially cached based on policy
- Metrics are captured for optimization (query, number of hits, time to complete).
- <3> If requested, a search may be saved for future execution
The user has successfully found the resource(s) of interest, or is confident they are not available.
These comments provide additional context (usually quite technical) for editors of the use case.
The identification and prioritization of constraints/metadata attributes relevant to each data type will be performed by a team from Product Management and UX, including the Data Curator. It will take into account user needs (previously expressed in interviews), system needs (to perform required system functions), and the team's previous ocean data system experience.
The design should accommodate new attributes in the default attribute specification interface at extremely low or no implementation cost.