Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/ops/tof/SEA_future.html
Дата изменения: Tue Apr 20 19:31:45 1999
Дата индексирования: Sat Mar 1 07:42:09 2014
Кодировка:

Поисковые слова: http www.eso.org public videos list 22

Draft of the SEA "future ideas"

First, the SEA attempts to address a number of concepts that are detailed in several papers which are available at: http://aaaprod.gsfc.nasa.gov/SEA/papers/Default.htm
It would also be worthwhile to look at the report from our Workshop on Observing Tools: http://aaaprod.gsfc.nasa.gov/workshop/WorkshopReport.htm

While developing the SEA, we've attempted to collect ideas for future tools that are beyond the scope of the SEA effort. The following is a list of ideas large and small:

  1. Add Sky Scanning patterns to the VTT, allowing the user to easily layout exposures in standard patterns.
  2. Add ability to display "dead" or "hot" pixels in the CCD.
  3. Add image calibration to the VTT, allowing non-calibrated image files to be read and calibrated.
  4. Provide greater data mining capabilities to search catalogs with sophisticated queries over any property. Queries should span multiple catalogs.
  5. Add the ability to annotate every element in the proposal, so that at any point the user can explain "why" they made a particular choice.
  6. Develop a tool that allows the user to search for resources that would best fulfill a given science objective.
    1. Resources would include observatories, instruments, or existing observations. User would essentially search for observatories that can do their science, but might get an answer like "this data is already available" indicating that the tool found similar science results in an existing archive.
  7. Natural language or (preferably) speech recognition interfaces to catalog search engines.
  8. IRAF functions should be available within the visualization portion of the proposal tool (VTT).
  9. Proposal tools shouldn't force the user to work within the proposal structure if they don't wish to.
    1. The user should be able to define their own structure, or no structure at all, and later form that structure into a completed proposal. This facilitates more exploratory use of the tool, instead of forcing the user down a rigid path. The user should be free to manipulate objects in whatever structure makes the most sense to them.
  10. Future tools should support the upcoming Astro-XML standards so that tools and their products are interoperable. All output should be in XML using a common astronomical DTD.
  11. All astronomical data sources should be in a standard XML format so those new sources can be added without having to write new interfaces to the sources.
  12. When data is displayed in the tool, use visual cues to differentiate between data that has been entered by the user and data that has been filled in automatically, either as a default or as part of some query result. The user should be able to see where a particular value came from.
  13. Provide an active assistant "agent" that monitors the user during a session and detects when the user is lost, needs help, or is making a mistake. The agent would offer assistance in some non-obtrusive way, and should learn from past usage.
  14. Create an "amateur/educational" version of the SEA to be used by the amateur astronomer or in the classroom. It should be easy to define, say, a user's "backyard" telescope as the observatory.
  15. Provide CORBA interfaces to the tool so that other tools can be linked to/from the tool.
  16. Add to the VTT the visualization of spectroscopic lines, grisms, and coronography.
  17. Develop next-generation "live" documentation. The documentation should be dynamically built on the fly using the latest data from configuration files and algorithms so that the documentation is automatically up-to-date with all tool changes.
  18. Develop some standard way of representing data "pedigree". Users should be able to ask where a piece of data came from and what its error rates are.
  19. Develop a "re-validation agent" to address the following problem:
    1. Currently, the Program Coordinators at the Institute spend a great deal of time re-processing already approved, but still pending proposals when a change to the instrument occurs. These changes can include a variety of things, for example, new calibration information that affects optimal exposure times. Currently, the concept for the re-validation agent is to use agent-based technology to evaluate the impact of changes to both submitted proposals and proposals that are still under development. The agent could seek out impacted proposals, calculate the effect of the impact, develop a recommendation and then notify the observer and observatory staff of possible alternatives.
 
Jeremy Jones
Advanced Architectures and Automation Branch
NASA Goddard Space Flight Center
Jeremy.E.Jones@gsfc.nasa.gov
http://aaaprod.gsfc.nasa.gov/SEA/