Regarding my previous unfinished message.

1. Build UML "Use Case" of scenario

   http://www.omg.org/techprocess/meetings/schedule/Technology_Adoptions.html#tbl_UML_Specification

   I believe a graphical diagrammatic representation of your scenario for the "use" of SDS, applying the standardized "use case" notation of the Unified Modeling Language (UML) will be beneficial to your efforts at communicating, marketing, and implementing SDS. You can download an evaluation version of a UML CASE tool from www.rational.com and a few other sites that should suffice for learning and application to your need. Let me know if you'd like to examine this option and need any assistance.

   In the same regard, I believe that your embracing the use of terms, concepts, and constructs (methods, tools, notation) from the standard technologies that seem to overlap your approach would benefit you.

   This might take the form, initially, of a cross-reference table where your terms are in one column, and the corresponding standard technology terms and sources are in the other column.

   I'm in the process of doing this for my own work, starting with an online glossary of terms (mine and others). The standard technologies I see overlapping your approach are the ones I've identified earlier (XML tagging, XLL as XML Extended Linking -XLink and XML Extended Pointer - XPointer) and iCalendar. I perceive that your approach nicely encapsulates some of the functionality of each of these standard technologies, while extending the idea of tags, links, and pointers to include the significant capability for time-stamped and source-stamped tags.

   Your demonstrated use of this resultant functionality is quite powerful and satisfies a broad yet unstated need. You might consider packaging your approach as a standards Draft Submission to some group like the ISO, IEEE, EIA, ANSI, IETF, or W3C unless you want to try to keep it proprietary.

   The risk of keeping it proprietary is that:

   1. You do not appear to have any means to broadly implement this, market it, and thus dominate it sufficiently enough to "lock" in a steady sales base;

   2. It seems your approach can be easily reversed engineered, much as I have done by a brief examination of your product, and then repackaged or submitted as a "new" capability under another name by someone else (as has been done with several of my earlier prototypes); and

   3. It seems you do not meet the criteria for gaining a "patent" on your material (your functionality would be "obvious" to a practitioner once the idea was presented), although you can always claim copyright.

2. Contact Voice Recognition companies for their interest in licensing SDS to work within their products, or design a product to work with all Voice Recognition software (as text input to SDS).

   I've tracked several of the Voice Recognition/Recording technologies, and they all are assuming that the resultant text file from the recognition will be a flat file without contextual metadata (without content tagging or relation to other files through an advanced filing and linking system).

   SDS appears to be able to provide these Voice Recognition vendors the means to use their product as "Knowledge" recording devices, with their technologies at the front end, your technology in the middle, and appropriate storing/linking technologies in the back end. Your technology as middle-ware would also apply to all other recorded textual, seminstructured information [systems]. (http://www.one-world-is.com/rer/dem/slides/img089.gif).

   One of several possible competitors to your categorization, indexing, tagging efforts is at: http://www.autonomy.com

   You've made your time and source tagging and linking explicit and visible as data, while most other approaches to time and source tagging and linking have hidden the constructs as metadata or system data.

3. Send link to GEM "Object to Fact flow" diagram.

   The diagram at http://www.one-world-is.com/rer/dem/img111.gif is one I've provided to my current programming team to aid in their implementation of the underlying software engine for dynamic object management, http://www.one-world-is.com/rer/dem/img033.gif which my client will use for management of a large-scale "IT Architecture" effort for DoD, http://www.one-world-is.com/rer/bei/img064.gif within a larger "Enterprise Management" improvement effort.

4. Review of IETF Calendaring and Scheduling standards http://www.imc.org/ietf-calendar/ The iCalender DTD http://www.imc.org/draft-dawson-ical-xml-dtd used in conjunction with XLL provides a good foundation for building SDS as an XML application on top of XML-enabled Application and Database Server(s).

   See above on "standards" approach. I believe that the more you embrace standard technology, perhaps even extending it through commercial or standardization processes, the richer your approach will become, and the more likely of broad and simpler implementation.

5. NSF terms of grant content ownership.

   NSF Info relevant to us is at NSF Info relevant to us is at http://www.eng.nsf.gov/sbir/index.htm. Particularly look at Chapter 1 of the SBIR/STTR guide for 99 http://www.nsf.gov/pubs/1999/nsf9957/Chapt-1.htm Then look at http://www.nsf.gov/pubs/1999/nsf9957/Chapt-8.htm#IT to see where both our efforts, singly and jointly, would apply. Regarding our retention of ownership of the resultant research and data, and the government's rights to it see http://www.nsf.gov/pubs/1999/nsf9957/Chapt-5.htm#BM5_5 through Section 5.8.

6. As a critique, both our writing styles are too complex and use far too many modifiers in phrases, clauses, and sentences. We both use esoteric terms as though they were common, or use common terms in ways that are assuming contextual/subject awareness of our meaning/variation/history/ background/concepts. This is a consistent trait with intellectuals who have high competency with words, concepts, and abstraction, and is also common to "specialists" in a given subject. We appear to be are both.

   This trait is a strength when communicating with peers because it instills confidence, and is a weakness when communicating with the public because it excludes them. Who are we trying to communicate with, and what are we trying to communicate? We might be able to "sell" our ideas to individuals or small groups with whom we've spent our individual time "translating" and "tailoring", but we have obviously not succeeded in "selling" to a market.

   I've been working with some friends and family to get a "Napolean's Corporal" view of my content (also known as proofreading and editing). It has been quite revealing and helpful. I expect that improvements of my efforts will follow from this.

Sincerely,

Roy
roy@one-world-is.com