Delete Inference of WasDerivedFrom, promote assertion of WasDerivedFrom

Authors

Luc Moreau, June 19, 2009.

Subject

OPM1.01

Background

OPM v1.00 introduced an inference rule that allows us to infer a WasDerivedFrom edge.

Problem addressed

This inference rule was observed to be incorrect, and OPMv1.01 made this clear in rule (3) of Figure 11. ChangeProposalWasDerivedCannotBeInferred provides explanations for this problem.

Proposed solution

Remove the inference rule from the specification. But also, make the case in the introduction that WasDerivedFrom needs to be asserted. It's an important edge that, at the minimum, represents control flow, and at the maximum, represents data derivation. It can only be asserted. This requires adding this edge to the examples at the beginning of the paper.

Rationale for the solution

Inferences need to be sound, allowing us to derive data derivations that exist!

Comments

Community is invited to provide comments on proposals.

Comment 1 by Simon Miles

I agree with this proposal.

Regardless of deleting wasDerivedFrom inference, there is a case (made in discussions here) for allowing inferrable information to be asserted, which would include wasDerivedFrom, wasDerivedFrom* etc.

-- JimMyers - 17 Sep 2009

I would counter propose that OPM processes be restricted to assure that this inference is always valid - a process must causally relate its inputs and output via control or data flow to be valid in OPM. I think this has minimal impact on real use cases - we're trying to capture causality after all. I think it would still be possible to represent the 'incorrect' case in OPM by breaking the process into subprocesses - a pain but only to those in this hopefully minor case.

Comment 3 in reply to Jim above

A problem with restricting OPM processes to make the inference valid, as someone raised in Amsterdam, is that you often just don't know, or want to know, what is happening inside a particular process but you do know what's going in and coming out. By restricting the definition to one for which the inference rule works, you are placing an impossible burden on the asserter to know what is occurring and expanding the amount of documentation (by breaking into subprocesses) with little apparent benefit.

Comment by Paul Groth

I agree that wasDerivedEdges should be asserted. However, I think we could allow an annotation on a process that says: I assert that all outputs are derived from all of this process's inputs. This would allow what many of the participants in PC3 did but make it explicit and thus not break OPM inference rules.

Vote

Luc Moreau, Yes

Jim Myers, No - would like a variant of the alternate proposed above to keep the inference but remove the possibility of incorrectness

Simon Miles, Yes

Paul Groth, Yes - would like to see the introduction of a convenience annotation

NataliaKwasnikowska, yes

PaoloMissier, yes

Jan Van den Bussche, yes

Outcome

The ballot result is: Yes: 6/No: 1.

However there is a suggestion to support a convenience annotation (by which inference could be made for annotated processes). This could be defined as a profile: ChangeProposalWasDerivedFromInferrableProfile.

The resolution is that this change proposal is endorsed by we should work on ChangeProposalWasDerivedFromInferrableProfile.

-- LucMoreau - 19 Jun 2009
to top