- From: Timothy Lebo <lebot@rpi.edu>
- Date: Mon, 4 Jun 2012 08:26:33 -0400
- To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Cc: Provenance Working Group WG <public-prov-wg@w3.org>
- Message-Id: <6727E55D-D7A3-403B-B835-294FEADC4BBA@rpi.edu>
Luc,
On Jun 4, 2012, at 4:58 AM, Luc Moreau wrote:
> 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,
I think that's fair.
> 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).
Notice the "same URI" edge between the two visual nodes :bob (:run1) and :bob (in :run2).
I think this pro ides the "should" conditions that you just described.
http://www.w3.org/2011/prov/wiki/Eg-33-a-simpler-hasProvenanceIn
>>
>>
> 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
"one needs" -> "one may need" (depending on how it was asserted)
> compute all the alternates (and their transitive closure), in the subject's bundle
> but probably also in the object bundle.
In the "worst case", yes.
Though, this "worst case" for a data model is the "best case" for any consumer trying to find out about provenance.
>
> This feature is therefore suitable in a query/reasoning context, but not for navigating a data structure.
I don't see these as competing contexts. I see the data model context a simple case of the query/reasoning context.
We only need to provide the data model construct, which will permit the more general (and, realistic) situation.
>
> 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.
Yes. As I've said, I'm can already do this bundle linking with dcterms:isReferencedBy.
So, where do you see hasProvenanceIn(xargs) standing?
Regards,
Tim
>
> 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 12:27:11 UTC