[[VEP-005]<-- Re: Datalink vocabulary extension: sibling/co-generated

[alberto micol]

Thanks François. The ESO need was for raw files taken as part of the same observation template; all those (I was calling them “siblings”) are subject to exactly the same set of calibrations. 
Or to say it differently and maybe more clearly: the datalink service activated on a particular raw file returns not only the link to the calibration files that can be used to process the given raw file, but it also links to the other raw (sibling) files that can be calibrated using the same calibration files.

Do I understand correctly that “sibling” is now called “co-generated” ?

I think “co-generated” could work for this case of mine, as indeed those raw files have been generated by the same observation template (not from other data, but from the same observing process). Would that work?

If the above is correct, then I would not use “counterpart”. 

Many thanks,
Alberto

> On 6. May 2020, at 14:42, François Bonnarel <francois.bonnarel at astro.unistra.fr> wrote:
> 
> Hi Mireille, Markus, all
> 
> Le 28/04/2020 à 19:02, Mireille LOUYS a écrit :
>> Sounds ok to me.
>>> 
>>> Now, vocabularies 2 currently says on VEP review:
>>> 
>>>    During the process, all parts of the VEP may be changed except the
>>>    term(s) proposed.
>>> 
>>> and I still think that's largely a good idea.
>>> 
>>> Hence, before I retract VEP-003 and replace it with an essentially
>>> identical VEP-004 with co-generated: Would anyone here object to that
>>> or strongly prefer #sibling?
>> 
>> I agree with "co-generated". The meaning is close to "sibling" ,
>> 
>> has less connotation towards graphs' theory and may be understandable for a larger audience.
> :-)
>> 
>>>> p
>>>> 
>>>>       I propose something like "#other" or "#alternate" ( the latter was
>>>> already proposed by Markus ..... in 2015 !!! semantics session during
>>>> interop In Sydney)
>>> #alternate was really intended when #this has multiple
>>> representations (classic example: a spectrum that you get as
>>> FITS-array, FITS-table, SDM VOTable, or CSV).  I still think this is
>>> a good idea because we ought to make it a SHOULD that there's just
>>> one #this per ID.  But that's for another VEP.
>> 
>> I agree. I understand this term means "same content in a different representation" while we need a term to mention
>> 
>> we link to another dataset interesting to hela /enrich the interpretation of the data stored in #this.
>> 
>> "related_data", "other", "see-also" seem too vague for this , but I cannot make up a better term .:-(
>> 
>> 
>> 
> I was still looking for a word which says it is
> 
>       1 ) not metadata, but data, not calibration data, not auxiliary (but main information)  not documentation, and not a service
> 
>       2 ) is associated to the #this thing but is neither derived, nore progenitor , nore co-generated.
> 
>             We have plenty of use cases like that in VizieR, for XMM, probably for ESO if I remember well an older request from Alberto Micol. And this also can be valid for "TimeSeries" outside the Gaia use case well represented by co-generated (see VEP-004)
> 
>       Eventually I found the "counterpart" term.
> 
>      Online Oxford dictionary definition reads "A person or thing holding a position or performing a function that corresponds to that of another person or thing in another place"
> 
>      Sounds good to me. Is more general than "contains" (corresponds to the source #this but in the "image" world") "followup" (corresponds to  #this but in the future) and "cross-associated," "cross-correlated" ...  but is still covering these terms as an head term if desired.
> 
>      I think with "progenitor", "derived", "co-generated" and "counterpart" we cover a wide field of relationships between #this and a linked dataproduct.
> 
>      As you know from the DataLink discussion the actual dataproduct_type will be given in the mime-type parameter of the "content-type" field of Datalink response
> 
>    So This is the VEP-005
> 
> Vocabulary:http://ivoa.net/rdf/datalink/core
> Author: François Bonnarel
> Date: 2020_05-06
> Supercedes: VEP-001
> 
> New Term: counterpart
> Action: Addition
> Label: counterpart dataproduct
> Description: Data products holding a position that corresponds to #this in another data space.
> Used-in:
>      VizieR or ESO example to be worked on
> 
> Rationale:
>     Astronomers often want to associate to astronomical objects, sources or datasets dataproducts of other provenance but sharing some common features with those.
> 
>     examples of that are measurements in another band, images, cubes, spectra, timeseries of a source, same dataproduct type and location in physical space  but at another time, etc ....
> 
> 
> Cheers
> 
> François
> 
> 
> 
>