Re: Comments on the current data model

This means that in the workflow example [1] we would have to do two
accounts (two graphs), one for the overall workflow execution, and one
for the sub-processes of the workflow. (any sub-sub-processes would be
even more accounts).


One would have to make sure that one generates different entities,
which can be related using wasComplementOf.  This reduces to:

:cake1 prov:wasGeneratedBy :cookInOven .
:cake2 prov:wasGeneratedBy :baking .

## But with which attributes are they complementing each-other??
:cake1 prov:wasComplementOf :cake2 .
:cake2 prov:wasComplementOf :cake1 .


or you can do
  :cake2 prov:wasDerivedFrom :cake1
but this implies a 'hidden' process execution. (The process of taking
the cake out of the oven?)



In the current PROV-O proposal for roles [2] you can use different
EntityInRole in each ProcessExecution:

:cake a prov:Entity .

:rawCake a prov:Entity .
# Its provenance excluded for brevity

:cookInOven a prov:ProcessExecution ;
  prov:used :rawCake .

:bakedCake a prov:EntityInRole, :OvenContent ;
  prov:assumedBy :cake ;
  prov:derivedFrom :rawCake ;
  prov:wasGeneratedBy :cookInOven .

:cakeFromBaking a prov:EntityInRole, :Product ;
  prov:assumedBy :cake ;
  prov:wasGeneratedBy :baking .

(Imagine prov:assumedBy as a  more specific version of
prov:wasComplementOf - which defines which entity is assuming the
role)

(In [1] this is equivalent to #sha1OutputFromShasum and
#sha1OutputFromWorkflow assumed by #sha1)


However this leaves open the question of how the abstract :cake was
generated. Perhaps that's OK to be blurry, after all it depends on
which scale you look what counts as "generating the cake" - the
abstract concept of the cake is formed in your head, if you like, and
not subject to provenance.


[1] http://dvcs.w3.org/hg/prov/raw-file/tip/ontology/ProvenanceFormalModel.html#example-workflow-run
[2] http://dvcs.w3.org/hg/prov/raw-file/tip/ontology/components/EntityInRole/car-purchase.ttl


On Tue, Oct 11, 2011 at 13:46, Simon Miles <simon.miles@kcl.ac.uk> wrote:
> Hi Luc,
>
>> I don't understand your multiple granularities. Can you explain?
>
> I mean, to use an old example, that a cake may be reasonably be
> asserted to be generated by a BakeCake execution and also by a
> CookInOven execution, because the latter is a finer grained
> description than the former. The assertions could be by the same
> asserter or two different asserters.
>
> Before accounts are mentioned, this seems perfectly reasonable - why
> would we disallow such a description? However, we have a restriction
> that, for an account to be valid, each entity can only be generated by
> one execution within that account. This suggests to me that he
> restriction is about accounts and their validity rather than
> generation events.
>
> Thanks,
> Simon
>
>
>> Luc
>>
>> On 10/10/2011 17:42, Simon Miles wrote:
>>> I can't see what it would mean without knowledge of accounts, or how
>>> it could be "correct without qualification". Surely it is simply not
>>> true that only one PE can generate an entity independently of
>>> accounts? Why do we not allow multiple granularities of description?
>>>
>>
>>
>
>
>
> --
> Dr Simon Miles
> Lecturer, Department of Informatics
> Kings College London, WC2R 2LS, UK
> +44 (0)20 7848 1166
>
>



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

Received on Tuesday, 11 October 2011 13:36:01 UTC