추상 위키백과/위키함수를 위한 틀 언어

아리엘 거트만과 마리아 키트의 제안

참고: 주로 언어 구현에 관심이 있는 경우 아래 구현 섹션을 참조하세요.

이 문서의 목표는 추상 위키백과 프로젝트에서 사용할 템플릿 언어 구문을 제안하는 것입니다. 이것은 자연어 생성(NLG) 시스템 아키텍처 문서와 특히 "템플릿 렌더러" 구성 요소의 정교화입니다. "컴포지션" 구문으로 변환하여 위키함수 플랫폼에서 구현하거나 위키백과의 Scribunto 환경과 같은 다른 프로그래밍 환경에서 구현할 수 있으며 다른 NLG 시스템 또는 실현자로 매핑하거나 변환할 수 있습니다.

첫 번째 버전의 주요 변경 사항은 다음과 같습니다. 1) 부록으로 위키함수에 맞춤화된 실현 알고리즘의 일반화; 2) 일부 디자인 선택에서 보다 명확해지고 커뮤니티 구성원이 제기한 의견, 제안 및 예를 처리합니다. 3) 다른 NLG 실현자 및 구현과 관련시키는 것과 같은 추가 예시적 확장.

소개

반 디엠터, 크라머 & 테우네(2003)은 틀 기반 시스템을 다음과 같이 설명합니다:

템플릿 기반 시스템은 비언어적 입력을 언어적 표면 구조(cf., Reiter and Dale (1997), p.83-84)에 직접(즉, 중간 표현 없이) 매핑하는 자연어 생성 시스템입니다. 결정적으로, 이 언어 구조에는 간격이 포함될 수 있습니다. 잘 구성된 출력은 간격이 채워지거나 더 정확하게는 모든 간격이 간격을 포함하지 않는 언어 구조로 대체되었을 때 발생합니다.

즉, 템플릿은 "슬롯" 또는 "갭"이 산재된 일련의 (정적) 텍스트로 이해될 수 있으며 구조화된 콘텐츠(예를 들어 데이터베이스의 데이터, 온톨로지의 지식) 또는 일부 계산의 결과(아마도 실현된 다른 템플릿 또는 함수의 출력)가 포함된 일부 다른 정보 소스 또는 구조화된 콘텐츠(우리의 사용 사례에서는 아직 정의되지 않은 새로운 추상 콘텐츠를 포함하여 대부분 위키데이터에서 비롯된 정보)로 채워질 수 있습니다. WF용 NLG 모듈에 대해 제안된 설계에서 템플릿의 슬롯을 연결하는 UD/[:en:Universal Dependencies SUD] 주석이라는 추가 요소가 추가되어(Gutman et al., 2019; 2022에 따름) 결과 출력이 단순한 텍스트 문자열이 아니라 구문 트리(또는 나무 숲) 슬롯/텍스트 조각에 대해 정의됩니다. 슬롯은 언어 구문의 다양한 수준, 즉 문장 조각, 단어, 하위 단어 형태소 등의 구성에 해당할 수 있습니다. 따라서 대상 자연어의 구문에 따라 필요한 세분성에 따라 결과 문장의 다른 언어적 요소 간에 종속성 링크가 정의될 ​​수 있습니다.

템플릿은 텍스트가 터미널 기호로 사용되고 슬롯이 비터미널로 사용되는 문맥 자유 문법 규칙으로 재구성될 수 있습니다. 이러한 이유로 템플릿은 언어의 대부분(전부는 아니지만) 현상을 다루는 것으로 알려진 CFG 기반 시스템만큼 표현력이 뛰어납니다. 둘 사이의 차이점은 템플릿 시스템 설계자가 NLG의 작업을 위해 중간 언어 표현을 사용하는 초기의 부족함에 있지만 실제로 템플릿 시스템이 성장하고 도메인 독립이 됨에 따라 템플릿을 획득할 수 있습니다. 대상 언어의 형식 문법과 유사합니다.

다음에서 우리는 먼저 자유 텍스트 설명에서와 같이 위키함수에 대해 제안된 템플릿 언어 구문을 제시하고 이후에 형식 표기법을 CFG로 사용하고 도식적으로 렌더링된 논리적 모델로 사용합니다(cf. Mahlaza & Keet 2021).

템플릿 언어 구문

템플릿은 다음 조합으로 구성됩니다:

1. 구두점 및 특수 동작이 있는 어휘(단어)를 포함한 자유 텍스트
2. 슬롯은 인수의 보간 또는 어휘 함수 및 하위 템플릿의 호출이며 종속 관계로 주석이 달릴 수 있습니다.

요지를 위해 ORM 표기법에서 템플릿 언어의 주요 기능을 포함하는 비표준 다이어그램은 다음과 같습니다:

ORM 표기법으로 된 템플릿 언어의 주요 기능이 있는 예시 다이어그램: 실선이 있는 직사각형 = 개체 유형; 점선이 있는 직사각형 = 값 유형(대략: 속성); 구분선과 그 옆에 레이블이 있는 사각형 = 관계; 화살표 = 포섭; 보라색 얼룩 = 필수 제약 조건; 직사각형 위의 보라색 선 = 고유성 제약 조건; 얼룩이 있는 보라색 원 = 둘 중 하나는 필수; 선이 있는 보라색 원 = 외부 고유성

별개의 텍스트 조각(공백으로 구분)과 슬롯을 템플릿 요소로 집합적으로 이름을 지정합니다. 각 템플릿에는 최소한 하나의 요소가 있습니다. 템플릿 언어를 사용하면 모든 템플릿이 참여 슬롯에 대한 트리로 해석될 수 있는 방식으로 슬롯 간의 종속성 호를 지정할 수 있습니다. 서브템플릿이 반드시 이 트리에 연결되는 것은 아니며, 서브템플릿은 자체 루트를 나타낼 수 있으므로, 템플릿 언어는 다양한 하위 템플릿의 슬롯에 대한 포리스트 지정을 허용하며, 원하는 경우 상위 템플릿의 루트에 연결할 수 있습니다. 이 구조의 의도는 실현을 안내하기 위해 템플릿의 생산적 요소에 대한 종속성 문법 분석을 제공하는 것입니다. 이에 사용할 수 있는 인기 있는 종속성 문법 프레임워크는 예를 들어 UD 또는 SUD이지만 이들은 일반적으로 단어 수준에서만 분석을 제공하므로 슬롯이 형태소인 경우 다른 문법 프레임워크를 사용하거나 UD/SUD 종속 문법 프레임워크를 확장해야 합니다(예: 최근에 UD 또는 밀접하게 관련된 catena에 대해 제안됨).

슬롯은 중괄호로 구분되며 다음 구문에 따라 두 부분으로 구성됩니다(대괄호는 선택 사항을 나타냄):

{[dependencyLabel:]invocation}

1. dependencyLabel: 선택적 dependencyLabel 부분은 다음과 같은 구문을 가지며 콜론이 뒤에 오는 세 개의 요소로 구성됩니다: role[_index][<sourceLabel]:
   • role은 슬롯의 (들어오는) 종속 관계를 나타내므로 dependencyLabel의 필수 구성 요소입니다.
     • 종속성 트리의 root (head라고도 함) 역할을 하는 슬롯에는 root 역할이 있어야 합니다. 템플릿에서 종속성 레이블을 사용하는 경우 root로 표시된 슬롯이 정확히 하나만 있어야 합니다.
     • 각 역할은 주어진 역할의 적용을 반영하기 위해 기본형 트리를 변환하는 위키함수 함수에 해당해야 합니다. 예를 들어 subj 역할은 기본형 트리에서 주어-동사 일치를 강제합니다. 이러한 위키 기능 기능은 언어에 따라 다르며 또한 해당 언어로 레이블이 있을 수 있습니다(예: 네덜란드어로 subj에 대한 "onderwerp").
   • _index는 밑줄 다음에 오는 선택적 양의 정수로, 동일한 역할을 가진 여러 슬롯을 구분할 수 있습니다(예를 들어 2개의 형용사 수식어: amod_1, amod_2). role 및 index 조합은 각 템플릿에서 고유해야 합니다.
     • role과 index의 조합은 각 템플릿에서 고유해야 합니다.
     • role 자체가 템플릿 내에서 고유한 경우 인덱스 부분이 필요하지 않습니다.
   • <sourceLabel은 여는 꺾쇠 괄호 뒤에 오는 선택적 문자열로, 소스 슬롯의 레이블로 지정된 수신 관계의 소스를 지정할 수 있습니다(이는 역할 뒤에 선택적 색인이 옴). 소스가 제공되지 않으면 root 슬롯이 암시적으로 소스로 간주됩니다.
   • 존재하는 경우 종속성 레이블 부분은 호출과 구분하기 위해 콜론이 뒤에 옵니다.
2. invocation은 다음 세 가지 유형 중 하나일 수 있습니다: functionInvocation() 또는 interpolation 또는 "string"
   • functionInvocation()은 이름에서 알 수 있듯이 함수 호출입니다. 함수는 괄호 사이에 쉼표로 구분된 인수 목록을 가져올 수 있으며, 위에서 정의한 대로 자체적으로 호출일 수 있습니다. 호출된 함수는 하위 템플릿일 수 있습니다.
   • interpolation은 템플릿의 형식 인수로 슬롯을 채우는 것과 같습니다. 인수는 일반적으로 슬롯의 필수 반환 유형이 아니므로 이것이 작동하려면 인수에 암시적 변환 기능을 적용해야 합니다. 특히 생성자인 형식 인수는 보간될 때 해당 템플릿이 해당 필드와 함께 호출되도록 하여 합성성을 허용합니다.
   • "string"(따옴표로 묶인 모든 텍스트)은 자유 텍스트와 동일한 문자열을 사용하는 것과 동일하지만 다른 슬롯과 마찬가지로 종속성 역할로 레이블을 지정할 수 있다는 차이점이 있습니다.

CFG로 공식화

위의 구문은 CFG 규칙 집합으로 공식화될 수 있습니다. 터미널이 아닌 기호는 "기울임꼴"로 표시되는 반면 터미널 기호(터미널 기호 집합과 함께)는 monospace으로 표시됩니다.

규칙	의견
Template → Element
Element → {Slot} | Text | Element Element
Text → lexeme | punctuation | string	lexeme은 동일한 의미(예: sit, sits 및 sitting)를 갖지만 결국에는 기본형으로 이어지는 모든 형식의 집합입니다. 터미널로 끝나는 텍스트 – 속기 표기법입니다. punctuation도 집합이며 결국 터미널 기호로 이어지며 여기에서도 이에 대한 속기 표기법이 사용됩니다. string은 공백과 { }를 제외한 모든 문자 조합이 될 수 있습니다.
Slot → DependencyLabel : Invocation | Invocation
DependencyLabel → Label < SourceLabel | Label | root
Label → Role _ Index | Role
Role → …	역할 이름의 유한 집합(루트 제외), 예를 들어 UD/SUD 또는 그 확장에서 가져옴
Index → 1 | 2 | …	양의 정수의 유한 집합
SourceLabel → Label	소스 레이블은 템플릿의 다른 곳에서 레이블로 사용된 레이블 중 하나일 수 있습니다. 여기서는 명확성을 위해 주로 다른 비터미널 이름을 사용합니다.
Invocation → FunctionInvocation | Interpolation | String
FunctionInvocation → F(ArgumentList) | F()	변수가 있는 함수(비어 있을 수 있음) 인수 개수
ArgumentList → invocation | invocation , ArgumentList	모든 호출은 인수로 작동할 수 있습니다.
F → functionName | templateName	시스템에서 사용할 수 있는 기능(또는 기능 역할을 하는 템플릿)의 이름입니다.
Interpolation → interpolation	이름 집합(생성자의 필드)은 터미널일 뿐이므로 여기서는 속기 표기법입니다.
String → "string"	분명히 터미널 집합(“ 및 ” 내에 배치됨), 속기 표기법.

각 템플릿과 함께 기록해야 하지만 렌더링 대상이 되는 부분에는 영향을 미치지 않는 세 가지 템플릿 수준 기능이 있습니다. 그들은:

• 템플릿의 “이름/식별자(필수)”입니다. 템플릿의 지정된 범위(구현에 의해 정의됨)에서 이름은 고유해야 합니다.
• 렌더링해야 하는 “언어”입니다(필수). 언어 코드는 사용되었거나 사용될 예정이거나 미래에 위키데이터에서 사용될 수 있는 것과 일치해야 합니다.
• “전제 조건”(선택 사항). 생성자는 둘 이상의 템플릿과 연결될 수 있습니다. 즉, 관련된 변형 템플릿 목록이 있습니다. 이러한 변형 템플릿 목록에는 적절한 템플릿을 선택하기 위한 하나 이상의 전제 조건이 있습니다. 전제 조건을 충족하는 첫 번째 변형 템플릿이 선택되고 실현됩니다. 전제조건에는 다음과 같은 매개변수가 포함될 수 있습니다:
  • 변형 주입을 위한 템플릿 변형의 무작위 시드 조건 또는 순위;
  • 형식 또는 장황함 수준과 같은 구현에 대한 글로벌, 언어별 또는 문서별;
  • 생성자의 특정 필드가 있는지 여부 또는 해당 값에 대한 조건;
  • 상위 템플릿 내 하위 템플릿의 문법적 역할(종속 레이블에 의해 정의됨).
  • 필요에 따라 더 많이 지정할 수 있습니다.

조건부 함수에 의한 확장

여러 하위 템플릿이 있는 보다 정교한 템플릿에 대한 약식 표기법인 소위 '문법적 설탕'으로 구문을 확장할 수 있습니다. 예를 들어 슬롯의 함수 호출은 다음과 같이 하나 이상의 조건부 함수로 확장할 수 있습니다:

{[dependencyLabel:](invocation)[|conditionalFunction]*}

파이프 기호를 통해 이전 함수와 분리하여 반복할 수 있는 선택적 conditionalFunction 부분은 지정된 인수 외에 다음을 수행하는 조건부 함수 호출을 지정합니다. 파이프 기호 앞의 호출 결과. 즉, 어휘 목록을 가져와서 수정된 어휘 목록을 반환하는 함수입니다. 몇 가지 가능한 사용법은 다음과 같습니다:

• 이것은 슬롯의 조건부 생략(그 문법적 특징을 여전히 유지하면서) 또는 조건부 대명사화(표현 생성 참조)를 허용합니다. 예: "심바 사자 ... ; 그는 …” 참조 반복 “사자 심바 … 심바..."
• 일반적인 문장 재정렬과 같이 슬롯에서 대체 단어 사이의 선택을 용이하게 하기 위해 문장 구조에서 더 많은 유연성을 허용합니다. 예: "x 때문에, 우리는 y를 했습니다" 및 "우리는 x 때문에 y를 했습니다."
• 그리고 가능한 다른 작업.

이 구문을 사용하는 이유는 단순한 함수 구성이 아니라 템플릿의 가독성을 높이기 위한 것입니다. 메인 invocation 부분은 슬롯에서 기대하는 렌더링된 결과의 유형을 명확하게 나타내야 하기 때문입니다. 이 문법적 설탕이 없으면 하나의 함수를 다른 함수에 포함시켜 {ConditionalFunction(invocation, conditional_arguments)}를 생성하거나 (하위)템플릿 선택 위에 조건 레이어를 추가하여 다음을 수행할 수 있습니다. 그러한 전제 조건을 처리합니다.

구문의 예는 아래에 더 포함되어 있습니다.

핵심 함수

템플릿 언어의 핵심 요소는 슬롯 내의 함수 호출입니다. 이러한 함수 호출은 어휘소(위키데이터 어휘소와 유사한 문법적 특징과 관련된 굴절된 형태의 패러다임) 또는 각 하위 트리의 루트 어휘소가 최소한으로 제공되는 어휘소의 부분적으로 지정된 구문 트리를 반환해야 합니다.

그러나 템플릿 언어의 핵심 기능은 단일 어휘소를 반환합니다. 이러한 "핵심 함수"는 추상 위키백과 기여자가 작성하므로 닫힌 목록은 없습니다. 사전에 또는 시간 경과에 따라 핵심 기능으로 간주될 수 있는 기능의 예는 다음과 같습니다.

• Lexeme(L-id, …): L-id(지정된 언어로)와 연관된 위키데이터 어휘소를 가져와 어휘소 유형으로 변환합니다. 추가 인수는 형식 선택을 제한하는 문법적 특징의 Q-id일 수 있습니다.
• Label(entity) 또는 Label(entity, language): 지정된 언어로 Q-id와 관련된 레이블을 가져옵니다. 기본값은 다음과 같습니다. 지정되지 않은 경우 실현 언어입니다.
• Cardinal(integer): 해당 문법 번호(단수/복수/등)가 있는 정수(철자가 나올 수 있음)로 구성된 어휘 단일 항목을 만듭니다.
• Ordinal(integer): 원하는 서수에 해당하는 어휘 단일 항목을 생성합니다(언어에 따라 굴절이 있을 수 있음).
• TemplateText(string): 입력 문자열에 해당하는 어휘를 생성합니다.

또한 특정 의미 도메인에 해당하는 함수를 구현할 수 있습니다. 예를 들면 다음과 같습니다:

• Person(entity): Name과 유사하지만, 사람의 성별에 따라 문법적 성별을 채우고 대명사 어휘 형식도 생성할 수 있습니다.

언어별 함수 디스패치

위에서 언급한 모든 기능은 언어별로 구현될 수 있습니다(대부분 그럴 것입니다). 언어별 구현을 선택하는 방법은 구현에 따라 다릅니다.

댓글 처리

템플릿 또는 템플릿의 요소에 주석을 추가할 수 있습니다. 현재 사양에는 요소에 대한 별도의 주석 필드가 없습니다. 원하는 경우 모든 구현은 코드에 주석이 추가되는 것처럼 주석에 대한 조항을 추가할 수 있습니다. 적절한 예약 문자 앞에 주석을 사양의 아무 곳에나 배치할 수 있습니다. 이 예약된 문자열은 템플릿 사양이 저장되는 구현에 따라 다릅니다. 예를 들어, 위의 CFG 사양에서 사용되는 % comment here, 또는 <!-- comment here -->. 예를 들어 위키함수에서 주석은 함수의 페이지에도 표시되며 템플릿이나 다른 추가 인터페이스 구성 요소에도 채택될 수 있습니다.

실현 알고리즘

위 표기법을 사용하여 지정된 템플릿의 실현은 5개의 개별 단계에서 발생합니다.

1단계

모든 템플릿 요소는 내용을 평가하여 확장됩니다. 텍스트 요소, 슬롯 문자열 및 문자열 보간은 어휘소(일반 또는 언어별 함수 사용)로 변환되고 모든 슬롯 함수는 해당 인수로 평가됩니다. 하위 템플릿을 평가할 때 2단계까지 재귀적으로 평가해야 합니다(자세한 내용은 아래 참조).

각 텍스트 요소 또는 슬롯의 평가는 어휘소 또는 어휘소 목록 데이터 유형을 생성해야 합니다:

• 어휘소는 굴절 형태의 모음으로 구성되며, 각각은 문법적 특징 목록과 관련된 자체 철자를 가지고 있을 뿐만 아니라 공통 문법적 특징 목록(모든 형식에 적용 가능하거나 이를 제한함)을 가지고 있습니다. 모든 문법적 특징은 문법 범주(예: "숫자")와 관련된 식별자(예: "단수")로 구성됩니다. 이러한 문법적 특징 중 품사적 특징은 의무적이어야 한다. 다른 출처에서 범주 또는 범주의 특정 값으로 기능이라는 용어를 사용하기 때문에 위의 용어와 관련하여 약간의 혼동이 있습니다(이 용어에 대한 논의는 Kibort & Corbett, 2008 참조). 여기서 우리는 범주의 값(예: "복수형")을 지정하기 위해 좁은 의미에서 "기능"이라는 용어를 사용하고 범주와 할당된 값을 모두 나타내는 위의 데이터 유형을 지정하기 위해 넓은 의미에서(굵게 표시됨) 용어를 사용합니다.

  모든 텍스트 요소와 대부분의 핵심 기능은 어휘소 데이터 유형으로 평가되어야 합니다.

• 어휘소 목록은 항목의 순서가 지정된 목록으로, 그 중 하나는 목록의 루트로 식별됩니다. 각 항목은 그 자체로 어휘소 또는 어휘소 목록입니다. 이는 어휘 목록이 부분적으로 지정된 어휘소 트리임을 의미합니다. 어휘소 목록의 루트로 재귀적으로 다이빙하면 결국 목록의 루트 어휘소라고 하는 단일 어휘소에 도달합니다.

  하위 템플릿의 평가는 일반적으로 어휘소 목록을 생성해야 합니다(하위 템플릿이 단일 어휘소로 평가되는 특수한 경우 제외). 여기서 해당 목록의 각 항목은 하위 템플릿의 요소에 해당합니다. 또한 root 레이블이 지정된 요소는 목록의"루트"로 식별되는 항목과 일치해야 합니다.

2단계

이 단계에서 템플릿의 종속성 레이블이 평가됩니다. 평가 순서는 중요하지 않습니다. 레이블이 있는 각 템플릿 슬롯에 대해 슬롯 자체를 대상 슬롯이라고 합니다. 슬롯 레이블이 참조하는 슬롯을 출처 슬롯이라고 합니다. 슬롯 레이블이 없는 경우 출처 슬롯은 항상 템플릿의 루트 슬롯(root 레이블로 식별되는 슬롯)으로 간주됩니다.

대상 어휘소는 대상 슬롯의 평가 결과로 생성된 어휘소입니다. 해당 평가에서 어휘소 목록이 생성되면 목록의 루트 어휘소를 선택합니다. 유사하게 우리는 출처 어휘소를 찾습니다.

각 종속성 레이블은 두 개의 어휘소 인수(출처 및 대상 어휘소)를 입력 인수로 취하는 함수에 해당해야 합니다. 그러한 기능이 없으면 종속성 레이블은 비활성입니다. 종속성 레이블 함수의 평가 순서가 중요하지 않도록 각 함수는 다음 세 가지 작업만 사용할 수 있습니다:

• 종속 레이블과 관련하여 어휘소의 품사 확인(즉, 품사는 일부 품사 유형에 포함되어야 함).
• 통합을 통해 두 어휘소 간에 범주로 식별되는 일부 기능을 공유합니다. 기능은 지정된 기능 계층에 따라 호환되는 경우에만 통합할 수 있습니다. 통합되면 어휘소 전체에서 공유됩니다. 임의의 어휘소를 통한 해당 기능의 후속 변경(예: 다른 종속 관계 함수를 통해)은 다른 어휘소에도 영향을 미칩니다.
• 주어가 되는 요소에 "주격"을 할당하는 것과 같이 미리 결정된 값으로 어휘소의 일부 기능을 수정합니다. 이는 해당 범주로 식별되는 기능을 미리 결정된 값으로 통합함으로써 달성됩니다.

위의 통합 작업은 형식 수준의 기능이 아닌 어휘 수준의 문법 기능에서만 작동합니다. 이 단계 이후에는 각 어휘소의 공통 문법적 특징이 모든 형식에 대해 반드시 참인 것은 아니며 형식에 대한 문법적 제약을 나타냅니다.

3단계

이 시점에서 어휘소 목록의 트리 구조는 더 이상 필요하지 않으며 목록을 평면화할 수 있습니다. 그런 다음 템플릿의 결과 어휘 목록을 순회하고 문법적 제약에 따라 각 어휘소의 형식 목록을 정리하고, 문법적 과소 사양의 경우 문법 범주 및 기능의 사전 결정된 상대적 중요도에 따라 사전순으로 정렬하여 기본 기능 또는 표시되지 않은 기능(예: "명목")이 있는 형식에 우선 순위를 부여합니다.

양식 가지치기는 어휘 데이터의 일관성과 청결도에 따라 두 가지 방법으로 수행할 수 있습니다:

• 언어적으로 가능한 모든 특징의 조합에 대한 형식이 있다는 점에서 어휘 데이터가 일관되고 깨끗하다고 알려진 경우, 필요한 문법 범주가 정확하게 표현되고 엄격한 가지치기가 수행될 수 있으며 제약 조건을 포함하는 형식만 유지됩니다. 특히 이는 양식에 제약 조건에 언급되지 않은 문법 범주가 있는 경우 가지치기됨을 의미합니다. 결과 형식 중에서 해당 목록의 다른 형식을 포함하는 형식도 제거합니다. 이는 여전히 제약 조건을 포함하는 가장 구체적인 형식(기능 계층 관점에서)을 찾는 것과 같습니다.
• 어휘 데이터가 부분적으로만 알려지거나 '깨끗하지 않은' 경우 실현자는 최선의 대안 전략을 구현할 수 있습니다. 이는 제약 조건이 제약 조건과 통합될 수 있는 모든 형식이 유지되도록 하는 관대한 가지치기이거나 일종의 인간 개입 가지치기일 수 있습니다. 여기서 사용자의 입력은 엄격한 가지치기로 전환하기 위해 간격을 메우거나 영향을 받는 부분을 제거하기 위한 점진적 저하 방법입니다.

이 두 가지 가지치기 방법은 여러 개의 나머지 양식을 생성할 수 있습니다. 이러한 이유로 표준 순서에 따라 양식을 정렬하는 것이 중요하므로 선호하는 양식을 궁극적으로 선택할 수 있습니다.

4단계

이 단계에서는 어휘소의 선형 목록을 탐색하고 빈 어휘소(빈 하위 템플릿 실현 또는 일부 함수 호출의 결과일 수 있음)를 제거하고 음운 제약 조건을 계산(또는 조회)합니다. 이를 통해 다양한 어휘소의 음운론적 조건을 갖춘 형태를 선택하여 "sandhi" 현상(단어 내부 및 단어 경계 모두)을 효과적으로 모델링할 수 있습니다.

이 단계의 세부 사항은 실현 언어에 따라 다릅니다. 일반적으로 음운적으로 조건지어진 형태를 가진 어휘소는 선형적 어휘소 목록에서 인접한 어휘소의 음운적 표현(또는 특징)에 접근해야 하고 그에 따라 해당 형식을 선택해야 합니다. 이것은 (주어진 음운론적 제약에 따라) 기존 형식 목록을 추가로 잘라내거나 기존 형식을 변경하기 위해 일부 논리를 적용할 수 있음에 유의하세요.

이 단계에서는 양식의 필요한 융합도 처리해야 합니다. 이는 음운적으로 조건이 지정된 형식을 선택하는 것과 유사하지만 하나 이상의 어휘소(일반적으로 두 개)에 영향을 미칩니다. 경우에 따라 하나의 어휘소 형식이 수정되고 두 개의 형식이 융합되는 두 번째 어휘소 형식이 제거될 수 있습니다.

5단계

이 단계에서 최종 실현 텍스트가 구성됩니다. 모든 어휘소의 기본 형식(정렬된 형식 목록 중 첫 번째)은 사이에 적절한 간격을 두고 함께 연결됩니다. 일반적으로 원본 템플릿의 간격이 유지되지만 연속적인 공간 범위는 단일 공간으로 축소될 수 있습니다. 그러나 일부 공백은 제거될 수 있으며, 특히 구두점 근처 또는 (철자) 기호로 표시된 어휘소 근처에서 제거될 수 있습니다.

이 단계에서는 최종 구현에서 중복되는 구두점을 제거하여 대문자 표시 및 구두점도 처리합니다(예를 들어 일부 하위 템플릿이 빈 문자열로 인식되는 경우 발생할 수 있음). (필요한 언어로) 문장 첫 단어를 대문자로 표기합니다.

예제 템플릿

템플릿 구문과 결과 합성 구문을 설명하기 위해 아키텍처 문서에 제공된 예제 생성자를 살펴보겠습니다:

Age(
    Entity: Malala Yousafzai (Q32732)
    Age_in_years: 24
)

이 간단한 예제에서 생성자의 두 필드는 문장을 생성하는 데 필요하지만(예: "말랄라 유사프자이는 25세입니다"), 더 많은 유연성을 허용하는 선택적 필드가 있는 생성자가 있을 수 있습니다.

생성자가 Age_renderer_xx 형식의 템플릿 함수 호출에 연결되어 있다고 가정할 수 있습니다(오케스트레이터 또는 특수 Dispatch 함수에 의해). 여기서 xx는 언어 코드를 나타냅니다. 또한 생성자의 하위 필드는 이러한 함수에 대한 형식 인수로 사용할 수 있습니다. 설명을 단순화하기 위해 여기에서는 영어 레이블을 사용하지만 실제로는 생성자 이름과 인수가 모두 Z-id일 수 있습니다.

구현이 템플릿 구문과 파생된 합성 구문에서 다양한 언어를 찾는 방법을 살펴보겠습니다. 예제를 더 현실적이고 흥미롭게 만들기 위해 일부가 "n년" 명사구만 렌더링하는 역할을 하는 하위 템플릿 호출 Year_xx을 사용한다고 가정해 보겠습니다.

스웨덴어

스웨덴어에는 (사람) 구두 굴절이 없습니다. 이 문맥에서 숫자 1만 명사의 성에 따라 변용될 수 있지만, 숫자 출력에만 관심이 있다면 이것은 관련이 없습니다. 따라서 결과 템플릿은 문법적 합의가 필요하지 않으므로 매우 간단합니다.

Age_renderer_sv(Entity, Age_in_years): "{Person(Entity)} är {Age_in_years} år gammal ."

프랑스어

Age 생성자가 항상 사람을 참조한다고 가정하면 이 생성자에 대해 주동사 "avoir"를 단수형 "a"로 유지할 수 있으므로 구두 동의가 필요하지 않습니다. 반면에, 연도의 명사 "an"은 숫자를 나타낼 수 있습니다(복수형 "ans"). 이를 인코딩하기 위해 문법적 종속 관계인 [avoir nummod]를 사용합니다. 이 관계의 효과(명사와 수량사 사이의 성별 및 숫자 일치)는 다른 곳(해당 함수에서)에 정의되어 있습니다.

Age_renderer_fr(Entity, Age_in_years):

"{Person(Entity)} a {Year(Age_in_years)}."

Year_fr(years): "{nummod:Cardinal(years)} {root:Lexeme(L10081)}"

히브리어

히브리어에는 두 가지 추가 복잡성이 있습니다. 하나는 주 술어(가사 동사 입자)가 주어와 성별이 일치해야 한다는 것입니다(그리고 종속성 레이블 gmod를 사용하여 표시됨). 두 번째는 "n년"을 표현하기 위한 구성(나이의 맥락에서)은 "n"의 값에 따라 "n" 또는 "년"만을 표현한다는 점이다. 내장 함수 ElideIf가 어근의 문법적 특징을 제거하지 않고 어휘 목록의 텍스트 내용을 조건부로 제거할 수 있다고 가정할 수 있습니다. Piping 구문을 사용하면 기본 슬롯 호출 위에 쉽게 적용할 수 있습니다.

Age_renderer_he(Entity, Age_in_years):

"{subj:Person(Entity)} {root:GenderedLexeme(L64310, L64399)} {gmod:Year(Age_in_years)}."

Year_he(years):

"{nummod:Cardinal(years)|Elide_if(years<=2)} {root:Lexeme(L68440)|Elide_if(years>2)}"

줄루어

줄루어(isiZulu라고도 함)에서 문장의 일반 구조는 "Person has a year(s) that are N"(예제의 출력: "UMalala Yousafzai uneminyaka engama-25")과 유사합니다. 주의해야 할 몇 가지 수준의 일치가 있습니다:

1. 줄루어의 Person 함수는 적절한 명목 표시와 함께 사람의 이름을 가져와야 합니다(사람의 경우 항상 "u", 모음 앞에 "u-"로 표기됨).
2. 동사 "have"(na-)는 주어 일치 표시를 통해 주어와 일치해야 합니다. 일반적으로 사람들은 항상 주제 마커 u-를 가지고 있지만, 예시를 위해 여기서는 관계/subj/ subj 주제 슬롯과 주제 콩코드 형태소를 가져오는 슬롯 사이의 관계(동일한 이름의 함수를 통해). 주제 Concord 형태소는 주제 역할에서 명사의 명사 클래스에 의해 지배됩니다.
3. L-id L686326로 표시되는 "unyaka"(복수형. "imiyaka")라는 단어는 나이와 숫자(단수/복수)가 일치합니다. 이것은 연도 슬롯과 연령 추기경의 슬롯 사이에 nummod 관계를 적용함으로써 달성됩니다.
4. 상대 일치는 연도와 연도를 연결합니다. 연도에 대한 단어의 명사 클래스에 의해 결정됩니다(단수형과 복수형에 따라 다름). 이는 어휘 "연도"를 소스로 하여 해당 어휘가 속한 명사 클래스를 속성으로 갖는 상대 일치 마커를 가져오는 함수에 적용된 concord 관계를 통해 달성됩니다.
5. 나이 숫자 자체는 명사로 취급되며 명사 접두사가 필요합니다. 다시 말하지만, 이것은 concord 관계를 사용하여 달성되며, 이번에는 연령 기수에 소스가 있습니다. 여기서 우리는 Zulu 언어에 대한 Cardinal_zu 함수가 언어 규칙에 따라 적절한 명사 클래스로 기본 어휘를 강화한다고 가정합니다.

이러한 형태 통사 일치 패턴 외에도 몇 가지 음운 조정이 필요합니다. 이는 NLG 파이프라인의 후속 부분에서 처리되지만 완전성을 위해 여기에 나열됩니다.

1. 동사 "na"("have")는 다음 단어 "imyaka"("years")와 함께 단일 단어로 작성됩니다. /a/는 /i/와 병합(즉, 모음 병합)되어 /e/를 형성합니다.
2. 이 문맥에서 코퓰러 "ba" (“to be”)는 /i/ else "ng"가 뒤에 오는 경우 "y"로 실현됩니다. 여기서는 Copula() 함수로 표현됩니다.

Age_renderer_zu(Entity, Age_in_years):

"{subj:Person(Entity)} {root:SubjectConcord()}na{Year(Age_in_years)}."

Year_zu(years):

"{root:Lexeme(L686326} {concord:RelativeConcord()}{Copula()}{concord_1<nummod:NounConcord()}-{nummod:Cardinal(years)}"

브르타뉴어

(이 예를 제시한 VIGNERON에게 감사드립니다)

브르타뉴어는 명사가 항상 숫자 뒤에 단수 형태를 취하기 때문에 형태학적 변화가 필요하지 않다는 점에서 스웨덴어와 유사합니다. 예제 생성자의 결과 문장은 "25 bloaz eo Malala Yousafzai"이어야 합니다. 이러한 이유로 "연도" 어휘(bloaz, 어휘 L45068)의 슬롯에 종속 관계 레이블로 주석을 추가할 필요가 없습니다. 단수 형식이 기본적으로 선택되기 때문입니다. 반면에 bloaz라는 단어는 특정 숫자(1, 3, 4, 5, 9)와 숫자 1000을 따라 음운 돌연변이("연화"라고 함)를 거쳐 vloaz가 될 수 있습니다. 이를 설명하기 위해 우리는 Cardinal 함수(Cardinal_br)의 브르타뉴어 구현이 렌더링된 숫자에 음운 기능으로 주석을 달고 있다고 가정해야 합니다. 이 경우 NLG 아키텍처의 음운학 모듈은 종속성 레이블 주석 없이 다음 명사의 연화를 처리합니다.

Age_renderer_br(Entity, Age_in_years):

"{Cardinal(Age_in_years)} {Lexeme(L45068)} eo {Person(Entity)} ."

템플릿 구문의 도구화

템플릿 구문의 의미는 있는 그대로 구현하거나(구현 참조) 템플릿 구문을 다른 방식으로 사용할 수 있는 실현 알고리즘에 의해 제공됩니다. 위키함수의 맥락에서 템플릿 구문은 위키함수 구성 구문에 알고리즘적으로 매핑되어야 합니다. 다른 접근 방식에는 템플릿 구문을 다른 NLG 프레임워크에 매핑하는 작업이 포함될 수 있습니다. 아래에 샘플링이 나와 있습니다. 관심, 기술 및 툴링이 증가함에 따라 적시에 더 많은 것이 추가될 수 있습니다.

템플릿 구문을 위키함수 구성 구문으로 변환

See also: Abstract Wikipedia/Template Language for Wikifunctions/Transformation of template syntax to Wikifunctions

NLG 구현자에서 템플릿 구문을 다른 형식으로 변환

See also: Abstract Wikipedia/Template Language for Wikifunctions/Transformation of template syntax to other formalisms

구현

현재 Scribunto 모듈로 시스템의 단일 구현이 있습니다.

See also: Abstract Wikipedia/Template Language for Wikifunctions/Scribunto-based implementation