Re: Roles

On 16/09/2011 10:36, Stian Soiland-Reyes wrote:
> On Fri, Sep 16, 2011 at 09:37, Khalid Belhajjame
> <Khalid.Belhajjame@cs.man.ac.uk>  wrote:
>
>> The Specialization of Entity into Role, or what I think of as
>> "EntityAssumingAGivenRole", allows to get around this, at least in the case
>> of use and generation. It is a sort of "weak" resource, that cannot exists
>> on its own and that make sense only in the context of the entity it
>> represents and the process execution it is connected to.
> I agree on this approach. As such the "EntityAssumingAGivenRole" is
> not a first-class citizen of the PROV language, just a glue class to
> express the n-ary relationship in RDF - and we might not need to
> address it in the abstract model.
Exactly, that what I was thinking of.

>
> (If we should include a class for the Role itself is a separate matter
> - personally I believe we should not, as we don't have much general to
> say about the role, but perhaps use cases would prove otherwise)
>
>
>
> So can an EntityAssumingAGivenRole (or perhaps EntityAssumedRole)  be
> thought of as having the inverse property
>
>   :entityAssumingAGivenRole prov:assumedRoleIn :processExecution

Yes, I think there will be a need for two property, a property that link 
"EntityAssumingGivenRole" to the "Entity" that it represent, and a 
property that links it to the process execution.
>
> with prov:assumedRoleIn being a functional property so that it can
> only be applied for a single process execution? (ie. for each
> PE/role/entity combination a new EAAGR is needed)
>
>
> > From the EntityAssumingAGivenRole - how do we find the actual "role"
> as defined in the formal model - ie. the "RestaurantCustomer" or
> "Researcher"? Subclass or something more explicit like prov:role ?
> (Subclass would more easily allow the "Researcher in Restaurant in
> Manchester" role, but not as easy to look up)
I guess one way is to defined is a data property of the 
"EntityAssumingGivenRole".


Thanks, khalid

>
>
>
> Note - I am not challenging the proposal, I believe we need something
> like this, but I'm not sure what to call it or the exact semantics
> intended.
>
>
>
> Strawman example with various made-up prov:properties:
>
> # Flour was purchased and used in baking a bread
>
> :myFlour a prov:Entity ;
>      prov:assumedRole :flourAsProduct, :flourAsIngredient .
>
> :flourAsProduct a prov:EntityAssumingAGivenRole ;
>      a shop:PurchasedProduct ;
>      prov:started "2011-02-15 11:15";
>      prov:ended "2011-02-15 11:20";
>      shop:paidInGBP 1.42 ;
>      food:weightInGrams 1000 ;
>      prov:assumedRoleIn :purchase .
>
> :flourAsIngredient a prov:EntityAssumingAGivenRole ;
>      a food:Ingredient ;
>      prov:started "2011-02-15 15:14";
>      prov:ended "2011-02-15 17:28";
>      food:weightInGrams 500 ;
>      prov:wasGeneratedBy :baking ;
>      prov:assumedRoleIn :baking .
>
>
> :purchase a prov:ProcessExecution, shop:Purchase ;
>      prov:started "2011-02-15 11:12" ;
>      prov:ended "2011-02-15 11:20" .
>
> :baking a prov:ProcessExecution, shop:Baking ;
>      prov:used :flourAsIngredient ;
>      prov:started "2011-02-15 15:10";
>      prov:ended "2011-02-15 17:28" .
>
>
> Now my earlier argument is that the above could also be expressed with
> :flourAsProduct and :flourAsIngredient as two entities which are
> prov:complementOf :flour - but that would not as easily relate the
> entities to properties of their usage/generation.
>
> Above the roles were assumed at different times from the overall
> process. The flour was not the first item to be put in the bag of
> purchased items ("Generated as a purchased product") - and the baker
> added other things before the flour was "Used as an ingredient". (Of
> course the flour existed before it was a purchased product, but then
> it was not :myFlour)
>
> This also shows why properties have to be related to the role
> usage/generation, because I purchased ("generated") 1 kg of flour, but
> only used 500g when baking. (Again a case for prov:complementOf and
> pure entities!)
>
>
> Are we perhaps not inviting to lots of confusion with both approaches
> allowed, or is that a powerful flexibility?
>

Received on Friday, 16 September 2011 10:05:41 UTC