Re: PROV-ISSUE-651: 3 comments on prov-o (wasDerived, wasAttrib, actedOnBehalf)

Thanks, Simon.

I've included them.


On Mar 14, 2013, at 10:21 AM, "Miles, Simon" <> wrote:

> Hello,
> The response looks good. I might add:
> An activity having used an entity and generated another, does not necessarily mean that the latter entity was derived from the former. So adding a dummy activity actually conveys less information than wasDerivedFrom.
> It is important that provenance describes the past, regardless of the level of detail expressed. actsOnBehalfOf would incorrectly imply that the delegation relationship holds currently. This might or might not be the case, but is not part of provenance, so not expressible in PROV.
> thanks,
> Simon
> Dr Simon Miles
> Senior Lecturer, Department of Informatics
> Kings College London, WC2R 2LS, UK
> +44 (0)20 7848 1166
> Efficient Multi-Granularity Service Composition:
> From: Timothy Lebo []
> Sent: 14 March 2013 13:57
> To: Provenance Working Group
> Subject: Re: PROV-ISSUE-651: 3 comments on prov-o (wasDerived, wasAttrib, actedOnBehalf)
> prov-wg,
> I've drafted a response to Jacobo's comments at:
> Any comments welcome.
> Regards,
> Tim
> On Mar 14, 2013, at 9:13 AM, Provenance Working Group Issue Tracker <> wrote:
>> PROV-ISSUE-651: 3 comments on prov-o (wasDerived, wasAttrib, actedOnBehalf)
>> Raised by: Timothy Lebo
>> On product: 
>> Hello,
>> I have been looking at PROV-O and I intend to use or extend it for a
>> project where we need provenance metadata for named rdf graphs. I have
>> a “triple” of suggestions that come from vocabulary restrictions I
>> have thought of for my own use, but since I see the vocabulary is
>> still in a CR stage, I have decided to expose them for the case they
>> might be included in the base vocabulary. However, I must say I am
>> quite a newcomer into RDF and related technologies, so I might well be
>> very wrong.
>> 1. I wonder if instead of the wasDerivedFrom property, a dummy
>> instance of Activity could always be used to connect the original and
>> obtained entities, even without further properties. This would make
>> modeling more homogenous, which might make things easier for automated
>> tools, and would be straightforward to add information about the
>> activity if it was discovered in a later stage, without the need of
>> removing triples. I think these advantages and the reduction of the
>> vocabulary make up for the overhead in extra nodes.
>> 2. The existence of wasAttributedTo seems unnecessary to me, as we
>> already can express the same with wasAssociatedWith from the Activity
>> that led to the Entity. I am aware that without cardinality
>> constraints between Activity and Entity, an activity can generate
>> several Entities and therefore an Agent involved in an Activity is not
>> necessarily involved in one of its generated Entities. But maybe this
>> would be a reason to consider introducing cardinality constraints, as
>> activities that generate several Entities can usually be divided into
>> more specific Activities that only lead to one Entity. So Activities
>> that generate several Entities could be modeled as a higher level
>> resource that aggregates several activities. I know in this way you
>> remove a term to introduce another one, but you get rid of the
>> semantic overlapping and possible redundancy between wasAttributedTo
>> and wasAssociatedWith.
>> 3. The unqualified relation actedOnBehalfOf, since it is independent
>> of the activity, it becomes a general or "atemporal" property of the
>> agent and should be better named actsOnBehalfOf.
>> Best regards,
>> Jacobo Rouces.

Received on Thursday, 14 March 2013 14:26:39 UTC