Trial 0.8.4

[Tony Linde]

Thanks, Ray.

> saying all resources are curatable.  I'm okay with making Curation 

I think if we're going to extend the resource schema into projects,
organisations (and, possibly, people) then they certainly aren't curatable -
an organisation does not have a curator (unless you put the janitor down :)
) so which person associated with an organisation do you put as the
'publisher'?

> I'm concerned that this is the inclusion of the table 
> description stuff 
> will draw fire on the DataCollection element from NVO.  

That's a rather worrying statement.

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

The key reason for including table data is to accommodate ADQL, not
AstroGrid. To use ADQL we need to know what tables and columns are in a data
collection (or the accompanying SkyService). How can you construct a query
if you don't know table names and column names / UCDs?

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

Catalogue is the data collection which has data in one or more tables -
apologies if I'm using the wrong terms.

> What non-VOTable data are we talking about?  Images?  If 

I just thought that the VOTable schema was overkill for what we wanted. 90%
of the schema is pointless and the rest (FIELD) is a completely different
structure to the rest of the registry schema.

> My VOTableColumns element required no changes to the VOTable 
> schema.  Note 

I see what you mean - but this doesn't allow UCDs to be associated at the
table and collection level, which I understand they can be.

Cheers,
Tony. 

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