- From: Satya Sahoo <satya.sahoo@case.edu>
- Date: Mon, 24 Oct 2011 17:05:52 -0400
- To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Cc: Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk>, Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>, public-prov-wg@w3.org
- Message-ID: <CAOMwk6ytOPy+CEvJBC7BWPOD1D=ix_zjA6d2RVj_zzgvwiMj4w@mail.gmail.com>
Hi Luc, Role is a consensus term from the provenance incubator that we agreed to model in the provenance WG provenance model. As we discussed earlier, Role is a modeling mechanism to allow Entities to assume different "personas" (hence the re-labeling of role to EntityInRole) without the need for n-ary relations. Issue 111 [1] is about the new relation wasAssumedBy introduced to link Entity to EntityInRole (also hasLocation for linking Location to Entity). Using EntityInRole is not incompatible with PROV-DM, we model the same information, that is, make assertions about the generation and use of Entities cleanly in OWL. In an earlier mailing list thread I had clarified that the time value (of generation, use, start, stop etc.) is associated with either the PE or Entity and not the property (use, generation etc.). If we take two assertions together: e1 wasGeneratedBy pe1. e1 wasGeneratedAt t1. We get required information that e1 was generated by a particular PE instance and at specific time. Similarly, for use we can create two identifiers (URIs) and make assertions that they were used by (perhaps) the same PE instance at different points in time in distinct roles. Other similar qualifiers can be asserted for other instances of EntityInRole. In the telcon today we discussed adding some clarification text in the html document that may help users to understand this point better. Thanks. Best, Satya On Mon, Oct 24, 2011 at 4:45 PM, Luc Moreau <l.moreau@ecs.soton.ac.uk>wrote: > ** > > Hi Khalid, Daniel and Stian, > > What have we gained with this entityInRole? you now seem to have > ended up with two different entities in role, for the same entity? How are > they related? > > So, what is the point to be incompatible with the data model, if you are > not achieving > the idea of connecting a process execution to an entity directly with a > property. > > In fact, you have created a new class EntityInRole, and introduced a new > instance, instance of entityInRole, > like you would have had to introduce a class Used, and an instance of it, > for each used property that requires > time/qualifer/etc. > > Luc > > > > > On 24/10/2011 17:35, Khalid Belhajjame wrote: > > On 24/10/2011 16:54, Khalid Belhajjame wrote: > > On 24/10/2011 16:49, Daniel Garijo wrote: > > Yes, Khalid, but if you have the same entity used 2 times by different > process executions > with the same role, you would also need 2 different EntityInRole. > > Yes, if the same entity play two different roles w.r.t. the same process > execution, then we need to create two different EntityInRoles. > > > I meant if the same entity plays the same role in 2 different process > executions, then we need to create two different entityInRoles. > > khalid > > > > Imagine that pe1 uses e1Input1 (entity e1 with role: Input1) at time t1. > According to our current modeling, we would assert t1 to the entityInRole > (with hasTemporalValue). > > If some time later we execute another p2 that uses e1 with the same role at > time t2, we cannot use e1Input1, > because it has already associated t1. That is why we would need e1Input1' > (a new EntityInRole instance). > > But I remember we already discussed this with Satya :S > It seems that we should make it clear somewhere, since people are getting > confused. > > Yes, I agree. We need to write it down. It is probably not the most elegant > solution, but it is a solution that works :-) > > khalid > > > Best, > Daniel > > 2011/10/24 Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk> > >> On 24/10/2011 15:44, Stian Soiland-Reyes wrote: >> >>> On Mon, Oct 24, 2011 at 12:07, Luc Moreau<L.Moreau@ecs.soton.ac.uk> >>> wrote: >>> >>> >>> That's exactly the point, time is associated with generation/use, not >>>> entities. >>>> >>> But as we have not (as of yet) made a deliberate n-ary relationship >>> Generation or Use class in PROV-O - so prov:wasGeneratedAt is >>> associated with an Entity (as it can only be generated once within an >>> account) and prov:assumedRoleAt with an EntityInRole (as it can only >>> be prov:wasASsumedBy one Entity). >>> >>> >>> To be fair this is not a direct mapping with PROV-DM, because it would >>> allow the same entity-in-role to be prov:used by two different PEs - >>> the prov:assumedRoleAt would only record time of the first such use. >>> On the other hand a PE could actually be using the entity several >>> times, and we don't have a way to record each of these unless we do it >>> as separate roles each time. (And still can't capture the duration of >>> the use) >>> >> >From my understanding that is not the case. If the same entity is used >> twice by two different process executions or by the same process execution, >> then we will have to create two EntityInRole(s) each associated with a >> different role. >> >> For example consider an entity e that is used by a process execution p >> such that the role of e w.r.t. p is r, and let p' be another process >> execution that uses e such that the role of e w.r.t. p' is r'. >> >> Using prov-o, we will have two entityinRoles that represent the entity e >> but with different roles. Consider that these entityinroles are er and er'. >> er and er' will have as properties the characterizing attributes of e. >> Additionally, er (resp. er') will have the role property r (resp. r'). >> >> Khalid >> >> >>> >>> >>> >> >> > > >
Received on Monday, 24 October 2011 21:06:23 UTC