Coordinates model - Working draft.

[Laurino, Omar]

On Thu, Jan 17, 2019 at 5:12 AM Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

>
> (a) Why do you keep the information that epoch's values are in DALI's
> ISO format in two places (COLUMN/@type and FIELD/@xtype)?
>
> (b) And even if you have a good reason to have the same piece of
> information in two places, why do you use two different vocabularies
> (ISOTime vs. timestamp)?
>
> I'd be great if I didn't have to answer them.
>

That's a very good point. The thing is that the conversation on using the
DALI types came about after we had proposed 3 different mapping strategies
(the first one, six years ago, used VOTABLE 1.3, the second one added very
few element types to VOTABLE 1.3, the third introduced a bunch of new
element types).

I remember Pat giving a presentation on this at one of the latest Interops,
and we probably never followed up. Maybe we should branch off and keep that
conversation going. In my opinion the question is: can we find a formal way
of reusing the DALI types in the VODML serialization and/or in the model
definitions? Having VODML Mapping depend on DALI does not sound too wise,
but it doesn't mean we can't do it or find a way around it.

Note that one of the design decisions of the first mapping proposals was
exactly what Markus said, i.e. make sure existing parsers would be able to
just keep parsing what they know, and just add DM/semanting information
using additional markup. Those proposals were shot down. Then when
redesigning Mapping we decided we didn't want to reuse the FIELD/PARAM type
exactly to avoid the current type-attribute-creep (type, datatype, utype,
xtype, to which people were suggesting adding a dmtype). There were also
other reasons, i.e. trying to decouple the VODML element type from VOTABLE
as much as possible.

Can we find a sustainable way to reuse the DALI types in DM in a rigorous,
sustainable way that also facilitates things for parsers? I hope we can, or
we should have rather compelling reasons not to.


> Ah... well, I had in mind something a bit more concrete; you see, in
> DM I think we're doing us a favour if each box in our UML diagrams
> can be clearly and as unambiguously as possible (applying Occam's
> razor) derived from a requirement, which again would be derived from
> a very concrete use case ("merge two time series from different
> sources; examples of time series we want to look at include ivo://X,
> ivo://Y, and ivo://Z").  That way, I think a lot of the DM
> discussions would become a lot less tedious.
>
>
Hear hear! I have been bringing this up so many times, for some reason
everybody agrees but then we never do it. I wouldn't stop trying though.

Omar.

-- 
Omar Laurino
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
100 Acorn Park Dr. R-377 MS-81
02140 Cambridge, MA
(617) 495-7227
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20190117/7a4e32d3/attachment.html>