Alternative proposal

[Tony Linde]

One further comment: I'm not sure how far my proposal meets the fine/coarse
grained dispute. What I would say, however, is that if one particular store
chooses not to cache all levels of metadata, it ought not to be prejudiced.
So a query sent to a shallow store works as well as one sent to a deep
store. Ie, if the query includes terms not in the store, it ignores them and
only uses the terms to hand - maybe with a flag returned indicating so. I
*think* this is how xquery works against incomplete data structures.

Does this meet the fine/coarse issue?

T.

> -----Original Message-----
> From: Tony Linde [mailto:Tony.Linde at leicester.ac.uk]
> Sent: 10 May 2007 16:32
> To: 'IVOA Registry WG'
> Subject: Alternative proposal
> 
> (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