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 Received on 2003-04-30Z19:09:51