Suggested best practices
Phyllis
developers might want to consider when implementing support for OAL.
These are minor things that can make exchanging data less confusing
for users. If you agree, perhaps these should be listed as best
practices in documentation for developers.
1) Session and site information is recommended for all observations.
2) Universal time is recommended for dates and times.
3) Applications should accept object designations as being equivalent
without regard to case - ngc7000 == NGC7000
4) Applications should accept object designations as being equivalent
whether a space separates the catalog acronym from the object number
or not - NGC 7000 == NGC7000.
I am aware that DeepSkyLog doesn't provide session information. My
implementation requires sessions, so I generate a session on importing
an OAL file to improve compatibility.
Items 3 & 4 really should be stated. I have run into item 4 myself and
have plans to address it.
Comments?
- Phyllis
Dirk Lehmann
I think that's a great idea, if we would come up with such a "Best
practise" document.
and your examples given below make absolut sense to me.
I think we should separate between, best practises for OAL
implementing developers/applications
and recommendations for OAL end-users.
No.1 and No.2 aren't really best practises/recommendations for OAL
implementing
developers/applications, but for end-users. So, it might be more
likely that we'll face data
that doesn't stick to those recommendations, as the # of end-user will
be higher as the # of
OAL supporting applications.
Let me add some more Best practises for OAL applications, I've learned
while implementing Observation Manager:
- If a session is set for an observation, the list of coObservers
shouldn't list the observations' observer again
(OM can deal with it, but from a sematical pov this looks odd to me
and OM asks, whether this was intended, if the end-users enters the
data like this)
- If a session is set for an observation, the start/end date/time of
the observation should be within the sessions' start/end date/time.
- End dates/times should be after the given start date/time
- If a session is set for an observation, and that session contains a
site, this site must be used for the observation as well.
(Where the site XML element should be set in the XML structure of the
session as well as in the XML structure of the observation itself,
even though this might
be redundant, it'll ensure that data can be read correctly in other
OAL applications)
- The Constellation used in the target type, should be filled with the
nominative latin name of the 88 constallations approved by the IAU, or
with
the three-letter abbreviations of the constellation (approved by IAU)
(see http://www.iau.org/public_press/themes/constellations/)
- If there's a specialized Finding for a target type available, the
most specialized finding for a target type should be used.
E.g. for observations of deepSkyDS the finding type
findingsDeepSkyDSType should be used
- The same should hold true for targets. Used target types should be
as specialized as possible.
That's what I've for now...
What do you guys think?
Best
Dirk
Tom
previously I have played a bit with Deep Sky Planner 5, Observation
Manager 0.920 and Eye&Telescope (dev version, will become 3.1.1).
Imagine the following situation: from an OAL compatible datasource
like www.deepskylog.org or by exchange with other users of the
programs mentioned above, you have collected a bunch of observations.
Due to different naming of optics, eyepieces, sites and so on there
will sometimes be multiple "items" that indeed refer to one and the
same "item". For example take an eyepiece. It could be named "Meade
UWA 8,8mm" or "UWA 8.8 mm (Meade)" and so on.
I'm working on a "consolidator" feature to detect and re-unify such
aliases of the same true thing. Progress is good and my design seems
to work. A key task in consolidating is finding similiar items, of
course. To this, I've invented a "degree of similarity". To calculate
this, the code compares strings and it looks for deviations of scalar
properties of item (like aperture, focal length, magnification,
latitude, longitude, time zone, field of view, ...). The deviations
are weighted and together with hit or miss of names/designations a
number comes out. The closer to 1, the more similar the two items are.
Simple but effective.
I ran across the optics type: this is a string and our OAL Schema does
not enforce an enumeration. Instead of this, a recommendation is
written in a comment, specifying what letters should be used for what
type of optics.
Eye&Telescope only allows for the recommended optics types.
When importing a file with Dirk's observations, I detected that OM
allows for free entry of the optics type. Yes, you guessed it: my
similarity decreases because a "Newton" is not a "N".
As one best practise, I recommend to restrict the optics type to the
letters suggested in the comments of our Schema file.
Clear skies,
Tom