IVOA Provenance DM -RFC- answers to comments

[Ole Streicher]

Hi Matieu, all,

On 05.11.2018 15:16, Mathieu Servillat wrote:
> Hi Markus,
> 
> thanks for your comments, as Mireille answered, I would follow most of
> your advices that would clarify the standard.

it was actually my mail that you answered :-)

> However, one important point: the IVOA core model is just the W3C core
> model, so this would not stand as an IVOA recommendation, maybe a note
> stating that the IVOA should restrict its provenance to W3C
> provenance...

What is the problem with that? If we can state that our data model is
just the general one, then we did a good job, didn't we?

And, we still *restrict* our model by not allowing everything that is in
W3C provenance. And we could, for example, extend it to integrate
prov:Plan in our core model to handle the use cases "give me all
activities according of a certain type" (which is BTW not at all trivial
in any model because of the versioning).

> As for the wasInformedBy and wasDerivedFrom relations: they are not just
> shortcuts! and they are not presented as such in the document.
> "wasInformedBy" can be seen for example as a signal that triggers
> another activity (or any form of signal, which are extremely common in
> our instruments and in the web in general). "wasDerivedFrom" is a
> general relation that can also express specialization and revisions.

Even within the author's, it is therefore unclear what the use of
wasDerivedFrom is:

* Mireille see them as a shortcut to speedup the search,

* You see this as additional information

When even we do not agree here, what should a potential client software
assume?

> Moreover, it is not clear by just following used+wasGeneratedBy that an
> entity is derived from another (in particular if we include many
> configuration parameters as general entities, hence the proposition to
> separate the handling of configuration parameters). For example, for an
> activity that applies a flatfield to a science image: the output image
> is derived from the input science image, but not from the flatfield
> image.

This example shows IMO that it is not so simple: If you find some
artefacts on the final image, you may want to ask "what was the
progenitor" to get this -- but the artefact may come from either the
flatfield, or the science image. So, to investigate the artefact both
are progenitors. If you really want to have the science progenitor, you
can always ask for the "used" relation with the according role and don't
need that shortcut.

There are use cases where we would need them; but before we introduce
them into our model, we should make *ourself* clear what they are and
when they should be used. And in the meantime, we could probably live
without them.

Best regards

Ole