Hi Cory --
Thanks for your quick reply. I see that this subject is so
interesting that it's worth our weekend time. Surely a good sign
(:-)
You wrote...
The structured English approach I am most familiar with is SBVR and would be interested in how they relate.
Actually, the Executable English supported by the Internet Business
Logic system is not structured in the usual sense. The vocabulary
is open, and so is most of the syntax. So, the technology is
different from controlled/structured English. Some key
differences between EE and SBVR are described in the presentation
www.reengineeringllc.com/Business_Rules_and_OMG_SBVR_Presentation.pdf
It would also be of interest (to us)
if it could use the semantic web infrastructure (RDF more than OWL)
since that has a better chance of fitting into a familure distributed
knowledge infrastructure where we can give concepts with well defined
identity (regardless of the logic used).
The example
www.reengineeringllc.com/demo_agents/RDFQueryLangComparison1.agent
shows how to work with RDF. There are further RDF and OWL
examples in the same directory. The system can automatically
generate and run SQL over a networked triple store (such as the one
supported by new versions of Oracle). The generated SQL can be
much more complex than could be written reliably by hand, but the
results of running it can be explained in English, at the business of
scientific level.
When trying to help people be precise and consistent we find
semi-structured methods better than "type stuff here". Also "type
stuff here" is not very efficient for making similar statements about
many things. We also like to do some things with pictures - much more
efficiently than writing lots of text.
Yes, pictures are great for summarizing, but in general they don't
contain enough information to specify an application. So then,
the choice is to let programmers fill in the details according to their
own best guesses, or to provide some accompanying non-executable
English to guide them. A less error-prone approach is to write
executable English and to test and refine it in a tight loop.
So I guess the question is, what is
the relationship between the [Internet Business] logic [system], the
syntax and other forms of _expression_ - including standard forms,
tables, graphics and those being developed for the SW?
As described above, RDF fits nicely, as does one of the OWL
syntaxes. Tables are, well, tables. A key difference is
that the Internet Business Logic system supports closed world
negation. Thus, if you want to know for sure whether or not Cory
works for MIT, you avoid the open world negation situation where you
have to list both who works for MIT and also all the people in the world who don't work for MIT.!
This is also a difference with SBVR. However, when open world negation
is required for SW purposes, there is a rather neat and user friendly
way of supporting it in the Internet Business Logic system.
I hope you may have time to go hands on the system. It's online
at the site below, and shared use if free. There are examples
that you can view run and change. You are welcome to write and
run your own examples, but be aware that anyone on the web can view,
run, and change anything you write into the shared space.
Cheers, -- Adrian
Adrian Walker, Reengineering
Internet Business Logic (R)
A Wiki for Executable Open Vocabulary English
Online at www.reengineeringllc.com Shared use is free
Having the capacity to produce and interpret English text to/from your
logic is great. What I am not convinced of is that the logic
should be built around such syntactic structures or that it is the only
means of expressing information. While a great deal of
information is in natural language, a great deal is also in
semi-structured forms - tables, lists, forms, diagrams, etc. The
underlying logic should support multiple forms of _expression_.
When trying to help people be precise and consistent we find these
semi-structured methods better than "type stuff here". Also "type
stuff here" is not very efficient for making similar statements about
many things. We also like to do some things with pictures - much
more efficiently than writing lots of text.
So I guess the question is, what is the relationship between the logic,
the syntax and other forms of _expression_ - including standard forms,
tables, graphics and those being developed for the SW?
On 2/24/07, Cory Casanave <cory-c@xxxxxxxxxxxxxxxxxxxxxxx
> wrote:
Adrian,
Based on your prior posts I thought that comment may make
you pop up! The structured English approach I am most familure with is
SBVR and would be interested in how they relate. It would also be of
interest (to us) if it could use the semantic web infrastructure (RDF more than
OWL) since that has a better chance of fitting into a familure distributed
knowledge infrastructure where we can give concepts with well defined identity
(regardless of the logic used).
Having the capacity to produce and interpret English text
to/from your logic is great. What I am not convinced of is that the logic
should be built around such syntactic structures or that it is the only means of
expressing information. While a great deal of information is in natural
language, a great deal is also in semi-structured forms - tables, lists, forms,
diagrams, etc. The underlying logic should support multiple forms of
_expression_. When trying to help people be precise and consistent we find
these semi-structured methods better than "type stuff here". Also "type
stuff here" is not very efficient for making similar statements about many
things. We also like to do some things with pictures - much more
efficiently than writing lots of text.
So I guess the question is, what is the relationship
between the logic, the syntax and other forms of _expression_ - including standard
forms, tables, graphics and those being developed for the
SW?
-Cory
Hi Cory --
You wrote...
I am very encouraged by the "web 2.0" style
of
community involvement. If we see our knowledge
base as a community
resource that evolves with the participation of all
the stakeholders and
as it does so captures, refines and expands their
knowledge - we have
that humanistic coloring book you seem to be calling
for. If we can
then ground that community resource, wherever
possible, in well founded
theory we can start to bring together the hard-edges
of formal methods
with wide-scale involvement.
As
mentioned in our recent discussion about Jim Schoening's paper, there is a
way of supporting what you are calling for here. Hopefully it may be
useful in this discussion too.
As you know, the slogan is
"Executable English", in a Wiki-like system that supports communities as they
write their wish lists into a browser, *run* them, and refine them till they
become readable and runnable English specifications.
The
underlying server system encapsulates a theory of declarative knowledge --
described in papers with lots of theorems and proofs and a correspondingly small
readership (:-). But, to write for the system, you don't have to know the
theory, because it is, well, encapsulated. You just have to know how to
write down what you want in English, to run it, and to refine it in the light of
the results.
The key of course is to make the English executable, without
resorting to the brittleness of "controlled English". Then, writers get
immediate feedback about the consequences of what they write, rather than the
usual waterfallish situation in which it's difficult and expensive to change a
spec.
The system online at the site below is emerging technology that
does this. The underlying theory of declarative knowledge is referenced in
the FAQs at the same site.
Thanks for comments from folks in this
discussion, and apologies to those who have seen this
before.
Cheers, -- Adrian
Adrian Walker, Reengineering
Internet
Business Logic (R)
A Wiki for Executable Open Vocabulary English
Online at
www.reengineeringllc.com
Shared use is free
On 2/23/07, Cory
Casanave <cory-c@xxxxxxxxxxxxxxxxxxxxxxx>
wrote:
Debbie,
Marketing
hype aside I am very encouraged by the "web 2.0" style of
community
involvement. If we see our knowledge base as a
community
resource that evolves with the participation of all the
stakeholders and
as it does so captures, refines and expands their
knowledge - we have
that humanistic coloring book you seem to be calling
for. If we can
then ground that community resource, wherever
possible, in well founded
theory we can start to bring together the
hard-edges of formal methods
with wide-scale involvement. One
thing we have been working on lately
is trying to express architectures
more in this way - like a resource
and, sometimes, like a "wiki" that is
part of the communities body of
knowledge. We can sometimes get
caught up in our notations and theories
and in doing so obscure the
essential information.
One thing I have learned about languages and
tools is that they are not
sufficient, they need to be seeded with well
developed starting places
and parts that can be used, refined and
integrated. This is the
attraction of resources like Cyc, Dolce
or Wordnet - we don't have to
start from a blank page. Add to
this the body of knowledge in
architectures, models and domain ontologies
and we have a lot to draw
from - a very rich
heritage. Unfortunately the resources are very tied
to their
formalism and not so easily reused across that boundary.
Perhaps we
need to find a way to focus on the concepts (as understood by
real people)
that are then formalized in multiple ways, rather than
assuming life starts
with a particular logic/model/theory/design?
Perhaps this also suggests
contracting and design is less of a
"procedure" and more of a
culture? How can we encourage and enable
that
culture?
-Cory
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Deborah
MacPherson
Sent: Friday, February 23, 2007 5:31
PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] vague wish lists VS
formal specifications
Every single one of these reasons below is
driving my own vague wish for
a standardized contracting and design
procedure.
What if the chief designer is out sick for a
month?
It can be difficult and tedious to fill in blanks and answer
questions
outside your area of expertise but its better for users to go
through
some anxiety before the engineers start
designing/specifying.
Just a guess and I could be wrong, but maybe
everyone is starting out
with blank sheets and arguing about the same words
again every time.
It needs to be more like a coloring book/dictionary -
some lines, nodes,
and definitions already in
place.
Debbie
On 2/23/07, Cory Casanave <cory-c@xxxxxxxxxxxxxxxxxxxxxxx>
wrote:
> I going to take position that may get me in real trouble on
this list;
> The need to embrace vague wish lists.
>
>
I have a vague wish: I wish users would state their requirements more
>
precisely. I could even state this as a policy or
requirement. Such
> vague requirements can cause contracts to
be paid or not or could land
> you in jail. Of course to
the person stating the "wish", it is clear.
> It has an
intent. It may have authority.
>
> There are multiple
things we can do with such wishes; a) We can state
>
them more precisely (Regardless of the language used to do so). B) We
>
can create derivative statements (E.G. If you are going to state
>
requirements better you need to be able to express yourself precisely
>
in some language). C) We can design tests to see if the wish is
being
> fulfilled and D) We can create designs proposing
to fulfill the wish.
>
> In all cases the additional information
is with respect to the Vague
> wish - it is still the speech act that,
in the speakers mind, started
> all this derivative
work. This this "fact", as fuzzy as it may be, is
> a
crucial part of the linage developed in various formalisms or
designs.
> We can't loose this linage or the intent of the speaker
in the context
> from which it is stated. So vague wishes
have to be integrated as
> part of the knowledge base and our formal
models traceable to them.
> Hopefully our formal expressions can be
interpreted in such a way that
> they speak to the originator such
that they can say "Yes, that is
> exactly what I intended to say - thank
you for restating it so well".
>
> If our formal expressions
can't be interpreted by the casual user as a
> better re-statement
of their intent we have no feedback loop -
> ontologies CAN NOT be
buried in the depths of an application, they are
> front-and-center
expressions of our knowledge about a domain and can
> only succeed where
they can, at lease, be understood by the domain
> expert. (I
don't mean read in the raw form, any kind of presentation
> is just
fine). To be really useful the domain expert should be able
>
to MAKE statements that are fully precise - because architecture and
>
design is a participatory sport, the more who participate the better.
> So our methods & tools have to help them here, to assist in
the
> process of precise statement.
>
> This is not to say
there is no room for the professional, there is
> always room for the
great designer who can suck it all in and produce
> the great
result. There is also always room for the expert able to
>
take a vague statement and make it precise (in any language, from law
>
to FOL). But these experts are there to aid in the process, not be
> the process - so our tools and methods have to embrace the casual
user
> and vague statements and help capture these and then more
fully
> develop and refine them to be more precise and to impact the
designs
> that will realize them.
>
> So part of the point
is that such core intent, no matter how poorly
> expressed, are the
statements that we are refining, formalizing and
> creating designs to
satisfy. The vague wishes are part of the
> knowledge
base. To the person making the statement, all the logics,
>
modeling languages and other formalisms are just tools to capture
what
> they were saying all along.
>
> -----Original
Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
>
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx
] On Behalf Of Deborah
> MacPherson
> Sent: Friday, February
23, 2007 3:41 PM
> To: [ontolog-forum]
> Subject: Re:
[ontolog-forum] vague wish lists VS formal specifications
>
>
There are probably very few really good chief designers then.
>
>
Debbie
>
> On 2/23/07, John F. Sowa <sowa@xxxxxxxxxxx> wrote:
> >
Debbie,
> >
> > Yes, but it's necessary to know why the user
must participate:
> >
> > > I ... want to
emphasize the point is to have the end user >
> >
participate in the design process.
> >
> > The users'
participation is essential to educate the chief designer,
> >
who must fully understand the problem.
> >
> > The users can
never discover all the details of what might be
> >
possible
>
> > unless they become technologists -- and in most
cases, that is not
> > practical. Therefore, the chief
designer must learn from the user
> > (without prefiltering by
managers, planners, and requirements
> > surveys).
>
>
> > John
> >
> >
> >
>
>
> >
_________________________________________________________________
> >
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
>
>
> >
>
>
> --
>
>
*************************************************
>
> Deborah
MacPherson
> www.accuracyandaesthetics.com
>
www.deborahmacpherson.com
>
>
The content of this email may contain private confidential
information.
> Do not forward, copy, share, or otherwise distribute
without explicit
> written permission from all
correspondents.
>
>
**************************************************
>
>
_________________________________________________________________
>
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
>
>
>
_________________________________________________________________
>
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
>
>
--
*************************************************
Deborah MacPherson
www.accuracyandaesthetics.com
www.deborahmacpherson.com
The
content of this email may contain private confidential information.
Do not
forward, copy, share, or otherwise distribute without explicit
written
permission from all
correspondents.
**************************************************
_________________________________________________________________
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
_________________________________________________________________
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
_________________________________________________________________
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
_________________________________________________________________
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)
|