The need for procedural attachment is also a central requirement in what I
view as the primitives-based foundation ontology (PIFO) tactic for accurate
semantic interoperability. The procedures are required for proper
"grounding" of the meanings of the symbols, in procedural methods for both
perceptions and actions; in effect, the meanings will only be properly and
fully grounded when the computers have sufficient perceptual and robotic
capabilities to recognize objects and actions and perform actions that are
labeled by the symbols being used in an ontology. Clearly, this capability
is still rather a way off in the future. For the near-term, the "grounding"
such as it is will consist of actions that computers can take now (e.g.
search the web for information or look into a database, or query some
sensors that may be local or remote). This is similar to the "procedural
semantics" discussed by Woods since 1967. For perceptions and actions that
are not now automatically implementable, a PIFO should have, in addition to
its formal logical specifications, sufficient text documentation for each
symbol so that a human can understand what perceptions and actions are
required to verify the veracity of an assertion; in effect, for now the
humans who use an ontology can serve as a component of the meaning-grounding
"procedural attachments" of an ontology. This part of the documentation has
no formal force, but in addition to providing guidance for usage of the
ontology, also serves as a guide to what is needed for future development of
a more automated system. (01)
The implication of this tactic is that, the physical tools that do the
perceiving and acting will need to be carefully specified and standardized.
Among such "tools" will be those that attempt to replicate human perceptions
and action capabilities, to grasp the meanings of what people say they can
see, hear, and do. (02)
But before we ever get to the point where we can consider standardized
procedural attachments, I would imagine that we would first need some broad
agreement on the symbolic ontology components for a common foundation
ontology. As I have mentioned on many occasions, I believe that is quite
feasible if we adopt the semantic primitives approach to keep the common
ontology as small as possible. But we seem to be a long way even from that.
It may be that a detailed discussion of procedural semantics is a little
premature in the ontology context. (03)
Pat (04)
Patrick Cassidy
MICRA Inc.
cassidy@xxxxxxxxx
908-561-3416 (05)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F Sowa
Sent: Sunday, December 09, 2012 1:02 PM
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: Re: [ontolog-forum] Hybrid Reasoning Literature / Systems / Model
Theory (06)
On 12/8/2012 7:03 PM, Obrst, Leo J. wrote:
> There is limited research in general for denotational
> semantics of procedural programming. (07)
There has been an enormous amount of research in that area, but
it usually depends on a special language for writing the procedures: (08)
1. Formal specifications: The Vienna Definition Language (VDL) was
a logic-based language and methodology (VDM) that was started by
Heinz Zemanek in the 1960s. Their most notable achievement was
the formal definition of PL/I, which led to important changes in
the language. They used an axiomatic method for specifying an
abstract machine that executed the language. This method is
logic-based, but it's not really denotational semantics. (09)
2. Scott-Strachey denotational semantics: In the early 1970s,
Dana Scott worked at Oxford U. with Christopher Strachey
on denotational semantics. Scott earned his PhD at Princeton
with Alonzo Church as his thesis adviser. It's no coincidence
that he based the semantics on lambda calculus. Joseph Stoy
wrote a book on that semantics (1977). (010)
3. Hoare Logic: Tony Hoare developed a system for representing,
analyzing, and reasoning about programs. It's based on
"Hoare Triples": (011)
{Preconditions} Command {Postconditions} (012)
Then he developed methods for relating the preconditions and
postconditions of any procedure to those of each command or
subprocedure in it. When such procedures are combined with logic,
the preconditions and postconditions can be added to the axioms
of the ontology. For example, Peano's axioms could specify the
arithmetic operators that are implemented procedurally. (013)
4. Functional programming: A function is a formal object in logic,
and it can also be implemented efficiently on a digital computer.
Functional programming is a method of creating programs as pure
functions defined as the composition of more primitive functions.
The resulting program *is* a logical expression that has a well-
defined denotation. McCarthy designed LISP as a functional
language, but the "scruffies" added a lot of procedural stuff. (014)
5. Logic programming: This is a relation-based alternative to
functional programming. Cordell Green proposed it in 1969.
Prolog is the most widely known version, but it has a lot
of procedural features. But there are more pure versions. (015)
6. Pi calculus. This is Robin Milner's method for specifying
concurrent systems that pass messages among themselves.
Milner describes it as the concurrent extension to lambda
calculus: any function can be implemented by message passing,
but pi calculus is much more flexible and extensible. (016)
At VivoMind, we use a method of message passing that implements
a version of pi calculus for message passing among independent
modules or agents. For a purely formal system, the agents would
have to be specified by some pure version of functional or
logic programming. (017)
In practice, it's necessary to accommodate legacy systems and
anything anyone might invent in the future. That would limit
the ability to prove everything formally. But it's still possible
to do some useful reasoning: (018)
1. Every module would have some specified constraints (preconditions
and postconditions) on what it does with messages. (019)
2. But these constraints would be *underspecified*. Any module
might have side effects that other modules might not know. (020)
3. This is a realistic approach that is better than what we have
today, but requiring total specifications of what each module
does is impossible to achieve. (021)
4. Furthermore, privacy and security reasons would make total
knowledge undesirable or even dangerous. (022)
John (023)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (024)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (025)
|