Spectrum load MType(s)

[Allan Brighton]

Hi Mark,

I just implemented a jskycat "Send Spectrum to ..." feature using PLASTIC and the
"ivo://votech.org/spectrum/loadFromURL" message. At first I wasn't sure
what to put in the Map argument, but after reading your mail, I think I
understand now.

In this case, the user is viewing the results of an SSA query and a table
cell editor displays an icon with a "send menu" that sends the spectrum URL
for that row to an another application. I assume that the Map should map
the column UCDs to the column values for the selected row.
I tested this with PLASTIC and SPLAT and it seems to work fine.

Currently the SAMP version of this code just sends a "table.load.votable"
or "table.load.fits" message, but once you have a version of SPLAT that works with SAMP,
I'll test the new SAMP spectrum message. Let me know if there is a new SPLAT version
I can check out from the StarJava SVN sources.

--
Allan

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
>