Datalink vocabulary extension: sibling?

[Markus Demleitner]

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?

> 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".

> 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.

>      In addition i think #derived,#progenitor, #co-generated (#sibling ? )
> and #alternante (#other ?) should share the same "head term"  "#science".

I see what you mean, and I have cases like that, too.  But let's
finish #co-generated or #sibling before tackling the next concept.  At
least while we're still trying out processes, we shouldn't bite off
too much in one go.

Thanks,

          Markus