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

Re: prov:Dictionary example - without the specs

From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Date: Thu, 07 Jun 2012 11:04:30 +0100
Message-ID: <EMEW3|6cd596665fe69105d277d9ca4528b2cao56B4W08L.Moreau|ecs.soton.ac.uk|4FD07CAE.3050202@ecs.soton.ac.uk>
To: James Cheney <jcheney@inf.ed.ac.uk>
CC: "public-prov-wg@w3.org" <public-prov-wg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:16 UTC