Alternative proposal

[Tony Linde]

Yes, it is, Matthew. Must be how the idea first lodged in my
email-overloaded brain. My proposal, though, pushes all the query-type
metadata out to the DD so 99% of queries for resources are against that -
registry is only used to get location of the resource(s) selected, how to
invoke them, who to call if they goes wrong etc.

T.

> -----Original Message-----
> From: Matthew Graham [mailto:mjg at cacr.caltech.edu]
> Sent: 10 May 2007 17:36
> To: Tony Linde
> Cc: 'IVOA Registry WG'
> Subject: Re: Alternative proposal
> 
> Hi Tony,
> 
> This sounds like an elaboration of exactly what I suggested on Tuesday
> so it has my support.
> 
>     Cheers,
> 
>     Matthew
> 
> Tony Linde wrote:
> > (this affects DAL and GWS but I assume relevant people are here
> anyway)
> >
> > Ray's proposal attempts to minimise the amount of fine-grained
> > metadata in the registry and needing to be harvested. My proposal is
> a
> > little more off-beam and not really thought all the way through (or
> > fully checked with AG colleagues <gulp>).
> >
> > Basically, I reckon the registry is about finding resources. So the
> > registry needs to contain both the location of resources and the info
> > necessary to determine the right resources. In addition, it needs
> > housekeeping info such as the curator, publisher etc. Let's call
> these
> > location, selection and curation metadata.
> >
> > I don't think there is any argument that we need the location
> metadata
> > and little that we need the curation metadata. The dispute is about
> > the selection metadata. I would propose therefore that
> > (1) registries only contain and harvest location and curation
> > metadata: what I will call core metadata.
> >
> > Obviously this would make registries of little use to scientists or
> > applications (ie, clients generally). So, I propose that
> > (2) the Registry WG form a subgroup to get started on creating a
> > Resource Selection specification: this to cover:
> > (2.1) selection store: types of information needed per resource type
> > (details worked out in conjunction with the group which writes the
> > resource spec);
> > (2.2) selection service: basic interfaces required and how/if
> > information is replicated.
> >
> > In order to locate selection metadata in the first place,
> > (3) the core metadata might include pointer(s) for retrieving the
> > selection metadata (if consistent with the resource type), the number
> > and format of those pointers to be determined in conjunction with the
> > group which writes the resource spec.
> >
> > Since a lot of the discussion has been about tabular data, I'd
> suggest
> > that
> > (4) the first selection spec be based on the needs of tabular data
> > services and be developed in conjunction with DAL.
> >
> > That's basically it for my proposal but I'd like to add some other
> > thoughts that I think come out of this:
> >
> > (5) there will obviously be discussion about the distinction between
> > location, curation and selection metadata but if we keep those as the
> > main ideas, we can decide what works best for each type of resource.
> >
> > (6) we ought not to assume that there is a one-to-one relationship
> > between a resource and a block of selection metadata. It could be
> that
> > several resources are described by the same block and several blocks
> > refer to a single resource. This has implications for the pointers
> > mentioned above.
> >
> > (7) the structure of the registry and its contents and how those are
> > specified (xml schemas and extensions) does not need to change: this
> > approach was worked out over a long time and we do not need to start
> > that discussion again. I'd suggest sticking with this _approach_ in
> > determining the selection store format.
> >
> > (8) this approach will allow the development of a wider range of
> > resource finding services. A project which only wants to implement a
> > registry can do so with little effort. Ditto for those who offer a
> > finding service (I can think of at least one such service). But it is
> > also possible that a service offers *both* the registry interface and
> > the selection interface and maybe some enhanced combination of
> > services. As with Ray, I've always wanted to make sure projects are
> > free to develop radically new approaches to VO-based astronomy and I
> > hope this idea helps with that.
> >
> > And the most important point of all:
> >
> > (9) we do not change the current way the registry works but put all
> > our energy into getting this proposal mapped out and implemented. If
> > we push hard, I see no reason why we cannot get all this complete by
> > the autumn meeting.
> >
> > Okay - time for everyone to tear my ideas to shreds...
> >
> > Cheers,
> > Tony.
> >