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

('binary' encoding is not supported, stored as-is)
Hi all.

This is an example of the kind of potential mismatch between PROV-DM and PROV-O that I was concerned about in the other thread I started [1].  Maybe it would be interesting to define two mappings from PROV-DM to RDF, one following the current approach (EntityInRole) and one following the "Usage" approach.  This could also be helpful for future modifications such as making Event explicit (if we go that route).  

I personally find the EntityInRole approach worrying, if only because the use of multi-word concepts makes me think that two concepts are being glued together (or a concept / relationship that describes how multiple concepts is missing).

--James

[1] http://lists.w3.org/Archives/Public/public-prov-wg/2011Oct/0185.html


On Oct 25, 2011, at 9:51 AM, Daniel Garijo wrote:

> Hi Luc,
> imo, that is why we supported the entityInRole. The alternative is to have both a class and a property in the ontology
> for modelling the same thing, which can be confusing. And not only that, we would need a class "Usage", "Control"
> and "Generation", while now we only need one class: EntityInRole.
> 
> The current approach is more flexible: if you want to go for a simpler provenance (no role, or time involved), 
> you link the process execution to the used entity with the "used" relationship. Otherwise, you link it it to the entityInRole,
> which is assumedBy some entity. You would have a unique instance of EntityInRole for each PE the same way that you 
> would need a unique instance of "Usage" in the other approach. In fact, both approaches are very similar in the end
> (introducing a new class to model the n-ary relationships), but we thought this one was more clear.
> 
> What must be done is explain this modelling in the document. 
> 
> Thanks,
> Daniel
> 
> 
> 
> 2011/10/25 Luc Moreau <L.Moreau@ecs.soton.ac.uk>
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Received on Tuesday, 25 October 2011 09:04:49 UTC