- From: Graham Klyne <GK@ninebynine.org>
- Date: Thu, 21 Jul 2011 12:39:39 +0100
- To: reza.bfar@oracle.com
- CC: public-prov-wg@w3.org
Reza B'Far wrote:
> The issue with a loosely defined attribute (if it's not bound) is that
> there is then a compatibility issue. Vendor A will implement their own
> types. Vendor B, a totally different set of types. And you won't be
> able to import content produced by Vendor A into Vendor B's system.
[...]
I think there's no single correct answer to this, just a choice to make that
optimizes easy wins for provenance and interoperability.
A fully minimal solution would be to have an agent class that can be subclassed
as needed by all applications. But maybe that loses us an opportunity for a
quick interoperability win? (The opportunity for interoperability isn't lost
forever, and derivative specifications can still define subclass vocabularies,
but that will probably take longer to gain traction).
At the other end of the spectrum is to define a comprehensive ontology of
agents. I don't think anyone is suggesting this.
As I currently understand the landscape, I could support two approaches:
(a) define a single agent class, and leave it at that (first option)
(b) define an agent superclass, with two subclasses corresponding roughly to
software agents (computational agents) and people (volitional agents). I didn't
catch any clear need for finar distinctions in Reza/Ryan's use case.
As a procedure option, we could go with option (a), but "support" the
publication of an accompanying NOTE that suggests some vocabulary and practice
for agent types that could act as a seed for future developments in this area.
(Per W3C process, I think this need not be a WG output, but might be a member
submission?)
#g
--
Reza B'Far wrote:
> Thanks Khalid -
>
> The issue with a loosely defined attribute (if it's not bound) is that
> there is then a compatibility issue. Vendor A will implement their own
> types. Vendor B, a totally different set of types. And you won't be
> able to import content produced by Vendor A into Vendor B's system. Let
> me give you an analogy. What if in HTML, they chose to define one tag
> called <section> with an attribute called "type" and let that type be
> whatever instead of defining <p>, <div>, <br>, etc.? I definitely think
> it's a judgement call, but I'm biased to more strong-typing. I see the
> challenge as defining the right types versus defining something generic
> and letting people define their own types.
>
> In this case, if we go with what you're saying, an attribute that's wide
> open and not bounded to a defined list, then there can be all sorts of
> different agents defined by different vendors and this will cause
> compatibility issues. I guess the key decision here is whether or not
> this is significant and pervasive enough of an issue that other folks
> think it's a big compatibility issue versus a small one. To argue
> against myself, you will always have some incompatibility. My point
> here is that typing of agent is a big compatibility issue, not a small one.
>
>
> On 7/16/11 10:58 AM, Khalid Belhajjame wrote:
>>
>> 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 Kingdom http://www.ecs.soton.ac.uk/~lavm <http://www.ecs.soton.ac.uk/%7Elavm>
>>>>>>
>>>>>>
>>>>
>>
Received on Thursday, 21 July 2011 12:04:02 UTC