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

Re: prov:Dictionary example - without the specs

From: James Cheney <jcheney@inf.ed.ac.uk>
Date: Thu, 07 Jun 2012 00:36:47 +0100
Message-ID: <4FCFE98F.2090709@inf.ed.ac.uk>
To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
CC: public-prov-wg@w3.org
('binary' encoding is not supported, stored as-is)

I have been skimming the recent discussions, so apologies if this is 

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 

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.


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.
Received on Wednesday, 6 June 2012 23:37:35 UTC

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