+Description of Core components for the Observation Data Model (ObsCore)
++News /draft /reports
We plan to deliver updates every Monday during the working group discussion period , from 01 March to 02 April 2011.
On the
ObsTAPdraftDiscussion page you will find the new releases of the ObsTAP draft and a place for discussing all contentious topics to be discussed.
Thanks for contributing to this discussion.
++Previous drafts
First official draft version was
WD-ObsCore-v1.0-20101207.pdf and can be found
here.
The corresponding original Tex file is attached below and currently updated following inputs during the Nara meeting.
++Goal
This model is meant to gather all queriable metadata that play a role in the discovery of observation data.
It is meant to be implemented using the Utypes derived from this model in a TAP/Schema implementation at various archives sites.
This exercise focuses on the capability to serve 80% of the data , with reduced / reasonable implementation costs at the archive side.
++ Uses cases
A list of Use- cases for data queries on all possible data types has been collected by David Schade , CVO and collaborators on behalf of the IVOA Uptake committee.
see the document
here.
++ UML Model
v0.1
This is the first version of the UML diagram describing the main components for this Observation DM.
The compressed archive file contains a bunch of webpages that describes the various packages and classes of the model.
see the archive compressed file in 7zip
here , in zip
there .
These are hyperlinked pages: to start with the top level , launch the index.html file and you will navigate in the various elements of the model.
ObsCoreDM v1.0 / March 2011 available
in zip
here .
++ UTypes
From the UML classes and attributes names, one can derive Utypes strings as described in the current
UTYPES draft (
Utypes WD).
Utypes are built up accordingly for ObsDMCoreComponents and can be used as unique labels for each piece of information represented in the the data model. These Utype strings can be used in the TAP implementation of the model.
For most of the query mentionned in the Use-Case document
here there is an item in the model covering the corresponding concept with a Utype string representing this data model element.
+ v0.11:
A set of Utypes has been identified by the Obs/TAP focus group as 'mandatory' for any service that supports an Obs/TAP discovery protocol. They are avaiblable in
Table 1.
Column-names will be mapped to these Utypes and used in
ADQL queries.
Other Utypes supported in the model and useful to identify the piece of metadata in the response of an Obs/Tap service have been listed in
Table 2.
+ v0.2:
Just one list of elements for the data model with corrected Utypes, mandatory fields are shown in green.
see the full table
here
+ v1.0 /Feb 2011:
Utype defined for the ObsCoreDM are listed in the TAP_SCHEMA.columns description in Appendix C of the
ObsTap WD . See last version at
http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/ObsTAPdraftDiscussion
++ Registering ObsTAP services
Since ObsCore is just another table in an otherwise normal TAP service, the current notion is that support for ObsCore will be advertised via a flag in the TAP Capability extension. This is being discussed at
TAPRegExt.
++ XML serialisation see the
XMLObsCore page
++ Previous
ObsTap Discussion ( 2009-2010)
Details on the model and its implementtaion have been discussed in various meetings and summarised in the notes attached below.
Summary in the
ObsTap page.