[provo] Re: Difference between wasInformedBy and wasStartedByActivity (ttl examples)

Given this discussion below, I had to go again to the definitions and 
constraints in prov-dm to remind myself of the difference between 
wasInformedBy and wasStartedByActivity.

I didn't follow closely on the email exchange made on the mailing list 
in this respect. However, here are my thoughts. Please let me know if 
you share the same impression.

* To me wasInformedBy is justified and we should not have trouble in 
finding good examples. That said, I don't like the wording of the 
definition in the PROV-DM.

In prov-dm, it is stated that:
" A communication implies that activity a2 is dependent on another a1, 
by way of some unspecified entity that is generated by a1 and used by a2."

I don't understand why  the entity should be unspecified. I can 
understand that it may not be specified. So, I would have prefer a 
definition in the following lines:

"A communication implies that activity a2 is dependent on another a1, by 
way of some entity, which may not be specified, that is generated by a1 
and used by a2."

For illustration purposes, in the example, we should I think be explicit 
about the entity in question, so that the user get the semantics of 
wasInformedBy.

* Regarding wasStartedByActivity, I don't think its definition is 
intuitive, and I am not sure if this relation (property) will be useful 
in practice, and even when it is used, I fear that it will be misused. 
We used the same example as in the dm, i.e., a workflow triggering a 
subworkflow. According to the defintion, for wasStartedByActivity to 
hold, an entity that is generated by one activity will start the second 
activity, I wonder what would that entity be in the case of workflow 
triggering a subworkflow. So I think we should not use this example, 
even though it is used in the dm. Another example that we can use is as 
follows:

:letterRespection a prov:Activity .
:accidentNotification a prov:Entity .
:accidentNotification prov:wasGeneratedBy :letterReception .

:insurranceClaim a prov:Activity ;
     prov:wasStartedBy :accidentNotification ;
     prov:wasStartedByActivity :letterReception .

What do you think?

khalid

On 03/05/2012 10:48, Stian Soiland-Reyes wrote:
> On Thu, May 3, 2012 at 9:47 AM, Jun Zhao<jun.zhao@zoo.ox.ac.uk>  wrote:
>>> So shall we make my fuel warning example the wasStartedByActivity
>>> example instead of the current workflow-execution example (where the
>>> implied entity would be difficult to identify, what about the workflow
>>> enactor agent, etc)? I believe it would fit well as it's easy to
>>> understand the implied entity (the warning), and as you point out
>>> there is no information passed over beyond the entity being present.
>> +1
> OK, proceeding.
>
> I've changed the activities to :observing-low-fuel to avoid confusion
> with agency - it's now the driver observing and filling - rather than
> making it look like it was the fuel lamp who was filling.
>
> (By the definition, wasStartedByActivity does not require any shared
> agency - and the old example should be fine with wasStartedByActivity
> - but it could be confusing by the literal reading of 'was started
> by').
>
> I've committed both of these.
>
>
>
>> How about reworking your wasStartedByActivity.ttl example
>> (->wasInformedBy.ttl), but explicitly stating some data that triggered the
>> execution of the sub-workfow. I can work on this if you want, after you did
>> your updates.
> OK, so we say the subworkflow was using some data generated by the
> main workflow. But then.. what is the value of the
> wasInformedByActivity statement? It would just be restating something
> anyone could infer.
>
>
> wasInformedByActivity would only make sense to me if the data is not
> stated. So for instance
>
> :writing-celebrity-gossip prov:wasInformedBy :voicemail-interception .
>
> We don't know which message was intercepted - but we know something
> came out of that voicemail and influenced the gossip.
>
> (I've added this to property_wasInformedBy and friends instead of the workflow)
>
>