Datalink vocabulary extension: sibling/co-generated

[Mireille LOUYS]

Hi all ,

After a short discussion on line after the last DM session today, we 
tried again to see the drawbacks of each proposed terms.

My understanding ogf the situation and discussion is that :

  * we agree there is the idea of a graph, and precisely a provenance
    graph.

  * we agree #sibling is concise and handy : one single word

  * we agree it is fuzzy enough to encompass items generated at
    different generations steps : not only 'brothers' and 'sisters' ,
    twins , etc.

  * we agree #sibling  does not imply in which hierarchical tree it
    belongs.

  * Simbad has a /sibling/ property for mentionning astronomical Objects
    issued from the same parent object ( Ada 's use-case) ,
    so with another hierarchical property between astronomical objects

  * #co-generated and #co-derived , have been proposed (François), but
    they imply 'generated at the same time' , or by the same step,
    which is too tight a constraint.

  * @has-common-progenitors  proposed by Pat , carries all the meaning ,
    but is may be too long (?)

  * #sibling has been implemented already at ESO ( Alberto)  and at GAVO
    ( Markus)

In trying to build a consensus, I have a suggestion :

Why not keeping #sibling for simplicity in the label, and mention 
precisely in the vocabulary definition of the term that we mean
"siblings-by-provenance" as exposed by Pat.

Cheers, Mireille


Le 07/05/2020 à 11:58, Markus Demleitner a écrit :
> Dear Lists,
>
> On Wed, May 06, 2020 at 04:40:45PM -0700, Patrick Dowler wrote:
>> 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
> That is an interesting point that, I have to say, makes me feel a bit
> less enthusiastic about #co-generated.
>
>> 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.
> I suspect one could sensibly define #sibling as something like the
> recursive closure of #co-generated (in some twisted way).  Which
> would make it, in set-informed semantics, a wider term
> (extension(#sibling) is a superset of extension(#co-generated)).
>
>> 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.
> The process certainly admits that.
>
> But: before I put in #co-generated into my service and thus make
> François' proposal for VEP-004 valid and publishable: Pat, what
> you're saying is you would not like the proposed description:
>
>    Data products derived from the same progenitor as #this.  This
>    could be a lightcurve for an object catalog derived from repeated
>    observations, the dataset processed using a different pipeline, or
>    the like.
>
> for #co-generated?  And how much would you dislike it? [as in: enough
> to block the VEP?  Because then I'd probably save the time until
> we're closer to consensus or someone else goes ahead with
> #co-generated]
>
>
> Meanwhile, a process point: To avoid later confusion with running
> numbers:
>
> (a) Please try and have the Used-in: field ready (and the VEP
> complete otherwise) before submitting them.
>
> (b) Please do not assign VEP numbers yourself; as long as nobody uses
> #counterpart, for instance, what François has sent around as VEP-005
> it will not enter the VEP repo (assuming we play by the current WD's
> rules).  Now, if another VEP comes in in the meantime, it will become
> VEP-005, and people doing a web search and (hypothetically) ending up
> in the mailing list archive will be confused when they see a
> completely unrelated thing.
>
> So, my request would be to submit to semantics@ without a running
> number, just as "new VEP".
>
> I also suspect it would be cool if there was a non-public way to
> submit the requests, as people may worry about publicly making a fool
> of themselves.  Which brings us back to the question if there should
> be mail aliases for each WG/IG's char/vice-chair combo.  But that's
> for another day.
>
> Thanks for making it to here in these busy times,
>
>           Markus

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20200508/e78fc059/attachment.html>