new MType proposals.

[Noel Winstanley]

On 8 Apr 2009, at 11:15, Mark Taylor wrote:

> On Tue, 31 Mar 2009, Noel Winstanley wrote:
>
>> Hi,
>> I'd like to propose 2 new SAMP mtypes, for exchanging references to  
>> registry
>> resources and academic papers. Both are based on existing plastic  
>> messages at
>> http://eurovotech.org/twiki/bin/view/VOTech/PlasticMessagesProposal
>>
...
>>
>> 2 Exchange a set of VOResources
>> (http://www.ivoa.net/Documents/latest/VOResource.html)
>> MType:
>> 	voresource.loadlist
>> Parameters:
>> 	name: (optional) name for this set of resources
>> 	ids: (required) map of IVOID -> (optional) URL
>> 		The keys of this map are the IVO-identifiers of the
>> voresources to load. The optional value associated with each key is  
>> an URL
>> from which the XML of the voresource can be downloaded.
>>
>> Return Values:
>> 	none
>>
>> The URL values in the ids map are optional and need not be  
>> provided, but may
>> be useful for a receiving application which isn't able to query a  
>> registry
>> service. (e.g. because it doesn't bundle the whole SOAP stack  
>> required to do
>> this)
>
> I wonder whether this ought to be decomposed into two MTypes,
> one in which the URLs are present and one in which they are not.
> The reason is that an application which can't do IVOID->resource-info
> mapping (e.g. no SOAP, no registry access) probably won't be able
> to do much with a list of IVOIDs (will it?).  So such a client would
> want to subscribe to receive messages that come with the URLs but not
> ones that don't.  An application which can do IVOID->resource-info
> mapping would be able to use either form.  An alternative would be
> to have only one MType as above, but make the URLs mandatory.
>

I didn't want to make the URLs mandatory, as it's maybe a bit too  
onerous for some applications (you need to setup an internal webserver  
to do this at the moment, as resources are only SOAP-accessible).

Is there some suitable language between mandatory and optional? -  
recommended, preferred?

I was less keen to have two mtypes, as the messages have the same  
semantics and intention.
However, is it possible to do something with MType subtyping? My  
understanding of the spec at this point is a bit shakey, but can't a  
client subscribe to a MType, and it will receive all subtypes of that  
MType too?

So would defining the following MTypes work?
voresource.loadlist : same as described above
voresource.loadlist.annotated - same structure, but resource URLs are  
mandatory.

A client that didn't require the resource URLs could subscribe to  
'voresource.loadlist', and would receive both kinds of mesage, while a  
client that required the resources would subscribe only to the subtype.

Does a subscription to 'voresource.loadlist' automatically match  
subtypes, or does an explicit wildcard need to be used (in whichcase,  
this could be a bit of a gotcha)


> I'm not much involved with applications which send or receive this
> kind of message, so I may have misconceptions about how it would be
> used; more weight is due to the opinions of those (like Noel) who are
> likely to use it.
>

One of the use cases I had in mind was sending a set of resources off  
to an external tool (such as Norman's SKUA)  that uses some kind of  
deduction / ontological reasoning / magic to suggest related  
resources, which are then messaged back to voexplorer.

In this case, when voexplorer hands off the set of resources, the  
resource URLs might be useful if the external tool wants to crawl the  
XML to extract search terms, or whatever it uses as input to the  
reasoner.

However, if the reasoner has previously digested a registry, it might  
not have access to the XML source of the suggestions it computes - and  
voexplorer wouldn't require the resource URLs anyhow. So it seemed  
convenient not to require these.

thanks for the suggestions
noel.

> 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/