the present invention addresses the cost and lack of efficiency in known method of generating a labeling guide . instead of starting from scratch with each new application for which a labeling guide must be generated , the present invention enables a labeling guide designed as disclosed herein to be ported or used for new applications by requiring labeling guide designers to modify a smaller set of data that relates to the new application or new domain . in this regard , the designer of the labeling guide has a reduced workload and can more quickly and efficiently design the labeling guide for new applications . according to the invention , user &# 39 ; s utterances should be labeled with the intent of the speaker as opposed to the action that the system must take in response . once the intent is captured , changes or extensions in application only require changes in the responses to the intents . to capture the intent , a two - tiered tagging scheme is proposed . fig2 illustrates an exemplary flow - chart for the method of the present invention . the first tier of each label ( tag ) may be a domain - independent verb ( also referred to as predicate ) that reflects the action the user is trying to perform by the utterance . a labeling guide designer selects domain - independent actions ( 202 ) according to this first tier organization . these predicates are sometimes also referred to as dialog acts but will generally be referred to herein as domain - independent actions . the designer may select a set of domain independent actions from a pre - existing set that may be derived from a previous labeling guide or from other documentation . in other cases , the designer may generate a new set of domain - independent actions for an application . clearly , as more sets of domain - independent actions are developed , the more these existing sets will be used and drawn upon for newly developed labeling guides . included within the file history of the present application is an example labeling guide generated according to this two tiered approach . this labeling guide is incorporated herein by reference . this example labeling guide is for a telecom industry customer care application . labelers who use the information contained in the labeling guide listen to numerous calls and label each call according to calltypes and other information . for example , in this labeling guide , there are five groups of calltypes in a verb ( noun ) format : billing for general billing services ; service for general service queries ; named entities for specific data items requested or supplied by the caller ; discourse for generated speech used when the user converses with the system ; and miscellaneous . other calltypes are contemplated and will come within the scope of the invention . an example of a calltype in the verb ( noun ) format is combine ( account ). this is for when a caller wants only one bill from the company for all user accounts . for example , the caller wants to receive their charges on another company &# 39 ; s bill — such as they desire to have their verizon bill shown on their at & amp ; t account . the “ combine ” first - tier component of this calltype is independent from the domain and reflects a user intent or a general action ( combine account ) that the user desires . the “ noun ” or “ account ” second - tier portion of the calltype reflects the domain - related objects , action or concept ( also known as argument ) on which the first - tier action is being performed . in this case , the user desires to “ combine ” “ accounts .” since the meaning of domain - independent actions remain the same across the applications , one could use data from other applications to build the models for a new application . one could directly use the same data in a new application if the domain objects offered in the previous application were the same as in the new applications . for example , many applications deal with “ bills ” and caller requests are commonly requests for an explanation of their bill . in such fortunate cases , data previously labeled by “ explain ( bill )” can be directly used for the new application . in other cases , a labeling guide designer would have to transform the data to make it suitable for the new application . in the telecom domain , for example , if a labeling guide designer has data labeled for report ( service_problem ), the designer could use this data for a software company that attends to the software problems , i . e ., report ( software_problem ), by replacing the phrase that points to the service problem with those indicating a software problem . an example of the steps necessary to manage this portability follows : the utterance “ i have a & lt ; company & gt ; corporate calling card it doesn &# 39 ; t work i want to know why ” having a calltype of report ( service_problem ) can be changed to “ i have a & lt ; company & gt ; tax software it doesn &# 39 ; t work i want to know why ” having a calltype of report ( software_problem ) by simply changing the “ corporate calling card ” which is a domain object in the telecom domain to “ tax software ” which is a domain object for the software company . such modification to previously labeled data can be done automatically by using pattern recognizers of domain objects and actions . the terms “ actions ” and “ objects ” and / or “ concepts ” that reflect the arguments or subject matter of a domain independent or domain - dependent analysis are used interchangeably and may have a broad or narrow meaning depending on the concept of the use of any particular term . after the labeling guide designer identifies and selects the domain , the second - tier action constitutes the domain related objects actions or concepts ( also referred to as arguments ) on which this action ( from first tier ) is being performed . some examples of predicates from the first tier follow — request : an utterance embodying a request for specific object ; tellme : an utterance in which there is a request for specific information ; report : an utterance in which some information is being reported ; verify : an utterance in which there is a request to verify something ; explain : an utterance embodying a request for some observation . some further examples of the arguments ( the second tier ) from a transactional domain are credit , payment , and bill_charge . having identified the domain - dependent objects and concepts , a list of labels ( tags ) can be generated by joining them with domain independent predicates — for example : request ( credit ), verify ( payment ), explain ( bill_charge ), and report ( payment ). for illustration purposes , some examples of the utterances and their labels from this set are given below . utterance : “ i see charges on my bill that i do not understand ” label : explain ( bill_charge ) utterance : “ i am just wanting to tell you that i have made the payment ” label : report ( payment ) utterance : “ i am calling to check if you received my payment ” label : verify ( payment ) notice that by separating domain - dependent aspects from domain - independent aspects of labeling provides a systematic method to create a labeling guide . once labelers understand the semantics of predicates , they only need to learn to spot the domain - dependent object / concepts in the utterances from a new and different application . this reduces the complexity and training necessary when training labelers for new applications . these labels capture the intents embedded in the utterance ; therefore changes / extensions in application only require changes in the responses to the intents and do not require re - labeling of data . since the labeling scheme captures the intent that is consistent across applications , it is possible to use data labeled for one application for developing other applications . for example , data labeled as request ( credit ) can be used for all applications where a caller is likely to ask for credit . embodiments within the scope of the present invention may also include a labeling guide generated according to the process described above . in this regard , such a labeling guide will be similar in general principles to the labeling guide incorporated discussed above that is incorporated herein by reference . although the above description may contain specific details , they should not be construed as limiting the claims in any way . other configurations of the described embodiments of the invention are part of the scope of this invention . for example , some aspects of the process of generating a labeling guide may be automated where possible . in this regard , although the general description of the invention above relates to a more manual process of labeling guide designers selecting domain - independent and domain - dependent objects , some of these may be presented and selected in a software or multi - media electronic context and such applications are considered within the scope of the invention . accordingly , the appended claims and their legal equivalents should only define the invention , rather than any specific examples given .