UseCase: ObservingProposalCheckForData

PrimaryActor:

Research astronomer, as proposer of observation

---

EndResult:

Proposer receives yes/no answer to question as to whether data matching given specification already exists in the VO.

---

OtherActors:

Observatory staff (in AlternativeFlows)

---

PreConditions:

Proposer has specified proposed observation adequately, including allowed tolerances. What this means in detail might depend on the observation, but could include things like position, band, limiting depth, seeing...

Proposer has worked out desired observation can be performed using instrument X at telescope Y.

---

FlowOfEvents:

1. Proposer contacts proposal preparation system of telescope Y.
2. Proposer enters specification of observation.
3. Proposal preparation system searches VO for data matching specification.
4. Proposer is returned summary of results of search, saying where matching data were found, and indicating whether the proposed observation will be allowed.

---

PostCondition:

Proposer knows whether proposed observation is acceptable, given observatory policy, as implemented in algorithm used to deduce yes/no answer from summary of query results.

If acceptable data do already exist, then proposer is given link to data, so s/he can start using it now, rather than waiting for proposed observation.

---

BasicAssumptions:

All relevant aspects of the observation can be readily specified, and map to metadata stored in relevant archives. This includes the availability of utilities such as described in UseCase InstrumentFootprint, which will be required to discover whether the desired data really do exist: e.g. if proposer wants a high-resolution optical image of a given distant galaxy, then to search the HST archive for such an observation requires knowledge of the WFPC2 footprint, as well as the telescope roll angles of all observations in the archive.

---

AlternativeFlows:

It seems sensible for this check to be run by the proposer, before submission of the proposal, but, alternatively, it could be run by observatory staff as part of their assessment of the feasibility of the observation.

The proposer might discover that data matching his/her specifications exists in the VO, but that it is proprietary for another nine months, say. In this case, the proposer would have to justify to the telescope's time allocation committee that the desired analysis cannot wait for the data to become public, and s/he must be allowed to undertake the proposed observation.

---

Discussion:

It is highly likely that something like this will be commonly implemented within a few years: the VO will become sufficiently well integrated into observatory proposal preparation systems, that someone proposing a particular observation will have to provide the time allocation committee with evidence that suitable data does not already exist, in the form of the results of a query as described above.

---

Links to ScienceProblems:

---

KeyReferences:

---

---

GoodStyle: Please add comments below. This area should be used for refinement of the above document. If you want to ask questions or start a dialogue with the author, please use (or create) a topic in the Use Cases Forum.
Author: Once the refinements here and comments in the forum die down, perhaps you could rewrite the problem, incorporating the comments and refinements.

---

-- BobMann - 12 Feb 2002