A couple of years ago, I mused on the (possibly fatal) limitations of having Rationalism as the fundamental basis of the Semantic Web. Recently in the Communications of the ACM, an article added another example to the list of things that can be "known" but can't reliably be put into words. In Face Recognition Breakthough[1], a new technique was presented that performed significantly faster and with more accuracy than traditional face-recognition techniques. The basis of the technique was so surprising and counter-intuitive that, as recently as 2007, papers about it were rejected by mainstream computer vision conferences.
In very simplistic terms, the new technique finds the most compact way to represent the pixels of a picture (of say a face) by throwing them at a random set of numbers and seeing what sticks. That compressed data is compared directly with compressed versions of other face pictures to find the closest match. (If you really want the gory math details, see this video lecture.[2]) What is DOESN'T do is all the traditional figuring out of where eyes and mouth and nose and ears are, and calculating the relationships between their locations, distances, etc. In other words, it doesn't work by analyzing a face into words/concepts (eye, nose, mouth, etc) and specifying relationships between them. It DOES do weird math using random numbers that is irrational in the literal sense of the word. And apparently this weird math not only works, it works better!
The 2007 rejection of the papers as presenting outlandish claims was based on the same bias as rationalism has; if you can't put something into words, much less rational arguments, its not true, and its not knowledge. Just as neural-nets do, the mechanics of sparse representation and compressed sensing encode "knowledge" in a form that is completely unintelligible to us humans when we look at the "raw data". And while techniques that DO use more human-reason-friendly ideas are available, they often don't work as well.
[1] http://portal.acm.org/citation.cfm?id=1536616.1536623
[2] http://content.digitalwell.washington.edu/msr/external_release_talks_12_05_2005/15994/lecture.htm
Note: use IE browser; also you can skip forward past 46 minutes of theory to go directly to applications.
Showing posts with label semantic network. Show all posts
Showing posts with label semantic network. Show all posts
Tuesday, August 11, 2009
Friday, September 21, 2007
The Savant Semantic Network Database
Back in 1983, when "expert systems" where just starting to be all the rage, I had a contract (and was later hired as Chief Scientist) with a startup company that wanted to develop several microcomputer based "business" applications. I realized that they were all essentially database applications with a forms-centric user interface. [Mind you, this was back before there were real databases on PCs, and 80x24 color text was the state of the art for user interfaces.] I decided to build a general database and forms UI engine from scratch, and then quickly create the business apps (e.g. contacts, H/R data, calendar, memos, etc) using the engine. The engine eventually became a product in its own right and was dubbed Savant. Mark Wozinac (brother of the famous Woz) ran an early computer store in Silicon Valley and was an early enthusiast for the technology.
Having always been interested in AI and general knowledge representation, and with expert systems looking hot, I took a semantic networking approach. Savant had an interactive development mode where the user could move the cursor around the screen and dynamically define form fields, associating each field with an EAV (entity/attribute/value) data triple (way before the term EAV was widespread). The name of each form field was the "attribute", the value entered into the field was the "value", and the "entity" was the value of some other form field that the user specified. Savant let users create their app, complete with database, on the fly, with the form definitions stored in the same EAV database. I had some novel techniques to optimize the data retrieval (using my written from scratch B+/B* tree DB kernal). All this was written in UCSD Pascal (grandpa to Java) such that it ran on IBM PC, Radio Shack TRS80, Apple ][, and exotic 32-bit computers, and ran on FLOPPIES! Only shortly later, when Corvus hard drives for Apple ][ and the IBM XT came out, did it benefit from their size and speed. To UCSD's credit, I didn't really have to change any code.
One of my inspirations was to make a more intuitive approach for non-technical users than was required by a popular database of the day, pfs:File. It also let users create form screens and save the data from each screen into its own "table". I thought that it was too complicated to know which screen each bit of data you wanted was on, plus, you couldn't share data between screens! My goal was to have all data available from all screens/forms without having to know about tables and schemas. One would just design forms and the data would magically go to the right place.
The other day, I stumbled across, MindModel, a product that looks very similar to Savant (except its written for the new-fangled graphic user interface :-) It also looks like it may have the same fatal flaw that my system had. Namely, Savant didn't (because I didn't) understand that the value of a "name" attribute of an entity is not the same thing as the entity itself (nor is it a key). E.G. (JoeSmith,phone#,123-456-7890) does not represent the same information as (key123,name,JoeSmith) plus (key123,phone#,123-456-7890). So, if you change JoeSmith to JoeBlow, you either lose the association with other attributes tied to JoeSmith, or you must remap them all. So, Savant changed all the JoeSmith references to JoeBlow in all triples, but then what to do about the phone number changing? If you change all 123-456-7890 references to 321-654-9999, you have not only changed JoeSmith's phone number but anyone else who shared that number. In other words, it didn't really understand the concepts of entity and attribute.
I see the same fuzzy understanding of entities and attributes in many articles about the Semantic Web and how easy it is to encode data such that any lay person can do it intuitively. They show the same (JoeSmith,phone#,123-456-7890) flavor examples. We all need more basic metaphysics and ontology training in grade school!
Having always been interested in AI and general knowledge representation, and with expert systems looking hot, I took a semantic networking approach. Savant had an interactive development mode where the user could move the cursor around the screen and dynamically define form fields, associating each field with an EAV (entity/attribute/value) data triple (way before the term EAV was widespread). The name of each form field was the "attribute", the value entered into the field was the "value", and the "entity" was the value of some other form field that the user specified. Savant let users create their app, complete with database, on the fly, with the form definitions stored in the same EAV database. I had some novel techniques to optimize the data retrieval (using my written from scratch B+/B* tree DB kernal). All this was written in UCSD Pascal (grandpa to Java) such that it ran on IBM PC, Radio Shack TRS80, Apple ][, and exotic 32-bit computers, and ran on FLOPPIES! Only shortly later, when Corvus hard drives for Apple ][ and the IBM XT came out, did it benefit from their size and speed. To UCSD's credit, I didn't really have to change any code.
One of my inspirations was to make a more intuitive approach for non-technical users than was required by a popular database of the day, pfs:File. It also let users create form screens and save the data from each screen into its own "table". I thought that it was too complicated to know which screen each bit of data you wanted was on, plus, you couldn't share data between screens! My goal was to have all data available from all screens/forms without having to know about tables and schemas. One would just design forms and the data would magically go to the right place.
The other day, I stumbled across, MindModel, a product that looks very similar to Savant (except its written for the new-fangled graphic user interface :-) It also looks like it may have the same fatal flaw that my system had. Namely, Savant didn't (because I didn't) understand that the value of a "name" attribute of an entity is not the same thing as the entity itself (nor is it a key). E.G. (JoeSmith,phone#,123-456-7890) does not represent the same information as (key123,name,JoeSmith) plus (key123,phone#,123-456-7890). So, if you change JoeSmith to JoeBlow, you either lose the association with other attributes tied to JoeSmith, or you must remap them all. So, Savant changed all the JoeSmith references to JoeBlow in all triples, but then what to do about the phone number changing? If you change all 123-456-7890 references to 321-654-9999, you have not only changed JoeSmith's phone number but anyone else who shared that number. In other words, it didn't really understand the concepts of entity and attribute.
I see the same fuzzy understanding of entities and attributes in many articles about the Semantic Web and how easy it is to encode data such that any lay person can do it intuitively. They show the same (JoeSmith,phone#,123-456-7890) flavor examples. We all need more basic metaphysics and ontology training in grade school!
Monday, May 14, 2007
Rationalism of the Semantic Web a Flaw?
In thinking about how knowledge is represented in the real world, it occurs that, in addition to the traditional rational representation via human and formal languages, there are at least two other biggies: DNA and neural nets.
Many, if not all, of the things we learn are represented in our brains as complex networks of (mathematical) functions that are simulated in computers via the technique of neural networks. And, if you have ever looked at the data associated with a neural net that has been trained to, say, recognize a handwritten letter "A", you've seen how there isn't any way to put that knowledge into words. In fact, it is not clear by simply looking at a net's matrix of fuzzy weights that it knows anything at all, much less what it knows!
In a similar vein, DNA obviously encodes tremendous amounts of knowledge, like how to make a beating heart, that are also very hard to translate into explicit "facts". In fact, DNA, like self-modifying source code in Lisp, is hard to verbalize because what it "does" can be very far removed from what is "says".
Now because the whole theory and strategy of representing knowledge via "facts", whether in a traditional database, or a semantic network, assumes that everything can be put into a fact format, there are huge amounts of knowledge in the world that can't be used. Yes, one can simplistically use a BLOB to stuff anything reducible to a number string into a database tuple, but that doesn't really put the knowledge into a form that can be "reasoned" about via inferencing rules. And it is that sort of inferencing that is the rationale behind the Semantic Web and why we should bother to create it.
Is this a (fatal) flaw in the foundation of the Semantic Web? Many philosophers have claimed it is a fatal flaw in Rationalism which is the philosophical equivalent to semantic networks. Phenomenologists insisted that many other flavors of knowledge had to be handled beyond the ones covered in rationalism and logic. How will the semantic web handle these? Is it even possible philosophically?
Wednesday, June 7, 2006
Ontology Merging Strategy
Summarizing the posts from yesterday, there is a general problem of "things" in one ontology/data model not mapping (in a definite way) to "things" in another model. How to support (or even automate) mapping from one model to another? I.E. how to facilitate "transformation" from one "basis" to another?
A strategy at the heart of an existential programming language could be to reduce entities to their most atomic level: semantic relations between an entity and a single attribute. Use "identity" algorithms to reconstitute these atoms into "things".
A new language that did this and integrated multiple sources of data (OO data, E/R relational data, semantic networks, web-search-results) could create a single seamless framework and data continuum.
[Ed. Note: as found 10/29/07, others have had similar ideas.]
A strategy at the heart of an existential programming language could be to reduce entities to their most atomic level: semantic relations between an entity and a single attribute. Use "identity" algorithms to reconstitute these atoms into "things".
A new language that did this and integrated multiple sources of data (OO data, E/R relational data, semantic networks, web-search-results) could create a single seamless framework and data continuum.
[Ed. Note: as found 10/29/07, others have had similar ideas.]
Subscribe to:
Posts (Atom)
PolyGlot, Inc.
- Bruce Wallace
- As Principal Consultant of PolyGlot Inc since 1980, Bruce Wallace has provided computer software development, consulting, and contract programming services around the world. Projects have been completed in San Francisco, Juan-les-Pins France, Sydney Australia, Perth West Australia, "Silicon Valley" CA, "Route 128" MA, Austin TX, Charlotte NC, Atlanta GA.