IVOATheorySNAP < IVOA

---+ SNAP
---++ Participants
   * Claudio Gheller (chair)
   * Herve Wozniak
   * Laurie Shaw
   * others ...
   * Gerard Lemson

TBD

---++ Issues and decisions, FAQ
Below follows a list of issues that have come up during the work on this projecr, the decisions that were taken to resolve them and the reasons why. This list will serve as a history of the development of the specification for those interetsed parties who were not closely involved in the process.

---+++ Which type of simulation is covered ?
*Issue*
We have had many discussions about what type of simulations are meant to be published under the SNAP protocol. The original idea was that they should include simulations of "objects evolving in 3D space".
This will allow a concept of spatial subset to be predefined, including various geometries (SPHERE, BOX).

*Discussion*
Various parties argued that any simulation that can be expressed as a N-dimensional box could/should be included. 


*Resolution* As of 2006-09-15 no resolution yet. <br>
Action items are: <br> 
to find several realistic use cases of the more generic configuration space where a subset protocol would be useful (Herve).<br>
Develop the data model and see whether there is place for more complex use cases (Gerard)


---+++ On which other prorotocol will we model SNAP
*Issue*<br>
Original SNAP spec was heavily based on the old SIAP protocol. Is this correct ? Should we use a newer protocol ?

*Resolution* May 2006, Interop Victoria<br>
In Victoria we decided to model ourselves on SSAP like protocols. This includes having a data model for structuring the metadata describing simulations for registration and discovery.

---+++ Support for data staging

*Issue*
Due to the large size of data produced by numerical applications, usually data are not avaialble immediately. Data should be stored on a disk from which they can be downloaded separately 


*Discussion*
Various solutions have been discussed for the following items:
1. the staging "may" or "must" be supported
2. interaction between the service and the user
3. management of the staging service (multiple queries, expiration time...)

*Resolutions* Some indications provided on 15/09/2006. <br>
Action items are: <br> 
1. Staging "may" be implemented if the server supports only data download. It "must" be provided if full snap service, with cutout function, is supported. In fact, in this case, the cutout action is expected to take a long time (more than minutes, up to hours) to be completed.
2. We expect to support simple interactions between client and service. The client can submit the request, delete it and check its status(pending, running, completed). Optionally expected times to complete various stages can be presented. All these actions are up to the user. Server can send messages to the users, but only in a very simple way (e.g. sending an e-mail that the data are available up to a certain date). Other methods could require single sign-on systems and then complicate and unpopular requirements to the users.
3. This is up to the service provider. However this features have to be published in registry using proper tags.

The details of all these points will be writeen in the Snap document (in preparation)

---+++ Selection tools

*Issue*
What kind of tools should be provided to users in order to select subset of data?


*Discussion*
The user does not know a priori the characteristics of the data. On the other hand he cannot download the whole dataset (Snap should avoid this!!!). Therefore the service has to provide tools to perform such selection. We cannot identify a single tool, since this can depend on the data themself, on the server etc.
This tools should be provided by the service. It "may" be provided from services that supports only download of complete dataset. It "must" be supported if cutout function is implemented. Registration of the service is required. It may be a web service based tool. 

*Resolutions* 
The basic idea is to provide a reduced dataset (that can be either precalculated or extracted on the fly), let's call it "thumbnail", that can be handled easily both for download and by various alorithms. There can be various possible realizations of the thumbnail:
- decimated dataset (take one particle or une grid point over N)
- orthogonal projections
- averaged datasets (reduce resolution of meshes, averaging over neighbouring cells
- ...

---++ other ...
<br/>
<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->
   * [[%ATTACHURL%/Snap-0.5-1.doc][Snap-0.5-1.doc]]: SNAP definition v0.5
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
doc	Snap-0.5-1.doc	r1	manage	149.0 K	2007-04-07 - 16:15	LaurieShaw	SNAP definition v0.5
This topic: IVOA > IvoaTheory > IVOATheorySNAP
Topic revision: r5 - 2007-04-07 - LaurieShaw