Please find attached to this page a draft of the document "The IVOA in 2006: Assessment and Future Plans".

After detailed feedback during the Victoria meeting, the Technical Coordination Committee expects to finalize this document.

Comments (please include your name) ......


Roy, Of course I don't entirely accept your description of DM...

I think that with our experience developing the spectrum DM and the SSA DAL, we now have software implementations and we have what Doug calls 'component data models' that are small bits which can be reused in different contexts. The Curation, DataID, and soon Characterization/Coverage models are pieces that are relatively simple and can be reused elsewhere.

The Spectral Line model, which is rapidly heading to 1.0, is a nice example of a DM which is relatively simple and on which we have achieved convergence quickly. So I think we have learned how to do it.

- Jonathan


From your description of the GWS work-packages:

VOStore should be carefully defined so that data store can be indirect, not controlled by VOStore, yet the metadata still well synchronoized with the data store.

If we replace "VOStore" with "VOSpace" (since VOStore being dropped), then I agree with you in general. I think that where we have two interfaces to a data-store, e.g. VOSpace and SkyNode talking to the same RDBMS, then the ensemble is responsible for keeping coherence, and we should write that into the spec. If you had some other requirement or use case in mind then maybe you could explain in more detail; perhaps a note to the Friday GWS session?

-- GuyRixon


Hi Roy, a few comments on the IVOA in 2006 doc.

  • I think the document should have the word 'Technical' in the title - thus, 'Technical Assessment'
  • In terms of layout - it would be good to number the sections/ subsections.
  • Is it possible to give an indication of what WG areas impact on which others?
  • I think we need to be clear as to the role of the IVOA Exec: I think that under your general recommendations section - the Tech Coord Committee should come to agreement on these issues - as they have the technical know-how. The Exec then just needs to endorse - but not decide.
  • stds and docs group - i think that this should be re-instigated - as you note it oversees the process. (if it isn't re-instigated - you'll need to remove reference to it in the doc).
  • As to maintaining support for older versions of standards - this isn't tenable longer term - c.f. how long did MS keep support for windows 95 going? Thus we need to be clear that support of older versions of the stds will cease at some point (or just bite the bullet and expect support only for the newer (=better) versions).

Under specific working groups - there is also the 'Astro-RG IG' of which I am chair.

Text for this would be:

'The Astro-RG IG' is a forum to provide formal cross representation between standard development in the wider 'Grid' computing world and the IVOA community. This occurs through cross membership of this group with that of the Astronomy Applications Research Group of the Global Grid Forum (GGF) (see http://forge.gridforum.org/projects/astro-rg/)

It provides a forum to discuss relevance of grid and web service standards for the IVOA, and conversely provides a conduit to feedback example usage experience of standards to the GGF. A recent workshop at GGF17 was held - see http://www.ivoa.net/twiki/bin/view/IVOA/GgfIvoaMay06WorkShop - which addressed a number of common standard areas.'

Table 1 - add entry for astro-rg IG:

WG/IG Chair Current Priorities
Astro-RG IG IG IVOA.Nicholas Walton Authorisation, Storage

Yours, NicholasWalton


Concerning the use-cases for VOSpace, yes, let us have a document presenting them. However, should this not be written (or at least co-written) by the original proponents of VOSpace? It doesn't seem like something for the exec to set in isolation.

We should note that VOSpace is a standard for interfaces to existing storage system. The assumption is that many existing systems provide the facilities for one use case but none of them provide for all use cases, even the ones already known. Therefore, by adding a common facade to existing systems we get to use them without too much custom client-code and we get to combine them.

-- GuyRixon



Topic attachments
I Attachment History Action Size Date WhoSorted ascending Comment
PDFpdf IVOARoadMap-20060510.pdf r1 manage 160.7 K 2006-05-11 - 15:24 RoyWilliams The IVOA in 2006: Draft 20060510
Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r6 - 2006-05-14 - NicholasWalton
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback