Hi Jeffrey --
Thanks for your reply. you wrote...
The engineering process of
requirements gathering, functional analysis, design, build, and test is
especially amenable to a reduced language set, since the expected
product is already in a constrained design space.
Most folks assume that "executable English" means "controlled
vocabulary executable English". Correct me if I'm wrong, but I
seem to detect that assumption in your note.
The [IBL] system actually supports open vocabulary
executable English. (There's a trade off of course -- if you want
the system to treat two sentences as having the same meaning, you have
to say so.) However, this means that folks can use their own
words and phrases*, and the appropriateness of the meanings becomes
clear when they 'run' the English -- and get English explanations of
the results.
Paradoxically, the system can be used to reason about and query a controlled vocabulary or ontology. But you can use any words and phrases in the reasoning part.
Hope this makes sense. I'll be glad to talk off-list if it's of interest.
Cheers, -- Adrian
* such as technical terms, government acronyms etc.
[IBL] Internet Business Logic
A Wiki and SOA Endpoint for Executable Open Vocabulary English
Online at www.reengineeringllc.com Shared use is free
Adrian Walker
Reengineering
On 2/14/08, Schiffel, Jeffrey A <jeffrey.a.schiffel@xxxxxxxxxx> wrote:
> From: Adrian Walker
> Hi Jeffrey --
> Does using a Wiki for executable English help with that?
> Appended below is a previous post about this.
> Thanks for comments, -- Adrian
Yes, executable English can certainly help, but not completely solve the
problem. It does reduce language ambiguity. The engineering process of
requirements gathering, functional analysis, design, build, and test is
especially amenable to a reduced language set, since the expected
product is already in a constrained design space.
Whether a Wiki, or some other tool, such as the commercially available
DOORS or Slate, or several others, is a matter of choice, project size
and complexity, and price.
The main problems are, first, training all parties in the reduced set;
and second, in maintaining and enforcing the rules. This is the problem
of all ontologies, of course.
-- Jeffrey Schiffel
> ------------------------------------------------------
Hi Jakub & All --
A while ago, Pat Cassidy raised a good question about NL
ambiguity and whether it is a show stopper without long term research
into full natural language understanding.
As many folks on this list know, there's an online system [IBL]
that supports the writing and running of database applications -- as
rules in open vocabulary, executable English. Pat's question was about
a specific application in the oil industry, but it serves to illustrate
one way of handling ambiguity.
Pat wrote:
As for how ambiguity can creep into IBL, I look at the first
example:
estimated demand some-id in some-region is for some-quantity
gallons of some-finished-product in some-month of some-year
in that-month an order for that-finished-product can consist in
whole or part of some-base-product
in that-month the refinery some-name has committed to schedule
some-amount gallons of that-base-product
we have some-method transportation from refinery that-name to
region that-region
------------------------------------------------------------------------
------------------------------------------------------------------------
---------------------------------
for demand that-id for that-finished-product refinery that-name
can supply that-amount gallons of that-base-product
. . . and then consider that, if someone creates a similar rule
with the third line being:
in that-month the refinery some-name has uncommitted scheduled
production some-amount gallons of that-base-product
There will be two rules having similar intended meaning. , but
with the difference that in the second case it is more explicit that the
refinery's output can be provided to fill a new order, and is not
already committed. Whether the first rule actually conflicts with the
second depends on whether the one who wrote the first rule actually
intended to say that the output was not already committed (which depends
on a time point, not explicitly mentioned in the rule). The third line
might also be:
in that-month the refinery some-name has uncommitted scheduled
production some-amount gallons of that-base-product on date some-date
If someone, searching for the second rule (looking for
uncommitted production) runs a query that fires the first rule, they may
mistakenly believe that there is an uncommitted production when all of
the output may in fact be already committed. This is just one example,
and I am sure you can find many others, of where different people,
intending to say the same thing, may phrase it differently enough to
create problems in an inference system.
To avoid unintentional generation of conflicting rules and
inferences, I expect that a system will need true understanding of
linguistic input.
Adrian replied to Pat as follows:
You raise a good general point illustrated with committed vs
uncommitted in the rules for the oil industry supply chain example.
Fortunately, the angel is in the details. The IBL provides two
mechanisms that help in such situations -- 1. context, and 2.
explanation.
1. If you add the "uncommitted" rule as you suggest, the system
responds as follows
In this rule, the line in some-month the refinery some-name has
uncommitted scheduled production some-amount gallons of
some-base-product should be (a) the conclusion of some rule, or
(b)
the heading of a table, or (c) a predefined sentence.... You may
like
to consider the sentence in some-month the refinery some-name
has
committed to schedule some-amount gallons of some-product
2. If you just leave the "uncommitted" rule in place, and ask
for an oil production schedule, an explanation shows this step:
estimated demand 523 in NJ is for 1000 gallons of product-y in
October of 2005
in October an order for product-y can consist in whole or part
of product-x
in
October the refinery Shell
Canada One has committed to
schedule 300 gallons of product-x
we have truck transportation from refinery Shell Canada One
to region NJ
for
demand 523 for product-y refinery Shell Canada
One can
supply 300 gallons of product-x
The context and explanation mechanisms are generic, so they also
address the general point you illustrate with your example.
The other aspect of course is that anyone with appropriate
permission can edit the rules. So, there is also a Wikipedia-like
social mechanism in place. For example, you could now go in and change
a couple of rules so that your "uncommitted" improvement works, and
shows up in explanations.
(End of Adrian's reply to Pat)
The full example is
www.reengineeringllc.com/demo_agents/Oil-IndustrySupplyChain1.agent
and there's a paper about it
www.reengineeringllc.com/Oil_Industry_Supply_Chain_by_Kowalski_and_Walke
r.pdf
So, the basic point is that if you bring in some appropriate
technology to watch and comment on what people write, and if you also
exploit the 'social' Wiki aspect of the Web, then you can to a useful
extent have your NL cake and eat it -- without choking on ambiguity.
With apologies to folks who have seen some of this before.
-- Adrian
[IBL] Internet Business Logic
A Wiki and SOA Endpoint for Executable Open Vocabulary English
Online at www.reengineeringllc.com Shared use is free
Adrian Walker
Reengineering
On 2/13/08, Schiffel, Jeffrey A <jeffrey.a.schiffel@xxxxxxxxxx>
wrote:
Please see below.
> -----Original Message-----
>
From: John F. Sowa [mailto:sowa@xxxxxxxxxxx]
>
Sent: Wednesday, February 13, 2008 1:03 AM
> To: [ontolog-forum]
>
Subject: Re: [ontolog-forum] language ambiguity
>
> Jakub,
<snippage>
>
The same is true for designing an airplane or a
computer program.
>
If everybody who walked into a design meeting had a
>
completely finished specification, it would be
impossible to
>
reach an agreement on anything. Instead, you go
through a
>
period of negotiation to arrive at a reasonable plan
that
> everybody can agree to.
>
>
It's not a matter of politeness, but the normal course
of
>
developing a vague idea into a finished design, which
is
>
usually not completely specified until after a
prototype has
>
been built and tested. (Even after a product has been
>
delivered, there are usually many changes as time goes
on.)
It
is rarely the case that that a design is finished, in
terms of
reconciling
divergent viewpoints about specifications.
This is because
there
are different levels of interested parties. A
customer (the future
owner)
may not have the same view as even the future
users (who work
for
the owner). The architects may not see the same as
the designers.
The
hardware and software engineers have different
opinions about
interpreting
the original requirements and designs, and
also the
technologically
imposed requirements and constraints.
The test group
probably
wonders if anyone else is even sane :-)
Language
ambiguity does lead to trade-off in design. But
since no one
can
be guaranteed to understand someone else, acceptance
is also
trade-off.
The design is a partly understood set of
compromises.
>
> John
-- Jeffrey Schiffel
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (01)
|