Time/Target mandatory

Thu Aug 14 09:41:36 PDT 2014

Markus,

Just to re-state. The real issue is that you need to cast your theoretical
data to
an observational model, because that is all that is defined.  If you only
come up
with these 3 conflicts.. I think that is pretty encouraging.  I'll provide
my opinions
on what to do for these fields, but I wouldn't call that definitive.

In general, I think the answers depend heavily on what type of theoretical
data
you have.. and what it's goals are.
  - are you modeling a particular star or object?
  - are you modeling a general class of star/object?

On Thu, Aug 14, 2014 at 3:41 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Hi Mark,
>
> On Wed, Aug 13, 2014 at 12:51:00PM -0400, CresitelloDittmar, Mark wrote:
> > > 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
>
> Hm -- so, what do I put there in my theoretical spectra?  Do I just
> make up bogus dates?  Use the time of their computation?  A NULL
> value?  But if the latter is allowed, what does "mandatory" mean in
> the end?
>

The Char.*Axis.Coverage elements describe the overall domain of the data in
each axis.
To date, you have been supplying NULL/NaN for both the Time and Spatial axes
   Char.TimeAxis.Coverage.Location.Value
   Char.SpatialAxis.Coverage.Location.Value

   Char.TimeAxis.Coverage.Bounds.Extent
   Char.SpatialAxis.Coverage.Bounds.Extent

IMO, the values depend on what you are doing.
  + modeling a particular object
       - spatial can be the location of that object, and spatial range
included in the simulation/model
       - time can be time of simulation run; extent, the simulated exposure
time.
       "this is a simulated spectrum of 3c273 using Chandra ACIS-S with
10ks exposure"
  + generic models
       perhaps these values just don't apply here.  In which case, what you
are doing
       seems the most reasonable approach. (Nan/Null)

In any event, I would not make up bogus dates.
For the fields which don't apply, I wonder if it would be better to use the
DESCRIPTION
to state why the value is null, rather than the generic text from the
document.
  e.g. for SpatialAxis.Coverage.Location.Value
     "ICRS location of aperture center" => "Theoretical data with no
spatial axis dependency"

> > 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.
>
> Aha -- so, my SDM metadata inherited "mandatoriness" from SSA, where
> Target.Name is optional (section 4.2.5.7), so whether or not it was
> mandatory in SDM 1, I'm advocating a harmonisation of SSA and SDM.
> In either direction -- is it intended to use SDM2 in SSA?
>

For all of these, you should find that the 'requirements' are in agreement
with ObsCore.
I expect there would be/has been an evaluation of SSA w.r.t. Spectral-2.0.

> And I just notice I did assign target.name in my theoretical service
> although it's optional in SSA.  It's "model star" for all the
> different model stars that are in there.  Hm.
>
> Since I feel some mild urge to improve the situation: Are there any
> opinions on what should be done in such cases, either from my little
> list
>
> > * 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
> > >
> >
> > Good point.. I'll keep it in mind for the cube model work.
>
> or yet something else -- or maybe drop the requirement for
> Target.Name entirely?  What, by the way, is the rationale for having
> it mandatory?
>

As for rationale.. I don't have any.  It has been mandatory, so it remained
so.
As for value..
  The purpose of the field is better described in ObsCore and SSA as being
to
  provide the user with the identity of the "target of the observation",
typically
  an astronomical object, but could be some other term such as "dark field".

  This is pretty consistent with the Simulation model description as
letting the user
  know 'what was simulated'.

So, IMO again, the best value is whatever completes the sentence:
  "This is a Spectrum of _______"

If "model star" best answers that, fine.  If something more specific...
that's fine to.
I don't think it ever needs to be empty, because it is certainly a spectrum
of something.
It does not seem to be something intended for query.. so no formal
syntax/content
is defined.  If it is an astronomical object, then something usable within
a name resolver
is highly recommended.

I don't think the 'identity of the code' is appropriate.. this is more
appropriate for the
"ObsConfig.Instrument.Name" element.

I hope this helps.
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20140814/347d7338/attachment-0001.html>