- From: Graham Klyne <GK@ninebynine.org>
- Date: Thu, 14 Jul 2011 22:47:24 +0100
- To: Paul Groth <p.t.groth@vu.nl>
- CC: "reza.bfar@oracle.com" <reza.bfar@oracle.com>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Paul, all, I'd just note that I think that, for our purposes, widespread usage of a term outside the provenance community should trump established usage within the community. I think a big part of our goal (if not our entire goal) is to make the available work on provenance more widely usable. #g -- Paul Groth wrote: > Hi Reza, All: > > I think it's important to note again that Agent is defined in a number > of other provenance ontologies and they generally share the same > meaning. Wikipedia says it nicely: > > Agent may refer to one who acts for, or in the place of, another, by > authority from him. > > But why do we need agent for provenance. My feeling is to denote > *responsibility*. > > Who owned the Picasso then? > Who approved the publication of the document? > Who can I attribute that quote to? > Who made a particular decision? > What party made this ad in a web page? > > All these use cases are about responsibility. In order for someone or > something to take responsibility they need to be able to do things using > their own volition. Agent is a good match for this because it usually > refers to a person or organization, which we know have this ability to > act on their own. When we use it in the software sense we either mean an > intelligent agent (something or to mean a proxy for some other agent > (i.e. user-agent in http). > > > In terms of trust, I would prefer that to be another discussion if > possible. One of the insights of the Provenance Incubator Group was that > provenance can be a platform for trust decisions but provenance should > not be intertwined with trust. > > Reza, I wonder if the notion of responsibility covers your trust use case? > > Thanks, > Paul > > > > > Reza B'Far wrote: >> Satya - >> >> Thanks for clarification. Please note below (and please read reply to >> Yolanda as well). >> >> 1. I think we're talking about completely different notions of agent >> and this is why I stressed that we shouldn't use words that are >> outside of standard computer science or software engineering >> vernacular. In fact, if we use those words, then we're in >> violation of what you're saying "we become domain dependent". So, >> I'm assuming that the only context for all the wording we use in >> this working group is something that can be found as an >> established understanding in the field of CS or SE at the time of >> discussion. >> 2. My point from the papers is that Agent has an exact meaning in >> software engineering and CS. If we mean something else, then we >> need to find what that is in the field and use that word. If we >> mean something completely new, then I would be VERY skeptical of >> that NEW thing since it would indicate we're inventing stuff >> instead of standardizing. >> 3. Again, please see the references. The word Agent has an exact >> meaning. Fugetta, et. al, Norvig/Russell, etc. For User-Agent, you >> can see UAProf, CC/PP, Fielding/REST, etc. below. >> >> Thanks. >> >> On 7/14/11 11:00 AM, Satya Sahoo wrote: >>> Hi Reza, >>> > Please note that the concepts of "Human agent", "System agent", >>> "Trusted agent", "Untrusted >agent", etc. have NOTHING to do with >>> domain. >>> >>> Hypothetical scenario from biomedicine: >>> -------------------- >>> A monoclonal antibody XY is introduced in an mouse model with cancer >>> to inhibit protein vascular endothelial growth factor A (VEGF-A) - XY >>> is agent involved in process of inhibition (of a protein). >>> But, it is found that XY is not effectively inhibiting VEGF-A (which >>> leads to death of the mouse). >>> >>> Upon analyzing the provenance of the XY, it is found that an error in >>> the manufacturing process of XY reduced its ability to inhibit VEGF-A. >>> -------------------- >>> >>> Please identify "Human Agent" and "System Agent" in above scenario. >>> >>> Also, how does your option 2 (User Agent) cover the above scenario >>> requirements? >>> >>> The point is: each domain has its set of entities/entity states etc. >>> it identifies as "Agent". As a WG, I am not sure how do you propose to >>> enumerate all possible set of these entities/entity states? >>> >>> > I can post a half-a-dozen IEEE papers here about agents. >>> Not sure about your point here. I am sure different communities >>> (biomedical, sensor web, oceanography etc.) can post multiples of >>> dozens of papers about agent (e.g JBI, Nature, Science, JAMIA etc.) >>> >>> >>> > The usefulness of the provenance model, independent of domain, at >>> least to me, is in its ability to >accommodate the domains. Without >>> some strong typing, the standard becomes useless. >>> Agree. Modeling the provenance model in OWL will ensure strong typing >>> (i.e. it will be interpreted consistently based on OWL RDFS semantics >>> + other semantics introduced by axioms in the ontology - in your words >>> " import and export without data loss"). >>> >>> Thanks. >>> >>> Best, >>> Satya >>> >>> >>> On Thu, Jul 14, 2011 at 1:13 PM, Reza B'Far <reza.bfar@oracle.com >>> <mailto:reza.bfar@oracle.com>> wrote: >>> >>> Satya\Lena - >>> >>> The usefulness of the provenance model, independent of domain, at >>> least to me, is in its ability to accommodate the domains. Without >>> some strong typing, the standard becomes useless. I state this as >>> an opinion, but I believe this to be widely shared in the >>> commercial software industry by practitioners. Strong typing >>> provides a better chance of compatibility succeeding in a software >>> market place which I believe to be of paramount importance to any >>> standard, not just Data Provenance. >>> >>> 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. >>>> >>>> >>>> > >
Received on Thursday, 14 July 2011 21:55:29 UTC