1.  Automate recurring and on-demand ways to request its output via the local SOAP server, then save its records locally for asynch retrievel into Java objects as needed for processing.

2.  Model all exported fieldnames, record names, and lang/NASIC markers using RDF, to add "semantics" we can tweek as needed.  They will associate with known INTERESTS for Trade Show GROUPS, USERS, etc.

3.   Select an inference engine to process the metadata.  (This project will eval and compare available options.  Stick to Java versions ideally; if Cyc is up and not prohibitive in price/complexity, make it an early contender.)

4.  Design a report-producer using our RDF data plus other selected ontologies to answer queries on things modeled in step 2.  Explore USER-specific topic maps as a simple way to scope such queries to personalized contexts.

5.  Design servet-based I/O mechanisms, limiting queries to those things (or contexts) that work well enough to be publicly released.

Step 1 we need anyway.  Steps 2-5 should let us explore many issues in this new area at modest costs (labor-only).  Release 1.0 is ideally before Christmas.

A.  An interesting Trade Show mechanism to find GROUPS, MEMBERS, PROJECTS, ... which match the self-declared INTERESTS of a USER.  It would become a standard, hopefully sexy, feature of the lobby.

B.  A profitable extension to MESDA's Industry Directory, which can expand gradually into a semantic web "map" open to ANY Maine developer, project, etc.  To become modeled in it, a company or GROUP not belonging to MESDA would pay a modest fee, then post a self description.  Then they too would appear in the reports which answered USER's queries.

C.  A prototype Java product potentially portable to ANY set (!) of RDF and XTM files compliant with expectations.  It would have 5 layers total, which ideally could be quickly customized and reconfigured at the text file level:

• to new SOAP inputs via new ontology data cited at layer #2, then..
• to each new client GROUP and/or USER via topic maps in #4

The basic value proposition would be "smarter" (more personalized) queries than a DB or text inderer could offer.  In practice, good marketing partners for the C usage might be the supplier of layer #3's engine, or the supplier(s) of the SOAP service(s) whose data it helped clients to retrieve.