Characterisation Data Model RFC

This document will act as RFC centre for the Characterisation Data Model 1.11 Proposed Recommendation.

Review period: 01 Jun 2007 to 4 Jul 2007

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the data model mailing list, dm@ivoa.net.

Comments

---

• Sample comment (by BrunoRino): ...
  • Response (by authorname): ...

---

• CharacterisationAxis class (by FabienChereau):

Hello, instead of having many collections of Properties for each instance of Characterisation (like Resolution, SamplingPrecision etc..) one for each axis as shown in Figure 4, why don't you have only one collection of a CharacterisationAxis class which itself would contains the properties for this axis? I think it would make the design clearer. It is also convenient because to each CharacterisationAxis instance can be associated a single coordinate frame which also apply to each property.

---

• Response (by MireilleLouys):

The XML representation of the model has this feature , that is each CharacterisationAxis is a node underwhich we have the properties: coverage, resolution, Sampling for this axis. For the model we want to keep the symetry , the matrix-like design that is shown in the different examples. One could search / group the metadata in a Property first order and have , for example Resolution , for all axes, then Coverage, for all axes, etc... When the axes are not independant, that is Space depends on time, for instance, Resolution may be represented by a multi-variable function of all axes, and will be hooked in the Resolution Class.

---

• FrancoisOchsenbein (30-Jul-2007)

Several documents related to Characterisation are named by a URL to alinda.u-strasbg.fr, but the link does not work. I was especially interested by the VOTable serialisations given as http://alinda.u-strasbg.fr/Model/Characterisation/examples/MPFSVOt-v1.1.xml

I really like the document: well structured, easy to read, with well explained concepts and clear examples.

---

• Response (by FrancoisBonnarel):

Actually this link is available the machine was simply dowwn when you tried. IT is planned to have all these examples on the IVOA site anyway.

---

Comments from the Working Group Chairs and Interest Group Chairs

Chairs should add their comments under their name.

Mark Allen (Applications WG)

Christophe Arviset (TCG vice Chair)

Matthew Graham (Grid & Web Services WG)

Bob Hanisch (Data Curation & Preservation IG)

Gerard Lemson (Theory IG)

Mireille Louys (Data Models WG)

Keith Noddle (Data Access Layer WG)

Francois Ochsenbein (VOTable WG)

Pedro Osuna (VOQL WG)

The concepts in the document apply very well to the description (Characterisation) of, for instance, an observation. There is a clever separation into axes with different properties, which makes the complete characterisation possible with few parameters. For instance, the table in page 9 is very useful to identify correctly the concepts for a proper description of a "data set". The figure 2 on the different levels of description is also very enlightening.

There are some points however that,not being showstoppers for the Recommendation process, should be considered for improvement, whether in this version or subsequent ones. Other issues are probably more editing than any other thing.

- in pg.3 reference is done to the Observation DM. However, it looks like not much work has been going on on the Observation DM. Is the Observation DM going to go ahead, or is it going to be "superseded" by the Characterisation DM globally?. In the former case (Obs DM disappearing), the Char DM should contain all the info that is currently on the Obs DM. In the latter, the difference (or complementarities) between the two should be briefly mentioned.

- in pg. 10 (point 3.4.1) mention is done to a combination of UCD and units to "ensure uniqueness and recognition by standard software". This issue has been treated many times, and at the last Beijing meeting it was finally recognised that a set of "BIYECTIVE UTYPES" should be defined for Data Models to be understood. This biyective-utypes were given the name "UFIs" by Jonathan. Despite the fact that they are undefined yet, they resemble very closely the Object Oriented technology attribute naming, i.e., names constructed by dots in between class names. The issue of how to mention actions in the UFIs is also an important issue and a small team has been created to deal with these things (although admittedly, not started to work on it yet). Therefore, this paragraph should either contain a reference to that, or remove the first paragraph.

- the whole list of attributes in the Data Model should be clearly made explicit in the document. They should normally correspond to what has been called UTypes during all this time, and they should be inside the document, and not in a separate one. In particular, the UTypes should clearly reflect the UML structure of the DM. The UML is missing a "top level" diagram, where inheritances and associations are clearly seen. Also, the "Axis vs Properties" issue can be solved through proper UML modeling of the DM, and should be done so, in my opinion. Leaving the possibility to traverse the tree upside down (Axis to Properties) or the other way around might make the model unworkable for software handling. The UML and its attributes should be reviewed.

- mention is done in 4.4 of the Quantity DM. In my understanding, the Quantity DM effort has been discontinued by the DM group. If this is the case, the reference should be removed. Otherwise, a more detailed reference of how the Quantity DM is affecting this document should be made explicit.

- point 5.2 goes again to the UType creation. UTypes (or UFIs in our more "modern" view after Beijing) should not have repetitions in their names. Different model classes don't need to have the name of the parent in their name. In any case, the whole list of the UFIs (or UTypes) should be given in the document with a clear mapping 1 to 1 to the UML diagram that represents them. The Spectral DM could be a good example of how this can be done.

---

• Partial Response (by FrancoisBonnarel):

I am only answering About Observation Data model and let MireilleLouys adress the other points:

This datamodel effort has been frozen since we decided to focus on the characterization part,which became a model in itself. In the original view (see Note http://www.ivoa.net/Documents/latest/DMObs.html, 2004) Characterization was a class of the overall Observation data Model. Other classes were Data, Curation, Provenance, DataID, Target etc ... But I think it is now time to go back it. there is some demand for that.

Actually a complete Observation datamodel already exists, but specific for 1D spectra: its the spectrum datamodel and its relationship to Overall Characterization is rather clear I think: the Char class in Spectrum datamodel is a specific implementation of overall char.

For an overall Observation Data Model we will have to revisit the Data, Curation, DataID, Target as in spectrum and check if they are general enough. My personnal opinion is that Data is not and that Curation, DataID, Target probably are. (But do we really need a data class for Images, 3D data , etc ??? We have FITS which is working well for data in that case ...)

So we see that for an overall Observation datamodel we have to split the effort in two parts : - Data class on one side, (which may keep simple or ethen neglected ?). - Metadata classes on the other side.

For all the metadata classes the Spectrum model is a good starter except that Provenance is missing. There is a lot of demand in various communities for modelizing the instrumental and moreover softawre Provenance of the datasets. So I think the next step as we already stated during the first DM session in Beijing (see my talk there and Jonathan's conclusions) will be to focus on Provenance...

Now the last point you adress is a vocabulary one. Some people may want to call all metadata "Characterization" (actually some astronomers outside our IVOA community allready do when they specify their needs - see the discussions during spectroscopic workshop last March at your site) including Curation and Provenance ... It may be the final IVOA choice, but in that case we have to find a new class name for what is presently called Characterization which is this part of metadata dealing with the description of the dataset in the data parameter space.... My personal opinion is that I don't see any good reason to change:

so the future ObservationDM Map could be:

____________ObservationDM

_______Data_______________Metadata

___________________ObsId, curation, Char, Provenance , etc ...

Ray Plante (Resource Registry WG)

This is well-written, well-organized, and easily digested--nice work.

A few small comments:

• If the schema discussed in section 5 is intended to be used as an interoperable exchange format, then the schema should be located at www.ivoa.net and should have namespace URI rooted at www.ivoa.net. (I recommend http://www.ivoa.net/Characterisation/v1.1.)
• I wonder if the contents of App. D should be made part of the main document since it gives specific requirements for judging compliance.

Andrea Preite-Martinez (Semantics WG)

Roy Williams (VOEvent WG)