Error column in VOResource
Doug Tody
dtody at aoc.nrao.edu
Tue May 18 09:17:34 PDT 2004
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
> >
> >
>
>
More information about the registry
mailing list