<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi all , <br>
</p>
<p>After a short discussion on line after the last DM session today,
we tried again to see the drawbacks of each proposed terms. <br>
</p>
<p>My understanding ogf the situation and discussion is that :</p>
<ul>
<li>we agree there is the idea of a graph, and precisely a
provenance graph. <br>
</li>
</ul>
<ul>
<li>we agree #sibling is concise and handy : one single word <br>
</li>
</ul>
<ul>
<li>we agree it is fuzzy enough to encompass items generated at
different generations steps : not only 'brothers' and 'sisters'
, twins , etc.<br>
</li>
</ul>
<ul>
<li>we agree #sibling does not imply in which hierarchical tree
it belongs. <br>
</li>
</ul>
<ul>
<li>Simbad has a <i>sibling</i> property for mentionning
astronomical Objects issued from the same parent object ( Ada 's
use-case) , <br>
so with another hierarchical property between astronomical
objects <br>
<br>
</li>
<li>#co-generated and #co-derived , have been proposed
(François), but they imply 'generated at the same time' , or by
the same step, <br>
which is too tight a constraint.</li>
</ul>
<ul>
<li>@has-common-progenitors proposed by Pat , carries all the
meaning , but is may be too long (?)</li>
</ul>
<ul>
<li>#sibling has been implemented already at ESO ( Alberto) and
at GAVO ( Markus) <br>
</li>
</ul>
<p>In trying to build a consensus, I have a suggestion : <br>
</p>
<p>Why not keeping #sibling for simplicity in the label, and mention
precisely in the vocabulary definition of the term that we mean <br>
"siblings-by-provenance" as exposed by Pat. <br>
</p>
<p>Cheers, Mireille<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Le 07/05/2020 à 11:58, Markus
Demleitner a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20200507095829.ltkbifn2w46juulw@victor">
<pre class="moz-quote-pre" wrap="">Dear Lists,
On Wed, May 06, 2020 at 04:40:45PM -0700, Patrick Dowler wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
That is an interesting point that, I have to say, makes me feel a bit
less enthusiastic about #co-generated.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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)).
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
--
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</pre>
</body>
</html>