Trial 0.8.4

[Ray Plante]

Hi Tony,

On Fri, 10 Oct 2003, Tony Linde wrote:
> >     * Identifier
> >     * Title
> >     * Summary/Description
> >     * Summary/ReferenceURL
> >     * Type (at least one value)
> >     * Curation/Publisher/Title
> >     * Curation/Contact/Name
> 
> I can live with all except Curation being mandatory since not all resources
> will be curated (happy with Publisher/Title & Contact/Name) - would prefer
> Summary to be optional as well for same reason.

I think the essential issue being raised here (again) is whether we're 
saying all resources are curatable.  I'm okay with making Curation 
optional to allow greater flexibility, but I know others feel more 
strongly about this than I do.  (Prod.)

> > 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.  
> 
> Maybe a TabularDataCollection and ImageDataCollection - I don't think we'll
> get people creating separate Table resources. Or we could have
> DataDescription (as I defined it) contain both table and image data so
> DataCollection could apply to both - they'd be optional so curator could
> fill in whichever was appropriate - would also then apply to colleciton
> which held both images and catalogue(s). 

> (This'd also keep the schema
> flatter which I thought was a NVO goal.)

Flatness is not necessarily a goal, but clarity it is.  The 
ManagedResource drew criticism for being too abstract and for drawing what 
some people felt was an unnecessary distinction between curated resources 
and non-curated resources.  

> I completely agree with separation of classes etc for schema maintenance but
> I don't think we can do that this time around (before Jan demo that is) - we
> can look at logical separation after Jan (if any of us is still sane!).

I'm concerned that this is the inclusion of the table description stuff 
will draw fire on the DataCollection element from NVO.  Alternatively, if 
you (Astrogrid) define a new, say, TabularDataCollection resource class in 
a separate extension schema, you can use it on your end and we (NVO) can 
ignore it on ours.

Sociologically, it's much easier.  On my own volition, I defined and 
posted an extension schema for handling Cone Search services (which is how 
we'll be registering catalogs).  It's outside the discussion of the other 
schemas.  If we put the table description directly into DataCollection, it 
affects us all.  

> I don't think VOTable is appropriate for the types of table in catalogues,
> is it? We cannot really fiddle with the VOTable schema in order to make it
> fit non-VOTable data.

(Hmm, I detect that you distinguish between a "table" and a "catalogue".  
Could you clarify?)

What non-VOTable data are we talking about?  Images?  If there is an
examples of a table that cannot be encoded as a VOTable, then you have a 
point.

My VOTableColumns element required no changes to the VOTable schema.  Note 
also that I don't use the entire VOTable schema, just the FIELD element 
and its contents.  FIELD captures all of the information (and more) that 
your "Column" element does.  

It's just a suggestion.  I want to encourage the re-use of existing 
metadata, and discourage creating new redundant metadata.  

cheers,
Ray