IVOA Executive Committee Meeting (FM28)

Sunday May 18 2008 @ 16.00-18.00 GMT (18.00-20.00 European Summer Time)

Logistics

At Trieste interop - see InterOpMay2008 - Vulcania 2.

Agenda: DRAFT 20080512

1. Roll Call and Agenda
2. Minutes of TM27
3. Project Reports - Significant events only
4. Review of Actions
5. Approval of new IVOA Recommendation(s) [Standing Item]
6. Reports from WG and IG Chairs
7. Background Re: New WG and IG Chairs and Vice Chairs
8. Final Report of Assessment Committee - DD
9. Review of 2008 Roadmap - RW
10. (The following items to be included as time permits)
11. TCG Charter Status - RW,CA
12. Revised Policy on Inactive Members - DD
13. Introduction Package for New WG/IG Chairs - RW,DD
14. Prospective New Members - Update/Status - DD
15. Start Date for Next IVOA Chair - BH
16. CODATA Announcement - DD
17. Fall Interop Status - BH
18. Next Exec Meeting
19. AOB
20. Review of New Action Items

Reports from the Projects

ArVO

AstroGrid

Australia-VO

China-VO

CVO

Euro-VO

France VO

GAVO

HVO

Japan-VO

Korean VO

NVO

The NVO Book—“The National Virtual Observatory: Tools and Techniques for Astro-nomical Research”—was published as Volume 382 in the Astronomical Society of the Pacific Conference Series. The book is based on the materials developed for the three NVO Summer Schools. M. Graham (Caltech), M. Fitzpatrick (NOAO), and T. McGlynn (NASA GSFC/HEASARC) edited the book.

The NVO project had an exhibit at the January AAS Meeting in Austin, Texas. Pre-release components of the data discovery portal were demonstrated, and the theme “NVO Inside” was used to highlight how many organizations are making data and services available through VO protocols. The first edition of the NVO Newsletter was distributed in March to a mailing list of nearly 400 people who have expressed interest in the VO. The Newsletter is also available on the NVO web site.

We are now accepting applications for the fourth NVO Summer School, which will be held in Santa Fe, New Mexico in early September. The Summer School faculty has been planning the program and assessing the need for new or updated software and tutorials.

Much progress was made on the deployment of the new registry schema. All IVOA registries worldwide were scheduled to be updated in late April. Also, initial implementations of VOSpace were under development, and interoperability testing between VOSpaces at Caltech, JHU, and in AstroGrid are planned for the coming quarter.

As the NVO development project comes to a close, we are undertaking a comprehensive review and assessment of all software (applications, tools, libraries) that have been developed in the past 6½ years. The goal is to understand the level of completeness and the long-term value so that we can identify those components that are most essential to support in the future.

RVO

SVO

VObs.it

VO-India

Reports from WGs & IGs(follows order as at http://www.ivoa.net/forum/)

Applications WG

Activities in the Apps WG have been focused mainly on SAMP, and recently a small group has explored the idea of a VO Applications newsletter.

• SAMP

Significant progress has been made over the past few months. The 3 lead authors drafted a document to describe SAMP. While full agreement between the authors was not obtained a coherent draft was posted to the apps-samp mailing list for public debate in the lead up to the Trieste meeting. The Trieste SAMP sessions are structured around discussing the undecided points, with the plan to publish a well developed Working Draft shortly after the interop meeting.

At present the draft is within the working group and undergoing rapid changes. The plan for the progress of SAMP will be revised in Trieste but is roughly mapped out as follows:

1. Discussions at Trieste
2. Further editorial work until we have something which we do not plan to make further immediate changes to
3. Publish WD in June 2008
4. Hub and client implementations based on published WD
5. Make revisions to document as required
6. Publish PR

We hope to maintain the current momentum to carry out this plan, and we have also obtained commitments from a group of likely implementors to review the WD.

• VO Applications Newsletter

A few of the astronomers associated with the Apps WG have been discussing the possibility of a newsletter about VO Applications that would communicate short news items about advances in VO tools to astronomers. An 'experimental draft' has been written, and posted to the apps mailing list in order to explore the ideas of what sort of content or format such a newsletter might involve. Development of this idea will depend on discussion in Trieste, and reaction from the exec.

Data Access Layer WG

The DAL WG is actively involved the following areas:

• TAP: In an effort to break the log jam of requirements on the Table Access Protocol, the standards definition work has been divided into two separate but bound efforts, one to address Parametrised querying (TAP/Param) and the second to address ADQL querying (TAP/QL). The TAP Wiki page here explains the rational, the process being followed and the experts active in each effort. Initial drafts for TAP/Param and TAP/QL have been published in advance of the Trieste Interop. These will be (vigorously!) discussed to check fitness for purpose and to identify common requirements enabling us to start to draw together the two TAP halves. This latter may proceed quickly or slowly; that has yet to be discovered, but the process requires their eventual merging.

• SIAP v2: Work on the scope, concept and interface has been undertaken and prototyping efforts from NVO and EuroVO are expected to be shown and discussed in Trieste.

• SSAP V1.04: This document was made an IVOA Recommendation in February 2008. It represents the first of the DAL v2 standards and is considerably more comprehensive than the V1 standards. It is important we get this right and detailed review is essential. Effort will be made to put SIA2 at the level of SSA 1.04. N-D datasets will be considered as long as they have a spatial signature and WCS. Region search and WCS support will be enhanced. Relationships with Other DAL efforts and GWS will be clarified.

• Footprint services: Much work has been undertaken defining Footprint services by both NVO and EuroVO, with prototype services available from a number of sources. Definition of the specification for a DAL Footprint Service Protocol has begun.

Interaction with Registry Working Group

We are especially interested in the Registry WG schema for Service Registration and the various Resource schemata as they present opportunities for DAL services to exploit.

Interaction with Grid and Web Services Working Group

VOSI is of particular importance to DAL services, especially Capabilities and Availability. By their nature, DAL services typically need monitoring by systems administrators, so the work on Availability is particularly relevant.

Data Models WG (MireilleLouys)

• Spectral Line Model: identification of two levels of use-cases and definition of two packages with two levels of complexity and goals:
  1. Simple Spectral Line Data Model, focused on spectral lines recognition in observed spectra, and matching the requirements for tools like VOSpec and the SLAP protocol.
  2. Atomic and Molecular Line Data Model, (for observations and simulations), encompassing more general uses-cases for physics (fine descriptions of molecular physics, atmosphere, etc.). Both packages currently finalised, with description of the existing implementations.
• Provenance DM and relationship with advanced levels of Characterization DM .
  We had a telecon (April, 23) where we discussed use-cases definitions, visibility and polarized data as well as the design strategy for complex data and complementary science data ( response , variability functions, etc.). The classes design is not yet fixed but we would like to be consistent with existing models : Characterisation, Spectrum and STC.
  We also discussed how to disseminate our effort and help users to take up the models serialisation.
• Syntax definition of UTypes : on going

Interaction with the Theory IG :

• Data Models for Simulations ( numerical simulations)

Models in action : new developments

• CAMEA : a user-friendly tool to help to publish observation datasets via their XML Characterisation metadata has been updated and is now available via SAMP (Plastic). It supports the last version of the Utypes list of CharacterisationDM and the STC leafs elements, via a java library.
• An interactive mapper from data base columns to Characterisation Utypes was built up in the case of ad hoc heterogeneous data sets in the SAADA environment.
• The STC DM was implemented in the NVO FootPrint service via its XML serialisation STC-X. Utypes for STC are still an issue as it would help to reuse coordinates definition when the data management requires tabular structures.

Grid and Web Services Working Group

The main activity for the GWS working group over the past few months has been VOSpace 1.1. A working draft of the specification, WSDL and schema was released on 16 January 2008. Reference implementations have been/are under development at Caltech, UCSD, JHU, Astrogrid and CDS. At least one of these (UCSD) also interfaces with the iRODS software from SDSC. There has also been work on the VOSpace usage document (Harrison, Morris) which describes the core metadata terms that we will be registering.

Members of the WG have been looking at security issues, including delegation (Rixon, Graham), particularly with a view to a more RESTful approach; and authorisation (Graham).

There has also been work on VOSI (Rixon) and CEA/UWS (Harrison).

Registry WG

In April, we passed a long awaited milestone when we officially began harvesting v1.0 standard records across the IVOA. A list of the 13 currently compliant registries can be viewed at http://rofr.ivoa.net/. With several weeks now of operation, we will discuss any remaining interoperability questions during the Trieste meeting. We will also hear about the various products and services that are now coming out that use the updated registry interfaces.

Our attention can now be turned to moving our working draft documents through the standardization process. Most pressing are 2 VOResource schema extensions, VODataService and VOStandard, which are to be referenced explicitly in other maturing specs. Two particularly important drivers are TAP and VOSI. VODataService includes metadata for describing tables, and TAP is driving a number of changes pending in how this is done. VOSI provides a way to get the table metadata directly from the service in a uniform way. We note that the pending changes will require an uprev in the schema; thus, one new phenomenon we will have to deal with is supporting v1.1 and v1.0 records simultaneously within the registry framework (as not all registries will upgrade all their records at once). The registry framework allows for this, and so there should not be a problem with this; however, we will see if any issues arise in practice. This phenomenon will become more common as we across the IVOA working groups evolve our standards.

Much like what is happening with STC, we still hear complaints that VOResource is too complicated, despite its apparent successful use in various apps in the IVOA. This is also despite design choices specifically meant to allow applications to only support the metadata they are interested in. I note that certain XML technologies--namely, XML binding tools that generate code automatically--work against our goals of enabling flexibilty and evolution, and their use should be discouraged in favor of other standard technologies. The demand for VOResource extensions remain strong. Nevertheless, discussion continues about how to ensure that simple registry use cases are implemented simply.

The authors of the Outreach Metadata proposal, previously issued as an IVOA Note (http://www.ivoa.net/Documents/latest/AOIMetadata.html), have developed a revised version and have been actively engaging the outreach community for comments. This new version is currently be reformatted into a Working Draft. Once submitted to me, I will release it to the document repository, and develop a twiki discussion page. Their efforts have not gone unnoticed among alert IVOA people, and there is growing interest in this document (from Semantics and DM). The authors would like to encourage the development of prototypes and path-finder applications using this document. After a 6-month development period along with general discussion, we expect to hold a Registry WG session at the Baltimore IVOA meeting to discuss in detail the future of this document in the IVOA. I'll note that the authors have expressed some trepidation about a review by largely technically-minded IVOA insiders of a standard with focused, practical purpose for implementation by less-technically oriented outreach practitioners.

-- RayPlante - 18 May 2008

Semantics/UCD WG

The WG chair (APM) and vice-chair (SD) will not be present at the EXEC as they already had flights booked before the formal invitation was sent.

What we hope to accomplish at this InterOp:

The major subject of discussion will be "Vocabularies in the VO". The WD has been discussed at length, but there are still few open issues to settle down. The most important are

• cross-matching of different vocabularies
• use cases (VOEvent, Registry, ...)
• if and how to go for an IVOA vocabulary

During the InterOp we hope to clarify these (and other) points, and then promote the document to the PR stage.

But here there is a "procedural" problem: the adopted format for the IVOA vocabularies is SKOS, now at the stage of W3C Working Draft. SKOS will not become a W3C REC until (hopefully) the end of this year. The question then is: can the IVOA (through its Semantics WG) have documents based on this W3C format that are in a higher stage than the W3C document describing the format?

We ask the advise of the EXEC on this point.

VOEvent

Major prototyping work now is bringing in new event providers to the IVOA standard, and building scientifically useful tools, in order to show proper directions for future standards. Work in Trieste will involve digital signatures for VOEvents, registration of event streams and event stream repositories, standard vocabularies, extension schemas, and forming the VOEvent 2.0 standard.

VOQL WG

VOTable WG

• FrancoisOchsenbein will not be able to attend the meeting
• No VOTable-specific meeting at this Interop, just a common meeting about utypes/units shared with DM.
• The finalisation of the preparation of VOTable1.2 requires an IVOA note about referencing STC in VOTables, as an (important) example of referencing data models in VOTable. The final redaction of this note was delayed essentially due to diverging points of views of the persons involved. Recently the situation improved, and this note should finally be ready within days, followed by the draft version of VOTable1.2
• After this final step, I imagine the VOTable WG could change its status into some maintenance group ?

Astro-RG IG

• A draft new charter has been prepared (shown at the AstroRG wiki page), and it is needed to be approved at the Trieste meeting.
• At the Trieste interop meeting we will have one session jointly with the GWS Working Group, focusing workflow systems and Grid experiences. The former topics would be a good occasion toward the OGF23 AstroRG session, which is described below.
• The Astro-RG session in OGF will be held during the OGF23 meeting in Barcelona, Spain, together with the Workflow Management RG. Its schedule will be announced soon by the OGF program committee - see http://www.ogf.org.

Data Curation and Preservation IG

Theory IG

This report deals mainly with SimDB as that is where most progress has been made. The progress of this effort in terms of data models, XML schemas etc etc can be followed on the Volute, Google code SVN repository: http://volute.googlecode.com/svn/trunk/projects/theory/snap/. A Note is being written, which can be found under http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/doc/note/SimDB-note.html.

1. SimDB is a specification for a Simulation (meta-)Database (could be called Simulation Registry, -Portal)
2. SimDB is an online service offering query capabilities to a database containing meta data describing results of simulations and their post-processing as well as about the codes used in these algorithms. Currently the simulations are still supposed to be those that produce a representation of 3+1D space, (possibly reduced spatial dimentsions through assumptions of symmetry). This is open for discussion.
3. A SimDB also contains information about web services giving access to the simulation results themselves. The more detailed specification of such services is the goal of the SimDAP-specification.
4. SimDB is based on a (logical) data model, fully specified in UML.
5. From the UML data model we derive physical models for use in their respective contexts:
   • The "public tables" of a relational data model, for implementing the database in a RDBM system so that SQL (c.q. ADQL) queries can be easily implemented.
   • XML schema, defining valid XML documents containing SimDB meta data descriptions
   • UTYPEs for the elements of the model.
6. We present XSLT scripts that derive these physical models directly from the UML model according to predefined mapping rules.
7. We also derive Java classes with JPA and JAXB annotations to make it easy to implement a SimDB from the specification.
8. We suggest an implementation path to transform an existing relational database to SimDB.

We think this effort is evolved far enought that it can be moved onto the recommendation track. There some issues have to be resolved that require input from a number of working groups, among which are:

• We need to confront scientists with our ideas and extract feedback. This includes defining use cases.
  => This is a task for the TIG
• We need to iron out the wrinkles from the data model and check its relevance.
  => We need input from domain experts (i.e. theorists) to see whether their results fit in the model.
  => We need input from the DM WG (i.e. people with data modelling experience) on various aspects of the data model.
• Should a SimDB be stand alone, or should it be possible to have relations between SimDB/Resource-s in different SimDB-s? The answer to this has repercussions for the XML and RDB representations. It may have repercussions for the functioning of a SimDB in case it is supposed to be stand alone (mirroring through harvesting of external resources may be required).
  => We would like to discuss these issues with the Registry WG who have experience with similar issues.
• Should a SimDB be read-only, i.e. represent the work of the groups publishing their own results? Or can external parties register their results in a nearby SimDB? I.e., is SimDB S*AP like, or Registry like (an extension registry?), or something in between?
  => We'd like to discuss this with Registry and DAL WGs.
• We need a common vocabulary for certain attributes in the model that refer to astrophysical concepts and are likely prime targets for queries. We want to use existing vacobularies where possible, but may need to define new ones.
  => We would like to discuss this with the Semantics WG.
• We need a way to express formally that SimDB services offer a particular ADQL query interface.
  => We think we need to discuss these issues with Registry and DAL(TAP) WGs.
• SimDB is a service that ADQL queries can be sent to and may(?) be thought of as a TAP service. However we'd rather not wait until TAPs specification is done before continuing.
  => We would like to discuss the issues arising from this within the context of TAP and ADQL, i.e. need discussions with DAL and VOQL.

We suggest forming a focus group to tackle these and other issues. This group should contain members from the mentioned WGs, together with the current developers of SimDB ("members" from the TIG).

It is unclear what the formal organisation should be, as there is not a single WG that could most obviously be given responsibility for the further development of this standard and the theory INTEREST group can not move a working draft through the recommendation track. Might it be possible for cross-WG focus groups like the one proposed here to get such responsibility? Or should intereste groups get this responsibility after all? Note that similar questions may come up based on the corss-WG focus group on UTYPE proposed by Mireille Louys.

SimDAP

http://volute.googlecode.com/svn/trunk/projects/theory/snap/.

Micro-physics and Semantics

Suggestions for DM meta-specifications (see Mireille's contribution)

• a UML profile defining a domain specific language for logical data models in the IVOA.
• mapping rules to transform these logical models to physical models.

-- NicholasWalton - 14 Jan 2008

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->