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

Luc,

Graham just argued about attributes rather than aggregate parts but
there's clearly overlap (though - if C is 'wooden' because B.1 and B.2
are both 'wooden', would C derive from A in my scenario because it does
inherit properties of A?). 

 

In any case, I don't think that just dropping the attribute language
makes things self-consistent. What's the definition of derivation when
we're requiring that there be a temporal path for 'causality' (B had to
be generated after A was used and we can't infer derivation from
used-PE-generated) but do not require a physical path for 'causality' (C
could be derived from different parts/different attributes of B than the
parts/attributes of B that were derivedFrom A yet we allow
transitivity). I use 'causality' to capture the idea that the attribute
relations tried to capture - somehow there's a substantive connection
between Bobs. If derivation means that, regardless of whether we talk
about attributes, both inference from used/generated and transitivity
don't work. If derivation does not mean that, inference from
used/generated and transitivity work/are equally sloppy- Just like you
want to avoid inferring if the temporal annotations of used/generated
preclude 'causality', transitivity should be avoided if there are Bob
aggregation annotations (or info about attributes) that precludes
causality. If we want to allow transitivity because we're going to not
talk about attributes or parts, we should allow inference from
used/generated if there are no time annotations - both could be wrong.

 

Jim

 

From: public-prov-wg-request@w3.org
[mailto:public-prov-wg-request@w3.org] On Behalf Of Luc Moreau
Sent: Wednesday, August 03, 2011 10:44 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,

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