Coords/Measurement model RFC comment response

[François Bonnarel]

Hi Laurent, all

Le 24/03/2020 à 11:49, Laurent MICHEL a écrit :
> 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.
>
Thanks for confirming that.

There still remains this part of the question

"What is the value of this tag (ucd) when the Parameter is actually an 
IVOA Meas:measurement instance (as can be seen in your diagram) ? Still 
"time" ? "pos" ..... or something more specific to this data model ?

Cheers

François

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