Data Model Work Group Sessions Oct 14-15, 2003 at InterOpOct2003


Attendees at Oct 14 DM WG session

DataModelParticipantsOct2003

1. Introduction: JonathanMcDowell (JM)

Aim for the creation of a White Paper describing the 'IVOA' Data Model

  • Data Model provides abstract description of data.
  • Provides basis for interoperable exchange of data and queries
  • Provides basis for DAL interface design and XML metadata choices
  • Process:
    • White paper
    • UML model
    • XML representation - reference implementation
  • DAL implements interface
  • Summary of convergence efforts for Observation in various data models, which come from different points of view e.g. archive vs analysis tools. A number of data models have been considered so far, and these show areas of similarities.
    • CfA data model from JonathanMcDowell
    • Starlink one from DavidGiaretta
    • one from readon of egso
    • one from CDS - MireilleLouys
    • others from Brian Thomas, Canadian VO, German VO
    • Common Areas identified: see CommonFeatures.ppt
      • Processing
      • Acquisition
      • Instrument
      • Coverage
      • Packaging
    • Issues: Scope and Level of detail and naming
      • Need to work on White Paper then iterate with UML diagram
      • People are encouraged to send links to DM mailing list, showing their own special data model, preferably as UML plus documentation, pointing out special features, and the mapping to common areas
        • Frank Valdes: Will send in the NOAO data model described in UML with supprting text description.
    • Common concepts:
Keywords Concept/ Description
Dataset
Observation
Result
Abstract top level container for astronomical data. Could be a values of these
Provenance
obtained with experiment
Abstract class describing how file was created
Observatory
Observing platform
"Mission"
Location where data was taken/first acquired
Coverage
Meta-coverage
Sample
Limits/boundaries on any parameters (possibly numeric with scientific units)
Data container
Quantity
NDArray
Holds information array having the same "type" - type = numeric/string/enumerated type, eventually classes - with units
Data acquisition  
Coordinate system
pixel mapping
Reference system
Mapping
WCS:Frame
Set of labels and parameters that uniquely define the context of some values
Mapping
WCS:Mapping
Defines transformation of values between coordinate systems
Frameset
Collection of standards
(Type coords)
Contains one or more coordinate systems and zero or more mappings between them
History The sequence/ensemble of "provenance" items
Accuracy
Errors
A precise numerical measurement of the fidelity of one or more values.
Example: systematic and/or statistical errors
Quality
Flagged accuracy
Feature
A classification of the reliability/fidelity of one or more values. The classification should contain two or more choices.

We are starting with highest level concepts; once they are agreed, we will define lower level concepts. The level of detail will be guided by the requirements for querying. The model must be extensible to allow lower level commonalities to be captured. In addition this should encourage sharing of concepts.

2. DM Use Cases: AlbertoMicol

Alberto's slides in .ppt format

There is a requirement for Science Cases to help in the scoping of the Data Models. Initially could look at the Science Cases from e.g. AstroGrid (AstroGrid top ten science cases) and NVO etc.

Issue of science use cases required for this.

NicholasWalton: Meeting needs to identify responsible person/people to lead the requirements capture and analysis process.

AGREED: Alberto Michol, Brian Thomas, David Giaretta, agreed to supervise this process of collation and first cut review of science requirements for Data Models. All are encouraged to send their science use cases for input into this activity.

Discussion points

Q. ??: Inclusion of plate data from smaller institutes A. JM: will be considered as a lower priority case.

Q. Javier Solano: scope to include say Planetary Data. A. JM: not first priority but will be included. Thus RA,Dec is not seen as the key identifier of objects as this isn't the case for say planetary data!

Q. Lyndsay Fletcher: assessment of quality A. Doug Tody: data characterisation is a key component of this activity, thus user assesment of 'quality' when assessing data for their use will be possible.

Reports on mini-models

Quantity - Pat D will post summary
  • there is an extensive discussion on the mailing list on how to model small amount of data - quantity

Transformations: (David Berry)

  • transforming values
  • transforming between coordinate systems

Language was proposed on mailing list involving abstract classes and subclasses, including compound mappings so that arbitrarily complex mappings. DT proposed that such transformations are the remit of analysis software; it was decided to let work be driven by requirements. Additional ideas can be found in Radio data - in AIPS++ MeasurementSet. - ALMA data format and associated model

3. Road Map

Requirements needed by the DAL group. Doug Tody noted upcoming input required from the data model needed by the DAL group in their v1.0 SSA and v1.1 SIA standards.


Short term goals: Priority:

  • Spectral Data Model for SSA
  • Observation data model
  • Incremental "deliveries" are needed in order to have useable pieces
  • Consider Packaging as a possible area of work
    • Mosaic images
      • There are several different ways of packaging these currently


Other issues:

  • Data Collections - e.g. from an IFU - maybe just
  • Updating of data infomation - maybe a registry problem (e.g. handle update of photmetric calibration data)

Brian Thomas: would like to see a more developed framework for the development of the Data Model

On the whiteboard:

  • slow> top level: obs, spectra etc
  • intermediate> mid level: components
  • fast> low level: qualntities, units

(There was disagreement on which activities were slow and which were fast)

Move with idea of local namespaces.

JonathanMcDowell: Names against Milestone Tasks

  • White Paper at Observation and Component Level - end Dec 2003
    • Take a Use Case to implement and pass to the DAL group for consideration

  • UML Level Feb 2003.

Francois Bonnarel - common rules - ensure compatability with DAL.


-- NicholasWalton & DavidGiaretta - 16 Oct 2003


Topic attachments
I Attachment History Action Size Date Who Comment
PowerPointppt CommonFeatures.ppt r1 manage 263.0 K 2003-10-17 - 09:14 DavidGiaretta Common features in several data models
Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2005-05-20 - MarcoLeoni
 
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