Scope of registry

Tony Linde ael at star.le.ac.uk
Thu Feb 6 09:52:39 PST 2003


> However in my previous email I was refering to the "front-end" of the
> Registry service(s) i.e. what can clients get from a  Registry e.g. "tell
> me
> everything you know about area of sky X?" or "where is the best place to
> join catalaog Y to catalog Z?" or "who do I ask to get access to resource
> B?" or "how do I convert magnitude-A to magnitude-b?"

I would assume that all these are answered by:

> List Metadata Formats (what schemas do you have for metadata)

This describes the types of information held in the registry. The
'client' (portal or client) would need to 'understand' this metadata and
how to use it. So if there is a resource which *can* provide the answer
to "where is the best place to join catalaog Y to catalog Z?", the client
would need to know what *type* of resource will provide such an answer
(eg TableJoinService type) and will need to query the registry asking
which resources of type 'TableJoinService' can cope with a catalog of
type Y and a catalog of type Z. 

This is probably astro-drivel but I hope you can see what I'm getting at.
I suppose Roy will come along and say that I'm talking complete-drivel!

The idea that we can send a generalised query like "where is the best
place to join catalaog Y to catalog Z?" and the registry will be able to
interpret this and work out what the client really wants will have to
wait for the AstroOntology-based registry (cue Elizabeth :).

Cheers,
Tony.

On Thu, 6 Feb 2003 17:05:36 -0000 , "Giaretta, DL (David) "
<D.L.Giaretta at rl.ac.uk> said:
> The simplest service in this that context is probably
>    CanYouAnswerThis( some text )
> which a Registry would send to every resource on its list - delegating
> the
> question it received.
> 
> A Registry itself could have a service "PleaseAddMeToYourList" which an
> external resource could use to get itself added to a Registry's list of
> things to send message to.
> 
> The OAI verbs provide a high level "back-end" protocol, which optimises
> how
> a registry would work and gather information.
> 
> However in my previous email I was refering to the "front-end" of the
> Registry service(s) i.e. what can clients get from a  Registry e.g. "tell
> me
> everything you know about area of sky X?" or "where is the best place to
> join catalaog Y to catalog Z?" or "who do I ask to get access to resource
> B?" or "how do I convert magnitude-A to magnitude-b?"
> 
> Once we get those front-end questions sorted out then some of the
> optimisation-type (back-end) questions should become clearer.
> 
> ..David
> 
> 
> -----Original Message-----
> From: Roy Williams [mailto:roy at cacr.caltech.edu]
> Sent: 06 February 2003 15:44
> To: Giaretta, DL (David) 
> Cc: registry at ivoa.net; metadata at us-vo.org
> Subject: Re: Scope of registry
> 
> 
> > We surely need to define what services the Registry should
> > provide - and recognise that we don't need to make an
> > exhaustive list now because we should be able to extend it.
> > All registries need to sign up to this set of services -
> > or at least be able to specify what sub-set it adheres to
> 
> In the OAI model, there are exactly six verbs that the registry
> understands.
> The verbs are:
> 
> Identify (who are you)
> List Metadata Formats (what schemas do you have for metadata)
> List Sets (collections hosted by this repository)
> List Identifiers (return just the identifiers and dates of most recent
> change)
> List Records (return full records)
> Get Record (return a full record from its identifier).
> 
> This is a pretty basic set of services!
> 
> If a registry has an OAI interface, it can have others too. ArXiv and ADS
> brought up OAI long after they had their native interfaces.
> 
> In addition to OAI, we would need to define and implement a query
> language
> using additional verbs. If, for example, we define each survey by its sky
> coverage, then OAI provides no way to ask for every survey that covers
> Orion.
> 
> Roy
> 
> --------
> Caltech Center for Advanced Computing Research
> roy at cacr.caltech.edu
> 626 395 3670
> 
__
Tony Linde                       Phone:  +44 (0)116 223 1292
AstroGrid Project Manager        Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy      Mobile: +44 (0)7753 603356
University of Leicester          Email:  ael at star.le.ac.uk
Leicester, UK   LE1 7RH          Web:    http://www.astrogrid.org

-- 
http://fastmail.fm - Choose from over 50 domains or use your own



More information about the registry mailing list