- From: Reza B'Far <reza.bfar@oracle.com>
- Date: Tue, 12 Jul 2011 12:46:58 -0700
- To: public-prov-wg@w3.org
- Message-ID: <4E1CA4B2.6040601@oracle.com>
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 Tuesday, 12 July 2011 19:47:38 UTC