- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Tue, 7 Feb 2012 01:38:45 +0000
- To: Timothy Lebo <lebot@rpi.edu>
- Cc: Paul Groth <p.t.groth@vu.nl>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
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 . ] . 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. > 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? 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. -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester
Received on Wednesday, 8 February 2012 21:58:28 UTC