comments

[Tony Linde]

> I am trying to push OAI. I believe it to be just the simple and
> flexible standard that can federate our registries.

>From what you've written so far, Roy, OAI does look useful. We need to
look at it in detail and see how much of it we want to implement. There
seem to be standards for document format, layout and exchange and others
for the protocols of how the registries work. I don't know enough about
it to comment on any of these, but assume that we could adopt the format
and layout and choose our own registry protocols if it better suits us.

I think the best use of OAI, GLU at this stage is to help us define the
requirements for VO registries and how they interoperate, eg:

> It works because the protocol is *harvestable*

do we 'need' registries to be harvestable? and is it mandatory or
optional? and how does a registry specify its harvest area? etc.

> A harvestable protocol means a
> distributed virtual registry.

As could a peer-to-peer 'push' type of protocol.

> I don't care if your brain is
> made of cheese, so long as you say the right things! 

You promised not to repeat that!!

> If you want to
> record pages, then our robot will probably not harvest them. It will
> only ask about the larger entities (tables).

A good reason for 'harvest' rather than 'push': to ignore info the
registry not able to use. But do we want this?

> > Likewise in AstroGrid we are
> > starting to make some specific technology choices that we should not
> > necessarily force on others.
> 
> What are these specific technology choices?

The choices are, firstly along the lines of your granularity choice -
which will probably turn out to be the same as your level - and secondly,
we are going to build a working registry within the next six months -
which is why we're pushing to get people discussing this stuff now.

Getting back to the requirements, I guess we need to distinguish between
requirements and options. A requirement would be that each registry
'knows' about the resources in other registries. Options for fulfilling
that would be a harvesting method or a push method (among possibly
others). We'd then need to get into technical options of how the chosen
method was defined as a protocol.

Anyone want to start pumping in some requirements?

Cheers,
Tony (on a Java course, not paying attention).


On Mon, 3 Feb 2003 08:20:40 -0800, "Roy Williams" <roy at cacr.caltech.edu>
said:
> Andy
> 
> I am trying to push OAI. I believe it to be just the simple and
> flexible standard that can federate our registries. Librarians use it
> everywhere. The ADS uses it.
> 
> > (1) I strongly agree that we must keep the VO an enabling
> infrastructure
> > rather than an actual structure. Getting the right approach to the
> > Registry is a key step in getting the philosophy right. We shouldn't
> be
> > over prescriptive. It should be possible to have multiple
> Registries.
> > Registries should not require a supervising authority. A Registry
> should
> > be a service somebody can offer competitively, just like offering
> data
> > search services  etc.
> 
> The OAI model is based on multiple registries (eg one at Edinburgh,
> one at Caltech, etc). There could also be collector registries (eg
> Astrogrid, AVO, NVO). It works because the protocol is *harvestable*.
> You can ask for identifiers of all records that are more recent than a
> given date. Therefore a robot can do this on a regular basis, grabbing
> everything new from a group of other registries, so new records in one
> registry percolate to others. A harvestable protocol means a
> distributed virtual registry.
> 
> > (2) On the other hand, we want as much as possible of the software
> we
> > develop in the various VO projects to be inter-operable.
> 
> I think that the IVOA *must* agree on something harvestable, otherwise
> nobody will be able to find what has been published.
> 
> The GLU system is made to be harvested. I think I know how to build a
> OAI service on top of GLU. I believe that UDDI is also harvestable,
> but I think the only things you can regiater in the registry are web
> services. With OAI you can register anything you like.
> 
> > (3) Each VO project should be free to use its own choice of
> > implementation technology, consistent with the interoperability
> > principle, and also free to make design choices, such as whether
> their
> > registry is fine grained or coarse grained. (At this stage we
> probably
> > want to positively encourage a diversity of choices, for technical
> > experimentation.)
> 
> I agree entirely about implementation. I don't care if your brain is
> made of cheese, so long as you say the right things! However, I point
> out the large collection of open-source tools at the OAI site:
> http://www.openarchives.org/tools/index.html
> 
> Once we have something harvestable, the next choices concern the
> nature of the entities that are described in the registry, which then
> crystallizes to the XML schema used to describe that entity. This
> comes to the graininess issues. In a telecon last week, we (NVO)
> thought it would be good to register a *table* (ie catalog) into the
> registry, but it would not be good to register each *record* from that
> table. (Librarians record books, not pages from books.) If you want to
> record pages, then our robot will probably not harvest them. It will
> only ask about the larger entities (tables).
> 
> In order to make a IVOA regstry of tables, we would need to agree on
> the metadata description of a table.
> 
> > The conclusion is that the IVOA forum should aim at answering the
> > question "what is the MINIMUM set of agreed standards that we should
> > agree on" ? I think some of the US-VO resource data document is
> relevant
> > to this aim, and some goes beyond it. Likewise in AstroGrid we are
> > starting to make some specific technology choices that we should not
> > necessarily force on others.
> 
> What are these specific technology choices?
> 
> Roy
> 
> 
__
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