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

Hi Satya,

Your message clearly shows that you are describing a concept that is not 
in the data model.
How can readers understand this?

It is an arbitrary choice you made to associate this information with 
the entity. It could have
been associated with the PE.  I, in my application, may prefer to have a 
subclass of PE
"app:UsingProcessExecution", which would capture all the relevant 
information (time, qualifier, etc).

The Data Model is not choosing this approach. It is saying that there is 
a Used event connecting
PE, Entity, time, qualifiers, etc.

As an ontology developer, you always have the choice to define
   app:EntityInRole as a subclass of both Entity and Used
or alternatively
   app:UsingProcessExpression as a subclass of both PE and Used

Why have you made this choice in the ontology, when we don't make it in 
the model?

The Data Model defines role as a reserved qualifier. So, we are still 
following the charter.

Luc

On 24/10/2011 22:05, Satya Sahoo wrote:
> 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 
> <mailto: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
>>>>     <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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

Received on Monday, 24 October 2011 21:23:49 UTC