Eric Armstrong wrote:
>
> Good note, Paul.
Thanks.
> On the bright side, XML has standardized 3 important things that
> needed standardizing:
> * Encodings (ascii-based)
> * Line Endings (newlines -- at least when they hit the program)
> * Markup syntax
True.
> Despite its shortcomings, that base level of interchange-standardization
> is *allowing* for standardized DTDs so that, one day, we can
> actually get where we need to be.
The point is there will never be standardized DTDs because needs keep
changing.
Where we need to be keeps changing. You can't easily standardize
knowledge representations because knowledge representation by itself
requires flexibility in problem specific representation.
That said, you can come up with common useful representations for common
problems -- within limits. But whatever system you use should be able to
move beyond common representations at a moment's notice as new
problems/situations come up. The whole XML way of thinking (standardize
a DTD everyone agrees on) goes against this flexilibity.
> I'm interesting if *any* encoding system would solve the problems
> you mention.
No XML-ish scheme can. It's like saying the type of paper you use helpds
you write a good novel. It may make a tiny difference if the paper is
easier to put in the printer and doesn't curl as much in the humidity
(i.e. XML line endings don't require conversion), but in general, the
problem of writing a novel has little to do with the paper it is
printwed on. So too the problems of knowledge representation have
little to do with the character encoding, line endings, or markup
syntax.
> Possibly and object-based system, rather than a data- based system?
Objects and such by themselves also don't solve the problem. In fact, to
an extent object-oriented programming compounds the problem because it
leads programmers down the garden path of thinking if they can just pick
the right objects all will be simple.
I wrote my undergraduate thesis "Why Intelligence: Object, Evolution,
Stability, and Model" on what would now be called Evolutionary
Psychology (done then as Cognitive Psychology). One major point was
objects are an artificial construct that are useful for solving certain
common survival problems simply and quickly. Every "object" one defines
can under another circumstance require decomposition into subelements or
require composition into another aggregate. Yet, objects are so
prevalent in our way of thinking even cognitive psychologist take them
for granted in conducting their research.
Examples of things we can think about that transcend common object
definitions and show the flexibility of human thought:
* That apple is half eaten (where's the other half? -- in chunks in you,
until it's digested and becomes part of you...)
* Take apart the chair and glue it back together so it's less rickety.
* What's inside a quark?
The point is to create a DKR/OHS flexible enough to deal with this issue
of representations changing over time as users needs change.
The point is that XML hype doesn't even admit this problem exists and
that it is the central one. In that sense, I see XML as just a
distraction. Yes, it might be useful insome instances, but it is
basically irrelevant as to addressing the core problems of knowledge
representation.
And to take things further, why invent XML when one could instead just
use LISP to the same effect (and with less bytes)? Lisp is used all the
time to define representations such as:
(user
(ID 100001)
(name "Grampa Muenster")
(address "13 Mockingbird Lane"))
Lisp can easily parse this which defines a valid LISP list, and we can
define LISP programs with related data that validate such
representations. That is what AI programmers have been doing for
decades.
There isn't a good answer, other than to say that XML like Java is
benefiting from hype and good marketing, and neither conceptually
improve beyond where Lisp was a decade or two ago -- and both actually
are a step backwards relative to Lisp because they both lack its
generality and elegance.
Lisp does have shortcomings and emotional baggage that a language like
Smalltalk somewhat addresses (and in turn creates some of its own
shortcomings). Java does have the initial advantage for C or Pascal
programmers over Lisp or Smalltalk because the syntax looks more similar
and makes it more approachable. XML seems to be easier to use for people
who know SGML or HTML because it looks more familiar and people think
that marking enging tags will be more reliable than counting parentheses
(it doesn't matter when you use a structured editor or a editing tool
like emacs). However, in my opinion, the investment in learning and
using these other systems (Smalltalk, Lisp) is worth it.
-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com
------------------------------------------------------------------------
Get a NextCard Visa, in 30 seconds!
1. Fill in the brief application
2. Receive approval decision within 30 seconds
3. Get rates as low as 2.9% Intro or 9.9% Fixed APR
Apply NOW!
http://click.egroups.com/1/975/3/_/444287/_/954812227/
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Mon Apr 03 2000 - 18:44:25 PDT