Re: Roles

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.

(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

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)



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?

-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Friday, 16 September 2011 09:39:27 UTC