W3C home > Mailing lists > Public > public-prov-wg@w3.org > October 2011

Re: Comments on the current data model

From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Date: Tue, 11 Oct 2011 14:35:01 +0100
Message-ID: <CAPRnXt=7wdO=nODsv5H-4Zmz58UtpPe3VBRwBMssSWtUGap8NQ@mail.gmail.com>
To: Simon Miles <simon.miles@kcl.ac.uk>
Cc: Provenance Working Group WG <public-prov-wg@w3.org>
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

(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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:10 UTC