Документ взят из кэша поисковой машины. Адрес
оригинального документа
: 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:
-
Add Sky Scanning patterns to the VTT, allowing the user to easily layout
exposures in standard patterns.
-
Add ability to display "dead" or "hot" pixels in the CCD.
-
Add image calibration to the VTT, allowing non-calibrated image files to
be read and calibrated.
-
Provide greater data mining capabilities to search catalogs with sophisticated
queries over any property. Queries should span multiple catalogs.
-
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.
-
Develop a tool that allows the user to search for resources that would
best fulfill a given science objective.
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.
-
Natural language or (preferably) speech recognition interfaces to catalog
search engines.
-
IRAF functions should be available within the visualization portion of
the proposal tool (VTT).
-
Proposal tools shouldn't force the user to work within the proposal structure
if they don't wish to.
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Provide CORBA interfaces to the tool so that other tools can be linked
to/from the tool.
-
Add to the VTT the visualization of spectroscopic lines, grisms, and coronography.
-
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.
-
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.
-
Develop a "re-validation agent" to address the following problem:
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/