<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If I think of these terms just as normal english words, I have two kids that are siblings (same parents) and with computers we'd use those terms with trees and graphs without confusing anyone. When I think of co-generated, that is a much tighter relationship: if it was kids, they would be twins, not just siblings :-)... with data it seems to mean "generated by the same instance of processing from the same input" (same instance also implying/saying "at the same time". So I'm pretty sure co-generated is a narrow term just because it seems quite specific/restrictive. Is it a narrower than sibling? I think sibling is just the "from the same input" because I think we are talking about siblings-by-provenance.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I don't really see that either sibling or co-generated capture the relationship from Alberto/ESO use case: those other files that would be calibrated by the same set of calibrators are related, but not in this way... that seems more like "you can do the same thing to these ..." eg I don't know what word to use :-)</div><div class="gmail_default" style="font-size:small"> <br></div><div class="gmail_default" style="font-size:small">My gut feeling is that vocabularies are easier to grow if one defines general broad terms and adds narrower terms later., when differentiation is needed.. the other way around (define a term and later on realise it is a narrower term for a new or existing broad term) is a kind of refactoring. That could be harmless in practice or it could imply a subtle change in meaning. Still, refactoring is also a normal kind of evolution so it isn't wrong to define a narrow term and add a broad parent later.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">my 2c,</div><div class="gmail_default" style="font-size:small"><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<span class="gmail_default" style="font-size:small"></span><br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 6 May 2020 at 08:52, François Bonnarel <<a href="mailto:francois.bonnarel@astro.unistra.fr">francois.bonnarel@astro.unistra.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Le 06/05/2020 à 17:37, alberto micol a écrit :<br>
> 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.<br>
> 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.<br>
><br>
> Do I understand correctly that “sibling” is now called “co-generated” ?<br>
Yes, It's my proposal because a couple of people didn't like "sibling" <br>
at all. I thought to something inspired by provenance like <br>
"co-generated" will fit better with the definition. I didn't know you <br>
were using "sibling" actually.<br>
><br>
> 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?<br>
Yes.<br>
><br>
> If the above is correct, then I would not use “counterpart”.<br>
<br>
Humm. My mistake. I had the wrong remembering that your use case was <br>
something like "counterpart" and not "co-generated".<br>
<br>
Cheers<br>
<br>
François<br>
<br>
><br>
> Many thanks,<br>
> Alberto<br>
><br>
>> On 6. May 2020, at 14:42, François Bonnarel <<a href="mailto:francois.bonnarel@astro.unistra.fr" target="_blank">francois.bonnarel@astro.unistra.fr</a>> wrote:<br>
>><br>
>> Hi Mireille, Markus, all<br>
>><br>
>> Le 28/04/2020 à 19:02, Mireille LOUYS a écrit :<br>
>>> Sounds ok to me.<br>
>>>> Now, vocabularies 2 currently says on VEP review:<br>
>>>><br>
>>>> During the process, all parts of the VEP may be changed except the<br>
>>>> term(s) proposed.<br>
>>>><br>
>>>> and I still think that's largely a good idea.<br>
>>>><br>
>>>> Hence, before I retract VEP-003 and replace it with an essentially<br>
>>>> identical VEP-004 with co-generated: Would anyone here object to that<br>
>>>> or strongly prefer #sibling?<br>
>>> I agree with "co-generated". The meaning is close to "sibling" ,<br>
>>><br>
>>> has less connotation towards graphs' theory and may be understandable for a larger audience.<br>
>> :-)<br>
>>>>> p<br>
>>>>><br>
>>>>> I propose something like "#other" or "#alternate" ( the latter was<br>
>>>>> already proposed by Markus ..... in 2015 !!! semantics session during<br>
>>>>> interop In Sydney)<br>
>>>> #alternate was really intended when #this has multiple<br>
>>>> representations (classic example: a spectrum that you get as<br>
>>>> FITS-array, FITS-table, SDM VOTable, or CSV). I still think this is<br>
>>>> a good idea because we ought to make it a SHOULD that there's just<br>
>>>> one #this per ID. But that's for another VEP.<br>
>>> I agree. I understand this term means "same content in a different representation" while we need a term to mention<br>
>>><br>
>>> we link to another dataset interesting to hela /enrich the interpretation of the data stored in #this.<br>
>>><br>
>>> "related_data", "other", "see-also" seem too vague for this , but I cannot make up a better term .:-(<br>
>>><br>
>>><br>
>>><br>
>> I was still looking for a word which says it is<br>
>><br>
>> 1 ) not metadata, but data, not calibration data, not auxiliary (but main information) not documentation, and not a service<br>
>><br>
>> 2 ) is associated to the #this thing but is neither derived, nore progenitor , nore co-generated.<br>
>><br>
>> 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)<br>
>><br>
>> Eventually I found the "counterpart" term.<br>
>><br>
>> 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"<br>
>><br>
>> 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.<br>
>><br>
>> I think with "progenitor", "derived", "co-generated" and "counterpart" we cover a wide field of relationships between #this and a linked dataproduct.<br>
>><br>
>> 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<br>
>><br>
>> So This is the VEP-005<br>
>><br>
>> Vocabulary:<a href="http://ivoa.net/rdf/datalink/core" rel="noreferrer" target="_blank">http://ivoa.net/rdf/datalink/core</a><br>
>> Author: François Bonnarel<br>
>> Date: 2020_05-06<br>
>> Supercedes: VEP-001<br>
>><br>
>> New Term: counterpart<br>
>> Action: Addition<br>
>> Label: counterpart dataproduct<br>
>> Description: Data products holding a position that corresponds to #this in another data space.<br>
>> Used-in:<br>
>> VizieR or ESO example to be worked on<br>
>><br>
>> Rationale:<br>
>> Astronomers often want to associate to astronomical objects, sources or datasets dataproducts of other provenance but sharing some common features with those.<br>
>><br>
>> 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 ....<br>
>><br>
>><br>
>> Cheers<br>
>><br>
>> François<br>
>><br>
>><br>
>><br>
>><br>
</blockquote></div>