<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>I have to recenter the discussion, it becomes unnecessarily complex and confusing. A derivation is a derivation, no need to extract more meaning out of it (for the W3C definition, see here: <a href="https://www.w3.org/TR/prov-dm/#term-Derivation">https://www.w3.org/TR/prov-dm/#term-Derivation</a>). A generic client should answer the question: does this entity has a wasDerivedFrom relation ? yes/no, which ones if they exist. The sense of it comes from the people or project that recorded this relation. A dedicated client for a project may make more sense out of a given derivation, not a generic client.</div><div><br></div><div>Here is the paragraph on derivation in the PR:</div><div><div>"Note that the \class{WasDerivedFrom} relation cannot always automatically be</div><div>inferred from following existing \class{WasGeneratedBy} and \class{Used} relations alone.</div><div>If there is more than one input and more than one output to an activity, it is</div><div>not clear which entity was derived from which. Only by specifying</div><div>the descriptions and roles accordingly, or by adding a \class{WasDerivedFrom}</div><div>relation, this direct derivation becomes known."</div></div><div><br></div><div>Here is a preliminary diagram of what can be the calibration data flow for CTA:</div><div><a href="https://banshee.obspm.fr/index.php/s/BRuf26L1sdX085u">https://banshee.obspm.fr/index.php/s/BRuf26L1sdX085u</a><br></div><div>Please let me have derivations, at least between data levels (e.g. DL0 to DL1, so I don't have to dig in all the complex relations to find the main progenitors. Also, I don't want the parameters, the descriptions, the context or other side entities of my activities to be exposed automatically as progenitors. Used+wasGeneratedBy does not mean wasDerivedFrom all the time. The precise derivations can be explained textually in the descriptions, but the derivation relation helps to find automatically relevant provenance information in the mass of provenance data.</div><div><br></div><div><br></div><div>Here is the page of the working group with discussions, probably not everything is contained in the minutes of the discussion, but this gives a good idea of the topics discussed, e.g. on derivation sometimes. Sorry if the draft does not contain all those discussions, for obvious reasons, but the paragraph in the PR does not come from nothing.</div><div><a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/ObservationProvenanceDataModel">http://wiki.ivoa.net/twiki/bin/view/IVOA/ObservationProvenanceDataModel</a></div><div><br></div><div><br></div><div>I would also like to discuss a more important topic: what is relevant provenance information? The W3C structure allows anyone to store a huge mass of provenance *data*, however, only part of it is relevant provenance *information*. The proposed extended model for the astronomy domain aims at guiding projects to store the information that is relevant in astronomy. But it is not sufficient, a project should then select precisely the relevant provenance information for their application, i.e. maybe not everything should be recorded, just the minimum relevant information.</div><div><br></div><div><br></div><div>Cheers,</div><div>Mathieu</div><div><br></div><div><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">Le mar. 6 nov. 2018 à 10:53, Ole Streicher <<a href="mailto:ole@aip.de">ole@aip.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06.11.2018 01:13, Mathieu Servillat wrote:<br>
> Le lun. 5 nov. 2018 à 16:45, Ole Streicher <<a href="mailto:ole@aip.de" target="_blank">ole@aip.de</a><br>
> > However, one important point: the IVOA core model is just the W3C core<br>
> > model, so this would not stand as an IVOA recommendation, maybe a note<br>
> > stating that the IVOA should restrict its provenance to W3C<br>
> > provenance...<br>
> <br>
> What is the problem with that? If we can state that our data model is<br>
> just the general one, then we did a good job, didn't we?<br>
> <br>
> you seem to forget easily all the discussions we had on the necessity to<br>
> include descriptions, configuration and context for our use cases. This<br>
> information is simply *relevant* to assess the quality, reliability and<br>
> usefulness of entities in several use cases. This should be acknowledged<br>
> and respected. <br>
<br>
I don't; however a number of the discussions is not settled yet: There<br>
are quite many points in my RFC comments that remain unanswered since<br>
two weeks, for example about how to handle Context and Configuration<br>
(they are basically roles, but not inherent properties of an Entity).<br>
<br>
You can't ignore these points and then just argue that I "forgot" the<br>
discussion.<br>
<br>
> Even within the author's, it is therefore unclear what the use of<br>
> wasDerivedFrom is:<br>
> <br>
> seriously... Is this constructive? I wrote that they are not *just*<br>
> shortcuts. Why do you want to see this as an opposition? this shortcut<br>
> is simply not obvious, and can carry more information than just a shortcut.<br>
> <br>
> * Mireille see them as a shortcut to speedup the search,<br>
> <br>
> * You see this as additional information<br>
> <br>
> When even we do not agree here, what should a potential client software<br>
> assume?<br>
> <br>
> Sorry, this is not relevant. A client software for what objective?<br>
<br>
A generic client. The idea of Provenance as an IVOA standard is that<br>
anyone can take the standard and by just using it write a client (or a<br>
query) for any compliant server. So, if we have alternative ways to<br>
express the same thing, a generic client/query needs to handle all<br>
cases, since it does not know what is actually used. You can't rely on a<br>
"wasDerivedFrom" shortcut, since it may be implemented by CDS, but not<br>
in MuseWISE.<br>
<br>
> to make sense of a single wasDerivedFrom relation? The provenance of an<br>
> entity is not transported by just the wasDerivedFrom relation. What is<br>
> extracted is a graph, which contains different relations to other<br>
> entities (and activities and agents). If this graph contains<br>
> wasDerivedFrom relations, then it brings additional information to<br>
> assess the qaulity/relaibality/usefulness of something: maybe a shortcut<br>
> to the main progenitor, maybe a derivation from another entity, which<br>
> may be further explored... There is a user and probably a project behind<br>
> all this.<br>
<br>
There currently seem to be at least three different purposes of<br>
"wasDerivedFrom":<br>
<br>
1) /just/ as a shortcut in an existing entity-activity-entity graph,<br>
2) when the activity is unknown,<br>
3) providing additional information beyond the role in the "used" relation<br>
<br>
The first point is just an (questionable) implementation optimization,<br>
as Mireille pointed out.<br>
<br>
The second may be replaced by an ad-hoc Activity and used/wasGeneratedBy<br>
relations, as suggested by Markus D.<br>
<br>
For the third, you didn't bring an example yet; and it may be that it is<br>
not so important to have it *in the first version* of the standard.<br>
<br>
> > Moreover, it is not clear by just following used+wasGeneratedBy<br>
> that an<br>
> > entity is derived from another (in particular if we include many<br>
> > configuration parameters as general entities, hence the proposition to<br>
> > separate the handling of configuration parameters). For example,<br>
> for an<br>
> > activity that applies a flatfield to a science image: the output image<br>
> > is derived from the input science image, but not from the flatfield<br>
> > image.<br>
> <br>
> This example shows IMO that it is not so simple: If you find some<br>
> <br>
> artefacts on the final image, you may want to ask "what was the<br>
> progenitor" to get this -- but the artefact may come from either the<br>
> flatfield, or the science image. So, to investigate the artefact both<br>
> are progenitors. If you really want to have the science progenitor, you<br>
> can always ask for the "used" relation with the according role and don't<br>
> need that shortcut.<br>
> <br>
> not bad, but not to the point. The derivation brings additional<br>
> provenance information, not possible to carry by a used relation (that<br>
> may even not exist). You can twist the examples if you want, but the<br>
> argument is still here.<br>
<br>
It was *your* example, not mine. It is something that is already carried<br>
by the role of the "used" relation, and not a use case that requires<br>
wasDerivedFrom.<br>
<br>
> There are use cases where we would need them; but before we introduce<br>
> them into our model, we should make *ourself* clear what they are and<br>
> when they should be used. And in the meantime, we could probably live<br>
> without them. <br>
> <br>
> sure, I remember deep discussions on wasDerivedFrom, accumulating<br>
> examples and external references, and we couldn't get rid of it because<br>
> it brings information that cannot be carried by the other relations.<br>
<br>
It would be great if you could point to these examples. The suggestion<br>
was brought up from Markus, and he should get a comprehensive answer;<br>
not just a "it didn't work for us".<br>
<br>
And the point here is: we could start with a simple model, collect<br>
experiences how far we (and others) *really* come, and then add the<br>
required extensions.<br>
<br>
For example, what is currently distributed as provenance (in the FITS<br>
files, f.e. from ESO) is usually just input files and values, recipe<br>
name and version of the last processing step. Obviously this already<br>
helps the majority of people to understand how the file was generated.<br>
If we would implement *just that*, we would already serve a huge part of<br>
our community, and this would be *simple*.<br>
<br>
And then we can think of which of our use cases are *really* relevant<br>
for the standard. For example, Mireilles "re-organize some computing<br>
steps" is an internal requirement of CDS and could be supported by their<br>
internal structures. Why should this be a relevant use case for an IVOA<br>
provenance standard?<br>
<br>
Having a simple standard first (like our core model, or even just<br>
activities, entities, used, wasgeneratedby) would be easy to adopt on<br>
both server and client side. We therefore could have soonish<br>
implementations not only from the working group, both server and client<br>
side. It also would help people to get used to the terminology -- just<br>
the four words "Entity", "Activity", "used" and "wasGeneratedBy" help to<br>
understand already most of the provenance, and they are unambiguously<br>
used in such a simple model.<br>
<br>
That would be a typical "80/20 solution": it solves 80 percent of the<br>
use cases, but with only 20 % of the efforts/complexity.<br>
<br>
> This is about the same for the other parts of the model, which was<br>
> progressively acknowledged by the group to reach the current PR.<br>
<br>
Many parts of the PR were *not* acknowledged "by the group". You<br>
continue to try keeping us as not being part of the group. To make that<br>
clear: Both Anastasia and me are part of the provenance working group,<br>
and our arguments should be respected as well (and not ignored, as you<br>
did in the last two weeks). You can't speak "for the group" when<br>
announcing or discussing the PR.<br>
<br>
Best regards<br>
<br>
Ole<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Dr. Mathieu Servillat<div>Laboratoire Univers et Théories, Bât 18, Bur. 221</div><div>Observatoire de Paris-Meudon<br><div>5 place Jules Janssen</div><div>92195 Meudon, France</div><div style="font-family:arial,sans-serif;font-size:12.8px;letter-spacing:0.2px">Tél. +33 1 45 07 78 62<br></div><div>--<br></div></div></div></div></div></div></div></div>