Re: ISSUE-385: hasProvenanceIn: finding a solution

Hi Tim
Response interleaved.

On 01/06/2012 16:07, Timothy Lebo wrote:
> (to those that worked on specializationOf and alternateOf in the last round, can you please walk through this?
> This example is an exercise of the final definitions, and isTopicOf might be phrased in terms of them.)
>
> Luc,
>
>
> On May 31, 2012, at 5:54 PM, Luc Moreau wrote:
>
>    
>> All,
>>
>> To try and converge towards a solution, I am
>> circulating an example using a ternary hasProvenanceIn.
>> I would like to understand if and how we can make it work with
>> a simpler relation.
>>
>>
>> Two bundles ex:run1 and ex:run2 describe bob's role as a controller
>> of two activities.  Same bob, two different bundles.
>>      
>
> I've diagrammed your example scenario, which can be found at http://www.w3.org/2011/prov/wiki/Eg-33-a-simpler-hasProvenanceIn
> It uses the "decomposed" hasProvenanceIn modeling that I recommend, using simply prov:isTopicOf and prov:alternateOf.
> Also, the Trig encoding is at http://dvcs.w3.org/hg/prov/file/tip/examples/eg-33-a-simpler-hasProvenanceIn/rdf/eg-33-a-simpler-hasProvenanceIn.trig
>
>    

Your picture indeed displays what I would like to express, but it is 
misleading, since it does
not really display what you have encoded.

tool:bob1 alternateOf :Bob has no reason to point to :Bob in :run1, it 
should also
point to :Bob in :run2, and likewise for the other alternate property. 
(in fact, :Bob should
be a shared node your graph, across all three bundles).

>>     bundle ex:run1
>>      activity(ex:a1, 2011-11-16T16:00:00,2011-11-16T17:0:00)  //duration: 1hour
>>      wasAssociatedWith(ex:a1,ex:Bob,[prov:role="controller"])
>>     endBundle
>>
>>     bundle ex:run2
>>      activity(ex:a2, 2011-11-17T10:00:00,2011-11-17T17:0:00)  //duration: 7hours
>>      wasAssociatedWith(ex:a2,ex:Bob,[prov:role="controller"])
>>     endBundle
>>      
> The important bits above (though, the context is useful), are that :run1 mentions ex:Bob and :run2 mentions the same ex:Bob.
>
>    
>> A performance analysis tool rates the performance of agents (this could be used
>> to dispatch further work to performant agents, or congratulate them, etc).
>>
>>
>>     bundle tool:analysis01
>>
>>       agent(tool:Bob1, [perf:rating="good"])
>>       hasProvenanceIn(tool:Bob1, ex:run1, ex:Bob)  // Bob performance in ex:run1 is good
>>
>>       agent(tool:Bob2, [perf:rating="bad"])
>>       hasProvenanceIn(tool:Bob2, ex:run2, ex:Bob)  // Bob performance in ex:run2 is bad
>>
>>     endBundle
>>      
>
> I guess all of that is important bits :-)
> I think the diagram illustrates its relation to the original run bundles nicely (:bob, tool:bob_1 and tool:bob_2).
>
>    
>> The performance analysis tool has to rate two involvements of ex:Bob in two separate activities.
>> Two specialized version of ex:Bob are defined: tool:bob1 and tool:bob2, with rating good and
>> bad respectively.
>>      
> I'd like to note that for this example, specializationOf __is__ appropriate,
> since the evaluator __cares__ about the distinction between "good bob on the 16th" and "bad bob on the 17th",
> while the original asserter __did_not__ care about the difference. (Though, this does demonstrate the great value of the two relations).
>    
> But, in general, only alternateOf should "fall out" of a hasProvenanceIn assertion (which I think should be reduced to isTopicOf, letting alternateOf to be asserted directly on its own).
> An additional benefit of "decomposing" hasProvenanceIn is that we don't have to argue about which one (alternateOf or specializationOf) "falls out" -- it's left to the asserter to determine.
>
>    
>> tool:Bob1 is linked to ex:Bob in run1, and tool:Bob2 is linked to ex:Bob in run2, with the following
>>
>>       hasProvenanceIn(tool:Bob1, ex:run1, ex:Bob)
>>       hasProvenanceIn(tool:Bob2, ex:run2, ex:Bob)
>>      
> Which should be replaced with:
>
> tool:Bob1 prov:alternateOf ex:Bob .
> tool:Bob2 prov:alternateOf ex:Bob .
>
> (really, it should be specializationOf for this example, but decomposing hasProvenanceIn will make that concern moot).
>
>    
>> Nothing is expressed about ex:Bob in bundle tool:analysis01 (except that this is an alias
>> for tool:Bob1 and tool:Bob2).
>>      
> I disagree. As you already point out, ex:Bob is mentioned in your
> "hasProvenanceIn(tool:Bob1, ex:run1, ex:Bob)"
> and my
> "tool:Bob1 prov:alternateOf ex:Bob ."
>
> If a bundle mentions a resource (as subject or object) using any PROV relation, that resource prov:isTopicOf the bundle.
> This is trying to parallel the concept of
>
> "Benjamin Franklin" is mentioned in the book "The private life of the late Benjamin Franklin" [1]
>
> [1] http://archive.org/details/privatelifeoflat00franrich
>
>
>    
I don't think that
tool:Bob1 prov:isTopicOf :run1
is a suitable construct,
since to effectively use this relation, it looks like one needs to
compute all the alternates (and their transitive closure), in the 
subject's bundle
but probably also in the object bundle.

This feature is therefore suitable in a query/reasoning context, but not 
for navigating a data structure.

For this reason, I think it does not belong to a data model.

Furthermore, it looks like similar properties already exist in other 
ontologies. So
they don't seem to have anything provenance specific.  We don't need to 
introduce
them in PROV.

Luc
>> It is suggested that the ternary relation could be replaced by
>> isTopicIn(tool:Bob1, ex:run1)
>> and
>> specialization(tool:Bob1, ex:Bob).
>>      
> I disagree. specialization should be replaced by alternate (when decomposed).
> Again, this disagreement is moot once we get rid of hasProvenanceIn and just use the decomposed forms, where the asserter gets to choose their own alternateOf or specializationOf.
>
>    
>> I don't understand the point of
>>   isTopicIn(tool:Bob1, ex:run1)
>> since tool:Bob1 is not a topic in ex:run1.
>>      
> I think this is a reasonable concern.
>
> e.g., If I talk about the color of the shirt that you were wearing at F2F1 day 1 at 10:30:04.5466 EST, and I used<luc_on_july_6_2011>  as the URI,
>       am I not mentioning __you__ (the ex:Bob in your current example, or, more concretely<http://data.semanticweb.org/person/luc-moreau>)?
>
>
>
> So, if
>
> isTopicOf(:topic, :bundle), then
>
> either
>
> :topic is mentioned in :bundle
>
> or
>
> $$ :topic prov:isSpecializationOf ?general $$ is mentioned in :bundle.
>
> (or probably alternateOf, I'm not sure in the general case beyond this example.)
>
>
>
> However, this uninformative (though, intuitive) inference can be avoided if we just decompose hasProvenanceIn and let the asserter assert it in a way that avoids your confusion:
>
> tool:analysis01 {
>      tool:Bob1
>          pref:rating "unbelievably terrible; horrendously appalling";
>          prov:alternateOf ex:Bob;
>      .
>      ex:Bob prov:isTopicOf :run1 . # This I think you'd agree with, since ex:Bob appears in :run1
> }
>
>
>    
>> Also, we now seem to have made ex:Bob a topic of tool:analysis01, because
>> the following expression.
>> specialization(tool:Bob1, ex:Bob).
>>      
>
> Absolutely.
>
>
>    
>>  From tool:analysis01, where do I find provenance about ex:Bob?
>>      
> You find it in your statement (which "falls out" of hasProvenanceIn, but would be directly asserted by the asserter):
>
> specialization(tool:Bob1, ex:Bob).
>
> ^^^^^ This is provenance about ex:Bob. We found it in bundle tool:analysis01
>
> But I think you're asking about finding _more_ provenance about ex:Bob, which is in :run1 and :run2.
> That is achieved from the following PROV from the particular bundle:
>
> tool:analysis01 {
>      tool:Bob1
>          pref:rating "unbelievably terrible; horrendously appalling";
>          prov:isTopicOf :run1;         # When you go into :run1, look for tool:Bob1.
>          prov:alternateOf ex:Bob;   # When you go into :run1, also look for ex:Bob.
>
>          # Or if you did:
>          prov:specializationOf ex:Bob;   # When you go into :run1, also look for ex:Bob.
>      .
> }
>
>
>
>    
>> It look like this has become a dead end in this graph.
>>      
> If one does not apply alternateOf and specializationOf inferences, yes.
>
>    
>> Do I need to introduce:
>>   isTopicIn(ex:Bob, ex:run1)
>>   isTopicIn(ex:Bob, ex:run2)?
>>      
> That would get you there as well.
> It's true. But I'd encourage the perspective given in the example above, since it "defers description of ex:Bob" to where bob is actually described.
>
>    
>>
>> So now we would  have:
>> isTopicIn(tool:Bob1, ex:run1)
>>      
> ^^^ I'd disagree with this one. run1 isn't talking about the specialized (good) bob; it's just talking about the general bob.
>
>    
>> specialization(tool:Bob1, ex:Bob)
>> isTopicIn(tool:Bob2, ex:run2)
>>      
> ^^^ I'd disagree with this one. run1 isn't talking about the specialized (bad) bob; it's just talking about the general bob.
>
>    
>> specialization(tool:Bob2, ex:Bob)
>> isTopicIn(ex:Bob, ex:run1)
>> isTopicIn(ex:Bob, ex:run2)
>>
>> Which means that:
>>
>> specialization(tool:Bob1, ex:Bob)
>> isTopicIn(ex:Bob, ex:run2)
>>
>> ... would lead us to believe that good rating is due to slow performance.
>>      
> Aha!
>
> Attributes don't "climb up" the specialization hierarchy.
> What goes on tool:Bob1, stays on tool:Bob1 and does NOT go on ex:Bob.
> That's why the asserter of tool:analysis01 made the specialization in the first place.
>
>
>
>    
>> Can the proposer of the separate binary relations explain how this example can work?
>>      
> Do I have anybody else on my team? ;-)
>
> Best,
> Tim
>
>    
>> Thanks,
>> Luc
>>
>>
>>      
>

Received on Monday, 4 June 2012 08:58:53 UTC