Abstract:
The present invention discloses a software development system for WIKIs including a WIKI server, a BLOG server, and a data store. The WIKI server can serve WIKI pages to WIKI clients. The BLOG server can serve BLOGs to BLOG clients. The data store can manage WIKI BLOG entries. Each WIKI BLOG entry can include a link to one of the WIKI pages and metadata for the linked WIKI page. The metadata can include a WIKI page title, a WIKI page version, a WIKI page description, design notes, and other information. Searchable keywords can be generated from the metadata. WIKI BLOG entries can be searched by WIKI developers to find WIKI pages having designer specified criteria based on a keyword search. Wherein searching for WIKI BLOG entries and editing discovered WIKI pages associated with WIKI BLOGs can be performed by a WIKI client via a WIKI interface.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This continuation-in-part application claims the benefit of U.S. patent application Ser. No. 11/765,900 filed Jun. 20, 2007, the benefit of U.S. patent application Ser. No. 11/765,928 filed Jun. 20, 2007, and the benefit of U.S. patent application Ser. No. 11/765,962 filed Jun. 20, 2007, which are incorporated by reference herein. 
    
    
     BACKGROUND 
     1. Field of the Invention 
     The present invention relates to the field of WIKI applications and, more particularly, to a WIKI application development tool that uses specialized BLOGs to publish WIKI developmental content in an organized/searchable fashion. 
     2. Description of the Related Art 
     A WIKI is a collaborative web application that allows end users to add and edit content. A WIKI application refers to a collection of WIKI pages written in a markup language that are interconnected via hyperlinks. WIKIs are served by a WIKI server to standard Web browsers which function as WIKI clients. A WIKI server can also serve a special Web page that is a WIKI editor where users add and edit content. Some WIKI sites permit WIKI content to be written in accordance with a WIKI syntax, such as having special characters to indicate hyperlinked content, bulleted content, and the like. WIKI syntax is generally designed to be more intuitive for end-users to utilize than standard markup languages. 
     Although WIKI pages are quickly and easily developed by relatively novice developers, conventional development techniques for WIKIs have many significant disadvantages. At present, WIKIs are developed in an ad-hoc, loosely coupled manner. Each WIKI page generally behaves in an autonomous fashion in accordance with internally defined standards. A WIKI application formed from multiple linked WIKI pages typically has a non-cohesive feel. In other words, unlike conventional applications that have many common and consistent components, such as common color schemes, common font sizes and types, common toolbars and toolbar icons, common pop-up windows, common hot-key combinations, and the like, a look and feel of a WIKI application can vary greatly from page to page. Further, a current lack of cohesion among WIKI pages makes it difficult to establish settings that affect an entire WIKI application. State information is generally not retained from page-to-page or session-to-session. 
     Additionally, WIKI syntax and WIKI editors are presently not standardized and WIKI implementation specifics can vary from one WIKI server to another. Thus, a WIKI developer creating a set of one or more linked WIKI pages for execution on one WIKI server may have to manually adjust or recreate the set of WIKI pages for execution on a different WIKI server. 
     Generally, software design principles used for most types of programming, such as modularization, software re-use, documenting code, documenting an application, and the like, have not been applied to WIKI applications. This lack of foundational structure has relegated WIKIs to small scale software efforts which can be quickly created by a single developer. 
     At present, no community/collaboration toolsets exist that facilitate integrated development efforts other than providing content to an otherwise static WIKI application. Tools do not exist to permit developers to collaborate on creating/modifying the WIKI application itself. Existing WIKI tools do not encourage developers to create re-usable code components, to share code components with others, or to utilize code components created by others. What is needed is a mechanism to facilitate sharing and re-use of WIKI application code, preferably in a fashion consistent with general Web 2.0 techniques and protocols. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       There are shown in the drawings, embodiments which are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown. 
         FIG. 1  is a schematic diagram of a system for establishing and using BLOGs for WIKI publication in accordance with an embodiment of the inventive arrangements disclosed herein. 
         FIG. 2  shows a WIKI editing interface that includes options to publish a WIKI and to search for WIKI content in accordance with an embodiment of the inventive arrangements disclosed herein. 
         FIG. 3  is a schematic diagram of a system for a Web 2.0 for voice system in accordance with an embodiment of the inventive arrangements disclosed herein. 
         FIG. 4  is a schematic diagram illustrating a WIKI server configured to interact with a speech for Web 2.0 system in accordance with an embodiment of the inventive arrangements disclosed herein. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       FIG. 1  is a schematic diagram of a system  100  for establishing and using BLOGs for WIKI  136  publication in accordance with an embodiment of the inventive arrangements disclosed herein. A BLOG for WIKI  136  publication is a special BLOG that contains collections of WIKI applications and pages. Each entry in the BLOG for WIKI  136  publication can include a link to a WIKI page as well as metadata information pertaining to the WIKI page. The metadata information can include a page version, title, developer, summary, and other information. The metadata information of the BLOG for WIKI  136  publication can be indexed for keyword searching. The BLOG for WIKI  136  publication can be organized so that developers  140 ,  142  can add new content and search for pre-existing content matching desired criteria. Thus, the BLOG for WIKI  136  publication facilitates WIKI re-use and code sharing among a set of developers  140 ,  142 . 
     More specifically, a WIKI developer  140  can utilize an editor  112  of a WIKI server  110  to create a WIKI  150 . Upon creating the WIKI, the developer  140  will be provided an option to publish the WIKI content, which triggers a publication event. In one embodiment, the WIKI server  110  can automatically initiate the publication event upon WIKI creation or modification. The publication event causes a publication engine  114  to convey WIKI data  152  to the BLOG server  130 , where it is ultimately processed to create a BLOG for WIKI publication  136  which is stored in data store  134 . The newly created WIKI can be placed in data store  118 , where it is served as a WIKI page  119  which may be linked to other pages  119  to create a WIKI application. 
     Other developers can specify criteria used by resource searching engine  116  to search the data store  134  for matching BLOG for WIKI  136  publications. These discovered publications can link the developer to a related WIKI page which can be edited by the developer. The developer can, for example, incorporate the discovered WIKI content into a new project, thus leveraging pre-existing software that should minimize the development time. In another example, the developer can customize a pre-existing WIKI so that it behaves in a user-desired manner. Thereafter the user and others preferring the customization can use the modified WIKI instead of the base WIKI. 
     In one embodiment, publishing WIKI data  152  to the BLOG server  130  can entail copying all the related files for the WIKI to an external data space, such as data store  134 . A WIKI developer  142  can modify  156  the stored WIKI by first accessing a WIKI server  120 . The WIKI server  120  can query the data store  134 , can retrieve the stored WIKI data  154 , and can store this data  154  in data store  122 . The WIKI server  120 , which is different from the original server  110 , can publish the WIKI version that was modified by the developer  142 . 
     Additionally, the BLOG server  130  can include a Rich Site Summary (RSS) engine  132 , which establishes RSS feeds related to the BLOG for WIKI  136  publications. Developers  142  can subscribe to the RSS engine  132  and can receive update  123  notifications whenever changes are made to a corresponding WIKI page. 
     Unlike WIKIs, BLOGs are highly organized, often using the ATOM PUBLISHING PROTOCOL (APP) or other organized structure for storing and linking content. BLOG for WIKI publication  160  shows a exemplary structure for a sample BLOG for WIKI publication. The publication  160  is associated with a WIKI application that stored different categories of accessible content in a hierarchy. Categorized content can include category entries  170 , such as literature and music. The music category can include subcategories  172  of rock, classical, and other types of music. Each type of music can be broken down into entries  174  for artist, album, song, and the like. 
     Each BLOG for WIKI item can include an introspection document, an entries link, and a resource link in accordance with the APP or other utilized protocol. Each entry can be associated with a WIKI application, page, or page element. A special type of entry can be a metadata entry  171 , which provides metadata information concerning a parent item, such as version, title, summary, and the like. In another embodiment, the metadata can be associated with special markup tags, which can be introspected, and need not be implemented as a separate entry  171 . 
     A set of resources can also be associated with each item of the BLOG for WIKI publication  160 . Resources can contain media that is applicable at each level of the WIKI. In one embodiment, these resources can include speech resources used to speech-enable the associated WIKI. To illustrate, the music entry of category  170  links to media resources  176 . These resources  176  include a media plug-in for playing music and a set of input/output (I/O) controls. The I/O controls are linked to speech processing resources  178 , such as automatic speech recognition (ASR) resource and text-to-speech (TTS) resource. These resources  178  can be further configured, such as by specifying speech recognition grammars, a speech synthesis language, and the like. 
       FIG. 2  shows a WIKI editing interface  210  that includes options to publish a WIKI  211  and to search for WIKI content  212  in accordance with an embodiment of the inventive arrangements disclosed herein. The publication option  211  and the searching option  212  rely upon an infrastructure where WIKI data is published to a BLOG server which organizes the WIKI data in BLOG for WIKI publications. Thus, the interface  210  can be an interface of WIKI server  110  or  120  as shown in system  100 . It should be appreciated that details of interface  210  are for illustrative purposes only and that derivatives in element arrangement, included tools, interface modality, and the like are contemplated. 
     The interface  210  can be rendered in a standard browser which is able to render pages served by a WIKI server. A special WIKI application is shown, which is transparently integrated to a BLOG server, and which stores BLOG for WIKI publications. The publish WIKI  211  tab can permit the rendered WIKI page to function as a BLOG editor for BLOG for WIKI publications. In one embodiment, a user can also view, edit and search BLOG for WIKI publications through a BLOG interface (not shown) served by a BLOG server. 
     A second special WIKI application is associated with the search for WIKI tab  212  that is configured to permit a user to search BLOG entries associated with WIKIs (e.g., BLOG for WIKI publications) to choose entries of interest. More specifically, the search  211  application can include a criteria specification element  214  which permits a user to enter search terms. These terms are compared against indexed keywords. The indexed keywords can be constructed by analyzing metadata associated with WIKI for BLOG publications and/or by analyzing content of WIKI for BLOG publications. In system  100 , resource searching engine  116  can perform tasks associated with querying a data store for entries that satisfy the criteria entered in element  214 . 
     Upon pressing a find button, a set of results  216  can be presented. These results can include a title  220  of a matching entry, version information  222 , ownership information  224 , and other metadata associated with a WIKI. For example, user criteria of “authentication based on speech” can produce results  216  including “1. SIV (speech identification and verification) WIKI,” a “2. Speech Construction WIKI,” “3. Speech Authentication treatise,” and “4. Authentic Speeches WIKI” as shown in  FIG. 2 . Each returned WIKI result can be further decomposed into sub-elements, as shown by the sub-elements of “SIV Resource,” “Audio Input Resource,” “Enrollment Resource,” and “Authentication Dialog Entry,” which each correspond to the “SIV WIKI component.” 
     Sub-elements are in accordance with an underlying organizational structure which can conform to an APP based protocol. Thus, the BLOG for WIKI  160  publication of system  100  would include sub-elements of literature and music. The music sub-element would have further sub-elements of rock, and classical. The rock sub-element would have sub-elements of artist 1 and artist N. Appreciatively, organizing WIKI applications in the specified structure permits fine-grained control of WIKI entries and resources which lends itself to software re-use and sharing. User facing tools, such as interface  210 , permits advantages of the organized structure to be exploited by WIKI application developers. 
     Each returned WIKI result  216  item can be associated with one or more user selectable actions. One selectable action can be to subscribe to an RSS  226  feed associated with an item. Pressing the RSS button  226  corresponding to the SIV resource, for example, can ensure a user is provided with notices whenever the SIV resource is modified. Another selectable action is a retrieve  228  action. This action can cause the selected item to be retrieved. Retrieving an item can load syntax for that item into a WIKI editor. Thus, retrieving  228  the SIV WIKI component and then pressing the WIKI markup tab can result in a presentation of editable WIKI markup for the SIV WIKI component. The actions  226 ,  228  are not intended to be exhaustive and other actions are contemplated. For example, actions to edit/view metadata, to upload WIKI server data for publication in a specified WIKI server, to solicit an owner for permission to modify a secure or proprietary WIKI item, and other actions are to be considered within the scope of the present invention. 
       FIG. 3  is a schematic diagram of a system  300  for a Web 2.0 for voice system  330  in accordance with an embodiment of the inventive arrangements disclosed herein. System  300  can be one contemplated underlying infrastructure for system  100 . 
     In system  300 , Web 2.0 clients  340  can communicate with Web 2.0 servers  310 - 314  utilizing a REST/ATOM  350  protocol. The Web 2.0 servers  310 - 314  can serve one or more speech-enabled applications  320 - 324 , where speech resources are provided by a Web 2.0 for Voice System  330 . One or more of the speech-enabled applications  320 - 324  can include AJAX  356  or other JavaScript code. In one embodiment, the AJAX  356  code can be automatically converted from WIKI or other syntax by a transformer of a server  310 - 314 . The servers  310 - 314  can communicate with each other using a REST/ATOM protocol. For example, the WIKI server  310  can publish WIKI data to BLOG server  312 , which organizes and indexes the WIKI data in an APP compliant format. Special WIKI applications ( 320 ) can search entries managed by the BLOG server  312 , as described in  FIGS. 1 and 2 . 
     Communications between the Web 2.0 servers  310 - 314  and system  330  can be in accordance with REST/ATOM  356  protocols. Each speech-enabled application  320 - 324  can be associated with an Atom container  331 , which specifies Web 2.0 items  332 , resources  333 , and media  334 . One or more resource  333  can correspond to a speech engine  338 . REST/ATOM protocols  350 ,  356  can include HyperText Transfer Protocol (HTTP) and similar protocols that are RESTful by nature as well as APP or other protocols that are specifically designed to conform to REST principles. 
     The Web 2.0 clients  340  can be any client capable of interfacing with a Web 2.0 server  310 - 314 . For example, the clients  340  can include a Web or voice browser  341  as well as any other type of interface  344 , which executes upon a computing device. The computing device can include a mobile telephone  342 , a mobile computer  343 , a laptop, a media player, a desktop computer, a two-way radio, a line-based phone, and the like. There are no assumptions regarding the client  340  other than an ability to communicate with a Web 2.0 server  310 - 314  using Web 2.0 conventions. 
     The Web 2.0 servers  310 - 314  can be any server that provides Web 2.0 content to clients  340  and that optionally provides speech processing capabilities through the Web 2.0 for voice system  330 . The Web 2.0 servers can include a WIKI server  310 , a BLOG server  312 , a MASHUP server, a FOLKSONOMY server, a social networking server, and any other Web 2.0 server  314 . 
     The Web 2.0 for voice system  330  can utilize Web 2.0 concepts to provide speech capabilities. A server-side interface is established between the voice system  330  and a set of Web 2.0 servers  310 - 314 . Available speech resources can be introspected and discovered via introspection documents, which are one of the Web 2.0 items  332 . Introspection can be in accordance with the APP specification or a similar protocol. The ability for dynamic configuration and installation is exposed to the servers  310 - 314  via the introspection document. 
     That is, access to Web 2.0 for voice system  330  can be through a Web 2.0 server that allows users (e.g., clients  340 ) to provide their own customizations/personalizations. Appreciably, use of the APP  356  opens up the application interface to speech resources using Web 2.0, JAVA 2 ENTERPRISE EDITION (J2EE), WEBSPHERE APPLICATION SERVER (WAS), and other conventions rather than being restricted to protocols, such as media resource control protocol (MRCP), real time streaming protocol (RTSP), or real time protocol (RTP). 
     The Web 2.0 for Voice system  330  is an extremely flexible solution that permits users (of clients  340 ) to customize numerous speech processing elements. Customizable speech processing elements can include speech resource availability, request characteristics, result characteristics, media characteristics, and the like. Speech resource availability can indicate whether a specific type of resource (e.g., ASR, TTS, SIV, VoiceXML interpreter) is available. Request characteristics can refer to characteristics such as language, grammar, voice attributes, gender, rate of speech, and the like. The result characteristics can specify whether results are to be delivered synchronously or asynchronously. Result characteristics can alternatively indicate whether a listener for callback is to be supplied with results. Media characteristics can include input and output characteristics, which can vary from a URI reference to an RTP stream. The media characteristics can specify a codec (e.g., G711), a sample rate (e.g., 8 KHz to 22 KHz), and the like. In one configuration, the speech engines  338  can be provided from a J2EE environment  336 , such as a WAS environment. This environment  336  can conform to a J2EE Connector Architecture (JCA). 
     In one embodiment, a set of additional facades  360  can be utilized on top of Web 2.0 protocols to provide additional interface and protocol  362  options (e.g., MRCP, RTSP, RTP, Session Initiation Protocol (SIP), etc.) to the Web 2.0 for voice system  330 . Use of facades  360  can enable legacy access/use of the Web 2.0 for voice system  330 . The facades  360  can be designed to segment the protocol  362  from underlying details so that characteristics of the facade do not bleed through to speech implementation details. Functions, such as the WAS 6.1 channel framework or a JCA container  337 , can be used to plug-in a protocol, which is not native to the J2EE environment  336 . The media component  334  of the container  331  can be used to handle media storage, delivery, and format conversions as necessary. Facades  360  can be used for asynchronous or synchronous protocols  362 . 
       FIG. 4  is a schematic diagram  400  illustrating a WIKI server  430  configured to interact with a speech for Web 2.0 system  410  in accordance with an embodiment of the inventive arrangements disclosed herein. Although a WIKI server  430  is illustrated, server  430  can be any WEB 2.0 server including, but not limited to, a BLOG server, a MASHUP server, a FOLKSONOMY server, a social networking server, and the like. 
     In the system  400 , a browser  420  can communicate with WIKI server  430  via a REST/ATOM  404  based protocol. The WIKI server  430  can communicate with system  410  via a REST/ATOM  402  based protocol. 
     The WIKI server  420  can include a data store  432  in which speech-enabled applications  434  and other server applications are stored. In one embodiment, the applications  434  can be written in a WIKI syntax contained in an APP format. 
     The contents of an application  434  can be accessed using editor  450 . The editor  450  can be a standard WIKI editor having a voice plug-in or extensions  452 . Modifications made to the application  434  via the editor  450  can be published to a BLOG server, where WIKI data is able to be stored as BLOG entries. 
     The transformer  440  can convert WIKI syntax into standard markup for browsers. In one embodiment, the transformer  440  can be an extension of a conventional transformer that supports HTML and XML. The extended transformer  440  can be enhanced to handle JavaScript, such as AJAX. For example, resource links of application  434  can be converted into AJAX functions by the transformer  440  having an AJAX plug-in  442 . The transformer  440  can also include a VoiceXML plug-in  444 , which generates VoiceXML markup for voice-only clients. 
     Each of the speech-enabled WIKI applications  434  can be organized in an APP based format, as shown by WIKI application  460 . The application  460  includes an introspection document and a link to an entries collection  462  and a resource collection  464 . Each of these collections  462  and  464  can be linked to other collections  466 - 469 . For example, entry collection  462  can be a collection of WIKI pages, which are linked to WIKI page sections (collections  466 - 467 ). The resource collection  464  can include speech processing resources, which are linked to resource specifics (collection  468 - 469 ). 
     The present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in one computer system or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein. 
     The present invention also may be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form. 
     This invention may be embodied in other forms without departing from the spirit or essential attributes thereof. Accordingly, reference should be made to the following claims, rather than to the foregoing specification, as indicating the scope of the invention.