STC/archive/deltas_from_my_model.lis

Deltas between the AR model in UModel vs the alternate model by MCD which  
has been used in the TimeSeries serialization discussions and stems from
the prototype STC-2 work in Cube.

================================================================================
IVOA model:
  + GL changed ivoa model.. rational/complex ==> primitive types: URL change
    ACTION: AR  - update internal proxy in STC
    ACTION: MCD - update internal proxy in STC-alt, DatasetMetadata, Cube [DONE]

================================================================================
Coords Model
  General
    Base Packages
      M: Base elements of astronomical coordinates and systems in base level.
      A: Divides into 'coordsystem' and 'coords' packages.

      ACTION: AR - reduce package structure

    Domain Names
      ** The above change ended up increasing the delta in domain names used
      M: spatial, spectral, temporal, redshift, polarization, pixel
      A: space, spectral, time, redshift, polarization, pixel


    M: CoordSpace.coordAxis:Axis[1..*] vs [1..3].. no need to restrict here
        AR: the restriction was to prevent abuse, but I don't particularly care.

    M: Axis.name[0..1] vs [1].. I don't see any real reason to require a name
        AR: That implies the order of the axes is fixed if > 1..
        MCD: No, objects/instances are not identified by their name, but by their ID

    M: Axis subclasses ==> PhysicalAxis, DiscreteAxis
       A: Axis subclasses ==> CoordAxis, DiscreteAxis, PixelAxis
       a) PhysicalAxis is more descriptive than CoordAxis, coincides with PhysicalCoordValue
          AR: Is a discrete axis not physical?  I think it is.
          MCD: Trying to convey a difference in concept.. migrating to [ ContinuousAxis, BinnedAxis, DiscreteSetAxis ] in alt2 model.

       b) PixelAxis is pixel domain element
          AR: why, if all other axes are defined here?
          MCD: They aren't, these are the base conceptual axes.. a PixelAxis is either a domain specific type, or domain extension of a conceptual (BinnedAxis) type.

    M: BinnedCoordValue datatype for things like "PixelIndex" with cval:integer[1]
       A: IntegerCoordValue equivalent but not descriptive of the concept (Binned, Physical, Discrete)
          AR: "Binned" is too restrictive; it can also be a bed-of-nails. 
          MCD: ??

       A: RealCoordValue is not needed (IMO)
          AR: You need it for non-integer coordinate values in pixel space
          MCD: Which isn't a thing.. what type of axis would it point to?  a PixelAxis with numpix=100 ? would a value of -0.5 be legal? how would you know?

    AstroCoordSystem.refPosition and planetaryEphemeris
     ** These should move back to the Frame(s), they are not accessible at the level they are needed. [AR-DONE][MCD-OPEN]

  Pixel Domain
    A: RealPixelValue.. IMO this is not needed (philosophical difference regarding pixel space).. see RealCoordValue above.
       AR: Your concept of pixel spaces is too restrictive, as it is limited
           to what is essentially a (binning) collimator model;
           I want to explicitly allow pixels derived from a continuous function multiplied by a bed-of-nails function.

    M: PixelAxis in this package along with PixelFrame and PixelSpace
       AR: None of the other axis types are in the domain packages
       MCD: So.. maybe this should just be renamed to something more conceptual?
       AR: adds naxis attribute

    A: PixelCoord*.. not needed


  Polarization Domain
    A: PolEnum == full set with restricive extensions for Stokes, Linear, etc..
        this is better for vodml-ids, so far, I can't make Modelio do this.

  Redshift Domain
    A: DopplerVelocity.dopplerDefinition:DopplerDefinition[0..1] vs [1]
       AR: That allows for specifying a default value; may or may not be useful
    A: DopplerDefinition.. still has 'redshift' option.

  Spatial Domain
    A: SpaceFrame still contains epoch attribute, which was moved to SpatialValue
       AR: I have it in both, allowing the one in SpatialValue to override
       MCD: This is not proper modeling, that is an implementation flattening which would be part of their local
            model if their data was unified.  The element should be associated with the object to which it pertains.

       ACTION: AR - remove 'epoch' from SpaceFrame

    M: [RefLocation - StdRefLocation - CustomRefLocation] vs [Location - StdLocation - CustomLocation]
       difference is mostly in keeping the usage clear, this is not just a general 'location' the spatial domain, 
       it is a reference location.
       AR: Are you sure people might not want to use them by themselves?
           IMO they get that RefLocation designation when the type is used for the refPosition attribute.
       MCD: They shouldn't.. that is what the Position measure if for.  This has a very specific use.

       ACTION: AR - rename *Location => *RefLocation

    M: SpatialCoord type to define vectors of 1,2,3D spatial coordinates, each component == SpatialCoordValue
    A: SpatialValue type 
       MCD: IMO, the vector is a compound Coordinate whose parts are Coordinate Values
       AR: I am not sure what the issue is here: like in the other domains, 
           the coordinate value is called Value, but because of the nature of the space
           it has to be a compound (vector) value here.
       MCD: I see the point, but don't like it.. the 'vector' is the bracket thing [x,y,z] where the 'value'
            is the x, y, or z part.
            I'm migrating further toward this in alt2:
            <Coordinate> <---- <CoordValue> <--- <PhysicalCoordValue> etc
                         \---- CompositeCoordinate
            So, the Value is always the singular coordinate value, while vectors are composite coordinates.

    A: SpatialSpace constrains coordAxes type
       The constraint should be done on the children (Spherical, Cartesian), so that others (HealPix?) can be 
       based off different axis types.
       AR: That depends on whether the expert knowledge of how to interpret the axes rests in the SpatialSpace 
           children or in the specialized axis children.
           If the latter, it means that all new flavors need both an extension to space and to axis..
    *: Neither of us do this, but Epoch would be much more efficient in serialization if it were a primitive type.
       Epoch  with prescriptive format [B,J]<decimal year>
       AR: Isn't that a serialization issue?
       MCD: Kind-of, but it also is a bit over-modeled, the explicit definition adds elements, but not any significant benefit over a defined primitive type.
            This is one of those things where a model change maps better to the most common serialization types (XML,VOTable, FITS, VODML/Mapping).

  Spectral Domain
    <none>

  Temporal Domain
    A: TimeFrame.timeOrigin.. has been TimeFrame.time0 up till now, we've probably crossed compromises as I had
       wanted 'origin' across the board, but have migrated since most domains do not specify an origin.
       AR: So what do we do?
       MCD: pick one.. 
       AR: timeOrigin

       ACTION: MCD - switch to timeOrigin

    A: JD, MJD.. I don't have these as I think they are shortcuts for a TimeOffset with specific set of Frame/Space
         however, could these be extensions of TimeOffset? and do away with JDTime?
       AR: JD and MJD are the most basic variables to set the value of a time stamp.
           Since they are fundamentally different from TimeOffset (like: they don't have a unit), they should not be derived from it.


Measurement Model
  A: sub-packages.  This model doesn't really need subpackaging and I have removed them from mine.  I originally 
     had them to corelate to the coordinate domains, but have dropped them since they typically only have 1 object.
     AR: No strong feelings, but it provides a symmetry with the Coords model
     MCD: This is true.. also no strong feeling and slightly prefer the symmetry.. so lets keep it

     ACTION: MCD - restore domains to Measurement model.

  Pixel Domain
    A: This is the philosophical difference between our views.
       Me - pixel space is binned indexes only... no errors.  A 'measurement' derived from these indexes would 
            reside in a contiguous Spatial domain space, with units of 'pixel'. (eg: chip coords)
       AR: Yes, and I think "pixel" is a pseudo unit whose use should be restricted to pixel spaces
           And, btw, pixel axes can also be projected to domains other than spatial.

  Polarization Domain
    A: PolCoord should be Polarization ala Position, Velocity, Redshift, etc..
       AR: What do we do with the names?  I have 'measure' in them and that does not work for polarization
       MCD: Right.. because it is not a CoordMeasure type, so Polarization should be fine.
       ACTION: AR - rename this element


====================================================================================================
Closed items:
  General
    Domain Package structure
      M: domain, domain/<domainName>
      A: CoordinateDomains, CoordinateDomains/<domainName>Domain
             <model>:domain.spatial.SpatialCoord    vs  <model>:CoordinateDomains.spatialDomain.SpatialCoord
             <model>:domain.temporal.TimeOffset     vs  <model>:CoordinateDomains.timeDomain.TimeOffset
             <model>:domain.spectral.SpectralFrame  vs  <model>:CoordinateDomains.spectralDomain.SpectralFrame
             coords:PhysicalCoordValue.cval         vs  stc2_coordinates:coords.PhysicalCoordValue.cval
      ** The additional structure and repeated text (eg "Domain") leads to longer, more complex looking vodml-ids..

      ACTION: AR - reduce package structure [DONE]


  Pixel Domain
    A: renames PixelFrame.coordSpace => PixelFrame.pixelSpace
       renames PixelSpace.coordAxis  => PixelSpace.pixelAxes
       not sure why.. not done in other domains.
       ** NOT POSSIBLE WITH VO-DML.?  Allows restriction of type only.. see Section 4.21 of spec
          The text says other features may be redefined so long as the redefinition constrains the set of allowed values.
          I guess this would be handled by normal constraint stereotype.. the vo-dml/xml for
          subsetting is simply identifying the subsetted role (original) and the new datatype.
          <constraint xsi:type="vo-dml:SubsettedRole"> 
            <role> <vodml-ref> sample:catalog.AbstractSource.positionError </vodml-ref> </role> 
            <datatype> <vodml-ref>sample:catalog.AlignedEllipse</vodml-ref> </datatype> 
          </constraint>
       ACTION: AR - remove 'rename' of these attributes. [DONE]

    M: PixelIndex vs PixelIndex1D.. 1D is not needed, it is only option.
       ACTION: AR - rename PixelIndex1D [DONE]

  Spatial Domain
    M: StdRefFrame enumeration vs SpaceStdRefFrame.. IMO the 'Space' part is redundant being in the spatial domain.
       ACTION: AR - rename SpaceStdRefFrame => StdRefFrame [DONE]


Measurement Model
  A: CoordMeasure.coord:CoordValue[0..1]   << this type should be BasicCoordValue
     ACTION: AR - change type of this attribute [DONE]
1	Deltas between the AR model in UModel vs the alternate model by MCD which
2	has been used in the TimeSeries serialization discussions and stems from
3	the prototype STC-2 work in Cube.
4
5	================================================================================
6	IVOA model:
7	+ GL changed ivoa model.. rational/complex ==> primitive types: URL change
8	ACTION: AR - update internal proxy in STC
9	ACTION: MCD - update internal proxy in STC-alt, DatasetMetadata, Cube [DONE]
10
11	================================================================================
12	Coords Model
13	General
14	Base Packages
15	M: Base elements of astronomical coordinates and systems in base level.
16	A: Divides into 'coordsystem' and 'coords' packages.
17
18	ACTION: AR - reduce package structure
19
20	Domain Names
21	** The above change ended up increasing the delta in domain names used
22	M: spatial, spectral, temporal, redshift, polarization, pixel
23	A: space, spectral, time, redshift, polarization, pixel
24
25
26	M: CoordSpace.coordAxis:Axis[1..*] vs [1..3].. no need to restrict here
27	AR: the restriction was to prevent abuse, but I don't particularly care.
28
29	M: Axis.name[0..1] vs [1].. I don't see any real reason to require a name
30	AR: That implies the order of the axes is fixed if > 1..
31	MCD: No, objects/instances are not identified by their name, but by their ID
32
33	M: Axis subclasses ==> PhysicalAxis, DiscreteAxis
34	A: Axis subclasses ==> CoordAxis, DiscreteAxis, PixelAxis
35	a) PhysicalAxis is more descriptive than CoordAxis, coincides with PhysicalCoordValue
36	AR: Is a discrete axis not physical? I think it is.
37	MCD: Trying to convey a difference in concept.. migrating to [ ContinuousAxis, BinnedAxis, DiscreteSetAxis ] in alt2 model.
38
39	b) PixelAxis is pixel domain element
40	AR: why, if all other axes are defined here?
41	MCD: They aren't, these are the base conceptual axes.. a PixelAxis is either a domain specific type, or domain extension of a conceptual (BinnedAxis) type.
42
43	M: BinnedCoordValue datatype for things like "PixelIndex" with cval:integer[1]
44	A: IntegerCoordValue equivalent but not descriptive of the concept (Binned, Physical, Discrete)
45	AR: "Binned" is too restrictive; it can also be a bed-of-nails.
46	MCD: ??
47
48	A: RealCoordValue is not needed (IMO)
49	AR: You need it for non-integer coordinate values in pixel space
50	MCD: Which isn't a thing.. what type of axis would it point to? a PixelAxis with numpix=100 ? would a value of -0.5 be legal? how would you know?
51
52	AstroCoordSystem.refPosition and planetaryEphemeris
53	** These should move back to the Frame(s), they are not accessible at the level they are needed. [AR-DONE][MCD-OPEN]
54
55	Pixel Domain
56	A: RealPixelValue.. IMO this is not needed (philosophical difference regarding pixel space).. see RealCoordValue above.
57	AR: Your concept of pixel spaces is too restrictive, as it is limited
58	to what is essentially a (binning) collimator model;
59	I want to explicitly allow pixels derived from a continuous function multiplied by a bed-of-nails function.
60
61	M: PixelAxis in this package along with PixelFrame and PixelSpace
62	AR: None of the other axis types are in the domain packages
63	MCD: So.. maybe this should just be renamed to something more conceptual?
64	AR: adds naxis attribute
65
66	A: PixelCoord*.. not needed
67
68
69	Polarization Domain
70	A: PolEnum == full set with restricive extensions for Stokes, Linear, etc..
71	this is better for vodml-ids, so far, I can't make Modelio do this.
72
73	Redshift Domain
74	A: DopplerVelocity.dopplerDefinition:DopplerDefinition[0..1] vs [1]
75	AR: That allows for specifying a default value; may or may not be useful
76	A: DopplerDefinition.. still has 'redshift' option.
77
78	Spatial Domain
79	A: SpaceFrame still contains epoch attribute, which was moved to SpatialValue
80	AR: I have it in both, allowing the one in SpatialValue to override
81	MCD: This is not proper modeling, that is an implementation flattening which would be part of their local
82	model if their data was unified. The element should be associated with the object to which it pertains.
83
84	ACTION: AR - remove 'epoch' from SpaceFrame
85
86	M: [RefLocation - StdRefLocation - CustomRefLocation] vs [Location - StdLocation - CustomLocation]
87	difference is mostly in keeping the usage clear, this is not just a general 'location' the spatial domain,
88	it is a reference location.
89	AR: Are you sure people might not want to use them by themselves?
90	IMO they get that RefLocation designation when the type is used for the refPosition attribute.
91	MCD: They shouldn't.. that is what the Position measure if for. This has a very specific use.
92
93	ACTION: AR - rename Location => RefLocation
94
95	M: SpatialCoord type to define vectors of 1,2,3D spatial coordinates, each component == SpatialCoordValue
96	A: SpatialValue type
97	MCD: IMO, the vector is a compound Coordinate whose parts are Coordinate Values
98	AR: I am not sure what the issue is here: like in the other domains,
99	the coordinate value is called Value, but because of the nature of the space
100	it has to be a compound (vector) value here.
101	MCD: I see the point, but don't like it.. the 'vector' is the bracket thing [x,y,z] where the 'value'
102	is the x, y, or z part.
103	I'm migrating further toward this in alt2:
104	<Coordinate> <---- <CoordValue> <--- <PhysicalCoordValue> etc
105	\---- CompositeCoordinate
106	So, the Value is always the singular coordinate value, while vectors are composite coordinates.
107
108	A: SpatialSpace constrains coordAxes type
109	The constraint should be done on the children (Spherical, Cartesian), so that others (HealPix?) can be
110	based off different axis types.
111	AR: That depends on whether the expert knowledge of how to interpret the axes rests in the SpatialSpace
112	children or in the specialized axis children.
113	If the latter, it means that all new flavors need both an extension to space and to axis..
114	*: Neither of us do this, but Epoch would be much more efficient in serialization if it were a primitive type.
115	Epoch with prescriptive format [B,J]<decimal year>
116	AR: Isn't that a serialization issue?
117	MCD: Kind-of, but it also is a bit over-modeled, the explicit definition adds elements, but not any significant benefit over a defined primitive type.
118	This is one of those things where a model change maps better to the most common serialization types (XML,VOTable, FITS, VODML/Mapping).
119
120	Spectral Domain
121	<none>
122
123	Temporal Domain
124	A: TimeFrame.timeOrigin.. has been TimeFrame.time0 up till now, we've probably crossed compromises as I had
125	wanted 'origin' across the board, but have migrated since most domains do not specify an origin.
126	AR: So what do we do?
127	MCD: pick one..
128	AR: timeOrigin
129
130	ACTION: MCD - switch to timeOrigin
131
132	A: JD, MJD.. I don't have these as I think they are shortcuts for a TimeOffset with specific set of Frame/Space
133	however, could these be extensions of TimeOffset? and do away with JDTime?
134	AR: JD and MJD are the most basic variables to set the value of a time stamp.
135	Since they are fundamentally different from TimeOffset (like: they don't have a unit), they should not be derived from it.
136
137
138	Measurement Model
139	A: sub-packages. This model doesn't really need subpackaging and I have removed them from mine. I originally
140	had them to corelate to the coordinate domains, but have dropped them since they typically only have 1 object.
141	AR: No strong feelings, but it provides a symmetry with the Coords model
142	MCD: This is true.. also no strong feeling and slightly prefer the symmetry.. so lets keep it
143
144	ACTION: MCD - restore domains to Measurement model.
145
146	Pixel Domain
147	A: This is the philosophical difference between our views.
148	Me - pixel space is binned indexes only... no errors. A 'measurement' derived from these indexes would
149	reside in a contiguous Spatial domain space, with units of 'pixel'. (eg: chip coords)
150	AR: Yes, and I think "pixel" is a pseudo unit whose use should be restricted to pixel spaces
151	And, btw, pixel axes can also be projected to domains other than spatial.
152
153	Polarization Domain
154	A: PolCoord should be Polarization ala Position, Velocity, Redshift, etc..
155	AR: What do we do with the names? I have 'measure' in them and that does not work for polarization
156	MCD: Right.. because it is not a CoordMeasure type, so Polarization should be fine.
157	ACTION: AR - rename this element
158
159
160	====================================================================================================
161	Closed items:
162	General
163	Domain Package structure
164	M: domain, domain/<domainName>
165	A: CoordinateDomains, CoordinateDomains/<domainName>Domain
166	<model>:domain.spatial.SpatialCoord vs <model>:CoordinateDomains.spatialDomain.SpatialCoord
167	<model>:domain.temporal.TimeOffset vs <model>:CoordinateDomains.timeDomain.TimeOffset
168	<model>:domain.spectral.SpectralFrame vs <model>:CoordinateDomains.spectralDomain.SpectralFrame
169	coords:PhysicalCoordValue.cval vs stc2_coordinates:coords.PhysicalCoordValue.cval
170	** The additional structure and repeated text (eg "Domain") leads to longer, more complex looking vodml-ids..
171
172	ACTION: AR - reduce package structure [DONE]
173
174
175	Pixel Domain
176	A: renames PixelFrame.coordSpace => PixelFrame.pixelSpace
177	renames PixelSpace.coordAxis => PixelSpace.pixelAxes
178	not sure why.. not done in other domains.
179	** NOT POSSIBLE WITH VO-DML.? Allows restriction of type only.. see Section 4.21 of spec
180	The text says other features may be redefined so long as the redefinition constrains the set of allowed values.
181	I guess this would be handled by normal constraint stereotype.. the vo-dml/xml for
182	subsetting is simply identifying the subsetted role (original) and the new datatype.
183	<constraint xsi:type="vo-dml:SubsettedRole">
184	<role> <vodml-ref> sample:catalog.AbstractSource.positionError </vodml-ref> </role>
185	<datatype> <vodml-ref>sample:catalog.AlignedEllipse</vodml-ref> </datatype>
186	</constraint>
187	ACTION: AR - remove 'rename' of these attributes. [DONE]
188
189	M: PixelIndex vs PixelIndex1D.. 1D is not needed, it is only option.
190	ACTION: AR - rename PixelIndex1D [DONE]
191
192	Spatial Domain
193	M: StdRefFrame enumeration vs SpaceStdRefFrame.. IMO the 'Space' part is redundant being in the spatial domain.
194	ACTION: AR - rename SpaceStdRefFrame => StdRefFrame [DONE]
195
196
197	Measurement Model
198	A: CoordMeasure.coord:CoordValue[0..1] << this type should be BasicCoordValue
199	ACTION: AR - change type of this attribute [DONE]
msdemlei@ari.uni-heidelberg.de	ViewVC Help
Powered by ViewVC 1.1.26