![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Back a couple of careers ago, I developed so-called expert systems, which - without referring to any kind of academic definitions - are programs that embody the expertise of one or more "subject-matter experts" in such a way as to make that knowledge available for future utilization by non-experts.
One such system I worked on involved modeling the control system hardware - the collection of limit switches, flow sensors, pressure sensors, etc. - used when loading propellant aboard the Space Shuttle. The model was designed in such a way that, should some part of the real-world system indicate that things are not right (for example, that there was no pressure in a line with flowing propellant, suggesting a ruptured pipe) the model would be used to determine whether the indication was correct. If so, further propellant loading operations would be suspended, pdq. On the other hand, if the indication was the result of a malfunctioning sensor (which is statistically almost a certainty, given the enormous number of sensors in such a complex system), operations should continue, cautiously.
Making a mistake is costly: it costs a pile of money to stop loading propellant; it costs even more to replace a Shuttle.
It was challenging work, and I don't know if anything ever came of the prototype we worked on, as the lure of Silicon Valley brought me to California and a new career, which is grist for another post.
Developing expert systems involves interviewing experts and using various techniques to elicit information from them. You've got to challenge them in ways that might reveal aspects of what they do that they themselves might not be aware of. Experts do not always like "knowledge engineers" (which is the name applied to developers of expert systems), because the latter physically represent what is often perceived as a vainglorious and quixotic effort by upper management to put the expert's knowledge "in a can," perhaps with the intention of then forcibly retiring the expert.
I find I use much the same eliciting techniques whenever I quiz the people with whom I work on the terminology they use, and sometimes, I get much the same in the way of reaction, although here there are two basic drivers.
First, many experts in technical fields have decidedly poor language skills, and asking such a person to stop and focus on the words that he or she uses is a lot like asking an expert to get into the nitty-gritty of how decisions are made on a subconscious level (as in the case of locomotor skills). As soon as you start to think about it, you're not sure.
Second, some experts are reluctant to get into explanations that might be construed to be too complicated for a "mere" translator to understand. (The typical flag for this reaction is the response "Well... <pause>... it's actually the same thing" when asking an expert to draw a distinction between two different terms.)
In my experience, most violators in the first group are English-speakers; most in the second group are Russian-speakers.
I'm sitting here right now, elbow deep in various scratchings, trying to make sense of my terminology related notes. Somewhere here I have a really marvelous description of экспериментальная отработка that I feel will be key to a broader understanding of several other terms as well.
At 9 am, I'm going to accompany some of the folks staying over for the two-day meeting next week (which I will be supporting) on a trip to Microcenter. I've got an idea.
Cheers...
One such system I worked on involved modeling the control system hardware - the collection of limit switches, flow sensors, pressure sensors, etc. - used when loading propellant aboard the Space Shuttle. The model was designed in such a way that, should some part of the real-world system indicate that things are not right (for example, that there was no pressure in a line with flowing propellant, suggesting a ruptured pipe) the model would be used to determine whether the indication was correct. If so, further propellant loading operations would be suspended, pdq. On the other hand, if the indication was the result of a malfunctioning sensor (which is statistically almost a certainty, given the enormous number of sensors in such a complex system), operations should continue, cautiously.
Making a mistake is costly: it costs a pile of money to stop loading propellant; it costs even more to replace a Shuttle.
It was challenging work, and I don't know if anything ever came of the prototype we worked on, as the lure of Silicon Valley brought me to California and a new career, which is grist for another post.
Developing expert systems involves interviewing experts and using various techniques to elicit information from them. You've got to challenge them in ways that might reveal aspects of what they do that they themselves might not be aware of. Experts do not always like "knowledge engineers" (which is the name applied to developers of expert systems), because the latter physically represent what is often perceived as a vainglorious and quixotic effort by upper management to put the expert's knowledge "in a can," perhaps with the intention of then forcibly retiring the expert.
I find I use much the same eliciting techniques whenever I quiz the people with whom I work on the terminology they use, and sometimes, I get much the same in the way of reaction, although here there are two basic drivers.
First, many experts in technical fields have decidedly poor language skills, and asking such a person to stop and focus on the words that he or she uses is a lot like asking an expert to get into the nitty-gritty of how decisions are made on a subconscious level (as in the case of locomotor skills). As soon as you start to think about it, you're not sure.
Second, some experts are reluctant to get into explanations that might be construed to be too complicated for a "mere" translator to understand. (The typical flag for this reaction is the response "Well... <pause>... it's actually the same thing" when asking an expert to draw a distinction between two different terms.)
In my experience, most violators in the first group are English-speakers; most in the second group are Russian-speakers.
I'm sitting here right now, elbow deep in various scratchings, trying to make sense of my terminology related notes. Somewhere here I have a really marvelous description of экспериментальная отработка that I feel will be key to a broader understanding of several other terms as well.
At 9 am, I'm going to accompany some of the folks staying over for the two-day meeting next week (which I will be supporting) on a trip to Microcenter. I've got an idea.
Cheers...
