WD-DataLink-1.0

Fri Nov 15 03:50:08 PST 2013

Hi all,
      As Laurent explained, I think trying to go much further the small 
mandatory list will rapidly become a nightmare. The list we proposed 
illustrated the kind of thing people would like to distinguish.  But it 
is not exhaustive as we could see from the first reactions. So  I think
the addition of "content=content_string" after the starting word taken 
in the Standard predefined short list is a good compromise.
I met Laurent today at coffee break. What he proposes is really to have 
this "content_string" totally  free, domain dependant in other words, 
just forbidding a few ambiguous words.
I fully agree with that (another possibility would be to put this 
statement in the "description" column)

By the way, for the short predefined list I propose to distinguish plot 
from preview. To me plot is a graphical representation of something like 
a function, necessary for spectra, light curves etc... Nothing specially 
preview in this. So we will have the plot predefined word oin addition.

Cheers
François

Le 14/11/2013 16:18, Laurent Michel a écrit :
> Hello,
>
> We must keep in mind that Datalink is a protocol enable to operate any 
> remote service whether using VO protocols or not.
> For this reason, I believe that the project of achieving a  dictionary 
> of links serving all astrophysical fields is destined to fail. There 
> will always be some peculiar cases carrying concepts which are not in 
> that dictionary. Indeed, the ability of a client to do appropriate 
> processing strongly depends on this vocabulary.
> To sort out this contradiction we are supporting the idea of using 
> some hierarchical construction for this vocabulary where a path 
> element refines its predecessor. With this concept, the first element 
> (mandatory) would have to match the list set in 4.6.
>
> PROPOSAL
> ========
> Our first idea was to use the same construction as for UCDs, but 
> another alternative, avoiding any confusion with UCDs, could be to use 
> the grammar of the Mime type parameters (A nice example is given in 3.1)
>
> Example: The calibration bias would be expressed as 
> "calibration;content=bias" where "content=bias" remains optional.
> The basic concept "calibration" would be enough for most of the 
> clients (another similitude with Mime types)
>
> Using this mechanism would allow to go ahead with the V1 of the 
> protocol. The possible values of the content field would remain open 
> or just restricted by list of reserved words.
>
> Bye
> LM
>
>
>
>
> Le 14/11/2013 11:51, Louys Mireille a écrit :
>> Hi Arnold , Hi all ,
>>
>> The goal here is not to classify things again in a general data model 
>> and force a categorisation of data products, but on the
>> contrary ,
>> to record some terms that will be meaningful. Applications could 
>> follow the links between datasets and touch the attached data /
>> metadata useful for their context/ usage.
>>
>> if the radio community uses "Beam" instead of PSF, the usual "beam" 
>> term would be meaningful and understandable for the context of
>> radio oriented applications.
>> the idea was to relax the constraints we had in the data modeling and 
>> offer more flexibility.
>>
>> Best wishes,
>> Mireille
>>
>>
>> Le 12/11/2013 20:30, Arnold Rots a écrit :
>>> I think this list needs some serious consideration,
>>> particularly to make sure that the terms have
>>> general application and that coverage is complete.
>>>
>>> For instance, a radio beam image is no different
>>> from a PSF. And what is the relation between an
>>> error map and a noise map? How does that relate
>>> to a sensitivity map. What about an exposure map?
>>> And I thought it peculiar that the first item under
>>> ancillary contains miscellaneous calibration data;
>>> why isn't that under calibration? Also, the set of
>>> calibration data types seems rather limited.
>>>
>>> Let's not rush this list.
>>>
>>> Cheers,
>>>
>>>   - Arnold
>>>
>>> ------------------------------------------------------------------------------------------------------------- 
>>>
>>> Arnold H. Rots Chandra X-ray Science Center
>>> Smithsonian Astrophysical Observatory tel:  +1 617 496 7701
>>> 60 Garden Street, MS 67 fax:  +1 617 495 7356
>>> Cambridge, MA 02138 arots at cfa.harvard.edu 
>>> <mailto:arots at cfa.harvard.edu>
>>> USA http://hea-www.harvard.edu/~arots/ 
>>> <http://hea-www.harvard.edu/%7Earots/>
>>> -------------------------------------------------------------------------------------------------------------- 
>>>
>>>
>>>
>>>
>>> On Tue, Nov 12, 2013 at 11:25 AM, François Bonnarel 
>>> <francois.bonnarel at astro.unistra.fr
>>> <mailto:francois.bonnarel at astro.unistra.fr>> wrote:
>>>
>>>     Hi all,
>>>         The attached file  gives a proposal for extended values for 
>>> the semantics column described in 4.6.
>>>         We were considering the fact that the original list could be 
>>> too short for our various use cases.
>>>         Semantics column is supposed to give the role  of the linked 
>>> resource with respect to the original dataset
>>>     Best regards
>>>     Mireille Louys, Laurent Michel, François Bonnarel
>>>
>>
>> -- 
>> Mireille Louys    , Maître de conférences
>> Centre de Données astrophysiques de      Icube & Télécom Physique 
>> Strasbourg                Pôle API
>> Observatoire de Strasbourg         300, boulevard Sébastien Brant
>> 11, Rue de l'Université            CS 10413
>> 67000 Strasbourg             F - 67412 ILLKIRCH Cedex
>> http://astro.unistra.fr            http://www.telecom-physique.fr
>> tel : 03 68 85 24 34
>>
>