MyUCDs & Registry

[Gretchen Greene]

Thanks for the insights Ray,  I realize I missed out on some discussions
that occurred at the IVOA.  Still,  in building this first registry with
the existing schemas,  I am finding that there are subtleties to the
implementation and my concern is in chasing down multiple schema
versions and metadata definitions prohibits efficient prototyping.  For
example,  the existing repositories (OAI, previous Cone registry, etc.)
all have varying elements and content.  Now which schema files to I
pursue to bring about uniformity?  This is only the very beginning.  

The other point is that there are not huge numbers of entries/resources
yet in these registries (remember I'm used to the GSC2 billions) and so
it seems a little odd to create a highly designed configuration before
ever implementing one even though the design ideas are good ones.  

So...I cheer on the designing but encourage people to start working with
the standard schemas/files and see how they interface before going too
far.

-Gretchen




-----Original Message-----
From: Ray Plante [mailto:rplante at poplar.ncsa.uiuc.edu] 
Sent: Monday, May 19, 2003 2:43 PM
To: Gretchen Greene
Cc: ucd at ivoa.net; registry at ivoa.net
Subject: RE: MyUCDs & Registry

Hi Gretchen,

On Mon, 19 May 2003, Gretchen Greene wrote:
> If the registry is going to supply 'Subject' , i.e. keywords for
> targeting specific astronomical topics, then I think it would equally
> serve to provide the UCDs and their associated tags (units, type,
etc.)
> for refining queries.  
> 
> Not to sound harsh,  my only question is why do we have to consider
> generating more schema files to do this?  UCD's are fundamental
> descriptors in my mind and could be included in the base terms as
> optional elements.  I guess the discretion comes from service
providers
> with column descriptions not mapped into UCD's?

There is precedence for integrating it into the generic resource
metadata:  
the current VOResource contains Coverage.  However, it was pointed out
last week that it is unclear, for example, what Coverage means when it
applies to an organization.  It was suggested (and I plan to look at
this)
that Coverage only be associated with descriptions of Data Collections
and
Services.

I mention this because it illustrates a basic modeling issue.  When UCDs
are associated with a description of an SIA service, it can be made
clear
what the role the UCDs play in the service (i.e. these are the UCDs
associated with the columns returned from an image query).  Similarly,
the
connection is clear when made part of a Catalog description.  However,
if
they are associated with a generic resource, their role is ambiguous.  
That is, what does it mean to search for Organizations based on UCDs?

> my only question is why do we have to consider
> generating more schema files to do this?  

Your question suggests that dealing with multiple schema files has 
additional overhead costs associated with it (as opposed to just have
one 
schema).  Do you see this as a problem?

We put the metadata that is not purely generic Resource metadata into a
separate schema because it makes for a friendlier extension mechanism.  
If we add new metadata that, say, specifically describes Catalogs into
the
VOResource schema, it affects all users of this schema regardless of
whether they care about Catalogs.  (They may have to change their
software
to cope with the new version.)  However, if we put the metadata into its
own schema that extends VOResource, it only affects those that want to
describe Catalogs.

cheers,
Ray