roadmap

[Tony Linde]

> 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/
>