#Austin Tate
At 13:57 -0700 22/5/97, Phyl Speser wrote: > With respect to primitives, could someone explain why there is nothing which > addresses motive, goal, intention, perception, etc. or some such. I bring > this up as I am not clear how one can construct the fact humans are involved > in these processes and know-how and motivation are as important as machines > for production processes. It would seem to be necessary to provide the > ability to address the people side of the equation considering the broad > range of economic production activities to which this is to apply. But then I > may also be misunderstanding things.Phyl, I am SURE that we all want to include such things in PSL. It would be a poor base indeed if it did not allow for the capturing of objectives and the relationship of objectives to the people holding them and the relationship of those objectives to the processes or plans that can satisfy them.
In our approach (and this is also true of PIF 1.1, CPR, KRSL-Plans, etc), we have allowed agents as one type of object. An agent (singular or a grouping) can be involved in processes in two ways: a) as the PERFORMER of an activity (i.e. PERFORMS(Activity-spec, Agent-spec) b) as the OBJECTIVE-HOLDER of an OBJECTIVE (I.e. HOLDS-OBJECTIVE(Objective-spec, Agent-spec). http://www.mel.nist.gov/psl/psl-secure/teams/semantics/hypermail/0017.html
#Chris Menzel
This in fact was an important topic of discussion at the PSL workshop. For a time, I think, there was an impression that some of the participants simply didn't want to accomodate these notions, and others did. My take, after some discussion (other recollections welcomed!), was that the division was really between those who thought these notions belonged in the PSL core -- among the basic primitives of the language -- and those who thought these notions belonged in some sort of specialized extension of the core. I was among the latter crowd, so I will presume only to speak for them. The idea is that the core should only include those notions sufficient for describing processes per se, independent of human goals, intentions, etc. There are several reason for this. Most notably, perhaps, these intentional notions (so it seems to me) do not attach to processes per se, where a process is simply viewed as the thing that happens in the world -- the gears grinding, the motors turning, the part being painted, etc. By contrast, the same general process description might be associated with a number of different conflicting intentions. Intentional notions are thus highly contextual, and don't seem to be a part of what a process is per se. By way of analogy, I use my car for many purposes. But those purposes are not part of what my car *is*, and shouldn't be included in a description of it per se.It is important to note that no one has suggested intentional notions are not important; clearly, they are crucial for describing business and industrial processes. The issue is where those notions belong in the overall architecture. My suggestion has been that, because they are not essential to describing what is common to all processes per se, they belong in an *extension* of the PSL core, not in the core itself. Again, this is a *logical* or *architectural* issue. It is not to say that intentional notions are somehow less important! It is only to try to place them in their proper architectural niche. Clutter in the core, I think, should avoided at all costs. We don't want a specification language analog to ADA, methinks. http://www.mel.nist.gov/psl/psl-secure/teams/semantics/hypermail/0040.html
#Chris Menzel
I wrote: The idea is that the core should only include those notions sufficient for describing processes per se, independent of human goals, intentions, etc. There are several reason for this. Most notably, perhaps, these intentional notions (so it seems to me) do not attach to processes per se, where a process is simply viewed as the thing that happens in the world -- the gears grinding, the motors turning, the part being painted, etc.Phyl replied: ********* This is certainly true for physical processes of nature. From a social scientific perspective, placing agent in the extension is symbolic of the de facto ontology of modern industrial processes.
On the other hand, re Jintae Lee's and Chris' posts, I do not see it as a make or break issue from an industrial perspective since, as they point out, a reified agent can be constructed from object. For most industrial applications only a limited dimensionality for the agent is required anyway.
As we get to the extensions, this will become more of an issue for people like me, who are addressing processes which integrate R&D, concurrent engineering, design, and manufacturing across entities. (We work in the commercialization of technology and are building nonmonotonic tools for such activities.) Here process per se cannot exist without intentionality. ********
I disagree. I think you can always give a description of the thing that happens in terms of the (types of) objects that appear in the process, the relations they bear to one another, etc. Indeed, I think it is crucial that we do so for certain types of knowledge sharing, as I may want to use your process for different ends, i.e., with different intentions. What this means, I think, is that many process descriptions might be incomplete *relative to* certain industrial contexts -- but then I think the way to proceed is to add any missing intentional notions to the process description in those contexts. I think this makes sharing much cleaner -- and knowledge sharing is one of the central purposes of PSL.
Can you perhaps give an example or an argument to supplement your claim that processes can't exist without intentionality? http://www.mel.nist.gov/psl/psl-secure/teams/semantics/hypermail/0042.html
#Phyl Speser
Consider Chris' car example. The process of operation includes a human = operator who starts the vehicle and drives it. The manner in which = driving is done determines wear on the vehicle as well as resource = consumption. The process includes a regulator, which is the foot on the = pedal and the hand on the wheel and the person to whom they are = attached. The person moving the pedal and wheel are intrinsic in the = design of the process of a car as a mode of transportation, which is to = say the person is part of the process of the vehicle as designed. We = can go further, if we take a "big picture" look at the car as part of an = industrial process which spans R&D through manufacturing. In this social = context, the very process which is the car is a prime example of = "embodied intentionality." The machinery is developed to operate in a = setting where infrastructure like gas stations (water, fuel, oil, other = fluids) are placed at definable distances (around no more than 200 miles = apart), that it meets certain safety and fuel efficiency standards as = well as speed, comfort, etc. and styling requirements. By styling I am = not referring to the cosmetics of the exterior. Styling carries into the = very design of the engine, which has to "look" like an engine when the = hood is raised or people do not buy the car. =20Some of this debate is no doubt rooted in disciplinary perspectives and = foci of work. In my case, I am trained as a philosopher of science and = now work in nonmontonic modes of reasoning in artificial intelligence = applied to technology management. The reification of industrial = processes has been addressed in the social science literature on = technology for years (cf. work by Everett Rogers and by Louis Tornatsky) = as well as the critical thought school of philosophy (cf. Habermas). =20
In my admittedly somewhat Kantian theoretical perspective, I would = argue for a primitive called entity with derived concepts of agent = (subject) and object. I would also ague for a primitive, perhaps called = construct, from which the cognitive/emotive aspects would be derived = (i.e. not only intentionality but knowhow which also is de facto vital = for making industrial processes work.) But I also realize I can build = these in for my applications as extentions to a core and that keeping = the core sparse has practical value which, at some point, justifies = trading-off theoretical rigor.=20
Another trade-off for me is I am currently working on a project and am = at the point where if I want to map into this effort and closure would = help, given my timeline with NSF, which is funding the work. (On the = other hand, the discussion is interesting and I find myself thinking = about issues I have not worked with in years so on that level I am glad = to continue it.) http://www.mel.nist.gov/psl/psl-secure/teams/semantics/hypermail/0043.html
#Richard C. Anderson
I've been monitoring the discussions betwen Chris, Phyl, et. al. over the past week about process intent, and in what should be a surprise to no one, thought I'd get my "two cents" in...Basically, I still agree with the "compromise" of sorts we worked out at the roundtable that while process intent is important, it is not necessary to represent *all* conceivable processes, so I can live without it being in the core. However, I would like to make a few points...
The way I see it, for systems and processes that have already been designed and developed, the functionality is "built in," and thus so is any intent of the designer. An example of this is a satellite - once it is launched, it does what it was designed to do (of course, with the exception of any intentional human control from the ground - but even the nature and allowable extent of that has been predetermined by the features of the design). As for the car example, yes, once it is built, the designed artifacts and their imbedded possible behaviors are set.=20 Hopefully then, the intent of the customer and of the driver have been successfully captured to the point where we can take it for granted. But it stands to reason that a careful driver will experience a much different process experience than would one whose intent is to maintain it poorly or drive it too hard. Intent still plays an important role in determing what operational modes a system will operate in under given circumstances, unless of course we don't care what result we get or there is only one possible mode to operate in, or the operation is completely automatic.
Aside from operations of committed products and processes, from my perspective of early-stage system engineering and design, intent is an *extremely* important element. At this point in a product life cycle, the product (satellite, car, etc.) and the processes by which they will be built, integrated, tested, deployed, operated, and disposed have not even been decided yet. As the design process unfolds, products and processes are selected based on their ability to satisfy requirements and *objectives*. Until you settle upon a design solution to implement those objectives, you are faced with many (sometimes virtually unlimited)=20 possible product and process configurations to choose from. The "best"=20 design configuration is eventually determined by extensive evaluations and tradeoffs between alternatives to estimate their relative responses to the requirements. In other words, a process model can help designers to evaluate how different design alternatives measure up against the objectives/intent of the customer and the producer. All products and process activities must be somehow traceable to top-level objectives - if they are not, they are likely to be overspecified, non-value-added entities that can be descoped. If you can't give me a good reason *why* something is being done, I, as a systems engineer, would naturally become suspicious and want to investigate whether it actually needs to be done at all. How does the activity contribute to the overall success of the process? *Someone* somewhere needs to know this, or has had to have thought about it at some point, even if it is purely automated (with no thought required) at the time it is actually done.=20
Granted, processes like the workings of the solar system that are outside of human control (that are not purposeful systems, as Dr. Elmaghraby would say), do not require a description of intent. However, we are not trying to squeeze every last bit of efficiency out of those processes inorder to make a profit and satisfy customers!=20
I certainly don't intend this to escalate the discusion over process intent - we've been there and done that. However, it might serve us well to revisit the issue from time to time to be sure we are handling this important process component in the best possible manner. I'm still not sure we all have quite the same meaning in mind when we speak of process intent. I hope the above helps to clarify what I think it is. http://www.mel.nist.gov/psl/psl-secure/teams/semantics/hypermail/0057.html
#Austin Tate
Intent for me is the objective of an agent. I.e. the RESULT they wish to be brought about by the process. Design rationale can relate the decisions taken to select from alternatives that might achieve this. Causal and other technological dependencies are in plans because of the descisions thus taken - and these may beed to be preserved to ensure that the process executes siccessfully to achieve the requirements.So dependencies are definitely in plan and process representations. design rationale may be outside it. Intent is a relationship between a designed process and the agent who is the pourpose holder. http://www.mel.nist.gov/psl/psl-secure/teams/semantics/hypermail/0060.html