Spectrum load MType(s)

[Thomas Boch]

Hi Mark,

I'd be happy with the SAMP message as you define it. I also wouldn't be 
against splitting the meta map into 2 separated maps, one for UCDs and 
one for utypes. But I don't have a strong feeling about that since my 
application won't be parsing those maps but will just send them.
Therefore, it would be interesting to hear the opinion from other 
developers of spectrum viewers/analysis tools.

Cheers,

Thomas

Mark Taylor wrote:
> 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
>
>