CN101137957A

CN101137957A - 用于在基于任务的对话系统中产生查询的方法和系统

Info

Publication number: CN101137957A
Application number: CNA2006800029198A
Authority: CN
Inventors: 李恒舜; 威廉·K·汤普森
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 2005-01-26
Filing date: 2006-01-26
Publication date: 2008-03-05
Also published as: BRPI0607223A2; US20060167848A1; KR20070090045A; WO2006081369A2; EP1846814A2; WO2006081369A3

Abstract

提供了一种用于在基于任务的对话系统(102)中查询数据库(106)的方法。所述基于任务的对话系统(102)包括任务模型(110)、用户模型(114)、对话管理器(112)、查询产生器(116)和映射器(120)。所述方法解释被要求来完成任务的用户输入。产生用于查询所述数据库(106)的查询。如果所产生的查询并不适于查询所述数据库(106)，那么它被转换为适当的查询。执行适当的查询以便完成所述任务。

Description

用于在基于任务的对话系统中产生查询的方法和系统

技术领域

本发明涉及对话系统领域并且尤其涉及在基于任务的对话系统中查询生成的领域。

背景技术

基于任务的对话系统是与用户相交互以便完成一个或多个任务的系统，所述任务诸如检索信息、处理事务以及其它这类问题求解任务。在用户和基于任务的对话系统之间的一组交互作用被称作为对话。每个交互作用被称作为对话的回合(turn)。由用户或基于任务的对话系统所提供的信息被称作为对话的上下文(context)。基于任务的对话系统具有为完成任务所要求的一组预定义的任务参数。用户经由诸如触敏显示屏或鼠标或小键盘之类的输入设备来指定任务参数的值。

典型情况下，任务参数根据它们的值相互关联。在数据库中定义了在任务参数之间的相关性。基于任务的对话系统发现这些相互关联性来完成任务。基于任务的对话系统查询数据库以发现这种相关性。

基于任务的对话系统使用由用户所提供的任务参数值作为模板，用来匹配来自数据库的数据。例如，用户希望通过定义城市区域和价格范围来执行搜索旅馆的任务。然后基于任务的对话系统查询数据库以获得旅馆细节并使用它们来完成该任务。

常规的基于任务的对话系统是与领域(domain)相关的。与领域相关的任务模型依赖于基于任务的对话系统所应用的应用领域的具体启发式。传统的基于任务的对话系统需要针对每种应用来设计。因此，传统的基于任务的对话系统无法用于不同的应用领域。此外，传统的基于任务的对话系统还依赖于数据库的存储格式。

附图说明

借助附图以举例而并非限制的形式来图示本发明，其中相同的附图标记表示同样的元素，并且其中：

图1是依照本发明一些实施例的基于任务的对话系统的框图；

图2是依照本发明一些实施例的对话管理器的框图；

图3依照本发明一些实施例示出了用于图示用来在基于任务的对话系统中查询数据库的方法的不同步骤的流程图；和

图4是依照本发明一些实施例用于产生查询的电子设备的框图。

本领域技术人员应当理解，为简单和清楚起见，图中所示元件并且不必按比例绘制所述元件。例如，可能相对于其它元件放大了图中的某些元件的尺寸，用于改进理解本发明的实施例。

具体实施方式

在依照本发明实施例详细描述用于在基于任务的对话系统中查询数据库的方法和系统之前，应当注意，本发明的实施例主要体现在与基于任务的对话系统相关的方法步骤和设备组件的组合当中。据此，在适当的情况下，已经用附图中的惯用符号表示了设备组件和方法步骤。这些附图只示出了与理解本发明相关的具体细节，以免用对那些本领域普通技术人员来说显而易见的细节模糊了本公开和这里所描述的有益效果。

参照图1，框图依照本发明一些实施例示出了其中可以实施本发明的代表性环境100。代表性环境100包括基于任务的对话系统102、用户104、数据库106和输入/输出模块108。基于任务的对话系统102与用户104相交互以完成所述用户104所希望执行的任务。在交互作用期间，用户104提供为完成任务所要求的输入。用户104经由输入/输出模块108提供输入。输入/输出模块108可以是用户接口，诸如计算机监视器、触摸屏、键盘、麦克风(用于自动语音识别)或其组合。在用户104和基于任务的对话系统102之间的交互作用被称为对话(dialog)。每个对话包括在用户104和基于任务的对话系统102之间的多个交互作用(interaction)。每个交互作用被称作为对话的回合(turn)。由用户104或由基于任务的对话系统在对话的每个回合所提供的信息被称作对话的上下文(context)。基于任务的对话系统102维护并更新对话的上下文。数据库106存储数据用于完成用户104所提供的任务。数据库106的例子包括XML数据库和关系数据库。基于任务的对话系统102查询数据库106以完成该任务。基于任务的对话系统102向用户104提供查询的结果。基于任务的对话系统102经由输入/输出模块108向用户104提供结果。基于任务的对话系统102并不依赖于使用该基于任务的对话系统102的领域的特定信息。

例如用户104希望执行预订旅馆房间的任务。用户104向基于任务的对话系统102提供了城市区域和价格范围作为输入。基于任务的对话系统102使用这两个输入来查询数据库106并且获得旅馆详情。使用这些详情与用户104进一步对话来完成任务。

图1还示出了依照基于任务的对话系统102的组件。基于任务的对话系统102包括任务模型110、对话管理器112、用户模型114、查询产生器116、判定装置118和映射器120。对话管理器112使用任务模型110、用户模型114和对话上下文来解释由用户104所提供的输入。对话管理器112根据由用户104所提供的输入的解释来制作模板。模板按可用于产生查询的构造形式包含由用户104所提供的输入。对话管理器112向查询产生器116提供模板。查询产生器116使用对话管理器112所提供的模板来产生第一查询。在本发明的一个实施例中，查询产生器116用XQuery产生第一查询。判定装置118确定该第一查询是否适合于查询数据库106。可用于查询数据库的某种语言的查询被称为适于查询数据库，例如只有用SQL编写的查询可以用于查询关系数据库。因此，SQL查询适合于关系数据库。判定装置118可以作为软件、硬件或其组合来实现。如果第一查询适合于查询数据库106，那么使用所述第一查询来查询数据库106。如果第一查询不适于查询数据库106，那么在本发明的一个实施例中，映射器120把所述第一查询转换为第二查询，所述第二查询适合于查询所述数据库106。在本发明的一个实施例中，第二查询是SQL查询。映射器120的例子包括XQuery到SQL的映射器和SQL到XQuery的映射器。然后使用第二查询来查询数据库106。向对话管理器112提供通过查询数据库106所获得的结果。

参照图2，框图依照本发明一些实施例示出了对话管理器112。对话管理器112包括解释器202和决策装置204。解释器202接受并解释由用户104所提供的输入。解释器202使用对话的上下文、任务模型110和用户模型114来解释该输入。解释器202可以使用与用户104进行对话的上下文或所存储对话的上下文。任务模型110是用于建模基于任务的对话系统102可以执行的任务的数据结构。用户模型114指定由用户104所提供的输入的相对分级(ranking)。解释器202向决策装置204提供解释。决策装置204根据由解释器202所提供的解释来执行检查以判定是否可以产生用于查询数据库106的第一查询。决策装置204进一步判定第一查询的类型。第一查询可以是参数完成查询或模板搜索查询。决策装置204可以作为软件、硬件或其组合来实现。

参照图3，流程图依照本发明一些实施例示出了用于在基于任务的对话系统102中查询数据库106的方法的一些步骤。所述方法并不依赖于利用所述方法的领域的特定信息。在步骤302，对话管理器112接受并解释由用户104所提供的输入以用于由用户104所选择的任务。用户104根据任务模型模式选择任务。任务模型模式规定了用户104可以执行的任务。所述任务的例子包括获取信息、处理事务以及其它这类问题求解任务。任务模型模式还规定为完成每个任务所需要的任务参数。任务模型模式的例子包括但不局限于可扩展标记语言(Extensible Markup Language，XML)模式和文档类型定义(DTD)模式。用户104与基于任务的对话系统102相交互以便提供关于任务的输入。此外，用户104提供了为完成任务所要求的任务参数值。对话管理器112使用对话的上下文、任务模型110和用户模型114来解释输入。当前对话的上下文或所存储对话的上下文可以由对话管理器112用来解释由用户104所提供的输入。

任务模型110是一种数据结构，用于建模基于任务的对话系统102可以执行的任务。使用任务模型模式来开发任务模型110。任务模型110由使用基于任务的对话系统102的应用可以执行的多个任务组成。对于每个任务来说，存在可以由该应用使用的一个或多个计划(plan)。用于任务的计划也被称为配方(recipe)。每个配方又包括为完成任务所需要执行的多个步骤。配方的每个步骤也被称为任务动作(act)。此外，配方还包含对任务动作执行的约束，诸如它们时间的次序以及是否可以重复合某个任务动作。每个任务动作又包括为完成任务所必须指定的多个任务参数。每个任务参数对应于基于任务的对话系统102所应用领域中的对象实例。任务参数可以被分类为原子参数或复合参数。只附带有一个属性的任务参数被分类为原子参数。附带有多个属性的任务参数被分类为复合参数。任务模型110中的任务模型域对象具有与数据库106的结构同构的结构。

用户模型114指定任务模型110的参数的相对分级，所述参数具有由用户104所指定的值。它根据基于先前对话所构建的用户偏好和简档来向对话管理器112提供关于在产生查询之前的对话期间需要从给定用户请求什么任务参数的信息。

对话管理器112根据对由用户104所提供输入的解释来执行检查，以确定是否可以产生第一查询来查询数据库106。例如，对话管理器112可以产生对数据库106的第一查询之前根据用户模型114来判定向用户104要求更多参数值。此外，对话管理器112根据对由用户104所提供输入的解释，来判定要产生的第一查询类型。由对话管理器112所产生的第一查询可以是参数完成查询或模板搜索查询。

所产生的用于完成部分指定的任务动作参数的查询被称作参数完成查询。所产生的根据完全由用户104指定的参数来完成任务的查询被称为模板搜索查询。

对话管理器112根据由用户104所提供的任务模型110的参数值来制作模板。使用模板来产生用于查询数据库106的第一查询。对话管理器112在判定第一查询的类型以产生对数据库106查询之后，调用查询产生器116。对话管理器112向查询产生器116提供模板。

在步骤304，查询产生器116产生对话管理器112所确定类型的第一查询。查询产生器116通过使用由对话管理器112所提供的模板来产生第一查询。

在步骤306，判定装置118确定该第一查询是否适合于查询数据库106。可用于查询数据库的某种语言编写的查询被认为适于查询该数据库，例如用SQL编写的查询可用于查询关系数据库。因此，SQL查询适合于关系数据库。如果第一查询适合于查询数据库106，那么使用该第一查询来查询数据库106。如果该第一查询不适于查询数据库106，那么在步骤308，映射器120把所述第一查询转换为第二查询，所述第二查询适合于查询所述数据库106。查询产生器116例如用XQuery产生第一查询并且数据库106是关系数据库。映射器120把第一查询转换为第二查询。第二查询是用可用于查询关系数据库的语言编写的查询，所述第二查询例如是SQL查询。然后使用第二查询来查询数据库106。向对话管理器112返回通过查询数据库106所获得的结果以完成任务。对话管理器112完成所述任务并且经由输入/输出模块108向用户104提供结果。

下面示出了示例性的任务模型。

<！DOCTYPE AIMModel SYSTEM″../resources/AimModel.dtd″>

<Constraint type＝″not″

<Constraint type＝″and″

<Constraint type＝”equals”

arg＝″deptCity.name″

arg＝″arrCity.name″>

</Constraint>

<Constraint type＝″equals″

arg＝″deptCity.state″

arg＝″arrCity.state″>

</C onstraint>

</Constraint>

<Constraint type＝″precedes″

arg＝″deptDate.time″

arg＝″arrDate.time″>

</Constraint>

</DomainObj ect>

</DomainObj ect>

</DomainObj ect>

</DomainModel>

</TaskAct>

</TaskAct>

</TaskAct>

</TaskAct>

</Recipe>

</TaskModel>

</IAMModel>

在上述任务模型中所指定的任务是‘LookupFlight’，即用户104想要关于航班的信息。使用来‘LookupFlightRecipe’配方来执行‘LookupFlight’任务。‘LookupFlightRecipe’包括‘SpecifyDeptCity’、‘SpecifyDeptDate’、‘SpecifyArrCity’、‘SpecifyArrDate’和‘FindMatchingFlights’作为任务动作。任务动作‘SpecifyDeptCity’、‘SpecifyDeptDate’、‘SpecifyArrCity’、‘SpecifyArrDate’和‘FindMatchingFlights’分别用来指定离港城市、指定离港日期、指定到港城市、指定到港日期以及查找匹配航班。‘LookupFlightRecipe’对离港日期、到港日期、用于任务动作‘SpecifyDeptCity’的一组参数值、用于任务动作‘SpecifyArrCity’的一组参数值以及将执行任务动作的次序具有约束。在‘LookupFlightRecipe’中，离港日期始终在到港日期之前，用于任务动作‘SpecifyDeptCity’的该组参数值不能与用于任务动作‘SpecifyArrCity’的该组参数值相同，并且将依照在‘LookupFlightRecipe’中所指定的次序来执行所述任务动作。任务动作‘SpecifyDeptCity’要求离港城市的名称以及离港州的名称作为参数值。任务动作‘SpecifyDeptCity’要求离港时间、离港日、离港月份以及离港年份作为参数值。任务动作‘SpecifyDeptCity’要求到港城市以及到港地的州名称作为参数值。任务动作‘SpecifyArrDate’要求到港时间，到港日、到港月份以及到港年份作为参数值。任务动作‘FindMatchingFlights’使用为任务动作‘SpecifyDeptCity’、‘SpecifyDeptDate’、‘SpecifyArrCity’和‘SpecifyArrDate’所指定的参数值来查找匹配的航班。下面示出了在数据库106中所存储的、用于完成上述任务模型的‘Flight’对象的示例性数据。

<City>

<name>Portland</name>

<state>Oregon</state>

</City>

</deptCity>

<Date>

<month>October</month>

</Date>

</deptDate>

<City>

<name>Portland</name>

<state>Maine</state>

</arrCity>

<Date>

<month>October</month>

</Date>

</arrDate>

</Flight>

以上任务模型中的任务模型领域对象具有与数据库106的结构同构的结构。例如，在数据库106中所存储的信息是XML格式，于是每个参数类型及其属性与XML元素相匹配。此外，对于原子型参数来说，即那些包含诸如离港城市名称之类的字符串值来说，所述值被存储在XML元素的正文中。对于复合型参数来说，即包含诸如离港时间之类的另外的领域对象的那些参数来说，对应于具有值的对象的XML元素被用作对应于复合型参数的元素的子元素。下面示出了另一示例性的任务模型。

<！DOCTYPE AIMModel SYSTEM″../resources/AimModel.dtd″>

<Attributename＝″number″type＝″string″></Attribute>

<Attributename＝″street″type＝″string″></Attribute>

</DomainObj ect>

</DomainModel>

</TaskAct>

</TaskAct>

</TaskAct>

</TaskParam>

</TaskAct>

</Recipe>

</TaskModel>

</IAMModel>

在以上任务模型中所指定的任务是‘Add Entry’和‘Find Entry’，即用户104想要增加或想要查找的电话簿中的条目。使用‘LookupFlightRecipe’配方来执行‘Find Entry’任务。‘FindEntryRecipe’配方具有‘Find Field’和‘Finish’作为任务动作。任务动作‘Find Field’和‘Finish’分别用于指定关于条目和用于完成任务的数据，所述条目将在电话簿中被发现。‘FindEntryRecipe’对待执行任务动作的次序具有约束。作为约束，将依照在‘FindEntryRecipe’中所指定的次序来执行任务动作。‘Find Entry’具有复合类型并且要求名、姓、家庭电话号码和地址作为参数值。此外，地址具有复合类型并且要求门牌号、街道名称以及城市名称作为参数值。下面示出了在数据库106中所存储的、用于完成上述任务模型的‘PhoneBookEntry’对象的示例性数据。

<firstname>raymond</firstname>

<street>Algonquin Rd.</street>

<city>S chaumburg</city>

</Address>

</address>

</PhoneBookEntry>

用户104有时在对话期间部分地指定参数，例如对于‘LookupFlight’任务来说，在与用户104的对话中，基于任务的对话系统102向用户104询问‘离港城市是哪个’并且用户104回答是‘Portland(波特兰)’。任务动作‘SpecifyDeptCity’要求离港城市的名称以及离港地的州名称作为参数值。由用户104所提供的输入只指定离港城市的名称由此部分地指定任务动作‘SpecifyDeptCity’的参数值。下面示出了为任务模型所部分指定的参数，所述任务模型对应于利用由用户104所提供的输入来更新的“LookupFlight’任务。

<City>

<name>Portland</name>

</City>

</deptCity>

</Flight>

为了完成任务动作‘SpecifyDeptCity’的参数值，对话管理器112判定产生参数完成查询。参数完成查询可能会获取在数据库106中被命名为‘Portland’的城市状态。

如果用户104提供完全指定的参数，那么可以产生用于完成任务的查询，例如对于对应于‘LookupFlight’任务的任务模型来说，所述‘LookupFlight’任务的参数值完全由用户104指定。下面示出了由用户104为‘LookupFlight’任务充分指定的示例性输入。

<City>

<name>Portland</name>

<state>Oregon</state>

</City>

</deptCity>

<Date>

<month>October</month>

</Date>

</deptDate>

<City>

<name>Portland</name>

<state>Maine</state>

</City>

</arrCity>

<Date>

<month>October</month>

</Date>

</arrDate>

</Flight>

为了完成‘LookupFlight’任务，对话管理器112判定产生模板搜索查询。模板搜索查询可能会从数据库106获取所有航班，所述航班中‘Portland’为离港城市、‘Oregon(俄勒冈)’为离港州、‘Portland’为到港城市、‘Maine(缅因)’为到港州、离港时间为‘3PM’、离港日为‘13’、离港月份为‘十月’、离港年份为‘2004’、到港时间为‘9PM’、到港日为‘13’、到港月份为‘十月’、到港年份为‘2004’。

查询产生器116产生由对话管理器112来判定的查询。下面示出了所产生的用于完成以上例子的任务动作‘SpecifyDeptCity’的部分指定参数值的示例性参数完成查询。

for$city in document(″flights.xml″)/deptCity

where$city/name＝″Portland″

return$city

下面示出了所产生的用于完成以上例子的“LookupFlight’任务的示例性模板搜索查询。

for$flight in document(″flights.xml″)

where$deptCity/name＝″Portland″

AND$flight/deptCity/state＝″Oregon″

AND$flight/deptDate/time＝″3PM″

AND$flight/deptDate/day＝″13″

AND$flight/deptDate/month＝″October″

AND$flight/deptDate/year＝″2004″

AND$flight/arrCity/name＝″Portland″

AND$flight/arrCity/state＝″Maine″

AND$flight/arrDate/time＝″9PM″

AND$flight/arrDate/day＝″13″

AND$flight/arrDate/month＝″October″

AND$flight/arrDate/year＝″2004″

return$flight

如果由查询产生器116所产生的查询适合于查询数据库106，那么使用所述查询来查询所述数据库106。下面示出了通过利用以上例子的上述参数完成查询来查询XML数据库所获得的结果。

<City>

<name>Portland</name>

<state>Oregon</state>

</City>

<City>

<name>Portland</name>

<state>Maine</state>

</City>

以上参数完成查询已经为离港州的名称产生两个值。因为在数据库中存在两个州具有城市名称为‘Portland’，所以获得用于离港城市名称的两个值。可以把对离港州名称的附加约束引入‘LookupFlightRecipe’配方使得只得到一个结果。下面图示了用于在对以上例子中的离港州名称进行约束的情况下完成为任务动作‘SpecifyDeptCity’部分指定参数值的示例性参数完成查询。

for$city in document(″flights.xml″)/deptCity

where$city/name＝″Portland″

AND(not(and($city/name＝″Portland″)($city/state＝″Maine″))

return$city

下面示出了通过利用上述参数完成查询来查询XML数据库所获得的结果。

<City>

<name>Portland</name>

<state>Oregon</state>

</City>

无法利用上述参数完成查询和模板搜索查询来查询关系数据库，这是因为它们是用Xquery编写的。然后由映射器120把上述参数完成查询和模板搜索查询转换为适当的查询，例如由映射器120把对‘LookupFlight’任务的以上参数完成查询转换为SQL查询。下面示出了在转换到SQL查询之后的示例性XQuery模板搜索查询。

SELECT DEPCITY.STATE

FROMFLIGHT，CITY，STATE

WHERE DEP.CITY.NAME＝″Portland″

AND(NOT(AND(DEP.CITY.NAME＝″PORTLAND″)

(DEP.CITY.STATE＝″MAINE″))

于是使用SQL查询来查询关系数据库。经由输入/输出模块108向用户104提供通过查询数据库106所获得的结果，例如‘Oregon’会作为查询数据库106的结果获得并且被提供给用户104。

参照图4，框图依照本发明一些实施例示出了用于产生查询的电子设备402。电子设备402包括解释装置404、生成装置406和转换装置408。解释装置404接受并解释由用户104所提供的输入。解释装置404执行检查以判定是否可以根据输入来产生第一查询。此外，解释装置404判定第一查询的类型。解释装置404向生成装置406提供解释。生成装置406根据所述解释来产生第一查询。转换装置408执行检查以判定该第一查询是否适合于查询数据库106。如果第一查询适合于查询数据库106，那么使用所述第一查询来查询数据库106。如果第一查询不适于查询数据库106，那么在本发明的一个实施例中，转换装置408把第一查询转换为第二查询，所述第二查询适合于查询所述数据库106。然后使用第二查询来查询数据库106。向电子设备402提供通过查询数据库106所获得的结果。

应当注意，所有示出的代码只用于说明性目的。在不偏离本发明的精神和范围的情况下可以用其它格式来表示所述代码。

应当理解，这里所描述的用于在基于任务的对话系统中查询数据库的方法可以包括一个或多个常规的处理器和特别存储的程序指令，所述程序指令用于控制所述一个或多个处理器来实现这里所描述的一些、大部分或所有功能；因而，用于确定查询是否适合于查询数据库的功能可以被解释为所述方法的步骤。作为选择，相同的功能可以由没有存储程序指令的状态机来实现，其中每个功能或确定功能部分的一些组合被实现为定制逻辑。可以使用两种方法的组合。从而，这里已经描述了用于这些功能的方法和装置。

可以在嵌入式设备和企业应用中使用如这里所描述的用于查询数据库的方法。例如，其中用户可以利用可输入语音的耳麦、小键盘或两者的组合。还可以在用于个人通信系统(personal communication

systems，PCS)的嵌入式设备中使用该方法。可以在从极其复杂的计算机到机器人再到简单的试验设备件的工业设备中使用该方法，只是命名一些电子设备类型和种类。此外，应用的范围延伸到其中利用多模接口来访问信息并进行浏览的所有领域。

在上述说明书中，已经参考具体实施例描述了本发明及其益处和优点。然而，一个本领域普通技术人员应当理解在不脱离如下面权利要求所阐明的本发明范围的情况下，可以进行各种修改和变化。据此，说明书和附图应当被认为是说明性的而并非是限制性的，并且所有这种修改都应包括在本发明的范围内。然而，益处、优点、问题的解决方案和可能导致任何益处、优点或解决方案出现或使其变得更加显著的任何元素(一个或多个)不应当被解释为任何或所有权利要求的关键性、必要或必需的特征或元素。

如这里所用，术语“包括”、“包含”或其任何其它变形旨在覆盖非排他性的包括，使得包括一列元素的过程、方法、物品或设备并且不只包括那些元素，而且还可以包括没有显式列出的其它元素或为这种过程、方法、物品或设备所固有的元素。

如这里所用的“集”意指非空集(即，对于这里所定义的集来说，包括至少一个成员)。如这里所用，术语“另外的”被定义为至少是第二个或更多。如这里所用，词语“具有”被定义为包括。如这里所用，参考电光技术的术语“耦合”被定义为连接，不过不一定是直接连接，也不必是机械连接。如这里所用，术语“程序”被定义为被设计用来在计算机系统上执行的指令序列。“程序”或“计算机程序”可以包括子例程、函数、过程、对象方法、对象实现、可执行应用程序、小应用程序、小服务程序、源代码、目标代码、共享库/动态加载库和/或被设计成用来在计算机系统上执行的其它指令序列。应当进一步理解，相关术语的使用(如果存在的话)，诸如第一和第二、顶和底等，仅仅用于把一个实体或动作与另一实体或动作相区分，而不必要求或意指在这种实体或动作之间的任何实际这种关系或次序。

Claims

1.一种用于查询数据库的方法，所述数据库存储数据，所述数据用来在基于任务的对话系统中完成任务，所述方法包括：

根据任务模型和对话上下文来解释用户输入，以形成对所述用户输入的解释，所述对话上下文包括由所述用户和基于任务的对话系统中的至少一个所提供的信息；

根据所述用户输入的解释来产生第一查询；并且

当所述第一查询不直接适于查询该数据库时，则把所述第一查询转换为第二查询，所述第二查询直接适于查询所述数据库。

2.如权利要求1所述的用于查询数据库的方法，其中所述方法是独立于领域的。

3.如权利要求1所述的用于查询数据库的方法，其中所述第一查询是用Xquery编写的。

4.如权利要求1所述的用于查询数据库的方法，其中所述第二查询是用结构化查询语言(SQL)编写的。

5.如权利要求1所述的用于查询数据库的方法，其中解释所述用户输入进一步包括：

检查是否可以根据所述用户输入来产生所述第一查询；并且

根据所述用户输入来判定待产生的第一查询的类型。

6.一种用于查询数据库的方法，所述数据库存储用来在基于任务的对话系统中完成任务的数据，所述方法包括：

根据任务模型和对话上下文来解释用户输入，以形成对所述用户输入的解释，所述对话上下文包括由所述用户和基于任务的对话系统中的至少一个所提供的信息；并且

根据所述用户输入的解释来产生用Xquery编写的查询。

7.一种基于任务的对话系统，所述基于任务的对话系统用于查询数据库，所述基于任务的对话系统包括：

任务模型，所述任务模型用于在基于任务的对话系统中建模任务；

对话管理器，所述对话管理器管理对话；

查询产生器，所述查询产生器产生用于所述对话的第一查询；和

映射器，所述映射器把所述第一查询转换为第二查询。

8.如权利要求7所述的基于任务的对话系统，进一步包括用于确定所述第一查询是否适于查询所述数据库的装置。

9.如权利要求7所述的基于任务的对话系统，其中所述对话管理器进一步包括：

解释器，所述解释器根据任务模型和对话上下文来解释用户输入以形成对所述用户输入的解释，所述对话上下文包括由所述用户和基于任务的对话系统中的至少一个所提供的信息；和

用于判定何时产生所述第一查询以及产生哪种类型的第一查询的装置。

10.一种用于查询数据库的电子设备，所述数据库存储用来在基于任务的对话系统中完成任务的数据，所述电子设备包括：

用于根据任务模型和对话上下文来解释用户输入以形成对所述用户输入的解释的装置，所述对话上下文包括由所述用户和基于任务的对话系统中的至少一个所提供的信息；

用于根据所述用户输入的解释来产生第一查询的装置；和

用于把所述第一查询转换为第二查询的装置。