[QUANTITY] Plea for pragmatism

[Steve Lowe]

Hi All,

I went back an reviewed Alberto Micol's original posting on this thread, 
and I must say that I agree with it wholeheartedly with many of his 
points. I would like to add some thoughts about use cases based on my 
observation of the NVO correspondence during the past year.

Many of the design proposals I've read skip some important steps in 
hurrying to a final design specification. These proposals (my own 
included, I'm afraid) lay out data structures and operations that the 
author(s) believe will be useful for data retrieval and analysis. The 
difficulty is that there are an endless list of features that *could* be 
useful, and this leads to endless disputes over which ones to include. 
What is needed is to set priorities on the capabilities on that long list.

To do this, I agree with others that have posted that we should pay 
attention to use cases. I wish to add that I believe the use cases need 
to be described more completely, or perhaps to say it a different way, 
the requirements implied by those use cases need to be set out in much 
more detail. This may have been said before, but if so, it is worth 
repeating.

I would like to see use cases that step through a particular calculation 
to identify exactly what capabilities the author thinks are needed. This 
would also be an opportunity for the author to express an opinion on how 
the processing responsibilities would be divided up among the data 
provider, the data model implementation, and the data user.

For example, consider determining the luminosity of an object from a CCD 
image. For a *particular* object, image and instrument, the use case 
scenario would provide answers to many detailed questions. What are the 
steps, what do you do to manipulate the data? (The steps I describe here 
may not be right; I'm just trying to illustrate the level of detail that 
I'm talking about.) First off, one might select a region within which to 
sum the pixel values. How would you specify the boundary of the region, 
how much freedom or precision do you need (not in general, but for this 
particular case)? Is it on the sky or on the detector? Are pixels that 
straddle the boundary in or out of the region, or perhaps for those 
pixels you need a value indicating the fraction of overlap with the 
region. Or you may need more exact information than this. What position 
error information does your analysis require?

Then you need to add up the fluxes. Is it to be assumed that, as 
delivered by the data provider, the pixel data values are linearly 
related to flux, so one can add the values directly? What information do 
you need related to saturation? And so on.

I think detailed scenarios like these are needed for data analyses that 
people actually do, and they need to be written down.

Obviously, preparing complete use case scenarios will be a lot of work. 
However, a collection of them might make it possible to
- identify and prioritize specific functional capabilities
- decide on a target capability set from the prioritized list---this 
clarifies goals for DM design
- verify that proposed DM elements meet that target---that is, the 
target set would be a basis to check design proposals against
A careful analysis like this would move us more quickly toward a real 
design.

Steve

-- 
Steve Lowe
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
slowe at cfa.harvard.edu
1-617-496-1661


Alberto Micol wrote:
 >
 > Dear All,
 >
 > At this point my feeling is that we are going nowhere.
 > All these discussions about quantities  are too phylosophical for me.
 >
 > We need to focus on what we want to achieve, provided that it is clear
 > to everybody what the goal is. I might be wrong, but I do not think that
 > the goal is well identified within the group. (After all, this is why I
 > called
 > for user cases).
 > I do not believe that defining a generic thing call quantity will 
bring us
 > anything immediately useful. It is too generic.
 >
 > For example, sorry Brian, I do not understand the requirements in
 > http://nvo.gsfc.nasa.gov/cgi-bin/view_requirements.pl
 > Most of them in my opinion are not requirements, but definitions.
 >
 > Requirements should describe what is to be achieved, and not
 > which class is associated with what, or who inherits from who.
 > And too generic requirements (quantity will be used to facilitate
 > search, etc)
 > bring nowhere either.
 >
 > In all cases, I do not find useful to start from the Quantity level.
 >
 > Let's concentrate on the top level things we need to solve for the VO,
 > eg, how to describe coverage (bandpasses, regions, time intervals, 
depths)
 > of existing data products, how to describe images, spectra, light curves,
 > exposure maps, visibilities, etc, how to package products, etc.
 >
 > Those should be the starting points, because that is what we have to
 > describe
 > in the 99% of the cases.
 >
 > In the process of developing a data model to cope with these (already
 > complex)
 > aspects, we will find the needs to define other things like Quantity,
 > Phenomena,
 > or anything else that WILL RESULT USEFUL in the process. Not the 
other way
 > around!
 >
 > I thought that it was decided that we start with Observational Data 
Model,
 > and not with Quantities. That is certainly a much more pragmatic point
 > of view,
 > am I wrong ?
 >
 > Alberto
 >