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

Luc,

I added this example to the collection.

bash-3.2$ cat eg-10-trust-agent-annotation/document/homepage
http://www.w3.org/2011/prov/track/issues/260
http://www.w3.org/2011/prov/wiki/eg-10-trust-agent-annotation

I think it covers your first and second examples in this thread, as well as the one I offered in between.

Can you look it over and make sure it reflects your use case?

Regards,
Tim



On Mar 3, 2012, at 6:40 PM, Timothy Lebo wrote:

> 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 Sunday, 4 March 2012 00:16:07 UTC