So, why not let's enumerate the problems of knowledge representation we want
to solve, then start from there.
Jack
From: Eric Armstrong <eric.armstrong@eng.sun.com>
> Paul Fernhout wrote:
> >
> > Eric Armstrong wrote:
> >
> > > I'm interesting if *any* encoding system would solve the problems
> > > you mention.
> >
> > No XML-ish scheme can....
> >
> Ignoring XML and anything remotely like it. What would you use?
>
> > ...
> > The point is to create a DKR/OHS flexible enough to deal with this
> > issue of representations changing over time as users needs change.
> >
> How?
>
> > 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"))
> >
> If we're only talking about data representations, this could easily
> be done in XML. One is not required to use DTD-validation when parsing
> an XML structure. So one can easily add other name/value pairs, without
> being constrained by a DTD. The only time a DTD comes into play is when
> you *want* to enforce restrictions. And there are times when you want
> that.
>
> > 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.
> >
> Certainly. Validating the structure is always possible in the program,
> with Lisp, XML, or any other data representation. DTD-validation is only
> a convience that permits taking that burden off the programmer, when it
> is desirable. There is also an intermediate ground. An DTD can be
> written so that any number of pairs of name and value elements can
> occur, so what you see is
> <name>ID</name><value>100001</value><name>address</name>... etc.
> The DTD can then ensure that the name/value pair restriction is never
> violated, but the values can be anything we want. Again, validation is
> not required, so even this restriction does not have to be enforced.
>
> > However, in my opinion, the investment in learning and
> > using these other systems (Smalltalk, Lisp) is worth it.
> >
> No argument there. Maybe some of the flexibility you desire comes from
> the ease of manipulation in those languages, rather than from the data
> structures themselves?
>
> ------------------------------------------------------------------------
> LOW RATE, NO WAIT!
> Get a NextCard Visa, in 30 seconds! Get rates
> as low as 2.9% Intro or 9.9% Fixed APR and no hidden fees.
> Apply NOW!
> http://click.egroups.com/1/2122/3/_/444287/_/954821718/
> ------------------------------------------------------------------------
>
> 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
------------------------------------------------------------------------
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/2646/3/_/444287/_/954857975/
------------------------------------------------------------------------
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 : Tue Apr 04 2000 - 07:26:57 PDT