[Top] [All Lists]

Re: [ontolog-forum] language ambiguity

To: "Schiffel, Jeffrey A" <jeffrey.a.schiffel@xxxxxxxxxx>
Cc: ontolog-forum@xxxxxxxxxxxxxxxx
From: "Adrian Walker" <adriandwalker@xxxxxxxxx>
Date: Thu, 14 Feb 2008 17:10:58 -0500
Message-id: <1e89d6a40802141410v7f8880bdtd1a22b0b0908cc0e@xxxxxxxxxxxxxx>
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

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

        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.

        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
        the heading of a table, or (c) a predefined sentence.... You may
        to consider the sentence in some-month the refinery some-name
        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


        and there's a paper about it


        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

        On 2/13/08, Schiffel, Jeffrey A <jeffrey.a.schiffel@xxxxxxxxxx>

                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,


                > 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
                > everybody can agree to.
                > It's not a matter of politeness, but the normal course
                > developing a vague idea into a finished design, which
                > 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

                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

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

<Prev in Thread] Current Thread [Next in Thread>