MyUCDs & Registry

[Ray Plante]

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
>