From: "Gretchen Greene" <greene-at-stsci.edu>
> I also endorse the ucdList element and hope to see this added into the
> VOResource schema. This element would simplify mining metadata content
> to find potential data sets which will satisfy data value driven query.
> In other words a high level filtering capability.
Gretchen et al
I am also interested in being able to store UCD information in the VO registry, as a way to select interesting resources. If the entity in the registry is a table of astronomical data, it would be good to put in UCD information. However, if the entity being described is not a table -- a project or organization, or a crossmatch service for example -- it is difficult to know what to put in the UCD section of the VOResource form.
The VOResource form is for information common to anything that might be in the registry -- title, creator, date, description, etc etc. But there should be specialized forms to describe other things.
When I fill in my taxes, there is a single form that everyone fills in, and a collection of optional forms (income from farming, gambling winnings, etc etc) for other aspects of the financial picture. In the VO registry, the single form is VOResource, and there is another form for describing, say, a table.
Therefore I think that UCD information should go into a new, separate document that can be attached to the VOResource. Just as we separated out the VOStdService, and we are building a schema for specifying a region of the sky, we should separate table description.
In fact this new document (table description) might be best expressed as a VOTable, but with no data. Surely this is the format of table metadata that we can all agree on?
Therefore there is no need for <UcdList><Ucd> .....etc. Right?
Roy Received on 2003-08-12Z22:14:28