Norman Gray's notes on DM1 Topic - DM meeting 1, Tuesday 25 May - Working groups - Active work packages: [group 1] Quantity, Observation, Transforms, Spectra, Catalogues - [group 2] Time-obs, resolution, limit-flux, interferometry, simulations - Feel free to create new areas on the wiki page. - The plan: support the definitions of schemas and serialisations for metadata and data transport. Our efforts are only useful if other working groups adopt them. But this will only happen if we create and issue a standard soon. - Near term goals - support DAL group in deployment of SSAP. Intended to be simple, and to take ideas from Observation and Quantity, but to support the January demos, and to show the community that DMs can be useful. - Move Observation and Quantity models forward. Possible approach is to issue the current Quantity document as an IVOA note. - Generate explicity summaries of the DMs implicit in the Registry, VOQL and VOTable, to expose heterogeneities in their approaches. Define DM link to VOTable and utypes - Catalogues: begin work on `derived data' and `source catalogs' (same thing? -- disagreement on names, possibly trivial). Can it be subsumed in the Observation work by simply adding a few extra features to that? Some inconclusive discussion about what a source/object catalog really is. - General conclusion: officially, provide class diagrams, but groups should be free to define interfaces or serialisations as they feel most appropriate. - Will implement the abstract definition in two ways - 1. Serialisation for interchange: how do we structure the files? How does a data provider describe what they have to the VO? - 2. Implementation as software classes. There may be a popular library, but it wouldn't be mandated. What is the common language of concepts? - Plus: The other thing people will want to do with this model is to implement databases (Peter). Link to SQL/VOQL: want to be able to give out a SQL statement that would let others query your database. Thus need commonality of concepts. - List protocol - In email discussions, request to focus on how we can get agreement rather than how to iterate. - At certain points, go offline. Jonathan points out that this did actually happen, and what appeared on the list was the overspill! - Brian's talk: Introducing the Quantity - What a quantity is, use and content of the Quantity DM, where we are now, and where we are going - What is a quantity? - A container which pairs semantic meaning with a `value' - Ie, a generic container for semantic data. Must have regular structure, adequate to make it searchable and manipulable. - Working at the lowest level of numbers. - Use cases - Decription of a scaler (eg, `3'), vectors of numbers or imaginary numbers, matrices, strings. - Description means being able to exchange, combine, enable search/exploration/discovery of Qs. Should be agnostic between theoretical and observational data. Contain explicit or mapped values (`mapped' meaning Mapping, the idea being that you don't have to care whether the Q is holding the numbers or the algorithm. - The DM described - DM is the realisation of this. Includes a set of abstract interfaces (UML), plus a set of schema for serialising this (XML). - Both of these detail the types of quantities and their components. - Different packages/components in different namespaces, such as units, coordiatesystem and accuracy. - Quantity interfaces - Frame: a quantity with no value. Eg, `RA in ICRS, in units of degrees' - BasicQuantity: a quantity with one value -- mostly for convenience - CoreQuantity: a quantity with a set of values -- scalars or vectors - StandardQuantity: a Q with a set of values that may be described by an n-dimensional coordinate system. May have axes that may be CoreQuantities. - Alternatively Atomic/List/MatrixQuantity instead. - Usage: designed to be used by higher-level data models. - Only interfaces -- not specifying a class hierarchy in order to avoid arguments - Present status - Identified a number of initial use-cases and requirements for the Quantity. - Have an initial determination of what is part of teh Q (components) - We have an initial draft IVOA spec, which includes XML schema and abstract interfaces. - Agreement on the Q components, and what are the sensible defaults (almost there) - Need to clean up and submit the IVOA spec. - Want expansion and development of components: accuracy, Mapping and Packaging are likely near-term components. - Reference implementation in Java - Jonathan: Issues - Is Q useful at all? - Should we use it directly or subclass it? - How should we represent coordinate axes? - How do we represent RA-Dec pairs? - What should the accuracy model be? Left rather undefined in the document at present; what are the short- and long-term goals for this? - How do we represent data quality? - Should we allow composite quantities (eg, arrays with component type Quantity)? Nifty, but makes things complicated and confusing, so possibly defer this until some later version. - Discussions - Francois Bonnarel: will produce detailed comments - Ray Plante: XPath as a pointer into the data model - Norman Gray: Mappings can do a lot of this work - Dick Shaw: Is accuracy necessary? - What should the default be for accuracy? - Options: (0) Accuracy optional but with a default, so there will be an accuracy returned whether or not you state it; (1) no default, must be explicitly set; (2) Quantity model will not include Accuracy, and it will be postponed for another day. Vote: 0=10, 1=3, 2=0. - So what should the default be? Should the default error be (0) special, distinct, undefined value; (1) zero -- number presumed exact; (2) context based? [Gerard] It depends on context -- if it's a count of detectors, then it's obviously exact; if it's the length of a detector, then the error is obviously missing. [Dick Shaw] The application should be left to choose what no-value means. [Ray] a subclass might specify a default. [Pedro] Everyone can always override the schema anyway (thought that this might be returning to (1) above. Vote: 0=15, 1=1, 2=1. - Units - Should they be exactly analogous to what we've decided for Accuracy? More options. - Options: (0.1) Require unit with default unitless/dimensionless; (0.2) ...with default undefined; (0.3) ...with default context-dependent or overridable; (0.4) ...with default of `undefined/unitless' for strings but unit (including special `unitless' value) required for numbers; (1) Must always specify (including `unitless' as an option); (2) No units in Quantity. Vote: 0.1=5, 0.2=3, 0.3=1, 0.4=6, 1=3, 2=1. - Packaging: how does one do the serialisation (in XML?).