Error column in VOResource

[Tony Linde]

Right back at ya :) ... How does an application know how to handle metadata
that conforms to no known standard? Whatever the problems for the registry,
they are a thousand times worse for the apps since there'll be thousands of
applications wanting to use the resources. 

I don't understand how the metadata can be dynamic (other than by a data
centre accumulating more data). Surely the coverage of a dataset, say, is
based on the data in it? Even virtual data has to be generated from some
real data and it is on that data that the metadata is based. 

Maybe some examples would help, Doug.

Tony.

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Doug Tody
> Sent: 18 May 2004 17:18
> To: Tony Linde
> Cc: registry at ivoa.net
> Subject: RE: Error column in VOResource
> 
> 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
> > > 
> > > 
> > 
> > 
>