- From: Paolo Missier <Paolo.Missier@ncl.ac.uk>
- Date: Wed, 06 Jun 2012 21:56:04 +0100
- To: public-prov-wg@w3.org
- Message-ID: <4FCFC3E4.8060509@ncl.ac.uk>
Hi,
I'm back from a short break... and catching up.
my (belated) comments below.
On 6/6/12 9:26 PM, Timothy Lebo wrote:
> Luc,
>
> On Jun 6, 2012, at 2:36 PM, Luc Moreau wrote:
>
>>
>> Hi all,
>>
>> I dont understand this discussion.
>>
>> See example 50
>> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#example_50
>
> http://aquarius.tw.rpi.edu/prov-wg/prov-o#derivedByInsertionFrom
> has a prov-o example very similar to #example_50.
>
>> We explicit list the contents of a dictionary after some insertion.
>
> I agree with this example, what does it show that is wrong with prov-o?
>
>
>>
>> Definition 38 in prov-constraints define membership
>> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#membership-as-insertion
>
> Great.
>
>>
>> Disallowing complete membership seems to go against the definition of insertion.
>
> How so?
> "Insertion is a derivation that transforms a dictionary into another, by insertion of one or more key-entity pairs."
>
>
>
>> Are you suggesting that we don't exactly know what is being inserted in a dictionary?
>
> No, we know _exactly_ what is inserted into the dictionary. They inserted KeyValuePairs are listed right in the assertion.
>
>
> What we're saying is that for any prov:Dictionary and for any N known members, there is no way to know if that prov:Dictionary
> only has N members, or if there are more.
this has been the topic of some discussion in the past. in the case of ex. 50 mentioned above, we do know that d2 is /precisely/ {
("k1", e1), ("k2", e2), ("k3", e3) }. this is because
1) d0 is the EmptyDictionary
2) there is no break in the precise derivation chain (i.e., no "weaker" wasDerivedFrom(d_n,d_n-1) in the mix)
in other cases, this may not be possible. But at least we do have cases where the state is fully known.
Regarding membership, def 38 in the constraints doc:
http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#membership-as-insertion
summarizes the conclusion that we reached when membership was introduced, namely:
"Membership is a convenience notation, since it can be expressed in terms of an insertion into some collection."
This postulates the existence of an otherwise undefined c0, such that
memberOf(c, {(k1, v1), ...})iff derivedByInsertionFrom(c, c0, {(k1, v1), ...}).
Following this definition, a "complete collection" defined through membership is simply one where c0 is the EmptyCollection in the
definition above (although this is currently not stated in the constraints doc). That seems quite natural and ensures that, just
like for a chain of insertions/removals, also for membership we have a case where the state of the collection is completely known.
This formulation is also independent of specific use cases, which may be vulnerable to Graham's "scope creep" argument.
Either way, I agree with Stian that a, say, Taverna-specific extension would reduce interoperability.
--Paolo
> Membership is alive and healthy in this last PROV-O update announced in this thread.
>
> What is being proposed is that the class prov:CompleteDictionary (and DM's optional "complete" attribute) be removed from PROV.
>
>
> -Tim
>
>
>
>>
>>
>>
>> Professor Luc Moreau
>> Electronics and Computer Science
>> University of Southampton
>> Southampton SO17 1BJ
>> United Kingdom
>>
>> On 6 Jun 2012, at 17:05, "Stephan Zednik" <zednis@rpi.edu <mailto:zednis@rpi.edu>> wrote:
>>
>>>
>>> On Jun 6, 2012, at 10:57 AM, Timothy Lebo wrote:
>>>
>>>> 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
>>>
>>> +1 to the relevance of Graham's point about scope creep and system use cases vs. coverage/scope of a standard.
>>>
>>>>
>>>>
>>>>
>>>>> 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.
>>>
>>> Are you specifically worried about the possibility that other members may be asserted at a later time by someone else? If this
>>> is an issue than perhaps you could use a system-specific extension of prov:Collection which utilizes a terminated ordered list.
>>>
>>> I must reiterate my agreement with Graham's point above that this need from this use case should not become a requirement for
>>> all collections defined in the standard.
>>>
>>>>> 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 ?
>>>
>>> Even if this attribute was added to the prov or an extension of prov, it does not enforce the closed-world membership that Stian
>>> would like to have.
>>>
>>> No attribute or class specialization will resolve the issue of trying to enforce CWA in RDF.
>>>
>>>>
>>>>>
>>>>>
>>>>> 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).
>>>
>>> +1
>>>
>>> I think in general the idea of 'completeness' is incompatible with OWA and should not be addressed in PROV-O.
>>>
>>> --Stephan
>>>
>>>>
>>>>>
>>>>> 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 <mailto: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 <mailto: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
>>>>>> <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 <mailto:l.moreau@ecs.soton.ac.uk>
>>>>>> United Kingdom http://www.ecs.soton.ac.uk/~lavm <http://www.ecs.soton.ac.uk/%7Elavm>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Stian Soiland-Reyes, myGrid team
>>>>> School of Computer Science
>>>>> The University of Manchester
>>>>>
>>>>>
>>>>
>>>
>
--
----------- ~oo~ --------------
Paolo Missier - Paolo.Missier@newcastle.ac.uk, pmissier@acm.org
School of Computing Science, Newcastle University, UK
http://www.cs.ncl.ac.uk/people/Paolo.Missier
Received on Wednesday, 6 June 2012 20:56:33 UTC