Technical FAQ on Scripted Topics

Q: What gets scripted in WORDS - the topic or the topic map?
A: Neither one.  Properly, you script MODELER, which in turn drives the Topic Map engine.  That way, the scripts you write can manage topic maps in application-specific ways, and link them to J2EE web apps, inference engines, and a GUI being shared in real time by a human operator. 

Q: Will the scripts work for any TM engine?
A: No, only those which MODELER explicitly supports.  Technically, a client application calls MODELER's API, which in turn calls the (unchanged) TM engine.  WORDS scripts only work when this API is used.

Q: Must WORDS scripts be stored inside Topics?
A: No.  WORDS is merely an expression language which causes MODELER to query and manipulate topic map elements and other J2EE software.  But some functions in its API do require that some scripts be present within topics if those functions are to do useful work.

Q: What does a WORDS script look like?
A: All scripts are expressions, which are short character strings.  FORMs are expressions that look a lot like English phrases.   They can be used inside other types of  "control" expressions which handle simple "if" tests, iterators, etc.  Such control expressions look and work like conventional scripting languages.

Q: What does an expression evaluate to?
A: That depends. One of our API methods, on request, will evaluate any expression and return its value as another String.  Other API methods (meant for lower-level programs) can take the same expression and (depending on what it means) return the handle of a Topic, Association, String or List.

Q: What role does the TM engine play?
A:  Evaluating an expression often depends on the state of CONTEXT, which the TM engine lets WORDS query and mutate.  This is similar to what happens when a SQL command is interpreted by software which uses other DBMS logic and data to guide its processing.

Q: Does WORDS overlap with TMQL?
A:  Perhaps in basic query features there will be some redundancy.  But WORDS seeks mostly to create new topics or characteristics, not search for them.  Also WORDS is clearly based on NLP and on English, both of which TMQL clearly avoids.  Long term, WORDS scripts will likely use TMQL to do complex searches. 

Q: Can I access MODELER from my own applications?
A: Yes, potentially in several ways.   Its API is written in and for Java, so any J2EE application or middleware can call it.  So too can other script interpreters that are implemented in Java, such as JSP (Java Server Pages), Jython, or JScheme.  WORDS expressions should make Topic Maps easy to access from all of these coding environments.
  
Q: Can I access MODELER across the web?
A:  Not directly, in part for security reasons.  But a JSP can selectively call its API on your behalf.  That lets you post WORDS inputs to a web app, provided you do the extra work of handling security as you see fit and catching any API exceptions. 

Q: Can I only call WORDS scripts programmatically?
A: No indeed.  MODELER's design includes a desktop shell for interactive WORDS use, with many nice support and training features.  It also manages batch jobs in which bulk WORDS expressions come from input files, while their values and created XTM go into separate output files.  Authors will find this shell very helpful for generating XTM files.

Q: Why bother storing WORDS scripts inside Topics?
A: They effectively configure CONTEXT on a type-by-type basis, to handle constraints, defaults and data inheritance.  This is where the PSIs come into play.  By citing them appropriately inside ontology-level topics (types of rolespecs, associations, occurrences, names), an author can script the whole topic map into a self-consistent mini-application, portable via XTM to other MODELER users.

Q: What can MODELER 1.0 do to help me?
A: The use cases show this varies with what you do.  But to your organization as whole, WORDS scripts that users can embed, or call from programs, or run interactively in the shell should be helpful.  They can help build, change, query or maintain TMs by automating many small related tasks - typically in authoring or content management.    Beta tests will provide concrete examples of helpful, portable prototypes.

Q: What can MODELER 2.0 do to help me?
A:   Same as above, plus handle bulk English paragraph inputs via our parser.  MODELER 2.0 goes way past text-mining tricks to support real time, conversational English I/O in its shell, eventually in voice mode.  The topics and associations  generated here become fodder for rule-based response generators. Think about automating a telephone call center with a scripted topic map, and you'll get what we envision.   A great goal for the 1.0 release might be simulating such an environment under instant message I/O and learning how WORDS can make it tractable. 

Q: How does voice I/O relate to MODELER?
A: The NLP needs of voice procession helped push us toward its design.  Release 3.0 will benefit voice I/O vendors, who can get from it a crucial new feedback loop that arises only with English understanding.  It lets software disambiguate the TERMs in each input by using the semantic state of CONTEXT.   But the heuristics only work if its topics have adequate semantic depth, so a smart CONTEXT seems required for continuous voice I/O.  If WORDS works well on your text-based applications, in 2-3 years it and Topic Maps could be critical support structures for voice I/O.