Branching off the spectrum data model?

[Alberto Micol]

Dear Doug and all,

I finally got a chance to read this fantastic document.
It is in very good shape, and will be a very good reference
to any data provider.

I will split the most relevant comments I have in a couple of emails.
Here the first and I think the most important one:

MUST/SHOULD/MAY aka REQUIRED/OPTIONAL
-------------------------------------

Regarding the Data Model we have always to compromise between:

- Data providers who must implement it;
   hence it must be described with absolute clarity to make things easy;
   any source of confusion is to be avoided,
   !data providers should not spend ages to implement it!

- Astronomers who do not care about the data model per se,
   but want to use the dm-based machinery
   in an easy and reliable way,
   !to do the science they are after, and quickly!

One could claim that data providers are astronomers,
but the feeling I have is that currently in the VO
many CSs, for various reasons, are assuming the role of
data provider.

For this reason I claim that any data model MUST be strict
and enforce some *required* fields, more than it is currently done.
Only in this way we will avoid mistakes and bad omissions;
without that we will not be able to build the fantastic machinery
to do science that we want to build.
Note: As an example to this, I'll comment about the
       Accuracy fields (which are all currently optional)
       in another email.

On Sep 14, 2006, at 07:41, Doug Tody wrote:

>     In general what is required or optional depends upon how a general
>     data model is used - it might be different in different  
> circumstances.

This is why we should branch off the data model
according to the type; for example:

For a theoretical spectrum:

     the Space/Time characterisation is optional
     the Spectral characterisation is required
     etc.

For an observed spectrum,

     the Space/Time/Spectral characterisation is required
     etc.

etc.

I prefer this branching-off approach than the generic statement
that: "since we have too many different applications of the model
we should have no required fields".

This way it will be much easier for data providers,
and the VO will benefit of more conforming services.

Alberto