Re: Towards PROV-O Accounts

Hi Tim,

Thanks for your document on using graphs to model accounts.

There is a few issues that I think we should discuss since they
potentially represent substantial differences with prov-dm.

1. I have a problem with your statement:

    An Account is an Entity that was generated by an asserter during an
    assertion activity.

  This is not what prov-dm states at all.

  Indeed, an account is a "thing in the world". We can then take
  multiple perspectives about that thing, which we can represent as
  entities for provenance purpose.  Having done that, then we can talk about
  the provenance of an account.

  There maybe multiple ways of looking at a given account acc:
   - what account acc tells us about entity e
   - acc with suitable anonymization
   - acc with a cryptographic signature
   - etc

   It is up to the provenance asserter to decide how to assert entities
   and we can't do that for them.
   That's why it is not right to say that an account *is* an entity.

   However, an account is a thing in the world and we can define 
   on it as entities.

2. Currently an asserter is not modelled as an agent.  There is a note
    to that effect. Nobody has come back to this point.  Until we firm
    up this issue, we won't be able to decide whether your modelling is
    correct or not.

3. I agree with you that if we have an entity for an account, we can
    also explain how it is generated, etc.

    Maybe, it's easier to use attributionm rather than introduce 
activity types.

     wasAttributedTo ( eIdentifier , agIdentifier 
optional-attribute-values )

4. I can't decide whether your graph hash is central to your encoding
    or not. If it is part of the design, it doesn't match my view of 

    Using prov-aq, I may retrieve the provenance of entity e1, and obtain:


    Again, using prov-aq, I may retrieve the provenance of entity e2, 
and obtain:


    Same account in the sense that it is generated by
    http://ex/asserter1 and named ex:a1, but different subset of

    It's important to support that use case, since in that case, those
    two account instances are telling us that they are the same, coming
    from a same asserter, and can be merged without conflict (if the
    original full account was without conflict).

    I don't know how these hashes work, given that these account examples
    contain different records.

5. Your nested account example:

   In acc4_claims, you write:
       prov:wasComplementOf :e1;

   Shouldn't it be e0?
       prov:wasComplementOf :e0;

     How do you find which entity record this actually is?

    To be compliant with prov-dm, you should probably encode the example as

    :e1, ex:acc4
       prov:wasComplementOf :e0 , ex:acc3;

    meaning was is asserted about e1 in account4 wasComplementOf what is 
    about e0 in account3.

6. In your example, is it problematic or not, to have two different
    entity records containing the same entity identifier?

       dcterms:description "activity(a0,t,,[prov:type='createFile'])";
       a prov:Activity;
       a :CreateFile;

       dcterms:description "activity(a0,t,,[prov:type='copyFile'])";
       a prov:Activity;

     If no, than that's great. What is your concern with scope then?
     If yes, than what is the exact problem?


On 01/05/2012 03:35 AM, Timothy Lebo wrote:
> prov-wg,
> I have been working on some discussion [1] that is relevant to modeling Accounts in PROV-O.
> It is incomplete, but I think ready for some initial feedback.
> Modeling accounts is on the agenda for tomorrow's telecon [2], so I hope this can provide some discussion material.
> Regards,
> Tim
> [1]
> [2]

Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email:
United Kingdom           

Received on Thursday, 5 January 2012 13:55:39 UTC