LTER Metadata Query Interface – Current Status and Future Challenges
This document discusses the current status and future challenges of the LTER Metadata Query Interface. It evaluates the strengths and weaknesses of both the existing LTER query interface and the KNB Metacat system. Key strengths include familiarity among LTER scientists and a simple, fast interface; however, both systems face limitations in search parameters and result customization. Recommendations for improvement focus on enhancing usability, flexibility, and result orientation, ensuring that the interface supports multiple database targets and presents data resources prominently.
LTER Metadata Query Interface – Current Status and Future Challenges
E N D
Presentation Transcript
LTER Metadata Query Interface – Current Status and Future Challenges Wade Sheldon GCE-LTER
DTOC Strengths/Weaknesses • Strengths • Familiar to LTER scientists • Simple (keyword search, browse) • Fast • Populated by all LTER Sites • Weaknesses • Limited search parameters • Limited metadata content to search • Can’t tailor results (sort, filter, search within results) • Targets of document links highly variable (Site pages) • No scope for enhancement
KNB Metacat Strengths/Weaknesses • Strengths • Simple interface with keyword guidance • Searches rich metadata content (EML content) • Some constrained search support (title, author, all) • Consistent display for all documents • Highly configurable • Weaknesses (of default web interface, stylesheets) • Limited search parameters • Can’t tailor results (sort, page, filter) • Expansive displays of query results, metadata hard to view • Links to entities, data “buried” • Relatively slow
Ideal LTER Metadata Query Interface • Subject of working group (shameless plug) • Some considerations: • Needs to be PI-friendly (usability is key) • Should be flexible • support multiple interfaces (search, browse, query builder) • results should be customizable (user-selectable detail) • ideally should support multiple database targets • Should be results-oriented • links to resources described should be highly prominent(“where’s the *&!# data!”)