Re: Roles (was: Testing the ontology for expressing workflow provenance)

On Fri, Sep 9, 2011 at 15:35, Simon Miles <simon.miles@kcl.ac.uk> wrote:
> I could imagine many users might specialise the "used" property to
> express more precisely how an entity was used, e.g.
>
> taverna:2613
>  a prov:ProcessExecution;
>  mywf:usedValue taverna:676.
> mywf:usedValue rdfs:subPropertyOf prov:used.
>
> Does this make sense?  Assuming we have no power to stop this being
> done, does it have a different meaning to ascribing a role using the
> Role class?

It would only have the same meaning if you use lots of OWL trickery
with someValuesFrom etc. - but I see what you mean. In an open world
it's possible to specialize in any direction.

The problem of specialising directly like this is that it does not
allow you to specify anything more detailed about how you used it,
except by even further sub-properties. So if I wanted to describe how
I used my bread maker:


:RaisingAgent a owl:Class ;
    rdfs:subClassOf prov:Role .
:Ingredient a owl:Class ;
    rdfs:subClassOf prov:Role .
:coveredBy a owl:ObjectProperty ;
    rdfs:range :Ingredient ;
    rdfs:domain :Ingredient .

:breadMaking a prov:ProcessExecution .

:bread a prov:Entity ;
    prov:wasGeneratedBy :breadMaking .

:breadMaking prov:usedRole :yeastRaising, :yeastIngredient, :flourIngredient ;
# and a few more things

:yeastRaising a :RaisingAgent ;
    prov:assumedBy :yeast .

:yeastIngredient a :Ingredient ;
    prov:assumedBy :yeast ;
    :coveredBy :flourIngredient .

:flourIngredient a :Ingredient ;
    prov:assumedBy :flour .

(Ontologywise I assume here that roles have to be specified by
subclassing prov:Role and that prov:usedRole [ prov:assumedBy :flour ]
can be used to clarify the role instead of stating prov:used :flour -
how to specify this magic in OWL is left as exercise to the reader)


Here :yeast has played two different roles "raising agent" and
"ingredient".  - and I can clarify deeper details about how the yeast
was used in that role, for instance ingredients can be stacked on top
of each other in a given order.


In your approach, I can make subproperties :ingredient and
:raisingAgent, and use two different entities to avoid saying that the
yeast was always covered by the flour.


:RaisingAgent a owl:Class ;
:Ingredient a owl:Class ;
:ingredient a owl:ObjectProperty ;
    rdfs:subPropertyOf prov:used ;
    rdfs:range :Ingredient .
:raisingAgent a owl:ObjectProperty ;
    rdfs:subPropertyOf prov:used ;
    rdfs:range :RaisingAgent .
:coveredBy a owl:ObjectProperty ;
    rdfs:range :Ingredient ;
    rdfs:domain :Ingredient .

:breadMaking a prov:ProcessExecution .

:bread a prov:Entity ;
    prov:wasGeneratedBy :breadMaking .

:breadMaking :ingredient :yeastIngredient, :flour ;
  :raisingAgent :yeastRaising .

# Relate the two yeasts - as it was used as a raising agent
# for shorter time than as an ingredient.
:yeastIngredient :coveredBy :flour ;
    prov:wasComplementOf :yeast .
:yeastRaising prov:wasComplementOf :yeast ;



To be honest I can't decide. :-)  They both have their charm, but I
think there's a danger if we start using complemented entities to
explain roles in a process or vice versa.


However I know from my perspective from workflow systems where I can
view the 'role' as the service parameter, then the problem with your
approach is that I have to auto-generate sub-properties based on the
workflow definition, instead of having a fixed extension to the PROV
ontology. That's a bit too dynamic OWL even for my tastes.


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

Received on Friday, 9 September 2011 15:46:32 UTC