<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Markus and all,<div><br></div><div><div>first, an information to all: the RFC Review Period has now ended, after several meetings during the College Park interop with the DM chairs, the document will now evolve for another round to include the comments, based a more generic model.</div><div><br></div><div>As for your points, I will certainly keep in mind that additional features imply additional implementation work, so that those new features must come from use cases with good reasons. We indeed discussed often where the line should be between lean and not too lean, however, a "simpler" model is sometimes just hiding the complexity behind, with not enough guidance. The risk is that implementations are then not coordinated enough and interoperability is quickly lost. </div><div><br></div><div>Derivation: my first example was the usage of configuration parameters, which are not progenitors but can be seen as input entities. I tried a more simple example with the flatfied, but I now see that we have no definition of what a progenitor is. I assumed that the "science progenitor" was the obvious one, while the "calibration progenitor" was secondary (this difference can be highlighted by a wasDerivedFrom relation by the way). But 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 input and more than one output to an activity, it is not clear which entity was derived from which." This affirmation is maybe hiding the detailed examples, and could be reformulated, the thing is that "used+generated" is not equivalent to "derived".</div></div><div><br></div><div>When discussing this at the ProvenanceWeek (more general provenance meeting, not just astronomy), it was explained to me that the main information we generally extract from provenance records is the data flow (i.e. not the activity flow). Data (or entities) are connected between them with the wasDerivedFrom relation, which makes it the most basic structure to carry provenance information. </div><div><br></div><div>We also have to make clear that the "core model", being in fact the W3C core model, it is an *informative part* of the document. The "extended model" is the normative part, and brings meaning to the entities, hence some guidance. I don't see the extended model as being too expensive for clients as the normative names will be carried by a "type" attribute for entities, activities and relations, and connected to a restricted vocabulary. </div><div><br></div><div>Thanks for your inputs, we will now discuss all the RFC answers and review the document,</div><div><br></div><div>Best regards,</div><div>Mathieu</div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">Le mar. 20 nov. 2018 à 15:22, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear DM,<br>
<br>
Coming back from vacation, let me join the fray; I have a few more<br>
replies to Mireille's original answer that I'll post later as<br>
replies there. To keep the discussion reasonably focused, I'll<br>
keep this on the question of the "shortcuts" (wasDerivedFrom and<br>
wasInformedBy).<br>
<br>
<soapbox><br>
A general topic of all these things, however, is WAWSFC: We are<br>
writing standards for clients, i.e., for software that interprets our<br>
annotations and let the users work with them. Each feature we add<br>
makes their job harder. If their job is harder, they may not do it,<br>
and our standard remains unimplemented. And if it's a hard job, even<br>
if they decide to do it, it's much more likely they'll get it wrong,<br>
and then people will see tracebacks instead of interoperability.<br>
<br>
*That's* why I'm haggling here to keep things lean. And yes, we<br>
shouldn't be *too* lean. When figuring out what the line is, use<br>
cases and their derived requirements are about the only thing that<br>
helps us, and that's why I keep insisting on being able to trace<br>
features to use cases.<br>
</soapbox><br>
<br>
<br>
On Tue, Nov 06, 2018 at 02:11:43PM +0100, Mathieu Servillat wrote:<br>
> <a href="https://www.w3.org/TR/prov-dm/#term-Derivation" rel="noreferrer" target="_blank">https://www.w3.org/TR/prov-dm/#term-Derivation</a>). A generic client should<br>
> answer the question: does this entity has a wasDerivedFrom relation ?<br>
<br>
Hm -- what exactly is the use case for this question? In the<br>
debugging use case, isn't the question rather "Is Entity A in the<br>
progenitors of Entity B?" Is that what you mean here?<br>
<br>
If so, then I'd say a client has an easier time without wasDerived<br>
from. You see, all it has to do then is search the provenance graph<br>
for this structure recursively:<br>
<br>
Entity_A ---- wasGeneratedBy ---> Activity_X ---- used ---> Entity_B (a)<br>
<br>
Not overly pretty, yes, but at least it's just one thing, and you<br>
have Activity you can use to reliably detect cycles (entities aren't<br>
nearly as good for that because they might legitimately be used<br>
multiple time in the provenance of even a single thing).<br>
<br>
Now, with wasDerivedFrom, a client *additionally* has to go through<br>
all structures of the type<br>
<br>
Entity_A ---- wasDerivedFrom -----> Entity_B (b)<br>
<br>
Yes, that, in itself, is simpler, but just because it's there doesn't<br>
mean you'd not have to check for pattern (a), too. So, you now need<br>
to consider all kinds of mixtures of paths, do cycle detection even<br>
for mixes of patterns (a) and (b), and so on. I'd say roughly<br>
quadrupled complexity on the client side.<br>
<br>
<br>
This is an argument to make the point: "wasDerivedFrom comes as a<br>
cost".<br>
<br>
Granted, if that cost actually is *too* high to make wasDerivedFrom<br>
worthwhile for the VO DM I can't say -- as provenance goes, I don't<br>
have experience worth mentioning. But I'm asking everyone involved<br>
to make sure they've carefully worked out that questions for<br>
themselves.<br>
<br>
<br>
> Here is the paragraph on derivation in the PR: "Note that the<br>
> \class{WasDerivedFrom} relation cannot always automatically be<br>
> inferred from following existing \class{WasGeneratedBy} and<br>
> \class{Used} relations alone. If there is more than one input and<br>
> more than one output to an activity, it is not clear which entity<br>
> was derived from which. Only by specifying the descriptions and<br>
> roles accordingly, or by adding a \class{WasDerivedFrom} relation,<br>
> this direct derivation becomes known."<br>
<br>
Hmyes, but in my original response I wondered:<br>
<br>
If you have an activity with multiple inputs and outputs, it stands<br>
to reason that all inputs influence all outputs, so there's nothing<br>
for wasDerivedFrom to annotate. If there's distinct, unrelated<br>
groups of inputs and outputs then you really have two activities and<br>
you should describe them as such rather than hack around the<br>
deficient description.<br>
<br>
-- and I still don't see that point sufficiently addressed. Put less<br>
abstractedly following Ole's example: How would I *not* want to know<br>
about a flatfield used in the production of an optical image?<br>
<br>
> Here is a preliminary diagram of what can be the calibration data flow for<br>
> CTA:<br>
> <a href="https://banshee.obspm.fr/index.php/s/BRuf26L1sdX085u" rel="noreferrer" target="_blank">https://banshee.obspm.fr/index.php/s/BRuf26L1sdX085u</a><br>
> Please let me have derivations, at least between data levels (e.g. DL0 to<br>
> DL1, so I don't have to dig in all the complex relations to find the main<br>
> progenitors. Also, I don't want the parameters, the descriptions, the<br>
> context or other side entities of my activities to be exposed automatically<br>
> as progenitors. Used+wasGeneratedBy does not mean wasDerivedFrom all the<br>
> time. The precise derivations can be explained textually in the<br>
> descriptions, but the derivation relation helps to find automatically<br>
> relevant provenance information in the mass of provenance data.<br>
<br>
So, yes, provenance graphs, modelled to sufficient detail, will end<br>
up being rather complex. But that is exactly why I so yearn for<br>
keeping the model itself as simple as we possibly can: Throwing more<br>
complexity at a problem to make it more manageable has rarely worked<br>
(I'm not saying it never worked, though).<br>
<br>
Isn't your point here rather an argument for a hierarchical<br>
representation, where you'd have "top-level" entities and "top-level"<br>
activiites in a "top-level" provenance graph, wher you could then<br>
"drill down" into finer-grained provenance, HiPS-style?<br>
<br>
If so, I'd suggest that's not really a modelling issue. As long as<br>
there is a defined way in which clients can do the "drilling down"<br>
(essentially links "go here for a finer-grained provenance" and "go<br>
here for coarser-grained provenance"), the model can remain as it is.<br>
<br>
An alternative might be a "saliency" annotation to entities and/or<br>
activities. So, are we actually the first to struggle with<br>
provenance graphs of that complexity? If not, do we know what others<br>
have done to cope? And were they happy with what they went for?<br>
<br>
> Here is the page of the working group with discussions, probably not<br>
> everything is contained in the minutes of the discussion, but this gives a<br>
> good idea of the topics discussed, e.g. on derivation sometimes. Sorry if<br>
> the draft does not contain all those discussions, for obvious reasons, but<br>
> the paragraph in the PR does not come from nothing.<br>
> <a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/ObservationProvenanceDataModel" rel="noreferrer" target="_blank">http://wiki.ivoa.net/twiki/bin/view/IVOA/ObservationProvenanceDataModel</a><br>
<br>
Ouch. That's a bit much to comb through for me as a half-casual<br>
reviewer that just wants to humbly annotate time series points with<br>
their originating images. If there's anything I should be aware of<br>
in particular, could you perhaps provide a more direct link?<br>
<br>
And while I'm dwelling on this point, let me put in a brief piece of<br>
Mireille's original reply:<br>
<br>
On Sun, 4 Nov 2018 20:26:09 +0100, Mireille wrote:<br>
Mireille > In the Triplestore implementation for instance it really<br>
Mireille > speeds up the search. In the relational DB it avoids table joins.<br>
<br>
I don't dispute these -- in a concrete implementation, it might be<br>
advantageous to abstract away the actual activities. But that<br>
doesn't mean the interoperable model has to be burdened by that<br>
optimisation. If this turns out to be a good idea, you could even<br>
require a (progenitor, successor) table in a relational mapping of<br>
the model without having to have that in the model itself.<br>
<br>
<br>
> I would also like to discuss a more important topic: what is relevant<br>
> provenance information? The W3C structure allows anyone to store a huge<br>
> mass of provenance *data*, however, only part of it is relevant provenance<br>
> *information*. The proposed extended model for the astronomy domain aims at<br>
> guiding projects to store the information that is relevant in astronomy.<br>
> But it is not sufficient, a project should then select precisely the<br>
> relevant provenance information for their application, i.e. maybe not<br>
> everything should be recorded, just the minimum relevant information.<br>
<br>
That, I think, captures about my sentiment as to why we should keep<br>
the first version of this model really small -- at least until we<br>
feel we understand sufficienly well what people need and what clients<br>
(want to) do with our annotations.<br>
<br>
It's easy to add things to standards, but very hard to take things<br>
away once the standard is passed.<br>
<br>
With apologies for another long mail,<br>
<br>
Markus<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>