- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Thu, 05 Jan 2012 13:55:08 +0000
- To: public-prov-wg@w3.org
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 perspectives 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 accounts. Using prov-aq, I may retrieve the provenance of entity e1, and obtain: acc(ex:a1, http://ex/asserter1, entity(e1,[...]) ...) Again, using prov-aq, I may retrieve the provenance of entity e2, and obtain: acc(ex:a1, http://ex/asserter1, entity(e2,[...]) ...) Same account in the sense that it is generated by http://ex/asserter1 and named ex:a1, but different subset of records. 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: :e1 prov:wasComplementOf :e1; Shouldn't it be e0? :e1 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 asserted about e0 in account3. 6. In your example, is it problematic or not, to have two different entity records containing the same entity identifier? :a0 dcterms:description "activity(a0,t,,[prov:type='createFile'])"; a prov:Activity; a :CreateFile; :a0 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? Luc 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] http://www.w3.org/2011/prov/wiki/Using_graphs_to_model_Accounts > [2] http://www.w3.org/2011/prov/wiki/Meetings:Telecon2012.01.05 > > > -- 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 Thursday, 5 January 2012 13:55:39 UTC