String Measurement with STC2

François Bonnarel francois.bonnarel at astro.unistra.fr
Wed Sep 4 14:30:49 CEST 2019


Hi all,

I agree that enums  can be special case of measurements. Spectral types 
for example is summarizing measurements ?


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"

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



More information about the dm mailing list