Datalink - a naive question...

[François Bonnarel]

Hi Paul,
Back to this one:
     - When the DataLink resource  is a registered service then the ID 
must be an IVOA ID
     - When the DataLink resource is referred only in,  let's say, the 
SIAV2 query response then the ID can be anything IVOA ID or opaque 
string, or whatever.
The Draft give the two possibilities but we may clarify this point of 
differentiation between the two use cases.

The SIAV2 draft explains allready how you can refer to a DataLink 
resource in the query response (without going to the registry)
Cheers
François

Le 18/03/2014 11:15, Paul Harrison a écrit :
> On 2014-03 -14, at 10:47, François Bonnarel<francois.bonnarel at astro.unistra.fr>  wrote:
>
>> Hi all,
>>      I agree with Laurent.
>>      IN addition for the motivation I would say that having DataLink allows wider usage and more flexibility.
>>      IVO ID's such as Publisher_DID are uniquely defined all other the VO.
>>     -  A Datalink service could provide linked resources for PUblisherDIds defined by another institution.
>>     -  They can be stored outside VO services responses, eg gratia in publications.
>
> So it is a very good idea to have a such service (it might just end up being the VO’s killer app) - but I still maintain that it would be better to separate the DataLink response format definition standard from such a service definition standard - not least because there is some debate about IDs and long term curation - e.g. http://www.ivoa.net/pipermail/dal/2014-January/006617.html and in general the best way of resolving VO URI in their various forms. I still think that it is not necessary to have the service defined to make SIAP2 work if you just define accessURLs as simply opaque URLs with no “meaning” to any of parts of the string that make it up.
>
> Paul.
>
>
>> Best regards
>> François
>> Le 14/03/2014 11:05, Laurent MICHEL a écrit :
>>> Hello,
>>>
>>> Datalink can either be simple resource within a VOTable as you said or it can be a standalone service acceded in any context you could imagine.
>>> In both cases, the client must be able to get the availability/capabilities and others DALI/VOSI features.
>>>
>>> Regards
>>> LM
>>>
>>> Le 14/03/2014 10:47, Paul Harrison a écrit :
>>>> Hi DALWG,
>>>>
>>>> I have a naive question - why is DataLink defined as a service rather than simply a specialised VOTable pattern with an associated mime type?
>>>>
>>>> It seems to me that documentation could be greatly simplified if this approach were taken - no DALI, VOSI etc. in the Datalink document.
>>>>
>>>> Then just modify DALI to say that services that return URLs to data might point directly to a data file or to a DataLink VOTable with the two cases determinable by the client using the mime type.
>>>>
>>>> Overall this seems to reduce the overall complexity of the documentation with no loss of functionality, or am I missing something?
>>>>
>>>> Regards,
>>>>     Paul
>>>>
> Dr. Paul Harrison
> JBCA, Manchester University
> http://www.manchester.ac.uk/jodrellbank