Coords/Measurement model RFC comment response

[Laurent MICHEL]

Hi all

Response to Francois:
====================
The CABMSD proposal has a semantic attribute to set the role of generic 
measurements.
This can (has to) be done by UCDs although this not stated in the model.
I would say that using UCDs is the very best choice as long as we 
haven't hit a dead end.

Laurent


Le 19/03/2020 à 18:03, Francois BONNAREL a écrit :
> 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).
>>>
>>

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