Anita -- thanks for the pointers. For others who may wish to review Anita's
suggestions, note that the correct URLs are
http://wiki.astrogrid.org/bin/view/Astrogrid/RegistryUnits and
http://wiki.astrogrid.org/bin/view/Astrogrid/RegistryServiceMetadataConcepts.
When you say something "needs a namespace of recognized abbreviations" (as in Ticker/ShortName and PublisherID) do you mean like a pick-list? We have had some debate over whether ShortName really needs to be unique. Stock symbols are, and conflicts are resolved with sometimes rather arbitrary choices (LUV for Southwest Airlines, for example). So far it is only the Identifier that we have strictly required to be unique. I guess my approach would be to leave ShortName to the discretion of the resource publisher, and see if non-uniqueness is really a problem. Of the Sloan Digital Sky Survey and Schmidt Data Service System, who owns SDSS? Does it matter that they both use the same initials?
Am not sure about DataSize. There can be many answers for a given resource. HST archive DataSize might be 10 TB (entire holdings), 300KB (number of rows in pointings catalog), 160 MB (size of an ACS observation data set), 10 KB (size of a GIF preview image), etc.
UCDList: Not sure this is practical. A resource could have information on hundreds of UCDs. I'm not sure I could get through registering even one resource if I had to figure out in advance all the UCDs it might be able to provide information about. And do we actually learn anything by putting in things like POS_EQ_MAIN_RA when we also have metadata about spatial coverage?
I think the place to handle healpix is in the Space-Time Metadata.
We need a general specification concerning what to do with unknown, unspecified, or unapplicable metadata elements. For the RSM document I think I will use those or similar strings, recognizing that they might be implemented in other ways (NULL field in a database, for example, for unspecified).
Another potential metadata element we may wish to consider adding is a bibliographic reference, namely, the bibcode.
I don't think we need to debate the above points extensively right now. In the interest of moving ahead, as recent e-mails from Francoise Genova and Andy Lawrence have advocated, I will now try to finish up the RSM draft as quickly as possible.
Thanks,
Bob
>
> 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
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Dr. Anita M. S. Richards, AVO Astronomer
> MERLIN/VLBI National Facility, University of Manchester,
> Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
> tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
>
>
Received on 2003-06-19Z19:10:57