MyUCDs & Registry
greene at stsci.edu
Mon May 19 10:43:23 PDT 2003
If the registry is going to supply 'Subject' , i.e. keywords for
targeting specific astronomical topics, then I think it would equally
serve to provide the UCDs and their associated tags (units, type, etc.)
for refining queries.
Not to sound harsh, my only question is why do we have to consider
generating more schema files to do this? UCD's are fundamental
descriptors in my mind and could be included in the base terms as
optional elements. I guess the discretion comes from service providers
with column descriptions not mapped into UCD's?
From: Ray Plante [mailto:rplante at poplar.ncsa.uiuc.edu]
Sent: Monday, May 19, 2003 1:24 PM
To: ucd at ivoa.net
Cc: registry at ivoa.net
Subject: Re: MyUCDs & Registry
The current registry model allows for catalogs to be registered
individually and that the descriptions stored in the registry could
contain all the information that Patricio listed. The main question is
how fine-grained you want the registry to be and, thus, whether catalogs
are within your limit.
I think we heard at the interop meeting last week sufficient interest in
registering catalogs. So then the next step would be to model the
description, using the generic Resource metadata as a starting point.
would ask ourselves what additional information do we want in the
description. Column UCDs and names would be an example of that type of
I'll note that in our prototype schema for describing SIA services, we
included a description of the columns returned by an image query. This
was done using the VOTable FIELD elements; thus, it included both the
local names and the UCDs (along with the IDs, type, and anything else
can stick in a FIELD element and its children). This could be done for
catalog description as well (regardless of whether it is actually
available in VOTable format).
hope this helps,
On Mon, 19 May 2003, Marco C. Leoni wrote:
> Patricio F. Ortiz wrote:
> >On Mon, 19 May 2003, Marco C. Leoni wrote:
> >>Hi Patricio,
> >> one question about the point below:
> >>> Let me include here another element before the submission of a
> >>> query to the resource handling catalogues: The registry.
> >>> Any registry will contain metadata about the services listed,
> >>> the catalogues.
> >>> The registry would know (among other things),
> >>> - catalogueName (possibly catalogueUniqueID)
> >>> - catalogueTitle
> >>> - catalogueKeywords
> >>> - catalogueAuthor
> >>> - number of columns
> >>> - number of records
> >>> - column names, UCDs, units
> >>> - name ID,MAIN ---
> >>> - RA POS_EQ_RA,MAIN h:m:s
> >>> - Dec POS_EQ_DEC,MAIN d:m:s
> >>> ....
> >>> - Vmag PHOT_JHN_V mag
> >>> - Bmag PHOT_JHN_B mag
> >>> - z REDSHIFT ---
> >>are you sure the Registry will include all these information?
> >>Perhaps "column names" and "units" will be resolved by the service
> >>provider, and not by the registry itself.
> >> Marco
> >Hi Marco,
> >well, I would have thought so. It's done already by vizier
> >tables (which could be considered a local registry) and surely by
> >services. It's a good point though, how much is a registry supposed
> >know? In the scheme that Keith Noddle presented in Cambridge, I would
> >expect at least the local register (read service provider's) should
> >about about this. Whether the higher level registers decide to
> >information is to be seen, but if you ask *me*, I would say yes, they
> >should keep this information. We are not talking about a huge data
> >here; the advantages are large though, as you don't have to go
> >with your query.
> >I just had to deal with getting a mortgage and run from bank to bank
> >filling up applications not knowing if I satisfied all the conditions
> >asked; then a consultant phoned us and we dealt with him, he found
> >who would lend us the money and it worked fine. The analogy seems
> >appropriate for our situation in VO. An astronomer wants to formulate
> >general query, he or she has no idea where this could be done, so
> >asks a service to lauch the query urbe et orbi... Surely the data
> >come back to the astronomer, but if we apply a filtering system which
> >can select the services which may give a positive answer (and weed
> >the ones with a negative), then the number of transactions diminishes
> >and the response time is shorter.
> >An intermediate solution would be to send the query to
> >et orbi, and let those services do the filtering and send the query
> >places which may give a positive answer.
> >IMHO not using this meta-information would be a real waste.
> >Patricio F. Ortiz pfo at star.le.ac.uk
> >AstroGrid project
> >Department of Physics and Astronomy
> >University of Leicester Tel: +44 (0)116 252 2015
> >LE1 7RH, UK
> I agree that a filtering system would be nice, and in fact a
> registry is supposed to do that (in my opinion): if necessary it will
> send an "urbi et orbi" query and give back to the astronomer only the
> relevant results, where this means compare them with the original
> requirements (e.g. exclude all the "no info about it" answers). The
> before sending the query, if the registry has enough information about
> services (this is not the case if we think of registries containing
> references to other registries, but this will simply add one more
> to the structure).
> What I meant before is that probably we need only UCDs in the registry
> without any unique column names: when the query reaches the service
> it will be translated and UCDs mapped to comlumn names.
> - On the other side, if the user already knows the unique column name
> then using it will remove any control about UCDs.
> - Last possibility, giving both unique column name and UCD will create
> well-defined detailed query, with specific result even in the "urbi et
> orbi" case.
More information about the ucd