Re: ISSUE-385: hasProvenanceIn: finding a solution

Simon did a great job explaining how this all comes together, I'd go with
his version.

Jim

On Fri, Jun 1, 2012 at 11:07 AM, Timothy Lebo <lebot@rpi.edu> 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
>
> >
> >    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
> >
> >
>
>
>


-- 
Jim McCusker
Programmer Analyst
Krauthammer Lab, Pathology Informatics
Yale School of Medicine
james.mccusker@yale.edu | (203) 785-6330
http://krauthammerlab.med.yale.edu

PhD Student
Tetherless World Constellation
Rensselaer Polytechnic Institute
mccusj@cs.rpi.edu
http://tw.rpi.edu