From: Paul Fernhout <pdfernhout@kurtz-fernhout.com>
Eric Armstrong wrote:
> Unfortunately, the appears not to be available. (Amazon doesn't even
> offer to look for it in the used shops -- they used to. Either they've
> discarded that feature or this book *really* isn't available. I'll have
> to rely on the links you sent.
Yes, I believe it is out of print. I first encountered it in the Iowa
State library around five years ago (and found it similar to stuff I had
been doing). I special ordered a copy through Borders about four years
ago. Kent is currently trying to republish it. I don't know how to get
it now.
The borders link below says it needs to come from the publisher.
http://search.borders.com/fcgi-bin/db2www/search/search.d2w/Details?&mediaType=Book&prodID=2784442
The amazon link says what you say -- not even available:
http://www.amazon.com/exec/obidos/ASIN/0444851879/o/qid=948711056/sr=8-1/002-3122665-7566621
> > One big drawback for the ROSE system is it is so flexible, that the
> > integrity of the data rests very heavily on the code that manipulates
> > it or which maintains it.
>
> That could be a drawback. I wonder if there is a way around it.
One way around it is to have "executables" which enforce certain
relationships. These provide some of the same enforced structure as say
a table does in a relational database. However, the executable part
isn't very well worked out in the book.
Other ways have to do with security and versioning.
Ultimately, whatever system you use can be defeated by bad coding. In
C++ you can generate bad code and jump to it using code, in Smalltalk
you can delete or add methods or classes using code, in relational
databases you can create new tables or put in bad data or restructure
tables by SQL code. However, in each of these other systems such code is
less commonly written, and many simple errors are caught by some part of
the language definition or development environment.
> > Let me provide an example ...
>
> This part really got my attention. One of the difficulties in building a
> nutritional model with the tools I had available was encoding the
> possible relations.
>
> Question: How does one tie an executable to a particular relation so
> that it can become a quantifiable part of model? As an example from that
> domain (since I'm familiar with it), I'd like to express relationships
> like the following:
> (general) The B-vitamins require the B-vitamin folacin for
> adsorption.
> (specifics) Vitamin B-1 requires folacin for adsorption.
> Vitamin B-2 requires folacin for adsorption.
> ...etc. (naming all the B-vitamins)
> (quantity) For each B-vitamin, amt_absorbed = folacin_amt
> (quantity) FDA-imposed folacin limit = 400 micrograms per supplement
> (model) B-vitamin_amt - folacin_amt => waste_amt
>
> Rather than giving a detailed reply, I guess I'm interested in a summary
> statement of how much of the above can be modeled.
> * Can we model the abstract statement with associated specific
> statements?
> * Can we model the quanitity relationships?
> * Can we turn those quantity relationships into a usable model?
The model is totally abstract and flexible. It can do all those things,
however the implications of quantity would require some sort of
simulation. The implementation of that simulation would be done in code
(although code could be represented in this system -- either as strings
or exploded out as nodes).
Using a simplification of only triadal links creating binary relations
(my favorite), and assuming strings are actually looking up nodes, this
would encode what you specified:
(where "new-node" makes an unnamed node, and "that-node" referes to the
last new-node)
(new-node) is concept
(that-node) named vitamin
(new-node) is concept
(that-node) named B-vitamin
(new-node) type vitamin
(that-node) named B1
(that-node) named thiamin
(that-node) in-class B-vitamin
(new-node) type vitamin
(that-node) named B2
(that-node) named riboflavin
(that-node) in-class B-vitamin
"The B-vitamins require the B-vitamin folacin for adsorption."
(new-node) type vitamin
(that-node) named folacin
(new_node) named uptake-limited-by
(new_node) named requirement
B-vitamin uptake-limited-by folacin
[or this could be done for each vitamin seperately, or some code could
iterate over the nodes].
"For each B-vitamin, amt_absorbed = folacin_amt"
> (model) B-vitamin_amt - folacin_amt => waste_amt
[This would be expressed by code related to a simulation model using the
data.
"FDA-imposed folacin limit = 400 micrograms per supplement"
(new-node) is variable
(that-node) quantity 400
(that-node) named FDA-imposed-folacin-limit
(that-node) named folicin_amt
(new-node) type calculation
(that-node) called waste-calculation
(that-node) computes waste-amount
(that-node) defined-by-code
"result = []
for each in (find (find-list ? is B-vitamin) amount ?):
result.append(each, (find each quantity ?) - (find folacin_amt
quantity ?))"
[Note the queries built into the above calculation -- find-list
producing a list of results, find producing a single match]
B1 amount 500
riboflavin amount 450
(do waste-calculaton) => ((B1 100) (B2 50))
(new-node) type vitamin
(that-node) named B3
(that-node) in-class B-vitamin
B3 amount 600
folacin_amt quantity 450
(do waste-calculaton) => ((B1 50) (B2 0) (B3 200))
"Getting fancy, assuming using Zope's DTML (HTML with Python server side
includes)"
(new-node) type presentation
(that-node) generates-html
"<table>
<tr><th>Vitamin</th><th>Excess</th></tr>
<dtml-in (do waste-calculaton)>
<tr>
<td><dtml-var first_item_in_list></td>
<td><dtml-var second_item_in_list></td>
</tr>
</dtml-in>
</table>"
(that-node) called waste-presentation
(do waste-presentation) ==> "Generates HTML table of waste data"
Of course, these calculations could have been done in a spreadsheet. Or
they could have been done my making various objects in Smalltalk or
Python. The power of the Kent model is you can endlessly elaborate, like
so:
B2 has-history
"http://www.suite101.com/article.cfm/pharmaceuticals/26165
It was in 1879 that a yellowish green fluorescent pigment was
identified in milk. The use of the substance, however, was not
clarified until the 1930's when the yellow enzyme isolated from
yeast was discovered to be an essential element for growth in
laboratory animals. It was named Riboflavin or vitamin B2."
"The history of vitamins!"
(find (find-list ? type vitamin) has-history ?)
There is a lot of subtly and indirection I am not describing here for
lack of time/energy/space. But in short, nodes can have multiple
symbolic representations. So, for example, multiple nodes could be
pointed to by "B1" and a node pointed to by "B1" could also be pointed
to by "thiamin" (as was done above). The disambiguation would have to be
done by parsing code or executables doing some kind of sophisticated
search if you referred to a node through name. Mapping natural language
onto this representation is a hard task, as is even the simpler task of
dealing with limited multiple names for relationships ("has-history vs.
history", "quantity vs. value vs. current-value"). Handling multiple
versions, browsing, and debugging in such a flexible system are also all
complex. Conventions would need to evolve in any project. "Find" and
"Find-list" can possibly be elimiated by clever use of syntax. Issues
like forcing a vitamin to have only one quantity have also been glossed
over. Phrases can be handled better in the parser. Also, the coding is
completely made up in this example. It is sort of a mix of Lisp and
Python. I have nothing that implements that exactly as is.
Still, hopefully one can see the potential flexibility of this approach
for adding knowledge to a OHS/DKR in a way that is more granular and
expandable than HTML or relational database tables. One might decry "I
can do that all in Common Lisp with some little effort" and you'd
probably be right. You could also do it on top of Python or Smalltalk or
even C++. Conversely, one could impliment Smalltalk, C++, Python, or
Lisp on top of such a representation. It is a "meta-representation".
It assumes practically nothing about data or use or implementation. It's
a state of mind -- like a paradigm shift. I think it likely someday all
data will be stored using such an approach (as parallel computing
increases and speed needs are addressed -- given a flexibility / speed
tradeoff in this representaion). Object-oriented programming is a subset
of this, in somewhat the same way HTML and XML are subsets of SGML.
http://www.ucc.ie/xml/#FAQ-SGML
I've been working towards my own implementation of this in a variety of
ways for almost twenty or so years (before I encountered Kent's work -
although "Data & Reality" definitely clarified my thinking). The system
I am working on is called "Pointrel" for "Pointers and Relationships".
It's what I sharpen my programming claws on.
-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the open source Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com
--------------------------- ONElist Sponsor ----------------------------
Independent contractors: Find your next project gig through JobSwarm!
You can even make money by referring friends.
<a href=" http://clickme.onelist.com/ad/jobswarm2 ">Click Here</a>
------------------------------------------------------------------------
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 2.0.0 : Tue Aug 21 2001 - 18:56:38 PDT