IVOA Provenance DM -RFC- answers to comments

[Markus Demleitner]

Hi Mathieu,

On Wed, Nov 21, 2018 at 05:45:56PM +0100, Mathieu Servillat wrote:
> you are right, technically they are both progenitors. Now, for a more
> precise example, let's define an activity that takes as inputs A, B and C
> and returns as results D and E. The internal calculations are in fact D=A+B
> and E=C+D. In that case D is *not* derived from C... You may say that the
> activity is then not well defined, that D is an intermediate result, but
> this is the real world, and one cannot be forced to do fine grained
> provenance. This was summarized in the PR by "If there is more than one

But is it realistic to expect that a data provider who doesn't care
to take apart these two activities will properly add wasDerivedFrom
relationships?  And even if they do: Is what we gain from this type
of information worth the cost in added complexity?

I guess what I'm saying is: In the interest of our future client
writers, we should try an implementation of the "is A a progenitor of
B?" functionality (which I'd say is undisputed as an important use
case) with and without wasDerivedFrom, also testing it with a
provenance graph with cycles (ideally a way that we can embed it into
SQL/ADQL engines).  

If we have that and find wasDerivedFrom is still worth it, I'm fine
with keeping it in.

         -- Markus