- 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