Fwd: Re: WD-DataLink-1.0

Tue Nov 12 08:36:21 PST 2013

Hi Jose, all
     Not sure this point has been discussed extensively but I give you 
my feeling.

Le 06/11/2013 16:09, Laurent Michel a écrit :
>
> *** 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.
NO, I disagree. there will be services ( ObsTAP or SIA) with 
heterogeneous content. So the links "semantics" and "service type" will 
change across the service. However nothing forbid you to build an 
homogeneous data link service.
>
> 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.
I think if you build an homogeneous DataLink service you could provide a 
test response (links for the first DataSet in your database for example)
>
> 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 ?
This can still be discussed.I just sent a proposal by Mireille Laurent 
and me for extensions.
> 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.
No, I think  DataLinks for datasets referred in papers is a good use 
case I think
Best regards
François
>
> 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>
>     ---