Coords/Measurement model RFC comment response

[Laurent MICHEL]

Hi Markus,

It is obvious that STC could never provides classes for any existing 
measurement. Thus it needs generic measurements that can be used in 
various context.
We have to keep in mind that STC (CMT in fact) provides model components 
for upper level models.

The real question is to know how a client can get the physical meaning 
of a specif model instance.

This can be done with three different ways:

1- BY CLASS NAME: If the measurement is modeled by a specific class, 
knowing that class (e.g. vodml type) is enough to resolve the physical 
axis the instance refer to. The fact that the class name does not give 
the role (e.g. main corrd or not) of a given quantity limits the 
interest of the approach

2- BY ATTRIBUTE NAME: If the host model (e.g. cube TS...) has a specific 
slot for this quantity, the attribute name (e.g. vodml role to keep 
simple) is OK even if the quantity is a generic measurement.

3- BY ??? If the host model has no specific slot for all supported 
quantities we need another mechanism.

It is to be noted the #1 could only occur in the case of data directly 
mapped on STC classes without any container model.

Case #2 is fine as long as modeled data contain a limited number of 
different quantities. This is not true for catalog data where we can 
find any existing quantity.

This question is the basement of my proposal for a model for source data 
  (CABMSD: 
https://wiki.ivoa.net/internal/IVOA/InterOpOct2019DM/A_Component_and_Association__URLFixed.pdf) 
where I link a source instance with a set of generic measurements.
In CABMSD, the role of a particular measurement is given by a semantic 
tag. The nature of these tag is not defined yet, but I'm convinced that 
we need it.
The breaks a little bit the standard modelling approach but I'm afraid 
that this is necessary to get some interoperability level for archival data.


Laurent



Le 21/02/2020 à 09:51, Markus Demleitner a écrit :
> On Thu, Feb 20, 2020 at 02:11:16PM -0500, CresitelloDittmar, Mark wrote:
>>      *) Domain specific Measurement types ("Time", "Position",
>> "Polarization" ) vs "GenericMeasure"
>>          *RESPONSE:*  We feel there is a distinct advantage to being able to
>> define that Field X is a "Time" and Field Y is a "Position", rather than
>> having everything be a generic measurement type.
> Well, for such a rather fundamental design decision I frankly would
> like to have a somewhat stronger reason.
> 
> In particular: Where would this end?  Will we have
> TemperatureMeasure, MassMeasure, MetallicityMeasure,
> EuropiumAbundanceMeasure?  And if not, why not, when we have special
> classes for some other measurements?
> 
> As usual, I'd say it would help a lot if there were a clear scenarios
> how a client would use the particular distinction in these classes
> for something it could not otherwise do  (where, of course, I do not
> deny that clients will have to know that a certain field fills the,
> say, time role in some space-time position -- but that's up to a
> coordinates model, not a measurement model).
> 

-- 
---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
      Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
      11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr
      67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
---