Re: The author of a query is (not) most likely the user

Hi Bijan --

Some more good points from you (below).  I'll try to answer them....

[Adrian] The problem [i.e. the costs stemming from the gap between business 
requirements and programming] can get worse with rule systems,

[Bijan] Why? What makes the difference? Maybe there's something wrong with 
rule systems (e.g., lack of modularity.)

[Adrian reply]  IMHO, nothing wrong with rule systems, particularly if they 
are highly declarative (e.g. the order of the rules does not matter.)  It's 
just that a minor change in any logic based system tends to have far 
reaching consequences compared to a minor change in say, a Java 
program.  Consider for example some interoperating rules reasoning over a 
future semantic web.  Someone somewhere adds a transitive closure 
rule.  Whole new set of answers, many of them probably wrong.

[Adrian]  the problem can get worse if we stick to the techie notations 
that us techies know and love.  Or it can be mitigated, if we make sure 
that the person writing the rules has to document what they mean at the 
real world business level.  If this is done by including lightweight 
English in the rules themselves...

[Bijan]  "Lightweight English" has no positive, or, indeed, contentful 
association for me. Either the language is regimented, or it isn't (or 
somewhat regimented). If it is executable, it will depart from English 
enough to belie (to my mind) any claim of lightweightedness. As the system 
gets large, the need for structure and (formalisitc) clarity seems to go 
up, not down.

[Adrian reply]  OK, "lightweight English" is shorthand for what is done in 
our online system.  The idea is to supply just enough support for 
self-documenting rules, without getting into the fascinating but deep field 
of natural language research.  If you have time to run some of the examples 
in our system (by pointing a browser to www.reengineeringllc.com), you'll 
see what this is.  You could even try using a browser to write and run your 
own rules.

Formalistic clarity is great for us techies, but if there is no way of 
linking it to real world business or scientific concepts, then we are back 
to square one.  (Of course formal clarity about what goes on _inside_ the 
black box is great.)

[Bijan] ..consider today's websites. More specifically, ecommerce sites. 
Though data and query [are] heavy, I'd be very surprised if any significant 
fraction of them provided anything more than stack traces on crash by way 
of explanation. (Or similarly techie oriented explanation.) Why not?

[Adrian]  Agreed, I don't know of any sites that provide more than 
techie-oriented traces when something goes wrong.  Why not? -- because 
organizations currently have large expensive staffs of people to read the 
techie-traces and meet with business people to try to figure out what 
happened.  (Is it a bug?  Is it bad data?  Was the answer correct, but hard 
for the business folks to accept?) At the least, English explanations 
should make the process more economical.  At best, business folks will read 
and understand the explanations directly themselves.

Now take this to the level of future interoperating rules systems, or web 
services over the semantic web, and one can foresee the support and call 
center costs becoming significant enough to limit the whole endeavor.

Hope this makes sense.  I look forward to your further testing questions.

                                 Cheers,  -- Adrian


INTERNET BUSINESS LOGIC (R)
www.reengineeringllc.com

Adrian Walker
Reengineering LLC
PO Box 1412
Bristol
CT 06011-1412 USA

Phone: USA 860 583 9677
Cell:    USA  860 830 2085
Fax:    USA  860 314 1029




At 01:24 AM 7/5/2005 -0400, you wrote:
>On Jul 4, 2005, at 3:28 PM, Adrian Walker wrote:
>
>>  Hi Bijan --
>>
>>  Many good points in your posting.  For the list, I'll just try to pick 
>> up on one of them here.
>>
>>  At 02:36 AM 7/4/2005 -0400, you wrote:
>>>don't know why it's [a reasoning chain is] so much harder [for people to 
>>>understand] than for complex software in
>>>  general. Executable specifications are in the minority of formal
>>>  specifications are in the minority of specifications, as far as a I
>>>  know. "Executable natural language" in the minority of all that.
>>>
>>>Wow, I'm making a popularity argument. Whoo, how the mighty Smalltalker
>>>  has fallen :)
>>
>>  The general thought here is that the mismatch between the business 
>> level and the programming level is already very expensive with 
>> conventional software.
>
>Let's grant that.
>
>>(E.g. some years ago, the US DoD IT spend was comparable to the GNP of 
>>Australia.) Part of the cost is for techies to understand what the 
>>business folks want, and for business folks to understand what the 
>>techies have built.  Just look at the 'modelling and specification' costs 
>>on any big software project.  And consider too what happens when business 
>>requirements change while the system is being programmed.
>
>One way of handling this is with methodology. E.g., the whole eXtreme 
>Programming craze.
>
>>  The problem can get worse with rule systems,
>
>Why? What makes the difference? Maybe there's something wrong with rule 
>systems (e.g., lack of modularity.)
>
>>if we stick to the techie notations that us techies know and love.  Or it 
>>can be mitigated, if we make sure that the person writing the rules has 
>>to document what they mean at the real world business level.  If this is 
>>done by including lightweight English
>
>"Lightweight English" has no positive, or, indeed, contentful association 
>for me. Either the language is regimented, or it isn't (or somewhat 
>regimented). If it is executable, it will depart from English enough to 
>belie (to my mind) any claim of lightweightedness. As the system gets 
>large, the need for structure and (formalisitc) clarity seems to go up, 
>not down.
>
>>in the rules themselves, the rules and the documentation cannot get out 
>>of step.
>
>Only if the rules themselves are adequate documentation of themselves. By 
>"adequate" I mean "epistemically adequate", i.e., that it really is the 
>case that a user understands the import and effect and, well, meaning of 
>the rule (esp. in combination with other rules).
>
>>   We can also get English explanations of the reasoning.
>>
>>  We don't yet have HCI  studies to say whether this is a good approach.
>
>We don't have a clear analysis of what "the problem" (more likely, a whole 
>family of problems) is/are. Again, consider today's websites. More 
>specifically, ecommerce sites. Though data and query heavy, I'd be very 
>surprised if any significant fraction of them provided anything more than 
>stack traces on crash by way of explanation. (Or similarly techie oriented 
>explanation.) Why not?
>
>[snip]
>
>Cheers,
>Bijan Parsia.

Received on Wednesday, 6 July 2005 20:21:36 UTC