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

I am suggesting that having a class Usage and a property used, allow details of usage to be captured as properties of the class, while natural rdf encoding still exists with used property.

Hence,   app:UsingProcessExpression can be a subclass of both PE and Usage class.
Likewise on generation side.

Professor Luc Moreau
Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom

On 24 Oct 2011, at 23:22, "Satya Sahoo" <satya.sahoo@case.edu<mailto:satya.sahoo@case.edu>> wrote:

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<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 Tuesday, 25 October 2011 04:32:08 UTC