Spectral 1.1 to 2.0 "cheat-sheet"

[CresitelloDittmar, Mark]

Markus,


On Mon, Aug 11, 2014 at 3:29 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

>
> However, I'm a bit confused on one point (though I suspect that's
> mainly due to utypes): The changes document says the
> Char.TimeAxis.Coverage.Bounds.* fields are mandatory.  However, the
> standard, in 7.1.2, says that both TimeAxis and SpatialAxis are
> optional ("None may be defined) -- as they must be, given that a large
> part of the spectra currently available in Spectral 1.1 are
> theoretical spectra that did not result from an observation and hence
> are not characterised in either time or space.
>

Table 7.1.5 shows that Characterisation TimeAxis coverage bounds are
required..
supplied as EITHER an extent, or a start/stop pair.

This is consistent with V1.1 where the utype list showed 'extent' as MAN,
'start/stop'
as REC (optional), and the text in section 5.2.1 stating that one must
supply either
extent or start/stop.

So, the 2.0 document does change the table listing, but only to make it
more
consistent with the text.


Table 7.1.2 is showing the axis requirements as a whole, for the 2 places
where
one provides 'Axis' information.. under Characterisation, and under Data.
  - one MUST have a TimeAxis in Characterisation
  - one MAY NOT have a TimeAxis within Data

You seem to interpret "None may be defined" as meaning it is optional..
I believe the expectation (from the previous versions) is that they are not
allowed.



> So, I guess the answer to that little riddle is that the Bounds
> fields are "conditionally mandatory" ("*if* you have a TimeAxis,
> then..."), right?
>

No, a validator should require there to be either:
  Char.TimeAxis.Coverage.Bounds.Extent
or
  Char.TimeAxis.Coverage.Bounds.Start
  Char.TimeAxis.Coverage.Bounds.Stop



> Slightly related: If we make Target.Name mandatory (and I'm always
> for doing away with optional things),


I'm a little confused on this one.. Target.Name has always been MAN.
I think that may be an error in the change doc.



> I guess some (non-normative)
> advice on what to do in case of generated spectra (in 2.11.1) would
> be useful.  As I'm not quite certain what the intended use of
> Target.Name is, I don't feel confident as to what a good solution
> would be, but possibilities that come to my mind include:
>
* Assign different names to the outcomes of different computations OR
> * Assign identical names to the outcomes of computations with the
>   same physics OR
> * Have a constant target identifying the code ("Spectrum computed
>   with Magic 3.23pl1") OR
> * Just have "Artificial" in there always if there's no physical
>   object
>
Each has advantages and disadvantages for certain scenarios.  Without a
> strong advice here I expect the providers of theoretical spectra will
> have a wild mixture of policies (prediction: most of them will have
> an empty string in that "mandatory" field), and we'd have all the
> disadvantages and none of the advantages, and that'd be a shame.
>

Good point.. I'll keep it in mind for the cube model work.


Your questions stem mostly from the fact that you want to put up
'theoretical' spectra.
This is a good topic to discuss as we continue this work on the
'Observation-Dataset metadata'
for the cube model.

In those discussions we have focused on "ObsDataset" (dataset derived from
an observation)
which the basis of ObsCore and the focus of most of our attention to date.
In that work, we
have described an 'Observation' as a type of 'Experiment' which produces
'ObsDataset' results.
This pattern is derived from the Simulation-1.0 model, where a 'Simulation'
is a type of 'Experiment'
which produces 'Dataset' results.

I expect that a 'Theoretical Spectrum' should be identical in form and
content to a 'Observational Spectrum'
other than the metadata referenced from the 'Experiment'... describing how
the data was generated.
This includes stuff like "Target", "ObsConfig" and much of the items
generally considered 'Provenance'.

In the Simulation model, section 3.6 describes the Target object from that
perspective..

I expect that as those working on Provenance, and the Experiment<->Dataset
relation
refine their model, these questions will be easier to address.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20140813/acc8f801/attachment.html>