roadmap

Tue Mar 9 09:08:44 PST 2004

Tony and Markus

Perhaps we are trapped? If the registry schema is too complicated, then
publishing is too difficult and we can't get uptake by the community. If
it's too simple, then it won't stay the course when people want complex
queries. Urggh!!

But no we are not trapped. In fact we are still evolving. Suppose we don't
tell the broad community about the sophisticated VOResource schema, but
rather give simple recipes: "If you have a SIAP service to register, use
this form. To register your project, use this form." etc. To query the
registry, use this simple protocol.

We will get records that do not exploit the schema, maybe all they have is
"Title, Authors, Description". But so what? Let's get the people in and show
them *something* they can use.

Later, when they get savvy, when we have professional librarians, when we
really know the use cases, it will be time to say that we already have the
technology for complex space-time coverage regions and sophisticated
queries.

Roy

--------
Caltech Center for Advanced Computing Research
roy at cacr.caltech.edu
626 395 3670
----- Original Message ----- 
From: "Tony Linde" <ael at star.le.ac.uk>
To: "'Markus Dolensky'" <Markus.Dolensky at eso.org>; <registry at ivoa.net>
Sent: Tuesday, March 09, 2004 8:38 AM
Subject: RE: roadmap

> > maturity of the underlying Schema is secondary to content
>
> I'm not sure the underlying schema is secondary. I *wish* it was. It would
> be good to say, let's forget the schema - any registry builder can do what
> they want - all we specify is the interfaces that the registry has to
> support.
>
> But for the interfaces to work, information has to be exchanged between
> registries (harvesting), between registry and dataset (publishing) and
> between registry and application (query). And it is the format of that
> information that we have to specify.
>
> An application has to know what type of query it can make and what type of
> information it will get back. If the query is of the type 'which tools
can,
> from a photometric catalogue, find the redshift of each object by means of
a
> standard SED fitting procedure' or 'which data services contain provide
> catalogue data about white dwarfs in patch X of the sky' or ... then it
> entails that the registry supports metadata about resources of the type
> required. And that is why we need the schema to be sorted out in agonising
> detail - unfortunately.
>
> Let's face it, putting entries into a registry is pointless unless they
can
> be used. And if all we use the registry for is to list datasets and their
> web address then we might as well just list them all on a web page. The
> metadata associated with datasets, tools etc must be rich enough to allow
> *applications* to do real work with them. (And I'm not saying all the
> metadata has to be in the registry as AstroGrid is doing - the metadata
can
> be held at the resource - but it must be accessible from the registry so
> that registry queries can be *completed* in a single call.) Making the
> resource metadata too simple is worse than useless since it makes the
whole
> VObs effort look like nothing more than collating a list of datasets.
>
> Cheers,
> Tony.
>
> > -----Original Message-----
> > From: owner-registry at eso.org [mailto:owner-registry at eso.org]
> > On Behalf Of Markus Dolensky
> > Sent: 09 March 2004 13:27
> > To: registry at ivoa.net
> > Subject: Re: roadmap
> >
> > Hi Tony,
> >
> > Coming back to the proposed roadmap: Speaking from a content
> > provider point of view there is really only a single date
> > that matters. That is the day when there is a query adapter*
> > (detailed at EOF message) to a full registry. The state of
> > maturity of the underlying Schema is secondary to content
> > providers who want to publish their data.
> >
> > So, the question is:
> > Which bullets (1-12) in the roadmap need to be done to reach
> > this point?
> >
> > Again, this is not about harvesting between registries, but
> > utilizing registries by applications.
> >
> > Markus
> >
> >
> > BTW, thanks Ray et al. for your excellent summary on lessons
> > learned using Schemas.
> >
> > *)
> > The server side registry adapter is the piece of software
> > that enables an arbitrary archive browser (web form, servlet)
> > to talk to the registry through a standard interface. Similar
> > to a target resolver the idea is that a user will not query
> > the registry directly, but the archive browser will generate
> > queries to a full registry dynamically depending on the
> > context of a user session.
> >
> > Of course, the assumption is that at least one institution is
> > willing to implement the specifications for such a registry
> > and provide it as an operational service and not just as a
> > prototype for prove of concept.
> >
> >
> >
> >
> > Tony Linde wrote:
> > > We need to develop a roadmap of what we intend to do. I see the two
> > > key goals for us to achieve as being:
> > >
> > >  A. Create RM v1.1 (incorporating registry schema)
> > >
> > >  B. Create Registry Interface (RI) spec v1.0 (incorporating
> > harvesting
> > > and query interface)
> > >
> > > I tried a schedule which had these complete by 31-Mar-05
> > but working
> > > backwards from this date made the intervening activities too tight
> > > (especially considering how long it has taken us to get
> > where we are
> > > now and given that we should allow 4-6 months for testing
> > new versions
> > > of standards). So I then simply worked forward from now,
> > allowing us
> > > time for two more trial developments of the registry schema
> > and one of
> > > the combined RM v1.1 and RI v1.0. This pushed the delivery of the
> > > above out to end of 2005.
> > >
> > >
> > > I would therefore propose the following activities as our roadmap:
> > >
> > > 2004
> > > ====
> > >  1. Publish RM V1.0 to REC status
> > >      31-Mar-2004
> > >
> > >  2. Agree modified Resource Metadata Schema (RMS) draft v0.91
> > >      30-May-2004
> > >
> > >  3. Agree modified Registry Harvesting draft (RH) v0.2
> > >      30-May-2004
> > >
> > >  4. Demonstrate viability of RMS v0.91 and RH v0.2 between projects
> > >      1-Jun-2004 to 30-Sep-2004
> > >
> > >  5. Create draft Registry Interface spec (RI) v0.1 (incl
> > harvesting & query)
> > >      30-Nov-2004
> > >
> > >  6. Agree draft RMS v0.92
> > >      30-Nov-2004
> > >
> > > 2005
> > > ====
> > >  7. Demonstrate viability of RMS v0.92 and RI v0.1
> > >      1-Dec-2004 to 31-Mar-2005
> > >
> > >  8. Develop draft RM v1.1 (incorporating schema)
> > >      31-May-2005
> > >
> > >  9. Agree modified RI v0.2
> > >      31-May-2005
> > >
> > > 10. Demonstrate RM v1.1 and RI v0.2
> > >      1-Jun-2005 to 30-Sep-2005
> > >
> > > 11. Publish RM v1.1 to PR/REC
> > >      31-Dec-2005
> > >
> > > 12. Publish RI v1.0 to PR/REC
> > >      31-Dec-2005
> > >
> > > I know that this seems like a long time but the fact is
> > that standards
> > > which are widely agreed and which have been proved to work do take
> > > many years to develop.
> > >
> > > The key to keeping this effort moving forwards is that we
> > continue to
> > > develop working versions of the registry schema and the harvesting
> > > interface. This will allow us to prove that these standards
> > work and
> > > to find the problem areas.
> > >
> > > Feel free to publish an alternative timetable if you think we can
> > > deliver the standards in less time than I've indicated. And I look
> > > forward to other comments as well.
> > >
> > > Cheers,
> > > Tony.
> > >
> > > __
> > > Tony Linde
> > > Phone:  +44 (0)116 223 1292    Mobile: +44 (0)7753 603356
> > > Fax:    +44 (0)116 252 3311    Email:  ael at star.le.ac.uk
> > > Post:   Department of Physics & Astronomy,
> > >         University of Leicester
> > >         Leicester, UK   LE1 7RH
> > >
> > > Project Manager,            Director,
> > > AstroGrid                   Leicester e-Science Centre
> > > http://www.astrogrid.org    http://www.e-science.le.ac.uk/
> >
>