[trans] - Model Comments (was RE: [vo-dml] Clarification on composition rule..)

[David Berry]

On Wed, 11 Mar 2020 at 15:39, Gerard Lemson <glemson1 at jhu.edu> wrote:
>
>
> Hi David
> Maybe some of your points have already been addressed in further emails and I think discussion should continue on those.
> Nevertheless I wanted to respond to some of your comments.
>
>        . I'd been thinking of the Transform model itself as a black-box that simply describes how to transform a given anonymous input vector to create an anonymous output vector.
> One other consequence of VO-DML is that sharing models has some restrictions and when making a reusable “blackbox” model should be taken into account.. For example a model should not define a type that has a composition relationship with a type defined in a second, imported model. Inheritance, reference and attribute relationships are fine though. So indeed having a FrameSet that could be inherited or referenced would be nice. Also using datatype-s if possible makes for good reusability.
>
>        Here we depart. Can you say what benefit you see from using a FrameSet to describe a compound Mapping,
> I accept you comments on not using the frameset as a compound mapping, I misunderstood the two concepts.
> I was not so much thinking about the latter really, being more concerned to see how the mapping are to be used.
> I understand from Mark this is still under construction.
>
>        Describing an intrinsically 2->2 mapping like a spherical projection as two 2->1 AxisMappings seems strange - each AxisMapping would presumably contain exactly the same parameter values (tangent point, axis scalings etc), as would any AxisMappings used to describe the inverse. So a Mapping used to describe a spherical projection would end up with four identical  parameter lists (2 forward, 2 inverse)
>
> As my sketch was a domain model, and not meant to replace or suggest changes to the Tranform model (see my reply to Mark’s email), I am not concerned with efficiency of representation. I wanted to see how far down one can go in describing the transformation, whilst thinking in terms of simplistic atomic operations that can be expressed as equations.
>
>        I'm not sure I understand what you mean by "explicit" and "implicit".
> As in implicit functions (https://en.wikipedia.org/wiki/Implicit_function). Maybe related to the iterative methods you are referring to in …
>        We tried using a string description for transformations back in the 1980's  (see section 2.2. of the AST paper https://arxiv.org/pdf/1602.06681.pdf)…
> In the paper it is stated that “A transformation is a mathematical recipe for converting a numerical input vector into a corresponding numerical output vector."
> So I thought in a domain modelling sense I could assume such expressions. But fair enough that for implementations it might become unwieldy.
> On the other hand, could/should metadata about the allowed input and output be part of the definition of a Mapping?
> Dimensionalities could be one, but is there also more? For example a mapping that transforms cartesian into polar coordinates, should as input not be given polar coordinates, even if represented as a 2d vector. So is some information about the acceptable input and output coordinate spaces also part of the definition?

It could well be possible to produce an implementation library that
transforms some sort of Quantity object instead of simple numerical
vectors. Then maybe the library could check that the supplied object
was of a type suitable to the Mapping class being used. But presumably
the restrictions imposed by each class of Transform would be implied
by the class of the Mapping being used, rather than being specified
explicitly within the Mapping structure.

> Btw, from the reference I understand that there are types of mapping for which you basically seem to say we better give up trying to give a full metadata description, but that we should accept certain types only to be represented by code. Is that correct? If so, does that tie this Transform model to AST as a specific implementation, or are such cases not supported in the model?

Are you thinking of the IntraMap class
(http://starlink.eao.hawaii.edu/devdocs/sun211.htx/sun211se20.html)?
This was an early experiment in trying to accommodate projects that
wanted to define there own Mappings, which would only be used
in-house. These are indeed defined by code rather than meta-data. It
was a bit of a kludge to encourage IRAF to use AST (many years ago),
and has never really been used in anger as far as I am aware. They do
not really fit into the rest of the AST data model.

>        If someone was supplied with an object such as you describe, and that object contained a pair of AxisMappings that describe how to go "from"
> pixel coords "to" (ra,dec), should they also be able to use that same object to transform an (ra,dec) position into pixel coordinates?
> No, that is not what I would expect in general. Maybe smart code can do that, but I would think it is up to the context if such an inverse is expected or not and whether a publisher may need to provide this.

>        That's not really how I understood Mark's problem. I though it was to do with the technical point that vo-dml disallows two or more classes from composing the same ObjectType.
> Sure, but it appeared in a particular part of the model, and just saying “you shall not do that” does not solve the modelling issue I thought. Then it led via Pat to further discussion on datatype vs objecttype which really made me want to understand the model better.

David