Re: prov:Dictionary example - without the specs

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> 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://dbpedia.org/resource/John_Glover_Roberts,_Jr.>, # prov:Collection.
>>>>>     
>>>>>     37       <http://dbpedia.org/resource/Antonin_Scalia>,           #
>>>>>     
>>>>>     38       <http://dbpedia.org/resource/Anthony_Kennedy>,          #
>>>>>     
>>>>>     39       <http://dbpedia.org/resource/Clarence_Thomas>,          #
>>>>>     
>>>>>     40       <http://dbpedia.org/resource/Ruth_Bader_Ginsburg>,      #
>>>>>     
>>>>>     41       <http://dbpedia.org/resource/Stephen_Breyer>,           #
>>>>>     
>>>>>     42       <http://dbpedia.org/resource/Samuel_Alito>,             #
>>>>>     
>>>>>     43       <http://dbpedia.org/resource/Sonia_Sotomayor>,          #
>>>>>     
>>>>>     44       <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.