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: <---- <--- 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] 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 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/ A: CoordinateDomains, CoordinateDomains/Domain :domain.spatial.SpatialCoord vs :CoordinateDomains.spatialDomain.SpatialCoord :domain.temporal.TimeOffset vs :CoordinateDomains.timeDomain.TimeOffset :domain.spectral.SpectralFrame vs :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. sample:catalog.AbstractSource.positionError sample:catalog.AlignedEllipse 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]