Interfaces which only use form elements only allow the use of predefined functions or terms. To let the user define new terms and functions and combine them, a simple programming language or data/knowledge representation language need to be offered by the interface. Handling simple languages is one of the most frequent task of computer scientist. It is for example required to handle any kind of data following a given format.
This project requires you to finish the implementation of an existing
"knowledge retrieval tool" called FCGquery.
Knowledge representations, or simply "knowledge", are data encoded with
a knowledge representation language. Knowledge representation languages
are designed to be less ambiguous than natural languages such as English,
so that a machine can parse and handle the knowledge representations.
In this project, the language used is the FCG language (FCG stands for
"Frame Conceptual Graph"). Each knowledge representation has to be
a well-formed FCG. Here is a FCG which represents the sentence
"The cat Tom is white and is on a blue mat":
[the cat Tom, color: the white, on: (a mat, color: the blue)].
A Knowledge Base (KB) is a file which contains knowledge representations,
that is, in our project, FCGs.
FCGquery proposes the user to specify a Web-accessible KB,
and a query to specify the knowledge s/he wants to retrieve. Then,
FCGquery retrieves in the given file the knowledge relevant to the query.
For example, a query to retrieve every FCG which is about a white animal
may be written:
spec [an animal, color: the white].
("spec" means "look for the specialisations of"). If cats have
been declared to be specialisations of animals, e.g. in the following way:
[Cat, subtype of: Animal],
then an answer to the query is the previous FCG:
[the cat Tom, color: the white, on: (a mat, color: the blue)].
Since the FCG language allows URLs to be used as terms inside FCGs, it allows knowledge to be associated to documents or parts of documents. Therefore, FCGquery may also be seen as a "knowledge-based private annotation tool". An annotation tool is a tool that let its users associate (parts of) documents with sentences (which are then called "annotations"). A public annotation tool is accessed by many users and stores the annotations of the users in a repository accessible by all. A private annotation tool is generally accessed by one user and stores his/her annotations into a file the name/address of which is generally known only by the user. This is the case for FCGquery since the KBs are Web-accessible files made by each user.
1) Complete the syntaxic parsing of FCGs.
a) Only the parsing of "path specification" remain to be implemented.
(Tests for this feature are at the end of kb.html).
See the grammar and the Part 5 of the code. The name of a
function which parses an object X should be named "getX" if the
presence of X is mandatory at the current point of parsing (an error
message should be displayed if X is not present). If the presence of X is
optional according to the grammar, the function should be named
"_getX".
b) Implementation of aliases. See the variable AlreadyReadChars in the code.
The variable Pos should diseappear except in the most primitive reading
function(s). (Tests for this feature also are at the end of kb.html).
2) Complete the construction and retrieval of types and FCGs.
a) During the parsing, construction of the relationships between the types
and the other objects of the KB (see Part 3 of the code to know the
relationships to build).
Coreferences must be handled. Semantic inconsistencies must be detected.
Whenever possible, the types of used but undeclared individuals and the
signatures of used but undeclared relations must be guessed.
(Note: fully doing this part is very complex).
b) Implementation the function printSpecsOfType(), and
completion of the function specsOfFCG() to handle path specifications.
Add your own tests in your copy of kb.html. When you have finished, send me the URLs of your FCGquery.html and kb.html