- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Thu, 7 Jun 2012 05:03:08 +0000
- To: James Cheney <jcheney@inf.ed.ac.uk>
- CC: "public-prov-wg@w3.org" <public-prov-wg@w3.org>
- Message-ID: <EMEW3|179f8a610547837ec43e7bdd2cc72edao5663D08L.Moreau|ecs.soton.ac.uk|322CB6A1>
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.
As far as unification is concerned, a unification base case is equality of two constants, if I recall correctly.
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.><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><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><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><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><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><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><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><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><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<mailto:Paolo.Missier@newcastle.ac.uk>, pmissier@acm.org<mailto: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.
Received on Thursday, 7 June 2012 05:04:35 UTC