Alternative proposal

[Tony Linde]

(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.

-- 
Tony Linde
Phone:  +44 (0)116 223 1292    Mobile: +44 (0)785 298 8840
Fax:    +44 (0)116 252 3311    Email:  Tony.Linde at leicester.ac.uk
Post:   Department of Physics & Astronomy,
         University of Leicester
         Leicester, UK   LE1 7RH
Web:    http://www.star.le.ac.uk/~ael

Project Manager, EuroVO VOTech   http://eurovotech.org
Programme Manager, AstroGrid     http://www.astrogrid.org