roadmap
Tony Linde
ael at star.le.ac.uk
Mon Apr 5 03:53:02 PDT 2004
Can I ask for comments from others re our roadmap - Peter is waiting for us
to publish one.
You have one proposal from me and a dissenting opinion from Bob (perhaps Bob
could post an alternative).
Please let us know what you think.
Thanks,
Tony.
> -----Original Message-----
> From: Robert Hanisch [mailto:rjhanisch at worldnet.att.net]
> Sent: 01 April 2004 04:59
> To: Tony Linde; registry at ivoa.net
> Subject: Re: roadmap
>
> Tony et al.,
>
> I start with this part of Tony's message:
>
> > > 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.
>
> Yes and no. In the astronomy community, FITS is the
> archetype of doing things slowly and deliberately. FITS is
> loved and hated equally (well, maybe not equally!); the
> slowness means that FITS is not technologically very
> state-of-the-art. But it works, and as a community we are
> extremely well-served by having it. On the other hand, it
> has taken us over 10 years to reach agreements on how to
> express coordinates. 10 years. And we are not finished yet!
>
> The VO is young and still volatile. This is a plus and a
> minus. The plus is we should be free to experiment, the
> minus is that we need to build Something, Now, so that the
> astronomy community knows what we are up to and buys into
> what we are doing.
>
> We need to reach agreements quickly, build to them, and
> iterate to improve them. We need to be willing to build and
> revise, or even in some cases throw away and start again. We
> have set up a standards process that recognizes change, and
> is intended to be responsive to change. I do not believe we
> can afford to set 2-3 year schedules for reaching consensus.
> If it takes this long, the community upon which we will
> utimately depend for support will see us as purveyors of
> snake-oil, and will blow us off.
>
> > > 2004
> > > ====
> > > 1. Publish RM V1.0 to REC status
> > > 31-Mar-2004
> > >
> > > 2. Agree modified Resource Metadata Schema (RMS) draft v0.91
> Whatever the number, this should be ready to promote to V1.0
> this summer.
> > > 30-May-2004
> > >
> > > 3. Agree modified Registry Harvesting draft (RH) v0.2
> > > 30-May-2004
> Ditto.
> > >
> > > 4. Demonstrate viability of RMS v0.91 and RH v0.2
> between projects
> > > 1-Jun-2004 to 30-Sep-2004
> ok. We validate RMS and RH over the summer, and bring them
> forward to RECs by 1 Sep 04 (bring forward by a month).
> > >
> > > 5. Create draft Registry Interface spec (RI) v0.1 (incl
> harvesting
> > > & query)
> > > 30-Nov-2004
> What is this? A query specification? We already have
> harvesting given above. And we need a query spec in parallel
> with the above if we are to make use of the registry,
> otherwise it is a blackhole that we pour info into and have
> no way of getting it out. Can't we make use of ADQL? Why is
> a registry so fundamentally different than another VO
> resource? A registry is all metadata, yes, but the
> mechanisms for querying it should not need to be any
> different, should they?
>
> So I am not sure what to say about the rest, except that the
> event horizon is way too far away. We need to push ourselves
> harder than this, accepting incompleteness and revisions, but
> developing and demonstrating registry capabilties --
> metadata, schema, harvesting, querying -- in ~6 months.
>
> We have some other very big challenges to deal with, not at
> all mentioned here. Curation, revision control,
> synchronization of distributed registries. We have an NVO
> registry with harvested information from a number of
> publishing registries, and it has 4000 or 5000 entries. Most
> entries are next to useless because the key metadata fields
> have either not been populated at all, or have been populated
> blindly with inappropriate information. In some ways even
> worse, well-intentioned content providers have assigned
> resource Titles and Shortnames and Descriptions that make no
> sense, that conflict with astronomy community understanding/
> expectation, and generally defeat the purpose of the
> registry. Our best-made plans for metadata elements (RM) and
> their encoding (RMS) are worthless if we have no way to
> review, endorse, validate, and update such information.
>
> Bob
>
> > > 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/
> > >
> >
> >
>
More information about the registry
mailing list