Time Series Cube DM - IVOA Note

Wed Apr 5 16:01:10 CEST 2017

Markus,

On Wed, Apr 5, 2017 at 8:28 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> 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?
>

I have the file from this pass.  I did not submit it because upon review,
we realized that the change I made to the model broke a different
requirement.. namely the ability to specify the flavor of a 'Measurement'
(eg;  target.pos:Position )

I have a new revision which accommodates both, and will be generating that
(and other) examples in the next couple days.
We have been focused the past few days on resolving some details needed to
get a PDF working draft out to the group.

> 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.
>

Agreed!

>
> (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...
>
> A little more problematic since a lot of people do their documenting in
something other than tex, but I understand the concern.

> (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?
>
We have need to share the model project in progress, this zip file is that
project.  As things evolve, and we have better, vo-dml savvy,  modeling
tools available, this will be cleaner.

There is a section in the vo-dml beginner's guide which describes the
layout that I would like to see here...
(obviously, there is a lot of heritage stuff, but it is the layout that
I've been using).  I agree that a README
with that content in the 'dm' directory would be helpful.

In general
   .../dm/<model>/*   ==  model document (PDF), diagrams, project file
(UML) content, and XMI export
   .../vo-dml/models/<model> == vo-dml XML and HTML products

> (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.
>

Good suggestion.

I know the 'stc' project is particularly confusing in this regard, with
some early prototypes to cast stc1 etc,
We will be cleaning some of this up as we go forward.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170405/8b1afe22/attachment-0001.html>