W3C home > Mailing lists > Public > public-prov-wg@w3.org > September 2012

Re: PROV-ISSUE-549: XML Schema Bundle vs. NamedBundle [XML Serialization]

From: Hua, Hook (388C) <hook.hua@jpl.nasa.gov>
Date: Thu, 13 Sep 2012 08:11:41 +0000
To: Luc Moreau <l.moreau@ecs.soton.ac.uk>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Message-ID: <CC76DB77.153BF%hook.hua@jpl.nasa.gov>
Hi Luc,

I'm curious what was the rationale for not wanting arbitrary levels of
nesting of bundles?

In scientific workflows, nested workflows provide a useful mechanism to
hide the level of detail at arbitrary levels. Wouldn't that be
conceptually similar to arbitrary levels of nested bundles?

Following example 39 in
I can see that not having arbitrary levels of bundle nesting would keep
the provenance of provenance simpler, say, to capturing first order



On 9/10/12 9:36 AM, "Luc Moreau" <l.moreau@ecs.soton.ac.uk> wrote:

>Hi Curt,
>Following discussion in prov-constraints/prov-n, we are going to rename
>the toplevel bundle
>a prov document, wheres the bundle (named set of statements) should
>remain bundle.
>If we follow the same terminology, old:NamedBundle should become
>and old:Bundle should become new:Document.
>BTW Your suggestion would allow arbitrary levels of nesting of bundles,
>which we don't want.
>On 09/10/2012 05:32 PM, Provenance Working Group Issue Tracker wrote:
>> PROV-ISSUE-549: XML Schema Bundle vs. NamedBundle [XML Serialization]
>> http://www.w3.org/2011/prov/track/issues/549
>> Raised by: Curt Tilmes
>> On product: XML Serialization
>> What is the rationale for distinguishing Bundle vs. NamedBundle in the
>> current XSD Schema?
>> Why not just have an optional prov:id on Bundle and just have one type?
>Professor Luc Moreau
>Electronics and Computer Science   tel:   +44 23 8059 4487
>University of Southampton          fax:   +44 23 8059 2865
>Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
>United Kingdom                     http://www.ecs.soton.ac.uk/~lavm
Received on Thursday, 13 September 2012 08:15:24 UTC

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