Well stated, Paul. Comments below...
From: Paul Fernhout <email@example.com>
> Jack Park wrote:
> > I believe we are headed for some kind of convergence here. I am of the
> > opinion that you can build a useful representation without knowing its
> > use cases. You can then reach into that representation and construct
> > views according to specific needs.
> Kent might argue that the representation is still built with some end in
> mind. For example, a database that represented people like Jo.B. and
> their locations and professions but not the position of the moon might
> be useless in planning a moon launch and safe return for Jo.B.
> I would argue we have so much experience in solving problems in certain
> domains we tend to know what is useful in advance -- for example, when
> creating a payroll system names are useful as are social security
> numbers. Obviously, most people share a common life situation (born,
> eat, sleep, work, get sick, die, etc.) and so for applications intended
> to cover typical human type situations we can guess at what is most
> In effect what you are saying is you can make a model of reality without
> knowing the intended use of the model. However, reality is almost
> infinitely detailed (down to probability waves of subatomic particles)
> and almost infinite in scale (~400 billion visible galaxies each of ~400
> billion stars) and almost infinite in time (20+ billion years back and
> who knows how far forward).
I remain convinced that we still have room for convergence here. It is my
view that what we are all doing with all this experience you mention is the
construction of ontologies, many of which are never interoperable. You make
it clear that models need purpose, and I have no quarrel with that. The
point I believe I am making is that all those models need to be grounded on
a common semantics, making them capable of interoperability and providing
affordances for discovery.
A cursory read of George Lakoff's book _Women, Fire, and Dangerous Things_
will tell you that it is not really possible to build a common semantics for
*all the world*. Just look at the title of the book; those are the names of
the three primary categories of an aboriginal people. But, it is possible
to construct maps between those categories and similar categories we may
share. I am looking for a way to construct the underpinnings of semantic
interoperability among all models. That, IMHO, is the only way we will ever
collectively evolve solutions to the many global-scale problems that Doug so
eloquently discussed during Unrev-II. It may be just my own biases showing,
but I have been wedded to the notion of semantic grounding since the days
when I first started fiddling with AI, back in the late 70's. I suppose
that, in the big picture, I am a relative newcomer to the field.
> I would stand by the notion that useful model building only happens as
> long as one is building a model similar to the kinds of questions one
> expects it to help one answer. Obviously, even if one may not know the
> exact questions to be asked, one may commonly just know most of the
> types of information one will want to ask questions about (which is
> almost the same thing).
> Again, as another example, a model of the Earth made from mapping
> geological formations won't tell you anything about when you cross a
> political boundary and need a passport. One of the "obvious" things that
> amazes people most on a trip on the Space Shuttle is that political
> boundaries aren't visible on the Earth from space (as opposed to how
> they appear on most maps and most globes). So, even on a specific scale
> at a time, there may be different issues to model.
> Obviously, if we are talking about modeling how email is managed or how
> hypertext is managed, we all know enough about those subjects from
> everyday practical experience that we can go pretty far in building
> flexible models based on our gut reactions without needing many use
> cases at the start. But even then, needs may change over time.
> > Placeholders need context. I suppose I am arguing that a triad is
> > insufficient, that a forth element of the tuple (context) is needed.
> I have considered that implementation approach. The issue is when things
> can be in multiple scopes. So I think as a start, it makes it easier and
> more flexible to just use additional triads to define one or more scopes
> for other triads. Those scope triads can also be in scopes, although you
> can end the infinite regress by assigning a default scope to triads
> without any specific scope triad. So, scope then emerges out of how
> triads are used. I'm not saying scope is unimportant, just that it
> should be an emergent property managed by code as opposed to built in to
> the structure (at least until we have more experience with it).
> > You inject another ontological entity into this discussion, *concept*.
> I am being a little unclear here. I am using "concept" in an API sense
> as I define "concept" related functions in the Pointrel Data Repository
> System (more on this below).
> > <note> I decided to see if I am fair in saying that you *inject*
> > Moving this to a text editor and using search, I see that I inject it at
> > conceptual level, and you elevate it to an ontological level when you
> > "(Things in quotes are intended as concepts, not strings or symbols.)"
> > <subnote>and maybe there is absolutely no difference between a
> > and an ontological level</subnote></note>. So, now we have a *concept*
> > represent. How do we do that? With strings alone? I don't think so.
> > meat-space thinks about Jo B., it conjures up images, recollections,
> > contexts. It seems to me that there needs to be a representation for
> > concept, one that, perhaps, points to all the known contexts in which
> > concept plays some role. At least, when any context uses some concept,
> > concept ought to be somehow grounded somewhere.
> I and Kent agree with you that one can't represent concepts as just
> strings. In both Kent's model and the Pointrel Data Repository System,
> concepts are more abstract, although for practicality reasons typically
> you can find a concept with a string that names it. There are some
> exceptions to this case, and more complex applications will have more
> exceptions and need better ways to find concepts from symbolic
> references. A reference to a triad can range from a strings to a snippet
> of code expressing search processes that resolve references (e.g. "get
> me the node that this node points to in this way and that has this
> specific property and if there is more than one give me the last one
> The system supports triads which are just arbitrary binary strings.
> The system supports symbols which are defined by arbitrary binary
> strings but the request for a certain string stored as a symbol always
> returns the same symbol.
> The way I define a concept (similar to Kent) is more or less as an
> abstract node (one with no links and no string data). The meaning of
> this abstract node emerges out of the relations it is linked into, and
> what those mean in terms of other relationships, the code, and the
> user's intent.
> For practicality and convenience of implementing simple things, I allow
> one or more symbols to be used to find that abstract "concept" node.
> Those symbols contain a string. So when I wrote "things in quotes are
> intended as concepts" what I meant was "concepts" as opposed to
> "strings" or "symbols", which each have a specific meaning in the
> Pointrel API. One might add a triad using a function something like:
> TheRepository.findOrMakeConcept("Jo B."),
> TheRepository.findOrMakeConcept("has location"),
> TheRepository.findOrMakeConcept("car 54")
> This may create a whole complex set of triads defining symbols
> associated with specific strings of characters in a symbol tree, with
> (triadal) links from those symbols to abstract nodes representing named
> "concepts". Multiple symbols can name the same concept in theory, as
> also one symbol could refer to multiple concepts in theory (although in
> practice the "convenience" concept API is set up for now to flag this as
> a problem you need to code around yourself using more basic API
> One could just as easily use the code:
> which accomplishes in some sense the same thing as the first expression,
> except there is no additional contextual information created (symbol
> table info involving symbols, strings, links) which one could later use
> to ever find those "concept" nodes in the future. Also, if those concept
> nodes had been created previously, there would now be two nodes for
> those concepts as there was no attempt to find the previously referenced
> nodes. And so the web of relations would not reflect what was intended.
> However, one could using low level APIs construct all the appropriate
> triads one at a time to accomplish the same as the first code example --
> just with lots more lines of code and keeping track of intermediate
> results from generating new triads.
> I think you raise good issues, but I think the Pointrel system or Kent's
> ROSE system can support them as well as or better than anything else. My
> bit of handwaving here is to say I prefer that many of these knowledge
> representation issues be dealt with for now with complex code that
> iterates over a complex web made of simple components, as opposed to
> trying to solve them with simple code iterating over a simple web of
> complex components. Or to put it another way, I feel they can be dealt
> with in code in the Pointrel System, but I think it less likely they can
> be dealt with in a system that assumes much more in the low level
I fully buy the notion of a complex web made of simple components. Sounds a
lot like the way I imagine meat-space working. I'd like to think that the
complex code to which you refer can, itself, be constructed from simple
components that can be interchanged as the whole knowledge space evolves.
Indeed, the meat-space metaphor *suggests* simple code as well. In fact, I
rather like your Pointrel code. It's just liable to convince me to begin
playing with Python, though my inclination is to just implement it in Java
and XML and get on with it. But, to use such a system, I prefer to find a
semantic grounding design that satisfies my belief in the notion of concept
drift (read: version control).
> The reason some of this is handwaving is that I don't have a big library
> of such complex code to do these sorts of tasks on this flexible
> substrate. I am focusing on trying to make a good first step in the
> right direction that supports a good next step. There is only so much
> one person can do with limited time against a background of people
> entrenched in the status quo. William Kent more or less got so
> frustrated trying to take on the RDBMS establishment for decades to make
> them see and respond to the sorts of issues he discusses in "Data &
> Reality" that he ended up going into technical writing as less stressful
> and has since recently retired to spend his days doing fun stuff
> unrelated to computing. It is a tribute to Doug's stamina and thick skin
> he's still working towards Augment despite much the same reception. One
> difference is that Doug has seen some of his more concrete ideas
> implemented in bits and pieces around the world (mouse,
> teleconferencing, email, hypertext, etc.), whereas the primarily more
> abstract truths in "Data & Reality" are still pretty much far from the
> mainstream with very few implementations.
> I've recently found out about this company:
> which is doing something similar in Java called "Sentences" (released
> about three weeks ago) which they call "the first entirely new database
> architecture since the advent of the Internet." (I wish I had their PR
> department. :-) They don't reference Kent's work or the Pointrel Data
> Repository System. While I'm not sure their model is as flexible or that
> they deal with as many issues, from the general stuff they have on their
> web site, they seem to be building a GUI and other support structure
> around some type of triadal model. Their marketing copy does point out
> many of the limits of the typical RDBMS and the value of more flexible
> systems. Their examples don't seem to indicate an understanding of the
> notion of abstration to a concept level yet though (something that took
> me a couple of years to "get" back in the 1980s and revolves around the
> "concept" abstraction issue you raised), although perhaps they just
> picked simple examples. But there is no question this is a large
> company, with some level of funding, dozens of employees, and a
> management with a successful track record in related areas. They appear
> to have written a book about their approach.
The white paper reminds me strongly of stuff I have viewed in the RDF
literature. RDF uses triples (sentences) to construct enormous graphs.
> I have also recently heard from:
> which is doing something related as well (in an open source way). They
> have links to other related projects.
> This arena of Knowledge Management and related tools is definitely
> shaping up to be an active one which will see titanic struggles over the
> next few years by major players (including the likes of IBM and Oracle),
> motivated by desperation as people look for new ways to cope with the
> firehose of information the internet puts at their desks. It would be
> nice if the core of a popular solution was an open source / free
> software one, accompanied by lots of rich open content. I had hoped the
> Pointrel Data Repository System could be such a core. But frankly, I
> could easily see it being passed by by heavily funded corporate
> intiatives patenting the wheel and its derivatives. I would predict if a
> system like the Pointrel Data Repository System or the Bootstrap OHS or
> "ourownthoughts" does not come to dominate the KM landscape in the next
> year or two, we will be a long time (until patent expiration) living
> with multiple incompatible proprietary solutions. One of the reasons I
> went public with a Pointrel implementation back last May was to have it
> available as prior art (in addition to Kent's book).
> Still, it will be expensive to fight patents on every minor variation.
> -Paul Fernhout
> Kurtz-Fernhout Software
You raise powerful notions, Paul. My hunch is that there really is room for
convergence here. Like your stuff, my stuff will be open source.
This message is intended only for the use of the Addressee(s) and may
contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
the intended recipient, dissemination of this communication is prohibited.
If you have received this communication in error, please erase all copies
of the message and its attachments and notify firstname.lastname@example.org
-------------------------- eGroups Sponsor -------------------------~-~>
It's Easy. It's Fun. Best of All, it's Free!
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIemail@example.com
Shortcut URL to this page:
This archive was generated by hypermail 2b29 : Tue Oct 24 2000 - 14:26:35 PDT