I'm at a public terminal but I wanted to jot down
some of the ideas on how the MELD system could work.
There must be a parser for MELD. We have a yacc, & lex file & makefile in the ftp area which can be a starting point for the parser. The MELD Features document ( link on the web page from http://pdkb.sourceforge.net ) requires that all
MELD knowledge bases define certain constants and have certain facts defined. Unfortunately, I don't think that appendix goes far enough. It gives some constant names without clear requirements of the semantic meaning. Since a MELD kb only has facts that are known to be true or false, therefore the facts and rules that keep inconsistent data from being put into the knowledge base are redundant once the kb exists.
It is useful to have these facts and rules as a knowledge base, however, so this is what I have named the MELD Semantics KB on the file download area. My thought is that the MELD parser would
first load the MELD Semantics KB into memory, and then use it as a filter on the next KB it reads in. If any rules or facts contradict this MELD Semantics KB, they won't be allowed into the 'real' KB. This might need to be a multiple
step process. The first filter would be the MELD Semantics KB, but if a term is used that isn't defined in terms of these base constants, a small subset KB which has the definitions of terms used in the input KB might have to be constructed.
This successive refinement is more complex than some language parsers, but allows each part to be simple and well defined.
I see one of these layers of KBs to be one that includes all the constants defined in the Context space paper at http://www.cyc.com , and another layer to be those constants defined in the text of the MELD Features document but which are not in the required semantics appendix.
I'll post more on the pdkb-meld mailing list later.
Dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm at a public terminal but I wanted to jot down
some of the ideas on how the MELD system could work.
There must be a parser for MELD. We have a yacc, & lex file & makefile in the ftp area which can be a starting point for the parser. The MELD Features document ( link on the web page from http://pdkb.sourceforge.net ) requires that all
MELD knowledge bases define certain constants and have certain facts defined. Unfortunately, I don't think that appendix goes far enough. It gives some constant names without clear requirements of the semantic meaning. Since a MELD kb only has facts that are known to be true or false, therefore the facts and rules that keep inconsistent data from being put into the knowledge base are redundant once the kb exists.
It is useful to have these facts and rules as a knowledge base, however, so this is what I have named the MELD Semantics KB on the file download area. My thought is that the MELD parser would
first load the MELD Semantics KB into memory, and then use it as a filter on the next KB it reads in. If any rules or facts contradict this MELD Semantics KB, they won't be allowed into the 'real' KB. This might need to be a multiple
step process. The first filter would be the MELD Semantics KB, but if a term is used that isn't defined in terms of these base constants, a small subset KB which has the definitions of terms used in the input KB might have to be constructed.
This successive refinement is more complex than some language parsers, but allows each part to be simple and well defined.
I see one of these layers of KBs to be one that includes all the constants defined in the Context space paper at http://www.cyc.com , and another layer to be those constants defined in the text of the MELD Features document but which are not in the required semantics appendix.
I'll post more on the pdkb-meld mailing list later.
Dave