- From: Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk>
- Date: Thu, 21 Jul 2011 13:58:05 +0100
- 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 UTC