String Measurement with STC2

Laurent Michel laurent.michel at astro.unistra.fr
Wed Sep 4 17:42:08 CEST 2019



Le 04/09/2019 à 14:30, François Bonnarel a écrit :
> Hi all,
> 
> I agree that enums  can be special case of measurements. Spectral types for example is summarizing measurements ?
>
OK, I buy it.
> 
> I also think, like Mark that shapes, regions are different. In the case of source data model and looking at your proposal, 
> Laurent, they could be a specialization of "linked data"
That is a possibility. I take it for now.

LM

> 
> Cheers
> 
> François
> 
> 
> Le 30/08/2019 à 20:25, Laurent MICHEL a écrit :
>> Mark & DMers,
>>
>>
>> Le 30/08/2019 à 18:04, CresitelloDittmar, Mark a écrit :
>>> Laurent,
>>>
>>> To answer the primary question:
>>>    Yes, the models do allow for 'discrete' data, and this is exercised with the Polarization object.
>>>    The values (coord) are PolCoordValue types from the coordinates model, which are Enumerations (matching your second use 
>>> case).
>>
>> That's right. Polarization states and object classes can be both described by enums.
>>
>>>
>>> My expectation for Source model is that it will define other properties which extend Measure in much
>>> the same way as the current suite ( Position, Velocity, ProperMotion, Time, Polarization ).  By extending
>>> Measure, they will automatically be usable in Cube-s.
>> That exactly the pattern I'm working on. The first STC extension I need is for the photometric measurements of course.
>>>
>>> As for non-numeric data.. it really depends on what the string represents.
>>>    e.g. "Q" =  Stokes Polarization
>>>
>>> In your examples, a MOC or STC-S string do not equate to Measure.
>>> STC-S = a standardized serialization for specific sets of STC-1.33 objects.
>>> o The string itself maps to a set of complex objects, not a single value
>>> o  It spans more of STC-1.33 than is covered by the new component models (Coords, Meas, Trans).
>>>     So, while it should be possible to express a Measurement instance as an STC-S string, not all STC-S
>>>     strings can be resolved into NEW component model instances. For example, STC-S includes Regions
>> Region are sufficient for my purpose.
>>>     and Intervals, as well as some properties not covered (Spectral) in the current Measurement model.
>> My concern is to build a branch modeling object shapes. Whatever the chosen option is (MOC, STS region both or anything else) 
>> I was wondering whether a shape can be semantically interpreted as a Measure.
>> Furthermore and practically, I'd be happy to have one superclass for all measurements.
>> But, if I understand well, object shapes are not Measures and the most reasonable approach would be to have one  branch for 
>> the Measures and another for the geometry.
>>
>>>
>>> So, when working the Source model, it'll be important to identify which Properties can extend Measure
>>> (or reuse components thereof), and what concepts are 'missing' (eg: Region).
>> Sure, the best approach is first to reuse VO stuff as much as possible and when this is not possible to be inspired by other 
>> standards or proposals and finally thinking to new things.
>>
>> Laurent
>>>
>>> Mark
>>>
>>>
>>> On Mon, Aug 26, 2019 at 11:26 AM Laurent Michel <laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>> 
>>> wrote:
>>>
>>>     Hello DMers,
>>>
>>>     I'm experimenting the use of STC2 (Meas/Cood) for a proposal for a
>>>     generic model for source data.
>>>
>>>     The idea is to use, as lond as possible,  STC2 measures for all
>>>     quantities attached to one source.
>>>
>>>     My question is to know whether it is possible to have a Measurement
>>>     with non numerical values.
>>>     I've 2 use cases:
>>>     - Object shape: a MOC or a STC string, both being possibly
>>>     serialized as strings
>>>     - Object type: literal
>>>
>>>     Can I use Generic classes (GenericMeasure and GenericCoord) or
>>>     should I extend meas:Measure with my own stuff?
>>>
>>>     Best
>>>     Laurent
>>>
>>>     --     jesuischarlie/Tunis/Paris/Bruxelles/Berlin
>>>
>>>     Laurent Michel
>>>     SSC XMM-Newton
>>>     Tél : +33 (0)3 68 85 24 37
>>>     Fax : +33 (0)3 )3 68 85 24 32
>>>     Université de Strasbourg <http://www.unistra.fr>
>>>     Observatoire Astronomique
>>>     11 Rue de l'Université
>>>     F - 67200 Strasbourg
>>>
>>
> 

-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg



More information about the dm mailing list