Spectrum load MType(s)

[Mark Taylor]

Dear SAMP people,

we are still lacking spectrum.load MType(s) for SAMP.

I'm currently adding SAMP functionality to SPLAT; I hope that VOSpec
and perhaps others will follow suit.  Here are my thoughts about
how a spectrum load MType should be defined.

As for other SAMP MTypes, it's helpful to look at the corresponding 
PLASTIC message.  Here it is (from 
http://eurovotech.org/twiki/bin/view/VOTech/PlasticMessagesProposal):

   ID:
      ivo://votech.org/spectrum/loadFromURL
   Parameters:
      url: String
      id: String
      meta: Map
   Returns:
      success: boolean
   Description:
      Loads a spectrum or SED. id is an identifier as for the
      VOTable load message - use the URL if there's no reason to
      do otherwise. The meta argument is a map/struct containing
      additional information about the type of data found at url
      which encodes the spectrum. The entries of this map take the
      form of key->value pairs, where the keys are either utypes
      as defined in the SSAP specification (e.g. "Access.Format"
      for MIME type) or UCDs. As many or few of these entries as
      are known may be filled in.

Unlike most of the other PLASTIC load messages (which have a fixed 
data format and transmit only the URL in a parameter), it wasn't very 
clear what was the best way to define this one, and it took us some while 
to decide how to do it.  The form we adopted is influenced by the fact
that there is a wide variety of spectrum data formats in use, and
there may or may not be a lot of useful associated metadata, some
or all of which receiving applications might want or need.

The "meta" argument above is messy but pragmatic.  It allows all
known metadata to be placed in one bag for receiving applications
to sort out.  This means it's easy for an application which has 
the result of an SSA query to pass it on via PLASTIC to another
application.  The receiving application has to do some work 
disentangling this: for instance the MIME type may be given 
as the value of the "Access.Format" or perhaps "ssa:Access.Format" 
key (utype in the SSA v1.0 standard) or of the "VOX:Spectrum_Format" 
key (UCD in some earlier SSA versions).
SSA Services which output in both these forms are alive and well.
In practice this isn't much of a burden for the existing spectrum-
consuming PLASTIC applications, since they all have to do the same
job when they consume SSA service results directly in any case.
Although in principle there is a possibility of meta map key 
clashes since utypes and UCDs are mixed, in practice the syntax
of these is sufficiently different that it's unlikely to be a problem.

You can use this message to transmit a spectrum which does not 
originate from an SSA query too - just fake the contents of
the metadata map (maybe even leave it empty).

A more or less direct translation of the above PLASTIC message,
following the PLASTIC->SAMP conventions we've used for the
other *.load.* MTypes, would look about like this:

      MType:
         spectrum.load.ssa
      Parameters:
         url (string):
            URL of the spectrum to load
         meta (map):
            Additional metadata describing the spectral data found 
            at the URL.  Key->value pairs represent either 
            Utypes or UCDs as defined or used in some version of 
            the SSA specification or its predecessors.
            For example "Access.Format" (SSA 1.0 MIME type Utype)
            or "VOX:Spectrum_Format" (pre-1.0 SSA MIME type UCD).
         spectrum-id (string) optional:
            Identifier which may be used to refer to the loaded spectrum
            in subsequent messages
         name (string) optional:
            Name which may be used to label the loaded spectrum in the
            application UI
      Return Values:
         none

There are other possibilities.  For instance:

   - We could take the opportunity to align more closely with 
     IVOA standards and require that the metadata map contains 
     only Utypes from the SSA 1.0 standard.  This would look tidier, 
     but in practice would require more work by sending applications 
     which have to deal with SSA responses that may not conform to 
     SSA 1.0 (most currently don't).  Doing a good job of translating 
     a non-v1.0 SSA metadata map to a v1.0 one would be non-trivial.

   - We could introduce a set of type-specific spectrum.load.* messages 
     (spectrum.load.fits, spectrum.load.votable, spectrum.load.ascii, ...)
     This would look more consistent with the way we've done other
     MTypes, but again introduces more work for sending applications,
     since they can no longer just forward the info from an SSA
     response.  Extracting the data type from the SSA response is
     not in practice straightforward, since you need to do a bit
     of detective work (a) finding the utype/UCD containing this
     information and (b) turning the "MIME type" (interpreted very
     loosely by a lot of existing SSA services) into a SAMP-defined
     data type.  We'd have to enumerate the list of known types for
     this purpose as well.

   - We could make the relatively minor adjustment of splitting 
     the metadata map into two parameters, one for UCDs and 
     one for Utypes.  Or maybe one for SSA v1 Utypes and one for 
     old-type SSA UCDs (call them ssa1-utypes and ssa-old-ucds or
     something).  This would look a bit more respectable and could
     make the parsing slightly easier or more robust.

   - No doubt other options and variants exist.

So, although it looks a bit untidy, I'm inclined to go for something
close to the PLASTIC-like MType I've written above.  We know this
works because its equivalent is in use in PLASTIC applications.

Of course since MTypes are just agreements between willing participants
there is no absolute requirement to have a single agreed form for this
purpose (i.e. different developers could do different things, or we
could adopt all of the above.  However the more agreement, and the 
fewer MTypes to do the same job, we can have, the better it will 
be for interoperability.

Does anyone else have an opinion or comment?

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/