How to not to design an NLP system

[John F. Sowa]

At the end of this note is an announcement of a conference on UIMA
(Unstructured Information Management Architecture).  I strongly
agree with the opening sentence of the note:

 > For many decades, NLP has suffered from low software engineering
 > standards causing a limited degree of re-usability of code and
 > interoperability of different modules within larger NLP systems.

Unfortunately, I have serious misgivings about the UIMA approach:

http://incubator.apache.org/uima/downloads/releaseDocs/2.2.2-incubating/docs/html/tutorials_and_users_guides/tutorials_and_users_guides.html

As their general representation, they use "typed Feature Structures,
which are are simply data structures that have a type and a set of
(attribute, value) pairs."

In conceptual graphs, a feature structure corresponds to a one-level
tree that consists of one concept node linked by binary relations
(called 'attributes') to other concept nodes (called 'values').
Another name for that kind of tree is 'frame'.

Such representations are widely used for NLP, but they obscure the
global structure.  People who use them think about little trees and
miss the forest.  Conceptual graphs focus on larger structures and
operations, such as the canonical formation rules, query graphs,
projections, and maximal joins.  Those operations can process
arbitrarily large areas of the forest in one logical step.

Although frames and feature structures are a lower-level notation
than CGs, many implementations are fairly efficient.  But the UMIA
gang decided to add "structure" to the frames: they represent trees
externally in XML and internally as instantiations of a separate
Java class for each type of tree (frame or feature structure).

I am all in favor of good architectures for intelligent systems.
That was the title of a paper I published in 2002:

    http://www.jfsowa.com/pubs/arch.htm

In that architecture, the focus is on the Flexible Modular Framework
(FMF), not on the details of notations and programming languages.
Although I like CGs, nothing in the FMF depends on CGs.  Feature
structures, frames, and XML could also be used, because such details
can easily be accommodated in any sufficiently flexible framework.

Although we use Java to implement the FMF, nothing in the FMF depends
on Java.  We also use Prolog and C++, but the FMF is completely neutral
to any of those details.  One field of the FMF message format specifies
the language (which could be any natural or artificial language of
any kind), and another field specifies the speech act.  Any computer
hardware or software could be converted to an FMF module by putting
a wrapper around it to map all I/O operations to FMF messages.

For architectures of any kind, form must follow function.  In my talk
at ICCS'09, I'll address the question of how to implement Minsky's
Society of Mind.  That is the ultimate goal, and the design of every
form in the architecture must address that goal.  The FMF is a part
of the architecture because it supports the ultimate goal.  Those
who begin with the goal of using XML and Java classes are lost
at the first step.

John Sowa

-------- Original Message --------
Subject: [Corpora-List] Germany: 2nd UIMA@GSCL Workshop - 2nd CFP
Date: Tue, 16 Jun 2009 10:07:30 +0200
From: Katrin Tomanek <tomanek@...>
Reply-To: tomanek@...
To: Corpora List <CORPORA@...>

================================================================================

Second Call for Papers
Unstructured Information Management Architecture (UIMA)
2nd UIMA@GSCL Workshop

September 30, 2009
Potsdam, Germany

http://www.ling.uni-potsdam.de/acl-lab/gscl09/workshops.de.html

================================================================================

** NEWS: a one-hour beginners tutorial on UIMA will be held prior to the
workshop at the same day **

For many decades, NLP has suffered from low software engineering standards
causing a limited degree of re-usability of code and interoperability of
different
modules within larger NLP systems. While this did not really hamper success
in limited task areas (such as implementing a parser), it caused serious
problems for the emerging field of language technology where the focus is on
building complex integrated software systems, e.g., for information
extraction
or machine translation. This lack of integration has led to duplicated
software
development, work-arounds for programs written in different (versions of)
programming languages, and ad-hoc tweaking of interfaces between modules
developed at different sites.

In recent years, the Unstructured Information Management Architecture (UIMA)
framework has been proposed as a middleware platform which offers
integration by
design through common type systems and standardized communication
methods for
components analysing streams of unstructured information, such as natural
language. The UIMA framework offers a solid processing infrastructure that
allows developers to concentrate on the implementation of the actual
analytics
components. An increasing number of members of the NLP community thus have
adopted UIMA as a platform facilitating the creation of reusable NLP
components
that can be assembled to address different NLP tasks depending on their
order,
combination and configuration.

This workshop aims at bringing together members of the NLP community
that are
users, developers or providers of either UIMA components or UIMA-related
tools
in order to explore and discuss the opportunities and challenges in
using UIMA
as a platform for modern, well-engineered NLP. In the context of an emerging
NLP-oriented UIMA community, the challenge to create not only reusable,
but also
interoperable components raises particular interest. From a methodological
perspective, interoperability relies largely on UIMA type systems.
Technically,
it includes issues related to the packaging and distribution of UIMA
components.
Also, tools are important, for example to assemble complex processing work
flows, to manage the bodies of data that are to be analysed and to
visualize,
explore, and further deploy the analysis results. Finally,
interoperability is
also affected by legal issues, such as potentially incompatible licenses of
components and tools.

The availability of ready-to-use components plays a major role in
choosing UIMA
over other alternatives. To accentuate this, the workshop puts a focus on
UIMA-based components and tools that are freely available for research.

======
Topics
======

Participants are invited to present applications realized using UIMA,
general
experiences using UIMA as a platform for natural language processing, as
well as
technical papers on particular aspects of the UIMA framework.
Alternatives to
and comparisons of other frameworks with UIMA are of interest, too. More
specifically, workshop topics include, but are not limited to:

     * UIMA components with a special focus on genericity and type-system
       independence
     * repositories of ready-to-use UIMA-based components
     * (generic) type systems for UIMA
     * distribution of UIMA components: documentation, licensing and
packaging
     * sophisticated tools to build and manage complex processing pipelines
     * experience reports combining UIMA-based components from different
sources,
       as well as solutions to interoperability issues
     * processing of very large data collections: scale-out,
parallelization, and
       performance optimization
     * analysis of results: exploration, evaluation, visualization, and
       statistical analysis
     * developing for UIMA: simplified APIs, debugging, unit testing, and
       limitations of UIMA

===========
Submissions
===========

We invite submissions of full papers, limited to 8 pages of text, and
position
papers or papers describing ongoing work as short papers, limited to 4
pages.
Both kinds of papers will be orally presented. Double submissions (whether
verbatim or in essence) should indicate this fact and name the workshop or
conference event also addressed. Reviewing will not be anonymous but authors
wishing to keep their anonymity may hide their identity on demand.

All submissions must be in English and follow the Springer LNCS style
[1] and
should be created using LaTeX. Submissions must be sent in PDF format to
uima.gscl2009@... no later than July, 6th.

Accepted submissions will appear in the GSCL conference proceedings.

[1] http://www.springer.com/computer/lncs?SGWID=0-164-7-72376-0

===============
Important Dates
===============

July, 6 : Submission deadline
July, 20: Notification of acceptance
July, 28: Camera-ready copies due
Sept, 30: Workshop held in Potsdam in conjunction with GSCL

======================
Organizers and Contact
======================

     * JULIE Lab, Friedrich-Schiller-Universität Jena
        * Udo Hahn
        * Katrin Tomanek
     * UKP Lab, Technische Universität Darmstadt
        * Iryna Gurevych
        * Richard Eckart de Castilho

Please address any inquiries regarding the workshop to:
uima.gscl2009@...

=================
Program Committee
=================

    * Anni R. Coden, IBM T.J. Watson Research Center, USA
    * Branimir K. Boguraev, IBM T.J. Watson Research Center, USA
    * Graham Wilcock, University of Helsinki, Finland
    * Dietmar Rösner, University of Magdeburg, Germany
    * Iryna Gurevych, Technische Universität Darmstadt, Germany
    * Katrin Tomanek, Friedrich-Schiller-Universität Jena, Germany
    * Leo Ferres, University of Concepcion, Chile
    * Michael Tanenblatt, IBM T.J. Watson Research Center, USA
    * Nicolas Hernandez, Université de Nantes, France
    * Philipp Cimiano, Delft University of Technology, Netherlands
    * Richard Eckart de Castilho, Technische Universität Darmstadt,
      Germany
    * Sophia Ananiadou, University of Manchester, Great Britain
    * Stefan Geißler, TEMIS GmbH, Germany
    * Udo Hahn, Friedrich-Schiller-Universität Jena, Germany

=====
Links
=====

    * http://www.ling.uni-potsdam.de/acl-lab/gscl09/
    * http://incubator.apache.org/uima
    * http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=uima
    * http://www.julielab.de/
    * http://www.ukp.tu-darmstadt.de/
    * http://u-compare.org/



---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Jon Awbrey]

Haven't you heard, Minsky's has been raided --

To wit -- http://wikipedia.org/

And the Society of Mind turns out to be
a contradiction in terms.

Have a Happy Bloomsday!

Jon

--

inquiry list: http://stderr.org/pipermail/inquiry/
mwb: http://www.mywikibiz.com/Directory:Jon_Awbrey
knol: http://knol.google.com/k/-/-/3fkwvf69kridz/1


---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[John F. Sowa]

Jon,

That depends on how you define the terms 'society' and 'mind':

JA> And the Society of Mind turns out to be a contradiction in terms.

Many different definitions of each have been proposed, used, and
rejected over the past many centuries.

My personal preference follows Peirce:  mind is a composite sign
that consists of the totality of all signs that we experience
during the course of a lifetime.

For society, I like definition 3a of the Merriam-Webster 10th
Collegiate:

    an enduring and cooperating social group whose members have
    developed organized patterns of relationships through
    interactions with one another.

For the individuals in a society, the MW 10th includes plants
and insects.  I would generalize that option to include anything
that could be with a mind or quasi-mind (as Peirce would call
it).  That would include robots, angels, and various kinds of
artificial agents.

For more about Minsky's society of mind, I recommend the survey
article by Push Singh:

    http://web.media.mit.edu/~push/ExaminingSOM.html
    Examining the Society of Mind

John


---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[S. D. Cook]

John,

I am very interested in this and more...please provide me more  
references and sources.

Also, when will you be in the area

Steve
Sent from my iPhone
202.256.7531


On Jun 16, 2009, at 8:16 AM, "John F. Sowa" <sowa@...> wrote:

> At the end of this note is an announcement of a conference on UIMA
> (Unstructured Information Management Architecture).  I strongly
> agree with the opening sentence of the note:
>
> > For many decades, NLP has suffered from low software engineering
> > standards causing a limited degree of re-usability of code and
> > interoperability of different modules within larger NLP systems.
>
> Unfortunately, I have serious misgivings about the UIMA approach:
>
> http://incubator.apache.org/uima/downloads/releaseDocs/2.2.2-incubating/docs/html/tutorials_and_users_guides/tutorials_and_users_guides.html
>
> As their general representation, they use "typed Feature Structures,
> which are are simply data structures that have a type and a set of
> (attribute, value) pairs."
>
> In conceptual graphs, a feature structure corresponds to a one-level
> tree that consists of one concept node linked by binary relations
> (called 'attributes') to other concept nodes (called 'values').
> Another name for that kind of tree is 'frame'.
>
> Such representations are widely used for NLP, but they obscure the
> global structure.  People who use them think about little trees and
> miss the forest.  Conceptual graphs focus on larger structures and
> operations, such as the canonical formation rules, query graphs,
> projections, and maximal joins.  Those operations can process
> arbitrarily large areas of the forest in one logical step.
>
> Although frames and feature structures are a lower-level notation
> than CGs, many implementations are fairly efficient.  But the UMIA
> gang decided to add "structure" to the frames: they represent trees
> externally in XML and internally as instantiations of a separate
> Java class for each type of tree (frame or feature structure).
>
> I am all in favor of good architectures for intelligent systems.
> That was the title of a paper I published in 2002:
>
>   http://www.jfsowa.com/pubs/arch.htm
>
> In that architecture, the focus is on the Flexible Modular Framework
> (FMF), not on the details of notations and programming languages.
> Although I like CGs, nothing in the FMF depends on CGs.  Feature
> structures, frames, and XML could also be used, because such details
> can easily be accommodated in any sufficiently flexible framework.
>
> Although we use Java to implement the FMF, nothing in the FMF depends
> on Java.  We also use Prolog and C++, but the FMF is completely  
> neutral
> to any of those details.  One field of the FMF message format  
> specifies
> the language (which could be any natural or artificial language of
> any kind), and another field specifies the speech act.  Any computer
> hardware or software could be converted to an FMF module by putting
> a wrapper around it to map all I/O operations to FMF messages.
>
> For architectures of any kind, form must follow function.  In my talk
> at ICCS'09, I'll address the question of how to implement Minsky's
> Society of Mind.  That is the ultimate goal, and the design of every
> form in the architecture must address that goal.  The FMF is a part
> of the architecture because it supports the ultimate goal.  Those
> who begin with the goal of using XML and Java classes are lost
> at the first step.
>
> John Sowa
>
> -------- Original Message --------
> Subject: [Corpora-List] Germany: 2nd UIMA@GSCL Workshop - 2nd CFP
> Date: Tue, 16 Jun 2009 10:07:30 +0200
> From: Katrin Tomanek <tomanek@...>
> Reply-To: tomanek@...
> To: Corpora List <CORPORA@...>
>
> ===
> ===
> ===
> ===
> ====================================================================
>
> Second Call for Papers
> Unstructured Information Management Architecture (UIMA)
> 2nd UIMA@GSCL Workshop
>
> September 30, 2009
> Potsdam, Germany
>
> http://www.ling.uni-potsdam.de/acl-lab/gscl09/workshops.de.html
>
> ===
> ===
> ===
> ===
> ====================================================================
>
> ** NEWS: a one-hour beginners tutorial on UIMA will be held prior to  
> the
> workshop at the same day **
>
> For many decades, NLP has suffered from low software engineering  
> standards
> causing a limited degree of re-usability of code and  
> interoperability of
> different
> modules within larger NLP systems. While this did not really hamper  
> success
> in limited task areas (such as implementing a parser), it caused  
> serious
> problems for the emerging field of language technology where the  
> focus is on
> building complex integrated software systems, e.g., for information
> extraction
> or machine translation. This lack of integration has led to duplicated
> software
> development, work-arounds for programs written in different  
> (versions of)
> programming languages, and ad-hoc tweaking of interfaces between  
> modules
> developed at different sites.
>
> In recent years, the Unstructured Information Management  
> Architecture (UIMA)
> framework has been proposed as a middleware platform which offers
> integration by
> design through common type systems and standardized communication
> methods for
> components analysing streams of unstructured information, such as  
> natural
> language. The UIMA framework offers a solid processing  
> infrastructure that
> allows developers to concentrate on the implementation of the actual
> analytics
> components. An increasing number of members of the NLP community  
> thus have
> adopted UIMA as a platform facilitating the creation of reusable NLP
> components
> that can be assembled to address different NLP tasks depending on  
> their
> order,
> combination and configuration.
>
> This workshop aims at bringing together members of the NLP community
> that are
> users, developers or providers of either UIMA components or UIMA-
> related
> tools
> in order to explore and discuss the opportunities and challenges in
> using UIMA
> as a platform for modern, well-engineered NLP. In the context of an  
> emerging
> NLP-oriented UIMA community, the challenge to create not only  
> reusable,
> but also
> interoperable components raises particular interest. From a  
> methodological
> perspective, interoperability relies largely on UIMA type systems.
> Technically,
> it includes issues related to the packaging and distribution of UIMA
> components.
> Also, tools are important, for example to assemble complex  
> processing work
> flows, to manage the bodies of data that are to be analysed and to
> visualize,
> explore, and further deploy the analysis results. Finally,
> interoperability is
> also affected by legal issues, such as potentially incompatible  
> licenses of
> components and tools.
>
> The availability of ready-to-use components plays a major role in
> choosing UIMA
> over other alternatives. To accentuate this, the workshop puts a  
> focus on
> UIMA-based components and tools that are freely available for  
> research.
>
> ======
> Topics
> ======
>
> Participants are invited to present applications realized using UIMA,
> general
> experiences using UIMA as a platform for natural language  
> processing, as
> well as
> technical papers on particular aspects of the UIMA framework.
> Alternatives to
> and comparisons of other frameworks with UIMA are of interest, too.  
> More
> specifically, workshop topics include, but are not limited to:
>
>    * UIMA components with a special focus on genericity and type-
> system
>      independence
>    * repositories of ready-to-use UIMA-based components
>    * (generic) type systems for UIMA
>    * distribution of UIMA components: documentation, licensing and
> packaging
>    * sophisticated tools to build and manage complex processing  
> pipelines
>    * experience reports combining UIMA-based components from different
> sources,
>      as well as solutions to interoperability issues
>    * processing of very large data collections: scale-out,
> parallelization, and
>      performance optimization
>    * analysis of results: exploration, evaluation, visualization, and
>      statistical analysis
>    * developing for UIMA: simplified APIs, debugging, unit testing,  
> and
>      limitations of UIMA
>
> ===========
> Submissions
> ===========
>
> We invite submissions of full papers, limited to 8 pages of text, and
> position
> papers or papers describing ongoing work as short papers, limited to 4
> pages.
> Both kinds of papers will be orally presented. Double submissions  
> (whether
> verbatim or in essence) should indicate this fact and name the  
> workshop or
> conference event also addressed. Reviewing will not be anonymous but  
> authors
> wishing to keep their anonymity may hide their identity on demand.
>
> All submissions must be in English and follow the Springer LNCS style
> [1] and
> should be created using LaTeX. Submissions must be sent in PDF  
> format to
> uima.gscl2009@... no later than July, 6th.
>
> Accepted submissions will appear in the GSCL conference proceedings.
>
> [1] http://www.springer.com/computer/lncs?SGWID=0-164-7-72376-0
>
> ===============
> Important Dates
> ===============
>
> July, 6 : Submission deadline
> July, 20: Notification of acceptance
> July, 28: Camera-ready copies due
> Sept, 30: Workshop held in Potsdam in conjunction with GSCL
>
> ======================
> Organizers and Contact
> ======================
>
>    * JULIE Lab, Friedrich-Schiller-Universität Jena
>       * Udo Hahn
>       * Katrin Tomanek
>    * UKP Lab, Technische Universität Darmstadt
>       * Iryna Gurevych
>       * Richard Eckart de Castilho
>
> Please address any inquiries regarding the workshop to:
> uima.gscl2009@...
>
> =================
> Program Committee
> =================
>
>   * Anni R. Coden, IBM T.J. Watson Research Center, USA
>   * Branimir K. Boguraev, IBM T.J. Watson Research Center, USA
>   * Graham Wilcock, University of Helsinki, Finland
>   * Dietmar Rösner, University of Magdeburg, Germany
>   * Iryna Gurevych, Technische Universität Darmstadt, Germany
>   * Katrin Tomanek, Friedrich-Schiller-Universität Jena, Germany
>   * Leo Ferres, University of Concepcion, Chile
>   * Michael Tanenblatt, IBM T.J. Watson Research Center, USA
>   * Nicolas Hernandez, Université de Nantes, France
>   * Philipp Cimiano, Delft University of Technology, Netherlands
>   * Richard Eckart de Castilho, Technische Universität Darmstadt,
>     Germany
>   * Sophia Ananiadou, University of Manchester, Great Britain
>   * Stefan Geißler, TEMIS GmbH, Germany
>   * Udo Hahn, Friedrich-Schiller-Universität Jena, Germany
>
> =====
> Links
> =====
>
>   * http://www.ling.uni-potsdam.de/acl-lab/gscl09/
>   * http://incubator.apache.org/uima
>   * http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=uima
>   * http://www.julielab.de/
>   * http://www.ukp.tu-darmstadt.de/
>   * http://u-compare.org/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cg-unsubscribe@...
> For additional commands, e-mail: cg-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Rich Elk]

John F. Sowa wrote:

>... Peirce:  mind is a composite sign that consists of the totality of all
>signs that we experience during the course of a lifetime.

That definition leaves me unsatisfied.  I've followed your Peircean
discourses for a long time, and they seem to be slowly slipping between my
interstitial fluids.  So please explain a little more clearly why the
conceptual graph encodes signs in a more useful way than other display
rendering methods.  

Let me paraphrase your statement: "mind is a composite sign comprising the
totality of an agent's experiences, each experience comprising a set of
signs".  

Surely mind is more than JUST a composite sign comprising a plurality of
signs witnessed by one agent.  The ontology, when stored as a database, must
have lots of interrelationships, methods, other executable and descriptive
components.  All that FOL encoding we use on this list from time to time,
and that consists of relationships among signs, rather than solely
consisting of the signs themselves.  

Please explain if you don't mind helping the slower list members.  

-Rich

Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com




---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Jon Awbrey]

Partly just having some fun in cerebration of Bloomsday,
partly incited, less funnily, to more sober reflections
on the last 2009 - 1985 = 24 years of socially inspired
models in AI, which you know goes still further back to
Peirce, if not indeed Hobbes, and no doubt beyond.

But I'll have to save that for a non-Bloomsday ... anon.

Jon

John F. Sowa wrote:

> Jon,
>
> That depends on how you define the terms 'society' and 'mind':
>
> JA> And the Society of Mind turns out to be a contradiction in terms.
>
> Many different definitions of each have been proposed, used, and
> rejected over the past many centuries.
>
> My personal preference follows Peirce:  mind is a composite sign
> that consists of the totality of all signs that we experience
> during the course of a lifetime.
>
> For society, I like definition 3a of the Merriam-Webster 10th
> Collegiate:
>
>    an enduring and cooperating social group whose members have
>    developed organized patterns of relationships through
>    interactions with one another.
>
> For the individuals in a society, the MW 10th includes plants
> and insects.  I would generalize that option to include anything
> that could be with a mind or quasi-mind (as Peirce would call
> it).  That would include robots, angels, and various kinds of
> artificial agents.
>
> For more about Minsky's society of mind, I recommend the survey
> article by Push Singh:
>
>    http://web.media.mit.edu/~push/ExaminingSOM.html
>    Examining the Society of Mind
>
> John

--

inquiry list: http://stderr.org/pipermail/inquiry/
mwb: http://www.mywikibiz.com/Directory:Jon_Awbrey
knol: http://knol.google.com/k/-/-/3fkwvf69kridz/1


---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[John F. Sowa]

Rich,

Before responding to your note, I'd like to emphasize the point that
conceptual graphs are just one version of logic that was inspired by
both Peirce's work on logic and the AI work on semantic networks.

My note about UMIA was a comment about how the more compact AI
representations, which include LISP-based notations as well as
CGs, tend to be compact and efficient.  XML is a good notation
for tagging documents (which is what the GML, SGML, HTML, XML
family was designed for).

But for knowledge representation, the AI languages of LISP,
Prolog, and many versions that have followed them (which
includes CGs) are vastly more efficient than any kind of
XML-based notation.

Fundamental principle:  No one-size-fits-all approach to
language design is a good idea.  And a notation that expands
the size by an order of magnitude is definitely a bad idea.

JFS>> ... Peirce:  mind is a composite sign that consists of
 >> the totality of all signs that we experience during the course
 >> of a lifetime.

RE> That definition leaves me unsatisfied.  I've followed your
 > Peircean discourses for a long time, and they seem to be slowly
 > slipping between my interstitial fluids.  So please explain a
 > little more clearly why the conceptual graph encodes signs in
 > a more useful way than other display rendering methods.

My remark about the mind was in response to Jon Awbrey, and it is
unrelated to the previous discussion of UMIA.  We should discuss
them separately.

RE> Surely mind is more than JUST a composite sign comprising a
 > plurality of signs witnessed by one agent.  The ontology, when
 > stored as a database, must have lots of interrelationships,
 > methods, other executable and descriptive components.  All that
 > FOL encoding we use on this list from time to time, and that
 > consists of relationships among signs, rather than solely
 > consisting of the signs themselves.

Trying to explain Peirce's ideas succinctly is very difficult
because all of them are tightly interwoven with everything else
he said.  That makes it very hard to explain any single point
without getting into a long dissertation about everything else.

But to make it as short as I can, Peirce emphasized that
everything that passes through our minds (or the minds of
any animal, insect, robot, or extra terrestrial being)
is a sign.

By everything, he meant ***everything.***  Every feeling,
every sensation, every relationship among sensations, every
thought, every experience, every whim, wish, hope, fear,
or inclination is a sign.  And every possible relationship,
pattern, process, composite of or among signs is also a sign.

That does not mean he had a one factor theory, because he
also developed a very rich classification of all the signs
of signs, signs among signs, etc.

John



---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Arun Majumdar]

Hi,

I recommend a first reading:  
http://plato.stanford.edu/entries/peirce-semiotics/

Then, I offer the following comment:

While it is relatively trivial to define a logic for results that are
produced by an operating sign-system, it is much harder to characterize
the logic operating within the sign system to produce a result.

A good analogy is the now obsolete billiard-ball model of how atoms
interact when they react --- the reality (to the extent we know such a
reality) appears to be based in quantum physical descriptions where the
logic is determined by mutual probabilities under uncertainty of not
being able to enact a measurement without interfering in the logic of
the system (operations).

Molecules and proteins in a biological network of reactions in a living
cell constitute a "sign system" but we have made some headway in
understand those.

Much less progress has been made in understanding the sign-systems of
the human mind.

The benefit of conceptual graphs is that you have:

1) A graph structure --- this is significant and important because a
graph permits you to see the structure of knowledge in a skeletal
fashion --- you can see how concepts are proximate and the natural
grouping of related ideas.

2) A representation for logic --- this is also important because if a
representation is not useful to a computer then there is little other
than pretty pictures that you can draw

3) An embedding for "chunks" of knowledge --- this is what one might
call a "sign" in some sense to a "computer".  The chemists do not keep
molecular databases in RDF triples because the triple-structure destroys
the sign embodied in the chunk (which is actually greater than the mere
sum of its parts).  If you have ever watched a chemist at work, they
work with substantial structures --- for example, biochemists work with
whole amino acids, and the computers they use need direct graph
representations to capture the "sign" of the molecule --- this is an
area where most traditional computer science graduates have a hard time
because it is a blend of soft-science principles with hard-science
modeling within the knowledge domain for practical gain (i.e for
example, working on that new drug to cure cancer).

My last point, #3 is likely the hardest for me to explain --- but then,
I was originally trained as a biochemist.

Cheers,

Arun

Rich Elk wrote:

> John F. Sowa wrote:
>
>  
>> ... Peirce:  mind is a composite sign that consists of the totality of all
>> signs that we experience during the course of a lifetime.
>>    
>
> That definition leaves me unsatisfied.  I've followed your Peircean
> discourses for a long time, and they seem to be slowly slipping between my
> interstitial fluids.  So please explain a little more clearly why the
> conceptual graph encodes signs in a more useful way than other display
> rendering methods.  
>
> Let me paraphrase your statement: "mind is a composite sign comprising the
> totality of an agent's experiences, each experience comprising a set of
> signs".  
>
> Surely mind is more than JUST a composite sign comprising a plurality of
> signs witnessed by one agent.  The ontology, when stored as a database, must
> have lots of interrelationships, methods, other executable and descriptive
> components.  All that FOL encoding we use on this list from time to time,
> and that consists of relationships among signs, rather than solely
> consisting of the signs themselves.  
>
> Please explain if you don't mind helping the slower list members.  
>
> -Rich
>
> Sincerely,
> Rich Cooper
> EnglishLogicKernel.com
> Rich AT EnglishLogicKernel DOT com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cg-unsubscribe@...
> For additional commands, e-mail: cg-help@...
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Jon Awbrey]

Re: http://article.gmane.org/gmane.comp.ai.conceptual-graphs/2745

Everybody knows that all of the following are true:

1. Two heads are better than one.
2. Many hands make light work.
3. Too many cooks spoil the broth.
4. Fifty thousand hedge-fund investors can be wrong.

Obviously, the "architecture" part of our social-technical architectures
makes a big difference to the success of the result -- and yet there is
an overwhelming tendency among the celebrants of "social media systems"
today to throw up their hands and leave all that to the "invisible hand"
of the markup place.  And so the intelligence that it takes to make the
collective one wit more intelligent than the glob (greatest lower bound)
of its elemental intelligences goes missing from the linkage of the net.

Jon Awbrey

CC: Arisbe, Cybernetics, Inquiry

--

inquiry list: http://stderr.org/pipermail/inquiry/
mwb: http://www.mywikibiz.com/Directory:Jon_Awbrey
knol: http://knol.google.com/k/-/-/3fkwvf69kridz/1


---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[John F. Sowa]

Jon and Arun,

JA> Obviously, the "architecture" part of our social-technical
 > architectures makes a big difference to the success of the result
 > -- and yet there is an overwhelming tendency among the celebrants
 > of "social media systems" today to throw up their hands and leave
 > all that to the "invisible hand" of the markup place.

I agree.  I strongly believe that C. S. Peirce had a much more
solid foundation for the Semantic Web than the W3C or the Web 2.0
gang has been able to define.

JA> And so the intelligence that it takes to make the collective one
 > wit more intelligent than the glob (greatest lower bound) of its
 > elemental intelligences goes missing from the linkage of the net.

I certainly agree with that point.  Arun was making some points about
how CGs address the current limitations of the SemWeb, and I'd like
to add a few comments.

AM> I recommend a first reading:
 > http://plato.stanford.edu/entries/peirce-semiotics/

That is indeed a good survey, but I would add that the four
additional URLs at the bottom of that article point to many
of Peirce's original writings that are available on the WWW.

In particular, the dictionary of Peirce's terminology is a very
useful compendium of quotations by Peirce on a wide range of
topics:

    http://www.helsinki.fi/science/commens/dictionary.html

AM> The benefit of conceptual graphs is that you have:
 >
 > 1) A graph structure ---
 >
 > 2) A representation for logic ---
 >
 > 3) An embedding for "chunks" of knowledge...

The word 'chunk', which was introduced by Newell and Simon in the
1970s, is widely used in AI and cognitive psychology for a collection
of related information that is treated as a single unit.

As Arun said, the basic units of chemistry are atoms, but atoms
are much too small for many kinds of operations that chemists
want to perform.  They have several chunking methods:

  1. Molecules -- stable combinations of atoms.  Example:  H20.

  2. Radicals -- combinations of atoms that can be derived from
     a molecule by removing one or more atoms.  Ex: -CH3, the
     methyl radical formed by removing one H from methane, CH4.

  3. Chunks of chunks.  Example:  proteins are combinations of
     large numbers of molecules called amino acids.  DNA is a
     very big protein that combines smaller proteins that represent
     individual genes.

For his existential graphs, Peirce wanted a representation that
would show the "atoms and molecules" of logic.  In his day, the
motion pictures were just coming in, and he viewed the graphical
rules of inference on EGs as showing "moving pictures of thought".

Conceptual graphs are based on Peirce's EGs and rules of inference.
There are three kinds of chunking methods for CGs, each of which
is based on a related method that Peirce introduced for EGs:

  1. Names of instances:  The referent field of any concept can
     have a name that refers to the individual described by the
     conjunction of relations attached to that concept node.

  2. Types:  Any conceptual graph corresponds to a "molecule" of
     thought that can be translated to a sentence (or paragraph)
     in a natural language.  A lambda expression in CGs has the
     effect of "removing" the referents from N concept nodes
     from a CG and thereby defining a type of N-adic relation.
     A monadic lambda expression can also be used to define
     a concept type.

  3. Contexts.  Any CG (of arbitrary size) can be enclosed inside
     a concept node, which is called a 'context'.  That concept
     node may have a type label and a name.

These three chunking mechanisms support rich structures that can
support logic, inference rules, and representations natural
language sentences, contexts, and discourse relations among
contexts.  For a 22-page summary, see

    http://www.jfsowa.com/cg/cg_hbook.pdf

As Arun said, the Semantic Web lacks that chunking ability
and the structures and reasoning methods it supports.

However, we can remedy that weakness of the SemWeb by mapping
the current representations to CGs -- and that's what we're
doing at our company, VivoMind Intelligence, Inc.  The
resulting representations are not only more compact, they
are vastly more flexible, expressive, and efficient.

I believe that it is essential for us to lead the Semantic
Webbers to Tim B-L's promised land, which cannot be attained
with the current crop of SemWeb notations.

John Sowa


---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[Rich Elk]

Hi John,

I'm starting a new thread since we seem to have branched away from the
original topic.  You wrote:
========================================================
As their general representation, they use "typed Feature Structures,
which are are simply data structures that have a type and a set of
(attribute, value) pairs."

In conceptual graphs, a feature structure corresponds to a one-level
tree that consists of one concept node linked by binary relations
(called 'attributes') to other concept nodes (called 'values').
Another name for that kind of tree is 'frame'.

Such representations are widely used for NLP, but they obscure the
global structure.  People who use them think about little trees and
miss the forest.  Conceptual graphs focus on larger structures and
operations, such as the canonical formation rules, query graphs,
projections, and maximal joins.  Those operations can process
arbitrarily large areas of the forest in one logical step.
==========================================================

That description is very subjective; you seem to be viscerally
uncomfortable with the other stuff, and viscerally satisfied with
the cg diagrams.  But I still don't see the logic of why they are
better than something like IDEF0 with its highly structured rules
for composition of contexts.  

IDEF0 is a widespread, well known description taught to many
disciplines as a simple graphical design language.  It seems to me
that CGs are ONLY really useful to computational linguists.  Is there
so other use I'm not aware of that makes them stand out in value?
Why should I invest my energy into CGs instead of IDEF0s?

-Rich

 
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com



---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...

[John F. Sowa]

Rich,

RE> ... you seem to be viscerally uncomfortable with the other
 > stuff, and viscerally satisfied with the cg diagrams.

The only thing I am "viscerally" dedicated to is the option to
use any appropriate representation for any problem that anyone
wants to solve.  The only things I am totally opposed to are the
"thought police" who try to force their notations or languages
down every body else's throat.

RE> But I still don't see the logic of why they are better than
 > something like IDEF0 with its highly structured rules for
 > composition of contexts.
 >
 > Why should I invest my energy into CGs instead of IDEF0s?

I would never recommend that anybody replace their successful
systems with one that is based on anything that they would
rather not use.  If you find IDEF0 fine for you project, then
that's great.  I would not advise you to replace it with CGs
or any other notation unless and until you find some reason
to do so.

RE> It seems to me that CGs are ONLY really useful to computational
 > linguists.

Ease of mapping to and from natural languages was one important
design criterion.  But CGs are one of the concrete notations in
the ISO standard for Common Logic, any of which can be mapped
very directly to any of the others.

Furthermore, graphs of any kind can support some very efficient
computational methods.  The CG notation has a direct mapping to
those formats, but it takes a great deal more effort to strip
out the angle brackets to map RDF and OWL to the underlying
graph structure.

But there are some points that I have made very strongly over
the years:

  1. The ultimate knowledge representations are natural languages,
     which have the best balance of readability, flexibility, and
     expressive power.  Unfortunately, they are not as computable
     as one might like, and it's useful to have special purpose,
     more restricted notations for many applications.

  2. All declarative notations are variants of logic, and it
     is important to show which subset of logic they conform
     to and how they can be mapped to other logics.

  3. Highly restricted notations that may be useful for some
     problems can be inappropriate for other problems.  It is
     essential to know how how to map knowledge representations
     from one dialect to another.

I discuss these and other points in the following paper:

    http://www.jfsowa.com/pubs/fflogic.pdf
    Fads and fallacies about logic

By the way, Jim Hendler, who has been hanging out with the W3C,
was the editor of the journal in which that paper was published.
And he said that he was pleasantly surprised to find that he
agreed with what I said in that paper.

The title of my paper and talk for ICCS'09 is "Two paradigms are
better than one, and multiple paradigms are even better."  The
supporting platform for the software we are developing is the
FMF, which has a message format that identifies the language
of each message -- which could be IDEF0, CGs, English, or
even RDF and OWL.

Having said that, I do maintain that there are objective reasons
for comparing various notations and determining which may be
better or worse for a particular problem.

In particular, nobody who understands the kinds of knowledge
representations that were developed in AI during the past 50 years
can look at notations like RDF and OWL without throwing up -- and
that is a very objective evaluation.  Even the person who designed
RDF (Tim Bray) admits that it was a mistake.  And the most successful
web-based corporation in the world (Google) uses JSON instead of RDF.

And by the way, I support the use of description logics, which
are a valuable subset of logic that has been used for many
practical problems.   But what I strongly object to is taking
a good approach and mapping it into a disastrous notation.

And by the way, I have nothing against XML.  I believe it is
a very good notation for what the family of *ML languages were
designed for:  marking up documents.  XML is valuable for
web pages, the AJAX paradigm that supports Google maps and
many other applications, and the OpenOffice formats.

But what I strongly object to are the thought police who edicted
that all knowledge representations on the Semantic Web must be
translated to an XML form.  JavaScript has demonstrated a far
better way to embed languages in web pages: use the <script> tag.

John Sowa


---------------------------------------------------------------------
To unsubscribe, e-mail: cg-unsubscribe@...
For additional commands, e-mail: cg-help@...