On Fri, 5 Sep 2003, David Berry wrote:
> At the IVOA meeting at Cambridge Jonathan McDowell asked me to
> get some discussion going on possible ways of representing transformations
> within the IVOA data model. I made an early attempt, focussing on the use
> of transformations to represent WCS information. This failed to raise much
> response, other than Doug Tody saying that the FITS-WCS papers supply
> everything we need. However, given that the next IVOA meeting is not far off,
> I thought I should have another bash. So I've produced a document giving
> an outline of an AST-like approach to the representation of
> transformations (i.e. Mappings - no Frames) which I intend to advertise on
> the IVOA mailing lists. It's at:
>
> http://www.ast.man.ac.uk/~dsb/ivoa/VOMapping.html
>
> I would welcome any comments (ASAP) before I make it public. Not so much
> on the detail, so much as on the overall approach. For instance, I've not
> included any formal definitions, either as XML schemas, or RDF, or
> anything else. Neither have I spent much time on the issue of how and
> where these transformations could be used within the IVOA data model.
Hi David,
from quick read of this the one thing that stood out as missing was a
concept of formal applicability. Clearly mappings defined this way have a
very limited scope, so some way of accessing their appropriateness is
needed, i.e. you need metadata to define what the input and output systems
can be.
I presume that the passing reference to "plus property accessor methods",
hides the fact that these mappings are also configurable to match specific
instances of input and output systems.
It seems to me (late on a Friday to be fair), that without applicability
rules your mappings are just "out there", when what they really need to do
is connect to physical systems, so they must have some sense of units
(maybe AST has some hidden mappings that need to be drawn out, the ones
that Frames use to provide purified outputs for the mappings).
No doubt this isn't what you wanted!
Cheers,
Peter.
|