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

Hi Luc,
As we have frequently discussed, the important point is to be able to
effectively model provenance related information.

Many of the modeling choices in the PROV-DM are also arbitrary choices -
 for example, I am not sure if we have consensus on associating qualifiers
with relations (Used, Generation) versus Entity/PEs for temporal information
etc.? In addition, as we discussed in the ontology telcon last week mapping
terms from the Data Model to the ontology will require us to make modeling
decisions that are compatible with the OWL-based approach.

Introducing n-ary relations will make generation of RDF (Paul's example)
difficult for users - introduction of blank nodes makes life very difficult
for exchange and interoperability of RDF data. Use of roles is a common
practice in the ontology community and I believe we should re-use some of
the best practices from existing ontology community rather than creating an
unnatural model. Some additional comments are inline:


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).
>
> If the PE instance generates multiple Entity instances, how will
app:UsingProcessExecution allow association of generation time with each of
the different Entity instances?


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
>
>
app:EntityInRole cannot be subclass of an owl class (Entity or PE) and an
object property (Used).


> The Data Model defines role as a reserved qualifier. So, we are still
> following the charter.
>
>
I cannot find any description of terms (roles etc.) in the charter and the
"proposed charter" from the incubator group [1] also just lists "role" as a
term from OPM with an example - there was no notion of "qualifiers" as has
been introduced in the Data Model.

Thanks.

Best,
Satya

[1]
http://www.w3.org/2005/Incubator/prov/XGR-prov-20101214/#Proposed_Charter_for_a_Provenance_Interchange_Working_Group


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