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

(Do we need to cross post? www-rdf-rules seems most appropriate. I'm 
going to send any further replies there.)

On Jul 6, 2005, at 4:19 PM, Adrian Walker wrote:

> 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.

Isn't that, by definition, a lack of modularity? It's not a minor 
change if it "tends to have far reaching consquences".

We can spin this as "rules are powerful! a textually small change can 
alter/fix the behavior of your whole system!!!!" But that's still a 
fragility (a metaobject protocol is powerful! it lets a small change 
alter/fix the behavior of your whole system! *use it sparingly in that 
way*!)

>  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.

I don't see how explanations will (substantially) help end users here. 
As we discuss in our (expanded version, as well as the original 
version, of our WWW) debugging OWL paper:
	http://www.mindswap.org/papers/debugging-jws.pdf

defect *detection*, when it's a *modelling* error is hard! How do you 
tell that these new answers are *wrong* (or probably wrong!) How do you 
*flag* them as wrong?

With unsatisfiable classes, defect detection is easy. Almost all 
unsatisfiable classes are a mistake and it's a straightforward 
reasoning task to discover them. Incorrect subsumption relations are 
much harder.

Basically, an unsatisfiable class is like a syntax error or a crash, 
whereas modeling errors in general are like modeling or logic errors in 
programs...you have to know the correct behavior and *test* for it.

That being the case, it seems very unlikely that you'll want to see 
"traces" in normal operation of a system. After all, we don't run our 
programs in debug mode all the time! (Though, in my experience, having 
a *good* debugger and IDE available all the time, like in a traditional 
Smalltalk system, can be a real boon).

> [Adrian]  the problem can get worse if we stick to the techie 
> notations that us techies know and love.

I don't see any relation between the problem above and the notation.

>   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.

I don't see how that helps. I mean, ok, I know how the arguments goes, 
"hey, if it's more use accessible, they will be able to spot and repair 
problems easier, in spite of the huge modularity problem". Or "Hey, if 
they can write the rules in the language of specification, they won't 
'get it wrong' and so mitigate the modularity problem". But eh. These 
are weak. The first presumes that NL is more perspicuous than other 
notations and yet is *SO* many areas that's clearly false (logic is one 
of these; algebra; music). Indeed, the temptation to feel like you *do* 
understand what's going one *when you don't* is very high. Also, I 
don't believe there is a "right business need" specification out there, 
platonically, to be accessed. Specifications and needs and 
understanding of the need evolve dramatically. How to realize them 
practically is a difficult challenge.

> 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,

Ah yes, "self-documenting", the holy grail. XML is 
self-documenting/describing too :)

> 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.

Well, the first example I see is:

"""customer some-cust-number is on the some-type plan effective 
some-plan-start-date
that-plan-start-date is less than or equal some-current-date
not : customer that-cust-number has switched plans between 
that-plan-start-date and that-current-date
""""

It's not the worst I've seen (though shouldn't there be a "to" after 
the "equal"? It's a bit like hypertalk or applescript. I've used them, 
and they can be "less intimidating" but often at the cost of verbosity, 
unclarity, pointless syntactic variation. I mean, If you were writing 
english, you wouldn't write the above.

And a bit of notation would help enormously. customer(customer-nr). >= 
insteand of "is less than or equal to".

> Formalistic clarity is great for us techies,

Let's just call it clarity :) Choosing good names is helpful. Avoiding 
mess is helpful. Whether NL inspired or "purely formal", you can create 
a mess.

>  but if there is no way of linking it to real world business or 
> scientific concepts,

I don't see that the above does that. It's as formal as you like. 
("not:"??!???)

> 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

Hmm. I think Ecommerce is often simpler :)

> out what happened.  (Is it a bug?  Is it bad data?  Was the answer 
> correct, but hard for the business folks to accept?)

Well, also because the tasks the sites do is fairly well defined.

> At the least, English explanations should make the process more 
> economical.

"should" != "will"

> At best, business folks will read and understand the explanations 
> directly themselves.

If you can't master a notation, what makes it so possible for you to 
get complex explanations of the relationship of a query and a dataset?

> 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.

The way it has XML?

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

Look forward no longer :)

My current belief is that it's hopeless to expect (most) end-users to 
be able to handle any sort of direct authoring of rules. They could 
maybe do wizards and forms, depending. But any "just write it down" 
seems like a hopeless non-starter.

Now you can entice powerusers, and maybe having a "friendly" syntax 
(though a friendly *enviroment* seems more important, see Hypercard) 
might help get them into it. But friendly means a lot of different 
things to different people (from Perl to Python :))

Anyway.

Cheers,
Bijan Parsia.

Received on Friday, 8 July 2005 03:41:04 UTC