Registry Schema v0.8.2

[Ray Plante]

Hi Elizabeth,

Thanks much for your comments--I'm a bit behind on my email but catching 
up.

On Wed, 24 Sep 2003, Elizabeth Auden wrote:
> 1. In VOCommunity-v0.1.xsd:
> 
> A. "DataCollRef" is separate from "ServiceRef".  Does "Service Ref" cover
> everything that's not a data collection, i.e. mySpace, communities, data
> models, data transformation and software packages (like SolarSoft, theXMM
> SAS, etc.)?  Should these services have their own ManagesType reference,
> or should they and data collections all be sub references under a more
> generic ManagesType reference?

ServiceRef was intended to refer only resources of class Service.  To 
refer to these other things we would at least have to add a generic 
"ResourceRef".  

This is a bit moot, as others have recommended that we drop "Manages" from 
Organisation as it is better to have these other things refer back to the 
organisation as its publisher.  

> 2. In VODataService-v0.2.xsd:
> 
> A. Element "DataCollection" is described as "a collection of
> digitally-encoded data accessible as a single unit" - will this definition
> fit data collections like 1XMM that are made up of multiple data
> collections?  Can a DataCollection contain other DataCollections?

Actually, that's the definition of a "dataset".  A DataCollection is a 
"logical grouping of data which, in general, is composed of one or more 
accessible datasets." 

> B. Formats can be MIME types or not MIME types.  Is it worth having an
> attribute that specifies "MIMEtype = true or false" to aid automation (ie,
> "if format = .wav, play file; if format = cd-rom, do not attempt to play
> file), or should that choice be left up to service implementors?

good idea.

> C. RightsType: Is it worth adding "administor" as a type to indicate
> whether the data held can be added, edited, or deleted?  For instance, if
> someone publishes a derived dataset, they may wish to indicate to the
> world that this data may change at their whim if reprocessed by improved
> models, but if another person or organization mirrors this dataset, they
> would not be able to change any of the data.

This is an interesting concept that we should look into.  Are you 
suggesting adding an additional value (along side "public", etc)?  
Right now, only one "Rights" is allowed; thus the choices must be mutually 
exclusive.  

My suspicion is that "Rights" will need more development in the
future; however, we probably don't know enough to fully define it
now.  I might recommend we keep a mental sticky on this idea unless
you think you need it now.  

> D. SkyService: I've talked to a few solar people at MSSL - it may be
> useful to give this a more generic name if it will be extended to solar,
> planetary, and atmospheric data: perhaps "ObservationService".  Otherwise,
> it would be nice to include sibling service types such as "HelioService",
> "PlanetService", "TerrestrialAtmosphereService", and so forth  (I realize
> that this has already been debated with references to
> "siderealSkyService", etc.)

I suspect that it would be better to make SkyService more specialized
to astronomy and later define sibling service types for the other
fields, as you suggest.  I'm still open for suggestions for a
different name.  

> 4. In VOResource-v0.8.2.xsd:
> 
> A. ResourceKey: how will this be generated?  Will each unique key include
> versioning, or will the key change if a resource is updated but old and
> new versions exist simultaneously?

It's completely up to the data provider.  If they don't want to bother
tracking different versions separately, they can effectively have new
versions retain the same ID, replacing the old version.  (This might
cause other resource metadata to be updated accordingly.)  I expect
this to be the norm.  

> B. Description: Is this equivalent to a README or will it be a URL to a
> README?  Anita and I discussed this in the current Astrogrid resource and
> decided to make the equivalent  README be a URL pointing to the
> appropriate file.  The reasoning is that if a user queries the registry
> for all metadata on a services containing data about stars, a whole lot of
> screen space is going to be taken up by full reproductions of README
> files.

Sounds like a good idea.  This URL can be stored in the "ReferenceURL".

> C. CatagoryType:  (This is nitpicky, but I think it should be spelled
> "CategoryType".)  

Not at all--thanks for pointing this out.

> The enumeration includes a choice of "simulation", but
> there should be another choice that indicates data transformation other
> than a simulation, such as procession, astrometric alignment, etc.  I
> can't think of a good name other than "DataTransformation".

Good idea--we can add this.  

> F. Instrument: Should there be a category for "sub-instruments"?  An
> example: Facility would refer to XMM-Newton, Instrument would refer to the
> Optical Monitor, but how would one specify "data from the UVW1 filter"?
> Maybe a Filter or Grism element?

Would having multiple "Instrument" elements take care of this?

cheers,
Ray