Re: ISSUE-385: hasProvenanceIn: finding a solution

(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

> 
>    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


> 
> 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 Friday, 1 June 2012 15:07:40 UTC