comments on Simple Spectral Line data model

[Mireille Louys]

Hi all,

Here are my comments on the current WD on Simple Spectral Line data model.
The document is well organised with fine detailed descriptions of all
concepts.
I tried to review it extensively, including typos. Do not be afraid of
this long list.
cheers, Mireille.
-------------------

Comments on SSLDM WDraft

1)Structure of the document:
-There is no "Use-case" section clearly exposed in the document , and
therefore no possibility to judge wether
the model fulfills the requirements or not.
This simple model would get more support if the use-cases are identified
easily by implementers/developers.
I don't think people are supposed to read the SLAP document to
understand what the model is for.
- there should be an implementation section, describing 2 independant
implementations.
Here we could have a short presentation of VOspec and another for SLAP
accessing a use-case described in the use-case part.
- there should be a section describing the XML schema
( probably a cut and paste from the SLAP doc)

In the UML diagram:
it is important to give names at the  extremity of an association line
F.I: Line -----is produced by------- Process
The role of Process could be mentionned then as -process
Line--Environment is probably a simple reference ---> to Environment
Line ----Species should have 2 associations:

Line ------------finalElement--Species   0..1
Line ------------initialElement--Species 0..1 if there can be none, one
of each , or both.

The same applies for Level.

In these cases, there is no need to have the attributes listed into the
Line Class, which can become much simpler.

General containers:
Physical quantity and Units are simple containers that are used through
out the place and in other models.
they can be mapped as types in UML.
The proper way to it in UML is by a Template class
PhysicalQuantity<numericType> with numeric type in {integer, unsigned
char, float, double, complex, etc...} which allows to generate each
necessary class like PhysicalQuantity<double>
But this is not easily translated in XML schema, therefore the model
could have a bunch of PhysQty like :
PhysicalQuantityDouble{
	value:double;
	error:double;
	unit: Unitref
};  and so on, for each other type.
I think it is interesting to add a UCD tag to the PhysicalQuantity
concept, as tried in other efforts ( Units, f.i.)
Then the Number hierarchy is no longer useful.

Coordinates:
*Source* should use the STC ObsdataLocation as explained in section B.9
"Using a FITS File" in the STC standard document or CatalogEntryLocation
in B8.

Model: this class seems to encompass what can be described extensively
in future efforts and has a role of place holder here.
Model is a very general name : what about PhysicalModel,
ModelforPhysics, ModelforPhysicalEnvironment???

I suggest to have 2 references on Model:
Process 0..* ---> Model   0..1 one process points to one Model
One Model describes 0 or more processes.
Environment 0..* ------> Model  0..1 one environment points to one Model
or none.
an Environment class may be described by one ore more models or none
Does it sound correct ?

Notations/typos:
2.1.2.1 Unit.UnitString  could be replaced by Unit.expression as defined
in the Units DM.
	Unit.scaleq   ----------------------- Unit.scaleSI
	Unit.dimensionalEquation------------- Unit.dimEquation
just for homogeneity.

2.1.3
observables: should we clarify it here like "observables, e.g. measured
physical parameters" ?
2.1.3.13 they are normalized in any way: does it mean just " they may
have been normalized?", and then we know how they can be expressed...
??? not clear for me: source , and they are this different....

2.1.3.18  Line.Process should be completely removed  in compliance to
the UML changes suggested above.
If not then point to 2.1.8 as this a reference to


2.1.4.1 see Appendix A and not I
2.1.6.2   section 2.2.5 not found  point to Appendix C instead?
2.1.7.2 see Appendix *B* for a description
2.1.7.5  Appendix ??? for those quantum ...

2.1.8 General remark: there are several valid combinations in the
string-valued attributes that could be listed as valid examples, so that
an API interpreting these metadata can detect inadequate string
combinations :
We could have a simple table of the various possibilities:
process.type 			/ process.name
				Photoionization		Collisional Excitation
matter radiation interaction		yes		?
matter-matter interaction		yes		yes

4.1.2 UML instantiation diagram

The diagram is difficult to read. Some values are not provided because
of lisibility.
I think the simple (utype, value] list in 4.1.1 for all the quantities
described in the model is easier to understand.
an XML serialisasion or Json serialisation would show another 
representation and usage of this model.

References:
some incomplete references : 2, 3, 12
SSA could be referenced too.

___________________________________end of comments_________________
-- 
--------------------------------------------------------------

  Mireille LOUYS          mailto: Mireille.Louys at astro.u-strasbg.fr

L S I I T                       &     CDS,
Ecole Nationale Superieure            Observatoire de Strasbourg
de Physique de Strasbourg,            11, Rue de l'Universite
Boulevard Sébastien Brant, BP 10413   67000 STRASBOURG
67412 ILLKIRCH Cedex       	      Tel: +33 3 90 24 24 34
---------------------------------------------------------------