- From: Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk>
- Date: Sat, 16 Jul 2011 18:58:06 +0100
- To: reza.bfar@oracle.com
- CC: public-prov-wg@w3.org
- Message-ID: <4E21D12E.8030304@cs.man.ac.uk>
Thanks Reza for the clarification. I still don't see the problem to be honest with you. If, as Simon suggested in the last telecon, we have a placeholder for agent, and the user adopt the definition of agent that they want, e.g., in your case, the agent will have a property that define the type of the agent, would you still have problem in the scenario you described below? Thanks, khalid On 16/07/2011 18:03, Reza B'Far wrote: > Khalid - > > I had told folks that I'd drop the thread, but since you're new on the > thread, here is the concrete use-case: > > A file is created and then modified. The modifications can be made by > a bunch of scripts, automated programs, etc. such as back-up programs, > automated merge programs, etc. or it can be made by a human being. > In practical use-cases that at least I'm concerned about, the > automated mods are treated completely differently than those made by a > human being. There are practical concerns (such as scalability, > usability, etc.) where you want to fundamentally differentiate between > the types. Now, let's assume we stay generic. The issue with that > becomes than an import/export becomes lossy. In other words, the gap > in the definition of agent is so large, that I can export my data and > import it back in without losing a bunch of semantics (unless I hack > it up with a bunch of extension). My contention on this thread was > that this use-case is fundamental, but, as previously stated, other > folks seem to disagree. > > Best. > > On 7/16/11 4:17 AM, Khalid Belhajjame wrote: >> Hi Reza, >> >> I believe you have reasons why we should specify the sub-types of >> agents, but I must admit I don't see them yet and would like to >> understand them. >> In particular, I am struggling to see what agent subtyping will add >> from provenance point of view. For example, are there cases in which >> provenance queries will treated differently depending on whether the >> agent is a human or a software. >> >> Thanks, khalid >> >>> >>> From an implementation perspective, and regardless of domain, unless >>> what you're saying is to completely rule out commercial software >>> products (again, I state, regardless of domain) which require core >>> features such as import and export without data loss, then you have >>> to provide some strong typing. And you can't just create some >>> generic entity and ask people to go implement their own specific >>> types as you will create (I would claim force) incompatibilities >>> between different implementers which will make the standard >>> completely useless. >>> >>> Having said that, I'm not even sure how the domain comes into play >>> here. Please read what I said previously, I'm going to restate it >>> at the end of my email by re-pasting since this is something that >>> any product implementer will feel strongly about. Please note that >>> the concepts of "Human agent", "System agent", "Trusted agent", >>> "Untrusted agent", etc. have NOTHING to do with domain. I can post >>> a half-a-dozen IEEE papers here about agents. >>> >>> In one sentence summarized - The request to consider here is to >>> either reduce the scope of agent to something like User-Agent which >>> is used in many other W3C standards such as HTML or to accommodate >>> stronger types as mentioned here (and hopefully we have enough >>> domain participants here that we can create a domain-independent >>> sub-typed system by consensus) >>> >>> Please read re-post below >>> --------------------------------- >>> 1. The distinction between the direct intervention of a human being >>> effecting the state of a data versus an indirect intervention is >>> absolutely crucial. Without this, establishing "trust" (I mean >>> this from a formal perspective - something like PACE[1]) >>> 2. I personally would lean towards one of the following options - >>> * Strong Typing of the Agent to multiple types and specifying >>> exactly what we mean by the types. For example, /Human >>> Agent, System Agent/, etc. I've mentioned this in a >>> previous thread. Within all practical usages of provenance >>> that at least I'm concerned with, there are completely >>> different treatments of a "snapshot" (or whatever you want >>> to call it) of the state of an entity (which would be >>> considered something that is included in provenance) based >>> on whether or not there is direct human intervention (or >>> alternatively, far more specification and strong typing) of >>> the changes. "Agent" is way to generic to be useful >>> practically. >>> * Reducing the use-cases of Agent to just User-Agent which is >>> the approach that is used in some of the other W3C >>> standards >>> and is weaved into the fabric of www as we know today. >>> This >>> would reduce the scope of what an "Agent" is. We may >>> possibly be able to leverage work of UAProf[2] and even if >>> not, we can learn from UAProf and CC/PP as examples. >>> 3. The key of both (1) and (2) above is that we in order to have a >>> practical implementation, it is highly desirable to have some >>> very >>> exact meaning for what "Agent" is, what it does, what the >>> boundary >>> conditions are, etc. I also highly encourage that we do NOT >>> include concepts that start going into RBAC and other security >>> related standards such as Role. IMO, we need to reuse concepts >>> from these standards. >>> >>> I'm relatively new to the group, but have spent a lot of time >>> reading the archives. From an implementation perspective, I caution >>> that if things are too generic and there is not enough specification >>> (typing) and exactness in order to accommodate a larger tent, there >>> may be long term implementation hurdles that are presented in terms >>> of practical implementation. In terms of a specific example, I >>> think "Agent" above is one. It's far too generically defined at >>> this point, IMO. >>> >>> Please see references below. >>> >>> [1] - PACE - >>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.58.8965, >>> http://www.mendeley.com/research/architectural-support-trust-models-decentralized-applications/ >>> >>> [2] - UAProf - http://en.wikipedia.org/wiki/UAProf >>> [3] - CC/PP - http://www.w3.org/Mobile/CCPP/ >>> >>> On 7/14/11 9:27 AM, Satya Sahoo wrote: >>>> Hi, >>>> I agree with Lena here. Subtypes of agents are domain dependent and >>>> I don't think we should define them in WG provenance model. >>>> >>>> Regarding Reza's point, our current "definition" of agent (by >>>> direct assertion or involved in process execution) does not (seem >>>> to) prevent particular domain users/developers from creating more >>>> specific sub-types of agent (s/w agent, enzymes, anti-bodies, >>>> sensors, researcher, legal analyst etc.) >>>> >>>> Thanks. >>>> >>>> Best, >>>> Satya >>>> >>>> On Thu, Jul 14, 2011 at 12:08 PM, Deus, Helena >>>> <helena.deus@deri.org <mailto:helena.deus@deri.org>> wrote: >>>> >>>> Hi Luc, >>>> >>>> I agree, agent subtypes are important. But are they not also >>>> domain dependent? >>>> >>>> Yes, in regard to your question – a catalyst, an enzyme are in >>>> fact agents. >>>> >>>> >>>> Best >>>> >>>> Lena >>>> >>>> *From:*public-prov-wg-request@w3.org >>>> <mailto:public-prov-wg-request@w3.org> >>>> [mailto:public-prov-wg-request@w3.org >>>> <mailto:public-prov-wg-request@w3.org>] *On Behalf Of *Luc Moreau >>>> *Sent:* 14 July 2011 16:21 >>>> *To:* public-prov-wg@w3.org <mailto:public-prov-wg@w3.org> >>>> *Subject:* PROV-ISSUE-4: agent subtypes? >>>> >>>> Hi Reza, >>>> >>>> Yes, it's a good idea to discuss agent subtypes as a separate >>>> thread. >>>> >>>> >From my point of view, I want to be sure that we don't >>>> disallow some kind of agents, simply >>>> because we had not thought about them. >>>> >>>> I believe that from a biology/chemistry point of view, a >>>> catalyst could be seen as an agent. >>>> >>>> Views on this? >>>> >>>> Regards, >>>> Luc >>>> >>>> >>>> On 07/13/2011 07:41 PM, Reza B'Far wrote: >>>> >>>> Graham - >>>> >>>> Thank you for your thorough response. Please note the following: >>>> >>>> 1. I'm completely fine with sub-typing. As long as the more >>>> concrete types (some more exact definitions of agent) are >>>> available, I'm fine with them "inheriting" from more >>>> generic types. My chief concern as an implementer is to >>>> make sure that there is enough "typing" available so that >>>> there is no loss of data in the export/import process >>>> that can be avoided. *_So, is the next step creation of a >>>> new email thread for sub-typing Agent?_* >>>> >>>> >>>> On 7/12/11 11:48 PM, Graham Klyne wrote: >>>> >>>> Reza, >>>> >>>> I have two main responses to your comments: >>>> >>>> (1) your description of "Agent" here seems to me to be closer >>>> to what the provenance work has envisaged than that described >>>> in ws-arch document mentioned by Ryan. >>>> >>>> (2) I fully accept your need for volitional vs computational >>>> agent distinction for establishing certain kinds of trust in >>>> data. But I still think that a generic agent class would keep >>>> things simpler for developers who are not so concerned with >>>> specific legislative or similar frameworks - I think it's >>>> easier to subclass a generic class as needed than to unite >>>> distinct classes. >>>> >>>> Given that yours is a concrete use-case addressing a real and >>>> immediate implementation need (I understand from comments by >>>> you and your colleague) I think it may be appropriate to >>>> include this person-vs-program distinction of agents in an >>>> initial model, but also providing a generic agent superclass >>>> for implementations that don't care or don't know what kind of >>>> agent is involved. >>>> >>>> ... >>>> >>>> Also, I note that even in my revised understanding per your >>>> comments, the provenance notion of "process execution" still >>>> isn't covered by the ws-arch terminology relating to agency. >>>> >>>> ... >>>> >>>> You mentioned PACE. The matter of the relationship between >>>> work in provenance and work in trusted systems came up in the >>>> telecon to review work of the provenance incubator group, led >>>> by Yolanda Gil. The point she made there was that [while these >>>> are clearly interconnected] the trust work has focused on trust >>>> in *systems*, where the provenance work is concerned with >>>> establishing credibility in specific datasets. To this extent, >>>> I think we need to be cautious about over-extending the >>>> provenance model to also include concepts that would propoerly >>>> belong in a model for trusted systems. >>>> >>>> #g >>>> -- >>>> >>>> >>>> Reza B'Far wrote: >>>> >>>> Folks - >>>> >>>> To add to Ryan's comments, I had put in a comment previously >>>> regarding using stronger types for agents. From a practical >>>> implementation perspective, a subset of which Ryan mentions to >>>> be "audit" trail, etc., please note the following - >>>> >>>> 1. The distinction between the direct intervention of a >>>> human being >>>> effecting the state of a data versus an indirect >>>> intervention is >>>> absolutely crucial. Without this, establishing "trust" >>>> (I mean >>>> this from a formal perspective - something like PACE[1]) >>>> 2. I personally would lean towards one of the following >>>> options - >>>> * Strong Typing of the Agent to multiple types and >>>> specifying >>>> exactly what we mean by the types. For example, >>>> /Human >>>> Agent, System Agent/, etc. I've mentioned this in a >>>> previous thread. Within all practical usages of >>>> provenance >>>> that at least I'm concerned with, there are completely >>>> different treatments of a "snapshot" (or whatever >>>> you want >>>> to call it) of the state of an entity (which would be >>>> considered something that is included in >>>> provenance) based >>>> on whether or not there is direct human >>>> intervention (or >>>> alternatively, far more specification and strong >>>> typing) of >>>> the changes. "Agent" is way to generic to be useful >>>> practically. >>>> * Reducing the use-cases of Agent to just User-Agent >>>> which is >>>> the approach that is used in some of the other W3C >>>> standards >>>> and is weaved into the fabric of www as we know >>>> today. This >>>> would reduce the scope of what an "Agent" is. We may >>>> possibly be able to leverage work of UAProf[2] and >>>> even if >>>> not, we can learn from UAProf and CC/PP as examples. >>>> 3. The key of both (1) and (2) above is that we in order to >>>> have a >>>> practical implementation, it is highly desirable to have >>>> some very >>>> exact meaning for what "Agent" is, what it does, what the >>>> boundary >>>> conditions are, etc. I also highly encourage that we do NOT >>>> include concepts that start going into RBAC and other >>>> security >>>> related standards such as Role. IMO, we need to reuse >>>> concepts >>>> from these standards. >>>> >>>> I'm relatively new to the group, but have spent a lot of time >>>> reading the archives. From an implementation perspective, I >>>> caution that if things are too generic and there is not enough >>>> specification (typing) and exactness in order to accommodate a >>>> larger tent, there may be long term implementation hurdles that >>>> are presented in terms of practical implementation. In terms >>>> of a specific example, I think "Agent" above is one. It's far >>>> too generically defined at this point, IMO. >>>> >>>> Please see references below. >>>> >>>> [1] - PACE - >>>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.58.8965, http://www.mendeley.com/research/architectural-support-trust-models-decentralized-applications/ >>>> >>>> [2] - UAProf - http://en.wikipedia.org/wiki/UAProf >>>> [3] - CC/PP - http://www.w3.org/Mobile/CCPP/ >>>> >>>> On 7/12/11 12:17 PM, Graham Klyne wrote: >>>> >>>> Ryan, >>>> >>>> I think the important element that is missing is that >>>> provenance as understood so far by this group is intended to >>>> capture actual rather than potential or unrealized processes. >>>> This is the idea that "Process execution" aims to capture. The >>>> notion of "Agent" as described by the ws-arch spec is, to my >>>> mind, very much concerned with the potential rather than the >>>> realized computation. >>>> >>>> Although I'm not a long-time expert in this field, I think this >>>> is quite central to the notion of provenance we're trying to >>>> articulate and record, so it's an area where the terminology >>>> needs to be quite distinct from other usages. You usage of >>>> "invocation" comes closer, I think, but I'm not convinced that >>>> yet another new term (it's not covered in ws-arch as I recall) >>>> is helpful at this stage. >>>> >>>> Because of the focus on actual computations, there's >>>> correspondingly less need (or so it seems so far based on the >>>> use-cases considered) to consider subteties of potential >>>> processes ("Recipes", "Roles", etc.). I remain open on this, >>>> but I would avoid adding concepts for which there is not >>>> demonstrated need within the goals of provenance modelling and >>>> recording. >>>> >>>> #g >>>> -- >>>> >>>> >>>> Ryan Golden wrote: >>>> >>>> Thanks for taking a look at this, Graham, and I'd be interested >>>> to hear more feedback from others. To address a couple of your >>>> comments: >>>> >>>> My intent with Agent was that it closely resemble the concept >>>> of Invocation, as you say. I suppose the language "is a >>>> computational entity" does not effectively convey the >>>> intention. I think Invocation necessarily implies an Invoker, >>>> so I chose a similar but broader concept of Realization. How >>>> does does this strike you as a replacement for Process Execution? >>>> >>>> An Agent realizes zero or more Roles on behalf of zero or >>>> more Persons or Organizations." >>>> >>>> My intention with Role is to broaden the idea of Recipe to >>>> include more abstract functions and purposes, but also to add a >>>> subtle implication (though not requirement) that it is >>>> something to be realized on behalf of a person or organization. >>>> >>>> In associating Person or Organization to the concepts of Agent >>>> and Role, the model comes closer to something that would be >>>> useful in representing audit trails or in establishing the >>>> trustworthiness of provenance assertions. >>>> >>>> --Ryan >>>> >>>> On 7/12/2011 10:00 AM, Graham Klyne wrote: >>>> >>>> (ref. W3C Web Services Architecture Note >>>> <http://www.w3.org/TR/ws-arch>) >>>> >>>> Notwithstanding the slightly divergent usage in the provenance >>>> research community, I think there is value in using terms >>>> already adopted in the web services community where they align >>>> - I think that would help to make our outputs be more readily >>>> accepted, hence more relevant. Thus, I think "Person or >>>> Organization" is reasonable term, replacing (as I understand) >>>> what provenance efforts have described as "Agent". >>>> >>>> But my understanding is that "Process execution" is *not* the >>>> same as ws-arch:"Agent", being intended to reflect a specific >>>> invocation of the programme or service. I think the term >>>> ws-arch:"Agent" would more closely replace "Recipe". >>>> >>>> I'm not sure "Role" (ws-arch:"Service Role") has a direct >>>> correspondence in the terms we've discussed to date, though >>>> there is a notion of something like role in OPM. Similarly for >>>> "Realizes" and "Acts on Behalf of". >>>> >>>> #g >>>> -- >>>> >>>> Ryan Golden wrote: >>>> >>>> I'd like to bring a proposal up for discussion regarding >>>> Process Execution and its related concepts. Although at the >>>> F2F1 there wasn't much discussion over "Process Execution," >>>> "Generates," "Uses," and "Agent," I believe more clarification >>>> and discussion is needed in these areas. >>>> >>>> High Level Proposal >>>> ---------------------------- >>>> a) Rename the concept of "Process Execution" to "Agent," >>>> adjusting/adding a few properties >>>> b) Rename the concept of "Process/Recipe" to "Role," >>>> adjusting/adding a few properties >>>> c) Add the concept of "Person or Organization" >>>> d) Add the concept of "Realizes" >>>> e) Add the concept of "Acts on Behalf of" >>>> >>>> More Detailed Proposal >>>> --------------------------------- >>>> a) Concept: Agent >>>> - is a computational entity (narrowed from "piece of work") >>>> - may use zero or more Entity States (Bobs) >>>> - may generate zero or more Entity States (Bobs) >>>> - may realize zero or more Roles >>>> - may have a duration >>>> - may acts on behalf of a "Person or Organization" >>>> Discussion: >>>> Agent is a relatively well-defined industry term for an >>>> program acting on a user's behalf. I propose it as a >>>> replacement for "Process Execution," which has the overloaded >>>> (and thus undesireable) term "process" in it, and does not >>>> necessarily imply that it is acting on behalf of any one person >>>> or organization. In scenarios involving trust, audit, or >>>> change tracking, the ability to identify the "who" is crucial, >>>> and so the relation between Agent and Person or Organization is >>>> introduced. "Person or Organization" is discussed further >>>> below. Some other common variations are "software >>>> agent," or "user agent." One notable difference between this >>>> concept and other agent concepts is that our Agent may have a >>>> duration. I'm still undecided on the utility of the duration. >>>> There will be some discussion here about >>>> non-computational agents. I would question the utility of >>>> being able to assert relations involving Entity States (Bobs) >>>> and non-computational agents, and would ask you to first >>>> consider whether the same semantics could be better represented >>>> by a Role instead [see next]. >>>> >>>> b) Concept: Role >>>> - is an abstract set of tasks which pertain to a job function >>>> - may have semantics beyond the scope of the WG model >>>> (e.g., as described in the RBAC reference model) >>>> - may be realized by zero or more Agents Discussion: >>>> Replaces the somewhat confused notions of "Agent" (as >>>> it was discussed at F2F1), "Process," and "Recipe". Note that >>>> multiple Roles can be realized by a single Agent. >>>> >>>> c) Concept: Person or Organization >>>> - is a real-world person or organization that an Agent acts >>>> on behalf of >>>> >>>> d) Concept: Realizes >>>> [see Agent and Role] >>>> >>>> e) Concept: Acts on Behalf of >>>> [see Agent and Person or Organization] >>>> >>>> References: >>>> I have adapted some of this proposal from concepts in the W3C >>>> Web Services Architecture Note <http://www.w3.org/TR/ws-arch>, >>>> a document that I don't entirely agree with, but which has some >>>> useful models in it. I also referred to the NIST RBAC reference >>>> model. >>>> >>>> >>>> >>>> -- >>>> >>>> Professor Luc Moreau >>>> >>>> Electronics and Computer Science tel:+44 23 8059 4487 <tel:%2B44%2023%208059%204487> >>>> >>>> University of Southampton fax:+44 23 8059 2865 <tel:%2B44%2023%208059%202865> >>>> >>>> Southampton SO17 1BJ email:l.moreau@ecs.soton.ac.uk <mailto:l.moreau@ecs.soton.ac.uk> >>>> >>>> United Kingdomhttp://www.ecs.soton.ac.uk/~lavm <http://www.ecs.soton.ac.uk/%7Elavm> >>>> >>>> >>
Received on Saturday, 16 July 2011 17:58:57 UTC