Re: Prov-o call on Monday 12:00noon US ET

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 
>>> <mailto: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
>>>         <mailto: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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>