Bruce,

Good heavens, no, I'm not offended. And I too have strong feelings 
about language.

The philosophical perspective you bring to bear on the issue with 
respect to diagrams as extended metaphor and so on is interesting, to 
be sure. Metaphor underlies a good deal of how we construe the world, 
how we communicate, and explorations of those processes are 
illuminating on many levels. I freely grant you that. But I think 
that your parsing of the interactions, in this context, of the system 
administrator and the developer reflects the workings of a deeply 
knowledgeable and analytic mind on an unfamiliar context. Within the 
context of the subject matter this figure is embedded in, within the 
context of the knowledge the audience of this document brings to bear 
on the material, none of this (the relationship of the administrator 
to the developer, the function of the roles, what "permissions" and 
"credentials" are, and so on) would be at all controversial or the 
least bit problematic. Yes, the concept of a "role" is metaphorical. 
But the application of that metaphor here is very prosaic.

An application, or software program, has within it a certain number 
of assigned user roles. These roles dictate the parameters within 
which a particular category of user can work: what areas of the 
application the user can see, what areas the user can make changes to 
(if any), what sorts of changes those can be, and so on.

For a given business environment, the administrator of the system 
defines those roles, those categories of use. When users of that 
application log in, they must do so within the role they have been 
assigned. And that role, in turn, determines what "permissions" they 
have: what they are permitted to see and to do within the app.

The developer is the programmer. "Developer" in this context is just 
another term for "software engineer." (The developer _develops_ the 
software.) So the developer is ordinarily working within the 
application at a very different level. The developer is the engineer, 
designing the application and making changes that alter the way in 
which the application works at a fundamental level. The system 
administrator, by contrast, is working only within a finished 
application, at a more superficial level. The administrator can make 
only those sorts of changes that have been built into the machinery, 
only those sorts of changes the application has been designed to 
allow her to make.

All of this and much, much more -- far more than I understand about 
these relationships -- the audience for this document would 
understand. I don't understand, for example, precisely why it is the 
developer has to call the AssumeRole function in order to make the 
update to the /app folder. That is the way the system has been 
designed, and presumably here the developer is working at "run time" 
(as the application is running), rather than, as is typical, at 
"design time" (while the application is being designed). For this set 
of callouts (or captions, if they are set up that way), I wouldn't as 
editor need necessarily to understand that aspect of the process. If 
there were accompanying conceptual text that entered into such 
explanations, I would have to make sense of that material far enough 
to determine whether those explanations were clear enough for the 
context.

At any rate, none of this material comes from anything I am working 
on. I was simply struck by the conundrum at item 3, the odd syntax 
and what it is exactly that makes it odd. The person who raised this 
issue originally has since posted the question online, and within the 
lengthy debate that followed (apparently quite a few of us have been 
drawn to this puzzle) has emerged an answer that I think gets at the 
heart of the issue. I won't attempt to summarize it here. If you're 
interested, check it out: http://languagelog.ldc.upenn.edu/nll/?p=4186

Scan the responses for Alan, Steve Kass, and finally Barbara Partree. 
Barbara sums up the issue and cites Jackendoff's _Semantic 
Interpretation in Generative Grammar_. This is the answer I was 
looking for. This, to me, explains why "requested to assume" is so 
darn odd, and why it is not a form most of us as native speakers 
would ever generate, in speech or in writing.

If you do take a look, is that an answer that makes sense to you?


Odile







>Odile,
>
>Thank you for your patience with me and my strong feelings about 
>grammar.  Your detailed explanation was very helpful.  I hope I 
>haven't offended.  You will know that the process of communication 
>is fraught with many opportunities for confusion.  For example, 
>callout (1) talks of user roles, and the perception may be that this 
>is any end-user of the system.  The subject of callout (3) is a 
>developer, only one kind of end-user.  It is an unwritten assumption 
>that the user is a developer or at least may be.  I suppose that 
>this is somehow understood from the environment of the figure.  The 
>metaphor of "role" is acting on a stage; the "playing" of the role 
>is only anticipated and hence spoken of as "assuming" the role, 
>i.e., putting on the mask or costume.  The application of the word 
>has been generalized.  There also seems to be an underlying 
>assumption that there is a difference between "permissions" and 
>"credentials:" the former being a specialized term (the plural 
>sounds foreign to English), and the latter an ordinary reference to 
>their use. 
>
>Diagrams or figures are extended metaphors or allegories.  In this 
>environment they attempt to propose a conformance between a model of 
>a process and the process itself.  Whenever such a conformance to 
>objects in the imaginary or the real world is attempted, some 
>language is appealed to.  The language brings with it quite a bit of 
>baggage; it has its own set of metaphors and allegories.  The 
>abstraction of concepts from the world, the model, and the language 
>is often inextricably mixed.  Some concepts are imposed by our 
>everyday model of the world, e.g., our culture, some by the 
>particular constructed model, e.g., our figures or diagrams, and 
>some by the model of the world that comes with the natural language 
>of English.  People acquainted with foreign languages find that they 
>have their own models and can usually make divisions between the 
>cultures of the various peoples that speak the languages.  Our 
>modern culture is beset by a great diversity of cultural mindsets 
>all with different allegories and metaphors.  The same phenomenon is 
>apparent in people of different generations using the "same" 
>language.  It is all too easy to offend one another when we are 
>stuck on our own models of the world, no matter their origin.  [It 
>is hard today not to see violence as the acting out of the metaphor 
>of a "battle" between "good" and "evil," each party trying to assume 
>the same role.  A reality without violence must lie beyond this 
>simple and pervasive metaphor.]
>
>Bruce
>
>--- [log in to unmask] wrote:
>
>From: Odile Sullivan-Tarazi <[log in to unmask]>
>To: [log in to unmask]
>Subject: Re: Computerese
>Date:         Fri, 14 Sep 2012 08:31:16 -0700
>
>Bruce,
>
>Strong words! Well, the figure callouts were probably written in
>first draft by whichever developer the writer is working with. And
>those callouts probably sound very odd indeed to anyone not
>accustomed to this writing environment. Like any technical or
>professional environment, it has its own language and some of that is
>very necessary and useful. The audience for this documentation is
>almost certainly other developers, and so the various abbreviated
>forms and what might otherwise sound odd (the particular thing a
>"role" is in this context, for example) will be familiar stuff.
>
>If this were a book for end users, or if this were a textbook, the
>language would be very different. At the very least, the process
>analysis would be cleaned up to something like this --
>
>       1. The system administrator creates the user role.
>       2. The system administrator then sets role permissions.
>       3. The developer sends a request to assume the role.
>       4. [ProductX] returns the appropriate credentials for the role session.
>       5. Using those permissions, the developer updates the /app folder.
>
>Item 3 might even be instead "The developer calls the AssumeRole
>function," which is more precisely what is happening. But then the
>other items ought to be reworded accordingly, to reflect at a deeper
>level what each action entails.
>
>A "callout" is a, well I suppose it's a publication term. It's a
>label used to identify parts of a figure, distinct from the caption
>(which titles the entire figure) or a legend (which adds additional
>information to the caption). A figure can be any sort of illustration
>or diagram or chart or whatever, though generally not tabular.
>Tabular info is numbered and titled in a distinct series, as tables.
>
>You can find callouts discussed in any style guide that addresses the
>graphics of figures: Chicago, APA, AAA, and so on. They are not
>discussed in the MLA, not that I can find, at any rate, and I'm
>supposing that's because the MLA is used more for academic papers
>within the realm of the university, papers written in a word
>processing program where there is not the formatting capability for
>producing callouts, or indeed most types of figures. In a published
>book, however, they sometimes do come into play. And any figure
>complex enough to benefit from such can include callouts: the context
>need not have anything to do with computers.
>
>
>
>Odile
>
>
>
>
>At 6:35 AM -0700 9/14/12, Bruce Despain wrote:
>>Odile,
>>
>>Please disregard this message, if I'm beating a dead horse.  It was
>>in disgust that I deleted your messages prematurely yesterday.  I
>>had not at first realized that your "callouts" were done by data
>>analysts, many of whom manifest a characteristic disregard for
>>natural language.  I think this feeling is reinforced
>>by philosophers who often express their consternation with the
>>weaknesses of human language.  (Mathematicians have largely
>>abandoned the use of natural language.)  I have worked with computer
>>programmers for years and should have known better.  In any case I
>>myself have long harbored a distain for the grammar of computerese
>>and the argot of texters, brought on by software developers often
>>with narrowly developed skills.  The latest (1999) dictionary in my
>>library does not even include this meaning of "callout."
>>
>>The process of assuming a role has probably been separated out and
>>was probably made part of the callout for clarity in what was more
>>accurately called out as a simple request for a role.  If other
>>requests were present along the same chain, it might make sense to
>>summarize the anticipated process of assuming the role requested.
>>The processes might suggest to the programmer that the developer
>>should confirm his request for a role before the role is assigned.
>>There is probably a "confirming" by the developer and then an
>>"assigning" by the software.  The result is that the "developer
>>assumes role requested."
>>
>>Bruce
>>
>>To join or leave this LISTSERV list, please visit the list's web
>>interface at: http://listserv.muohio.edu/archives/ateg.html and
>>select "Join or leave the list"
>>
>>Visit ATEG's web site at http://ateg.org/
>
>To join or leave this LISTSERV list, please visit the list's web interface at:
>      http://listserv.muohio.edu/archives/ateg.html
>and select "Join or leave the list"
>
>Visit ATEG's web site at http://ateg.org/

To join or leave this LISTSERV list, please visit the list's web interface at:
     http://listserv.muohio.edu/archives/ateg.html
and select "Join or leave the list"

Visit ATEG's web site at http://ateg.org/