Datalink vocabulary extension: sibling/co-generated

Mireille LOUYS mireille.louys at unistra.fr
Tue Apr 28 19:02:13 CEST 2020


Hi all,

I come back to this discussion .
My comments are inserted below .

Le 21/04/2020 à 11:28, Markus Demleitner a écrit :
> Dear lists,
>
> [because François asked about it: I suppose as a "good idea" item,
> cc:ing semantics in vocabulary discussions is probably a good thing
> to do in general; that way, for people just interested in terminology
> work it'd be enough to subscribe that].
>
> On Mon, Apr 20, 2020 at 12:51:15PM +0200, François Bonnarel wrote:
>> I agree that #see-also covers nearly everything we can imagine in the
>> contexte of Datalink as was my initial proposal of "#associated_data" in
>> VEP001.
>>
>> I think it's true that something like what Markus defined as sharing the
>> same "progenitor with #this" and that he called #sibling is needed.
>>
>> But )
>>
>>    -   Due to the   "non intuitive" terminology, I suggest a synonymous :
>> #co-generated.  This is directly inspired by Provenance dataModel, a new
>> IVOA recommendation dated  April the 11th this year. If you share a
> 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.

>> progenitor with somebody else, this means you have been *generated *by the
>> same *activity* with this guy and that this activity *used *the
> I don't think I agree with "the same activitiy" here -- why would you
> demand that, in particular because activities can be all kinds of
> granularities; for instance, "gaia data reduction" could be a
> monolithic acitivity that would make
>
>    <timeseries> #co-generated <gaia-source row>
>
> true, whereas if you have separate activities for the astrometric
> solution and the photometry gathering they wouldn't.
>
> Plus, I don't really see a case where a user or client would care
> about that distinction.
>
> So, I'd say let's just talk about identical progenitors; the use case
> would be "give me other data this project has found out based on what
> I'm looking at".

I agree we have to consider the description of generation steps may vary .

"has same progenitor" is fair enough.

>
>> some term for linking something to #thing which is scientific data (that is
>> not a process, not a preview, not a calibration file, no auxiliary data and
>> not additional medata) and which is neither progenitor nor derived and nor
>> sibling/co-generated.
>>
>>        To illustrate this look at the VizieR example below.  this is a
>> catalog of Spitzer galaxies with link to their optical counterpart image:
>> "Optical imaging for the Spitzer Survey of Stellar Structure in Galaxies.
>> Data release and notes on interacting galaxies.".
>>
>> As explained in the abstract
>> (https://cdsarc.unistra.fr/viz-bin/cat/J/A%2bA/569/A91) a link is provided
>> to opticals images of various origins for all galaxies extracted from
>> Spitzer IR information. This kind of relation between the Spitzer galaxy and
>> its optical counterpart image is not covered by sibling/co-generated,
>> derived, or progenitor.
>>
>>       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 help/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 .:-(


all the best . Stay safe and healthy,

Mireille

-- 
--
Mireille Louys,  MCF (Associate Professor)
CDS				IPSEO, Images, Laboratoire Icube
Observatoire de Strasbourg	Telecom Physique Strasbourg
11 rue de l'Université		300, Bd Sebastien Brandt CS 10413
F- 67000-STRASBOURG		F-67412 ILLKIRCH Cedex
Tel: +33 3 68 85 24 34



More information about the apps mailing list