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

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

From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Date: Fri, 24 Feb 2012 09:32:59 +0000
Message-ID: <EMEW3|5ffbca018fa5ed68ca3d9ccbd0812ff4o1N9X208L.Moreau|ecs.soton.ac.uk|4F47594B.6030009@ecs.soton.ac.uk>
To: Timothy Lebo <lebot@rpi.edu>
CC: public-prov-wg@w3.org
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.

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

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


>    
>> - 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.
>>      
> Now, you are showing _your_ serialization bias :-)
> Both prov:Note and prov:Provenance solutions have explicit, logical connections.
> What you see to be "out of context" , _actually_is_ in the context (a rdf1.1:Dataset - a union of graphs)
> So "in context" isn't a reason to use Note over Provenance because they both provide it.
>
>    

... there are lots of bias, and we are trying to find a reasonable 
compromise.
>> 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.

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

My trust service may just annotate individuals whose past actions need 
to be checked (not
all their past actions, only some).
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
}

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

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 Friday, 24 February 2012 09:33:33 GMT

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