Time Series Cube DM - IVOA Note

[Markus Demleitner]

Dear Mark, Dear everyone-else-who-as-stuff-in volute/.../DM,

I got hold of some time series data and would now like to write a
prototype service for these.  I'd like this to spit out something as
close to current drafts, Jiris proposal, SPLAT implemenation, and my
hopes at the same time.  For that, it would be great if I had a
blueprint of the "current upstream idea", as it were.  So,

On Mon, Mar 27, 2017 at 05:38:55PM -0400, CresitelloDittmar, Mark wrote:
> I have 'mocked' the resulting model changes and generated some example
> files:
>   1) chandra event list (real-world cube file)
>   2) timeseries example from the Note.. Figures 5, 6, 7
>       with added detail about the CoordSys, Frames, etc.

Are these files available now?  If so, where?


But since I just stumbled around in the DM tree in volute, I've
accumulated some additional requests as regards its (particular)
contents.  They come mainly with my user hat on (at least for me, it
is *very* hard to figure out what's what right now), but a little bit
of what's on my head is also coming from me as operator; everything's
much easier for a VCS (and makes more sense) if the amount of binary
data is a low as it can possibly be.

(1) volute is a VCS, so it does versioning by itself.  It would
therefore be great if you just kept the latest version of each
document in there and *not* use version number in file names.  If
people actually want to go back in time, they can use the standard
svn mechanisms (svn log, svn co -r...; yes, with office files there
are no diffs, which is regrettable, but the full files are still
there).  That would already clean up a directory like
http://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/doc/ very nicely.

(2) Being a VCS, I think volute should not be polluted by things that
aren't "source" but can be generated from things in volute.  In
particular, I don't think "baked" PDFs should be in there.  They are
almost certain to cause version conflicts, and there's no added value
in having them in a VCS.  And no, putting PDFs into volute don't
really improve any of the issues associated with using docx...

(3) It'd be great if there was a top-level readme explaining where
things are supposed to be (there's vo-dml/README.txt that goes a long
way, but how does that relate to the rest of the dm tree?).  Right now,
if I look for, say, the vo-dml of Dataset, where do I go?  Is
http://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/models/ the right
place?  Or
http://volute.g-vo.org/svn/trunk/projects/dm/DatasetMetadata-1.0/model/?
In the latter directory, there's even a zip file -- that in turn
contains a project.conf that says "GENERATED FILE, PLEASE DO NOT
EDIT!!!" [all the bangs included] -- does something like this really
have to be under version control?

(4) Lastly, again since volute is a VCS, it would be great if you
could just delete from trunk the traces of efforts that are pretty
certainly abandoned (e.g., ImageDM, I guess, SpectralDM-2.0 as well).
These things can always be recovered from the history if really
necessary, and if you think they must be visible somewhere in
HEAD, just make a tag containing whatever is going on (e.g.

svn copy http://volute.g-vo.org/svn/trunk/projects/dm/SpectralDM-2.0/ \
http://volute.g-vo.org/svn/tags/DM-attic/SpectralDM-2.0-as-abandoned
svn remove http://volute.g-vo.org/svn/trunk/projects/dm/SpectralDM-2.0/

All of that would really help usability of the dm subtree in volute.

Thanks,

        Markus