Re: [Plastic-devs] spectrum load message

[Noel W. <Noe...@ma...>]

On 14 Sep 2006, at 12:52, Mark Taylor wrote:

> On Thu, 14 Sep 2006, Noel Winstanley wrote:
>
>> Just trying to implement this now.
>>
>> The SSAP responses I see coming back from current services seem to do
>> a good job of annotating their columns with UCDs. However, utypes are
>> either incomplete or utterly missing.
>>
>>>       the spectrum. The entries of this map take the form of
>>>       utype->value pairs, where the keys (utypes) are as defined
>>>       in the SSAP specification, e.g. "Access.Format" for MIME
>>>       type. As many or few of these entries as are known may be
>>>       filled in.
>>
>> would UCD->Value pairs be acceptable to everyone?
>
> Probably time for me to bring up a complication I left out of my
> original proposal (on the grounds that I'd see how it was going down
> before I got to the nitty gritty).
>
> As you say, SSAP as currently practiced seems to be mostly UCD-based.
> I'm not sure to what extent this was ever standardised.
> The real-soon-now SSAP V1.0 standard, following the real-soon-now
> Spectral Data Model V1.0 standard, talks in terms of Utypes
> (which is probably the Right Thing to do).  No doubt our grandchildren
> will invent SSAP v1.1+

not mine. I'm going to warn them off, and suggest they do something  
less daft instead. like alligator wrestling, or something.


> to be based on VoTypes or something.
> Whether that's true or not, different versions of the standard will
> define more or less grossly different usages of actual utypes/UCDs.
> So exactly what version of SSAP we're using determines what's the
> right key-value pairs to pass in the metadata map, and what these  
> mean.
>
> Four possible solutions:
> ...
>
> (1) is the most rigorous, and tackles the case of utypes whose  
> semantics
> change between different versions of the standard.  (2-4) ignore that
> concern.  Am kind of tempted to plump for (4) following the "bit  
> scrappy
> but it'll probably do the trick" PLASTIC philosophy.  Anyone else?
>

I'd prefer 4) as
  - I've just implemented it in 5 mins (a good sign).
  - it requires no knowledge of SSAP specs encoded in the message- 
sender.
	- The sender can just pass-through whatever data was received from  
the SSAP service response.
	- requiring a client to understand a lot of SSAP, (and repeat for  
SIAP, SLAP, VOEvent, etc, etc) is going to make everyone's lives  
harder, and goes against 'do one thing well'
		- it's more the message receiver's task to understand the  
particular specs it supports.

A further thought.. If a specta tool prefers a _lot_ of metadata, I'd  
suggest it should also declare that it accepts the ivo://votech.org/ 
votable/loadFromURL message.
Then a client can pass it the queryURL to get the SSAP service  
response itself, and then maybe follow up with some
ivo://votech.org/votable/showObjects
messages to indicate which items the user is interested in.

I beleive that Aladin does something similar when passed a VOTABLE  
that is a SIAP service response.

cheers
noel

> Mark
>
> -- 
> Mark Taylor   Astronomical Programmer   Physics, Bristol  
> University, UK
> m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/ 
> ~mbt/
>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Plastic-devs mailing list
> Pla...@li...
> https://lists.sourceforge.net/lists/listinfo/plastic-devs
>