MyUCDs & Registry

[Gretchen Greene]

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?

-Gretchen


-----Original Message-----
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

Hi Guys,

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
catalog
description, using the generic Resource metadata as a starting point.
We
would ask ourselves what additional information do we want in the
description.  Column UCDs and names would be an example of that type of
information.

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
you 
can stick in a FIELD element and its children).  This could be done for
a 
catalog description as well (regardless of whether it is actually 
available in VOTable format).  

hope this helps,
Ray



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,
ie,
> >>>	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.
> >>
> >>Cheers,
> >>    Marco
> >>    
> >>
> >
> >Hi Marco,
> >
> >well, I would have thought so. It's done already by vizier
meta-information
> >tables (which could be considered a local registry) and surely by
other
> >services. It's a good point though, how much is a registry supposed
to
> >know? In the scheme that Keith Noddle presented in Cambridge, I would
> >expect at least the local register (read service provider's) should
know
> >about about this. Whether the higher level registers decide to
collect this
> >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
volume
> >here; the advantages are large though, as you don't have to go
everywhere
> >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
they
> >asked; then a consultant phoned us and we dealt with him, he found
out
> >who would lend us the money and it worked fine. The analogy seems
quite
> >appropriate for our situation in VO. An astronomer wants to formulate
a
> >general query, he or she has no idea where this could be done, so
s/he
> >asks a service to lauch the query urbe et orbi... Surely the data
will
> >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
off
> >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
broker-services urbe
> >et orbi, and let those services do the filtering and send the query
to
> >places which may give a positive answer.
> >
> >IMHO not using this meta-information would be a real waste.
> >
> >Cheers,
> >
> >Patricio
> >
> >---
> >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
> >
> 
> Patricio,
> 
>     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
same 
> before sending the query, if the registry has enough information about

> services (this is not the case if we think of registries containing
only 
> references to other registries, but this will simply add one more
level 
> 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
then 
> 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
a 
> well-defined detailed query, with specific result even in the "urbi et

> orbi" case.
> 
> 
> Cheers,
>     Marco
>