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

Re: PROV ISSUE-206 some possible proposals

From: Timothy Lebo <lebot@rpi.edu>
Date: Mon, 6 Feb 2012 21:03:50 -0500
Cc: Paul Groth <p.t.groth@vu.nl>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Message-Id: <8B754BE2-AEC6-4567-BF05-F0EE1E153DBE@rpi.edu>
To: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>

On Feb 6, 2012, at 8:38 PM, Stian Soiland-Reyes wrote:

> On Mon, Feb 6, 2012 at 22:44, Timothy Lebo <lebot@rpi.edu> wrote:
>> Is it because we wouldn't be able to distinguish this "cause" from the other instances of energy, network traffic, reading time etc. that were also used during the debate?
> Ah, but that could be clarified with a special role, right? That would
> also cover the push-driven dataflow examples, where an activity is
> started by its input arriving.
> We can call this role prov:Initiator or something:
> :flameWar a prov:Activity ;
>  prov:hadQualifiedUsage [
>     a prov:Usage
>     prov:qualifiedEntity :anEmail ;
>     prov:role prov:Initiator .
> ] .

I very much like this. What is it's unqualified form?

:flameWar prov:initiatedBy :anEmail .

> My only question would be - can a non-agenty entity (who is not
> wasAssociatedWith the activity) be initiating the activity, but still
> not being considered 'used'? I have a feeling not.

Quite a few nots in there...

Are you saying that everything going in to in an activity must be either a responsible agent OR a non responsible thing BUT NOT BOTH?

>> I say let "wasAssociatedWith" do what it was intended - to assign responsibility to agents.
> OK, but I liked the idea of associating entities with an activity
> which are not as easily 'used', but are more present and form some
> kind of frame for the activity, without necessarily having
> responsibility. Do we need such a concept - and should it be called
> something else - or is that simply covered by used?

despite the name, I'd say it's covered by "used"

The ball I threw at Khalid was used by the Assault activity.
And I can use it again if Daniel steps out of line... ;-)

I think "used" is the catch all for "stuff that went into this activity", but I like what you point out: An innocent bystander may have NOTHING to do with an Activity. The same would have happened whether the bystander was there or not. This bystander doesn't seem to be "used" by the Activity, but is certainly part of the "situational context" in which the activity occurred.

> Example: Execution of a C program. It prov:uses some text files and a
> connection to a web server. On a lower granularity perhaps,
> /lib/libc.so.6 (the C standard library) is prov:associatedWith with
> the programme. The asserter does not feel that *his* C program is
> *using* libc - that is merely an side-effect of the compiler and
> operating system.  It is not an agent, it is not like a Python
> interpreter responsible for running a script, it is just there for
> those boring system calls. However the asserter wants to link this
> stronger than just as some custom attribute on the plan-entity for the
> C-program-activity.
> The reason is that a concurrent system upgrade overwrites the
> /lib/libc.so.6 file (and this is captured by provenance) , and causes
> the C programme to crash.
> :libc a prov:Entity, :CLibrary ;
>  prov:location "/lib/libc.so.6" .
> :myProgramme a prov:Entity, :ProgramBinary ;
>  prov:location "/usr/local/bin/my" .
> :exec a prov:Activity, :ProgramExecution;
>  prov:hadPlan :myProgramme ;
>  prov:wasAssociatedWith :libc .
> :segmentationFault a prov:Entity, :ProgramError ;
>  prov:wasGeneratedBy :exec .
> :upgrade a prov:Activity, :ProgramExecution ;
>  prov:used :libc .
> I did not specify any prov:SoftwareAgent up here, because agents are
> currently disjoint from activities, and so the active :exec can't be
> an agent - while the dormant entity :myProgramme can.

That's some example. Too bad we're not collecting examples somewhere...
So what property do you feel is missing that this example demands?

Received on Tuesday, 7 February 2012 02:07:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:07 UTC