Hi Bob,
I hope that my notes at www.astrogrid.org/bin/view/Astrogrid/RegistryUnits are intelligible (it isn't just about units but it is painful to change wikiwords - drives people crazy trying to track changes). The comments in italics signify the things which I suggest adding to RSMv7. Basically - although some things (notably the metadata relating to meta-location) need explaining better for us blondes and redheads (see www.astrogrid.org/bin/view/Astrogrid/RegistrySeerviceMetadataConcepts - helped me, anyway!) - I think everything in RSMv7 is useful, but there are a few more things we need... I suspect the only thing which is controversial is putting in a list of UCDs. This is intended as something useful here and now for interoperability, what happens in the future depends on the future of UCDs. Other than that, if AstroGrid decides to have a few _extra_ elements that should not cause problems, I hope.
The items I have marked * are not yet in the AstroGrid schema, I think we should consider them for future and if Bob et al think they are a good idea maybe they will appear in RSMv8 but, as ever, I want to think about some real dataset applications before I am sure exactly waht is needed (v9...).
I have not attempted to incormporate the things you say below as we can deal with that in response to RSMv8.
Some of my suggestions may be covered by
> o Update description of Coverage.Spatial to utilize Space-Time Metadata
> region specification.
> o Change Ticker element to ShortName. We added Ticker just prior to the
> Cambridge workshop, and since then it has become clear that the definition
> of Ticker we were assuming is not even recognized very widely in American
> English. The 8-character limit also seems to be overly constraining.
I don't care about the element name, but, here and elsewhere, a namespace
would be the best way to cope with this? (Either that is painfully obvious
to everyone else or obviously wrong?)
> o Update list of acceptable Type values (add Organization, Project).
Fine
> o Rename the document. I'd prefer not, but will not make an issue of this
> if people care about it strongly.
Don't care - although I see Tony's point, I don't think the present name
is misleading, rather it is helpful for those who have not made the same
conceptual leaps.
Cheers
a