Resources = services!

[Ray Plante]

Hi Tony,

> I certainly think we should have the same metadata structure and approach:
> my previous proposal for curation plus metadata formats, which seems to
> match your curation plus extensions. Whether common curation metadata for
> 'services, community and mySpace' makes sense is difficult to say - I cannot
> see a lot of commonality (and I sure as hell do not want to start debating
> the contents of the 'Creator' item for people :) ).

I think it is sensible to review the major "supertypes" as you call them 
in terms of whether our generic metadata is sensible for all of them.

> (I don't like the Ticker or ShortName - this gets
> us straight back into managing uniqueness again) 

This is a bit of a red herring.  ShortName was never meant to be 
guaranteed unique (that's what the identifier is for); therefore, it can 
be handled exactly like Title.  However, it did come directly from a real 
application need (Tom's DIS), so I think it is worth retaining.  

> 2. Resources fall under a small set of supertypes: currently 'services,
> community and mySpace' (we'll change the name of mySpace to an IVOA generic
> name later). So, identity metadata for each resource will include a
> SuperType item.

I would like know a bit more how you see the "supertypes" relating to what 
is currently in the Schema.

In the VOResource XML Schema, there are what I have called 
Resource "classes" (as in, major type).  Currently defined are:
   Resource
   Organization
   Project
   DataCollection
   Service
The class defines what additional sets of metadata, beyond the generic 
Resource metadata, are available to describe the Resource.  Additional 
classes are envisioned and can be added at anytime in the future (subject 
to the standardization process).  

Do you see "supertypes" as...
  o  essentially the same thing as "classes" (that is, it captures most 
       of what you're going for),
  o  an alternative to "classes", or
  o  a concept to be used in addition to "classes"?

> 4. Resources also include MFs or extensions specific to their types. A
> resource can contract to provide more than one MF.

While I'm not against multiple MFs, I'm still unclear on the how you see
this being used.  Are MFs and extensions synonymous?  Do expect that
subcommunities (or sub-VOs; e.g.  AstroGrid) wanting to use a specialized
format that is only supported within a realm of resources?  Is this a
hedge against new formats in the future?

cheers,
Ray