Alberto and Jonathan's notes for DM session 5 (Friday Morning) Roadmap: ======================================== Spectrum: WD1.0 by July 2006 PR1.0 by Miscow Interop CHAR: WD1.0 before Moscow, PR1.0 complete by end 2006 -FrancoiseG: ASAP please!! Revised to PR1.0 by Moscow. STC: Begin PR by July2006, Approved by Aug 2006. ATOMIC Line: WD 1.0 by Aug06, PR at Moscow? 2007 Road Map: SED and Spectral Data Associations: PR1.0 by May 2007 Source Catalog: beginning 2007 WD, PR at May Interop (Osuna) AtomicQuantity and Accuracy: PR1.0 by end 2006? Catalog Container: PR1.0 by early 2007 Dataset component metadata: PR1.0 by May 2007. Provenance: Dec 2007? not clear 2008 Road Map Begin v1.1 versions Dataset observation metadata model -FG: Characterisation - finish it now! -AM: VOTable UTYPES link, DAL Generic dataset dependency -JCM yes, need to do UTYPE document. Pedro: Source Catalogue Data Model -- Outline: Is it Source DM or Container DM? required use case/reference implementation. One document for the Container data, and one for Source specific data Is VOTable good enough to serialise the model? Comments: -IC,AM: requires proper integration with Characterisation DM. -AM: SIMBAD: they must have a well proven data model. Pedro was not convinced. - Pedro: This effort is community-driven, with inputs from vo- scientists, EURO-VO Science Advisory Committee, etc. Aurelien Stebe: ESAC DMMapper (BasicSkyNode with Source DM support) outline: Aurelien presented an interesting idea on implementing data models. DQL+SCDM => ADQL2SQL XSLTs (Mapping to SCDM, Table Joins) -> DB -> -> VOTable generation -> VOTABLE+SCDM returned. -BT: would you make the code available? To combine with the xquery development. Answer: we are open to collaboration, but requires agreement by Pedro and Christophe. -FO: We would need 10000 config files for Vizier. Answer: We could read from the database instead. -BT for Pedro: Source DM heavily overlaps with Semantics WG. Answer: we will have to discuss that, but SourceDM gives a fast track to solve the problem. JCM: Field names ought to be taken from the Semantics Vocubulary standard. JCM: The DM WG has been modelling Data Analysis up to now, the Source DM is a new kind of effort modelling astrophysics itself. Francois' Observation/dataset DM: Restart non-char discussion? -- Outline: History of Observation DM. Char, Provenance, Curation, Packaging, Others. Provenance: Observing and Software components: list them, describe how they affect the characterisation of the data. Data Access and Views: Driver: generic dataset discovery Provide UTYPEs and structure for Generic dataset discovery protocols Depicted a model for various transformations (cutout, reprojection, etc.) Comments: -DT on Provenance: Any operation on the pixels should be decribable by Provenance. Pointer to some existing material will be provided. -DT: Given that the Char will be already there, what are we adding by giving the bounds and locations at the Transform level? -BT: Looks like a work flow. A Full dataset might encompass many files, while the cutout is for a single file. Contact Mink. There are a number of realised work flows you might look at. - Alberto (sotto voce) Why do we need bounds and locations on the transformation? THat's just an instance of Characterization which we already have. Mireille's DM for Numerical Models, Frederic Boone, Dubernet, Moreau, Bonnarel, Louys. -- Outline: How to represent a numerical code. Context: Simulated and Observation comparison and interpretation. See DALIA Interface presentation by Moreau. Example: Code that simulates observations of galactic disk: takes parameters in input, produces data cube. Inputs: . astrophysical source . instrumental effects (psf, etc) -> requires new DM . algorithm used (number of particles, etc.) . knowledge in physics (frequencies, Halpha, CO, etc.) -> Atomic Line DM . Output dataset -> Characterisation, Spectrum DM. Parameter Model Requirements: . to structure the paramater set according to physical meaning . allow dynamical description (hierarchy, tables) . information on the numerical source code UML Schema shown Perspectives: . publish the model to the Registry . share instances of models - Share theoretical knowledge at the same level as the observations Comments: -IK: Can the code be distributed? Answer: yes. -BT: Should enable for grid technology. It is across disciplines, difficult to coordinate. JCM: Describing the interfaces for parameters is in scope for DM group. Answer: how you describe the tool, whether you want to run a pipeline is a different problem. - BT: Describing parameter interfaces already part of existing grid efforts. Mark: Astrogrid is developoing something similar. Communication is important.