AstroGrid registry structure

[Tony Linde]

> I think the elephant is useful here. As you point out, the 
> concept of "project" can have different interpretations to 

I don't think that was what I said (or certainly not what I meant), Roy. I
don't see any problem in coming to some agreement about what metadata is
relevant to describing a project. I just don't think one block of metadata
(which includes curation and coverage) is relevant to *all* resources such
as people, project and service.

As I also said, if 'Curation' refers to the curation of the registry record
then I agree that it should go into the base metadata set for all resources
but not if if refers to the curation of the resource (who 'curates' a
person?).

> In OAI, each object can have multiple metadata descriptions, 
> one for the financial office (who are the funders), one for 
> the librarian (subject index), one for the grid engineer (the 
> WSDL files).

That was what I was trying to get at with the metadata modules (MMs)
approach but removed it as it seemed Ray did not like the idea of a resource
choosing which MMs it would contract to provide. I still think it would make
the whole schema more flexible and would be happy to re-include it, even if
we 'fixed' it by saying that given classes/types of resource must provide a
fixed set of MMs.

> The reason that curation is so special is that is that it 
> aligns with Dublin Core, which is a standard curation 
> labelling already used by a very wide community -- the entire 
> digital library world! Therefore it will be easy for a VO 
> registry to become part of a wider University Library system 
> if we decide that curation information should be mandatory.

I have no aversion to DC but I thought it was concentrated on bibliographic
resources. Does DC have a 'Person' entity? And if so, what does curation
mean for that entity? 

I'm not sure that conforming to DC buys us enough to warrant making our
metadata less meaningful at the outset. Maybe we should concentrate on
getting the metdata that really describes VO resources and *then* look at
how we make that metadata harvestable by DC routines (eg by transformations)
- shouldn't be too difficult.

> Some Entities have been suggested by the NVO: Coverage, Data 
> Collection, SIAP service, and each has a suggested schema. 
> Let us start thinking of Entities and their different types 
> of metadata description (Schemata).

That is what I have suggested. But I think it would be useful to decide how
the overall metadata is structured first. 

I think VOResource is not right as it seems to mandate that every resource
shares metadata that simply isn't applicable (like curation and coverage).
I've suggested that resources should share base metadata (such as identity
and possibly resource record curation) and that they then split into
classes. 

The classes I've suggested are Service, Community and perSpace but that is
based on how AstroGrid works and I'm open to alternatives. But class
metadata will share common items and types (like curation for Service and
possibly perSpace classes, invocation for Service classes) and then types
within that class will have their own specific sets (or modules) of
metadata. So, services which access portions of the sky will have 'coverage'
metadata (data access, image access etc services) while services which act
on files (file transfer, format transformation, etc) will not.

It is this ideal of structure and how we implement it that I think needs to
be agreed first - then we can get on with defining what the classes are,
what the types within classes are etc and then the metadata for each of
these subdivisions.

Cheers,
Tony. 

> -----Original Message-----
> From: Roy Williams [mailto:roy at cacr.caltech.edu] 
> Sent: 15 June 2003 00:49
> To: Tony Linde
> Cc: registry at ivoa.net
> Subject: Re: AstroGrid registry structure
> ...