Re: prov:Dictionary example - without the specs

Luc,

On Jun 6, 2012, at 3:37 PM, Luc Moreau wrote:

> Hi Tim,
> 
> It's not about a trade-off data model vs reasoning, it's about defining a data structure
> that makes sense.

I'm in.

> 
> I would argue that you are not defining a collection of entities but a collection of uris.

In prov-o, one uses URIs to talk about entities. The URI is a semiotic symbol for the referent. 
In prov-n, one uses Value to talk about entities. Those strings are also semiotic symbols for the referent.

When I assert the following prov-o, I am saying that a big ol' bag of flesh-n-bones, covered in a robe and gray hair, is a member of today's supreme court.
John is -- not his URI. I could call him right now on the phone. I'm not putting some text file or web page into a set. I picked him up and set him upon the bench.
This is symbols and referents.

I am defining a set of entities.

    21 :todays-us-supreme-court
    35    prov:hadMember                                             # These would be asserted on a simple (first step)
    36       <http://dbpedia.org/resource/John_Glover_Roberts,_Jr.>,




> That's exactly why we introduced keys in prov dictionaries, so that we could decide 
> whether something is in dictionary or not.

Meanwhile, Stian is agreeing [1] with those against his own CompleteCollection, saying that even with the completeness "boolean", he wouldn't really know if it was complete.
And if it's not complete, then we can't satisfy your "so that we could decide whether something is in dictionary or not", since a new _key_ could come along.
The problem was just displaced one level, and can't be solved in that fashion.

I'm wondering what outstanding issue is in this thread.
Is it that you do not want to have a 

     prov:hadMember with domain Collection and range Entity, 

and instead restrain it to:

     prov:hadMember with domain Dictionary and range KeyValuePair

?

I advocate the former, and think that you want the latter. 

Regards,
Tim


[1] http://www.w3.org/mid/CAPRnXtm52YzmjmpO4=Cx+q0um+UMpNdwMdjS68XjMhBmDi1pYQ@mail.gmail.com


> 
> Professor Luc Moreau
> Electronics and Computer Science
> University of Southampton 
> Southampton SO17 1BJ
> United Kingdom
> 
> On 6 Jun 2012, at 20:22, "Timothy Lebo" <lebot@rpi.edu> wrote:
> 
>> 
>> On Jun 6, 2012, at 3:05 PM, Luc Moreau wrote:
>> 
>>> Hi Tim,
>>> 
>>> Whats the matter?
>>> 
>>> If you have one entity denoted by two different URIs, and the following assertion:
>>> 
>>>> :collection 
>>>>    a prov:Collection;
>>>>    prov:hadMember :myMember;
>> 
>> Then I know that one of them is in, and am not sure about the other one.
>> 
>>> 
>>> How are you able to decide if the entity denoted by:myMember-alias is also member of the collection?
>> 
>> Why is identity resolution a requirement for simply saying that something is in a set?
>> That's an awfully tall order. 
>> 
>> Impossible, even. 
>> Since I can mint a URI and make it the same as any of your members's URIs and never tell you about my URI.
>> 
>> 
>> Why are we back to choosing when reasoning applies to DM, and when DM just gets to be a data model?
>> Am I getting confused?
>> 
>> -Tim
>> 
>> 
>> 
>>> 
>>> Professor Luc Moreau
>>> Electronics and Computer Science
>>> University of Southampton 
>>> Southampton SO17 1BJ
>>> United Kingdom
>>> 
>>> On 6 Jun 2012, at 14:49, "Timothy Lebo" <lebot@rpi.edu> wrote:
>>> 
>>>> Luc,
>>>> 
>>>> On Jun 6, 2012, at 12:46 AM, Luc Moreau wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 5 Jun 2012, at 23:01, "Timothy Lebo" <lebot@rpi.edu> wrote:
>>>>> 
>>>>>> 
>>>>>> On Jun 5, 2012, at 5:55 PM, Luc Moreau wrote:
>>>>>> 
>>>>>>> Sure, but we said we would just define a collection type for extensibility, and nothing else. 
>>>>>> 
>>>>>> Yes. But with no way to put something into it?
>>>>>>  
>>>>>>       "Thanks for the canoe, W3C…  can I have a paddle?"
>>>>> 
>>>>> Then, we should drop the type Collection entirely.
>>>> 
>>>> If I have to choose a memberless Collection and no Collection at all, I'd choose a memberless Collection.
>>>>>   
>>>>> membership of entities is not clear,
>>>> 
>>>> Yes it is clear, using:
>>>> 
>>>> :collection 
>>>>    a prov:Collection;
>>>>    prov:hadMember :myMember;
>>>> .
>>>> :myMember a prov:Entity .
>>>> 
>>>> Done!
>>>> 
>>>> 
>>>>> since we don't have 
>>>>> a predicate to decide whether two entities are equal.
>>>> 
>>>> 
>>>> Why does this matter?
>>>> Are you trying to fulfill a notion of  "complete collection".
>>>> If so, why?
>>>> 
>>>>> 
>>>>> Furthermore, why not insertion and removal relations?
>>>>> 
>>>> 
>>>> (… and Membership)
>>>> 
>>>> Because it's beyond scope, as the WG agreed during the rename to Dictionary.
>>>> We agreed to provide the "harder" Dictionary and let those operations and qualifications to an extension.
>>>> We also agreed to include the name of the "abstract" collection.
>>>> 
>>>> In the latest PROV-O, prov:Dictionary reuses the prov:hadMember that could also be used for simple Collections.
>>>> The latest PROV-O prov:Dictionary is a cheap win, I don't see the reason to go out of our way to prevent people from using or extending Collection.
>>>> And, the focus is clearly on prov:Dictionary, as we agreed.
>>>> 
>>>> -Tim
>>>> 
>>>> 
>>>>> Luc
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> All the rest would be dictionary specific.
>>>>>> 
>>>>>> Yes, all of the meat would be Dictionary specific.
>>>>>> Insertion and Removal and Membership are Dictionary specific.
>>>>>> That's fine.
>>>>>> I'm having all of that reuse the Collection's hadMember.
>>>>>> 
>>>>>> (new OWL is up, I'm putting the HTML up  now).
>>>>>> 
>>>>>> 
>>>>>> -Tim
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Professor Luc Moreau
>>>>>>> Electronics and Computer Science
>>>>>>> University of Southampton 
>>>>>>> Southampton SO17 1BJ
>>>>>>> United Kingdom
>>>>>>> 
>>>>>>> On 5 Jun 2012, at 22:39, "Timothy Lebo" <lebot@rpi.edu> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>>  
>>>>>>>> On Jun 5, 2012, at 5:34 PM, Luc Moreau wrote:
>>>>>>>> 
>>>>>>>>> The only membership defined in dm is:
>>>>>>>>> 
>>>>>>>>> Membership	memberOf(c, {(key_1, e_1), ..., (key_n, e_n)})
>>>>>>>>> 
>>>>>>>>> Why should we define membership on collections?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Because we defined Collection?
>>>>>>>> "A collection is an entity that provides a structure to some constituents, which are themselves entities. These constituents are said to be member of the collections. "
>>>>>>>> 
>>>>>>>> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#term-collection
>>>>>>>> 
>>>>>>>> -Tim
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Professor Luc Moreau
>>>>>>>>> Electronics and Computer Science
>>>>>>>>> University of Southampton 
>>>>>>>>> Southampton SO17 1BJ
>>>>>>>>> United Kingdom
>>>>>>>>> 
>>>>>>>>> On 5 Jun 2012, at 22:29, "Timothy Lebo" <lebot@rpi.edu> wrote:
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Jun 5, 2012, at 5:26 PM, Luc Moreau wrote:
>>>>>>>>>> 
>>>>>>>>>>> Dictionary keys can be compared. Hence, after insertion and removal, we can always determine a new dictionary state if we knew the state before operation.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> okay. But why should that prevent someone from asserting that an Entity is a member of a Collection?
>>>>>>>>>> I feel like your "we can't assume reasoning/inference; it's a data model" argument applies here (this time, against your position).
>>>>>>>>>> 
>>>>>>>>>> -Tim
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Professor Luc Moreau
>>>>>>>>>>> Electronics and Computer Science
>>>>>>>>>>> University of Southampton 
>>>>>>>>>>> Southampton SO17 1BJ
>>>>>>>>>>> United Kingdom
>>>>>>>>>>> 
>>>>>>>>>>> On 5 Jun 2012, at 22:11, "Timothy Lebo" <lebot@rpi.edu> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Jun 5, 2012, at 5: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).
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> huh? Why does that matter? In that case, we wouldn't be able to do it for Dictionaries, either.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> -Tim
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>   
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> 

Received on Wednesday, 6 June 2012 19:56:43 UTC