Paul Fernhout
pdfernhout@kurtz-fernhout.com


Date: Tue, 24 Oct 2000 15:28:28 -0400


From:   Paul Fernhout
pdfernhout@kurtz-fernhout.com
Reply-To: unrev-II@egroups.com
Organization: Kurtz-Fernhout Software

To:     unrev-II@egroups.com

Subject:   Architectural Snag

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 final use cases. You can then reach into that representation and construct useful 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 useful.

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 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.

Jack Park wrote:

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).

Jack Park wrote:

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).

Jack Park wrote:

(note) I decided to see if I am fair in saying that you *inject* concept. Moving this to a text editor and using search, I see that I inject it at a conceptual level, and you elevate it to an ontological level when you state "(Things in quotes are intended as concepts, not strings or symbols.)" and maybe there is absolutely no difference between a conceptual and an ontological level. So, now we have a *concept* to represent. How do we do that? With strings alone? I don't think so. When meat-space thinks about Jo B., it conjures up images, recollections, lots of contexts. It seems to me that there needs to be a representation for that concept, one that, perhaps, points to all the known contexts in which that concept plays some role. At least, when any context uses some concept, that 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 added.").

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.newTriadABC(

      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 functions).

One could just as easily use the code: 


  TheRepository.newTriadABC(
     TheRepository.newTriadAbstract(),
     TheRepository.newTriadAbstract(),
     TheRepository.newTriadAbstract()
     );

...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 architecture.

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:

http://www.lazysoft.com/

...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.

I have also recently heard from:

http://www.ms.lt/ourownthoughts.html

...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.

Sincerely,


-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