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

Re: PROV-ISSUE-471 (wrong-wasAttributedTo-constraints): wasAttributedTo constraints not sensical [prov-dm-constraints]

From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Date: Mon, 3 Sep 2012 17:09:16 +0100
Message-ID: <CAPRnXtkmTMd4etPWR6M9gb+L6v8NebDJPsTWEcr=4F1TJVPOAQ@mail.gmail.com>
To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
Cc: public-prov-wg@w3.org
On Mon, Sep 3, 2012 at 2:53 PM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote:
> I suggest the constraints becomes as follows:
> IF wasAttributedTo(_at;e,ag,_attrs) and
> wasInvalidatedBy(invE;e,_a1,_t1,_attrs1) and
> wasGeneratedBy(genAg;ag,_a1,_t1,_attrs1) THEN genAg precedes invE

Although this laxer constraint would still be 'true', I wonder then
about the point of this:

> Inference 13 (attribution-inference)
> IF wasAttributedTo(_att; e,ag,_attrs) THEN there exist a, _t, _gen, _assoc, _pl, such that wasGeneratedBy(_gen; e,a,_t,[]) and wasAssociatedWith(_assoc; a,ag,_pl,[]).

If I assume for the argument that wasAttributedTo also covers any kind
of ownership (which as you know I don't approve of ;) ), then I
struggle with the above inference, as this forces the agent to also be
involved with the *generation* of that entity. If I buy a car, then
yes, I might be involved in the "purchasing" activity, which you can
say is what generated the StiansCar entity. (which lives for as long
as it has the characteristic of being owned by me -  note that this
sounds more like attributes and entity characterisation) - but is this
true for any kind of ownership? If I inherit a massive castle, or I
have received in the mailbox (in a house I have just moved in to) a
2013 calendar from a local shop, am I then 'attributed to' the castle
or the calendar, and required to be associated with the activity that
made me the owner?

Should it then not a requirement be for the agent to be involved with
the activity before the entity was generated? Your proposed constraint
(as quoted above) would allow the agent to come to life just before
the invalidation of the entity, get a brief ownership (duration of
which we don't know), and then let the entity invalidate.  It is OK
with the wasAssociatedWith-ordering rule as long as the activity that
generated the entity is still running at this point, for instance that
the factory is still making cars or the postman still doing his

This sounds a bit odd for me. It should be one way or the other.  The
time ordering constraints should cover, ideally, exactly what is
required, not allow various scenarios we do not intend to be legal.

If the ownership is true for the whole lifetime of the entity (which I
would presume!), then that is an attribute that I would see in the
entity, not as a separate statement. If it is still to be said as a
statement, then we need boundary conditions on both sides, just like
we say attributes are valid all the way from the generation till

My proposal is to keep the current definition:

> Constraint 50 (wasAttributedTo-ordering)
> IF wasAttributedTo(_at; e,ag,_attrs) and wasGeneratedBy(gen1; ag,_a1,_t1,_attrs1) and wasGeneratedBy(gen2; e,_a2,_t2,_attrs2) THEN gen1 precedes gen2.
> IF wasAttributedTo(_at; e,ag,_attrs) and wasStartedBy(start; ag,_e3,_a3,_t3,_attrs3) and wasGeneratedBy(gen; e,_a4,_t4,_attrs4) THEN start precedes gen.

(Note: There are two rules, depending on the agent being an entity or
an activity. We can't time-order non-entity, non-activity agents).

This says that the agent must be involved in the generation of the
entity. We do not have time stamps on association, but the intention
is that he was associated before entity generation. This must be true
- from the above - also for the case of ownership.

The agent is not required to be involved with its invalidation, but we
know that the the invalidation must be after his generation, because
of the combination of constraint generation-precedes-invalidation and

Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
Received on Monday, 3 September 2012 16:10:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:18 UTC