Datalink data access services

[Pierre Fernique]

Dear Dal members,

I would like to bring your attention about a current tendancy in our 
drafts which could have an important impact if we do not take care of 
it. As you know, the "utype" attribut until recently was used for 
tagging some dedicated VOTable fields in order to recognize them without 
ambiguity. And some VO clients and servers use them for the 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 method (associated to a 
formalized model, serialized in VODML, mapped into GROUPs, etc). I do 
not want to enter again in this debate here, 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).

It raises two questions :

  * Does it means that the utypes, in practice, will be no longer used
    (old and new) ?
  * 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 ?


Regards
Pierre

Le 12/12/2013 14:04, Markus Demleitner a écrit :
>    The parameter characteristics consist of parameter name, ucd, and 
> unit.
>    Clients SHOULD only assume the semantics given here if all three
>    characteristics match; while distinguished in the table, neither
>    clients nor servers should distinguish between an empty and missing
>    unit attributes on the PARAM elements.
>
>    paramater name  UCD unit     remarks
>    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)
>    LAT_MIN         param.min;(see remark) deg      (1)
>    LAT_MAX         param.max;(see remark) deg      (1)
>    LON_MIN         param.min;(see remark) deg      (2,3)
>    LON_MAX         param.max;(see remark) deg      (2,3)
>    LAMBDA_MIN      param.min;em.wl m        (4)
>    LAMBDA_MAX      param.min;em.wl m        (4)
>    FORMAT          meta.code.mime (none)   (5)
>    SPECRP          spect.resolution (empty)  (6)
>    FLUXCALIB       phot.calib (none)   (7)
>    PIX(n)_MIN      param.min;pos.pixel.ax(n) pixel    (8)
>    PIX(n)_MAX      param.max;pos.pixel.ax(n) pixel    (8)
>    KIND            meta.code (none)   (9)
Le 12/12/2013 14:04, Markus Demleitner a écrit :
> Finally, here's a list of new UCDs we should try and get into the
> "big list": param.min, param.max, pos.spher.(lon|lat), pos.pixel.ax1..ax7
>
> (I have my doubts about the ax1..ax7, too, but it would be symmetric
> with what's there for other pos.* UCDs).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20131213/10423759/attachment.html>