Trial 0.8.4

[Tony Linde]

Hi Ray,

>     * 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.

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

The more we can get sorted beforehand the better: we need to resolve most of
http://ivoa.net/forum/registry/0730.htm .

> 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.)

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!).

>      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?

I don't think I understand - would this not be solved with a DataCollection
which could describe component tables?

>   *  What do you think of the idea of re-using VOTable elements to 
>      describe tables?  Perhaps you saw in "VOTableColumns" 

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.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Ray Plante
> Sent: 09 October 2003 17:59
> To: registry at ivoa.net
> Subject: Re: Trial 0.8.4
> 
> 
> 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
>