- From: Myers, Jim <MYERSJ4@rpi.edu>
- Date: Fri, 5 Aug 2011 11:45:25 -0400
- To: Simon Miles <simon.miles@kcl.ac.uk>, Provenance Working Group WG <public-prov-wg@w3.org>
Simon, Finding a neutral term for 'cannot infer derivation across' that could be an annotation on a Bob or a PE would be fine ... just a neutral assertion without further explanation. Having to make a relationship 'isNotDerivedFrom' between any/every two Bobs would be similar - would also work - but may be more work - I guess it depends on which use case is more common - are there a lot of processes where all/many of the input/output pairs are not connected? I guess I'd prefer the 'cannotinferderivationacross' option as a way to make a neutral statement - partly as a guess about what the common case is and because 'isNotDerivedFrom' opens another door - there's no derivation for entirely separate things either (rhino notderivedfrom ship) and having both positive and negative assertions gets messy. Jim > -----Original Message----- > From: public-prov-wg-request@w3.org [mailto:public-prov-wg- > request@w3.org] On Behalf Of Simon Miles > Sent: Friday, August 05, 2011 10:49 AM > To: Provenance Working Group WG > Subject: [Spam:***** SpamScore] Re: PROV-ISSUE-67 (single-execution): Why > is there a difference in what is represented by one vs multiple executions? > [Conceptual Model] > > Hi Jim, > > I like your proposal, and agree the definition of isDerivedFrom seems to > capture the essential meaning of derivation independent of accounts. > > It would be great if it is possible for the first draft of the model to make sense > without any implicit idea of accounts, so that we could leave discussion of what > they mean until later. > > >From a perspective of keeping the proposal simple, I wonder if we lose > much by, rather than labelling PEs or entities/bobs as 'composite', just having a > 'isNotDerivedFrom' assertion. If you want to express the reason why B is not > derived from A, you just give a finer granularity graph. > > Thanks, > Simon > > On 5 August 2011 15:30, Myers, Jim <MYERSJ4@rpi.edu> wrote: > > An account -dependent definition of derivation would be much less > > useful. Let me try to restate what I've been saying as a proposal that > > I think will capture our collective sense of derivation and that will > > lead to some clear consequences for the model. > > > > > > > > Derivation means that, independent of the granularity of the > > description of provenance there exists (assuming the description is > > complete) a chain of used-PE-generated relationships between the two > > entities. That is B isDerivedFromA if there is a direct, directed, > > linear path between them (no breaks, no temporal zig-zags). > > > > A <---PE.1 <---X <---PE.2<---Y<---PE.3<----B - derivation > > > > A<--------PE.1 > > / > > X > > / > > PE.2<---B - no derivation, though in some account A<---PE<---B > > (with used occurring after generation) > > > > A<---PE1<-----X.1 > > \ > > PE2 > > \ > > X.2<--PE3<---B - derivation > > > > A <----PE1 <--- X.1 > > > > X.2<---PE2<----B - no derivation, though in > > some account A<---PE1<---X<---PE2<---B (with no processes internal to > > X such that one part influences the other) > > > > > > The idea of this is consistent with our discussions - if A was used > > after B was generated, there is no such path between them and an > > account with finer granularity of the PE could show it to be multiple > > subprocesses with A used by one that occurs after the one that > > generates B (there's no path, or the path has one or more links in the > > opposite temporal direction. The part/attribute cases also fit - going > > to finer granularity would show there's no such path. > > > > The consequences of this definition are that, without additional > > information (which we may want to add in the model - see below), > > derivation cannot be derived from a used-PE-generated structure in a > > given account, and derivation is not transitive. > > > > Since we have groups and use cases where either or both of these would > > be useful, we can ask what else is needed to allow them: > > > > To allow derivation to be inferable, we need to know the connectivity > > inside a PE. For a PE with m inputs and n outputs, this is an n x m > > matrix if we want full detail, but it may be sufficient for most cases > > to simply label the PE as fully connected or not. I would be inclined > > to make the default 'fully connected' and to allow a PE to be tagged > > as 'less-than-fully-connected'/'composite'/'decomposable' to stop > > inferencing about derivation. I think this default would be a good > > 80-90% solution while also allowing users/asserters to rigorously > > indicate when inference is not appropriate. Asserters would always be > > able to directly assert derivation and/or decompose partially > > connected PEs to allow the inferences that are valid while still > > indicating which ones are not. > > > > A similar mechanism would apply for Bobs and allow transitivity for > > derivation - A Bob that is fully connected - it is either one thing, > > or the parts of the thing interact (there are internal processes in B > > that if expanded would show that there is a path from C to A) - is > > sufficient to support transitivity. Again, I would argue that the > > default might be 'fully-connected' since that is likely to be the most > > popular case, and one could label a Bob as 'composite'/'not well > > mixed'/'not fully integrated'/'decomposable' to stop transitivity. > > > > The benefits of this proposal are that I think it really captures the > > essence of what we all think of as derivation in a rigorous way that > > is not asserter/account dependent. It also focuses directly on the > > provenance graph versus trying to relate attributes of Bobs or the > > nature (as described in a recipe) of a PE. > > > > Choosing the defaults to be fully connected would open the door for > > incorrect assumptions given an open world - if you're missing the > > 'composite' label on a PE or Bob, you may infer derivation where there > > isn't any - these defaults would return the largest potential set of > > derivations given current knowledge. I suspect that this is actually > > the right way to 'err' - I'd rather have false positives than to flip > > the situation and be unable to find everything that something truly > > was derived from. If one inferred a derivation that looked odd, one > > would simply walk the chain of Bobs and PEs to see if there's evidence > > that one or more of them might not be fully connected (i.e. one could > > look in other accounts) along with checking to see if one or more of > > the provenance statements is simply wrong (A was not an input!). > > > > I think one can define a useful equivalent for the distinction between > > isDerivedFrom and isDerivedFromMultipleSteps as we're talking about > > them today. I would suggest an account-dependent > > isDirectlyDerivedFrom(x,y, account z) relationship that would be > > limited to one hop in a specified account. This would really just be a > > convenience for scoping a query then and it would have a clear relationship > to isDerivedFrom. > > isDirectlyDerivedFrom could be asserted and/or inferred from a single > > used-PE-generated structure (same definition as above). isDerivedFrom > > is always inferable from isDirectlyDerivedFrom). (Both the assertion > > and inference of isDirectlyDerivedFrom are account dependent, but the > > dependency is just about the "Direct" part - it would always be true > > in any account that if you have an isDirectlyDerivedFrom relationship > > in one account, there is an isDerivedFrom relationship between the > > same entities that is account-independent). A consequence is that > > isDerivedFrom would just be the superset of isDirectlyDerivedFrom and > > the additional relationships one gets from transitivity. If the > > asserters view of granularity fits yours, isDirectlyDerivedFrom would > > give you a useful subset of the overall derivation graph. If not, you > > just look directly at isDerivedFrom. > > > > > > Cheers, > > Jim > > > >> -----Original Message----- > >> From: public-prov-wg-request@w3.org [mailto:public-prov-wg- > >> request@w3.org] On Behalf Of Luc Moreau > >> Sent: Friday, August 05, 2011 2:52 AM > >> To: public-prov-wg@w3.org > >> Subject: [Spam:****** SpamScore] Re: PROV-ISSUE-67 (single-execution): > > Why > >> is there a difference in what is represented by one vs multiple > > executions? > >> [Conceptual Model] > >> > >> Hi Simon, > >> > >> Your proposal is broadly inline with what I am currently drafting. > >> > >> Thanks for the name suggestion, which I will shamelessly borrow ;-) > >> > >> It is unclear to me at this stage, whether the first definition of > > derivation is > >> dependent on account or not, but I made an explicit note about it in > > the draft > >> document. This will have to be discussed again in the next iteration. > >> > >> Luc > >> > >> > >> On 04/08/11 18:12, Simon Miles wrote: > >> > Hi Luc, > >> > > >> > OK. I believe that the current definitions do not fully capture > >> > what I've understood from your mails, so if I was clarifying the > >> > document based on my current understanding, I would start by > >> > refining the definitions (and rearranging the existing text to fit): > >> > > >> > "That characterized thing B _is derived from_ another characterized > >> > thing A means that B is transformed from, created from, or affected > > by > >> > A. In particular, this means that the values of some attributes of > >> > B are at least partially determined by the values of some > >> > attributes > > of > >> > A. > >> > > >> > xxx (B, A) represents that B is derived from A, and if P is the > >> > process execution generating B by the account in which the > > derivation > >> > is asserted, then P is the execution which used A and derived B > >> > from it. > >> > > >> > yyy (B, A) represents that B is derived from A, by any means > >> > whether direct or convoluted, and regardless of any other assertion made. > >> > > >> > For the account in which yyy (A, B) is asserted to be consistent > > then, > >> > within that account, it is implied that either xxx (A, B) also > >> > holds or there are multiple process executions ultimately using B > >> > and generating A through a chain of use and generation relations." > >> > > >> > xxx is currently called isDerivedFrom and yyy is called > >> > isDerivedFromInMultipleSteps. > >> > > >> > I fear that xxx is impossible to understand properly without > > including > >> > accounts, and consistency within accounts, in the model. Once we > >> > introduce accounts, it then makes sense. > >> > > >> > Assuming we don't want to introduce accounts into the current > >> > draft, > > I > >> > propose something like the following: > >> > > >> > - isDerivedFromInMultipleSteps (yyy) is renamed > > isEventuallyDerivedFrom > >> > - isEventuallyDerivedFrom is defined as for yyy above, removing > > the > >> > paragraph below mentioning accounts until accounts are introduced > >> > - isDerivedFrom (xxx) is excluded from the model until accounts > > are > >> introduced > >> > - isDerivedFrom+ is also excluded until accounts are introduced, > > as > >> > it depends on isDerivedFrom > >> > > >> > I don't like the proposal as it removes isDerivedFrom, but I can't > > see > >> > how we can define isDerivedFrom in a way which reflects your > > intention > >> > without introducing accounts. Otherwise, the implication that will > > be > >> > drawn (and has been by several people in discussing this issue) is > >> > that there is some implied notion of "atomic process executions". > >> > > >> > Thanks, > >> > Simon > >> > > >> > On 3 August 2011 22:56, Luc Moreau<L.Moreau@ecs.soton.ac.uk> wrote: > >> > > >> >> Hi Simon, > >> >> > >> >> It's good to see that we understand each other's definition of > > derivation. > >> >> > >> >> Given what you say about your notion of derivation, isn't it > > similar > >> >> to isDerivedFromInMultipleSteps? > >> >> > >> >> I wonder whether we should find a better terminology for these > > relations. > >> >> > >> >> Luc > >> >> > >> >> On 03/08/11 16:59, Simon Miles wrote: > >> >> > >> >>> Hi Luc, > >> >>> > >> >>> Sorry, just catching up with these mails. Your explanation helps > >> >>> a lot. In particular, I think the critical point which clarifies > >> >>> my confusion is the following: > >> >>> > >> >>> > >> >>> > >> >>>> Asserting that > >> >>>> isDerivedFrom(report2, data2) would be very different. It > >> >>>> would mean that the process execution that generated report2 > >> >>>> also used data2. > >> >>>> > >> >>>> > >> >>> I have always understood isDerivedFrom (A, B) as saying that "A > > was > >> >>> derived from B, regardless of any other assertion I make", which > >> >>> could be expressed as "there is a conceivably assertable process > >> >>> execution which used B and generated A". > >> >>> > >> >>> You are instead saying isDerivedFrom (A, B) means "A was derived > >> >>> from B, and if I assert A as being generated by a process > > execution, > >> >>> that was the execution which used B and led to A being derived > > from it". > >> >>> > >> >>> I agree these are semantically different. You are taking > >> >>> "use+generate" as fundamental, where "derived" implies a process > >> >>> which uses B and generates A takes place, so consistency within > >> >>> an account requires that the process which generates A is the > >> >>> same > > that > >> >>> is implied by derivation. > >> >>> > >> >>> I interpreted "derived" as fundamental itself and an independent > >> >>> assertion, so consistency in an account is given by this > >> >>> independence, i.e. by saying "derived" you are not implying a > >> >>> process in the same account anyway. And the independence of the > >> >>> assertion means that it does not even make sense to consider it > >> >>> in conjunction with the "generates" assertion (if it exists). > >> >>> > >> >>> thanks, > >> >>> Simon > >> >>> > >> >>> On 1 August 2011 23:59, Luc Moreau<L.Moreau@ecs.soton.ac.uk> > > wrote: > >> >>> > >> >>> > >> >>>> Hi Simon, > >> >>>> > >> >>>> That's a good example, thanks! > >> >>>> > >> >>>> Let me try and explain, how I see it: > >> >>>> > >> >>>> With > >> >>>> > >> >>>> isDerivedFrom (report1, data1) > >> >>>> > >> >>>> the asserter has a deep knowledge of the process execution that > >> >>>> underpins this derivation. In particular, it is PE workflow1 > >> >>>> that generates report1, and uses data1. Hence, both the > >> >>>> generation > > event > >> >>>> for report1 and the use event for data1 occur during workflow1. > >> >>>> > >> >>>> In the provenance challenge, when you were using slicing > > techniques > >> >>>> to extract derivations from process definitions, I would argue > > you > >> >>>> were generating similar derivations. > >> >>>> > >> >>>> With > >> >>>> > >> >>>> isDerivedFromInMultipleSteps (report2, data2) > >> >>>> > >> >>>> the asserter is much less precise, and does not state whether a > >> >>>> single process is involved for generation/use, and which > >> >>>> interval they occur in. > >> >>>> > >> >>>> Furthermore, in this example, with the provenance given, one > >> >>>> cannot ascertain whether 'unpublished2' is in the derivation > >> >>>> path between report2 and data2. > >> >>>> > >> >>>> A stronger provenance would have been > >> >>>> > >> >>>> isDerivedFrom (report2, unpublished2) > >> >>>> > >> >>>> isDerivedFrom(unpublished2, data2) > >> >>>> > >> >>>> > >> >>>> from which we can infer by transitive closure > >> >>>> > >> >>>> isDerivedFrom+ (report2, data2) > >> >>>> > >> >>>> > >> >>>> So, to me, > >> >>>> 1. isDerivedFrom is fundamental in the model, and requires > > deep/precise > >> >>>> knowledge of process executions. > >> >>>> 2. isDerivedFrom+ is useful inference (transitive closure). > >> >>>> 3. isDerivedFromInMultipleSteps is convenience assertion, but > >> >>>> not > >> >>>> as precise as 1&2. > >> >>>> > >> >>>> We could drop 3, but then, you wouldn't be able to express your > >> >>>> second example. > >> >>>> > >> >>>> Asserting that > >> >>>> isDerivedFrom(report2, data2) would be very different. It > >> >>>> would mean that the process execution that generated > >> >>>> report2 also used data2. > >> >>>> > >> >>>> So, > >> >>>> > >> >>>> used (workflow1.2, data2, r) for some role r. > >> >>>> > >> >>>> But that's not the intent. > >> >>>> > >> >>>> What do you think? > >> >>>> Regards, > >> >>>> Luc > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> On 01/08/11 16:53, Simon Miles wrote: > >> >>>> > >> >>>> > >> >>>>> Hi Luc, > >> >>>>> > >> >>>>> OK. Here's my stab at an motivating example. > >> >>>>> > >> >>>>> An organisation, Org, wants to use the WG standard to record > >> >>>>> and provide access to provenance data on the documents it makes > >> >>>>> available online to its clients. It has storage limits on the > >> >>>>> provenance it can maintain. > >> >>>>> > >> >>>>> Alice regularly receives government data sets and for each, > >> >>>>> creates a report which is published online. Looking for a > > minimal > >> >>>>> way to express this using PIL, Org decides on one BOB for each > >> >>>>> data set, one for each report, one process representing the > >> >>>>> create-and-publish workflow, and a derivation link to show that > >> >>>>> the report is based on the data set. A given instance of this, > > for one data > >> set, is: > >> >>>>> > >> >>>>> bob (data1, [ type: "File", location: "/shared/crime1.data" > > ]) > >> >>>>> bob (report1, [ type: "File", location: > >> >>>>> "http://example.com/report1.pdf", creator: "Alice" ]) > >> >>>>> processExecution (workflow1, create-and-publish, t) > >> >>>>> isGeneratedBy (report1, workflow1, out) > >> >>>>> used (workflow1, data1, in) > >> >>>>> isDerivedFrom (report1, data1) > >> >>>>> > >> >>>>> A client, Clive, finds a mistake in report1, looks at the > >> >>>>> provenance and, being "creator", Alice gets the blame. However, > >> >>>>> the error is actually due to Bob, who published Alice's report, > >> >>>>> messing up the axes on a graph. To avoid Alice's anger, Org > > agrees > >> >>>>> to refine what is modelled to a finer granularity: create, then > >> >>>>> publish. As they have storage constraints, they will make > >> >>>>> available only one granularity of provenance information, and > > use > >> >>>>> this finer granularity only for subsequent reports. A given > > instance would > >> be: > >> >>>>> > >> >>>>> bob (data2, [ type: "File", location: "/shared/crime2.data" > > ]) > >> >>>>> bob (unpublished2, [ type: "File", location: > >> >>>>> "/shared/report2.pdf", > >> >>>>> creator: "Alice" ]) > >> >>>>> bob (report2, [ type: "File", location: > >> >>>>> "http://example.com/report2.pdf", creator: "Alice", publisher: > > "Bob" > >> >>>>> ]) > >> >>>>> processExecution (workflow1.1, create, t) > >> >>>>> processExecution (workflow1.2, publish, t+4) > >> >>>>> isGeneratedBy (unpublished2, workflow1.1, out) > >> >>>>> isGeneratedBy (report2, workflow1.2, out) > >> >>>>> used (workflow1.1, data2, in) > >> >>>>> used (workflow1.2, unpublished2, in) > >> >>>>> isDerivedFromInMultipleSteps (report2, data2) > >> >>>>> > >> >>>>> Clive queries to find out what data sets the reports available > > are > >> >>>>> derived from. He finds that while report1 is derived from data1 > > in > >> >>>>> one step (isDerivedFrom), report2 is derived from data2 in > >> >>>>> multiple steps (isDerivedFromInMultipleSteps). He (like me) > >> >>>>> does not understand how he should interpret the distinction > >> >>>>> between > > the > >> >>>>> two. There is apparently something different in the way that > >> >>>>> report2 is related to > >> >>>>> data2 compared to how report1 is derived from data1, and > > possibly > >> >>>>> he should trust report2 less because of this indirect link to > > its > >> >>>>> source data. But Org is adamant that nothing has changed in > > their > >> >>>>> procedures, and there is no distinction. > >> >>>>> > >> >>>>> Thanks, > >> >>>>> Simon > >> >>>>> > >> >>>>> On 1 August 2011 12:15, Luc Moreau<L.Moreau@ecs.soton.ac.uk> > >> wrote: > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>>> Hi Simon, > >> >>>>>> > >> >>>>>> Sorry, but I don't understand. Your initial example was not > >> >>>>>> valid because you had two PEs generating a single BOB. > >> >>>>>> > >> >>>>>> If they are different ways of describing something happening > >> >>>>>> in the world, I assume that you will identify different > > activities, > >> >>>>>> and hence multiple process executions will be asserted. > >> >>>>>> > >> >>>>>> Can you reformulate an example that illustrate your concern? > >> >>>>>> > >> >>>>>> Luc > >> >>>>>> > >> >>>>>> On 08/01/2011 12:02 PM, Simon Miles wrote: > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>>> Hi Luc, > >> >>>>>>> > >> >>>>>>> I follow your argument, but it seems tangential to my point. > > The > >> >>>>>>> following argument still seems inevitably true to me: > >> >>>>>>> > >> >>>>>>> Activity in the world that uses one BOB and generates another > >> >>>>>>> *can* be described in PIL as multiple process executions or a > >> >>>>>>> single process execution (regardless of whether it actually > >> >>>>>>> is described in these different ways or not, or whether > >> >>>>>>> accounts > > are > >> required or not). > >> >>>>>>> > >> >>>>>>> Therefore, what one process execution denotes is not distinct > >> >>>>>>> from what multiple process executions denotes, we have just > >> >>>>>>> provided more detail in the latter description (and this > > detail > >> >>>>>>> is, in any case, removed when saying "is derived from"). > >> >>>>>>> > >> >>>>>>> Therefore, isDerivedFrom and isDerivedFromInMultipleSteps as > >> >>>>>>> defined do not describe anything different in the world, so > >> >>>>>>> we have two terms for representing the same thing. > >> >>>>>>> > >> >>>>>>> I know that we've debated this or similar before, but it is > >> >>>>>>> still not clear to me where the fault lies in my argument, or > >> >>>>>>> what isDerivedFromInMultipleSteps really represents. If it's > >> >>>>>>> only me that's confused, I understand there are more urgent > >> >>>>>>> concerns (though I'd still like to understand). > >> >>>>>>> > >> >>>>>>> Thanks, > >> >>>>>>> Simon > >> >>>>>>> > >> >>>>>>> On 1 August 2011 09:25, Luc Moreau<L.Moreau@ecs.soton.ac.uk> > >> wrote: > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>>> Hi Simon, > >> >>>>>>>> > >> >>>>>>>> If I understand you correctly, you are suggesting that the > >> >>>>>>>> following two assertions hold together. > >> >>>>>>>> > >> >>>>>>>> isGeneratedBy(e5,pe5,out) > >> >>>>>>>> isGeneratedBy(e5,pe4,out) > >> >>>>>>>> > >> >>>>>>>> But this is not legal, since it is stated that one BOB is > >> >>>>>>>> generated by at most one process execution. > >> >>>>>>>> > >> >>>>>>>> What you are suggesting should be encoded in a separate > > account > >> >>>>>>>> (though we have not defined this yet!). > >> >>>>>>>> A one-step derivation then expands to one process execution > > in > >> >>>>>>>> a given account. > >> >>>>>>>> In a separate account, there may be a multi-step derivation > >> >>>>>>>> between the same two BOBs and it would expand into multiple > >> >>>>>>>> process executions. > >> >>>>>>>> > >> >>>>>>>> Does it make sense? > >> >>>>>>>> Regards, > >> >>>>>>>> > >> >>>>>>>> Luc > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> On 07/29/2011 05:52 PM, Provenance Working Group Issue > > Tracker > >> wrote: > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>>> PROV-ISSUE-67 (single-execution): Why is there a difference > > in > >> >>>>>>>>> what is represented by one vs multiple executions? > > [Conceptual > >> >>>>>>>>> Model] > >> >>>>>>>>> > >> >>>>>>>>> http://www.w3.org/2011/prov/track/issues/67 > >> >>>>>>>>> > >> >>>>>>>>> Raised by: Simon Miles > >> >>>>>>>>> On product: Conceptual Model > >> >>>>>>>>> > >> >>>>>>>>> By the definition, "a process execution represents an > > identifiable > >> activity". This does not seem to preclude one process execution > > assertion > >> denoting, at a coarse granularity, the same events in the world > > denoted by > >> multiple process executions in other assertions. > >> >>>>>>>>> > >> >>>>>>>>> If so, then in the File Scenario example, I could add a > > coarse- > >> grained process execution representing the whole e1-to-e5 activity: > >> >>>>>>>>> processExecution(pe5,collaboratively-edit,t) > >> >>>>>>>>> uses(pe5,e1,in) > >> >>>>>>>>> isGeneratedBy(e5,pe5,out) > >> >>>>>>>>> > >> >>>>>>>>> But then Section 5.5.2 distinguishes between "a single > > process > >> execution" and "one or more process executions". Following the > > argument > >> above, these could represent exactly the same occurrences in the > > world. > >> >>>>>>>>> > >> >>>>>>>>> So there is no difference between what is denoted by one > >> >>>>>>>>> and > >> multiple process executions, and so no difference between > > isDerivedFrom and > >> isDerivedFromInMultipleSteps as described. Whether e5 was derived > >> from > > e1 > >> appears to me to be entirely independent of how many process > > executions > >> were involved. > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>> -- > >> >>>>>>>> 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 > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> > _______________________________________________________________ > >> >>>>>>>> _______ This email has been scanned by the MessageLabs Email > >> >>>>>>>> Security System. > >> >>>>>>>> For more information please visit > >> >>>>>>>> http://www.messagelabs.com/email > >> >>>>>>>> > >> > _______________________________________________________________ > >> >>>>>>>> _______ > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>> -- > >> >>>>>> 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 > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> > ________________________________________________________________ > >> _ > >> >>>>>> _____ This email has been scanned by the MessageLabs Email > >> >>>>>> Security System. > >> >>>>>> For more information please visit > >> >>>>>> http://www.messagelabs.com/email > >> >>>>>> > >> > ________________________________________________________________ > >> _ > >> >>>>>> _____ > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>> > >> > ________________________________________________________________ > >> ___ > >> >>>> ___ This email has been scanned by the MessageLabs Email > >> >>>> Security System. > >> >>>> For more information please visit > > http://www.messagelabs.com/email > >> >>>> > >> > ________________________________________________________________ > >> ___ > >> >>>> ___ > >> >>>> > >> >>>> > >> >>>> > >> >>> > >> >>> > >> >>> > >> >> > >> >> > >> > ________________________________________________________________ > >> _____ > >> >> _ This email has been scanned by the MessageLabs Email Security > >> >> System. > >> >> For more information please visit http://www.messagelabs.com/email > >> >> > >> > ________________________________________________________________ > >> _____ > >> >> _ > >> >> > >> >> > >> > > >> > > >> > > > > > > > > > > ________________________________________________________________ > ______ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > > ________________________________________________________________ > ______ > > > > > > -- > Dr Simon Miles > Lecturer, Department of Informatics > Kings College London, WC2R 2LS, UK > +44 (0)20 7848 1166
Received on Friday, 5 August 2011 15:45:56 UTC