[DatasetMetadata] Bandpass

[CresitelloDittmar, Mark]

All,

There was an off-list request to review the 'Bandpass' element in the
current DatasetMetadata draft.
The request is to see if the element maps to an object from the Photometry
model, in which case, we should
use that.  It also links to a request to review the SpectralBandType
enumeration to see if that is more appropriate
than using a 'SementicConcept' for the value.

The element is one of the ObsConfig objects, all of which are simple
place-holders for more complex definitions
to come when Observation itself is modeled.  As such, I don't want to spend
a lot of time trying to correct the
modeling of these elements now, but it is worth taking a look to see if
some step can be taken in the right direction.
FYI: I am going into the document to add a simple Party model to resolve
the vo-dml compliance issues discussed separately.

The description on pg. 33 reads:

4.6.2.3 Bandpass.name
A string describing the spectral range of the observation.
The value may be expressed in terms of general spectral bands, or specific
bandpass names.  If multiple bands are covered, the value may be a comma
delimited combination of appropriate bands.  If expressed as general bands,
the value(s) must be selected from the enumerated set given by the
SpectralBand type.  There is no controlled vocabulary for bandpass names as
the list is too long to enumerate.  Effort should be made to use highly
recognized bandpass names (eg: "U","V","B","R","I","H-alpha").
This field corresponds to both the Coverage.Spectral and
Coverage.Spectral.Bandpass fields of the Resource Metadata document.

5.2.4 SpectralBandType
Enumeration of generic spectral bands with definitions:
  Radio, Millimeter, Infrared, Optical, Ultraviolet, X-ray, Gamma-ray


My understanding is that this element refines the Spectral domain covered
by the observation, and does not, necessarily, indicate that a particular
filter was applied during the observation.

A) Usage
    Taking a quick look through the docs..
    Spectral-1.1 has the same definition as given here in DatasetMetadata.
    SSAP: BAND parameter can be either a numerical range, OR string
representation.
      + the numerical range would be coming from the
Char.SpectralAxis.Coverage.Bounds elements
      + as a string, it comes from this element.

    ObsCore/Tap only seems to support the numerical ranges from Char..
(em_min/max)
    SIA-2.0 same as ObsCore..numerical em_min/max

B) Comparison against Photometry model
    The Photometry model has the PhotometryFilter element which defines
filter profiles.
    This object has several identifier fields, of which, 'bandName' seems
the best match.

     PhotometryFilter.identifier:String
       - unique name within a filter profile service for a particular
filter eg: "SDSS/SDSS.G/G"
     PhotometryFilter.name:String
       - Human readable representation of the filter name. eg: "SDSS.G"
     PhotometryFilter.bandName:String
       - standard representation of the spectral band associated to this
filter. eg: "U","B","V"
         (not recommended for discovery purposes)

C) My Thoughts:
    This field seems to be used for 2 incompatible purposes
      a) a general idea of the spectral regime.
          Any dataset can be tagged with the element(s) of the SpectralBand
enumeration which apply to the observation.
          The enumeration is very short and covers the full domain, so I
don't see a need for representing it as a SemanticConcept.
          This may not even be something to model.. seems more like an
element to be defined by the access protocol to aid
          with discovery, and derived from the Bandpass-es and/or
Characterisation coverage data.

      b) a specific set of bandpass-es.
          For this usage, the model should show references to
PhotometryFilter objects from the Photometry model.  It may be that
          in certain use cases (SSAP), only the filter name is needed, but
that would be for the protocol to define.
          This does seem like a modeled element of Observation.

      The 'problem' is that the two usages have been denormalized to the
same representation as a single string of comma delimited values.
      So we have an element of an unmodeled package which may or may not
reference a modeled PhotometryFilter.


Options:
   1) Leave it as is.. address the modeling when we tackle Observation.
   2) Split the element into 2
       a) ObsConfig.Band:String  <= generic, from Enumeration
       b) ObsConfig.Bandpass:PhotometryFilter  <= specific
   3) Remove the 'generic' option, and leave the element definition as a
de-normalized string of PhotometryFilter names
       Address that modeling when we work Observation.
   4) Remove the 'generic' option, and only model this as references to
PhotometryFilters (2b above)
       NOTE: this is probably the most 'correct'
other) ?


  The content of the document/model satisfies the scope of what it is
expected to do and support.  Namely, to isolate, reconcile,
  and organize the various Metadata from existing models to an independent
model document.  This is taking a step toward
  modeling Observation, and I don't think we have the time to start working
those discussions.

  So I'm leaning toward #1 at this point.


Thoughts?
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20160301/f5cd7667/attachment.html>