Trial 0.8.4

[Ray Plante]

Hey Tony,

Thanks for the contribs.  Perhaps we should discuss the details next week 
(where we might get some beer involved).

I've only looked these over briefly (as I scramble to get my stuff 
together).  Here are some quick comments...

> 1. make more of the elements in ResourceType optional, in particular the
> Curation element: inheriting a PersonType from this would not make use of
> Curation and this avoids having to inherit by restriction. I'd make all
> elements optional except the identifier.

In the last revision, I changed what was required based on some feedback
from Roy and others.  The motivation was to set the minimum information
that must appear in the registry for each resource.  This need not
translate into restrictions set at the schema level; however, it certainly
makes verification by registries easier.  This was the recommendation that
came out of NVO as what should be required:

    * Identifier
    * Title
    * Summary/Description
    * Summary/ReferenceURL
    * Type (at least one value)
    * Curation/Publisher/Title
    * Curation/Contact/Name

Can we make this a discussion item at our Registry session?

> 3. we need to be able to describe the tables and columns in a dataset so
> I've created table, UCD and column types and elements. I've allowed UCDs to
> be added to the dataset, table and column levels. I've got each column
> described with mandatory column name and optional UCDs, data type and unit
> (latter two may need work: enumerators perhaps).

I was thinking that it would be better to put this table description 
information into a new Resource class called Table (which could inherit 
from DataCollection).  The idea is that some data collections, for 
example, contain images rather than tables.  

More importantly, I think, is that by putting it into a separate resource 
class, it can be put into a separate schema (with its own namespace) and 
put through the standardization process separately.  That is, working 
out the Table descriptions need not hold up the standardization of 
VODataService.  We can still prototype, however, with the proposed Table 
description schema.

Two other tidbits come to mind:
  *  This came up in our telecon today: Vizier tables are organized into 
     table collections--each associated with publication.  That is each 
     collection might have 1 or a few tables in it (where one might be 
     considered the primary table).  Would it make sense to define, 
     instead of a Table class, a TableCollection class, allowing each of 
     the component tables to be described?

  *  What do you think of the idea of re-using VOTable elements to 
     describe tables?  Perhaps you saw in "VOTableColumns" defined in the 
     VODataService schema.  This is used in the SIA and ConeSearch schemas 
     to describe the tables returned by these services.  

cheers,
Ray