Fwd: Re: WD-DataLink-1.0

[Laurent Michel]

*** thread transfered ****

-------- Message original --------
Sujet: 	Re: WD-DataLink-1.0
Date : 	Tue, 5 Nov 2013 21:23:20 +0100
De : 	Jose Enrique Ruiz <jer at iaa.es>
Pour : 	Laurent Michel <laurent.michel at astro.unistra.fr>
Copie à : 	Patrick Dowler <patrick.dowler at nrc-cnrc.gc.ca>, François Bonnarel <francois.bonnarel at astro.unistra.fr>



Dear DataLink co-authors

I've been reading the DataLink WD, and I would like to ask you if there is a way to get a description (VOTable metadata) of
which are the different links that one specific DataLink service actually provides (the *links set*)

While it seems there may not be any restriction on what DataLink services may provide as links, I think one specific DataLink
service should in principle provide the same set/pack of let's say "serviceType" links for all datasets where it applies.

e.g. one specific DataLink service could always provide a set of links with progenitors, provenance metadata and related
bibliography, while a different DataLink service could provide cutouts and one specific analysis service (in principle for
different datasets, since I understand DataLink services are somehow coupled to the catalog or archive where they are implemented)

I'm currently missing some mechanism in order to get this info, or I am not understanding the DataLink WD correctly.

This also relates with the allowed values for semantics, the proposed list of values seems to me a bit short or too generic,
couldn't we make this list extensible ? I'm thinking of not restricting the many potential uses of DataLink. For example,
providing in a DataLink service all the already existing related links for a specific ADS paper (authors, journal, SIMBAD
objects, tabular data behind the plots in Vizier, observing proposals, grants, used facilities, surveys, missions, ASCL
reference of used software/code, etc.) Maybe this is outside the scope now, but in my opinion we should not exclude this option
in a future, specially if the VO tackles links with published papers.

Best regards


---
Jose Enrique Ruiz
Instituto Astrofisica Andalucía - CSIC
Glorieta de la Astronomía s/n
18009 Granada, Spain____

Tel: +34 958 230 618 <tel:%2B34%20958%20230%20618>____

http://amiga.iaa.es/p/67-jer.htm





2013/10/29 Laurent Michel <laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>>

     Hello Path,

     Thank for the job.

     There are several questions or suggestions  I would to talk about.
     ==============================__==============================__======

     1.2.4: Standards Services:
     If the client is supposed to know the parameters required by the service, it does not know their range for a given
     observation.  We could say here more clearly  that the client must use its own data discovery capabilities (DM knowledge,
     UCD parsing...) to get them.

     1.2.5: Free or Custom Services
     I think that you could mention here the use-cases we developed in our note published last spring. This not could also be put
     in the paper references.

     2.1.1 REQUEST
     Could you give some example of a REQUEST parameter "value triggering alternate behaviour"
     Is that the way you suggest for custom services to deliver their parameter descriptions?

     2.1.3 ID
     "the service will return at least one... " Why put this particular caveat on the number of links returned by the server. An
     empty list can be returned for dataset without available links (e.g. no available progenitors).

     4 List if Links:
     AccessURL/ErrorMessage on required/one empty. I think that the spec must be a bit more flexible to support services not
     perfectly compliant: If the ErrorMsg is not empty, then the AccessURL is ignored. So, the client knows what to do even when
     both field are set.

     4.4 Service Type
     I would be nice to add a table listing all Service TAP

     And one 2 fundamental issues
     ============================

     Registry: According to your documents, the client has to get a query response before to know whether the datalink is
     supported. That makes senses in most cases. But it would nice to propose a way to mention somewhere in the registry
     capabilities whether a service support Datalink  or not.

     Self described service: There is almost nothing a bout the self described service and especially about how parameters are
     described. They are just mentioned. I do believe, though, that this feature is very important and not only for my own
     services since that is the way to connect the VO to legacy web services.


     Cheers
     Laurent


     Le 25/10/2013 19:40, Patrick Dowler a écrit :


         The first official and more or less complete WD for DataLink is now available in the document repository (in the
         Documents in
         Progress section).

         Direct link is here:

         http://www.ivoa.net/documents/__DataLink/index.html <http://www.ivoa.net/documents/DataLink/index.html>

         There are some possible re-organisation necessary (sec 2 and 4 go together and sec 3 needs to move to either before or 
after
         them). Also, the allowed values in the "semantics" column are still a bit up in the air and the ones presented are not
         final. I
         thought it better to get this out now.

         PS-Thaks to the co-authors and participants at the last couple of interop meetings for their contributions - it all
         helped to
         bring this together into what I hope is a simple and concise document.


     --

     ---- Laurent MICHEL              Tel (33 0) 3 68 85 24 <tel:%2833%200%29%203%2068%2085%2024> 37
           Observatoire de Strasbourg  Fax (33 0) 3 68 85 24 <tel:%2833%200%29%203%2068%2085%2024> 32
           11 Rue de l'Universite      Mail laurent.michel at astro.unistra.__fr <mailto:laurent.michel at astro.unistra.fr>
           67000 Strasbourg (France)   Web http://astro.u-strasbg.fr/~__michel <http://astro.u-strasbg.fr/~michel>
     ---