String Measurement with STC2

[Laurent MICHEL]

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
> 

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