W3C home > Mailing lists > Public > public-prov-wg@w3.org > July 2011

Agent terminology (was: PROV-ISSUE-4: agent subtypes?)

From: Graham Klyne <GK@ninebynine.org>
Date: Thu, 14 Jul 2011 22:47:24 +0100
Message-ID: <4E1F63EC.6000607@ninebynine.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:37 GMT