Registry hierarchical metadata

[Anita Richards]

Dear Alberto,

>
> I just read the dataService metadata document Anita circulated earlier today,
> and I have a counter proposal, far from being complete, but trying
> to visualise a hierarchical approach whereby the registry would try to
> answer a query not in a single step, but by scanning the repository at
> different level of complexity and details.

I don't think this is a contradictory 'counter proposal', but a more
advanced example of what I am groping towards.  The only place we may
differ (apart from details like when we use indexing and when we use
compex shapes to describe abgular coverage) is, how many layers do we
impliment when, and how do we decide what to put in them?  I am arguing
(influenced by discussions in AstroGrid) that we should start with two
layers based on information held in the Registry - the lower or more
detailed layer is the UCDs for each data set, and the top or more general
layer is the ResourceMetadata which the VO condenses from each data set
(or we ask curators to supply, but it would need checking) - hence very
simple and limited initially.

Then Alberto's heirachy could grow out of inadequacies which emerge in the
top layer during testing against science cases.

> Also, I tried to homogenise the naming convention onto different axes.
That makes sense up to a point but we should not pursue consistency so far
that we abandon useful conventions, for example it makes sense to
express spectral resolution as a dimensionless fraction for line
observations, but angular resolution needs units.


> HSTECF.Summary.Coverage.Spatial: (J2000,0,360,-90,90), sparse (how do I
tell?)

Could be by fraction of the sky covered (for imageable data) or sources
per square degree (for catalogue lists).  And eventually by indexing? What
do people outside AstroGrid think of that?

Please can we use 'Angular' instead of 'Spatial'? I know I am a pedant,
but space is wot I measure in metres with a ruler, angles are wot I
measure with a protractor in degrees....

....................

>
> Third Level:
>
> This level is no longer a Summary level for the resource itself
> At this point we need to specialise per SubResource.
> In the case of HST this means that here we start describing Instruments
> and their characteristics

How will this be stored?  Will these in fact be separate datasets - e.g. a
datset containing a list of HST observations (your 4th level?) and a
dataset describing the instruments, as here in your 3rd level? And other
datasets e.g. details of astronometric and photometric reference stars/QSO
etc.  So maybe they are actually on the same level, but we need to
cross-reference datasets to be able to make full use of the data?  The
reason I see it like this, is that now we are at the level where I think
that the data provider, rather than the VO, has the main responsibility
for maintaining the data set contents and their description, for example
if a more accurate position or proper motion is established for an
astrometric standard.

best wishes

Anita