- From: Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk>
- Date: Sat, 16 Jul 2011 18:58:06 +0100
- To: reza.bfar@oracle.com
- CC: public-prov-wg@w3.org
- Message-ID: <4E21D12E.8030304@cs.man.ac.uk>
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 Kingdomhttp://www.ecs.soton.ac.uk/~lavm <http://www.ecs.soton.ac.uk/%7Elavm>
>>>>
>>>>
>>
Received on Saturday, 16 July 2011 17:58:57 UTC