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