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