RE: PROV-ISSUE-67 (single-execution): Why is there a difference in what is represented by one vs multiple executions? [Conceptual Model]

I see parts as different from attributes, but - as in my email that
crossed with yours responding to Luc, the 'loss of precision' you get
from ignoring attributes/parts seems to be the same as you'd get from
allowing inference of derivation from used-PE-generated by 'ignoring'
time stamps. Doing both or neither makes sense to me (different but
self-consistent definitions of derivation), allowing one and not the
other seems inconsistent. 

 

Jim

 

From: public-prov-wg-request@w3.org
[mailto:public-prov-wg-request@w3.org] On Behalf Of Paolo Missier
Sent: Wednesday, August 03, 2011 11:03 AM
To: public-prov-wg@w3.org
Subject: Re: PROV-ISSUE-67 (single-execution): Why is there a difference
in what is represented by one vs multiple executions? [Conceptual Model]

 

yes, partial derivation, i.e., at the attribute level, gets in the way
of transitivity. Ignoring the attributes may be a way out. You lose
precision but save transitivity. 
So you could have:

B includes B.1, B.2
B.1 derived from A     => B derived from A   (1)
C   derived from  B.2  => C derived from B   (2)
=> C derived from A    (3) 

where inferences (1) and (2) are new, they "lift" derivation from
attribute to whole entity, and (3) is transitivity.

"graphically":

               B
             /   \
C --> B.1   B.2 --> A   becomes C --> B --> A   

Graham's example is more involved but similar:

     C                  B                 A
    /  \              /   \           /     \
 c0    c1 --> b1   b0 --> a0    a1      becomes  C --> B --> A

what do you think?

-Paolo


On 8/3/11 3:43 PM, Luc Moreau wrote: 

Jim,

This counter example was already raised by Graham in PROV-ISSUE-56.

My view on this is that for inference, we should ignore the attributes.

So, definitions should be tuned to accommodate this.

I don't think generation can be inferred from use/generated.

Luc

On 08/03/2011 03:35 PM, Myers, Jim wrote: 

Paolo, Luc,

 

Both clearly have to work the same way if we don't know about PE
internals. 

 

However, I still have some concern about the idea that B is partially
determined by A and transitivity don't mix. But it doesn't address
aggregate Bobs. If B has two parts, B.1, and B.2 and B.1 is derived from
A, so that B is derivedFrom A, we could also have C derived from B.2
(therefore C derivedfrom B) and transitivity would break -  C is not
derivedfrom A. (I see this as ~analogous to the issue of derivation
being inferable from used/generated: The doc does note that if B was
generated before A was used, derivation cannot be true, so you can't
infer derivation from used-PE-generated structures. This is because PEs
can have temporal parts- they could be an aggregate process. There are
analogous issues because Bobs can have spatial parts/be aggregate
objects. This means you can't infer across generated-Bob-used structures
either and transitivity allows this.)

 

I think that boils down to there only being two self-consistent
definitions for derivation - 

It is inferable from used/generated and is transitive

It implies partial determination, is only assertable, and is not
transitive

 

I think we can pick either or both, but right now it still looks like we
mix the idea that there's some real partial determination with
transitivity in ways that can break.

 

  Jim 

From: public-prov-wg-request@w3.org
[mailto:public-prov-wg-request@w3.org] On Behalf Of Paolo Missier
Sent: Wednesday, August 03, 2011 8:36 AM
To: public-prov-wg@w3.org
Subject: Re: PROV-ISSUE-67 (single-execution): Why is there a difference
in what is represented by one vs multiple executions? [Conceptual Model]

 

JIm

we have established that isDerivedFromInMultipleSteps is also
transitive. I hope this is fine.

The point of having the relation is that, as Luc explained here below,
in this case the "pe introduction rule"(*) should not be used.  
In other words, isDerivedFromInMultipleSteps simply means that,
according to the asserter, more than one pe is required to explain the
derivation (but we don't know how many).

I can see that your objection is valid, however, in the sense that I can
make up one single pe that encompasses an arbitrary number of steps. 
The problem is that we haven't said anything about the nature of the
activity represented by a pe. Unless we say something about their
granularity and composition, any pe can represent any aggregation of
"elementary" activities. 

-Paolo

(*) if isDerivedFrom(e1,e0) holds, then there exists a process execution
pe, and roles r0,r1, such that: isGeneratedBy(e1,pe,r1) and
uses(pe,e0,r0).


8/2/11 3:08 AM, Myers, Jim wrote: 

 

	It's not that pe is atomic or not. It's that there is a tight
link between

the derivation and  the process execution.
 

	isDerivedFromInMultipleSteps is silent about that link.

 
If B isDerivedInMultipleSteps from A, can't I (a second witness) always
make up a single process that encompasses all steps? Would it then be OK
(for me, the second witness making up this account) to claim a direct B
isDerivedFrom A. Then I can do transitive closure over such
relationships? And then recognize that there were multiple steps, thus
making isDerivedInMultipleSteps transitive too?
 

	I am not trying to infer derivation beyond transitive closures.

 
I don't see how the definitions given allow one to be transitive and one
not to be. If the only difference between the two was an implication of
how much the witness knew about what happened (one step or multiple),
but both were transitive, I wouldn't be confused (I might still argue
that we don't need the distinction).
 
Cheers,
 Jim
 
 
Regards,
Luc

 





-- 
Professor Luc Moreau               
Electronics and Computer Science   tel:   +44 23 8059 4487         
University of Southampton          fax:   +44 23 8059 2865         
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk  
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm
<http://www.ecs.soton.ac.uk/%7Elavm> 






-- 
-----------  ~oo~  --------------
Paolo Missier - Paolo.Missier@newcastle.ac.uk, pmissier@acm.org 
School of Computing Science, Newcastle University,  UK
http://www.cs.ncl.ac.uk/people/Paolo.Missier