Target -> Result/Finding mapping

[Dirk Lehmann]

Hi *,

I just did some <OAL> 2.0 programming on OM and found something that I
already realized several times in the past (I think Tom and I
discussed this shortly quiet some time ago...).

In the 2.0 example file (in our download section) you'll find
observation obs_303757 which targets a DeepSkyMS (Multiple
Starsystem). As result/finding type this observation refers to
"oal:findingsType" which is the generic finding type (without e.g.
rating, diameter, etc.). OM uses the DeepSkyFinding type
(oal:findingsDeepSkyType) for DeepSkyMS targets.
In worst case this would mean data loss for the end user, as OM and
E&T use different target<->finding mappings.

Here's how OM maps finding types to target types:
DeepSkyTargetDN -> oal:findingsDeepSkyType
DeepSkyTargetNA -> oal:findingsType
DeepSkyTargetDS -> oal:findingsDeepSkyDSType
DeepSkyTargetGC -> oal:findingsDeepSkyType
DeepSkyTargetGN -> oal:findingsDeepSkyType
DeepSkyTargetGX -> oal:findingsDeepSkyType
DeepSkyTargetOC -> oal:findingsDeepSkyOSType
DeepSkyTargetPN -> oal:findingsDeepSkyType
DeepSkyTargetQS -> oal:findingsDeepSkyType
DeepSkyTargetAS -> oal:findingsDeepSkyType
DeepSkyTargetSC -> oal:findingsDeepSkyType
DeepSkyTargetMS -> oal:findingsDeepSkyType
DeepSkyTargetCG -> oal:findingsDeepSkyType

variableStarTargetType -> findingsVariableStarType

CometTargetType -> oal:findingsType
MinorPlanetTargetType -> oal:findingsType
MoonTargetType -> oal:findingsType
PlanetTargetType -> oal:findingsType
SunTargetType -> oal:findingsType

Should we define a fix mapping in OAL? If yes, which? If no, I think
we should give at least some guideance on how to deal with this issue.

Best regards

Dirk

[Tom]

Hi Dirk,

please have a look at this:

<!-- New in V2.0: type definition for multiple stars -->
<xsd:complexType name="deepSkyMS">
<xsd:complexContent>
<!-- pls. note that this element is not derived from
oal:deepSkyTargetType -->
<xsd:extension base="oal:observationTargetType">
<xsd:sequence>
<!-- star which is a component of the multiple star system -->
<!-- refers to oal:starTargetType -->
<!-- Must occur at least three times. For double stars please use
oal:deepSkyDS -->
<xsd:element name="component" type="xsd:IDREF" minOccurs="3"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

Especially this: <!-- pls. note that this element is not derived from
oal:deepSkyTargetType -->

Thinking over this, I realize that the target type hierarchy and the
findings type hierarchy match pretty well in this case. Using a deep
sky findings type to describe a target that's not modelled as a deep
sky one simply seems confusing to me.

We have a similiar case of mismatch between the target and findings
type hierarchies: the NA (not applicable, meaning undefined) target
that derives from deep sky target but uses only a generic findings
type. The thought on this was that it might be a deep sky target not
covered by the well established types (f.e. a nova) but it could also
be a "near sky" object or even a transitory phenomenon such a sighting
of noctilucent clouds, an aurora or a halo.

I think on this from an OO point of view: you can always cast upwards
to more generic information, omitting or losing some data. But
downcasting an object to something it actually is not the type of
would be rejected by a compiler :-)

So if you want describe a MS with attributes of a deep sky findings
type, I would suggest to derive the MS from the deep sky target ype.

Whatever the MS is derived from, it will not break E&T as my program
simply does not take care of single, multiple or variable stars.

Meanwhile I'm doing some testing of Wim's deepskylog.org/test and it
really seems good. He could sort out one issue after the other. Sadly
I have to admit that E&T 3.1 (with OAL2 support) has a bunch of issues
I have to work on. So I cannot provide a beta for testing purposes
right now. But just as always: progress is slow, but it happens.

Best regards,
Tom

[Dirk Lehmann]

Hi Tom,

you're absolutly right. DeepSkyMS doesn't derive from
oal:deepSkyTargetType, that was the problem in my coding (which I
fixed).

However, the basic question remains, should we
a) force a certain mapping to be used
b) give some guideline which mapping could be used
c) do nothing here

I would vote for b). With that developers would have some guideance,
which finding types map best to which targets and the risk of some
incompatible usage
get's minimized.

Btw: OM8.20 is doing good with OAL2.0 now. I need some more testings,
before I can release a beta for testings...

Regards

Dirk

[Tom]

Hi Dirk and *

> However, the basic question remains, should we
> a) force a certain mapping to be used
> b) give some guideline which mapping could be used
> c) do nothing here
>
> I would vote for b). With that developers would have some guideance,
> which finding types map best to which targets and the risk of some
> incompatible usage
> get's minimized.
>

I agree with you. Basically the findings type hierarchy and the target
type hierarchy are parallel. BTW "Parallel hierarchies" is even an OO
design pattern.

> Btw: OM8.20 is doing good with OAL2.0 now. I need some more testings,
> before I can release a beta for testings...
>

This is great news to hear. And yet better, Wim was very busy and his
deepskylog.org test version is handling gracefully what I throw
against it from Eye&Telescope. I could import all of my deep sky
observations and was able to download several thousands of
observations from deepskylog and import it successfully into E&T. We
can see that the "hub" in the center of all OAL exchange is almost
ready. Regarding Eye&Telescope, now the XML stuff for OAL 2.0 seems to
work correctly, too. There are some loose ends and minor bugs left
over to be fixed, but this is no big deal. Sadly I have to document a
lot of new stuff in two languages and this means that I'm not too
close to the release of version 3.1. But I think that I can provide a
beta version for compatibility and data exchange testing within the
next three or four weeks.

Maybe Phyllis can join the test? How are you doing?

Best wishes,
Tom

[Phyllis]

Hi All,

I'm working on a bunch of loose ends myself. I have put my data import
and export code through *very thorough* unit testing this summer. I am
currently looking at updating some software components that I use in
preparation for Windows 7, and once that's complete I'll update my OAL
transforms and put them through internal testing before bothering you
guys with it.

Having spent a good deal of time testing import and export, I have a
good foundation to work with when I begin updating my OAL transforms.
I am optimistic that it will go well.

As regards target types and findings architecture, I shouldn't comment
until I have worked in that area again and saturated my mind with the
OAL schema. I can say that the discussion that I've read so far seems
agreeable. I expect to support the upper end of the 'class structure'
and I already have development notes for transforming to and from OAL.
After I update those notes, I should be able to distill some
information for a guidelines document.

I am sorry that I haven't been more in touch this summer. I've been
working on other areas in my product, and family life has been super
busy. Daughter has gone to university now so maybe things will quiet
down. Of course I still have a son at home to keep me on my toes :-)

Best to all,
- Phyllis