: Coords/Measurement model RFC comment response

[François Bonnarel]

Hi all,

To answer Markus I think there are basic measurements (the one we had in 
char DM and Obscore) which are space, time, spectral and polarization. 
Anything else can be considered as derived from this (with  probably the 
exception of DopplerShift which should be added in the future).

So I think we can easily distinguish specific measurements from Generic 
ones. Spectral measurement is probably very close to Generic.

For Time, Spatial and Polarization there are obviously big differences. 
I think they are not only in the Coordinates "subpart" but also 
reflected in the error.

A short question to laurent below too.

Le 25/02/2020 à 11:51, Laurent MICHEL a écrit :
> 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. 
a limited and predefined lst you mean ?
> 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.

My understanding of CABMSD was that these measurements could be 
instances of other models classes, including IVOA meas: ?

In the cABMSD diagram I see a semantic tag inside Parameter. Probably a 
ucd value would work, no ?

What is the value of this tag when the Parameter is actually an IVOA 
Meas:measurement instance ? Still "time" ? "pos" ..... or something like 
Meas ?

Cheers

François

> 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).
>>
>