Hi Debbie --
You wrote...
...values in the tables either are up
to date and meet the standard or not. The title of the table is not as
important as the inner details. Isn't it easier to weight or recognize
numeric values ahead of word meanings?
Actually, you can combine numeric and word reasoning in executable English, just as you can in ordinary English.
An example is
www.reengineeringllc.com/demo_agents/BlackScholes1.agent
Do you have a few paras describing your task, together with some sample (obfuscated) data?
If so, please send it off-list, and I can test to see if executable English would be useful.
If it does turn out to be useful, we can report the results on the list.
Thanks, -- Adrian
Internet Business Logic (R)
A Wiki for Executable Open Vocabulary English
Online at www.reengineeringllc.com Shared use is free
Adrian Walker
Reengineering
Phone: USA 860 830 2085
On 2/26/07, Deborah MacPherson <debmacp@xxxxxxxxx> wrote:
Hi Adrian and Cory -
My problem with the approach below is that most of the information I
am working with and trying to keep organized is not expressed
completely through words.
"The proper syntax" is assembling only the most current sets of
drawings and schedules/tables. The values in the tables either are up
to date and meet the standard or not. The title of the table is not as
important as the inner details. Isn't it easier to weight or recognize
numeric values ahead of word meanings? Also, and maybe this is where
architects need to increase or enrich our vocabulary. Many elements
are called the same thing.
Debbie
On 2/25/07, Adrian Walker <
adriandwalker@xxxxxxxxx> wrote:
> 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
> >
> > ________________________________
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
> [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx
] On Behalf
> Of Adrian Walker
> > Sent: Saturday, February 24, 2007 1:18 PM
> >
> > To: [ontolog-forum]
> > Subject: Re: [ontolog-forum] vague wish lists VS formal specifications
> >
> >
> >
> > 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
>
>
>
--
*************************************************
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 (01)
|