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

Hi Khalid, Daniel and Stian,

I am not sure how your proposal deals with generation.  The prov-dm 
document explains
that merging two well-formed accounts (where at most one PE generates an 
entity) may result
in a non well-formed.

I believe you have defined wasGeneratedBy property as functional, 
meaning that a non-well
formed account would be inconsistent in the ontology.

If wasGeneratedBy is no longer functional, then how do you associate 
time with a generation
event? (and any qualifier?)

Thanks,
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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>