<<O>>  Difference Topic ChangeProposalDeleteWasDerivedInference (r1.10 - 25 Sep 2009 - LucMoreau)

META TOPICPARENT WorkInProgressV1pt1

Delete Inference of WasDerivedFrom, promote assertion of WasDerivedFrom

Line: 77 to 77

Jan Van den Bussche, yes

Added:
>
>



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
 <<O>>  Difference Topic ChangeProposalDeleteWasDerivedInference (r1.9 - 23 Sep 2009 - JanVanDenBussche)

META TOPICPARENT WorkInProgressV1pt1

Delete Inference of WasDerivedFrom, promote assertion of WasDerivedFrom

Line: 75 to 75

PaoloMissier, yes

Added:
>
>
Jan Van den Bussche, yes

-- LucMoreau - 19 Jun 2009
 <<O>>  Difference Topic ChangeProposalDeleteWasDerivedInference (r1.8 - 23 Sep 2009 - PaoloMissier)

META TOPICPARENT WorkInProgressV1pt1

Delete Inference of WasDerivedFrom, promote assertion of WasDerivedFrom

Line: 73 to 73

NataliaKwasnikowska, yes

Added:
>
>
PaoloMissier, yes

-- LucMoreau - 19 Jun 2009
 <<O>>  Difference Topic ChangeProposalDeleteWasDerivedInference (r1.7 - 23 Sep 2009 - NataliaKwasnikowska)

META TOPICPARENT WorkInProgressV1pt1

Delete Inference of WasDerivedFrom, promote assertion of WasDerivedFrom

Line: 71 to 71

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

Added:
>
>
NataliaKwasnikowska, yes

-- LucMoreau - 19 Jun 2009
 <<O>>  Difference Topic ChangeProposalDeleteWasDerivedInference (r1.6 - 22 Sep 2009 - PaulGroth)

META TOPICPARENT WorkInProgressV1pt1

Delete Inference of WasDerivedFrom, promote assertion of WasDerivedFrom

Line: 52 to 52

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.

Added:
>
>

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.




Line: 63 to 69

Simon Miles, Yes

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

-- LucMoreau - 19 Jun 2009
 <<O>>  Difference Topic ChangeProposalDeleteWasDerivedInference (r1.5 - 21 Sep 2009 - SimonMiles)

META TOPICPARENT WorkInProgressV1pt1

Delete Inference of WasDerivedFrom, promote assertion of WasDerivedFrom

Line: 48 to 48

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.

Added:
>
>

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.




Line: 57 to 61

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

Added:
>
>
Simon Miles, Yes

-- LucMoreau - 19 Jun 2009

 <<O>>  Difference Topic ChangeProposalDeleteWasDerivedInference (r1.4 - 17 Sep 2009 - JimMyers)

META TOPICPARENT WorkInProgressV1pt1

Delete Inference of WasDerivedFrom, promote assertion of WasDerivedFrom

Line: 44 to 44

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.

Added:
>
>
-- JimMyers - 17 Sep 2009

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



Line: 53 to 55

Luc Moreau, Yes

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

-- LucMoreau - 19 Jun 2009

 <<O>>  Difference Topic ChangeProposalDeleteWasDerivedInference (r1.3 - 16 Sep 2009 - LucMoreau)

META TOPICPARENT WorkInProgressV1pt1

Delete Inference of WasDerivedFrom, promote assertion of WasDerivedFrom

Line: 51 to 51

Vote

Added:
>
>
Luc Moreau, Yes

Deleted:
<
<
-- LucMoreau - 15 Jun 2009

-- LucMoreau - 19 Jun 2009

 <<O>>  Difference Topic ChangeProposalDeleteWasDerivedInference (r1.2 - 30 Jul 2009 - SimonMiles)

META TOPICPARENT WorkInProgressV1pt1

Delete Inference of WasDerivedFrom, promote assertion of WasDerivedFrom

Line: 38 to 38

Community is invited to provide comments on proposals.

Changed:
<
<

comment 1

>
>

Comment 1 by Simon Miles


Changed:
<
<
include authors
>
>
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.


 <<O>>  Difference Topic ChangeProposalDeleteWasDerivedInference (r1.1 - 19 Jun 2009 - LucMoreau)
Line: 1 to 1
Added:
>
>
META TOPICPARENT WorkInProgressV1pt1

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

include authors



Vote

-- LucMoreau - 15 Jun 2009

-- LucMoreau - 19 Jun 2009

Revision r1.1 - 19 Jun 2009 - 09:04 - LucMoreau
Revision r1.10 - 25 Sep 2009 - 13:52 - LucMoreau