第六届国际控制自然语言研讨会论文集

需积分: 9 149 浏览量更新于2024-07-17 收藏 5.65MB PDF 举报

"Controlled Natural Language (Frontiers in Artificial Intelligence and Applications) 由B. Davis、C.M. Keet和A. Wyner合著，书号1614999031/9781614999034，2018年8月出版，116页。本书汇集了2018年在爱尔兰梅努斯举行的第六届Controlled Natural Language (CNL 2018) 工作坊的11篇论文，涉及CNL的各个方面，从面向人类的语言到机器可处理的语言，从理论成果到接口、推理引擎和CNL的实际应用。 Controlled Natural Languages（CNLs）是一种基于自然语言但对其词汇、语法和/或语义施加限制的语言。它们大致分为三类：一类旨在改善非母语者的交流；另一类是为了便于计算机分析文本，例如提高计算机辅助翻译；第三类CNLs设计目的是实现从看似自然的文本中可靠地进行自动推理和形式知识表示。书中涵盖的论文主题广泛，包括使用搜索和探索编辑控制语言、为金融服务合规性检查设计的CNL、响应式和灵活的CNL创作、基于拉链变换的CNL创作、自动化的isiZulu语言学习练习问题生成和评分、用于危险分析和风险评估的CNL、使用AIDA语言正式组织科学论断、将控制融入语言学习、从面向对象的自然语言自动生成程序、理解尝试性控制英语的文本、将简化文本重写为CNL，以及在GF中建模南非荷兰语陈述句的否定。这本书对所有从事控制自然语言工作的人来说都具有参考价值，无论他们的方法如何。" 本书的主要知识点包括： 1. 控制自然语言的概念和分类：CNLs是自然语言的变体，通过限制词汇、语法和语义来简化或强化特定目的的沟通和处理。 2. CNL的应用场景：包括提高跨文化交流效率、计算机文本分析、自动化推理和知识表示。 3. CNL的理论与实践：书中论文涵盖了从理论研究到实际应用的全貌，如编辑工具、问答系统、编程自动生成等。 4. CNL在不同领域的应用：如金融服务业的合规性检查、危险分析、科学论断的组织、语言学习等。 5. 自动化技术在CNL中的作用：如自动问题生成、文本理解和程序合成，这些技术展示了CNL如何与人工智能相结合。 6. CNL的语义建模：包括如何在特定语言环境中建模否定和其他复杂语义结构。 7. 推理引擎和接口设计：CNLs的实现涉及到与计算机交互的接口设计，以及推理引擎的构建，以支持自动推理。 8. 语言学习与教学：CNLs可以作为教学工具，帮助学生更好地理解和掌握语言。 9. 拓展阅读：书中的索引提供了作者和主题的查找功能，方便读者进一步研究相关领域。 "Controlled Natural Language"这本书不仅深入探讨了CNL的基础理论，还展示了其在多个实际应用领域的创新和进展，对于理解和利用CNL来改进人机交互和知识表示具有重要参考价值。

Figure 3. Screenshot of Parlira.

making a choice implies having to make further choices (for example, selecting

‘someone’s wife’ and then having to select ‘whose’ wife).

2. Elements which control the grammatical ‘shape’ of the sentence but do not

go into any particular placeholder, for example selecting whether the sentence

should be a statement, a question, or a negative statement.

3. Elements which ‘wrap’ the sentence inside a larger sentence, for example turning

it into reported speech (going from ‘someone wants some food’ to ‘someone

knows that someone wants some food’). Again, some of the choices made in

such an element are complex because making one choice implies having to make

further choices (for example, having to choose ‘who’ knows).

The logic of choices, how they depend on one another, and how they come together

into an abstract syntax tree for the entire sentence, has been hard-coded into the user in-

terface. This means that the user interface is speciﬁc to the Phrasebook application gram-

mar and cannot easily be re-used for other applications. The obvious next step would

be to devise a formalism or scheme where we could generate the user interface from

grammar itself or from some intermediate representation.

Based on the same ideas as Phrasomatic, the Parlira project [4] created an Android

app. Both Phrasomatic and Parlira use the Phrasebook grammar [11] and both suffer

from being tied to it. The initial goal of the Parlira project was to relax that limitation,

but that was not fully realized. In this paper we present a fully customizable solution

which ﬁnally overcame that limitation and has been tested with two grammars, [11] and

[10] (the later is an app developed by Digital Grammars AB for communication between

patient and ambulance personnel in several of the immigrant languages of Sweden).

Both Phrasomatic and Parlira did, however, play a role as experimental prototypes

for multilingual point-and-click authoring with GF. The advantage of such a tool over

machine translation is obvious: the application does not have to ‘guess’ (ie. parse) what

the user may have meant because the input is unambiguous, while the output is guaran-

teed to be correct (both in content and linguistically), making it reliable for production-

oriented situations where the user does not speak the target language. The disadvantage

is obvious too: the coverage is tiny and limited to one domain.

The fundamental challenge of tools like Phrasomatic and Parlira, however, is er-

gonomical: the user experience is slow-moving, involves ‘too much clicking’ (a com-

ment from an actual user) and can come across as unintuitive because most people are

not used to expressing their intended meaning in anything other than natural language.

K. Angelov and M.B. Mˇechura / Editing with Search and Exploration for Controlled Languages4

This limitation can perhaps be overcome by combining point-and-click authoring with

natural-language search: the user’s natural-language input would be used for an initial

search of candidate sentences, while conceptual authoring would come in later for re-

ﬁnement and disambiguation.

3. Editing

In this section we will tackle the key issue explained in the previous section, i.e. how

to make the editor reconﬁgurable. We assume that the underlying representation of a

sentence is a tree. This ﬁts perfectly with the Grammatical Framework (GF [9]), but it

can also ﬁt other frameworks. For example the sentence:

I am an ambulance nurse

in [10] has the representation:

statementPhrase

(professionStatement (mainPerson iMainPerson)

ambulanceNurseProfession)

The key components of the phrase are obviously in the representation, i.e. the pro-

fession ambulanceNurseProfession and the subject iMainPerson. What the presen-

tation does not say is how exactly these phrases are rendered. In GF this is deﬁned by the

grammar and can be different for each language while sharing the same representation.

For example, from the same tree the Spanish grammar produces:

Soy enfermera de ambulancia

Apart from the essential content of the sentence, the representation also contains

pieces which are irrelevant for the semantics but are helpful, for instance, in mak-

ing the grammar better structured. For example the functions statementPhrase and

mainPerson are only coercions from one category to another. In a typical syntax editor

the user might have to insert those coercions manually while working directly with the

tree. These, however, are just artefacts of the grammar engineering and the user should

not be bothered to make decisions whose purpose might not even be obvious for him/her.

Formally, we expect that there is a grammar which converts abstract trees into natural

language. The syntax for trees is deﬁned as:

Expression e ::= fe

... e

, k ≤|f |

Function f ,g,h

In other words, there is a set of functions where every function f takes | f | number of

arguments i.e. other trees. In order for a tree to be rendered in a natural language, every

function in the tree must be fully applied. However, in the intermediate steps when we

build a tree, it is helpful if we allow partial function applications. Because of that in the

deﬁnition above we wrote k ≤|f |.

In order to describe how the menus in the editor work we also need the notion of a

choice conﬁgurations. The formal deﬁnition is:

K. Angelov and M.B. Mˇechura / Editing with Search and Exploration for Controlled Languages 5

Choice c ::= option(ι,k) c

... c

| function(ι,e) c

... c

|e|

| call(ι) c

... c

| arg(k)

The ﬁrst conﬁguration option(ι, k) speciﬁes that the user can choose one of the options

from c

to c

and the default option is k. The second conﬁguration function(ι,e) says

that a tree is built by applying the tree e to the result of the choices from c

to c

|e|

.In

both cases there is also the parameter ι which must be an unique id which is different for

every conﬁguration instance. An example is:

function(ι

,mainPerson)(option(ι

,0) function(ι

,youMainPerson)

function(ι

,youFemMainPerson))

It says that the user can choose between two options which results in using either func-

tion youMainPerson or function youFemMainPerson. On top of that is applied function

mainPerson. The ﬁnal result is that one of these two trees will be produced:

mainPerson youMainPerson

mainPerson youFemMainPerson

By using this kind of choice conﬁgurations it is possible to describe the entire set

of trees in the grammar. The place and the granularity of the user’s choices is explicitly

speciﬁed. In the example every option consists of only a single function but in general

it is possible to insert a complex tree as a single unit. From the user’s point of view

every option will be rendered as an item in a menu. The text of the menu is generated

by rendering the attached tree by using the grammar. Thanks to that the abstract repre-

sentation is never visible. Sometimes the tree that is used for rendering the controlled

language is not appropriate for use in the menus. For example both youMainPerson and

youFemMainPerson will simply generate you in English. Instead we would like to see

something like you (man) and you (woman). For that purpose, the designer of the user

interface can choose to attach “description trees” which are also rendered to natural lan-

guage but in a more descriptive way than the trees that produce the controlled language.

Note also that coercion functions like mainPerson are automatically inserted without

user’s involvement.

The two other constructions call(ι) and arg(k) turn our conﬁgurations into a small

functional language. This is handy since one and the same sequence of choices might be

needed in different situations. call(ι) encodes a call into a choice with unique id ι which

is applied to arguments c

to c

. arg(k) retrieves and uses an argument with index k.

The choice conﬁgurations represent the semantics of the XML ﬁle that we use in the

actual implementation. The above example will look like:

</option>

</function>

The pseudo code for the conﬁguration interpreter is in Figure 4. It is a function

Ec|α;β ; γ with four arguments:

K. Angelov and M.B. Mˇechura / Editing with Search and Exploration for Controlled Languages6

Eoption(ι, k) c

... c

|ι ,lα;β;γ  = Ec

|α; β ι,l; γ

Eoption(ι, k) c

... c

|ι



,lα;β;γ  = Ec

|ε; β ι,r; γ, ι = ι



Eoption(ι, k) c

... c

| ε; β ; γ  = Ec

|ε; β ι,r; γ

Efunction(ι, e) c

... c

| α; β ; γ  =(ee

... e

, β

)

where (e

, β

)=Ec

|α; β ;γ

, β

)=Ec

|α; β

;γ

, β

)=Ec

|α; β

s−1

;γ

Ecall(ι) c

... c

| α; β ; γ  = Ec |α;β ;c

... c

γ, id(c)=ι

Earg(k) | α; β ; c

... c

γ  = Ec

|α; β ; c

... c

γ

Figure 4. An interpreter for choice conﬁgurations

• c - a choice conﬁguration

• α - a list of choice alternatives taken at the latest user interaction

• β - a list of choice alternatives to be made for the new user interaction

• γ - a stack for keeping track of the call arguments.

The arguments α and β are those that represent how the user interface looks and how

it should be updated. At every single point the interface shows a list of options. What is

currently selected in them is encoded in α. At this point the user can change the selection

of any of the options which is recorded again in α. After that the interpreter is executed.

A change in one place in α might require making other choices and showing new options.

This results in computing a new sequence of options which is computed in β. Both

α and β are sequences of pairs like ι,l, where ι is the unique id of an option(ι,k)

conﬁguration and l is the index of the selection currently taken. In the beginning l = k

but after that the user might change it, so we store the actual index in α.

The ﬁrst rule of the interpreter says that if there is an option(ι,k) conﬁguration and if

α starts with ι,l then we should proceed by processing c

. The pair ι, l is also copied

to β to specify that this option should continue to be available in the user interface with

the same selection.

The second rule is again about option(ι,k) but it handles the case where on top of

α there is a different id ι



which does not match the current conﬁguration. This happens

when the user changes somewhere the current selection and this affects the set of con-

secutive options. In this case we just disregard the rest of α. For the current option we

select choice c

The third rule of the interpreter is similar and it handles the case where α is an empty

sequence (ε). In that case we again make the default choice. When the user interface is

ﬁrst started it always starts with empty α. This lets the interpreter to choose the default

version of the sentence to be produced. The user then makes changes through the menus.

The fourth rule builds the trees. It applies the tree e to the results computed from

to c

. Usually e is just a function name, but more generally it could be a tree like

...e

. The constraint is that p + s = | f |. This guarantees that the tree can be

linearized according to the semantics in GF [9].

The last two rules implement function calls. The rule for call(ι) ﬁnds the conﬁg-

uration with key ι and proceeds with that while pushing the arguments in the stack γ.

Similarly the rule for arg(k) retrieves the appropriate argument from the stack.

K. Angelov and M.B. Mˇechura / Editing with Search and Exploration for Controlled Languages 7

4. Search

As we discussed, roaming through the set of menus might still not be straightforward.

For that purpose we also implemented search. The idea is to see the grammar as a ﬁ-

nite description of a potentially inﬁnite set of sentences. In information retrieval a set of

sentences (documents) is called a corpus and the task of the retrieval is to ﬁnd the sen-

tence which matches best the search query using measures like cosine similarity. With

cosine similarity the corpus sentence and the query are represented as vectors in a high-

dimensional space and the cosine of the angle between them measures the similarity [6].

Despite that a grammar represents an inﬁnite set of sentences the same information

retrieval techniques can be applied. We just use the grammar as a ﬁnite proxy for the

inﬁnite set. This method is already available as a service in the GF Runtime [1]. For

example with the grammar in [10], if the user searches for pain (Figure 5) the runtime

ﬁnds the trees:

statementPhrase (symptomStatement ? painSymptom)

statementTimePhrase (symptomStatement ? painSymptom) ?

questionPhrase (whetherQuestion (symptomStatement ? painSymptom))

This are partial trees where the question mark is a placeholder for the missing bits.

If the trees are reﬁned they could represent phrases like:

You are in pain.

You are in pain today.

Are you in pain?

As we can see all the phrases contain the search query pain. These are also the phrases

in the grammar which contain the least number of additional words that are not already

in the query. The partial trees have holes for you and today because there is no evidence

in the query for what kind of subject/adverb should be used. However, if the query is she

pain, then runtime will automatically ﬁll in the subject with she.

What the editor does is to take the trees computed by the runtime, and to match them

with the choice conﬁgurations. The parts of the tree that are already known are used to

ﬁnd the correct path through the choice options. When a placeholder is encountered, we

instead use the existing strategy to take the default option as described in the previous

section. This gives us for instance you as the default subject. The user can then use the

menus as usual to make changes.

5. User Feedback

The Ambulance app was tested twice by members of the ambulance service in Gothen-

burg. The ﬁrst test was done early on by a representative of the management staff. At

that point the app had the menus for editing but still did not have the search facility and

instead a traditional predictive editing mode was available. There was also a parser which

can be used in combination with keyboard or speech-to-text input.

The feedback was that as it is the app is difﬁcult to use without some prior training.

The reason is that ﬁnding the right phrase through the menus takes time unless if the

K. Angelov and M.B. Mˇechura / Editing with Search and Exploration for Controlled Languages8

剩余117页未读，继续阅读

THESUMMERE

粉丝: 23
资源: 328

第六届国际控制自然语言研讨会论文集

wx494社区门诊管理系统小程序-php+vue+uniapp.zip（可运行源码+sql文件+文档）

invite.html

MongoDB在Linux上的深度探索：安装、操作、可视化及实验指南.pdf

wx364校园约拍小程序-ssm+vue+uniapp.zip（可运行源码+sql文件+文档）

赫芬达尔指数表.xlsx

钉钉企业免登陆PHP版本源码

2019华为软件精英挑战赛决赛参赛源码+学习说明.zip

登录注册页面html

某四层倒L型框架教学楼建筑图结构图计算书4000平米左右（计算书+建筑图纸+结构图纸）

jsp高校学生考勤管理系统设计与实现（源代码+论文）.rar

最新资源