<div dir="ltr">Hi Ole,<div><br></div><div class="gmail_quote"><div dir="ltr">Le lun. 5 nov. 2018 à 16:45, 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">Hi Matieu, all,<br>
<br>
On 05.11.2018 15:16, Mathieu Servillat wrote:<br>
> Hi Markus,<br>
> <br>
> thanks for your comments, as Mireille answered, I would follow most of<br>
> your advices that would clarify the standard.<br>
<br>
it was actually my mail that you answered :-) </blockquote><div><br></div><div>technically, but I wasn't answering to you.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And, we still *restrict* our model by not allowing everything that is in<br>
W3C provenance. And we could, for example, extend it to integrate<br>
prov:Plan in our core model to handle the use cases "give me all<br>
activities according of a certain type" (which is BTW not at all trivial<br>
in any model because of the versioning).<br>
<br>
> As for the wasInformedBy and wasDerivedFrom relations: they are not just<br>
> shortcuts! and they are not presented as such in the document.<br>
> "wasInformedBy" can be seen for example as a signal that triggers<br>
> another activity (or any form of signal, which are extremely common in<br>
> our instruments and in the web in general). "wasDerivedFrom" is a<br>
> general relation that can also express specialization and revisions.<br>
<br>
Even within the author's, it is therefore unclear what the use of<br>
wasDerivedFrom is:<br></blockquote><div><br></div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Moreover, it is not clear by just following used+wasGeneratedBy 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, 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</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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. </blockquote><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Mathieu</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></div>