<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div>All,<br><br></div>There was an off-list request to review the &#39;Bandpass&#39; element in the current DatasetMetadata draft.<br></div>The request is to see if the element maps to an object from the Photometry model, in which case, we should <br></div><div>use that.  It also links to a request to review the SpectralBandType enumeration to see if that is more appropriate<br></div><div>than using a &#39;SementicConcept&#39; for the value.<br></div><div><br></div>The element is one of the ObsConfig objects, all of which are simple place-holders for more complex definitions<br></div><div>to come when Observation itself is modeled.  As such, I don&#39;t want to spend a lot of time trying to correct the <br></div><div>modeling of these elements now, but it is worth taking a look to see if some step can be taken in the right direction.<br></div><div>FYI: I am going into the document to add a simple Party model to resolve the vo-dml compliance issues discussed separately.<br></div><div><br></div><div>The description on pg. 33 reads:<br><br></div><div>4.6.2.3 Bandpass.name<br></div><div>A string describing the spectral range of the observation.<br></div><div>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: &quot;U&quot;,&quot;V&quot;,&quot;B&quot;,&quot;R&quot;,&quot;I&quot;,&quot;H-alpha&quot;).<br></div><div>This field corresponds to both the Coverage.Spectral and Coverage.Spectral.Bandpass fields of the Resource Metadata document.<br><br></div><div>5.2.4 SpectralBandType<br></div><div>Enumeration of generic spectral bands with definitions:<br></div><div>  Radio, Millimeter, Infrared, Optical, Ultraviolet, X-ray, Gamma-ray<br><br><br></div><div>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.  <br><br></div><div>A) Usage<br></div><div>    Taking a quick look through the docs.. <br></div><div><div>    Spectral-1.1 has the same definition as given here in DatasetMetadata.<br></div>    SSAP: BAND parameter can be either a numerical range, OR string representation.<br></div><div>      + the numerical range would be coming from the Char.SpectralAxis.Coverage.Bounds elements<br></div><div>      + as a string, it comes from this element.<br><br></div><div>    ObsCore/Tap only seems to support the numerical ranges from Char.. (em_min/max)<br></div><div>    SIA-2.0 same as ObsCore..numerical em_min/max<br></div><br><div>B) Comparison against Photometry model<br></div>    The Photometry model has the PhotometryFilter element which defines filter profiles.<br></div>    This object has several identifier fields, of which, &#39;bandName&#39; seems the best match.<br></div><br>     PhotometryFilter.identifier:String<br></div>       - unique name within a filter profile service for a particular filter eg: &quot;SDSS/SDSS.G/G&quot;<br></div>     PhotometryFilter.name:String<br></div>       - Human readable representation of the filter name. eg: &quot;SDSS.G&quot;<br></div>     PhotometryFilter.bandName:String<br></div>       - standard representation of the spectral band associated to this filter. eg: &quot;U&quot;,&quot;B&quot;,&quot;V&quot;<br></div>         (not recommended for discovery purposes)<br><div><br></div><div>C) My Thoughts:<br></div><div><div><div><div><div><div><div><div><div><div>    This field seems to be used for 2 incompatible purposes<br></div><div>      a) a general idea of the spectral regime.<br></div><div>          Any dataset can be tagged with the element(s) of the SpectralBand enumeration which apply to the observation.<br></div><div>          The enumeration is very short and covers the full domain, so I don&#39;t see a need for representing it as a SemanticConcept.<br></div><div>          This may not even be something to model.. seems more like an element to be defined by the access protocol to aid <br></div><div>          with discovery, and derived from the Bandpass-es and/or Characterisation coverage data.<br></div><div><br></div><div>      b) a specific set of bandpass-es.<br></div><div>          For this usage, the model should show references to PhotometryFilter objects from the Photometry model.  It may be that <br></div><div>          in certain use cases (SSAP), only the filter name is needed, but that would be for the protocol to define.<br></div><div>          This does seem like a modeled element of Observation.<br></div><div><br></div><div>      The &#39;problem&#39; is that the two usages have been denormalized to the same representation as a single string of comma delimited values.<br></div><div>      So we have an element of an unmodeled package which may or may not reference a modeled PhotometryFilter.<br></div><div><br><br></div><div>Options:<br></div><div>   1) Leave it as is.. address the modeling when we tackle Observation.<br></div><div>   2) Split the element into 2 <br></div><div>       a) ObsConfig.Band:String  &lt;= generic, from Enumeration<br></div><div>       b) ObsConfig.Bandpass:PhotometryFilter  &lt;= specific<br></div><div>   3) Remove the &#39;generic&#39; option, and leave the element definition as a de-normalized string of PhotometryFilter names<br></div><div>       Address that modeling when we work Observation.<br></div><div>   4) Remove the &#39;generic&#39; option, and only model this as references to PhotometryFilters (2b above)<br></div><div>       NOTE: this is probably the most &#39;correct&#39;<br></div><div>other) ?<br><br></div><div> <br></div><div>  The content of the document/model satisfies the scope of what it is expected to do and support.  Namely, to isolate, reconcile, <br>  and organize the various Metadata from existing models to an independent model document.  This is taking a step toward <br></div><div>  modeling Observation, and I don&#39;t think we have the time to start working those discussions.<br><br></div><div>  So I&#39;m leaning toward #1 at this point.<br><br><br></div><div>Thoughts?<br>Mark<br><br></div></div></div></div></div></div></div></div></div></div></div>