AstroGrid registry structure

[Tony Linde]

Hi Ray,

As usual, easy bit first - we do not disagree on the registry content. Every
resource will go in the/a registry. In AstroGrid, ServiceRegistry,
CommunityRegistry and perSpaceRegistry will conform to a common IVOA
interface. Whether we use the same or different software and whether we add
extra, specific, interfaces to the common one is undecided. I thought that
was clear from my document: the summary lists the *full* registry mode; the
AG approach defines the *class* mode which allows our registries to keep
only resources for a given class (may not be a new mode, just another
version of *specialist* mode); the uml diagram shows all resources as
belonging to a common class of ResourceRegistry.

> I could also use further clarification on what the drivers 
> are for a redesign of the metadata model.

So far we (as in IVOA Registry WG) do not have a metadata model. We have
your approach (which may be the US-VO agreed model) and we have my approach
and I think we're working towards a consensus model.

Bob's RSM document is probably better presented as a Note rather than a
'Working Draft'. The WG as a whole has not discussed issuing it as a WD and,
as you know, I have reservations about whether it can represent registry
metadata.

I don't see this as a problem. A lot of the elements in the RSM are well
defined. What we are talking about now is the way that they are put
together: the structure of the registry metadata.

> There is the concern that some or much of what is currently 
> called the generic resource metadata does not apply equally 
> well to all resources.  That is a legitimate concern which I 
> agree with at some level.  The solution that remains 
> consistent with the model is to move the metadata of limited 
> applicability to the extensions of the appropriate class.  

That might work. Though in my view, the only *common* metadata applicable to
*all* resources is the identity info and the class id. Curation has
different meanings for each type of resource. If by Curation, you mean just
the curation of the registry entry, then I agree that could go into the
common area, but if you mean curation of the resource itself then it really
should be class-specific. The curation of a service must have a different
meaning to the 'curation' of a person (and I don't think I'd use the work
curation at all).

> I think the key difference is that in 
> my model, which metadata items can be included is controlled 
> completely by the schema defining the class.  More precisely, 
> a class is defined by (1) a semantic definition, and (2) a 
> defined set metadata used to describe it (i.e. in XML-speak, 
> its type).  In your model, the class defines some of the 
> metadata, but the rest is the choice of the registrant 
> (yes?). 

Probably :) Actually, I think the answer is 'yes'.

I can see what you are getting at and to some extent, I agree. It does not
make sense for a Person resource to contract to provide 'DataAccess'
metadata nor for a DataAccess resource to include metadata specific to a
Person.

What we need is some form of combination of the two ideas... 

I have uploaded a new UML diagram to my document - check that out. It shows
that a resource listing consists of one piece of IdentityMd and one of
ClassMd only. The ClassMd then is composed of the MMs appropriate to that
class...

Actually, the more I write and think, the more inclined I am to your view,
certainly for CommunityCmd: do not want to have a resource defined as a
Person to include Group metadata.

As for perSpaceCMd it doesn't make sense for psServerMd to be combined with
FileMd or XmlMd etc. But we might want to combine XmlMd and TableMd. Maybe
we dump XmlMd which would leave us with the choice of psServerMd, FileMd,
TableMd, so that one might work.

The difficult one is ServiceCMd. Certainly it can only be either Service or
Reference type of item. But can we be certain that a service will never want
to offer both a DataAccess service and a CatalogExtraction service. I guess
there are two solutions: either we reduce the amount of metadata associated
with a service to just the common stuff but that would restrict searches too
much I think; or we could force the registrant to simply enter the service
twice, one for each type of service - that'd mean two IDs for the same
service but that may not matter.

How would your extension idea cope with this issue?

Hate to say it, but I am going back to my original view. Looking at the
CommunityCMd again: we would want to include say the MMs for AstronomerMd
and for ProjectManagerMd for the same person. And there may be flavours of
Group, Organisation etc where you would want to include more than one MM.

Yes, I think the MM approach is still best but we need to push the
multiplicity boundary further down the model, and down to different levels
for each class. And that might change in the future as we want to register
different types of resource, say under the perSpaceCMd.

(Hope you don't mind the above rambling but I thought I'd leave it as it
shows more detail about why I think the MM apoproach is better and gives you
more scope to counter it.)

> Finally, I wanted to stress the importance of considering how 
> we render metadata in XML... The disadvantage of metadata 
> modules is that it suggests a mechanism outside of the XML 
> technologies for "contracting" support for different schemas. 
>  That is, the modules supported are listed in some tagged way 
> in the resource metadata.  We have to implement mechanisms 
> (on the client and server sides) for figuring out which 
> modules we want and to retrieve them. 

I don't see how the MM approach is non-xml. It is all expressed in a schema,
an xsd file. The resultant xml is parsed with normal xml parsers. The MMs
are simply optional bits of xml. What problem is there?

I'll try to rework the uml diagram to take into account the above ramblings
and then work on the schema as well. Maybe by the time you get in I'll have
done so.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Ray Plante
> Sent: 11 June 2003 21:44
> To: registry at ivoa.net
> Subject: Re: AstroGrid registry structure
> ...