- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Thu, 12 Jul 2012 10:38:45 +0100
- To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Cc: "public-prov-wg@w3.org" <public-prov-wg@w3.org>, Timothy Lebo <lebot@rpi.edu>
It's not generally a derivation in my view, unless by 'my:Membership'
you mean 'JoiningTheCollection' - I would have done it as an
wasInfluencedBy.
But OK. I welcome our new simplicity overlords. It is clean enough to
obviously leave open questions such as completeness.
On Thu, Jul 12, 2012 at 10:26 AM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote:
> Stian,
>
> Yes, I suggest hadMember(c,e).
>
> James in a separate email suggested a way of defining a new
> membership class as a kind of derivation:
> For instance, wasDerivedFrom(c,e,[prov:type='my:Membership'])
> or even using prov-n syntax extensibility
>
> my:hadMember(c,e,[prov:label="what a beautiful membership"])
>
> Luc
>
>
> On 07/12/2012 10:10 AM, Stian Soiland-Reyes wrote:
>>
>> Short response - I don't feel strongly for membership to be qualified
>> (in PROV-O) and have attributes/id/type (in DM), but would have
>> preferred it to be there for extension purposes. Given the time frame
>> I am reluctantly not protesting. (a -0 vote if you like)
>>
>>
>> Could you draft what is your suggested new PROV-N syntax? I am
>> wondering which of these you are proposing:
>>
>> hadMembers(membership1, c, {e1, e2, e3}, true) // Drop attributes
>>
>> hadMembers(c, {e1, e2, e3}, true) // Drop attributes and statement ID
>>
>> hadMembers(c, {e1, e2, e3}) // Drop completeness (!!)
>>
>> hadMember(c, e1) // Drop entity set
>> hadMember(c, e2)
>> hadMember(c, e3) // ..now it looks like a subtype of wasInfluencedBy
>>
>>
>>
>> I can see that as collection is a general structure, it can be really
>> useful for applications to subtype and extend the membership. In
>> PROV-O it is of course possible to create subproperties, but we would
>> generally recommend subclassing an Influence class instead, like
>> making "physics:Fusion" a subclass of "prov:Derivation", allowing
>> additional attributes in the subclass. Making membership a binary
>> relationship breaks this pattern. In PROV-DM it would not be possible
>> to express any custom membership - for instance to provide
>> meta-provenance or annotations about how the membership was observed,
>> give a particular characterization to a subset of a collection, etc.
>>
>> I know that the current PROV-O solution (which I have not had time to
>> influence lately) unrolls the membership per entity - although the
>> examples there need updating, you can't any more in PROV-O reflect the
>> ID and attributes of a hadMembers() statement in PROV-N with multiple
>> entities in the set. So it would need to go one way or the other to
>> make it consistent.
>>
>>
>> I can also see an argument that it is an observational thing, like
>> specializationOf and alternateOf - which don't have statement
>> identifier nor attributes.
>>
>> So as short - reluctant OK for the simplification - but I'm sad to see
>> the extensibility mechanism be lost. I can see that this makes it more
>> difficult to make extensions like the note PROV-Dictionary, as I would
>> have to make my own, disconnected DictionaryMembership that can
>> reflect the dictionary key, rather than just adding it as an attribute
>> to a specialized prov:Membership/hadMembers().
>>
>>
>>
>> My earlier response to a private email below:
>>
>>
>> On Wed, Jul 11, 2012 at 11:23 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk>
>> wrote:
>>
>>> When reviewing the latest prov-o Membership I came across a misalignment
>>> between prov-dm and prov-o. Membership is not Influence in prov-dm, but
>>> is Influence in prov-o.
>>>
>>> If membership is a derivation then we are OK. But some in the group
>>> didnt
>>> want this.
>>
>>
>> I agree that membership is not (necessarily) a derivation. A
>> membership statement is just an observation, it is not expressing how
>> the two activities are formed. However, given that a characterisation
>> of a collection is static within PROV, then its constituent members
>> must have been generated before or at the same time as the collection.
>> Thus it is another case of 'traceTo' in my mind - and so it is an
>> influence.
>>
>> A derivation is a strong statement, because in DM we require the
>> derived from entity to be directly involved with the activity that
>> created the derived entity. We don't know at what stage the entity got
>> added, as the collection {e1,e2,e3} could have been formed by removing
>> d from {e1,e2,e3,e4}.
>>
>> However we know that at some point there must have been an (implied)
>> activity that used e1 and generated a collection that contained e1 -
>> and that the current collection has a trace of derivations leading
>> back to these two. Thus we are talking about here is the transitive
>> derivation - basically wasInfluencedBy towards every entity in the
>> entity set.
>>
>>
>> if e1 is a member of collection c1, then e1 influences c1 - because if
>> e1 was not there, c1 would have been different. Or in another way - e1
>> is a requirement for c1 to be made.
>>
>> This sounds just like any other influence.
>>
>> " Influence ◊ is the capacity of an entity, activity, or agent to have
>> an effect on the character, development, or behavior of another by
>> means of usage, start, end, generation, invalidation, communication,
>> derivation, attribution, association, or delegation."
>>
>> Well, if this definition is to list every subclass (basically like an
>> OWL equivalent class of the union of the subclasses) and do not allow
>> any other kind of influencing, then it simply needs to include
>> membership as well. That should not be a problem as membership is part
>> of DM.
>>
>>
>>
>>> With Tim, I explored a number of solutions, including making it a non
>>> qualified
>>> relation: i.e. a binary hadMember(collection,entity), no complete flag,
>>> no identification,
>>> no permitted subtype in prov-dm.
>>
>>
>> I suggest keeping it as it is, as I don't see a problem with it being
>> an influence. I think the qualified membership could be essential when
>> I get down to tidying up the Dictionary note so that it is a proper
>> extension of PROV-DM and PROV-O.
>>
>>
>> Another solution for PROV-O would be to introduce a superclass of
>> Influence that is "Qualified". This would become another abstract
>> class for a single purpose, which introductions have not been popular
>> within the task force. I even think we had "Qualified" earlier - and
>> it was much appreciated that now we have classes that almost all make
>> sense provenance wise and which relate to PROV-DM.
>>
>> --
>> Stian Soiland-Reyes, myGrid team
>> School of Computer Science
>> The University of Manchester
>>
>>
>> On Thu, Jul 12, 2012 at 9:26 AM, Luc Moreau <l.moreau@ecs.soton.ac.uk>
>> wrote:
>>>
>>> Dear all, Tim,
>>>
>>> After sleeping on this issue, I think there is only one workable outcome:
>>> Membership should be a binary relation without associated qualified
>>> class.
>>>
>>> Context: after F2F3, Dictionaries were dropped from prov-dm, but the
>>> n-ary
>>> membership relation was kept:
>>> hadMembers(mId, c, {e1, e2, e3}, true, [prov:label="A beautiful
>>> collection"])
>>>
>>> Recently, Tim re-introduced this relationship in prov-o as a form of
>>> Influence.
>>> There was some push back for membership to be a kind of Derivation.
>>> Making
>>> it Influence
>>> and not Derivation would suddenly introduce a new relation in the model
>>> we
>>> don't
>>> understand the implications. Not making it an Influence would break the
>>> prov-o design.
>>>
>>> Some reviewers had suggested to make it binary. It seems it is the right
>>> choice, in
>>> the circumstances, as the minimum we can agree on, given such a short
>>> time.
>>>
>>> So, I will implement the changes very shortly. Please should if there is
>>> a
>>> problem.
>>> Tim, ..., sorry to ask, can you revert back to a binary hadMember without
>>> associated
>>> class?
>>>
>>> Luc
>>>
>>>
>>>
>>> On 07/11/2012 11:15 PM, Luc Moreau wrote:
>>>
>>> Hi Tim,
>>>
>>> We have a number of possibilities for qualified Membership. None
>>> seems particularly good.
>>>
>>> 1. Membership is an Influence and a Derivation.
>>> Some F2F3 participants seemed to be against membership as
>>> derivation.
>>>
>>> 2. Membership is an Influence and not a Derivation
>>>
>>> I feel that this is not realistic. To me, all forms of influence
>>> between two entities are derivations.
>>>
>>> It would also be surprising that a concept that was about
>>> to be dropped from the provenance model, is in fact a primitive
>>> form of influence, not expressible differently.
>>>
>>> 3. Membership is still qualified, but not an Influence.
>>> This would break the prov-o design consistency.
>>>
>>> 4. Membership should not be qualified.
>>> Some wanted to keep it qualified.
>>>
>>> 5. ... drop membership ... timeout!
>>>
>>> Luc
>>>
>>>
>>> On 11/07/12 21:54, Timothy Lebo wrote:
>>>
>>> Luc,
>>>
>>> On Jul 11, 2012, at 4:49 PM, Luc Moreau wrote:
>>>
>>> Hi Tim,
>>>
>>> Thanks for the updated membership.
>>>
>>> We do have misalignment between provo and prov-dm.
>>> And I don't know how to solve it.
>>>
>>> In prov-dm, membership is not a subtype of influence.
>>> I recall explicitly some F2F3 participants didn't want membership as
>>> a form of derivation. I am not sure what their view would be about
>>> influence.
>>>
>>> If the group agrees that membership *is* a kind of influence,
>>>
>>>
>>> I think it's reasonable to say that an element of a set influences the
>>> set.
>>>
>>> I don't know
>>> where Influence should go in prov-dm, since it would no longer belong to
>>> component 3.
>>>
>>> If the group decides that membership *is* not a kind of influence, can
>>> you
>>> still
>>> express Membership using the qualified pattern ... without influence?
>>>
>>>
>>>
>>> To do so will lose a lot of design consistency.
>>>
>>>
>>>
>>> Hhhhmmm?
>>>
>>> What ever the decision ... more editing in perspective :-(
>>> Sorry about that.
>>>
>>>
>>> :-/
>>>
>>> -Tim
>>>
>>>
>>> Luc
>>>
>>>
>>>
>>>
>>>
>>> On 11/07/12 18:15, Timothy Lebo wrote:
>>>
>>> prov-wg,
>>>
>>> http://aquarius.tw.rpi.edu/prov-wg/prov-o
>>>
>>> now has the qualified membership terms (I added IncompleteCollection,
>>> which
>>> we haven't discussed before).
>>>
>>>
>>> The ontology in it's usual place:
>>>
>>> http://dvcs.w3.org/hg/prov/raw-file/tip/ontology/ProvenanceOntology.owl
>>>
>>>
>>> The examples need to be reviewed and updated. Any pointers to flaws would
>>> be
>>> appreciated.
>>>
>>>
>>> Regards,
>>> Tim
>>>
>>>
>>> On Jul 11, 2012, at 9:38 AM, Luc Moreau wrote:
>>>
>>>
>>>
>>> send a link and I'll try to look at it later today
>>>
>>> On 11/07/2012 14:31, Timothy Lebo wrote:
>>>
>>>
>>> Luc,
>>>
>>> I put qualified membership back into the OWL file.
>>> I need to regenerate the HTML and will check through the update today.
>>>
>>> If you can take a look and provide any early feedback, I'd appreciate it.
>>>
>>> Regards,
>>> Tim
>>>
>>> On Jul 9, 2012, at 8:58 AM, Luc Moreau wrote:
>>>
>>>
>>>
>>>
>>> Hi Tim
>>>
>>> I understood [1] as take the 'dictionary' concepts and move them in a
>>> separate document,
>>> and keep the rest unchanged. We had just been through a round of
>>> discussion, for
>>> which there seems to be agreement on Collection, EmptyCollection and the
>>> membership
>>> as currently described in the dm.
>>>
>>> I agree though that it is a good idea to change the name to hadMembers or
>>> similar.
>>>
>>> Regards,
>>> Luc
>>>
>>>
>>>
>>> [1] http://www.w3.org/2011/prov/meeting/2012-06-22#resolution_2
>>>
>>> ________________________________________
>>> From: Timothy Lebo [lebot@rpi.edu]
>>> Sent: Monday, July 09, 2012 1:39 PM
>>> To: Luc Moreau
>>> Cc: public-prov-wg@w3.org
>>> Subject: Re: PROV-ISSUE-444 (prov-o-to-last-call): Review PROV-O for last
>>> call [PROV-O HTML]
>>>
>>> Luc,
>>>
>>> On Jul 9, 2012, at 4:05 AM, Luc Moreau wrote:
>>>
>>>
>>>
>>>
>>> ... and no qualified form for membership.
>>>
>>> Dont' we want subtyping and identification ?
>>>
>>>
>>>
>>> I never got the impression that qualified membership was part of what
>>> "stayed in" during our F2F vote.
>>> We continually said "Collection and hadMember", and never mentioned
>>> "qualifiedMembership and Membership".
>>>
>>> So, what was the intent of the group?
>>>
>>> Or, does DM intrinsically connect these and I just misinterpreted?
>>>
>>> Thanks,
>>> Tim
>>>
>>>
>>>
>>>
>>> Luc
>>>
>>> On 07/09/2012 09:02 AM, Luc Moreau wrote:
>>>
>>>
>>>
>>> Hi prov-o team,
>>>
>>> It seems there is another non-alignment between prov-o and prov-dm.
>>> Isn't there a prov:EmptyCollection class in the ontology?
>>>
>>> Luc
>>>
>>>
>>> On 07/04/2012 03:02 PM, Luc Moreau wrote:
>>>
>>>
>>>
>>> Hi prov-o team, again,
>>>
>>> Find below some specific comments about the provo document.
>>>
>>>
>>> Thanks for the extensive work!
>>> It needs some polishing, but the majority of it, can happen after LC.
>>>
>>> Answer to your questions:
>>>
>>> 1) Are there any issues that should delay the WG's release of PROV-O as
>>> Last
>>> Call (i.e., is all of the technical work done).
>>>
>>> - Minor Issues in the ontology raised in my previous message
>>> - Definition alignment, and make sure that example don't use constructs
>>> incorrectly (e..g hadRole)
>>>
>>> 2) Are the examples and scenario adequate?
>>>
>>> - Yes, though I couldn't follow the scenario anymore without a picture.
>>> Can
>>> a picture be added, with the style adopted by other documents
>>>
>>> 3) Should the links to prov-dm, prov-constraints, and prov-n stay in the
>>> cross reference?
>>>
>>> - See comment below.
>>>
>>>
>>>
>>> Specific comments:
>>>
>>> Section 1
>>> - owl-rl -> orl-rl ++
>>> - para 3: provdm introduces a MINIMAL set of concepts ... delete MINIMAL
>>> - "... which facilitate a fixed interpretation and use of the prov data
>>> model concepts based on the formal semantics of owl2: " delete
>>> - reference to xml-schema should be to xml-schema11 (owl2 automatically
>>> switched to xml-schema11)
>>>
>>> section 2:
>>> - "the terms in this category ARE APPLIED IN the same way ..." not sure
>>> what
>>> this mean.
>>>
>>> section 3.1:
>>> - "the starting point category is a small COLLECTION ..." to avoid
>>> confusion, use SET instead.
>>>
>>> - definitions entity/activity/etc need updating
>>>
>>> - "In this case, the Agent that influenced an Activity or Entity
>>> prov:actedOnBehalfOf another Agent that MAY HAVE HAD LESS INFLUENCE, but
>>> still bears some responsibility for the resulting Activity or Entity."
>>> I
>>> am not sure we should say this at all. The agent may or may not have had
>>> more or less influence.
>>>
>>>
>>> - MailScanner has detected a possible fraud attempt from "example.org"
>>> claiming to be http://example.org# -> http://example.org/# ?
>>> everywhere
>>>
>>> - example after fig 1: it would be nice to see a "prov-style" picture
>>>
>>> - example 2 (agent derek) ... it was suggested for prov-dm that
>>> examples should be described in past tense. It should be done here
>>> too.
>>>
>>> - i don't understand wy ex:post9821v1 is a specialization of ex:post9821,
>>> I can see it's an alternate. (in example code and in text)
>>>
>>> - inmediately->immediately
>>>
>>> - "Since the provenance produced by the activities of Derek and Monica
>>> correspond to different user views, the system automatically publish it
>>> in
>>> different prov:Bundles (ex:bundlePost and ex:bundlePost1)." I don't
>>> understand. It is part of the scenario? or is part of prov?
>>>
>>>
>>> - I am lost in the example without a picture
>>>
>>> - Suggestion: number examples
>>>
>>> - an example still has prov:hasAnnotation
>>>
>>> - "and all the data related to the post is lost. " permanently?
>>>
>>> - example: bundles have not been used, so what is their point?
>>>
>>> - figure 3: can we keep the conventions used elsewhere: agent is
>>> represented
>>> by pentagon.
>>>
>>> - comments in some of the example (e.g. qualified usage) go beyond the
>>> box,
>>> into the margin
>>>
>>> - cross referencing, I am not against it, I am concern about the
>>> additional
>>> space it takes.
>>> Can it be folded in the title section?
>>> It's probably too early at this stage to link to constraints, though
>>> this would be valuable once the prov-constraints document is stable.
>>>
>>> - examples: dererk -> dereck
>>>
>>> - examples: to save space, can we define all prefixes upfront and avoid
>>> repeating them
>>>
>>> - prov:wasDerivedFrom contains definition of entity, and not of
>>> derivation
>>>
>>> - prov:Bundle: the text talks about account
>>>
>>> - prov:Bundle: maybe should state the purpose: provenance of provenance
>>>
>>> - prov:alternateOf: contains definition of software agent
>>>
>>> -<> prov:wasDerivedFrom< .... dm ...> :
>>> I guess it's always good to eat our own dog food, but I think this
>>> complicates
>>> the examples.
>>>
>>> - prov:invalidatedAtTime the painter seem to be destroyed in 2012???
>>>
>>> - prov:mentionOf/specializationOf: have software agent as definition.
>>>
>>> - prov:value: "The main value ... of a STRUCTURED value."
>>> What is structured, here?
>>>
>>> - prov:wasInvalidatedBy example:
>>> Is it right to say swissair_flight_111_crash prov:used<http//db....
>>> swissair_flight_111>?
>>>
>>> - prov:Influence and its subclasses: can they be used alone without a
>>> concrete influence?
>>> Shouldn't the text say something and RECOMMEND the use of subclasses?
>>>
>>> - prov:Communication is not allowed in the domain of atLocation (see
>>> example for prov:Communication)
>>>
>>> - typo: prov:Actvity in example with policySale
>>>
>>> - Delegation is not in the domain of hadRole (see insuranceAgent_Frank)
>>>
>>> - example of derivation goes into margin
>>>
>>> - EntityInvolvment: comments that appear in the example should be given
>>> in
>>> the narrative.
>>>
>>> - Quotation no longer has hadQuoter and hadQuoted in prov-dm
>>>
>>> - prov:Revision, the binary wasAttributedTo is incorrectly qualified by
>>> an
>>> Association
>>> instead of Attribution
>>>
>>> - example for prov:hadGeneration
>>> has a qulaifiedDerivation,
>>> dont' you need to specifiy influencer entity?
>>>
>>> - no role allowed in attribution
>>>
>>> :nationalRegionsList
>>> a prov:Entity;
>>> prov:qualifedAttribution [
>>> a prov:Attribution;
>>> prov:agent :civil_action_group;
>>> prov:hadRole :owner;
>>> ]
>>> .
>>>
>>>
>>>
>>> - no role in delegation
>>>
>>> :chauffeur
>>> a prov:Person;
>>> prov:actedOnBehalfOf :celebrity-in-car;
>>> prov:qualifiedDelegation [
>>> a prov:Delegation;
>>> prov:agent :celebrity-in-car;
>>> prov:hadRole :employer; # The celebrity employed the chauffeur
>>> during
>>> the enforcement.
>>> ];
>>> .
>>>
>>> - prov:qualifiedDerivation
>>> :bar_chart
>>> prov:wasDerivedFrom :aggregatedByRegions;
>>> prov:qualifiedDerivation [
>>> a prov:Derivation;
>>> prov:hadGeneration :illustration;
>>> ];
>>> .
>>>
>>> Shouldn't you link to :aggregatedByRegions;?
>>>
>>> - qualifiedInvalidation: check time of crash
>>>
>>> - prov:qualifiedQuotation uses quoter/quotedAgent
>>>
>>>
>>> - qualified source
>>> :temperatureDisplay
>>> a prov:Entity;
>>> prov:hadOriginalSource :sensorReading20120510;
>>> prov:qualifiedSource [
>>> a prov:Source;
>>> prov:entity :sensorReading20120510;
>>> ];
>>> .
>>>
>>> Isn't there a RECOMMENDation to use the qualified pattern only if it adds
>>> new information?
>>> It does not do it here.
>>>
>>>
>>> - qualified usage
>>>
>>> :newsPublication
>>> a prov:Activity;
>>> prov:used :tsunami_image;
>>> prov:qualifiedUsage [
>>> a prov:Usage;
>>> :hasCopyrightPermission :licensedUse;
>>> :hasOwner :reuters;
>>> ];
>>>
>>> Need to add prov:influencer tsunami_image
>>>
>>>
>>> -
>>>
>>> prov:ProvenanceService
>>> prov:hasAnchor prov:hasProvenance prov:hasProvenanceService
>>> prov:provenanceUriTemplate
>>> Should not be described in the html document, but in the paq document.
>>>
>>>
>>> - appendix
>>> # Instead of defining their own, modelers should use the
>>> # recommended inverse local name within the PROV namespace:
>>>
>>> This is confusing. So, it would be better to say that they are defined in
>>> prov namespace
>>> though not defined in prov-o.html ( a bit like paq stuff). It would be
>>> informative.
>>>
>>> - OWL2 primer should be normative reference
>>>
>>>
>>>
>>>
>>> On 04/07/2012 10:26, Luc Moreau wrote:
>>>
>>>
>>>
>>> Hi prov-o team,
>>>
>>> Thanks for producing the document. Here are a few comments on the
>>> ontology,
>>> before I start reading
>>> the html document.
>>>
>>> I think you removed too many of the property characteristics, some of
>>> which
>>> are prov-o specific
>>> (as opposed to being prov-constraints specific).
>>>
>>> Otherwise, I think the ontology is aligned with prov-dm. I think that
>>> Influence and influencer are
>>> quite nice!
>>>
>>> Cheers,
>>> Luc
>>>
>>>
>>> 1. hadRole: why is domain defined as intersection of Influence and six of
>>> its subclasses.
>>> Why not the subclasses directly?
>>>
>>>
>>> 2. qualifiedXXX: shouldn't they be inverseFunctional?
>>> Otherwise, this would allow for a given Influence instance, to be a
>>> qualified Influence
>>> for multiple subjects. This is not intended.
>>>
>>> The qualified pattern is prov-o specific. It was inverse functional
>>> before,
>>> but I think
>>> this characteristic was incorrectly removed.
>>>
>>> 3 influencer: should it be functional: there is only one influencer per
>>> qualified pattern instance, isn't there.
>>>
>>> 4. Likewise:
>>> hadPlan: is functional
>>> hadUsage: is functional
>>> hadGeneration: is functional
>>> hadActivity: is functional
>>>
>>> As per prov-dm.
>>>
>>> 5. generatedAtTime: In owl file: editorialNote "It is the intent that the
>>> property chain holds: (prov:qualifiedGeneration o prov:atTime)
>>> rdfs:subPropertyOf prov:generatedAtTime."@en
>>>
>>> --> It cannot be functional since qualifiedGeneration is not functional.
>>>
>>> Also applies to all the others, invalidatedAtTime, startedAtTime,
>>> endedAtTime,
>>>
>>>
>>> Cheers,
>>> Luc
>>>
>>>
>>> On 03/07/2012 21:20, Provenance Working Group Issue Tracker wrote:
>>>
>>>
>>>
>>> PROV-ISSUE-444 (prov-o-to-last-call): Review PROV-O for last call [PROV-O
>>> HTML]
>>>
>>> http://www.w3.org/2011/prov/track/issues/444
>>>
>>> Raised by: Timothy Lebo
>>> On product: PROV-O HTML
>>>
>>> PROV-O is ready for internal review for Last Call release.
>>>
>>> The document is at:
>>>
>>>
>>> http://dvcs.w3.org/hg/prov/raw-file/tip/ontology/last-call/2012-07-03-internal-review/Overview.html
>>>
>>> Please respond to this thread with general feedback and answers to the
>>> following questions:
>>>
>>> 1) Are there any issues that should delay the WG's release of PROV-O as
>>> Last
>>> Call (i.e., is all of the technical work done).
>>>
>>>
>>> 2) Are the examples and scenario adequate?
>>>
>>>
>>> 3) Should the links to prov-dm, prov-constraints, and prov-n stay in the
>>> cross reference?
>>>
>>> Regards,
>>> Tim prov:actedOnBehalfOf :prov-o-team .
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
--
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
Received on Thursday, 12 July 2012 09:39:42 UTC