Error column in VOResource

[Martin Hill]

If something is going to be discovered and used, we have to have some 
way of describing it so that the VO-wide tools can use it. ie, there is 
still some level of 'static metadata' even if it is metadata of metadata.

There will no doubt be all sorts of new tools that won't immediately fit 
in VOResource, so we need to make sure our metadata description can be 
extended (I really don't think VOTable can cope with this).

Bypassing the registry doesn't solve these problems; if the VO is going 
to work it still needs a consistent set of metadata descriptions (eg 
VODataService) that describe particular kinds of services so that 
VO-wide tools can interpret and use them.

And I know no-one's had time to answer this yet, but how can you do 
discovery if you don't describe reasonably fully what there is to discover?


Doug Tody wrote:

> Tony, how does your approach handle services which return virtual data,
> or datasets which contain metadata which has not been standardized?
> 
> In the case of virtual data, the metadata for the virtual dataset is not
> static hence cannot be cached in the registry.  One has to ask the actual
> service what it can generate to service a specific query, and the metadata
> for the virtual dataset is generated on the fly.  Probably this sort of
> thing will be the case for most sophisticated VO services.  Hence, the
> registry is limited primarily to service discovery based on fairly high
> level, static resource descriptors.    Doug
> 
> 
> 
> 
> On Tue, 18 May 2004, Tony Linde wrote:
> 
> 
>>As I keep saying, the coupling is an issue of implementation, not design. We
>>design the registry interface so that it is a one-stop shop for all metadata
>>but if one implementation gets the metadata from the resource every time it
>>is asked and another caches that metadata, it is transparent to the calling
>>application.
>>
>>
>>>Making the registry a one-stop shop for metadata demands a 
>>>tight coupling with the services they describe.  Any change 
>>
>>I don't see why - the registry only needs to know how to ask for the
>>metadata and how to return it to the calling app. We will have a standard
>>way of getting the metadata (from Wil's proposal for a standard baseline for
>>all services), a standard representation (VOResource which includes the
>>DM-based schema) and a standard way for apps to get that metadata (RI spec).
>>This is about as loose a coupling as I can think of.
>>
>>And if it *did* require tight coupling, all the more reason to put all this
>>processing into the registry, otherwise you end up with every single
>>application having to be tightly coupled to every resource - but this is not
>>the case.
>>
>>Making the registry the source of all metadata means that all applications
>>only have to manage one interface right down until they select the service
>>they want to invoke - they don't have to each and every one be coded to fish
>>around lots of services looking for the metadata they want.
>>
>>T.
>>
>>
>>>-----Original Message-----
>>>From: Ray Plante [mailto:rplante at ncsa.uiuc.edu] 
>>>Sent: 18 May 2004 16:51
>>>To: Tony Linde
>>>Cc: registry at ivoa.net
>>>Subject: RE: Error column in VOResource
>>>
>>>On Tue, 18 May 2004, Tony Linde wrote:
>>>
>>>>the registry is a one stop shop for all metadata.
>>>
>>>I disagree with this statement in general.  Besides various 
>>>pratical reasons of scaling and scope, there is an issue of 
>>>volitility.  
>>>
>>>Making the registry a one-stop shop for metadata demands a 
>>>tight coupling with the services they describe.  Any change 
>>>in the service must be reflected back into the registry.  If 
>>>the registry is simply about discovering services, the 
>>>coupling is looser, and the service is more flexible to 
>>>changes in implementation.  
>>>
>>>It can be argued that the tighter the coupling, the more 
>>>costly the system in terms of software development and 
>>>coordination of people.  A tightly coupled design may be 
>>>appropriate for a particular VO project that can manage that 
>>>coordination; however, it's less appropriate for the IVOA as 
>>>a whole.  
>>>
>>>It's an interesting issue that I expect we'll learn more 
>>>about with experience.
>>>
>>>cheers,
>>>Ray
>>>
>>>
>>
>>
> 
> 


-- 
Martin Hill
www.mchill.net
07901 55 24 66