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

Re: PROV-ISSUE-391 (jzhao): Reflecting Membership in the Collection Component [prov-dm]

From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
Date: Tue, 04 Sep 2012 13:50:14 +0100
Message-ID: <EMEW3|db052366926a9bb843e6d47a72305b87o83DoH08l.moreau|ecs.soton.ac.uk|5045F906.4000202@ecs.soton.ac.uk>
To: public-prov-wg@w3.org
Hi all,
This issue is now closed.
Luc

On 18/06/12 16:27, Jun Zhao wrote:
> On 14/06/2012 12:41, Timothy Lebo wrote:
>> On Jun 14, 2012, at 2:53 AM, Luc Moreau wrote:
>>
>>> Hi Jun
>>>
>>> Paolo has added a membership relation on collection, and the text regarding completeness has been toned down as per ACTION-91.
>>> I therefore propose to close this issue pending review.
>> +1
> +1
>
> Cheers,
>
> Jun
>> -Tim
>>
>>> Professor Luc Moreau
>>> Electronics and Computer Science
>>> University of Southampton
>>> Southampton SO17 1BJ
>>> United Kingdom
>>>
>>> On 3 Jun 2012, at 17:48, "Provenance Working Group Issue Tracker"<sysbot+tracker@w3.org>  wrote:
>>>
>>>> PROV-ISSUE-391 (jzhao): Reflecting Membership in the Collection Component [prov-dm]
>>>>
>>>> http://www.w3.org/2011/prov/track/issues/391
>>>>
>>>> Raised by: Jun Zhao
>>>> On product: prov-dm
>>>>
>>>> The PROV-O team are in the process of reflecting the modeling of Membership in the ontology. By reading deeply into the section 5.6.5 of the DM spec about Membership, I wonder whether we should reflect a bit on the DM modeling on this construct.
>>>>
>>>> It would have been straightforward to use this construct to declare which key-value pair as being a member of a collection. However, the definition of Membership shows that this construct is designed for expressing much more than this:
>>>>
>>>> - The DM doc says that: "The membership relation removes the need for explicit mention of the state of the dictionary prior to each operation, allowing the state of a dictionary to be expressed without having to introduce a prior state." What does this "state of the dictionary" refer to? If we know the collection c1 before the insertion or deletion, and collection c2 after these activities, then we are all OK, right? I wonder whether this statement implies some scenarios that I am not aware of.
>>>>
>>>> - A membership relation, written memberOf(id; c, {(key_1, e_1), ..., (key_n, e_n)}, cplt, attrs), has:
>>>>         id: an optional identifier identifying the relation;
>>>>         collection: an identifier (c) for the dictionary whose members are asserted;
>>>>         key-entity-set: a set of key-entity pairs (key_1, e_1), ..., (key_n, e_n) that are members of the dictionary;
>>>>         complete: an optional boolean Value (cplt); if true, it indicates that no other member belongs to the dictionary; if false, it indicates that other members belong to the dictionary; if unspecified, other members may belong to the dictionary.
>>>>         attributes: an optional set (attrs) of attribute-value pairs representing additional information about this relation.
>>>>
>>>> It seems a rather complicated definition. Why do we have to mark a collection as "complete"? What additional attributes are we expecting to provide for a membership relation? This has direct impact on the prov ontology. The distinction between a membership and a collection is not that obvious. Can we live without a Membership class to express provenance of collections?
>>>>
>>>> We would really like to have this issue resolved as soon as possible, in line with our internal release timeline, which is the upcoming Thursday. Help is much appreciated!
>>>>
>>>> [1] http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#component6
>>>>
>>>> Cheers,
>>>>
>>>> Jun
>>>>
>>>>
>>>>
>>>
>>
>

-- 
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 Tuesday, 4 September 2012 12:50:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 September 2012 12:50:50 GMT