[VEP-003]: datalink/core#sibling

[François Bonnarel]

Hi Markus, all


Following your recommendation I opened a new thread for the 
TimeDomain/observationof a source  use case discussion

Please answer there for that discussion

Now below I focus on the sibling thing.



Le 20/12/2019 à 08:34, Markus Demleitner a écrit :
> Dear DAL,
>
> On Thu, Dec 19, 2019 at 12:17:25PM +0100, François Bonnarel wrote:
>>   * When I proposed VEP0001 immediately after Groningen Interop I could
>>     not imagine that such a controversy discussion would occur.
>>       o Before considering the use case we have I would like to go back
>>         to the current usages of DataLink I know.
> Of course we need to work out how we will cover the "Figure out SAMP
> Target" use case in Datalink.
Well not only SAMP, but "client behavior control". sending it to another 
tool via SAMP is only one of the possibilities.
>    However, donning my semantics hat I'd
> be grateful if we could keep this effort separate from evaluating
> #sibling -- the two questions got entangled by accident and are
> really orthogonal to each other: SAMP target finding applies just as
> well to #this, #progenitor, or #derivative.  Also, if we find we do
> want to use semantics for SAMP target finding, the additional terms
> can be introduced independently of #sibling as such.
>
> So... it would be great if people could indicate support for or
> distaste with #sibling (both the concept and the term), as well as
> possible changes or improvements, in this thread, while ideally
> moving the SAMP target finding discussion to a separate thread.
>
> That, in particular, is a friendly gesture towards future readers:
> You see, I would like to link this thread from VEP-003's discussion
> section, and when our future colleagues try to figure out what we
> were thinking when making #sibling, they will be grateful if they
> didn't have to read through a lot of essentially unrelated discussion
> on Datalink proper.
>
> Thanks,
>
>             Markus
>
> ...who wishes you all a peaceful and refreshing holiday season...
I go back to VEP-003

> New Term: sibling
> Action: Addition
> Label: Sibling Data
> Description: Data products derived from the same progenitor as #this.
>    This could be a lightcure for an object catalog derived from repeated
>    observations, the dataset processed using a different pipeline, or the
>    like.
> Used-in:
>    http://dc.g-vo.org/gaia/q2/tsdl/dlmeta?ID=ivo://org.gavo.dc/~?gaia/q2/199286482883072/BP
>    This is GAVO's rendition of the Gaia DR2 epoch photometry, where
>    users retrieve a time series in a specific band; the time series
>    in the other bands are the siblings of that.
>
> Rationale:
>    It is fairly common in complex pipelines that multiple data products
>    result from a single observation.  Often, this is true even in a
>    single pipeline step, and hence the data products are not in a
>    progenitor-derivation relationship.  Still, researchers will want to
>    know about these data products; for instance, while exploring a source
>    in Gaia, a quick way to access epoch photometry or the RP/BP spectra
>    is obviously valuable; such artefacts are not really progenitors of
>    the catalog entry, though.  In such cases, #sibling (or perhaps one of
>    its future child terms) should be used.
>
>    Clients should offer #sibling links in a context of scientific
>    exploitation of the dataset (as opposed to, say, debugging).


If I compare this to the initial VEP-001 "associated-data" proposal and to the use case exposed in the other thread
I wonder if "sibling" is the right word.
I'm not sure we can always identify a common progenitor for what I called the "Main" and what I called the "Target"
(see the other thread for what I mean there) in the use cases VEP-001 was supposed to solve.

That's why instead of "associated_data" or "sibling" I proposed "Observation_Result_of_source".

This of course excludes the use case where both the Main and the Target are datasets.

So does everybody prefer "sibling" ?

Cheers
François

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20191220/a0e4ae4a/attachment-0001.html>