- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Thu, 07 Jun 2012 11:04:30 +0100
- To: James Cheney <jcheney@inf.ed.ac.uk>
- CC: "public-prov-wg@w3.org" <public-prov-wg@w3.org>
- Message-ID: <EMEW3|6cd596665fe69105d277d9ca4528b2cao56B4W08L.Moreau|ecs.soton.ac.uk|4FD07CAE>
Hi James, You're right. We never had time to write the constraints in the document. The text of the dm, however, reflects them. Here is a first stab at them, for discussion. http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#collections-and-contents Luc On 06/07/2012 10:37 AM, James Cheney wrote: > > On Jun 7, 2012, at 6:03 AM, Luc Moreau wrote: > >> Thanks James for reminding us that the empty collection is also complete >> knowledge of the membership! >> >> A key point about collections >> >>> The intent of these relations and types is to express the /history >>> of changes that occurred to a collection/. Changes to collections >>> are about the insertion of entities in collections and the removal >>> of members from collections. Indirectly, such history provides a way >>> to reconstruct the contents of a collection. >> >> By reconstruct, we mean recompute. This does not manifest itself in >> the constructs but in >> The comments we give in examples. We still need to make this explicit >> in constraints. >> > > If reconstruction is an indirect motivation that is only suggested by > comments about examples, then then why all the fuss? I don't see > where this requirement comes from. Is it going to imply a requirement > on the constraints/formal semantics? In that case, that should be > worked out first. > >> As far as unification is concerned, a unification base case is >> equality of two constants, if I recall correctly. > > Yes, I noted this already below. My real point was: > >>> But it still seems to me that the fact that *computing* membership >>> in a programming language requires a notion of equality, does not >>> imply that we need such a notion to *describe* memberships between >>> individuals and collections. > > that is, why are we talking about computing/deciding membership at all? > > If we want to (computably) reconstruct the history, then perhaps we > need more, but I don't see where the requirement arises. We aren't > defining a programming language. > > I don't see what stops anyone who believes they have complete > knowledge from going ahead and trying to compute with the collection > history, but I don't see why this needs to be standardized, given that > doing so seems incompatible with the open world assumption made on the > web. > > But again, I'm behind. > > --James > >> >> >> Professor Luc Moreau >> Electronics and Computer Science >> University of Southampton >> Southampton SO17 1BJ >> United Kingdom >> >> On 7 Jun 2012, at 00:37, "James Cheney" <jcheney@inf.ed.ac.uk >> <mailto:jcheney@inf.ed.ac.uk>> wrote: >> >>> Hi, >>> >>> I have been skimming the recent discussions, so apologies if this is >>> off-point. >>> >>> I thought PROV (-DM|-O) were about *describing* past states of >>> affairs, not *computing*. >>> >>> Far be it for me to denigrate ML, but to me, the right analogy for >>> what we are doing is logic programming, not functional programming. >>> >>> In Prolog, say, you don't need equality tests to define membership >>> declaratively: >>> >>> member(X,[X|Xs]). >>> member(X,[Y|Xs]) :- member(X,Xs). >>> >>> There is also nothing especially CWA-dependent about this >>> definition, as it does not use negation-as-failure. OK, to be >>> pedantic, the first clause implicitly uses equality via unification, >>> so maybe this is a red herring. But it still seems to me that the >>> fact that *computing* membership in a programming language requires >>> a notion of equality, does not imply that we need such a notion to >>> *describe* memberships between individuals and collections. >>> >>> It seems to me that the issue is that saying that a given collection >>> is complete (or empty, a special case) closes the door on future >>> knowledge that might be asserted elsewhere/later about the >>> collection. This seems orthogonal to the issue of whether the >>> descriptive information has a computational reading. >>> >>> Re-engaging lurk mode. >>> >>> --James >>> >>> On 06/06/12 22:45, Luc Moreau wrote: >>>> Hi Paolo, >>>> >>>> No that's not the issue I was trying to raise. >>>> >>>> The definition of a list is classically: >>>> >>>> - fun member(x,[]) = false >>>> | member(x,b::y) = >>>> if x=b then true >>>> else member(x,y); >>>> >>>> where one needs to be able to compare elements (x=b) >>>> >>>> Given two uris, one cannot decide whether the entities they denote >>>> are the same or not. >>>> Hence, we can't compute this member function. >>>> >>>> We should not attempt to specify prov:Collection >>>> >>>> Luc >>>> >>>> On 06/06/12 22:06, Paolo Missier wrote: >>>>> Hi, >>>>> >>>>> it seems to me that all the ping pong from this mail froward in >>>>> the thread is about whether Collections should be sets or bags >>>>> (multisets). In the latter case, it doesn't matter whether two >>>>> URIs really refer to the same entity. >>>>> Is this the case? If so, would it be reasonable to accept that >>>>> (abstract) Collections are bags, and Dictionaries as /sets/ (of >>>>> key-valuye pairs)? >>>>> >>>>> -Paolo >>>>> >>>>> >>>>> On 6/5/12 10:05 PM, Luc Moreau wrote: >>>>>> Hi Tim, >>>>>> >>>>>> Thanks for your example. >>>>>> >>>>>> The following is not valid according to prov-dm: >>>>>> >>>>>> prov:hadMember # These would be asserted on a simple (first step) >>>>>> >>>>>> 36 <http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l36> <http://dbpedia.org/resource/John_Glover_Roberts,_Jr.>, # prov:Collection. >>>>>> >>>>>> 37 <http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l37> <http://dbpedia.org/resource/Antonin_Scalia>, # >>>>>> >>>>>> 38 <http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l38> <http://dbpedia.org/resource/Anthony_Kennedy>, # >>>>>> >>>>>> 39 <http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l39> <http://dbpedia.org/resource/Clarence_Thomas>, # >>>>>> >>>>>> 40 <http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l40> <http://dbpedia.org/resource/Ruth_Bader_Ginsburg>, # >>>>>> >>>>>> 41 <http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l41> <http://dbpedia.org/resource/Stephen_Breyer>, # >>>>>> >>>>>> 42 <http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l42> <http://dbpedia.org/resource/Samuel_Alito>, # >>>>>> >>>>>> 43 <http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l43> <http://dbpedia.org/resource/Sonia_Sotomayor>, # >>>>>> >>>>>> 44 <http://dvcs.w3.org/hg/prov/file/tip/examples/eg-34-us-supreme-court-membership/rdf/eg-34-us-supreme-court-membership.ttl#l44> <http://dbpedia.org/resource/Elena_Kagan>; >>>>>> >>>>>> The key reason why we went for a dictionary and, say, a set of >>>>>> entities, >>>>>> is that we are unable to decide whether an entity belongs to a >>>>>> set on the basis of >>>>>> its urls (since the same entity may be denoted by multiple urls). >>>>>> >>>>>> Luc >>>>>> >>>>>> On 05/06/2012 06:25, Timothy Lebo wrote: >>>>>>> prov-wg, >>>>>>> >>>>>>> I tried my hand at modeling the provenance of the U.S. Supreme Court's current membership, and its derivation to it's first membership. >>>>>>> >>>>>>> The wiki page for the example is at: >>>>>>> >>>>>>> http://www.w3.org/2011/prov/wiki/Eg-34-us-supreme-court-membership >>>>>>> >>>>>>> In an attempt to take a fresh look at how we're modeling dictionaries (and collections?), I didn't reference PROV-DM, PROV-O, or any other examples or documentation -- I just tried to describe the subject matter. >>>>>>> >>>>>>> >>>>>>> How does it look? >>>>>>> >>>>>>> I'd like to move PROV-O (and DM, if it needs tweaking) towards this kind of modeling and naming. >>>>>>> >>>>>>> Discussion and feedback encouraged. >>>>>>> >>>>>>> Later today, I'll try to start from scratch on the DM and work through the current PROV-O modeling, and then the recent threads on this topic. >>>>>>> I hope by then we can converge on a satisfactory design. >>>>>>> >>>>>>> Regards, >>>>>>> Tim >>>>>>> >>>>> >>>>> >>>>> -- >>>>> ----------- ~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 >>>>> >>> >>> The University of Edinburgh is a charitable body, registered in >>> Scotland, with registration number SC005336. > > > This body part will be downloaded on demand. -- 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, 7 June 2012 10:05:16 UTC