Re: Changes to prov:Dictionary

Stian,

On Jun 6, 2012, at 10:39 AM, Stian Soiland-Reyes wrote:

> Without EmptyCollection or CompleteMembership the
> collections/dictionaries are of almost no worth to my use cases,

EmptyCollection remains in the latest PROV-O (so that is not an issue).

It was CompleteMembership that got the ax (this is the topic at hand).

Regarding your use cases, I think it's important to cite Graham's points about uses cases for standards:
http://www.w3.org/mid/4FCEFCB0.4090100@zoo.ox.ac.uk



> as
> all I can say then is that "some of the members are X, Y and Z" - but
> there might also be A, B and C. In Taverna workflows, all collections
> are closed (unless you export provenance before a workflow has
> finished). It is important to know that ALL these genes - and no other
> genes - came back. Just saying "some of these came back" is of less
> value.

Would this use case be handled if Taverna instead leveraged the "additional attributes" that DM already provides?

memberOf(id; c, {(key_1, e_1), ..., (key_n, e_n)}, cplt, attrs)

perhaps a property taverna:isComplete or class taverna:CompleteDictionary ?

> 
> 
> I understand that in RDF if we don't use rdf:List, then statements of
> such completeness are still fairly vague as the lists are not
> terminated and additional tuples could be adding
> members/insertions/removals.

If this can't be handled soundly and properly in PROV-O and OWA, then I don't think we should try (or, fake it).

> 
> However when I make a provenance export of a workflow run, I would
> want to also say something like "These are all the workflow processes
> that ran, and these are all the entities that were created".



> But
> perhaps a more general completeness-claim for an account/bundle is out
> of scope for PROV.

That seems to be the predominant perspective, as people have indicated in various email threads and tracker issues.
With the use of a custom attribute and type ( taverna:isComplete or class taverna:CompleteDictionary ), can you accept removing the special optional parameter on DM's memberOf?

> 
> 
> However, I still don't undertstand what is the problem with saying
> something is an empty collection.

Not an issue. EmptyDictionary is still in there :-)

Thanks!
Tim

> 
> On Wed, Jun 6, 2012 at 2:49 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk> wrote:
>> 
>> Hi Tim,
>> 
>> It's specifically your last point. Being to express whether membership was complete
>> was a request from Stian and Paolo I believe.
>> 
>> Luc
>> 
>> 
>> On 06/06/2012 02:31 PM, Timothy Lebo wrote:
>> 
>> Luc,
>> 
>> On Jun 6, 2012, at 12:48 AM, Luc Moreau wrote:
>> 
>> 
>> 
>> On 5 Jun 2012, at 23:18, "Timothy Lebo" <lebot@rpi.edu> wrote:
>> 
>> prov-wg (and prov-dm editors),
>> 
>> I've reviewed all of the materials (that I can find) regarding collective concerns about prov:Dictionary, and
>> have committed changes to the latest PROV-O owl and html to address those concerns:
>> 
>> * https://dvcs.w3.org/hg/prov/raw-file/default/ontology/Overview.html
>> * http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceOntology.owl
>> 
>> The changes are summarized here:
>> 
>> http://www.w3.org/2011/prov/wiki/index.php?title=Eg-34-us-supreme-court-membership&oldid=7905#PROV-O_changes_made.2C_inspired_by_this_example
>> 
>> and repeated here:
>> 
>>  Added class prov:Collection, as subclass of Entity
>> Added property prov:hadMember domain prov:Collection range prov:Entity.
>> 
>> This supports both generic "simple set" prov:Collection and prov:Dictionary.
>> 
>> Made KeyValuePair a subclass of Entity
>> 
>> this follows from Set Collection :c prov:hadMember :my_member and the definition of Collection "A collection is an entity that has some members. The members are themselves entities").
>> 
>> Renamed prov:membership to prov:qualifiedMembership to follow qualification pattern naming.
>> prov:Membership became subclass of prov:EntityInvolvement (though, it could become subclass of prov:KeyValuePairInvolvement, itself a subclass of prov:EntityInvolvement. But we'll try to simplify and reuse prov:entity)
>> prov:member renamed to prov:pair and became a subproperty of prov:involvee
>> Added property chain (qualifiedMembership o prov:pair) rdfs:subClassOf prov:hadMember
>> Added prov:removed domain prov:Removal range prov:KeyValuePair
>> Removed prov:CompleteDictionary from DM and PROV-O.
>> 
>> Why?
>> Luc
>> 
>> 
>> 
>> What in particular would you like to discuss.
>> As I said, this reflects a response to many concerns that have been raised by many people in many forms.
>> In an effort to maintain focus and to make progress, I recommend that these points, the latest prov-dm, and the latest prov-o update serve as the basis for these discussions.
>> 
>> -Tim
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> You'll notice the prov-o modeling of Dictionaries is not consistent with latest prov-dm.
>> 
>> The prov-o team would like to ask the prov-dm editors to reconsider how collections and dictionaries are defined, so that they reflect the latest prov-o modeling of the PROV concepts.
>> 
>> Regards,
>> Tim Lebo
>> 
>> 
>> 
>> 
>> 
>> cc tracker ISSUE-374 ISSUE-391
>> 
>> 
>> 
>> --
>> 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
> 
> 
> 
> 
> --
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester
> 
>