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

Re: PROV-ISSUE-4: agent subtypes?

From: Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk>
Date: Thu, 21 Jul 2011 13:58:05 +0100
Message-ID: <4E28225D.1020305@cs.man.ac.uk>
To: Graham Klyne <GK@ninebynine.org>
CC: public-prov-wg@w3.org
Hi Graham,

On 21/07/2011 12:24, Graham Klyne wrote:
> 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.
>
> Jumping in ... maybe a bit late.
>
> I would suggest that provenance queries would SHOULD NOT be treated 
> differently based on agent type, but some computations based upon 
> provenaqnce information retrieved might be.
>
> I'm thinking, for example, of possible information integrity 
> assessements in the Wf4Ever project:  knowing whether the generating 
> agent is a computational or volitional agent might affect the 
> application of a trust model that uses the provenance information.

Agreed. But I think in this case, a simple property that specifies the 
type of the agent should be enough: it is up to the application that 
enforces trust to decide whether the agent is malicious or not by, 
amongst other things, looking at the provenance.

Khalid

>
> <aside>
> But to the extent that provenance queries are SPARQL queries, these 
> different concerns may be combined in a single query.
> </aside>
>
> #g
> -- 
>
>> 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:58:51 GMT

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