/[volute]/trunk/projects/dm/STC/archive/deltas_from_my_model.lis
ViewVC logotype

Contents of /trunk/projects/dm/STC/archive/deltas_from_my_model.lis

Parent Directory Parent Directory | Revision Log Revision Log


Revision 5237 - (show annotations)
Tue Nov 20 20:30:08 2018 UTC (2 years, 2 months ago) by mdittmar
File size: 11181 byte(s)
restructure to separate component models, archive AR version
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