W3C home > Mailing lists > Public > public-prov-wg@w3.org > June 2012

Re: ISSUE-385: hasProvenanceIn: finding a solution

From: Timothy Lebo <lebot@rpi.edu>
Date: Mon, 4 Jun 2012 08:26:33 -0400
Cc: Provenance Working Group WG <public-prov-wg@w3.org>
Message-Id: <6727E55D-D7A3-403B-B835-294FEADC4BBA@rpi.edu>
To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:16 UTC