IVOA Provenance DM -RFC- answers to comments

[Mathieu Servillat]

Hi Ole,

Le lun. 5 nov. 2018 à 16:45, Ole Streicher <ole at aip.de> a écrit :

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


technically, but I wasn't answering to you.


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

you seem to forget easily all the discussions we had on the necessity to
include descriptions, configuration and context for our use cases. This
information is simply *relevant* to assess the quality, reliability and
usefulness of entities in several use cases. This should be acknowledged
and respected.


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

seriously... Is this constructive? I wrote that they are not *just*
shortcuts. Why do you want to see this as an opposition? this shortcut is
simply not obvious, and can carry more information than just a shortcut.


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

Sorry, this is not relevant. A client software for what objective? to make
sense of a single wasDerivedFrom relation? The provenance of an entity is
not transported by just the wasDerivedFrom relation. What is extracted is a
graph, which contains different relations to other entities (and activities
and agents). If this graph contains wasDerivedFrom relations, then it
brings additional information to assess the qaulity/relaibality/usefulness
of something: maybe a shortcut to the main progenitor, maybe a derivation
from another entity, which may be further explored... There is a user and
probably a project behind all this.


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

not bad, but not to the point. The derivation brings additional provenance
information, not possible to carry by a used relation (that may even not
exist). You can twist the examples if you want, but the argument is still
here.


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


sure, I remember deep discussions on wasDerivedFrom, accumulating examples
and external references, and we couldn't get rid of it because it brings
information that cannot be carried by the other relations. This is about
the same for the other parts of the model, which was progressively
acknowledged by the group to reach the current PR.

Cheers,
Mathieu


>
> Best regards
>
> Ole
>


-- 
Dr. Mathieu Servillat
Laboratoire Univers et Théories, Bât 18, Bur. 221
Observatoire de Paris-Meudon
5 place Jules Janssen
92195 Meudon, France
Tél. +33 1 45 07 78 62
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20181106/b22aefba/attachment.html>