roadmap
Tony Linde
ael at star.le.ac.uk
Wed Mar 10 01:22:46 PST 2004
> recipes: "If you have a SIAP service to register, use this
> form. To register your project, use this form." etc. To query
Yes.
> Let's get the people in and show them *something* they can use.
Agreed, but at the moment there isn't enough information in the schema for
anyone to use the registry except for browsing a list of resources. Or am I
wrong?
Has the NVO project (or anyone else) built or prototyped any way in which
users can submit a registry query (in whatever form) and have the resultant
services (even if only data services) automatically invoked? - including
AstroGrid data services, VizieR services etc? If so, can you point us to it
- would help to be able to see how this works.
Cheers,
Tony.
> -----Original Message-----
> From: Roy Williams [mailto:roy at cacr.caltech.edu]
> Sent: 09 March 2004 17:09
> To: Tony Linde; 'Markus Dolensky'; registry at ivoa.net
> Subject: Re: roadmap
>
> 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/
> > >
> >
>
More information about the registry
mailing list