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

Re: PROV-ISSUE-260 (TLebo): In Note section: cite prov:Provenance as better practice to annotate assertions. [prov-dm]

From: Timothy Lebo <lebot@rpi.edu>
Date: Sat, 3 Mar 2012 18:40:34 -0500
Cc: public-prov-wg@w3.org
Message-Id: <328E34D3-89E0-499F-A1AD-2BFEA330B0B0@rpi.edu>
To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Hi, Luc,

On Feb 24, 2012, at 4:32 AM, Luc Moreau wrote:

> Hi Tim,
> 
> Comments below.
> 
> On 02/24/2012 05:33 AM, Timothy Lebo wrote:
>> On Feb 22, 2012, at 5:32 PM, Luc Moreau wrote:
>> 
>>   
>>> Hi Tim,
>>> 
>>> I see some problems with this:
>>> 
>>> - First, we (at F2F2) have moved Account (used to be called AccountRecord) out of prov-dm. So, there is no standardized way of  creating and expressing them.
>>>     
>> We still have "Bundles", which seems to have been renamed to Accounts (again).
>>   
> 
> Bundles were only a word and section title in the prov-dm document. There has been no renaming, I think.
>> Or, alternatively, the constituents of Accounts were removed (e.g., the asserter).
>> 
>>   
> Yes, asserter was dropped, but, the *key* different is that it's not a construct of the data model anymore.
> In the data model, you cannot list the assertions in an account.
>>> - Second, your second account does not seem to have any provenance related term.
>>>     
>> It has an entity(:simon, [reputation = "excellent") assertion.
>> That's in PROV, right?
>>   
> That, yes, is a provenance assertion, but
>   :simon ex:reputation "excellent"
> does not involve anything that is prov related.

It's the trust service's characterization of the existing characterization known as :simon.

> 
>>   
>>> Which means that this is totally outside prov-dm. Which means, this is not an interoperable way of expressing annotation of provenance: this technique become serialization specific.
>>>     
>> see ASN above.
>>   
> 
> The reason why we create entities,
> e.g. :simon a prov:Entity
> 
> is because we want to be able to talk about their provenance.
> I don't think that a trust service wants to talk about the provenance of simon, with an attribute reputation=excellent.

We're slipping into "Thing versus Entity" again.

"talk about the provenance of simon, with an attribute reputation=excellent." is _exactly_ what a trust service wants to do.


> 
> My trust service may want to talk about the provenance of the "excellent" rating, but not of simon.

We're slipping into "Thing versus Entity" again. Leave Simon out of it and focus on :simon, the characterization in bundle :prov_0 (shown just below).

Why would the trust agent want to talk about its own "excellent" rating?
The trust agent wants to talk about :simon (and thus, _does_ in bundle :prov_2 below). Specifically, that :simon has a ex3:reputation of "excellent" .


>   - Third, assuming we really want
>> 
>>> 
>>> :prov_0 {
>>> :simon a prov:Human;
>>> :robbery prov:wasAssociatedWith :simon
>>> }
>>> 
>>> 
>>> :prov_1 {
>>> :simon a prov:Human;
>>>        prov:hasAnnotation [
>>>             a prov:Note; ex3:reputation "excellent";
>>>             rdfs:comment "This is a kludge way to get indirection. Use prov:Provenance instead.";
>>>        ];
>>> }
>>> 
>>> :prov_2 {
>>>  :simon ex3:reputation "excellent" .
>>> }
>>> 
>>> 
>>> I think it's important for annotation to be expressed in the context of the entities where they occur.
>>>     
>> 

...

>>> A trust rating algorithm
>>> may find agent simon "excellent" in prov_1 but "not so good" in prov_0.
>>>     
>>   
> Further comments after your example
>> You want a trust agent to augment another's assertions, within the _original_ context of the first asserter? That leads to a provenance nightmare!
>> You'll never be able to see who said what.
>> 
>> prov:Provenance is an Entity, so that trust agent should leave his iPAWs out of others' assertions.
>> 
>> :prov_1 {
>>    :simon a prov:Human.      # took out the Note, since it muddles who said what.
>> }
>> 
>> :prov_1 prov:wasAssociatedWith :original_asserter .
>> 
>> :prov_1b {
>> :simon a prov:Human;    # The rest of prov_1's assertions are included in prov_1b, too.
>>        prov:hasAnnotation [
>>             a prov:Note; ex3:reputation "excellent";
>>             rdfs:comment "This is a kludge way to get indirection. Use prov:Provenance instead.";
>>        ]; # This Note is now an unnecessary level of indirection, since we're in a new bundle/account/provenance. We can describe :simon directly and know that :trust_evaluator_agent said so.
>> }
>> 
>> :prov_2 prov:wasDerivedFrom :prov_1;
>>               prov:wasAssociatedWith :trust_evaluator_agent .
>> 
>> 
>> Now, we still need to satisfy your "different evals in different contexts" requirement (I'll avoid Notes this time):
>> 
>> :prov_0 {
>> :simon a prov:Human;
>> :robbery prov:wasAssociatedWith :simon
>> }
>> 
>> :prov_0 prov:wasAssociatedWith :original_asserter .
>> 
>> :prov_0b {
>> :simon a prov:Human;  ex3:reputation "not so good" .    # Added the reputation, which is different than the one in :prov_1b
>>   
> To me, we have changed the nature of the assertion, here.
> It is as if the reputation of simon is part of his characteristization.

Exactly!

> 
>> :robbery prov:wasAssociatedWith :simon
>> }
>> 
>> :prov_0b prov:wasDerivedFrom :prov_0;
>>           prov:wasAssociatedWith :trust_evaluator_agent .
>> 
>> 
>>   
> 
> I think there is a granularity problem though, since you have established
> a connection between accounts, and not between the entities across account.

The connection between the entities across the account exists because it is the ___same URI____.
I think your misunderstanding has to do with the TriG syntax. :simon is :simon is :simon is :simon.  
Same URI, regardless of where you find it mentioned.
It's not like XML.

> 
> My trust service may just annotate individuals whose past actions need to be checked (not
> all their past actions, only some).

Yes! Only the "some" actions that are characterized.
Your "annotations" are characterizations of the same entity.
:prov_2 {
 :simon ex3:reputation "excellent" .
}


> Sorry the example here is silly, but it corresponds to a real use case we have.
> 
> :prov_0 {
> :simon a prov:Human;
> :robbery prov:wasAssociatedWith :simon
> 
> :john prov:Human;
> :charityWork prov:wasAssociatedWith :simon

is this a typo? should it be :john?

> }
> 
> :prov_1 {
> 
>   :simon a prov:Human.
>   :workHard prov:wasAssociatedWith :simon
> 
>   :john a prov:Human
>   :NotWorkHard prov:wasAssociatedWith :john
> 
> }
> 
> So, the trust service can flag
> simon's behaviour in prov_0 and
> and
> john's behaviour in prov_1.
> 
> 
> If I have notes, I can add the following annotations

It's rather sloppy to muddle inside someone else's bundle.
I modeled the provenance of the annotated bundle deriving from the original bundle in my original example (perhaps my identifiers misaligned and it wan't clear; I'll add it to the collection).


> to simon in prov_0
> prov:hasAnnotation [
>            :todo1 a prov:Note; ex3:reputation "toCheck";
>       ];
> 
> to john in prov_1
> prov:hasAnnotation [
>            :todo2 a prov:Note; ex3:reputation "toCheck";
>       ];
> 
> I then have the hooks to ... create e.g. a todo list :todo1, :todo2, or what ever.


Can you add this second example to our collection?
I'd like to study it outside of email.
I can give you the same hooks using bundles that would better delineate the provenance among the original observations and the trust agent's assertions.

-Tim


> 
> Luc
> 
> 
>> BTW, Stephen Cresswell is dealing with this kind of meta provenance in case we want to prov:involve a domain user.
>> 
>> 
>> 
>> -Tim
>> 
>> 
>>   
>>> The problem is similar with annotations for graphical rendering: the position given to an element in a given account does not
>>> have to be the same as the position in another account.
>>> 
>>> Luc
>>> 
>>> On 22/02/2012 18:17, Provenance Working Group Issue Tracker wrote:
>>>     
>>>> PROV-ISSUE-260 (TLebo): In Note section: cite prov:Provenance as better practice to annotate assertions. [prov-dm]
>>>> 
>>>> http://www.w3.org/2011/prov/track/issues/260
>>>> 
>>>> Raised by: Timothy Lebo
>>>> On product: prov-dm
>>>> 
>>>> Please add a note to section Note to encourage people to use Account / AccountEntity/ Provenance to annotate provenance assertions as a better practice. When using AccountEntity, the annotated thing can be described _directly_ as a single triple instead of using Notes. Notes are very much "scruffy  provenance" and do not benefit from the directness afforded by AccountEntity / prov:Provenance.
>>>> 
>>>> :prov_1 {
>>>>  :simon a prov:Human;
>>>>         prov:hasAnnotation [
>>>>              a prov:Note; ex3:reputation "excellent";
>>>>              rdfs:comment "This is a kludge way to get indirection. Use prov:Provenance instead.";
>>>>         ];
>>>> }
>>>> 
>>>> :prov_2 {
>>>>   :simon ex3:reputation "excellent" .
>>>> }
>>>> 
>>>> :prov_1 a prov:Provenance; prov:wasAttributedTo :first_asserter .
>>>> :prov_2 a prov:Provenance; prov:wasAttributedTo :trust_evaluator_agent.
>>>> 
>>>> Thanks,
>>>> Tim
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>       
>>> 
>>>     
>>   
> 
> -- 
> Professor Luc Moreau
> Electronics and Computer Science   tel:   +44 23 8059 4487
> University of Southampton          fax:   +44 23 8059 2865
> Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
> United Kingdom                     http://www.ecs.soton.ac.uk/~lavm
> 
> 
> 
Received on Saturday, 3 March 2012 23:41:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:58 GMT