Datalink data access services

[Markus Demleitner]

Dear DAL,

On Fri, Dec 13, 2013 at 10:02:41AM +0100, Pierre Fernique wrote:
> best or for the worst. After the big discussion on the proposed new
> utype promotion (Heidelberg + Hawaii), it seems that new standards,
> such as Datalink are reluctant to use these old utypes (simple string
> tagging), but do not want, or do not arrive to use them with the new


Utypes do have a role in current datalink in marking up PARAMs as
data model elements (as they should). In the sample documents, you
see STC markup like this:

    <GROUP utype="stc:CatalogEntryLocation">
      <PARAM arraysize="*" datatype="char" name="CoordFlavor" 
        utype="stc:AstroCoordSystem.SpaceFrame.CoordFlavor" value="SPHERICAL"/>
      <PARAM arraysize="*" datatype="char" name="CoordRefFrame" 
        utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame" value="ICRS"/>
      <PARAM arraysize="*" datatype="char" name="ReferencePosition" 
        utype="stc:AstroCoordSystem.SpectralFrame.ReferencePosition" 
          value="BARYCENTER"/>
      <PARAMref ref="asoolshohtdn" 
        utype="stc:AstroCoordArea.Position2VecInterval.HiLimit2Vec.C1"/>
      ....

(from Appendix A), and now that you mentioned it, I've added SSAP
utypes to (some of the) parameters from the SSA examples in Appendix
B, too:

      <PARAM arraysize="*" datatype="char" name="FORMAT" 
        ucd="meta.code.mime" utype="ssa:Access.Format" value="">
        <DESCRIPTION>MIME type of the output format</DESCRIPTION>
        <VALUES>
          <OPTION name="FITS binary table" value="application/fits"/>
          <OPTION name="Original format" value="image/fits"/>

(though I frankly don't believe that's useful).  VO-DMLed data models
will look a bit more like the one in Appendix A, but if you want to
write old-style data models and have them represented in Datalink,
the second example shows how to do it.

The only place I've missed something like utypes in datalink proper,
was marking up the FIELD to take the identifier from; with it, we
could have used a FIELDref and thus piggyback on a mechanism that
pretty much looks like something well-established. But I believe the
proposed way with LINK and a content-role actually is clearer and
more scaleable if new requirements come up, and I wouldn't want da DM
definition for just a single utype anyway.

However:

> but as the need of recognizing fields has not magically disappeared,
> we see (below) to come back the usage of UCD just for tagging fields.
> Well, we had invented utype especially for avoiding it (SIAP v1, VOX
> UCD).

Pierre here referred to my table of proposed PARAMs:

> >   ID              meta.id;meta.main (none)
> >   DEC_MIN         param.min;pos.eq.dec deg      (1)
> >   DEC_MAX         param.max;pos.eq.dec deg      (1)
> >   RA_MIN          param.min;pos.eq.ra deg      (1,2)
> >   RA_MAX          param.max;pos.eq.ra deg      (1,2)

And there, no, I strongly believe that this is *not* a place for
utypes.  These parameters have a *physical* meaning, and UCDs exactly
give this physics.  And that is exactly right, as people want to
constrain the physics here, not values in some data model that they
probably don't know in the first place.

I give you the param.min/param.max things *could* go into a data
model for compond types in the VO.  However, since max/min is so
common (and actually necessary to sensibly query float-valued things
in the first place), I'd say promoting "desired max/min" to being
physical entities bends the rules in good proportion to the utility
of the sleight-of-hand.

Let me make the above statement a bit stronger: Data access services
as specified by the generic datalink spec should not be based on a
data model.  I maintain UCDs are sufficient (they clearly indicate
what you're cutting out or what operation you're going to perform).
If that is true (and if you think it's not, please give me use case
where this fails), than building this on a data model -- whether
ImageDM or something even more general that would include, e.g.,
recalibration of spectra -- is actually a bad thing since it
immediately excludes all server-side processing jobs that could
otherwise be satisfied using datalink.

If, on the other hand, we later find out that some specific use case
actually needs a data model-exact annotation of the PARAMs of, say,
ImageDM or whatever, that's still straightforward to do.  The current
STC prescription shows how to do that, as do the VO-DML drafts and
Sebastien's photometry draft.

And with UCDs still there, even clients unaware of the data model
would still work.  Isn't that wonderful?

>  * Does it means that the utypes, in practice, will be no longer used
>    (old and new) ?

As I hope I've argued above, no, it does not mean that.  Just as an
aside, I've offered pushing a datalink DM in Waikoloa, and I'm still
offering it, but I'd need some encouragement, as I think for
Datalink's "core" a proper data model is not necessary (albeit
certainly nice to have).

>  * And do we really want to see a such shift of UCD role ? And if yes,
>    do we have evaluate the impact of this new usage ?

I've tried to show above that this is not a shift in UCD role.  UCDs
have been meant to mark up the physics of input parameters as well as
output table columns ever since they were conceived.  They continue
to do that here.

The param.min/max thing is a bit of a wart, I give you that.  We've
talked about the desirability of a compound type DM in the VO in
SIAv2, and with that, no param UCDs would be necessary.  But given
the simplicity, the usefulness, and the fact that similar warts exist
with, e.g., meta.main in current UCDs, I'd say: Let's not wait for
compound type DM (which *is* actual work and *will* take time if we
want it to be useful) with Datalink (which is really urgent).  In
case you're really  worried, well, compound type DM annotation of
VO-DML type can be added backward-compatibly later.

Cheers,

           Markus