KR101130410B1 - 의미 프로그래밍 언어 및 언어 객체 모델 - Google Patents

Abstract

자연어 소프트웨어 응용 프로그램들을 프로그램하기 위한 소프트웨어 개발 도구가 제공된다. 소프트웨어 개발 도구는 프로그래밍 언어 및 컴파일러를 포함한다. 프로그래밍 언어는 자연어 프로그래밍을 용이하게 하기 위해 일련의 프로그래밍 구성자들을 갖는다. 컴파일러는 일련의 프로그래밍 구성자들의 인스턴스들을 포함하는 소프트웨어 프로그램을 수용하고 소프트웨어 응용 프로그램을 생성하기 위해 적응된다.

의미 프로그래밍 언어, 자연어 소프트웨어, 프리미티브 유형, 선언형 스키마

Description

의미 프로그래밍 언어 및 언어 객체 모델{SEMANTIC PROGRAMMING LANGUAGE AND LINGUISTIC OBJECT MODEL}

도 1은 본 발명의 일 실시예가 구현될 수 있는 컴퓨팅 시스템 환경의 도면.

도 2는 본 발명의 일 실시예에 따른 자연어 시스템의 간략 블록도.

도 3은 언어 객체 모델을 사용하는 도 2의 분석 엔진의 간략 블록도.

도 4는 본 발명의 일 실시예에 따라 전송 메일 명령을 실행하는 프로세스의 간략 흐름도.

도 5는 본 발명의 일 실시예에 따른 유형 분석(type resolution)의 간략 흐름도.

도 6은 본 발명의 일 실시예에 따른 명령 분석(command resolution)의 간략 흐름도.

도 7은 본 발명의 일 실시예에 따른 프레임 분석의 간략 흐름도.

도 8은 본 발명의 일 실시예에 따른 제한 절 분석(restriction clause resolution)의 간략 흐름도.

도 9는 본 발명의 일 실시예에 따른 엔티티 분석 프로세스의 간략 흐름도.

도 10은 본 발명의 일 실시예에 따른 지능형 시스템의 간략 블록도.

도 11은 본 발명의 일 실시예에 따라 어휘 의미 구조(lexical semantic structure)의 간략한 개념적 블록도.

<도면의 주요 부분에 대한 부호의 설명>

202 : SPL 클라이언트 응용 프로그램

214 : 선언형 스키마

212 : 텍스트 입력

204 : SPL 인터프리터(응용 프로그램)

206 : 분석 엔진

304 : 제어 흐름

306 : 응용 프로그램 스키마

302 : 분석 엔진

<관련 출원에 대한 상호 참조>

본 발명은 2004년 4월 23일에 출원된, "의미 프로그래밍 언어(SEMANTIC PROGRAMMING LANGUAGE)"의 표제의 미국특허 제10/830,988의 일부연속출원이다.

본 발명은 자연어의 의미를 모델링하는 시스템 및 방법에 관한 것이며, 보다 구체적으로, 본 발명은 자연어 입력의 내용을 모델링하는 어휘 의미 구조에 관련된다.

자연어는 (컴퓨터 언어 또는 다른 인공 언어와 달리)사람에 의해 생성되는 언어로서, 발화(utterance) 또는 텍스트의 관용어, 가정 및 암시를 모두 포함한다. 자연어 처리의 경우, 명령 및 제어 시스템은 자연어 발화 또는 텍스트를 처리하고 발화 또는 텍스트를 이해 및 해석하여 사용가능한 해석을 도출하려 한다.

종래, 자연어 명령 및 제어를 제공하는 기술 중 하나는 미리 인코딩된 명령의 정적 인식에 관련된다. 예를 들면, 상업적으로 이용가능한 음성-대-텍스트 프로그램은 사용자가 단순 명령들을 사용하여 파일 저장(save file)과 같이 미리 인코딩된 동작을 개시할 수 있게 한다. 그러나, 이러한 프로그램들은 통상 정확한 명령이 사용되지 않는 경우에는 이러한 명령을 처리할 수 없다. 즉, 파일 보관(store file)은 파일 저장이라는 명령을 인식하도록 코딩된 응용 프로그램에 의해 적절하게 이해되지 않을 수 있다.

유사하게, 질의/응답 유형의 응용 프로그램은 통상 탐색 및 검색형 펑션을 용이하게 하기 위해서 미리 인코딩된 어구들 또는 용어들을 포함한다. 그러나, 종래의 구현들은 특정 탐색 용어가 성공을 위해 발화 또는 텍스트에서 사용될 것을 요구하고, 그 결과 사람의 언어의 풍부함을 적절하게 설명할 수 없다.

자연어 응용 프로그램의 프로그래밍은 매우 어렵다. 통상, 프로그래머들은 컴퓨터 언어로 어떻게 코딩할 지를 알지만, 문장 구조를 도식화하고 및/또는 언어 분석을 수행하는 경험은 거의 없다. 이러한 경험부족은 자연어 응용 프로그램을 위한 프로그래밍을 어렵게 한다. 더욱이, 영어로 코딩된 자연어 소프트웨어 응용 프로그램의 다른 언어로의 확장은 통상 소프트웨어 응용 프로그램뿐만 아니라 임의의 관련 언어 분석 엔진의 재코딩을 요구한다. 이는 자연어 응용 프로그램들을 위 한 프로그래밍을 매우 어렵고 또한 매우 비싸게 한다.

일 실시예에서, 자연어 소프트웨어 응용 프로그램들을 프로그램하는 소프트웨어 개발 도구가 제공된다. 소프트웨어 개발 도구는 프로그래밍 언어 및 컴파일러를 포함한다. 프로그래밍 언어는 자연어 프로그래밍을 용이하게 하기 위한 일련의 프로그래밍 구성자들을 가진다. 컴파일러는 일련의 프로그래밍 구성자들의 인스턴스들을 포함하는 소프트웨어 프로그램을 수용하고 소프트웨어 응용 프로그램을 생성하기 위해 적응된다.

다른 양태에서, 자연어를 사용할 수 있는 소프트웨어 응용 프로그램을 생성하는 방법이 제공된다. 프로그램은 자연어 프로그래밍을 용이하게 하기 위한 일련의 프로그래밍 구성자들로부터 생성된다. 프로그램은 자연어 입력에 의존하는 소프트웨어 응용 프로그램의 특징들을 기술한다. 프로그램은 소프트웨어 응용 프로그램으로 컴파일된다.

다른 양태에서, 언어 객체 모델은 자연어의 의미 요소들을 모델링하기 위해 적응된다. 언어 객체 모델은 일련의 유형들 및 그 유형들이 모델링하기 위해 고안되는 언어 표현들의 클래스들을 포함한다. 일 실시예에서, 일련의 유형들 중의 각각의 유형은 발화의 의미적인 요소들에 대응한다.

다른 양태에서, 컴퓨터-판독가능 매체는 사용된 컴퓨터-판독가능 데이터 구조들을 저장하여 자연어를 모델링한다. 일련의 유형들은 클래스들을 추상 객체들로서 나타내기 위해 적응된다. 클래스들은 자연어 발화의 의미적 부분에 대응할 것인 카테고리화된 언어 표현들을 나타낸다.

다른 양태에서, 자연어 입력의 의미 해석을 생성하는 프레임워크는 인터프리터와 일련의 유형들을 포함한다. 인터프리터는 클라이언트 응용 프로그램과 한 개 이상의 분석 엔진들 간을 중재하여, 클라이언트 응용 프로그램에 대해 유효한 자연어 입력의 해석들을 생성하기 위해 적응된다. 일련의 유형들은 인터프리터와 한 개 이상의 분석 엔진들 간의 상호작용들을 정의하기 위해 적응된다.

다른 양태에서, 클라이언트 응용 프로그램의 자연어 특징들에 자연어 입력의 해석을 실체화(instantiation)하는 프레임워크가 제공된다. 인터프리터는 클라이언트 응용 프로그램과 연관된 선언형 스키마로 초기화된다. 인터프리터는 자연어 입력을 수신하고, 한 개 이상의 자연어 분석 엔진들과 통신하여 자연어 입력의 해석들을 생성하기 위해 적응된다. 인터프리터는 클라이언트 응용 프로그램에서 해석들 중의 한 개 이상을 실체화하기 위해 적응된다.

다른 양태에서, 컴퓨터에 자연어 입력의 의미들을 모델링하는 어휘 의미 구조가 제공된다. 일련의 어휘 의미 카테고리들은 자연어 입력의 내용을 모델링하기 위해 선택된다. 벙법은 일련의 어휘 의미 카테고리들 중의 한 개 이상의 카테고리들에 자연어 입력의 내용을 연관시킨다. 다른 실시예들에서, 어휘 의미 구조는 언어들, 언어적 카테고리들, 응용 프로그램들, 및 구문 카테고리(syntactic category)의 한 유형을 생성하기 위해 적응된 시스템들에 대해 자연어 입력을 정규화한다.

다른 양태에서, 자연어를 사용할 수 있는 소프트웨어 응용 프로그램을 생성 하는 방법이 제공된다. 프로그램은 자연어 프로그래밍을 용이하게 하기 위한 일련의 프로그래밍 구성자들로부터 생성된다. 프로그램은 자연어 입력에 의존하는 소프트웨어 응용 프로그램의 특징들을 기술한다. 프로그램은 소프트웨어 응용 프로그램에 컴파일된다.

다른 양태에서, 자연어를 사용할 수 있는 소프트웨어 응용 프로그램들을 개발하는 시스템이 제공된다. 분석가능한 유형들(resolvable types)은 언어 요소들 및 자연어 입력의 언어 요소들 간의 상호관계들의 추상적 표현들을 정의한다. 분석 의미들(resolution semantics)은 자연어를 이용할 수 있는 소프트웨어 응용 프로그램의 분석가능한 유형들의 인스턴스들의 유효성을 분석하는 프로시져 규칙들(procedural rules)을 정의한다.

다른 양태에서, 자연어를 이용할 수 있는 소프트웨어 프로그램의 분석가능한 유형의 실체화의 유효성을 분석하는 방법이 제공된다. 자연어 입력의 해석들이 제안된 제안된 해석 리스트가 집합된다. 각각의 제안된 해석은 한 개 이상의 커맨드들 및 분석가능한 유형들에 매핑되는 선택적으로 비명령(non-command) 요소들을 가진다. 각각의 제안된 해석과 연관된 실체화의 유효성은 자연어를 사용할 수 있는 소프트웨어 응용 프로그램에서 분석된다.

A. 개관

본 발명은 자연어 응용 프로그램을 생성하는 언어 객체 모델(LOM), 의미 프레임워크, 및 의미 프로그래밍 언어(SPL)이다. LOM은 사용된 자연어 또는 관련 응 용 프로그램 도메인과 독립적인 의미 발화를 모델링한다. 의미 프레임워크는 자연어 분석 엔진들과 클라이언트 응용 프로그램 간에 중재하는 런타임 컴포넌트(인터프리터)와 모든 시스템 컴포넌트 간의 상호동작 속성을 정의하는 일련의 유형을 포함한다. SPL은 LOM 및 LOM과 동작하기에 적합한 자연어 분석 엔진들을 인터페이스하는 프로그래밍 프레임워크를 제공한다. 또한, SPL은 다른 언어 객체 모델과 인터페이스하는데 사용될 수 있다.

본 발명은 다수의 서브프로세스들 및 데이터 구조들에 추가하여 전체 프로세스 및 아키텍처를 포함한다. 본 발명을 보다 잘 이해하기 위해서, 본 발명에서 사용될 수 있는 예시적인 환경이 도입된다. 그러나, 본 발명은 광범위한 다른 시스템 및 환경에서 또한 사용될 수 있음이 이해되어야 한다.

B. 예시적인 운영 환경

도 1은 본 발명이 구현될 수 있는 적절한 컴퓨팅 시스템 환경(100)의 일 예를 나타낸다. 컴퓨팅 시스템 환경(100)은 적절한 컴퓨팅 환경의 단지 일 예이며 본 발명의 사용 및 기능의 범위에 대한 임의의 제한을 암시하려는 것은 아니다. 또한, 컴퓨팅 환경(100)은 예시적인 운영 환경(100)에 나타낸 컴포넌트 중 임의의 하나 또는 조합에 관한 임의의 의존성 또는 요건을 갖는 것으로 해석되어서는 안된다.

본 발명은 수많은 범용 또는 특정 목적 컴퓨팅 시스템 환경 또는 구성으로 동작한다. 본 발명에 사용되기에 적합할 수 있는 공지된 컴퓨팅 시스템, 환경 및/또는 구성의 예는 개인용 컴퓨터, 서버 컴퓨터, 핸드헬드 또는 랩탑 장치, 멀티프 로세서 시스템, 마이크로프로세서 기반 시스템, 셋탑 박스, 프로그래머블 소비자 전자제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 전화 시스템, 상기 시스템 또는 장치 중 임의의 것을 포함하는 분산 컴퓨팅 환경 등을 포함하지만 이에 국한되지 않는다.

본 발명은 컴퓨터에 의해 실행되는 프로그램 모듈 등의 컴퓨터 실행가능 명령의 일반적인 경우에 대하여 설명할 수 있다. 통상, 프로그램 모듈은 특정 작업을 수행하거나 특정 추상 데이터형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 또한, 본 발명은 통신 네트워크를 통해 연결된 원격 처리 장치에 의해 작업이 수행되는 분산 컴퓨터 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 스토리지 장치 등의 로컬 및 원격 컴퓨터 스토리지 장치에 배치될 수 있다.

도 1을 참조하면, 본 발명을 구현하는 예시적인 시스템은 컴퓨터(110)의 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(100)의 컴포넌트는 처리부(120), 시스템 메모리(130), 및 처리부(120)에 시스템 메모리 등의 다양한 시스템 컴포넌트를 결합하는 시스템 버스(121)를 포함하지만 이에 국한되지는 않는다. 시스템 버스(121)는 메모리 버스 또는 메모리 컨트롤러, 주변 버스, 및 다양한 버스 구조 중 임의의 것을 사용하는 로컬 버스를 포함하는 여러 형태의 버스 구조 중 임의의 것일 수 있다. 예를 들면 - 한정이 아님 -, 이러한 구조는 산업 표준 아키텍처(ISA) 버스, 마이크로 채널 아키텍처(MCA) 버스, 개선된 ISA(EISA) 버스, 비디오 전자 표준 협회(VES) 로컬 버스, 및 메자닌 버스(Mezzanin)로도 알려진 주변 컴포넌트 직 접접속(PCI) 버스를 포함한다.

컴퓨터(110)는 통상 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(110)에 의해 액세스가능한 임의의 이용가능한 매체일 수 있으며, 휘발성 및 비휘발성 매체, 분리형 및 비분리형 매체를 포함한다. 예를 들면 -한정이 아님 -, 컴퓨터 판독가능 매체는 컴퓨터 스토리지 매체 및 통신 매체를 포함할 수 있다. "컴퓨터 스토리지 매체"라는 어구는, 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 또는 다른 데이터 등의 정보 저장을 위한 임의의 방법 또는 기술에 구현되는 휘발성 및 비휘발성, 분리형 및 비분리형 매체를 포함하려는 것이다. 컴퓨터 스토리지 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 시루, CD-ROM, 디지털 다기능 디스크(DVD) 또는 다른 광 디스크 스토리지, 자기 카세트, 자기 테이프, 자기 디스크 스토리지 또는 다른 자기 스토리지 장치, 또는 원하는 정보를 저장하는데 사용될 수 있고 컴퓨터(110)에 의해 액세스될 수 있는 임의의 다른 매체를 포함하지만 이에 국한되지 않는다. 통상, 통신 매체는 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 또는 반송파 또는 다른 전송 메커니즘 등의 변조된 데이터 신호의 다른 데이터를 구체화하며, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"는 신호 내의 정보를 인코딩하는 방식으로 하나 이상의 특성이 설정 또는 변경되는 신호를 의미한다. 예를 들면 - 한정이 아님 -, 통신 매체는 유선 네트워크, 다이렉트 와이어드 접속과 같은 유선 매체, 어쿠스틱, RF, 적외선 및 다른 무선 매체 등의 무선 매체를 포함한다. 또한, 상기의 것의 임의의 조합은 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다.

시스템 메모리(130)는 판독 전용 메모리(ROM; 131)와 랜덤 액세스 메모리(RAM; 132)와 같은 휘발성 및/또는 비휘발성 메모리의 형태의 컴퓨터 스토리지 장치를 포함한다. 기본 입출력 시스템(131; BIOS)은 시동 동안과 같이 컴퓨터(110) 내의 요소들 간의 정보 전송을 지원하는 기본 루틴을 포함하며 통상 ROM(131)에 저장된다. RAM(132)은 처리부(120) 상에 즉시 액세스가능하고 및/또는 현재 동작하는 데이터 및/또는 프로그램 모듈을 포함한다. 예를 들면 - 한정이 아님 -, 도 1은 운영 체제(134), 응용 프로그램들(135), 다른 프로그램 모듈들(136), 및 프로그램 데이터(137)를 나타낸다.

또한, 컴퓨터(110)는 다른 분리형/비분리형 휘발성/비휘발성 컴퓨터 스토리지 매체를 포함한다. 단지 예를 들면, 도 1은 비분리형 비휘발성 자기 매체로부터 판독하거나 이에 기입하는 하드 디스크 드라이브(141), 분리형 비휘발성 자기 디스크(152)로부터 판독하거나 이에 기입하는 자기 디스크 드라이브(152), 및 CD ROM 또는 다른 광 매체와 같이 분리형 비휘발성 광 디스크(156)로부터 판독하거나 이에 기입하는 광 디스크 드라이브(155)를 나타낸다. 예시적인 운영 환경에서 사용될 수 있는 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래시 메모리 카드, 디지털 다기능 디스크, 디지털 비디오 테이프, 고체 상태 RAM, 고체 상태 ROM 등을 포함하지만 이에 국한되는 것은 아니다. 통상, 하드 디스크 드라이브(141)는 인터페이스(140) 등의 비분리형 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광 디스크 드라이브(155)는 인터페이스(150)와 같은 분리형 메모리 인터페이스에 의해 시스템 버 스(121)에 통상 접속된다.

상술하고 도 1에 도시된 드라이브 및 이들의 관련 컴퓨터 저장 매체는 컴퓨터(110)에 대한 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 및 다른 데이트의 스토리지를 제공한다. 도 1에서, 예를 들면, 하드 디스크 드라이브(141)는 운영 체제(144), 응용 프로그램들(145), 다른 프로그램 모듈들(146)과 프로그램 데이터(147)의 스토리지로서 도시되어 있다. 이들 컴포넌트는 운영 체제(134), 응용 프로그램들(135), 다른 프로그램 모듈들(136), 및 프로그램 데이터(137)와 동일하거나 상이할 수 있다. 운영 체제(144), 응용 프로그램들(145), 다른 프로그램 모듈(146), 및 프로그램 데이터(147)는 적어도 이들이 상이한 복사본임을 나타내기 위해서 여기서 상이한 번호가 주어진다.

사용자는 키보드(162), 마이크로폰(163), 및 마우스, 트랙볼 또는 터치 패드 등의 포인팅 장치(161)와 같은 입력 장치를 통해 컴퓨터(110)에 명령 및 정보를 입력할 수 있다. 다른 입력 장치(미도시)는 조이스틱, 게임 패드, 위성 접시, 스캐너 등을 포함할 수 있다. 이들 및 다른 입력 장치는 종종 시스템 버스에 결합되는 사용자 입력 인터페이스(160)를 통해 처리부(120)에 접속되지만, 병렬 포트, 게임 포트 또는 범용 직렬 버스(USB) 등의 다른 인터페이스와 버스 구조에 의해 접속될 수 있다. 모니터(191) 또는 다른 유형의 디스플레이 장치가 또한 비디오 인터페이스(190) 등의 인터페이스를 통해 시스템 버스(121)에 접속된다. 모니터에 더하여, 컴퓨터는 출력 주변 인터페이스(190)를 통해 접속될 수 있는 스피커들(197) 및 프린터(196)와 같은 다른 주변 출력 장치를 포함할 수 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 사용하여 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 개인용 컴퓨터, 핸드헬드 장치, 서버, 라우터, 네트워크 PC, 피어 장치 또는 다른 공통 네트워크 노드일 수 있으며, 컴퓨터(110)에 대하여 상술한 다수의 또는 모든 요소를 통상 포함한다. 도 1에 도시한 논리적 접속은 근거리 네트워크(LAN; 171) 및 광역 네트워크(WAN; 173)를 포함하지만, 다른 네트워크를 포함할 수도 있다. 이러한 네트워킹 환경은 사무실, 범사내망, 인트라넷 및 인터넷에서 흔히 볼 수 있다.

LAN 네트워킹 환경에서 사용되는 경우, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워킹 환경에서 사용되는 경우, 컴퓨터(110)는 통상 인터넷과 같이 WAN(173)을 통해 통신을 설정하는 모뎀(172) 또는 다른 수단을 포함한다. 모뎀(172)은 내장형 또는 외장형일 수 있으며 사용자 입력 인터페이스(160) 또는 다른 적절한 메커니즘을 통해 시스템 버스(121)에 접속된다. 네트워킹 환경에서, 컴퓨터(110) 또는 그 일부에 대하여 도시된 프로그램 모듈은 원격 메모리 스토지리 장치에서 저장될 수 있다. 예를 들면 - 한정이 아님 -, 도 1은 원격 컴퓨터(180) 상에 상주한 것으로서 원격 응용 프로그램들(185)을 나타낸다. 도시된 네트워크 접속은 예시적이며 컴퓨터 간의 통신 링크를 설정하는 다른 수단이 사용될 수 있음이 이해될 것이다.

C. SPL 프레임워크 개관

SPL 프레임워크는 런타임 컴포넌트(인터프리터)와 일련의 유형으로 이루어진다. 런타임 컴포넌트는 클라이언트 응용 프로그램과 하나 이상의 자연어 분석 엔 진 사이에서 중재한다. 일련의 유형은 시스템 내의 모든 요소 간의 상호동작을 한정한다. SPL 프레임워크를 사용하는 응용 프로그램에서, 인터프리터 인스턴스는 자연어 입력에 의존하는 클라이언트 응용 프로그램에서 특성의 의미 모델을 설명하는 선언형 스키마로 초기화된다. 이러한 선언형 스키마는 응용 프로그램 코드에 따라 개발자에 의해 생성되며, 이는 개발자에 의해 생성되고 LOM에서의 유형으로부터 유도된 다수의 의미 모델링 유형 사이의 관계를 나타낸다. 이들 의미 모델링 유형은 선언형 스키마에서 나타내지 않고 유형의 인스턴스화 상의 런타임 문맥에 의한 제한을 배치하는 절차 코드를 포함할 수 있다.

도 2는 본 발명의 일 실시예에 따른 의미 프레임워크의 블록도이다. 의미 프레임워크(200)는 SPL 클라이언트 응용 프로그램(202), SPL 인터프리터 응용 프로그램(204) 및 복수의 분석 엔진(206)을 포함한다. 통상, SPL 클라이언트 응용 프로그램(202)은 (키보드 또는 다른 입력 장치를 통해)사용자에 의해 직접 입력되거나 음성 인식 시스템(208) 또는 텍스트 인식 시스템(210)으로부터 수신될 수 있는 텍스트 입력을 수신한다.

음성 인식 시스템(208)은 오디오 입력을 수신하고 상기 오디오 입력을 나타내는 텍스틀 출력을 생성하는 시스템이다. 텍스트 인식 시스템(210)은 수기 또는 스캔된 입력을 수신하고 상기 수신 또는 스캔된 입력을 나타내는 텍스틀 출력을 생성하는 시스템이다. 일 실시예에서, 음성 인식 시스템(208)과 수기 인식 시스템(210)은 클라이언트 응용 프로그램(202)에 통합된다.

프레임워크(200)에서, 텍스트 입력(212) 문자열은 SPL 클라이언트 응용 프로 그램(202)에 입력된다. 텍스트 입력(212A)은 음성 인식 시스템(208)으로부터의 텍스트 출력을 의미한다. 텍스트 입력(212B)은 수기 입력 시스템(210)으로부터의 텍스트 출력을 의미한다. 텍스트 입력(212C)은 키보드, 메모리 버터 또는 임의의 다른 입력 소스로부터와 같은 다른 텍스트 입력을 나타낸다. 이하, 참조 부호(212)는 소스와 독립적으로 수신된 텍스트 입력에 적용된다.

SPL 클라이언트 응용 프로그램(202)은 SPL 클라이언트 응용 프로그램의 텍스트 입력(212)과 응용 프로그램 스키마(214)를 SPL 인터프리터 응용 프로그램(204)에 전달한다. SPL 인터프리터 응용 프로그램(204)은 텍스트 입력(212)과 응용 프로그램 스키마(214)를 복수의 자연어 분석 엔진(206)에 전달하며(상자 분석 엔진(1) 내지 분석 엔진(N)을 통해), 이들 각각은 언어 객체 모델(LOM; 216)에 발화를 매핑하도록 설계된다. 임의 개수의 분석 엔진(206)이 사용될 수 있으며, 각 엔진(206)은 텍스트 입력(212)을 LOM(216)에 그리고 응용 프로그램 스키마(214)에 매핑하는 고유 분석 전략을 사용할 수 있다.

통상, 각 분석 엔진(206)은 텍스트 입력(212)을 이 패러다임에 적용하고 텍스트 입력(212)을 LOM(216)에 매핑하여 복수의 가능한 해석들(218)을 생성하며, 이는 SPL 인터프리터 응용 프로그램(204)에 리턴된다. SPL 인터프리터 응용 프로그램(204)은 하나 이상의 실제 해석(220)을 식별하고, 이들 실제 해석(220)을 SPL 클라이언트 응용 프로그램(202)에 리턴하며 그 후 하나 이상의 실제 해석(220) 상에 실행할 수 있다.

일 실시예에서, 분석 엔진(206)은 단지 하나의 가능한 해석들(218)을 구동하지만, 대부분의 의미 발화는 하나 이상의 가능한 해석이 가능하며, 이는 발화의 경우에 있어서 인터프리터(204) 또는 클라이언트 응용 프로그램(202)에 의해 분석될 수 있다. 이 경우, 문맥은 SPL 클라이언트 응용 프로그램(202)과 이것이 지원하는 객체의 도메인이다. SPL 인터프리터(204)는 SPL 클라이언트 응용 프로그램(202)으로부터 선언형 스키마(214)를 수신하여, 선언형 스키마(214)에 대하여 가능한 해석들(218)을 분석하려 한다. SPL 인터프리터(204)는 선언형 스키마(214)에 대하여 분석될 수 없는 가능한 해석들(218)을 폐기할 수 있다. 나머지 해석(선언형 스키마(214)에 대하여 분석될 수 있은 것)이 실제 해석(220)이다. SPL 인터프리터(204)는 클라이언트 응용 프로그램(202)에서 실제 해석 객체(220)를 호출하여 SPL 클라이언트 응용 프로그램(202)의 선언형 스키마(214)에 따라 복수의 실제 해석(220) 각각을 인스턴스화하려 한다.

프레임워크(200)의 구현 및 구성에 따라, 컨트롤(222)은 SPL 클라이언트 응용 프로그램(202)에서 SPL 인터프리터 응용 프로그램(204)으로 전달되어 다른 처리를 수행할 수 있다. 유사하게, 인터프리터 응용 프로그램(204)은 LOM(216)에 대하여 텍스트 입력(212)의 추가 처리를 위한 분석 엔진에 컨트롤(224)을 전달할 수 있다. 따라서, 의미 프레임워크(200)는 텍스트 입력을 처리하여 SPL 클라이언트 응용 프로그램(202)의 도메인 내에 한정된 유형에 대응하는 실제 해석에 반복적으로 도달할 수 있다.

통상, SPL 클라이언트 응용 프로그램(202), 인터프리터(204) 및 분석 엔진(206)은 단일 컴퓨터에 배치될 수 있다. 다른 실시예에서, 응용 프로그램(202), 인터프리터(204) 및 엔진(206)은 네트워크 상의 개별 서버와 같은 상이한 시스템 상에 배치될 수 있다.

SPL 인터프리터(204)는 클라이언트 응용 프로그램(202)과 분석 엔진(206) 사이의 중개자로서 동작한다. SPL 프로그래밍 언어는 개발자에게는 직관적이다. 일 실시예에서, 언어는 C#의 상부에 설치되고, 구문은 개발자에게는 보다 친숙할 수 있다. 그러나, SPL은 LOM 의미 구조를 표현하고 언어 분석을 수행하기에 적합하고 C#에 직접 또는 임의의 다른 객체 지향 프로그래밍 언어로 구현될 수 있다.

상술한 바와 같이, SPL 프레임워크는 런타임 컴포넌트(SPL 인터프리터(204))를 포함하고, 이는 개발자에 의해 생성되고 LOM에서 한정된 유형에서 유도된 일련의 유형과 자연어 분석 엔진(206) 사이를 중재한다. 일련의 유형은 프레임워크의 모든 컴포넌트 간의 상호동작의 속성을 한정한다.

SPL 프레임워크는 자연어 분석 엔진을 사용하지만 이를 포함하지는 않는다. 필요시, 다수의 분석 엔진이 동시에 사용될 수 있도록 설계된다. 예를 들면, 일부 엔진은 다른 것보다 특정 종류의 자연어에서 보다 우수할 수 있기 때문에 여러 분선 엔진을 사용하기 원할 수 있다. 다수의 엔진의 출력의 조합은 보다 우수한 전체 성능과 동작을 야기한다.

임의의 주어진 자연어 입력(212)에 있어서, 분석 엔진(206)은 선언형 스키마(214)에서 나타낸 유형의 시스템으로 표현되는 언어적으로 가능한 해석들(218)을 인터프리터(204)에 제공한다. 통상, 분석 엔진(206)은 실체 유형이 아닌 선언형 스키마(214)로의 액세스를 갖는다. 실제 객체를 생성하는 대신, 가능한 해석들(218)을 생성하며, 이는 실제 해석(220)을 구축하는 일련의 명령이다. 분석 엔진(206)에 의해 생성된 가능한 해석들(218)은 관련 유형의 절차 코드의 실행을 포함하는 인터프리터(204)가 해석의 인스턴스화 생성을 성공한 경우에만 실제 해석이 된다. 인터프리터(204)는 선언형 스키마(214)에 대하여 가능한 해석들(218)을 해석하려 하며, 특정 구현에 따라, 추가 처리를 위해 클라이언트 응용 프로그램(202)에서 성공적으로 분석된 해석을 인스턴스화한다.

클라이언트 응용 프로그램(202), 인터프리터(204) 및 분석 엔진(206)(텍스트 입력(212), 선언형 스키마(214), 가능한 해석들(218), 실제 해석(220), 및 컨트롤 흐름(222 및 224) 등)의 앞뒤로는 충돌 및/또는 모호성을 분리한다. 프레임워크와 LOM은 함께 프로그래머가 언어 분석 대신 응용 프로그램 도메인에 대한 걱정을 덜어 준다.

통상, 선언형 스키마는 XML 코드, 마이크로소트프 .NET 속성, 또는 마이크로소프트 .NET 속성과 자체적으로 분석가능한 유형일 수 있다. 다르게는, 분석가능한 유형은 스키마 정보가 "반사(reflection)"를 사용하여 유형으로부터 추론될 수 있도록 코딩될 수 있다. 반사는 메소드, 영역, 구성자 등이 클래스 또는 객체에 대하여 정의되는 방식을 분석하는 능력이다. 반사는 동적 프로그램을 생성할 수 있다.

프레임워크가 도입되기 때문에, 개발자가 그 또는 그녀의 응용 프로그램 특정 유형을 유도할 수 있는 하부 언어 객체 모델을 이해하는 것이 중요하다. 언어 객체 모델은 자연어 응용 프로그램 개발 목적을 위해 유용한 것에 더하여, 임의의 목적을 위해 자연어 의미 분석 시스템과 직접 상호동작하는데 사용될 수 있다.

D. 언어 객체 모델(LOM)

D1. 개관

본 발명의 언어 객체 모델(LOM)은 응용 프로그램 도메인 또는 언어와 독립적인 일련의 유형으로 이루어진다. 본 발명은 일련의 유형과 이들 유형이 모델하도록 설계된 언어 표현의 클래스를 포함한다. 유형은 LOM의 선언형 요소이다.

본 발명의 응용 프로그램은 임의 개수의 방식으로 구현도리 수 있으며, 특정 구현 세부사항은 여기서 제공된 예에서 변경될 수 있다. 그러나, 후술하는 예는 단지 예시의 목적이며 이를 한정하는 것으로 해석되어서는 안된다. 적절한 경우, 다른 방법 또는 프레임 변형이 본 발명의 다용성 및 강인성을 설명하도록 더 나타낼 수 있다.

통상, LOM은 도메인 독립 방식으로 발화(구두 또는 서면)의 의미를 모델링한다. 여기서 사용되는 "도메인(domain)"이라는 용어는 자연어 처리 요청을 발하는 SPL 클라이언트 응용 프로그램을 의미한다. 여기서 사용되는 바와 같이, "의미(semantics)"라는 용어는 구두 또는 서면 어휘의 의미 또는 표시를 나타낸다. "발화(utterance)"이라는 용어는 언어 엔진이 의미 분석하려 하는 소프트웨어 엔진에 의해 검출되는 임의의 유한한 사운드 또는 일련의 사운드 및/또는 임의의 서면 어휘를 나타낸다. 여기서 사용되는 바와 같은 "구문(syntax)"라는 용어는 언어 내의 심볼이 단어, 숙어, 표현 및 다른 인지가능 구성자를 형성하도록 조합되는 방식을 정의하는 문법 또는 구조 규칙을 의미한다.

LOM 유형은 소프트웨어 응용 프로그램에 의해 액세스되어 언어 표현의 클래스에 발화 요소를 매핑할 수 있다. 간이함을 위해서, 다음 설명은 LOM 유형으로부터 언어 표면의 클래스로의 주요 매핑으로서 취한다. 그러나, 이 매핑은 LOM 유형으로부터 언어 표현의 클래스로의 또는 그 역의 풀 듀플렉스(양방향) 매핑이다. 이러한 매핑의 양 방향은 상이한 작업에 있어서 중요하다. 더욱이, LOM 자체는 어떤 코드 변경도 상이한 언어를 모델링하기 위해서 LOM에 요구되지 않도록 독립한 언어이다. 이러한 언어 특정 코드 변화는 클라이언트 응용 프로그램이 아닌 분석 엔진에서 행해진다.

통상, LOM은 일련의 빌딩 블록으로서 추상적으로 언어를 규정한다. SPL 응용 프로그램은 빌딩 블록 프레임워크를 사용하여 도메인 의존 방식으로 어휘 의미 구조 및 분석 엔진을 액세스한다. 마지막으로, LOM은 응용 프로그램 스키마가 동작하지 않음을 이해하여야 한다. LOM은 발화를 모델링하도록 사용될 수 있고, 분석 엔진은 응용 프로그램 스키마와 독립적인 LOM 매핑을 제공할 수 있다. 따라서, LOM은 분석 엔진 내부로 간주될 수 있으며, LOM은 자연어를 의미상으로 표현하는 방식이다. 분석 엔진은 해당 발화에 대하여 올바른 LOM 표현이 무엇인지에 대한 분석을 행하여, 이 발화를 LOM에 효과적으로 매핑한다.

도 3은 본 발명의 실시예에 따라 도 2의 시스템의 분석 컴포넌트(300)의 간략 블록도를 나타낸다. 분석 엔진들(302)은 플로우 컨트롤(304), 응용 프로그램 스키마(306), 및 텍스트 입력(308)을 수신한다. LOM(310)을 사용하여, 분석 엔진들(302)은 응용 프로그램 스키마(306)가 수신되는 클라이언트 응용 프로그램에 의해 또는 SPL 인터프리터에 의해 분석될 수 있는 하나 이상의 가능한 해석(312)을 생성하기 위해서 응용 프로그램 스키마(308)에 텍스트 입력(308)을 매핑한다.

통상, 가능한 해석(312)은 단순히 LOM 객체로서 표현되는 특정 유형의 객체이다. 분석 엔진들(302)은 구현에 따라 가능한 해석을 인터프리터 또는 클라이언트 응용 프로그램에 리턴하기 전에 LOM 객체를 응용 프로그램 스키마의 대응 객체에 추가 매핑할 수 있다.

LOM의 구성을 보다 상세히 설명하기 전에, 의미 프로그래밍 언어에 의해 사용되는 베이스 유형의 적어도 피상적 이해를 구현하는 것이 유용하다. 통상, 의미 프로그래밍 언어는 임의 개수의 상이한 의미 객체 모델 상에서 동작할 수 있지만, LOM 구조에 동작하도록 구체적으로 최적화된다. 이 때, LOM은 프로그래밍 지능성(응용 프로그램 개발자의 관점)과 언어 커버리지(즉, 명령과 제어, 질의-응답, 등의 응용 프로그램 시나리오에서 요구되는 모델 요소) 간의 최적의 타협을 제공하는 특정 의미 액체 모델이다.

D2. 의미 프로그래밍 언어 유형

의미 프로그래밍 언어(이하, "SPL"로 불림)는 자연어 프로그램을 구현하도록 소프트웨어 응용 프로그램 개발자를 지원하려는 것이다. 대부분의 개발자는 의미 분석 또는 언어학 전문가가 아니기 때문에, SPL은 비언어학 개발자에게 프레임워크와 프로그래밍 언어를 제공하여 보다 직관적인 방식으로 자연어 의미를 다루게 한다.

SPL과 이에 수반한 컴파일러는 자연어 클라이언트 응용 프로그램의 LOM으로 의 프로그래밍을 용이하게 한다. SPL은 개발자가 프레임워크와 적절하게 상호동작하는 코드를 작성할 수 있게 하기 위해서 언어 프레임워크의 하부 세부사항 중 다수를 감추도록 설계된다.

SPL이 프레임워크를 사용하는 개발자에게 표준 전단(front-end)일 수 있더라도, SPL은 요구되지 않는다. 개발자는 다양한 프레임워크 인터페이스를 구현하는 유형을 생성하여, 다양한 프레임워크 인터페이스를 구현하는 유형으로부터 상속하여, 그리고 응용 프로그램 스키마을 인터프리터에 제공함으로써 프레임워크에 직접 타겟할 수 있다. 다르게는, 이는 예를 들면 시각적 형태 기반 설계 도구를 통해 프레임 호환 코드를 작성하는 다른 수단 등으로 간접적으로 행해질 수 있다.

통상, LOM은 SPL의 클래스 라이브러리로서 구현된다. 이는 C 런타임 라이브러리와 표준 템플릿 라이브러리(STL)가 예를 들면 소프트웨어 개발을 용이하게 하도록 설계된 응용 프로그램으로서 미국 워싱턴주 레드몬드의 마이크로소프트 사에 의한 마이크로소프트

비주얼 C++

의 표준 라이브러리를 형성하는 방식과 유사하다. 마이크로소프트

과 비주얼 C++

라는 용어는 미국 워싱턴주 마이크로소프트사가 소유한 상표이다.

SPL에서 의미론적으로 유의미한 유형은 인커밍 발화의 의미를 모델링하고 이들 인커밍 발화에 대응하는 응용 프로그램 명령을 모델링하는 것에 관여하는 유형이다. 의미론적으로 유의미한 유형은 SPL 작성자가 그들의 응용 프로그램 도메인으로부터 유도하여 특화하는 유형이다. SPL에서 의미론적으로 유의미한 유형은 엔티티, 프레임, 제한, 명령, 및 표시자(denoter) 객체이다. SPL에서 기능형은 어구 및 슬롯이다. 이들 유형 각각은 이하 개별적으로 설명한다.

통상, SPL 프레임워크는 클라이언트 응용 프로그램, SPL 인터프리터, 및 하나 이상의 자연어 분석 엔진들 간의 모든 상호동작 양태를 한정한다. "모든 상호동작 양태"라는 어구는 다양한 컴포넌트가 구현하여야 하는 인터페이스, 이로부터 다양한 컴포넌트가 상속하는 베이스 클래스, 및 시스템 컴포넌트 사이에 전달된 데이터 유형을 의미한다. 일 실시예에서, 프레임워크 유형은 미국 워싱턴주 레드몬드의 마이크로소프트

사에 의해 작성된 프레임워크인 .NET 프레임워크 내의 유형으로 구현된다. SPL 유형은 여러 명칭 공간으로 배치될 수 있다. 일 실시예에서, SPL 유형은 여러 명칭 공간으로 배치되고, 이들 모두는 예를 들면 System.NaturalLanguageServices 또는 System.NaturalLanguage 명칭 공간의 모든 서브명칭 공간이다. 여기서 사용되는 바와 같이, "명칭 공간(namespace)"은 명칭(식별자)이 정의되는 문맥을 의미한다. 해당 명칭 공간 내에서, 모든 명칭은 고유해야 한다.

간이함을 위해서, 다음 설명은 SPL 유형을 소개하며, LOM을 상세하게 소입한 후 SPL을 상세하게 리턴한다. 텍스트를 통해, 본 발명을 나타내는 적절한 경우의 예들이 사용된다. 대부분, 단순 자연어 발화(Send mail to Bob)로부터의 예가 유도한다. 이 발화에 있어서, LOM에 따라 기입되고 SPL을 사용하는 응용 프로그램은 텍스트 입력에 기초한 해석을 생성할 수 있다. 생성된 해석은 그 후 자연어 응용 프로그램에 대하여 분석되어 명령의 실제 해석을 식별 및 실행할 수 있다.

엔티티는 유형 엔티티의 객체로서, 엔티티가 데이터 멤버, 속성 및 메소드를 포함할 수 있다. SPL 엔티티는 그 유형이 클래스 엔티티로부터 유도되는 객체이고 주로 명사 어구 및 형용사 어구의 의미를 모델링하는데 사용된다. SPL 엔티티는 "with" 구문을 통해 프레임 또는 제한(모두 후술함)을 호스트할 수 있다. 또한, SPL 엔티티는 선택된 어구"표시(Denoted by)"를 포함하며, 이는 (후술하는)유형 "표시자"의 특별 데이터 멤버를 도입한다. 특별 데이터 멤버는 어구 "표시"에 의해 도입되며, SPL 인터프리터에 의해 사용되며 실제 자연어 단어에 엔티티를 매핑할 수 있다.

프레임은 의미 이벤트의 의미를 모델링하는 클래스이며, 의미 이벤트는 동사 또는 명사로서 표현될 수 있다. SPL 프레임은 프레임으로부터 유도하는 클래스이다. 통상, 프레임은 엔티티에 적용할 수 있으며, 프레임은 어구 "표시"뿐만 아니라 인수를 포함하는 (후술하는)"슬롯" 리스트를 가질 수 있다. 또한, 프레임은 "with" 구문을 통해 제한을 호스트할 수 있다. 일 실시예에서, 프레임에 대한 어두어(head word)는 개발자에 의해 한정되어 새로운 프레임 유형을 생성할 수 있다. 다른 실시예에서, 개발자는 기존 프레임에서 상속하여 상속으로부터 원하는 어두어를 유도한다. 다른 실시예에서, 개발자는 표시자가 규정하는 방식과 유사한 방식으로 어두어를 규정할 수 있다.

통상 제한은 사격(oblique) 인수, 수식어구, 및 다른 의미 요소를 모델링한다. SPL 제한은 클래스 제한으로부터 유도하는 클래스이다. 프레임과 같은 제한은 인수 등의 슬롯 리스트를 갖는다. 또한, SPL 제한은 "with" 구문을 통해 다른 제한을 호스트할 수 있다.

SPL 명령은 클래스 명령을 유도하는 클래스이다. 명령은 순수하게 도메인 종속적이어서, 관련된 특정 자연어 응용 프로그램에 의존하게 된다. 통상, 도메인 종속 명령은 입력 의미의 모델링에 어떤 역할도 하지 않으며, 그 명령은 LOM에서 동작하지 않는다. 그 대신, 명령은 응용 프로그램 내의 동작을 모델링한다.

또한, 명령은 선택적인 "사용(uses)" 어구를 가지며, 이는 프레임 유형의 특별 데이터 멤버를 도입한다. "사용" 어구는 도메인 독립 입력과 원하는 도메인 종속 동작 간의 주요 링크이다.

표시자 객체는 표시자 유형의 구조체이다. 실제, SPL의 표시자로서 사용되는 각 단어로부터 표시자의 대응 리스트에 매핑하는 어휘집이 생성되어, 표지가 객체가 문자열 리스트를 저장할 필요가 없다. 자연어마다 하나의 표시자 객체가 있다(영어 필드, 일본어 필드 등). 표시자 객체는 엔티티에 대한 로컬화 테이블로서 동작한다. 명령과 같이, 표시자 객체는 순수하게 도메인 종속이다. 그러나, 엔티티는 표시자 유형의 필드를 가지며, 이는 응용 프로그램이 표시자 객체를 검사하여 엔티티가 분석 엔진에 의해 제안되는 이유를 판정할 수 있도록 존재한다.

SPL에서의 기능 유형은 일부 모델링 목적을 지원하지만 특화되지는 않는 유형이다. 또한, 다른 클래스 및 유형은 기능 유형으로부터 유도될 수 없다.

기능 유형 "어구"는 몇몇 의미 객체 하부의 텍스트 문자열 입력의 일부에 대한 정보를 요약한다. 유형 어구는 소프트웨어 개발자가 입력 문자열의 의미의 구조화된 표현 내부로부터의 원래 입력 문자열의 임시 조작 및 검사를 수행할 수 있게 한다.

일 실시예에서, 기능 유형 "슬롯"은 엔티티, 프레임, 제한 또는 표시자 객체, 가능하게는 몇몇 보조 정보와 함께 보유하는 유형 슬롯의 객체이다. 예를 들면, 상대 어구에서의 갭에 대응하는 슬롯은 "후행 참조(backreference)"로서 표시된 엔티티를 포함한다. 다른 실시예에서, 엔티티, 프레임, 또는 다른 참조가 슬롯이 예측되는 곳에 배치된다. 또다른 실시예에서, 슬롯 객체는 보조 정보와 함께 생략되고, 엔티티, 프레임 또는 다른 참조가 간접적으로 사용된다.

D3. LOM 유형

SPL 의미 모델 구조체를 한정하는 유형을 검토하여, LOM을 보다 상세히 설명한다. 통상, LOM 유형과 유형에 의해 모델링되는 언어학적 표현의 클래스는 엔티티, 프레임 및 제한을 포함한다.

a. LOM 엔티티

많은 부분, 그리고 대부분의 SPL 프로그래머의 작업은 도메인 어레이 유형의 어레이를 설계하고 이들 유형 각각에 대한 올바른 로컬화 정보를 LOM 관점에서 수집하는 것에 중심으로 삼지만, 엔티티는 직접적이다. 많은 경우, 어구의 "어두어(head word)"는 엔티티의 어두어이다. 어두어는 통상 엔티티 모델의 어구의 구문 어두의 표제어(lemma)에 대응한다. 표제어는 단어의 상이한 형태에 대한 규범적 표현(canonical representation)을 나타낸다. 예를 들면, walks, walked 및 walking이라는 용어는 표제어 walk를 공유한다.

사용한 구술 언어에 관계없이, 모든 언어에 대한 일반 규칙은 NP가 LOM 엔티티가 된다는 점이다. 엔티티의 어두어는 NP의 주요 명사(head noun)의 표제어이 다.

통상, 엔티티의 좌표는 "CoordinatedEntity" 유형을 통해 LOM으로 표현된다. CoordinatedEntity 유형의 인스턴스화를 나타내는 코드 단편(code snippet)이 표 1에서 도시되어 있다.

표 1: CoordinatedEntity

Entity CoordinatedEntity

{

Entity entities [];

CoordRelation relBetweenEntities;

}

enum CoordRelation

{

And,

Or,

ExclusiveOr

}

좌표에 대한 LOM의 목표는 의미론적으로 무관한 브래킷 보호성을 최소화하는 것이다. 따라서, 예를 들면, X와 Y와 Z의 텍스트 입력은 플랫 리스트인 X AND Y AND Z로서 표현되고, 우측 결합 X AND [Y AND Z]와 좌측 결합 [X AND Y] AND Z사이에 모호하지 않게 된다. 그러나, 진정한 브래킷 모호성이 있는 경우, LOM은 모호성을 보존하게 된다. 예를 들면, 4WD 및 ABS 또는 AWD를 갖는 차량을 나타내는 어구에 있어서, 4WD AND [ABS OR AWD]와 [4WD AND ABS] OR AWD가 모두 가능하다. 물론, 이러한 특별한 경우, 단지 제2 표현이 의미를 갖지만, LOM이 아닌 분석한 응용 프로그램에 대한 것이다.

대명사는 "PronounEntity" 유형의 객체로서 LOM에 모델링된다. 본 발명의 일 실시예에 따른 대명사 엔티티의 인스턴스화의 일 예가 표 2에 도시되어 있다.

표 2: PronounEntity

entity PronounEntity

{

Entity potentialAntecedent [];

}

LOM은 PronounEntity 내의 "potentialAntecedents" 필드를 통한 어두 반복(anaphora) 분석을 위한 인터페이스를 제공한다. "어두 반복"이라는 용어는 동일 엔티티를 나타내는 다수의 단어 또는 어구 간의 관계를 나타낸다. potentialAntecendet 필드는 언어학적으로 가능한 선행사(antecedent)인 이전에 분석된 엔티티 객체의 리스트로 선택적으로 채워질 수 있다. 리스트는 하강 정렬로 정렬된다. 어두 반복 분석에서 가장 중요한 요소인 언어학적 일치 정보는 모든 엔티티에 부착된 "AgreementInfo" 유형을 통해 응용 프로그램 개발자에 의해 액세스될 수 있다. 구조체 AgreementInfo의 일 예는 표 3에 제공되어 있다.

표 3: Struct AgreementInfo

struct AgreementInfo

{

bool firstPerson;

bool secondPerson;

bool thirdPerson;

bool singular;

bool plural;

bool feminine;

bool masculine;

bool neuter;

bool honorific;

bool humble;

}

주어진 엔티티에 대하여 모호하지 않게 참인 AgreementInfo 필드만이 엔티티의 AgreementInfo 객체에 관련되어 있다. 즉, LOM은 논리합 일치 특성(disjunctive agreement feature)을 나타내려 하지 않는다. 예를 들면, cat라는 용어는 그 AgreementInfo 객체에 관련된 "thirdPerson" 및 "singular"를 가질 수 있다. she라는 어구는 이의 AgreementInfo 객체에서 "thirdPerson", "singular" 및 "feminine"에 관련된다. 프랑스어에서, "vous"라는 용어는, "secondPerson"에 관련된다. 스페인어에서, perro라는 용어는 "thirdPerson", "singular" 및 "masculine"이며, 이들 각각은 주어진 엔티티 perro에 대하여 모호하지 않게 참이며, 이에 따라 엔티티의 일치 객체에 관련된다.

"this" 및 "that"과 같은 지시사는 독립적인 NP로서 사용될 수 있으며, DemonstrativeEntity의 객체가 된다. 엔티티 Demonstrative의 예는 표 4에 도시되어 있다.

표 4: DemonstrativeEntity

entity DemonstrativeEntity

{

DemonstrativeType type;

}

enum DemonstrativeType

{

Near,

Middle,

Far

}

DemonstrativeEntity 유형의 객체는 Entity로부터 유도되기 때문에, 이들은 AgreementInfo 객체를 상속하여, this 및 that과 같은 단어가 구별될 수 있게 한다. 통상, 이러한 상속은 시스템이 영어, 프랑스어, 독일어, 일본어, 스페인어 및 수많은 다른 언어에서 이러한 요소들을 올바르게 구별할 수 있는 능력을 가질 수 있게 한다.

다른 관련 유형은 NamedEntity 유형이다. NamedEntity에 대한 구문은 다음과 같다.

namedentity OlapNamedEntity uses

Enxcel.FuzzyOlapCubeRecognizer;

통상, Namedentity 유형은 NamedEntityRecognizer 클래스로부터 상속한 개별적으로 정의된 클래스에 기초한다. NamedEntityRecognizer 유형은 스키마에 따라 전달되고, 분석 엔진은 이들을 사용하여 클라이언트 코드에 호출되고 발화 내의 응용 프로그램 객체 참조를 동적으로 식별할 수 있다.

b. LOM FRAMES

일 구현예에서, 모든 언어에 대하여, 절은 LOM 프레임이 되지만, 이는 모든 구현예에서 참은 아니다. 개념적으로, 하나의 프레임은 하나의 절에서 기인하지만, 입력 내에 하나의 절이 실제 있을 필요는 없다. 프레임의 어두어는 절의 처음에 있는 동사의 표제어이다. 예를 들면, 어구 "Send mail to Bob"의 분석은 "send mail"이 LOM 프레임에 관련되게 하고, 이는 "Send"가 절의 동사 어두의 렘마이고 이에 따라 프레임의 어두어가 될 수 있다.

제한은 기본 동작에 대한 제공으로서 개념화될 수 있음을 이해하여야 한다. 그러나, 이러한 동작은 반드시 강요되는 것은 아니다. 기능은 구현예에 특정된다.

슬롯은 엔티티 또는 프레임에 의해 채워지기 때문에, 기본 슬롯은 명사 어구 또는 절일 수 있다. 또한, NP는 공 대명사(empty pronoun; PRO)의 어두에 있을 수 있다. PRO가 다른 절에서 지시대상을 지시하는 경우, 절의 어두는 NP 엔티티의 어두로서 해석될 수 있다. PRO가 지시대상이 없는 경우, 일부 엔티티로서 해석될 수 있다(주요 사람 또는 주요한 것).

일 실시예에서, 절에 주어가 포함된다고 가정하면, 절의 주어는 "Doer" 제한을 채운다. 주어가 없는 경우, 실행자(doer), 동작주(agent), 행위자(actor), 선동자(instigator)로 느슨하게 표현된 의미 또는 동사로 지명된 이벤트 또는 상태의 요인을 사용하여 이벤트 내의 제1 구성원을 나타낸다. 절의 일부가 프레임의 제한을 "doer"에 매핑하는 동사 절의 예를 표 5에 나타낸다.

표 5. 주어를 갖는 동사 절

Instant message opens.

Robin is on my buddies list.

Amazon offers wish list capabilities.

[PRO] open the file

Having a program associated with a file ensures easy opening

밑줄친 단어 또는 어구는 Doer 슬롯에 매핑된 것이다. 이는 타동사와 자동사에 대응하는 타동사 및 자동사 프레임에서 모두 참이다.

절에서 목적어가 있는 경우, 목적어는 이벤트 내의 제2 의미 참가자를 나타내는 "DoneTo"로 불리는 제2 프레임 슬롯에 매핑된다. 의미론은 동상에 의해 지명된 이벤트 또는 상태에 의해 영향을 받는 목적어를 의미하는 것으로 광의로 이해될 수 있다. 표 6의 밑줄친 어구는 "DoneTo" 제한에 매핑된다.

표 6: The "DoneTo" 제한

Outlook has my buddies list.

Amazon offers wish list capabilities.

[PRO] open the file.

Preferences include having a program associated with a file.

일 구현예에서, 간접 목적어는 동작의 수익자로서 이해될 수 있다. 일 실시예에서, 간접 목적어는 수익자 제한에 매핑될 수 있다. 수익자 제한은 이벤트가 수행되는 것을 대표 또는 대신하여 자신을 표현하는 통상 동사 인수를 모델링한다. 수익자 슬롯은 표 7에서 포함된 밑줄친 대명사에 의해 간략하게 설명된다.

표 7: 수익자 슬롯

Open me a new file.

Play her some tunes

수익자 제한(다른 실시예에서, "슬롯"에서)은 수익자로서 해석되는 명사구를 모델링하는 엔티티로 설정될 수 있다. 표 8은 수익자 제한의 코드 블록을 나타낸다.

표 8: 수익자 제한

restriction Beneficiary<benef :=Entity>

{

}

수익자 제한은 종종 "수익자격(benefactive)"으로서 불리며, 영어에서의 할 당, 특히, "for" 전치사구의 단일 목적어와 중복된다. 또한, 일부 중복이 다른 언어에서 발생할 수 있다. 프레임에 인가된 경우, 수익자 제한은 다음 문장에서 명확해진다.

I baked a cake for my mother

PP[for]

통상, 수익자 제한은 대부분은 언어에서 동작 인수를 모델링한다. 표 9는 몇몇 샘플 언어에서 수익자 제한을 나타낸다.

표 9: 수익자 제한

영어:

전치사 For

목표가 아닌 간접 목적어에 적용("to" 전치사구에 의해 바꾸어 쓸 수 없음)

I baked her a cake -> I baked a cake for her

NOT: I gave her a book (cf. I gave a book to her, cf. Goal)

I baked a cake for her.

I baked her a cake.

프랑스어

전치사 pour

독일어

간접 목적어:

Ich schicke ihr eine Nachricht.

전치사 fur

Das ist eine Nachricht fur sie.

일본어

NP- NP

NP- ...VP

영어 bake a cake [for her to have]에 상당한, 고정적인 절(작은 절) 구문의 주어. 이에 반해, 예를 들어, 목표 인수를 취하는 동사는 give her-DAT book-ACC인 여격 불변화사(dative particle)를 사용하여 이를 표시

스페인어

전치사 para

Trajimos la lista de regalos para Fernado.

통상, 제한은 주어, 직접 목적어, 간접 목적어, 사격 인수, 수식어구 등일 수 있다. SPL에서, 프레임은 (후술하는 예외를 갖는)임의의 제한을 취할 수 있다. 그러나, LOM은 두 방향으로 제한을 선호하는 문법을 사용한다. 첫째, 사격 인수는 어휘 의미 구조 클래스에 관련된 제한 유형일 수 있으며, 이의 동사는 멤버이다(이는 보다 상세히 후술한다). 둘째, 사격 인수는 개별 동사에 특이하게 관련될 수 있다; 즉, 인수는 절의 어두어에서 임의의 제한을 포함하지 않는다. 인수는 (후술하는)디폴트 제한에 할당되어, 이들의 어휘 어두어에 의해 식별된다.

프레임의 좌표는 문맥에 따라 두가지 상이한 방식으로 행해진다. "탑 레벨" 좌표 프레임(즉, 매트릭스 동사로부터 기인한 것)은 (후술하는)CoorinatedEntity에 평행한 CoordinatedFrame 유형의 객체로서 표현된다. 일 예는 아래 표 10에 도시되어 있다.

표 10: CoordinatedFrame

frame CoordinatedFrame

{

Frame frame[];

CooRelation relBetweenFrames;

}

통상, 엔티티에서 ("with" 구문을 통해)나타나는 프레임은 제한으로서 동작한다. 후술하는 바와 같이, 이는 논리곱이 다수의 제한을 트리거하면서 논리합이 호스트 엔티티를 CoordinatedEntity로 증가시켜 표현됨을 의미한다.

상술한 바와 같이, 일 실시예에서, 프레임은 엔티티에 대한 제한으로서 자연어 상대 절을 모델링하는 역할을 할 수 있다. 프레임이 "with" 키워드를 통해 엔티티에 부착되는 경우, 프레임은 "프레임 기반 제한"으로서 불리는 엔티티에 제한을 부과한다. 많은 경우, 프레임 내의 하나의 슬롯은 어두어 명사에 의해 한정된 자연어 갭에 대응한다. LOM에서, 이는 슬롯 중 하나에서 호스트 엔티티에 대한 참조를 수신하는 프레임 기반 제한으로 번역한다. 프레임 기반 제한의 슬롯에서 호스트 엔티티에 대한 참조의 포함은 "후행참조(backreference)"로서 불릴 수 있다. 이러한 "후행참조"는 다르게는 트리형 LOM 표현으로의 재진입을 가능하기 하기 때문에, 갭에 대응하는 슬롯이 이의 isBackreference 플래그가 참으로 설정되게 한다. (이 플래그는 LOM 표현에 진행하는 프로세스에 편리하다.) 예를 들면, 아래 표 11에서, 프레임 기반 제한은 어구 "files that Billy opened yesterday"에 대하여 분석된다.

표 11: 프레임 기반 제한

Entity₁ (file)

|

open<Entity₂(Billy), {isBackreference}

Entity₁(file)>

Time([1 day back] OFFSET FROM [now])

표 12에서, 프레임 기반 제한은 어구 "people who work at Company"에 대하여 분석된다.

표 12: 프레임 기반 제한

Entity₁(people)

|

work< {isBackreference} Entity₁(people) >

|

Location< Entity₂(Company) >

표 13에서, 프레임 기반 제한은 어구 "people I have sent mail to"에 대하여 분석된다.

표 13: 프레임 기반 제한

Entity₁(people)

|

send< PronounEntity₂(1st_pers, sing), Entity₃(mail)>

|

Goal{isBackreference} Entity₁(people) >

프레임 기반 제한에 의해 도입된 재진입은 SPL의 분석 프로세스를 어렵게 한다는 점을 주목하는 것이 중요하다. 특히, 엔티티는 이의 모든 제한이 완전히 처리될 때가지 완전히 분석되지 않는다(이에 따라, SPL에서 기술적으로 "존재"하지 않는다). 그러나, 엔티티 제한 중 하나는 그 슬롯 중 하나에서 엔티티 자체를 취하는 프레임일 수 있다. 따라서, 엔티티 객체가 프레임을 정의하는 코드에 의해 점검될 필요가 있는 상황이 발생하지만, 엔티티는 프레임의 분석이 종료한 후 몇 포인트 까지 미정의 상태에 남게 된다. 이러한 문제는 단락 E.4에서 보다 상세하게 설명한다.

다른 실시예에서, 프레임은 슬롯을 갖지 않지만, 그 대신 상술한 바와 같은 "Doer" 및 "DoneTo"를 사용한다. 이러한 경우, 새로운 제한이 프레임에 기초하여 정의될 수 있으며, "Doer" 및 "DoneTo"에 대한 제한 절은 새로운 제한에 적용될 수 있다. 따라서, 제한은 프레임 인수를 처리하는 다른 방식을 제공한다. 다음 설명에서, 간이함을 위해서, 단지 하나의 이러한 구현예에 대하여만 참조할 수 있지만, 어느 구현이든 적용가능하다.

c. LOM 제한

엔티티 및 프레임과 달리, 제한 좌표는 CoordinatedEntity와 CoordinatedFrame과 같은 "복합" 유형의 사용을 통해 표현되지는 않는다. 그 대신, SPL의 의미는 제한 논리곱을 나타내도록 이용되고, 제한 논리합은 엔티티 또는 프레임 논리합으로 감소된다.

SPL은 논리곱 또는 교차 의미를 두개의 제한 절에 성공적으로 할당하여 동일 호스트 상에서 순차적으로 트리거하며, 이에 따라, 제한을 가진 채 모델링된 재료의 언어학적 논리곱은 시퀀스 내의 둘 이상의 제한을 단순 트리거함으로써 처리된다. 반면에, 제한을 가진채 모델링된 재료의 언어학적 논리합은 SPL 의미의 편리한 대응부분을 갖지 않는다. 그 후, 이러한 논리합은 제한 상부의 다음 엔티티 또는 프레임(통상 호스트)에 "부풀고(bubble up)", 이 레벨에서 CoordinatedEntity 또는 CoordinatedFrame 객체를 야기한다.

예를 들면, "mail from Kim or to Robin"라는 어구에 있어서, 하나의 엔티티 호스트 "Entity(mail)"와 두개의 제한 "Source(Entity(Kim))"과 "Goal(Entity(Robin))이 있다. 두개의 제한은 논리합 "or" 로 조정되기 때문에, 논리합은 호스트 "Entity(mail)"에 버블 업(bubble up)되어 표 14에 나타낸 매핑이 된다.

표 14: 제한 좌표

CoordinatedEntity([Entity(mail), Entity(mail)],

| |

Source(Entity(Kim))

Goal(Entity(Robin))

Or

)

이 코드는 Entity(mail)의 두개의 복사본을 생성한다.

대동 제한(accompaniment restriction)은 몇몇 그룹에서 추가 멤버 또는 멤버들을 모델링한다. 종종, 대동은 논리곱에 의해 바뀌어 쓰일 수 있다. 예를 들면, 생일과 함께 고객이라는 어구는 고객 및 생일이라는 어구로 바뀌어 쓰일 수 있다. 상호 이벤트 의미 엔티티(reciprocal-event-denoting entities)에 있어서, 대동 제한은 이벤트에서 추가 구성원을 모델링한다. 종종, 이러한 명사류는 대응 프레임을 갖는다(예를 들면, correspond, meet, chat 등). 또한, 대동 제한은 with my manager의 연락처, with Kim과의 약속, with Tim (추가된 강조) 만남, with Sue와 대화 등의 명사구에서 전치사구를 모델링한다. 본 발명의 일 실시예에 따른 대동 제한의 구문의 예가 표 15에 도시되어 있다.

표 15: 대동

restriction Accompaniment<accomp:=Entity>

{

}

또한, 대동 제한은 프레임의 문맥에서 누가 또는 무엇이 참가하는지를 추가적으로 모델링할 수 있다. 예를 들면, "chat with Robin"이라는 어구는 대동 제한으로서 "with Robin"라는 어구로 "Chat" 프레임을 호출한다.

또한, 대동 제한은 호스트를 동반하는 것으로 해석되는 명사구를 모델링하는 엔티티 내의 슬롯에 할당될 수 있다. 다르게는, 대동 제한은 "who" 또는 "what" 슬롯에 설정될 수 있다.

몇몇 경우, 엔티티 리스트로서 "with"의 경우의 리스트를 컴파일하는 것이 바람직할 수 있으며, 논리곱과 의미론적으로 등가이다. 등가 대동 표현이 다른 언어에 존재할 한도에서, 필요시 표면에 대한 엔티티 리스트를 컴파일하는 것이 유용할 수 있다.

대동으로서 모델링될 수 있는 소유격에 있어서, 엔티티 리스트에서 이들을 포함하는 것이 바람직할 수 있다. 예를 들면, "email with attachment"는 소유격 스타일 소유인 "email's attachment"와는 달리 대동형의 소유이다. 몇몇 경우, 언어학적으로 상보형으로서 처리될 수 있다. 또한, "an email that has attachment"와 같은 어구는 대동 제한으로서 모델링될 수 있다.

주어 상호관계(subject reciprocal)는 대동 제한으로 폴딩될 수 있다. 주어 상호관계의 예는 "John and Mary chatted"에 비교하여 "John chatted with Mary"이다. 어휘적으로, 이들 두개의 표현은 용이하게 식별된다. 유사하게, "Merge File A with File B"에 대한 "Merge File A and File B"와 같은 목적어 상호관계는 용이 하게 식별가능하다. 이러한 주어와 목적어 상호관계는 LOM에서의 대동 표준화(accompaniment normalization)로 포함하는 것이 바람직하다.

대동 제한은 특히 "along with" 또는 "together with"와 같은 전치사구에 대하여 많은 언어에 확장한다. 프랑스어, 독일어, 일본어, 스페인어, 및 다른 언어에서, 유사한 대동 제한이 사용될 수 있다. 표 16은 이러한 대동을 나타낸다.

표 16: 대동 제한

(along|together) PP[with] (English)

((tout)ensemble) PP[avec] (French)

PP[mit] + Dative (German)

"Er kommt mit den Kindern."

Entity Hosts: (Japanese)

NP- NP

NP- NP

Frame hosts: (Japanese)

NP- ... VP

NP- ... ... VP

PP[con] (Spanish)

통상, 표 17에 나타낸 바와 같은 할당 제한은 호스트 엔티티가 분포된 엔티티를 모델링하며 호스트 엔티티에 대체하여 생성되거나 존재하는 엔티티를 모델링한다.

표 17: 할당 제한

restriction Allocation<alloc :=Entity>

{

}

호스트 엔티티가 분포되는 엔티티를 할당 제한이 모델링하는 경우, 제한과 같은 예는 "online profile for each fund", "schools for linguistics" 또는 "application for a job"과 같을 수 있다. 밑줄 친 부분은 할당 제한을 나타낸다. 할당 제한이 호스트 엔티티에 대신하여 존재하거나 생성된 엔티티를 모델링하는 경우, 의미 발화는 "a cake for my mother" 또는 "party for my manager"일 수 있다. 두 경우 모두, 할당 제한은 구체성을 엔티티에 부가한다. 표 16은 할당 제한의 일 실시예에 대한 코드를 나타낸다. 할당 제한은 슬롯을 사용하는 호스트에 할당된 것으로서 해석되는 명사구를 모델링하는 엔티티에 설정될 수 있다.

통상, 할당 제한은 복수의 엔티티뿐만 아니라 단수로의 할당에 적용할 수 있다. 할당 제한은 영어의 수익자를 구비한 상보성 분포에 있다. 단지 엔티티는 할당을 호스트한다. 프레임만이 for 전치사구의 단수 목적어 상에서 수익자를 호스트한다. 영어에서, 이러한 전치사는 여러 방식으로 사용될 수 있다. 예를 들면, 패킷에서 for a specific destination은 목적을 나타내지만, 응용 프로그램에서 for which you are enabling authorization checking은 할당 유형이다. 유사하게, for taskpad views 탭, for the type of service 체크박스, 및 for Madison, WI 지역 코드는 모두 할당 제한을 나타낸다. 독일어에서, 특히, fur는 할당을 나타낸 다. 스페인어에서, 대응하는 전치사는 para이다: 어구 "una escoba para la cocina"는 할당 제한을 나타낸다.

프레임 상의 "AsBeing" 제한은 프레임의 객체 슬롯에 할당된 속성 또는 능력을 모델링한다. 단지 형용사구를 모델링하는 수식언구 제한만이 제한 버전에 매핑된다. 표 18은 AsBeing 제한의 두가지 코드 샘플을 제공한다.

표 18: AsBeing 제한

restriction AsBeing<asbeing :=Entity>

{

}

restriction AsBeing<asbeing :=Modifier>

{

}

통상, LOM 모델은 발화의 표제어 간의 의미 관계를 모델링한다. "AsBeing" 제한은 "as" 전치사구의 모델링을 시도한다. 예를 들면, "Save the file as a text file"이라는 구는 "Save the file to a text file"과 유사하다. "Set my status as busy"는 "Save the file to busy"와 유사하다. AsBeing 제한은 프레임의 객체 슬롯에 할당된 속성 또는 능력을 모델링한다. 여기서, AsBeing 제한은 제한 "as"를 "text file"에 모델링하며, 이는 프레임의 객체 슬롯에 할당된 속성이 된다. 다르게는, 이러한 기능을 Entity가 아닌 Denoter에 적용할 수 있다. 표 19는 영어, 독일어, 일본어 및 스페인어에서 AsBeing 객체의 일 예를 나타낸다.

표 19: AsBeing 예

영어

PP[as]: Save the file as text.

Make me an administrator

Mark all messages unread.

독일어

PP[als]: Speicher die Datei als Text.

일본어

- to complementizers

- to site adverbials

스페인어

PP[for]: para

기수 제한(cardinal restriction)은 수량사로 표현된 기수를 모델링하는 것이다. 슬롯 및 필드는 수량사의 부동소수점 값으로 설정될 수 있다. "an"과 "a"와 같은 부정 관사는 몇몇 경우 "one"으로서 모델링될 수 있다. 표 20은 기수 제한을 나타낸다.

표 20: 기수 제한

Restriction Cardinal

{

float number;

}

또한, 시간 단위에서 몇몇 경우 기수를 블록하는 것이 바람직할 수 있다("3시간 내에" 등). 특히, 시간 단위에 있어서, 기수 제한은 시간량의 도입이 통상 "in 3 hours" 또는 "for 3 minutes" 등과 같은 전치사구를 요구하기 때문에 시간형 객체(적어도 영어로)와 충돌하지 않아야 한다. 표 21은 기수 제한에 매핑될 수 있는 몇몇 예시적인 표현을 나타낸다.

표 22: 기수 제한을 나타내는 예시적인 표현

영어

3 cats

ninety dollars

2.5 kilos

프랑스어

3 chats

cinq francs

2,5 kilos

독일어

3 Mails

funf Euros

2,5 Kilos

일본어

2.5

...

스페인어

3 gatos

다른 유형의 제한, "비교"는 하나의 엔티티를 다른 명시적으로 식별된 엔티티와의 비교를 모델링한다. 비교 제한에 대한 구문이 표 23에 도시되어 있다.

표 23: 비교 제한

Restriction Comparison<dimension:=Modifier, refpoint:=Entity>

{

}

비교 제한은 비교하는 엔티티 중 하나가 명시적으로 참조되지 않은 경우와 같이 묵시적 비교에 사용되지는 않는다. 예를 들면, "a bigger file"은 비교 제한을 호출하지 않는 묵시적 호출을 제안한다.

비교 제한은 차원 슬롯에 적용될 수 있으며, 차원은 형용사구를 모델링하는 수식어구 제한에 설정된다. 이러한 수식어구 제한은 예를 들면 "more", "less" 또는 "same"에 설정된 정도(degree) 필드를 갖는 "degree" 제한을 통상 가질 수 있다. "refpoint" 필드는 엔티티에 설정되어 호스트 엔티티에 비교된다.

구체적인 구현예에 따라, 비교 클래스를 명시적으로 지정하는 최상급은 특별 한 주의를 요할 수 있다. 예를 들면, tallest girl이라는 구는 비교를 위한 refpoint로서 class가 호출될 수 있게 하며, 또는 다르게는 class는 girl의 위치로서 호출될 수 있다. 또한, 여러 다른 최상급 표현이 특별한 주의를 요구할 수 있다. 예를 들면, my daughter is tall for her age라는 구와 이에 등가인 스페인어 mi hija es alta para su edad는 LOM의 관점에서 유사한 문제를 제공한다.

표 24는 비교 제한에 의해 모델링될 수 있는 몇몇 예시적인 표현을 제공한다.

표 24: 비교 제한에 의해 모델링되는 예시적인 표현

영어

a file bigger than mydoc.txt

documents that are less relevant than mydoc.txt

watches as expensive as the Rolex X-55J

프랑스어

des livres plus chers que ce livre

독일어

PP[als]

Eine Datei, die kleiner ist als mydoc.txt

[ebenso/genauso/so/ [AJP] wie]

Die Datei ist genauso gross wie mydoc.txt

일본어

mydoc.txt

X-55J

스페인어

un archivo mas grande que mydoc.txt

조건부 제한은 발화 내에 표현된 조건을 모델링한다. 표 25는 조건부 제한 구문을 나타낸다.

표 25: 조건부 제한

restriction Conditional<condition:=Frame>

{

ConditionType type;

}

이전 예와 같이, 조건부 제한은 (무엇보다)영어, 프랑스어, 독일어, 일본어 및 스페인어 등의 대부분의 언어로 모델링될 수 있다.

기준 제한은 임의의 특정 구성 클래스를 모델링하지 않지만, 다른 LOM 객체에 의해 아직 요구되지 않은 하부 언어 분석의 부분에 대한 인터페이스를 제공한다. 표 26은 본 발명의 하나의 가능한 구현예에 대한 기준 제한 구문의 일 예를 제공한다.

표 26: 디폴트 제한

Restriction Default

{

LinguisticAnalysis analysis;

}

기준 제한의 다른 가능한 변형은 단일 엔티티를 슬롯으로서 취하는 것이다. 기준 제한의 이러한 변형은 단일 엔티티와 제한을 호스팅하는 객체 간의 임의의 관계를 가능하게 한다.

통상 제한은 이에 관련된 패턴을 가질 수 있는 것이 중요하다. 이러한 패턴 결합은 LOM 소비자가 LOM 생산자(분석 엔진)와 식별할 언어학적 구성 대상에 대하여 통신하게 할 수 있다. 단순 예는 문자열 기반 패턴일 수 있다. 예를 들면, 소스 제한 사용은 ["due to + X]의 패턴을 구비하여 분석 엔진(LOM 생산자)이 이 패턴을 소스 제한에 매핑하게 보장한다. 패턴 결합을 언어 분석에 적용함으로써, 프로그래머(작성자)는 사용자 입력 상으로 하부 레벨 추론을 하도록 선택할 수 있다. 다른 LOM 유형과 달리, 디폴트 제한에 부과된 교차 언어학적 표준화가 없다.

구현예에 따라, 전체 파싱 결과에서 단순 문자열에 노출할 수 있는 단일 인터페이스(예를 들면, "ILinguisticAnalysis")를 정의하는 것이 중요하다. 통상, 패턴은 발화의 일부가 ILinguisticAnalysis를 통해 노출될 수 있는 상이한 방식에 대응할 수 있다. 바람직한 실시예에서, 분석 엔진의 각 종류에 대하여 하나씩 기준 제한 범위에 있다.

정도 제한은 형용사구를 모델링하는 수식어구 제한에만 부착된다. 표 27은 정도 제한 및 DegreeType 열거에 대한 구문을 나타낸다.

표 27: 정도 제한

restriction Degree

{

DegreeType degree;

}

enum DegreeType

{

More,

Most,

Less,

Least,

Same,

High,

Low

}

그 후, DegreeType 열거의 값은 형용사구의 의미에 대한 여러 가능한 자격을 나타낸다. 정도 필드는 적절한 값으로 설정된다.

몇몇 경우, 절 부정(clausal negation)과 하이타입(high-type) 부사를 동시에 검색하여 DegreeType의 적은 값을 인식하는 것이 바람직하다. 예를 들면, "not very big"이라는 표현은 부정(not) 및 부사(very)를 통해 표현된 DegreeType의 적은 값은 나타낸다. 부정의 무시는 발화의 부정확한 해석을 야기할 수 있다. 표 28은 정도 제한을 사용하여 모델링될 수 있는 몇몇 예시적인 어구를 나타낸다.

표 28: 정도 제한을 암시하는 어구 예

영어

More: bigger, more relevant

Most: biggest, most relevant

Less: less relevant

smaller는 "less big"이 아닌 "more small"로 모델링된다. LOM은 스칼라 반의어의 임의의 의미를 모델링하지는 않는다.

Least: least relevant

Same: as big

High: very big, extremely popular

Low: not very big

독일어

More: großer, relevanter, mehr relevant

Most: großte/n, am Relevantesten

Less: weniger relevant, weniger wichtig

Least: wenigßte/n

Same: genauso/ebenso relevant

High: sehr klein, extrem dick

Low: nicht sehr dick

다른 정도 유형이 영어와 독일어에 존재하며 이러한 제한 유형은 또한 대부분의 언어에 존재함을 당업자는 이해할 것이다. 정도 제한은 거의 임의의 언어를 사용하여 접근할 수 있다.

방향 제한은 공간 위치의 방향 또는 움직임 방향을 모델링한다. 표 29는 방향 제한 및 관련 열거 예를 제공한다.

표 29: 방향 제한 및 관련 열거

restriction Direction<lanmark:=Entity>

{

DirType myDirType;

OtherDirectionType other;

}

enum DirType

{

Up,

Down,

Backward,

Forward

Around,

In,

Out,

Other

}

슬롯의 방향 유형("DirType")은 적절한 열거 값으로 설정될 수 있다. 몇몇 경우, 다른 열거 값이 바람직할 수 있다. 예를 들면, 명령 "turn"은 규정되지 않은 방향을 갖지만, "turn"은 인수로서 방향을 예측하는 것으로 나타낸다. 따라서, 이 구현예에 따라 다른 것과 이러한 표현을 구분하기 위해서 "비규정(Unspecified)"에 대한 열거 값을 제공하는 것이 바람직할 수 있다. 동사 합성 값은 어휘 엔트리 상의 새로운 객체 표현으로서 저장될 수 있다. 또한, 방향 제한은 첨부 사이트와 독립하여 방향 대상(전치사구) 및 방향 부사를 포함한다. 표 30은 방향 제한에 의해 모델링될 수 있는 어구의 몇몇 예를 제공한다.

표 30: 방향 제한에 의해 모델링되는 어구 예

영어

up (up, raise, elevate, increase)

down (down, lower, decrease, plummet)

forward (advance, proceed)

backward (back, backward, retreat, recede, retract)

around (rotate)

in (insert)

out (extract)

other (diagonal, left, turn)

독일어

up (hoch, anheben, erhohen)

down (runter, senken)

forward (vorwarts, nach vorn)

backward (ruckwarts, zuruck)

around (drehen, rotieren)

in (einfugen)

out (extrahieren)

당업자는 다른 방향 제한 유형이 영어 및 독일어에 존재하며, 이러한 제한 유형은 또한 대부분의 언어에 존재함을 이해할 것이다.

제한 예는 엔티티형의 원형, 프레임 또는 제한을 모델링한다. 표 31은 이러한 제한 유형의 예 각각에 대한 구문을 나타낸다.

표 31: 제한 예

restriction Example <example:=Entity>

{

}

restriction Example <example:=Frame>

{

}

restriction Example <example:=Restriction>

{

}

몇몇 구현예에서, 다음과 같은 구조체를 부착하는 SimilarTo 제한을 갖는 것이 바람직하다:

I want to find vendors, for example Volt.

I want to find vendors, Volt, for example.

다른 실시예에서, 원형이 일 예인 대상에 추가 슬롯을 제공하는 것이 바람직할 수 있다. 예를 들면, 어구 This program exemlifies solid coding techniques는 "solid coding techniques" 어구를 모델링하는 잉여 슬롯을 요구할 수 있다. 통상, 제한 예는 직유(simile)를 모델링하는 것으로 이해될 수 있다. 표 32는 제한 예에 의해 모델링될 수 있는 몇몇 구를 제공한다.

표 32: 제한 예에 의해 모델링되는 어구 예

영어

"like"

Show me cars like the Honda

Which CEO dances like a monkey?

What does a butterfly look like?

"as"

"such as"

독일어

wie

스페인어

como

당업자는, 다른 제한 예의 유형이 영어, 독일어, 스페인어에 존재하며, 이러한 제한 유형은 또한 대부분의 다른 언어에도 존재함을 이해할 것이다. 이 제한 예는 거의 임의의 언어를 사용하여 액세스될 수 있다.

범위 제한(extent restriction)은 공간상 몇몇 범위 개념이 측정되는 것에 대한 엔티티를 모델링한다. 표 33은 범위 제한의 구문을 나타낸다.

표 33: 범위 제한

restriction Extent<extent:=Entity>

{

}

통상, 슬롯의 범위 필드는 범위 측정을 모델링하는 엔티티에 설정된다. 일 실시예에서, 범위 전시차구의 목적어는 발화 내의 부착 사이트와 독립적이다. 표 34는 범위 제한에 의해 모델링될 수 있는 영어와 스페인어 용어의 일 예를 제공한다.

표 34: 범위 제한에 의해 모델링되는 어구 예

영어

along

스페인어

por

Mi hermana va por la calle San Juan.

목적 제한은 엔티티 또는 프레임에 대하여 (형태학 또는 물리적)움직임의 목적 또는 상태 변화의 마지막 상태를 모델링한다. 표 35는 본 발명의 일 실시예에 따른 목적 제한의 구문을 나타낸다.

표 35: 목적 제한

restriction Goal<goal:=Entity>

{

}

목적 제한은 하나 이상의 열거 값에 관련될 수 있다. (상기 표 29에서 정의된)"DirType" 필드는 예를 들면 목적 제한의 열거 값일 수 있고, 이는 적절한 열거값에 설정될 수 있으며, 표 36은 목적 제한에 의해 모델링될 수 있는 몇몇 어구를 나타낸다.

표 36: 목적 제한에 의해 모델링되는 어구 예

영어

to

프랑스어

a

독일어

fur

일본어

-NP

스페인어

para

Hay vuelos para La Paz todas las semanas.

당업자는 다른 목적 제한 유형이 대부분의 언어에 존재함을 이해할 것이다. 목적 제한은 대부분의 언어를 사용하여 액세스될 수 있다.

반복 제한 모델은 동작의 반복을 모델링한다. 표 37은 반복 제한의 구문을 나타낸다.

표 37: 반복 제한

restriction Iteration

{

IterationType type;

float times;

}

enum IterationType

{

Count,

Never,

Rarely,

Sometimes,

Often,

Always

}

일 실시예에서, 반복 제한은 시간 제한의 반복(recurrence) 필드에 포함될 수 있다. 통상, 카운트형의 필드는 동작이 수회(예를 들어, [무엇을] 5회 실시) 반복함을 알린다. 유형이 이 값을 갖는 경우, "횟수" 필드는 반복 횟수를 갖는다. 유형이 다른 값을 갖는 경우, 유형은 특정 개수의 반복을 나타내지 않은 수식어구를 모델링한다. 따라서, 유형이 카운트에 설정되지 않은 경우, 반복 개수를 보유하며, 그렇지 않은 경우, 유형은 무시된다. 표 38는 반복 제한에 의해 모델링될 수 있는 몇몇 용어 및 어구를 제공한다.

표 38: 반복 제한에 의해 모델링되는 어구 예

영어

5 times

never

sometimes

frequently

seldom

프랑스어

5 fois

jamais

souvent

rarement

독일어

5 Mal

nie, niemals

manchmal, ab und zu

oft

selten

일본어

5

스페인어

5 veces

nunca

algunas veces, de vez en cuando

con frecuencia, frecuantemente

raramente

당업자는 다른 반복 제한 유형이 대부분의 언어에 존재함을 이해할 것이다. 반복 제한은 대부분의 언어를 사용하여 액세스될 수 있다.

위치 제한은 물리적 또는 형태학적 위치를 모델링한다. 표 39는 위치 제한의 구문을 나타낸다.

표 39: 위치 제한

restriction Location<loc:=Entity>

{

}

표 40은 위치 제한에 의해 모델링될 수 있는 용어 및/또는 어구를 나타낸다.

표 40: 위치 제한에 의해 모델링되는 예시적인 어구/용어

영어

at

프랑스어

a

독일어

in/bei +Dative

Er ist in der Stadt.

Er ist bei Hamburg.

일본어

NP-

당업자는 다른 위치 제한 유형이 대부분의 언어에 존재함을 이해할 것이다. 위치 제한은 대부분의 언어를 사용하여 액세스될 수 있다.

수단 제한 모델은 엔티티 또는 프레임에 대한 것을 달성하는 수단 또는 장치를 모델링한다. 수단 제한의 구문이 표 41에 나타낸다.

표 41: 수단 제한

restriction Means<means:=Entity>

{

}

restriction Means<means:=Frame>

{

}

당업자는 다른 수단 제한 유형이 대부분의 언어에서 존재함을 이해할 것이다. 수단 제한은 대부분의 언어를 사용하여 액세스될 수 있다. 수단 제한을 사용하여 모델링될 수 있는 예시적인 용어/어구가 표 42에 도시되어 있다.

표 42: 수단 제한에 의해 모델링되는 용어/어구 예

영어

with a knife

employing a knife

use a spreadsheet program

by arriving early

프랑스어

PP[avec]

독일어

PP[mit]

Er schneidt mit dem Messer

benutzen, gebrauchen

SUBCL[indem]

Er gewinnt, indem er schnell rennt

일본어

NP-

NP-

VP-

측정 제한은 프레임 또는 엔티티에 대한 대상의 무게 또는 측정을 모델링한다. 표 43은 본 발명의 일 실시예에 따른 측정 제한의 구문을 나타낸다.

표 43: 측정 제한

restriction Measure<measure:=Entity>

{

}

restriction Measure<measure:=Frame>

{

}

당업자는 다른 측정 제한 유형이 다양한 언어에 존재함을 이해할 것이다. 측정 제한은 대부분의 언어를 사용하여 액세스될 수 있다. 표 44는 측정 제한에 의해 모델링될 수 있는 예시적인 용어/어구를 나타낸다.

표 44: 측정 제한에 의해 모델링되는 용어/어구 예

영어

무게: three pounds

돈: $4, fifty yen

거리: 3 yards

시간: all day

프랑스어

무게: deux kilogrammes

돈: un franc

거리: cinq kilometres

시간: toutela journee

독일어

무게: drei Kilo

돈: 4DM

거리: 3 Meter

시간: den ganzen Tag

수식어구 제한은 언어적 표현의 구문적으로 일치된 클래스를 모델링하지 않는다는 점에서 '캐치콜(catchcall)" ("쓰레기 더미(garbage dump)")로 간주될 수 있다. 그 대신, "부속물(adjuncthood)"의 구문 개념을 캡처한다. 통상, 수식어구 제한은 엔티티, 프레임 또는 제한에 대하여 형용사구, 명사구 또는 부사구를 모델 링할 수 있다. 일 구현예에서, 수식어구 슬롯은 모델링되는 구문 어구의 어두어로부터 구성된 표시자 객체로 단순 설정된다. 그러나, 이러한 구현예는 LOM을 사용하기 위해 반드시 필요한 것은 아니다. 표 45는 본 발명의 일 실시예에 따라 수식어구 제한의 구문을 나타낸다.

표 45: 수식어구 제한

restriction Modifier<mod:=Denoter>

{

}

통상, 수식어구 제한은 임의의 문맥에서 언어적 수식어구의 일부 클래스를 모델링한다. 임의의 언어적 수식어구가 하나의 수식어구 될 수 있지만, 수식어구 제한은 언어적 수식어구의 단지 부분집합의 주요 LOM 표현으로서 의도된다. 부분집합은 대부분 또는 모든 형용사구, 대부분 또는 모든 명사구 수식어구 및 일부 부사구를 포함한다. 많은 부사구, 주요 예 중 하나로서 시간 표현은, 다른 보다 구체적인 제한으로 주요 LOM 표현을 발견한다.

수식어구 제한은 이의 슬롯이 엔티티, 프레임 또는 제한보다 표시자 객체를 포함한다는 점에서 통상적이지 않다. 표시자 객체열은 수식어구의 어두어이다. 이러한 구성의 이유는, 언어적 수식어구가 이들 호스트(변형할 구성성분) 상에 구문적으로 단일 장소 기능어이므로, 프레임에 유사하고, 실제, 제한으로서 거의 배타적으로 사용된다. 또한, 언어적 수식어구는 프레임이 나타나는 다른 경우에는 거의 있지 않다. 각각의 원하는 변형자 클래스에 대하여 성가신 프레임 기반의 제 한 구문(MyLargeFrame<this>)의 라인에 따른 것)과 프레임형의 정의 대신, 수식어구 클래스에 대한 표시자 객체만을 규정하고 (제한이 부착한 호스트 객체 등)묵시적 제한 인수를 구문 인수로서 취할 수 있는 것이 충분하다.

관계절 내의 선언 형용사는 동일 형용사의 대응하는 한정적 사용과 동일한 방식으로 나타낸다. 따라서, "a large file"과 "a file that is large"는 모두 수식어구<large>가 된다.

이러한 용어사의 처리는 동사로부터 구문적으로 구별할 수 없게 동작하는 JAPANESE 등의 일부 언어에 대하여 적합하지 않을 수 있다. 명사는 교차 언어학적으로 매우 유사하지만, 명사는 SPL 엔티티에 매핑된다. 동사도 교차 언어학적으로 유사하지만, 동사는 SPL 프레임에 매핑된다. 그 후, 형용사는 명사와 동사 사이의 어느 사이에 있으며, 형용사는 교차 언어학적으로 유사하지 않다.

언어는 연속으로 존재하는 것으로 간주될 수 있다. 연속의 일단에서, 형용사는 실제 한국어에서와 같이 동사와 개별 어휘 카테고리가 아니다. 이 경우, 형용사는 단지 상태 동사, 자동사이다. 일본어는 이점에서, (형태학적으로 상이하더라도)형용사가 구문적으로 동사와 같이 동작하여, 한국어와 유사하다. 영어와 라틴어 어근에서 유도된 언어(유럽어)는 형용사를 동사와 상이한 카테고리로 취급한다. 스펙트럼의 타단에서, 아랍어 등의 언어는 특정 클래스의 명사로서 형용사를 취급한다. "red"라는 단어보다는, 아랍어는 "a red one"과 같은 의미의 명사를 사용하므로, 어구 "the book is red"는 "the book is a-red-one"이 된다.

몇몇 실시예에서, 매트릭스 절에서 선언형 형용사에 대한 표현이 있을 수 있다. 예를 들면, "this file is personal"이라는 어구는 "this file is text"와는 달리 처리될 수 있다.

또한, 다른 수식어구 제한 유형이 다양한 언어에 존재할 수 있음이 이해될 것이다. 수식어구 제한은 대부분의 언어를 사용하여 액세스될 수 있다.

네임드(Named) 제한은 호스트 엔티티의 표시자 객체로의 액세스를 제공한다. 이는 (예를 들면, MyAlias 및 DL_MyAlias) 작성자가 상이한 두개의 제한에 대하여 코딩할 필요없이 단일 DLEntity에 일반화될 수 있게 한다. 표 46은 본 발명에 일 실시예에 따른 네임드 제한의 구문을 나타낸다.

표 46: 네임드 제한

restriction Named<named:=Denoter>

{

}

restriction Named<named:=NamedEntity>

{

}

restriction Named<named:=String>

{

}

통상, 네임드 제한은 명사 어구명 또는 호스트 엔티티의 표시자 객체로 설정된다. 몇몇 실시예에서, 네임드 제한은 네임드 엔티티 속성으로의 몇몇 액세스를 제공하 는데 사용될 수 있다. 다른 실시예에서, 네임드 제한은 수식어구 제한으로 병합된다. 통상, 네임드 제한은 필요시 이미 존재하는 정보(호스트 엔티티의 표시자 객체 등)를 제공할 수 있다.

다른 네임드 제한 유형이 여러 언어에서 존재할 수 있음을 당업자는 이해할 것이다. 네임드 제한은 대부분의 언어를 사용하여 액세스될 수 있다.

부정 제한은 구문 부정 또는 논리 NOT을 모델링한다. 표 47은 본 발명의 일 실시예에 따른 부정 제한에 대한 구문의 일 예를 나타낸다.

표 47: 부정 제한

restriction Negation

{

}

몇몇 실시예에서, 부정 제한은 개별 제한으로서 제공될 수 있다. 다른 실시예에서, 부정 제한은 "with Negation" 절 또는 "!"(Not 연산자)로 사용될 수 있다.

서수(ordinal) 제한은 시퀀스 내의 일부 위치 개념을 표현하는 서수와 다른 수식어구("이전" 등)를 모델링한다. 표 48은 본 발명의 일 실시예에 따른 서수 제한과 그 열거에 대한 구문을 나타낸다.

표 48: 서수 제한 및 열거

restriction Ordinal

{

int distance;

Reference refpoint;

}

enum ReferencePoint

{

First,

Last,

Current

}

통상, 거리 필드는 기준점으로부터 부호 정수 거리에 설정될 수 있다. 다르게는, 처음 호출되는 기준점 필드(refPoint)는 음이 아닌 거리를 나타내어야 한다. 제로(0)의 거리값은 첫번째를 모델링하고, 일(1)의 값은 두번째를 모델링하는 등이다. 마지막 기준점은 양이 아닌 거리를 가져야 한다. 제로(0)의 거리값은 마지막을 모델링하고, 마이너스 일(-1)의 값은 마지막에서 두번째의 것을 모델링하는 등이다. 현재 기준 값 거리는 임의의 정수값을 가질 수 있다. 제로(0)의 거리값은 "현재" 상태를 모델링하고, 일(1)의 값은 "다음"을 모델링하며, 마이너스 일(-1)의 값은 "이전"을 모델링하는 등이다.

표 49는 서수 제한에 의해 모델링될 수 있는 어구를 제공한다.

표 49: 서수 제한에 의해 모델링되는 어구 예

영어

first 4^th

last, next to last, 3^rd from the end

previous, current, next, two back, two ahead

프랑스어

premier, 4^e

dernier

독일어

erst, 4^te

letzte/r/s, vorletzte/r/s

nachste/r/s, zwei , zwei weiter

일본어

, 4

, 2

, , , 2 ,

스페인어

primero 4^O

last, next to last, 3^rd from the end

previo, , proximo, dos , dos mas

당업자는 다른 서수 제한 유형이 다양한 언어에서 존재함을 이해할 것이다. 서수 제한은 대부분의 언어를 사용하여 액세스될 수 있다.

소유 제한 모델은 특성, 속성 또는 소유를 모델링하며, 소유자 제한(후술함)에 대한 보어로서 동작한다. 표 50은 본 발명의 일 실시예에 따른 소유 제한에 관련된 구문을 나타낸다.

표 50: 소유 제한

Restriction Possessed<possessed:=Entity>

{

}

통상, 소유 제한은 특성, 속성 또는 소유를 모델링한다. 예를 들면, 어구 email with headers, schools with linguistic programs 등은 소유 제한에 의해 모델링될 수 있다. 몇몇 경우, 소유 제한은 속성, 특성, 또는 소유를 "갖는 것"으로서 불릴 수 있다. 표 51은 소유 제한을 사용하여 모델링될 수 있는 몇몇 예시적인 용어 및 어구를 제공한다.

표 51: 소유 제한에 의한 모델링된 어구/용어 예

영어

with

mail with "conference" in the subject line

document with size greater than 1k

of

files of greater size

독일어

RELCL

Mail, die "Treffen" in der

Betreffzeile hat

mit

Mail mit Anhang

당업자는 다른 소유 제한 유형이 다양한 언어에 존재함을 이해할 것이다. 소유 제한은 대부분의 언어를 사용하여 액세스될 수 있다.

소유자 제한은 소유 제한을 보충한다. 통상, 소유자 제한은 전체 명사구 또는 소유 대명사구에 의해 표현되는지에 관계없이 엔티티 소유자를 모델링한다. 표 52는 본 발명의 일 실시예에 따른 소유자 제한의 구문을 나타낸다.

표 52: 소유자 제한

restriction Possessor<possessor:=Entity>

{

}

표 53은 소유자 제한에 의해 모델링될 수 있는 예시적인 용어/어구를 제공한다.

표 53: 소유자 제한에 의해 모델링되는 용어/어구 예

영어

my, your, her, his, its, their

of mine, of yours, of hers, of his, of its, of theirs

(wheel) of the car

Kim's, the computer's

PP[of]'s의 몇몇 경우

프랑스어

mon, son, ta, sa, leur

de moi, de toi, de lui, d'eux

PP[de]'s의 몇몇 경우

독일어

mein, dein, sein, ihr, Ihr

PP[von]의 몇몇 경우

소유격의 몇몇 경우

일본어

, , ,

NP-의 몇몇 경우

당업자는 다른 소유자 제한 유형이 다양한 언어에서 존재함을 이해할 것이다. 소유자 제한은 대부분의 언어를 사용하여 액세스될 수 있다.

LOM에서 모델링되는 다른 제한은 목적 제한이다. 목적 제한은 프레임에 관련된 예측 출력을 모델링한다. 표 54는 목적 제한에 의해 모델링될 수 있는 몇몇 예시적인 어구/용어를 나타낸다.

표 54: 목적 제한에 의해 모델링되는 용어/어구

영어

for, in order to

프랑스어

pour, afin de; de sorte que; de sorte a; de facon a

독일어

um...zu

so dass

스페인어

para, para que, con objeto de, con el fin de

이유 제한은 프레임 또는 엔티티에 관련된 신뢰 또는 동작에 대한 합리적 동기를 모델링한다. 일 실시예에서, 이유 및 목적 제한은 그 범위가 중복될 수 있다. 표 55는 이유 제한에 의해 모델링될 수 있는 예시적인 어구/용어를 나타낸다.

표 55: 이유 제한에 의해 모델링되는 어구/용어

영어

because, in order to

프랑스어

parce que; a cause de; en raison de

독일어

fuer

weil

wegen

스페인어

por, porque, a causa de.

이유 제한 및 목적 제한은 모두 임의 개수의 언어로 모델링될 수 있다. 상술한 예시적인 용어/어구는 리스트의 단지 일 예이며, 제한에 의해 모델링될 수 있는 용어를 예시적하는 것이다.

정렬순서 제한은 데이터 정렬의 스타일 및/또는 방법을 나타내는 수식어구를 모델링한다. 표 56은 정렬순서 제한 및 이의 관련 열거 정렬형에 대한 구문을 나타낸다.

표 56: 정렬순서 제한

restriction SortOrder

{

OrderType type;

OrderCriteria criteria;

}

enum OrderType

{

Default,

Reverse,

Increasing,

Decreasng

}

enum OrderCriteria

{

Default

Alphabetic,

Numeric,

GoJuuOn,

Iroha

}

통상, 필드형은 기본, 역, 알파벳, 수치, 증가, 강소 등일 수 있다. 기본형은 기본 정렬, 임의의 정렬 등으로 모델링할 수 있다. 역 유형은 역정렬로 모델링한다(후행). 알파벳형은 알파벳으로 모델링한다(알파벳 정렬). 수치형은 수치적으로 모델링한다(수치 정렬). 증가형 모델은 증가 정렬로 모델링한다. 감소형은 감소 정렬로 모델링한다.

이 구현예에 따라, 정렬순서 제한은 "알파벳 리스트"와 같은 것에 대한 엔티티 상에 행해질 수 있다. 또한, "알파벳화", "카테고리", "그룹", "분류" 및 "인덱스"와 같은 동사는 정렬순서 제한에 의해 모델링될 수 있다. 어떤 경우, "역 알 파벳 정렬", "감소 알파벳 정렬" 등과 같은 어구를 모델링하는 두개의 필드를 포함하는 것이 바람직할 수 있다. 더욱이, 두개의 상이한 언어에 일반적인 상이한 정렬 순서가 있을 수 있다. 표 56에 리스트된 열거는 영어에 흔하지만, 일본어는 언어에 일반적인 추가 정렬 순서를 가질 수 있다. 표 57는 정렬순서 제한에 의해 모델링될 수 있는 예시적인 어구/용어를 나타낸다.

표 57: 정렬순서 제한에 의해 모델링되는 용어/어구

영어

in default order, in amy order

in reverse order, backwards

alphabetically, in alphabetic order

numerically, in numeric order

in increasing order

in decreasing order

프랑스어

dans l'ordre par defaut; dans n'importe quel ordre

par ordre inverse; en ordre inverse; dans l'ordre inverse

alphabetiquement, par ordre alphabetique numeriquement, par ordre numerique

par ordre croissant; par ordre ascendant;

par ordre decroissant; par ordre descendant

독일어 [Babel]

im Ruckstellung Auftrag, in irgendeinem Auftrag

im Ruckauftrag, ruckwarts

in der alphabetischen Reihenfolge, alphabetisch

im numerischen Auftrag, numerisch

in zunehmendem Auftrag

in abnehmender Reihenfolge

일본어

, default-no-order-de, favorite-order-ni 또는

, 또는 reverse-no-order-de reverse-ni

opposite-ni

또는

alphabet-order-ni ABC-order-ni

number-order-ni

또는

small-number-order-ni low-number-order-ni

또는

large-number-order-ni high-number-order-ni

스페인어

ordenados por defecto, en el orden por defecto, en cualquier orden

en orden inverso, al reves

en orden alfabetico, alfabeticamente

en orden numerico, numericamente

en orden asend(i)ente, de menor a mayor

en orden descend(i)ente, de mayor a menor

소스 제한은 객체의 소스 또는 원형을 모델링한다. 소스 제한에 대한 구문은 표 58에 나타낸다.

표 58: 소스 제한

restriction Source<src:=Entity>

{

}

통상, 당업자는 다양한 소스 제한 유형이 여러 언어에 존재할 수 있음을 이해할 것이다.

구조기준(StructureCriteria) 제한은 구조적 방식으로 일련의 객체 대하여 동작하는 프레임에 대한 개념을 모델링한다. 구조기준 제한은 동작이 진행하는 기준 또는 기준들을 모델링한다. 구조기준 제한에 대한 구문은 표 59에 나타낸다.

표 59: 구조기준 제한

restriction StructureCriteria<criteria:=Entity>

{

}

LOM의 몇몇 구현에서, "in pairs", "5 at a time" 등과 같이 어구를 모델링하는 "increment"로 불리는 제한을 포함하는 것이 바람직할 수 있다. 이런 종류의 어구는 구현예에 따라 이들을 모델링하는 몇몇 특정 방식을 포함하기에 충분히 중요할 수 있는 매우 일반화된 수치 기준을 포함한다. 표 60은 구조기준 제한에 의해 모델링될 수 있는 몇몇 용어 및 어구를 나타낸다.

표 60. 구조기준 제한에 의해 모델링되는 용어/어구

영어

sort by subject, list by date

display in rows

tranmit in 1KB blocks

get my email one at a time

독일어

sortieren nach Thema

anziegen

senden/schicken

"대체" 제한은 하나의 용어가 다른 것을 대체하는 의미 이벤트에의 참가를 모델링한다. 프랑스어에서, 하나의 가능한 예는 pour에 대한 대체가 부속(adjunctive)인 경우이다. 부속은 동작 상황을 나타내는 부사의 유형이다. 유사하게, 스페인어에서, por는 부속으로서 사용되고, para는 선택된 동사와 함께 사용 될 수 있다.

시간이 제한으로 처리될 수 있다. 통상, 시간 제한은 엔티티로 표현될 수 있는 특정 시간 단위 또는 시점에 대한 참조를 포함하는 시간 수식어구를 모델링한다. 예를 들면, "after July 23^rd" 및 "after Thanksgiving"은 시간 제한에 의해 모델링될 수 있다. 그러나, 몇몇 실시예에서, "after my computer boots up"과 같은 어구는 시간 제한에 의해 모델링되지 않는다. 유사하게, "from 3:00 to 6:00"과 "between morning and evening"과 같은 시간 범위는 시간 제한에 의해 모델링될 수 있다. 그러나, "while the defrag utility is running"은 시간 제한에 의해 모델링될 수 없다. 임베디드된 절 내용(clausal content)을 포함하는 시간 표현은 조건 제한으로 처리된다. 표 61은 LOM 내의 제한으로서 구문과 시간의 구현을 나타낸다.

표 61: 시간 제한

restriction Time

{

BaseTime startTime;

BaseTime endTime;

BaseTime pointorSpan;

Duration duration;

TimeLength recurrence;

}

abstract class BaseTime

{

}

abstract class AbsoluteTime:BaseTime

{

}

class NowAbsoluteTime:AbsoluteTime

{

}

class Analyzed AbsoluteTime:AbsoluteTime

{

int second;

int minute;

int hour;

int date;

int week;

Weekday weekday;

Month month;

Int year;

Era era;

AmPm ampm;

}

enum Weekday

{

Unspecified,

Monday,

Tuesday,

Wednesday,

Thursday,

Friday,

Saturday,

Sunday

}

enum Month

{

Unspecified,

January,

February,

March,

April,

May,

June,

July,

August,

September,

October,

November,

December

}

enum Era

{

Unspecified,

BCE,

CE,

Heisei,

Showa,

Taisho,

Meiji

}

enum AmPm

{

Unspecified,

Am,

Pm,

TwentyFourHour

}

class UnanalyzedAbsoluteTime:AbsoluteTime

{

Denoter timeExpression;

}

abstract class RelativeTime:BaseTime

{

BaseTime relativeTo;

}

class offsetRelativeTime:RelativeTime

{

Offset offset;

}

class Offset

{

Direction direction;

TimeLength timelength;

Granularity granularity;

}

enum Direction

{

Unspecified,

Forwards,

Backwards,

}

enum Granularity

{

None,

Seconds,

Minutes,

Hours,

Days,

Weeks,

Months,

Years,

Decades,

Centuries,

Millenia

}

class TimeLength

{

float amount;

TimeUnit unit;

Denoter otherUnit;

}

enum TimeUnit

{

Other,

Minutes,

Hours,

Days,

Weeks,

Months,

Years,

Decades,

Centuries,

Millenia,

Mondays,

Tuesdays,

Wednesdays,

Thursdays,

Fridays,

Saturdays,

Sundays,

Januaries,

Februaries,

Marches,

Aprils,

Mays,

Junes,

Julys,

Augusts,

Semptembers,

Octobers,

Novembers,

Decembers

}

class SubsetRelativeTime:RelativeTime

{

AbsoulteTime subset;

}

class Duration

{

TimeLength timeLength;

TimeLengthQualifier qualifier;

}

enum TimeLengthQualifier

{

None,

MoreThan,

LessThan,

AtLeast,

AtMost,

Precisely

}

시간 제한은 필요시 하나 이상의 필드와 많은 수의 보조 데이터형을 사용한다. 필드는 개시 시간, 종료 시간, "포인트 또는 스팬", 기간 및 반복을 포함할 수 있다. 개시 시간 필드는 "from 5:00" 또는 "after tomorrow"와 같은 시간 간격의 개시점을 표현하는 기본 시간 유도 객체로 설정된다. 개시 시간 필드가 널(null)이면, 모델링된 시간 수식어구는 개시점의 어떤 공개 표현도 포함하지 않는다.

종료 시간 필드는 "to 6:00" 또는 "until Friday"와 같은 시간 간격의 종료 시점을 나타내는 기본 시간 유도 객체로 설정된다. 종료 시간 필드가 널이면, 모델링된 시간 수식어구는 종료점의 공개 표현을 포함하지 않는다.

포인트 또는 스팬 필드는 개시점과 종료점을 명시적으로 지정하여 표현되는 시간 간격과는 달리, 단일 어구로 표현되는 유일 시점 또는 시간 간격을 나타내는 기본 시간 유도 객체로 설정된다. 예를 들면, "tomorrow"에 대하여, 이 아이디어는 "tomorrow"가 시간 라인 상에서 단일점이거나 24 시간이 문맥과 사용자의 관점에 의존한다. LOM은 이 용어의 모호성을 제거하려는 시도를 하지 않는다. 포인트 또는 스팬 필드가 널이면, 모델링된 시간 수식어구는 단일 시점 또는 시간의 명시적 표현을 포함하지 않는다.

기간 필드는 특정 개시점과 종료점을 표현하지 않고 시간의 길이를 표현하는 기간 객체에 설정될 수 있다. 예를 들면, "for two hours"라는 어구는 기간 필드에 의해 모델링될 수 있다. 널의 경우, 모델링된 시간 수식어구는 명시적인 기간 표현을 포함하지 않는다. "from 4 pm to 6 pm"과 같은 시간 간격에 내재적인 기간은 기간 객체에 표현되지 않는다. 이 경우, 개시점과 종료점에 대한 널이 아닌 값일 수 있으며, 기간은 널일 수 있다.

반복 필드는 반복 이벤트의 발생 사이의 간격을 표현하는 시간 길이 객체로 설정된다. 예를 들면, "daily", "weekly", "monthly", "the first Monday of every month" 등과 같은 어구는 시간 길이 객체로서 표현될 수 있다. 널인 경우, 모델링된 시간 수식어구는 반복으로서 해석되지 않는다.

통상, 시간 제한은 다수의 보조 데이터형을 사용한다. 예를 들면, 기본시간(BaseTime)은 상대시간(RelativeTime)으로부터 유도된 제로 이상의 객체와 절대시간(AbsoluteTime)으로부터 유도된 정확히 하나의 "루트(root)" 객체로 이루어진, 기본시간으로부터 유도된 객체이다. 각각의 상대시간 유도 객체는 체인 내의 다음 객체에 대한 참조를 보유하지만 루트 절대시간 유도 객체는 이러한 참조를 보유하지 않기 때문에, 이들은 "체인"으로 불린다.

NowAbsoluteTime과 같은 절대시간 유도형은 체인 내의 다른 객체에 대한 기준을 보유하지 않는다. NowAbsoluteTime 유도형은, 예를 들면, 발화의 언급 시간의 비분석가능한 "now"를 나타낸다. LOM은 예를 들면, "now"를 2002년 10월 24일 3:42:27 pm으로 분석하려 하지 않는다.

AnalyzedAbsoluteTime은 초, 시간, 날, 연 등으로 분석될 수 있는 시점 또는 시간 간격을 나타내는 AbsoluteTime 유도형이다. 예를 들면, AnalyzedAbsoluteTime은 9:30 am에서 3:45 10 May 2003, Wednesday로서 "now" 시점 을 표현하는데 사용될 수 있다.

UnanalyzedAbsoluteTime은 시점으로 알려진 표현을 나타내지만 원소 시간단위로 분석될 수 없는 AbsoluteTime 유도형이다. 예를 들면, 휴일, 연의 계절, 추상 일시 개념은 이 카테고리에 해당한다. 예를 들면, "Thanksgiving", "Election Day", "my birthday", "summer" 및 "this evening"은 UnanalyzedAbsoluteTime으로 모델링되는 모든 어구이다.

상대시간 유도형에는 두가지가 있다: 오프셋상대시간과 부분집합 상대시간. 오프셋상대시간은 참조한 기본시간 유도 객체로부터 특정 시간 길이의 양의 또는 음의 오프셋을 나타낸다. 예를 들면, "two days ago"라는 어구는 "[2 days back] OFFSET FROM [now]"로서 모델링된다.

부분집합 상대시간은 기준 기본시간 유도 객체에 의해 표현되는 포함 시간의 부분집합으로서 해석되는 시점 또는 시간을 나타내는 상대시간 유도형이다. 예를 들면, "at 5:00 on my birthday"와 같은 시간 차원의 표현은 ["my birthday"]의 [hour:5 min:0]"의 등가로서 모델링될 수 있다. "5:00 on Wednesday" 등의 시간 기준은 어구가 시간 단위로 분석될 수 있기 때문에 단일 분석절대시간 객체에 의해 캡처될 수 있음을 인식하는 것이 중요하다.

몇몇 실시예에서, 한 쌍 이상의 개시시간 및 종료시간 필드를 갖는 것이 바람직할 수 있다. 예를 들면, "from Monday to Friday from 4:00 to 5:00"과 같은 표현을 캡처하기 위해서, 두 쌍의 개시 및 종료 시간 필드가 두 범위를 캡처하기 위해서 바람직할 수 있다. 사실상, 상기 표현에 있어서, 시간 엔티티를 갖는 것이 바람직할 수 있다. 또한, 다음 표현 간의 대비(parallel)는 시간 엔티티가 바람직할 수 없음을 제안한다.

Move the meeting [from 4:00 to 5:00].

Move the file [from Folder1]_source [to Folder2]_Goal.

또한, 소스 및 목적을 취하는 모든 구조가 개시시간과 종료 시간을 이와 같이 동작할 수 있게 하지는 않으므로, 종료 시간은 통상의 목적과 분리되어야 한다. 예를 들면, "Run a meeting [from 4:00 to 5:00]"의 표현을 모델링하기에 적합한 구조는 개시시간과 종료시간이 적절하게 동작할 수 없게 할 수 있다.

다른 제한은 토픽 제한이다. 엔티티 객체에 대하여, 토픽 제한은 엔티티가 무엇에 관한 것인지 또는 무엇에 관련되거나 무엇에 속하는지를 표현하는 인수 또는 수식어구를 모델링한다. 프레임에 관련된 토픽 제한은 이벤트의 주제 또는 토픽을 표현하는 동사 인수를 모델링한다. 통상, 토픽 제한은 토픽 또는 주제를 모델링하는 엔티티 또는 프레임에 설정된 슬롯을 갖는다. 다르게는, 슬롯은 문자열을 취할 수 있다. 표 62는 본 발명의 일 실시예에 따른 토픽 제한의 구분을 나타낸다.

표 62: 토픽 제한

restriction Topic<topic:=Entity>

{

}

restriction Topic<topic:=Frame>

{

}

몇몇 경우, 토픽 제한을 상이한 이름으로 라벨하는 것이 바람직할 수 있다. 특히, "토픽"이라는 용어의 심각한 과부하(적어도 언어학적 필드 내에서)의 경우, 이러한 제한에 대한 다른 라벨을 사용하는 것이 바람직할 수 있다. 몇몇 다른 라벨은 예를 들면 "Concerning", "Regarding", "About", "Subject", "Theme" 등을 포함할 수 있다. 표 63은 본 발명의 일 실시예에 따른 토픽 제한에 의해 모델링될 수 있는 몇몇 예시적인 어구/용어를 제공한다.

표 63: 토픽 제한에 의해 모델링되는 어구/용어 예

영어

about, on

concerning..., regarding...

remind Sandy that Kim is coming tomorrow

독일어

uber

Zeige die Mail uber den Hausbau.

[bezuglich/bezgl.]+ genetive case

Zeige Mail bzgl. des Hausbaus.

일본어

NP- NP

NP- VP

수량사 제한은 two thirds of와 같은 명사구 수량사 및 부분사(partitive)를 모델링한다. 통상, 수량사 제한은 유형 또는 퍼센트 필드를 포함할 수 있다. 유형 필드는, 통상(항상 그러한 것은 아니지만) 제로와 1 사이에 부동소수점으로서 저장되는, 퍼센트일 수 있다. 예를 들면, 퍼센트 유형은 one half of, 75% of, 200% 증가 등을 모델링한다. 또한, 필드 유형은 정확한 퍼센트에 대응하지 않은 수량사를 모델링할 수 있다. "all" 및 "none"의 용어는 이러한 "other" 유형에 속하지 않은 상이한 "privileged" 값으로서 열거된다. 퍼센트 필드는 유형이 퍼센트 값을 갖는 경우 수량사의 의미에 대응하는 퍼센트를 보유한다. 다르게는, 퍼센트 필드는 무시된다. 표 64는 수량사 제한과 이의 관련 열거에 대한 구문을 나타낸다.

표 64: 수량사 제한

restriction Quantifier

{

QuantifierType type;

Float percentage;

}

enum QuantifierType

{

All,

None,

Some,

Most,

Many,

Few,

Percentage

}

몇몇 구현예에서, 부정(negation)을 상이하게 처리하는 것이 바람직할 수 있다. "none"과 같은 용어를 열거하는 대신, 부정을 명사구로서 처리하는 것이 바람직할 수 있다. 표 65는 수량사 제한에 의해 모델링될 수 있는 몇몇 예시적인 용어/어구를 나타낸다.

표 65: 수량사 제한에 의해 모델링되는 용어/어구

영어

All: all((of) the), every, each (of the)

None: no, none (of the)

Some: some (of the)

Most: most (of the), the majority of

Many: many (of the)

Few: few (of the), not many (of the)

Percentage: a half of, 1/3 of, 40% of

독일어

All: alle (Gen), jede/r/s

None: keine/r/s (Gen)

Some: manche/r/s (Gen)

Most: die meisten (Gen), der Großteil (Gen)

Many: viele (Gen)

Few: wenige (Gen)

Percentage: die Halfte von (Gen), 1/3 von/ (Gen), 80% von (Gen)

당업자는 예시적인 용어 및 어구에 대한 상기 설명이 언어학적 모델링에 대한 임의의 특정 제한을 나타내는 대신, 도메인 및 언어 독립성을 나타내려는 것이다. 통상, LOM은 임의 개수의 언어를 모델링할 수 있다.

D4. 프레임 클래스: 어휘 의미 구조

후술하는 설명은 LOM 객체 생성자(분석 엔진)의 가능한 구현예의 일 양태에 관한 것이며, 이는 어휘 의미 구조(LSS)로 불린다. 이러한 특정 양태는 LOM과 함께 개발되지만, 다수의 다른 구현예가 LOM 객체를 생성하는데 사용될 수 있다. LSS는 또한 LOM의 유형에 대한 설계 프로세스에서 사용된다.

어휘 의미 구조(LSS)는 언어들 및 언어 카테고리들에 대해 자연어 입력의 정규화를 위한 언어 간 동작 및 자식-언어 획득에 대한 일반화에 기초한다. LSS는 어휘 의미 클래스들에 자연어의 요소들을 매핑하기 위한 방법을 제공한다. 그런 한 가지 사용은 언어 객체 모델(LOM)에 자연어 입력(언어 발화)을 나타내는 어휘 의미 구조를 매핑하는 것을 포함할 것이다.

LSS는 일련의 어휘 의미 카테고리들 및 일련의 어휘 의미 카테고리들 중의 한 개 이상에 자연어 입력을 할당하는 방법을 포함한다. 일련의 어휘 의미 카테고리들의 각각의 카테고리는 구문 카테고리들과 의미 역할들의 목록에 자연어 입력의 요소들의 매핑을 내포한다. 더 구체적으로, 각각의 카테고리는 한 개 이상의 의미 역할들에 한 개 이상의 구문 카테고리들의 매핑을 내포한다. 본 명세서에서 사용되는 바와 같이, "구문 카테고리들"이라는 용어는 문장의 구조 요소들(예를 들어, 주체들, 객체들, 전치사구들, 절 보문들(clause complements), 수식어구들 등)을 일컫는다. "의미 역할들"이라는 문구는 특정 발화 내에 특정 구문 카테고리 기능의 식별을 일컫는다 -예를 들어, 주체들은 일반적으로 "누구(who)"라는 역할(동작주(agent), 행위자, 실행자, 또는 행위의 원인 등)이 할당되고, 직접 객체들은 "무엇(what)"(수동적인, 피동적인, 수행된, 또는 행위의 효과 등)이고, 수식어구들은 다양한 역할들(소스, 목적, 시간 등)을 가질 수 있다. 위에 제공된 예들은 설명 목적으로 제공되고, 전체를 나타내려고 의도되지는 않음을 이해해야 한다. 최종적으로, 본 명세서에서 사용되는 바와 같이, "정규화하다" 또는 "정규화"라는 용어는 특정 구문 표현으로부터 의미 역할을 추상화하는 프로세스를 일컫는다.

목록 및 의미들은 언어 간의 동작과 자식-언어 획득으로부터 유도되고, 자연어들의 어휘 의미 특징들이 특정 속성들을 공유하는 일반화에 기초한다. 언어 정착(linguistic anchoring)과 의미 상세성의 관점에서, LSS는 세계 지식에 기초하여 언어로부터 의미 추론을 하는 인공 지능 시스템들과 명백한 유사어들 간의 구별을 모델링하는 더 세분화된 어휘 분석 프레임워크들 간에 위치된다. 부연하면, 모든 언어들은 디폴트로서 매핑될 수 있는 언어 구조들을 가진다. 추가로, 각각의 자연어는 의미 역할들에 다수의 구문 카테고리들의 논디폴트(non-default) 매핑들을 가진다. 주체와 객체보다 원인적으로 더 먼 의미 역할들을 갖는 이들 논디폴트 클래스들은 더 드물다.

디폴트 어휘 의미 구조는 문장의 주체를 "누구(who)"로서 그리고 객체를 "무엇(what)"으로서 카테고리화하여, 상술된 바와 같이, John broke the glass와 같은, 타동적 문장을 모델링한다. 수식어구들은 인과 사슬(causal chain)의 시간 노출(unfolding)을 나타내는 순서(또는 형태적 경우 표시(morphological case marking))로 식별된다. 부연하면, 수식어구들은 추가적 경우 표시(간접 객체) 및 전치사구들과 같은 부사적 수식어구들에 의해 플레이되는 의미 역할들로부터 유도된다. John broke the glass for me의 문구에서, John은 주체이고, the glass는 객체이고, "for me" 문구는 문장의 객체에 더 근접한 간접 객체로서 표시된다.

디폴트 자동적 문장은 보통 동작주 또는 "누구(who)"를 포함한다. 예를 들어, 문구 John ran은 동작주 "John"을 포함한다. 덜 일반적으로, 그 한 개의 인수가 수동적일 수 있다. 예를 들어, The glass broke라는 문구에서, "The glass" 문구가 피동적이고, 원래 문장이 [Something] broke the glass인 것처럼 동일한 방식으로 문장이 모델링될 수 있다.

LSS 목록에 포함될 의미 역할들에 대해, 그것은 일부 언어에서 구문 카테고 리로서 나타나야 할 것이고, 명사 및 동사 클래스들의 범위에서 인수 또는 수식어구로서 적용되어야 한다. 그러므로, 역할들은 언어 정착 및 의미 일반성을 모두 가진다. 예를 들어, "The office"라는 문구는 다음 예들의 각각에서 소스이다:

1. John left the office.

2. The office emitted smoke.

3. John went out of the office.

4. The man from the office called.

각각의 인스턴스에서, 소스는 동사 클래스 및 의미/구문 테스트들에서 그것의 동작에 기초하여 식별된다. 예 1을 참조하면, 소스는 이 클래스의 동사들의 객체이다. 동사 "left" 및 타동사 "to leave"(및, 다른 것들 중에서도, "to exit")는 추가 소스들을 취할 수 없다. 예를 들어, John left the house out of the yard는 "John went out of the house and out of the yard."를 의미하지 않는다. 예 2에서, "the office"는 의미/구문 테스트들의 유사물에 "emit"에 의해 설명된 동사 클래스의 동작에 기초한 문장의 주체이다. 위의 예 3과 4에서, 전치사들 "out of"과 "from"의 의미들은 일반적으로 그들의 객체들에 소스 역할을 할당한다.

LSS는 일련의 어휘 의미 카테고리들 및 일련의 어휘 의미 카테고리들의 한 개 이상의 카테고리들에 자연어 입력을 연관시키는 방법이다. 방법은 자연어 입력에 프로시져들의 집합을 적용하는 일련의 어휘 의미 카테고리들 및 규칙들에 자연어의 내용을 연계시키는 프로시져들의 집합을 포함한다. 본 명세서에 사용되는 바와 같이, "방법"이라는 용어는 일련의 어휘 의미 카테고리들에 자연어 입력의 내용을 연괸시키는 프로시져의 집합을 일컫는다. 각각의 어휘 의미 카테고리는 한 개 이상의 구문 카테고리들, 한 개 이상의 역할들, 및 한 개 이상의 구문 카테고리들과 이들 인수들이 발화 내에서 플레이하는 연관된 한 개 이상의 역할들 간의 매핑을 포함한다. 추가로, "방법"은 자연어 입력에 프로시져들의 집합을 적용하는 규칙들을 일컫는다. 일부 인스턴스들에서, "방법"은 자연어 입력의 내용의 매핑의 다른 단계들이 완료될 때를 분석하는 휴리스틱들을 포함할 수 있다. "방법"이라는 용어는 일련의 언어 카테고리들의 한 개 이상의 언어 카테고리들에 자연어 입력의 내용을 연관시키고 및/또는 정규화시키기 위해 채택된 기술들, 규칙들, 및 프로시져들의 집합을 포함한다.

정규화 구조로서, LSS는 구문 카테고리들(동사의 주체/객체, 동사를 수식하는 전치사구들의 객체 등)에 대해 의미 역할들의 식별을 돕는다. 더욱이, LSS는 언어들에 대해 의미 역할들에 구문 카테고리들을 연관시키는 것을 가능하게 한다. 이 정규화는 구문 카테고리들의 클래스들의 인수들과 그들의 의미들을 식별하고, 적합한 어휘 의미 카테고리에 식별된 인수들을 연관시켜서 수행될 수 있다. 그 다음, 어휘 의미 구조는 특정 구문 표현으로부터 추상화될 수 있다.

언어 객체 모델 및 의미 프로그래밍 언어(및 연관된 사용자 스키마)의 조합으로, 다수의 언어 카테고리들의 의미 모호성은 감소된다. 예를 들어, 전치사 "for"는 행위의 수해자들(I bought a dress for my daughter), 목적들(I go to California for the beaches), 시간 길이(I went to school for 20 years), 목적들(present for my daughter) 등을 식별한다. 그러나, 주어진 응용 프로그램 내에서, 단지 제한된 일련의 가능성들만이 컨텍스트와 관련된다. 결과적으로, 의미 모호성의 많은 부분이 컨텍스트에 의해 제거된다.

도 11은 본 발명의 일 실시예에 따라 어휘 의미 구조(LSS)(1100)를 도시하는 간략한 개념 블록도이다. LSS(1100)는 일련의 어휘 의미 카테고리들(1102) 및 어휘 의미 카테고리들(1102)에 자연어 입력(1106)의 요소들을 매핑하는 방법(프로시져들 및 규칙들)을 포함한다. 도시된 실시예에서, 그 다음, 자연어 입력(1106)을 나타내는 매핑된 요소들은 언어 객체 모델(LOM)(1110)에 매핑하여 자연어 입력(1106)을 나타내는 LOM 객체(1112)를 생성시키는 분석 엔진(1108)에 제공될 수 있다. 당업자라면 방법이 런타임 및 LSS 클래스들이 디자인 시간에 개발되는 방법의 접근법에 모두 적용됨을 이해해야 한다. 더 구체적으로, LSS가 언어들, 언어 카테고리들, 분석 엔진들 등에 대해 자연어 입력을 매핑하기 위해 실행시에 자연어 프로세싱에 적용할 수 있고, 또한 디자인 시간에 어휘 의미 구조는 프로그램 코드에게 LSS 클래스들에 대해 알린다.

통상, LSS는 지원된 언어 중 하나에서 기준 패턴과 상이한 구문 및 의미 프레임과 공유하는 프레임과 엔티티 그룹을 식별한다. 통상, 어휘 구문은 주로 단어 의미를 취급하는 언어학은 일부분야이다. 어휘 의미 구조(LSS) 이론은 문장 의미 및 구문의 단어 의미의 관계에 관한 것이다. 또한, LSS 이론은 상이한 언어 간의 어휘 의미 구조에서 상이함과 유사성을 분석한다.

통상, 프레임은 두개의 기본 패턴을 갖는다: 타동사 기본 패턴과 자동사 기본 패턴. 타동사 기본 패턴은 Who 슬롯을 주어 위치에 What 슬롯을 목적어 위치에 연결한다. 이에 대비하여, 자동사 기본 패턴은 What 슬롯과 목적어 위치가 부족하다. 둘 모두는 동사형이 어두에 있는 다음 예에서 설명된다.

[User]_who 유형 [email address]_what.

[User]_who 유형

프레임은 연결(프레임 슬롯이 문법으로 채워짐)과 인수 구조(슬롯 수) 모두의 기준이 변경할 수 있다. 예를 들면, 하나의 비 기본(non-default) 연결형에서, 비 직접목적격(unaccusative)의 동사 클래스는 increase 동사가 어두에 있는 후술하는 알 수 있는 바와 같이, 자동사 패턴에 대한 패턴을 상이한 연결을 갖는다.

[Users]_Who generally increase [the font size]_What. of headers.

[The font size]_What generally increases in headers.

이 경우, 자동사의 주어는 타동사의 목적어에 동일하고, What 슬롯에 연결된다. 언어학적으로, 이들 비 직접목적격, 비 기본 연결형은 몇몇 언어에서 대문자의 패턴으로 "능동" 동사로 종종 불린다. 이러한 동사는 기본 연결 패턴에 더하여 자동에서 추가적인 비 기본 연결 패턴을 생성한다.

다른 비 기본 연결형에서, ObliqueAsDefault 동사 클래스는 사격(oblique) 인수로서 Who 또는 What 인수를 표현한다. 예를 들면, 영어로 표현된 상호관계는 대동 제한의 객체로서 추가적인 Who 또는 What 참가자를 표현한다.

추가 Who: I chatted with John - John and I chatted.

추가 What: I merged file A with File B ~ I merged File A and B.

다른 언어는 대명사에 관한 것으로서 대상을 설명하지 않고 대상을 식별하거나 규정하는 인수를 의미하는 추가 대명사 인수로서 상호관계를 표현한다. 또한, 이들은 대동 제한으로 취급된다.

많은 동사는 의미론적으로 What 슬롯을 관련할 수 있는 구문적으로 사격 인수(특이 전치사로 표시)를 갖는다. 즉, 동사가 자동사이면, 전치사구는 의미론적으로 제한 카테고리 중 하나로 의미에 해당하지 않고, 어구는 직접 목적어로서 분석될 수 있으며(또는 다른 언어로 번역), What 슬롯으로의 연결로서 처리될 수 있다. 표 66에서 기본 슬롯으로서 사격을 트리거하는 어구를 나타내는 여러 예가 제공된다.

표 66: ObliqueasDefault

Juan cofia en Pedro -> 'John trusts Peter'

I'm waiting for MSN8 -> I'm awaiting MSN8.

Look for files on the internet -> Find files on the internet.

이들은 의미론적으로 밀접한 클래스(hope for, watch for, wait for)에 관련될 수 있거나, 정렬의 경우 표시자로서 이러한 방식의 특정 전치사를 취하는 일련의 동사에 개별 표시될 수 있다(예를 들면, find and look for).

동사 클래스는 프레임 내에서 Who 및 What에 더하여(이에 대신하여) 슬롯을 가짐으로써 기본으로부터 변형될 수 있다. 더욱이, 동사의 몇몇 클래스는 Who 또는 What 슬롯보다 LOM에서의 제한에 구문 주어 또는 목적어를 연결한다. 즉, 기준 슬롯 중 하나 또는 둘 모두는 제한에 의해 대체될 수 있다.

SubjectAsRestriction 패턴은 주어를 What 슬롯이 아닌 제한에 연결한다. 예를 들면, 동사 "receive"는 주어로서 Goal을 취한다.

[The website]_Goal received the data.

[The garden] swarmed with bees. ~ Bees swarmed in the garden.

유사하게, ObjectAsRestriction 패턴은 구문 객체가 What이 아닌 Goal인 프레임의 투사한다. 예를 들면, 동사 "enter"는 t를 구문 목적어가 what이 아닌 Goal 또는 위치인 프레임에 매핑한다.

Enter [the chat room]_Goal (cf. Enter in(to) the chat room, go in the chat room)

프레임은 사격으로서 하나 이상의 추가 제한에 의미론적으로 뒤따르는 기준에서 변할 수 있다. 추가 제한 패턴은 기본 슬롯에 더하여 사격 인수 또는 절 보충으로서 추가 제한을 연결한다. 예를 들면, 상태 변화 동사는 추가 Goal(동사 "reset"과 같은)을 취할 수 있거나, 후술하는 바와 같이, (동사 "change"와 같이)소스와 Goal 모두를 취할 수 있다.

Reset [the default font]_What [to Times New Roman]_Goal.

Change [the font]_What [from Arial]_Source [to Times New Roman]_Goal.

또한, 프레임은 하나 이상의 상기 비 기준 연결형(Unassusative, SlotAsRestriction[subject or object], and AdditionalRestriction)을 조합하는 등 다양한 방식으로 기본에서 변경될 수 있다. 더욱이, 동사는 상이한 의미를 취 하는 것으로서 추론될 수 있는 여러 프레임을 반영할 수 있다. 기본 프레임은 "enter"의 한 의미를 갖고, SlotAsRestriction은 다른 의미를 갖는다. 동사 "enter"는 구문 민감형일 수 있다.

Enter [the data]_What (into the form).

Enter [the chat room]_Goal.

키워드 "Keep"는 상이한 의미를 갖는 기본과 3개의 비 기본 프레임을 취한다. 예를 들면,

기본: Keep [the file]_What

AdditionalRestriction (위치): Keep [the file]_What [on the desktop]_Location

AdditoinalRestriction (목적): Keep [Bill Gates]_What [from emailing me]_Source

Unaccusative: The data won't keep.

통상, 어휘 의미 구조 프레임이 적어도 하나의 언어에서 기본과 상이한 동사에 대하여 모든 지원 언어에 걸쳐 갖는 것이 바람직하다. 본 발명에서, 이는 타동사와 자동사에 대하여 모두 적용되는 것으로 가정된다.

("expand", "increase" 등과 같은) 몇몇 동사에 있어서, 비 직접목적격 패턴만이 자동사에 대하여 유효할 수 있다. 다른 동사에서, 비 직접목적격 패턴 연결은 추가 옵션이다.

표 67은 추가 제한을 구비한 LSS 프레임에 의해 모델링될 수 있는 몇몇 예시적인 어구/용어를 나타낸다. 각 예에서, 제한은 기본 인수를 대체하거나, 인수를 프레임에 더한다. 원리상, 각 제한은 주어 위치에, 목적어 위치에, 또는 추가 사격 인수로서 나타날 수 있다. 일부 제한은 상술한 바와 같이 Who 및 What 슬롯에 참가자를 추가한다. 관련 명사구(NP) 프레임이 또한 주어진다.

표 67: 추가 제한을 구비한 LSS 프레임에 의해 모델링되는 대동

대동

주어 위치에서

Meet: My daughter and I met

Chat: My friend and I chatted.

목적어 위치에서

Accompany: My daughter accompanied me to Minneapolis.

영어에서, 추가 제한은 대명사 "with" 또는 가능하게는 "against"에 의해 통상 어두에 있게 된다. 다양한 동사 서브클래스는 관련 의미로 이러한 대명사 또는 대명사구를 선택한다. 샘플이 표 68에 주어진다.

표 68: 추가 제한을 갖는 LSS 프레임

Abscond: The Enron executive absconded with the money. ()

Accomodate: indulge

Accredit: accredit, credit

Ache: ache, burn, itch

Arrange

영어에서, 대동 제한은 Who 및 What 슬롯에 참가자를 추가할 수 있다. 이러한 제한이 수식어구인 프레임에 대하여 참이지만, "상호" 동사에서는 특히 일반적이다. 표 69는 기본 슬롯으로서 몇몇 사격의 예를 제공한다.

표 69: 기본 슬롯으로서 사격

Who

주어 상호관계

Chat: I IMed with Mary ~ Mary and I IMed;

chat, discuss, talk, visit

Agree

Alternate

Unaccusative: The file merged (together) with the data ~ The file and the data merged (together)

What

목적어 상호관계:

Merge: I merged the files with the data, I merged the data and the files

Acquaint: I familiarized them with topic; acquaint

영어에서, 추가 제한이 할당에 대하여 PP "for"에 의해 어두에 있게 된다. 다양한 동사 서브클래스는 이러한 PP를 관련 의미로 취한다. 샘플이 아래 주어진 다.

Adapt: Adapt the movie for the stage

Allocate: Allocate funds for linguistics;

allocate, appropriate,

Appropriate: Appropriate funds for increased wages

Assign: Assign a day for the performance

Nominate: Nominate candidates for congress

Transcribe: Transcribe the music for trumpet

Train: Train for a marathon

AsBeing 제한에 대한 제2 술어는 추가 제한으로서 사용될 수 있다. 몇몇 예시적인 어구가 아래 표 70에 제공된다.

표 70: AsBeing 제한의 제2 술어

명사구

Make me administrator

부속어구

mark messages low-priority

judge the data correct

mark that completed

mark low priority

judge the data correct

변형으로서 대명사구

mark task one as done

Mark messages as follow-up

mark that as completed

mark as low priority

judge the data as correct

Additional restriction

Show my status as busy

use as text file

save as file.doc

Log in as Administrator

put this message as message number two

수익자(beneficiary) 제한에 대한 추가 제한이 아래 표 71에 도시되어 있다.

표 71: 추가 제한을 갖는 수익자

목적어 위치에서

Benefit: Relaxed stock option laws benefited Enron; benefit, gain, profit

Unaccusative: Enron benefited from relaxed stock option laws

간접 목적어 위치에서

Benefit: Relaxed stock option laws benefited Enron; benefit, gain, profit

Unaccusative: Enron benefited from relaxed stock option laws

추가 제한

PP-for 및 간접 목적어

Build: arrange, asemble, bake

Create: design, dig, mint

Prepare: bake, blend, boil, clean, clear, cook, fix, fry...

Performance: dance, draw, ding, play, recite...

Get: book, buy, call, cash, cath

몇몇 제한 유형은 동사 프레임에 적용가능하지 않을 수 있다. 그러나, 전치사구가 비교 세트를 어디에 도입할 지 등의 추가 제한이 여전히 호출될 수 있다.

방향 제한은 어구 "move the cursor up (the page)"와 같은 추가 제한을 요구할 수 있다. 또한, 방향 요소가 동사 자체에 혼합되는 경우(such as "the stocks rose/fell/advanced/retreated" 또는 "rotate the picture" 등), 추가 제한이 요구될 수 있다.

추가 제한을 갖는 LSS는, 주어 위치에 포함된 제한 예에서, 다음 어구로부터 이해될 수 있다.

This document exemplifies table construction

Sample code illustrates possible applications.

범위 제한은 통상 추가 제한 위치 또는 목적어 위치에 해당한다. 이동형 동 사의 모든 방식은 범위 객체(예를 들면, "walk the mall", "crawl the web", "run the marathon" 등)를 취할 수 있다. 범위 제한에 의해 모델링될 수 있는 어구 예가 도 72에 나타낸다.

표 72: 범위 제한에 의해 모델링되는 어구 예

목적어 위치에서

The crawler traverses the web.

The data in this spreadsheet spans several builds.

추가 제한

I want a border around this text.

Maintain a uniform apperance throughout the web site.

Run through the spec before the review.

목표 제한은, 특히 클래스 또는 상태 간의 변환에 대하여, 추가 제한을 요구할 수 있다. 몇몇 동사에 특이 Goal로서 동작하는 전치사구의 범위는 구현예에 따라 변할 수 있다. Goal로서 특이 동작하는 전치사구의 예는 "save as file.txt" ("save to file.txt") 및 "reschedule for 5:00 ("reschedule to 5:00")이다.

몇몇 동사는 Bitrect에서(Goal 동작이 단일 동사에 기인한 경우) 또는 LSS 클래스에서(항목 클래스가 특이 Goal을 취하는 경우) 특히 목적을 취할 필요가 있을 수 있다. 추가 목적이 간단히 더해질 수 있으며, 패턴이 발견됨에 따라 어휘에서 이를 나타내는 클래스로 발췌할 수 있다.

위치에 관련된 추가 제한은 아래 표 73에서 나타낸 바와 같이 모델링될 수 있다.

표 73: 위치

Keep, Stand, CausedGoalOfMotion

주어 위치에서

Locative alternation (Levin 2.3): The garden swarmed with bees (cf. Beef swarmed in the garden)

목적어 위치에서

Search: Canvass the neighborhood, Search the web

추가 제한

타동사:

Keep: Keep the file on the desktop (hold, keep, locate, store)

Get: Find a book on Amazon.com

자동사

Stay: Stand here, Stay home

수단 제한이 또한 표 74에서 나타낸 바와 같이 추가 제한으로 모델링될 수 있다.

표 74: 수단

도구 주어: The knife cut the cake

추가 제한

Adorn: adorn, festoon, decorate

Adulterate: adulterate, ally, pollute

Anoint

Afflict

Aid: aid, assist, help

Analogize

Anoint

Answer

Arm

Assail: attack,

정렬순서 제한은 표 75에 나타낸 바와 같이 추가 제한에 의해 모델링될 수 있다.

표 75: 정렬 순서

영어

알파벳 순서로 배치

추가 제한

Arrange: sort alphabetically,

프랑스어

par ordre alphabetique inverse

du plus petit au plus grand [literally: from the smallest to the biggest]

du plus grand au plus petit [literally: from the biggest to the smallest]

유사하게, 구조 기준 제한이 표 76에 나타낸 바와 같은 추가 제한에 의해 모델링될 수 있다.

표 76: 구조기준

영어

Arrange by name (cf. 상기 정렬순서), in date order

프랑스어

{categoriser classer classifier filtrer grouper indexer ordonner regrouper rearranger reindexer trier}

Classe les messages {par ordre alphabetique, alphabetiquement}

'Sort the messages {in alphabetical order, alphabetically}'

Regroupe mon courrier par date

'Group/cluster my mail by date

Trie les fichiers en fonction de la taille

'Sort the files by size/as a function of the size'

Indexe la table sur le nom

'Index the table on the name'

통상, 시간 인수를 취하는 클래스는 완전 시간 표현을 구현할 수 있더라도 시간 유형의 측정 제한을 취하는 클래스로서 취급될 수 있다. 예를 들면, 다음 어구는 시간 유형의 측정 제한 또는 시간 인수를 취하는 클래스로서 모델링될 수 있다: "I spent at least an hour from 9 to 5 every day for weeks looking for a piano".

표 77은 추가 제한으로 모델링될 수 있는 몇몇 예시적인 토픽 어구를 나타낸다.

표 77: 토픽

Spact: talk about X, talk X, remind X that Y, book on Martin Luther

주어 위치에서

Her finances don't concern you; concern

목적어 위치에서

Discuss: The article addresses adolescents in the 20th century; address, cover, discuss

추가 제한

PP[{about, concerning, on, regarding}] takes either NP objects (about cats) or clausal objects (about John coming to Seattle)

PPRPTCL

The object of address could also be the addressee, rather than the topic.

D5. 엔티티의 클래스

본 단락은 개인 엔티티, 위치 엔티티, 및 LSS 엔티티와 같은 SPL 라이브러리로서 지지되는 엔티티 유형에 대한 데이터를 수집할 장소를 제공한다. 또한, SPL 라이브러리는 특히 추가 제한을 취하는 각 LSS 프레임 클래스에 대응하는 명사구(LSS 엔티티)의 클래스를 포함할 수 있다.

SPL 라이브러리는 또한 제한 클래스를 포함할 수 있다. 각 제한에 있어서, 제한을 지정하는데 사용될 수 있는 (적은) 일련의 명사구가 있다. SPL에서, 이들은 제한 슬롯 필러의 존재를 알리는 것으로서 일련의 구조로 식별될 수 있다. 예를 들면, 토픽이 주어 또는 목적어 또는 연결사(copula)인 경우, 토픽 제한 슬롯 필러(굵게 표시)는 보어 위치에 있다.

Find discussions where the economy is the topic.

Find discussions where the topic is the economy.

유사하게, 토픽이 AsBeing 슬롯을 채우면, 관련 엔티티는 토픽 슬롯을 채운다.

Find discussions that have the economy as a topic.

이들 구조는 토픽 제한으로서 식별되는 것과 함께 일반화되어야 한다.

Find discussions about/on/concerning/regarding the economy.

또한, theme, matter, subject, issue, focus 및 area와 같은 동의어는 TopicEntity일 수 있다. 더욱이, 개발자는 "subject in an email application"과 같은 이들 시나리오에 보다 구체적인 엔티티 클래스 토픽 단어에 추가될 수 있다.

E. 의미 프로그래밍 언어(SPL)

E1. 구조

SPL은 응용 프로그램 개발자가 그들의 응용 프로그램에 대한 풍부한 자연어(NL) 구현, 명령 및 제어(C&C) 기능을 구축할 수 있게 하는 수반하는 런타임 플랫폼을 구비한 특화된 프로그래밍 언어이다. (SPL이 구현할 수 있는 명령 및 제어 시나리오와, 예를 들면 Outlook에 대하여 구현될 수 있는 명령 종류에 대한 설명은 부록 I 참조).

SPL은 발화로부터 의미의 유도를 용이하게 하고 이 의미에 따라 동작을 용이하게 하는 작성 솔루션이다. SPL은 개발자가 이 스케일가능성에 대한 부담을 지울 필요없이 복잡한 발화를 스케일하도록 설계된다. 개발자에 대한 많은 추가 부담을 가하지 않고 음성 및 텍스트 입력에 대한 출처를 용이하게 하는 것이 SPL의 목적이다. 구체적으로, 언어/의미 분석의 지식이 거의 또는 전혀 없이 개발자가 NL 응용 프로그램을 개발할 수 있게 하는 NL 작성 도구를 제공하는 것이 바람직하다. 통상, SPL은 음성 입력에 대한 작성과 텍스트 입력에 대한 작성 간의 차이점을 최소화하도록 설계된다. 그러나, 음성 인식 문제점으로 인해, 몇몇 차이점은 개발자에 표면화되어야 할 수 있다.

NL 응용 프로그램은 SPL 없이 LOM에 따른 분석 엔진에 인터페이스하도록 작성될 수 있지만, 이러한 프로그래밍은 어렵고 개발자가 보다 많은 언어학적 지식을 요구하며 어휘 구조에 대하여 보다 많은 관리를 요구할 수 있다. 마지막으로, SPL은 특정 요소를 추상화하여 개발을 용이하게 하기 때문에, 개발자는 분석 성분이 아닌 응용 프로그램의 기능에 집중할 수 있다.

이는 특화된 프로그래밍 언어 아래의 전체 포인트이며, 개발자가 관리 및 이 해하는 것으로부터 자유롭게 하여 그/그녀가 즉시(이 경우, NL 구현 응용 프로그램) 태스크에 집중할 수 있게 한다. SPL은 개발자가 자연적 그리고 직관적으로 프로그래밍 공간의 기본을 표현할 수 있게 한다.

통상, 자연어 의미는 복잡하고 본질적으로 모호하다. 사람들은 방대한 세상의 지식과 문맥을 사용하여 의미를 이해하여 모호성을 제거한다. 사실상, 인간들은 이러한 이해 및 모호성 제거를 자연스럽게 행하기 때문에, 우리는 이러한 과정을 종종 지각하지 못한다.

발화의 의미 상에 동작할 수 있는 응용 프로그램에 있어서, 응용 프로그램에 발화의 의미가 무엇인지를 분석하여야 할 뿐만 아니라 자신의 지식과 문맥에 따라 의미의 모호성을 제거할 권한을 가져야 한다. 따라서, SPL은 응용 프로그램 도메인에 대하여 추론하여 이러한 추론이 깊고 유의미한 방식으로 의미 분석에 영향을 미치게 할 능력을 개발자에게 제공한다. 이러한 응용 프로그램 특정 추론과의 깊은 통합은 SPL에 내재적으로 구축되어 있다.

높은 레벨에서, 일 실시예에 따라, SPL의 접근법은 개발자가 구문이 아닌 발화의 의미에 대해서만 작성하게 하는 것이다. 구문을 액세스할 백 도어 방식이 몇몇 구현예에서 제공될 수 있다. 이는 LOM을 통해 달성된다(단락 D에서 상술함). 간략히 말하면, LOM은 도메인 독립 방식으로 (언급된) 발화 의미를 모델링한다. 많은 방식에서, SPL 프로그래밍 모델은 이러한 의미 모델을 구체화한다.

SPL 프로그램을 통한 발화의 분석을 통해, SPL은 응용 프로그램에서 엔티티에 결합된 언급된 것의 매우 유형화되고 도메인 의존적인 모델을 구성한다. 또한, 의미는 구문에서 분리되기 때문에 다국어 지원을 달성하기가 훨씬 용이하다.

SPL은 두개의 주요 부분으로 이루어진다. 제1은 강하게 유형화된, 절차의 이벤트 구동 및 객체 지행 언어이다. 일 실시예에서, SPL은 오늘날의 주류 개발자에게 매우 친숙한 C#(기업 스케일 응용 프로그램을 구현하는 객체 지향 및 유형 안전 프로그래밍 언어)에 기초한다. 다른 실시예에서, SPL은 속성의 사용을 통해 C#로 모두 작성된다. SPL의 설계 시에, SPL은 프로그램에 대한 새로운 저근법이 아님이 중요하다. 개발자의 기존 지식과 경험은 무효화되지 않고 영향을 받는다. 제2 부분은 SPL의 언어 의미에 따라 언급된 것의 도메인 의존 모델을 구성하는 런타임이다.

SPL은 기존 응용 프로그램에 영향을 주지 않고, 개발자가 기존 응용 프로그램 인터페이스 또는 객체 모델을 사용하여 발화의 의미론적 의미를 결합할 수 있게 한다. SPL은 개발자가 본래의 도메인 지식에 대하여 추론하는 코드를 작성할 수 있게 하지만, SPL이 .NET 공통 언어 런타임에 컴파일하기 때문에 개발자는 또한 임의의 마이크로소프트

.NET

프로그래밍 언어 등의 임의의 프로그래밍 언어로 이 코드를 자유롭게 작성한다.

SPL의 기본 구성은 엔티티(명사), 프레임(동사), 제한(엔티티 간의 관계), 명령(응용 프로그램 태스크 엔트리 포인트), 네임드 엔티티(NamedEntity) 및 표시자이다. 이들은 SPL의 주요 제1 클래스 유형이다. 이 언어는 자연어 구현 명령 및 제어(C&C) 기능을 위해 응용 프로그램에서 설계되기 때문에, 설계상 명령 중심적이다.

SPL 프레임워크를 상세히 설명하기 전에, 간단한 SPL 예가 이 경우의 나머지 부분의 이해를 제공하기 위해서 설명된다. 표 78은 "send email to Bob" 명령 시나리오를 처리하는 SPL 코드를 나타낸다. 이 명령 시나리오는 본 발명의 나머지 부분을 통해 여러번 참조된다.

최고 레벨에서 '명령'에서 개시하여, 이전에 소개된 LOM 모델에 SPL 코드가 적상된 것임을 이해하여야 한다(단락 D 참조). 명령은 프레임에 대하여 작성된다. 프레임은 동사를 통상 나타내는 객체이다. 하나의 동사를 나타내는 기본 프레임은, 분석 시스템으로 제공된다. 개발자는 또한 프레임을 설명하는 단락에서 보다 상세히 설명되는 그 또는 그녀 자신의 동사 프레임, 특성을 한정할 수 있다.

표 78: "Send Mail to Bob" SPL 코드

//굵은 서체의 토큰은 키워드 또는 반전 단어이다.

command SendMailCommand uses

MySendFrame<DoneTo.what:=MailEntity>

{

on resolve

{

// 분석절 개시

// 분석이 개시하기 전에 호출됨

begin

{

//응용 프로그램 특정 초기화를 행하고 또는 이 명령에 대한 분석을

//추가적으로 하지 않으면(예를 들면, 응용 프로그램 올바른 문맥/

//상태에 있지 않은 경우) 실패.

}

//이러한 객체에 대한 발화의 분석이 성공하는 경우 호출되는,

//분석 절을 지속

success

{

//응용 프로그램 특정 태스크 실행을 실행 (url 또는 xml을 생성,

//명령을 동작, 대화를 팝업 등)

}

//이러한 객체에 대한 분석이 실패한 경우 호출되는,

//분석 절을 중단

failure

{

//태스크 특정 클린업을 실행(자원 해제, 대화 팝업 등)

}

}

}

SendMailCommand는 전송된 객체('DoneTo.what' 슬롯)가 MailEntity인 경우에 MySendFrame을 사용하는 응용 프로그램 태스크 엔트리 포인트를 정의한다. 명령은 태스크를 캡슐화하여, 개발자가 특정 초기화 및 클린업을 실행할 수 있게 하며, 플랫폼에 응용 프로그램으로의 엔트리 포인트를 제공한다.

표 79는 MySendFrame에 대한 SPL 코드를 나타낸다.

표 79: MySendFrame

Frame MySendFrame: send<DoneTo.what:=MailEntity>

{

on resolve

{

begin

{

// 응용 프로그램 특정 초기화 또는 실패를 실행

}

//RecipientEntity는 프로그램 내의 어딘가에 정의됨

with restriction Goal<goal:=RecipientEntity>

{

//코드는 발화 내의 MySendFrame과 RecipientEntity 간의

//유효 Goal 관계가 있는 경우에만 실행된다.

//응용 프로그램 특정 추론을 실행하여 응용 프로그램 객체, 설정 상태를

//결합하거나 분석을 거부한다.

}

success

{

}

failure

{

}

}

}

MySendFrame 코드 블록은 도메인 독립 기본 "send" 프레임(플랫폼에 의해 제공됨)으로부터 상속하고 MailEntity에 'DoneTo.what'을 서브타입하는 응용 프로그램 특정 프레임, MySend를 정의한다. 'DoneTo.what'은 전송된 객체이다.

'to Bob'을 전송하는 의미는 Goal 제한(예를 들면 LOM에 기초한 SPL로서, 플랫폼에 의해 제공)에 의해 캡처되어, 'with restriction' 절을 통해 'send'에 연결된다. 이러한 연결에 더하여, 'to Bob'에 전송된 엔티티는 또한 RecipientEntity에 기초한다.

상술한 바와 같이, 제한은 통상 엔티티들 간의 유형화된 의미 관계이다. SPL 플랫폼은 소정의 기본 세트(base-set) 관계를 제공한다. 개발자는 제한의 기본세트를 서브타입화하여 그들 자신의 관계를 생성할 수 있다. 소정 제한의 몇몇 예는 위치("mail in Inbox"), 시간("delete after 3 days"), 소유자("Bob's book") 및 토픽("mail about cats")이다.

제한에 대한 중요한 점 중 하나는 구문 내의 변화가 의미 플랫폼에 의해 일반화된다는 점이다. 예를 들면, 토픽은 의미론적으로 여러 방식으로 표현될 수 있다: "mail about cats", "mail with cats as the subject", "mail regarding cats", "mail with subject cats" 등. 상이한 언어는 토픽 의미를 상이하게 표현한다. 이들 변화는 의미 플랫폼에 의해 일반화되어 개발자들은 각각의 가능한 의미 변화에 대해서가 아닌 토픽 제한에 대해서만 프로그램하여야 한다.

표 80은 본 발명의 일 실시예에 따른 MailEntity의 구문을 나타낸다.

표 80: MailEntity

Entity MailEntity denoted by MailWords

{

on resolve

{

begin

{

}

success

{

}

failure

{

}

}

}

denoter MailWords

{

Japanese:=noun(" "), noun(" ");

English:= noun("mail"), noun("email"), noun("electronic mail");

}

이 예에서, MailEntity는 단어 리스트에 의해 한정 및 지정된다. 의미하는 단어는 항상 개별적으로, 통상 그들 자신의 파일(로컬화 파일 등)에서 정의된다.

프레임과 같이, 엔티티는 또한 이들에 적용된 제한을 가질 수 있다. 표 81는 제한을 구비한 엔티티의 구문을 나타낸다.

표 81: 제한을 갖는 엔티티

entity MailEntity denoted by MailWords

{

with restriction Location<loc:=MailFolder>

{

}

}

개발자의 관점에서, 이러한 구문은 메일 항목이 MailFolder의 속성(제한)을 가질 수 있음을 선언한다. 엔티티 관계의 관점에서, MailEntity와 MailFolder는 위치 관계를 통해 관련된다. 런타임에, 위치 제한을 갖는 MailEntity의 인스턴스는 특정 MailFolder에서 제한되는 일련의 메일 항목을 나타낸다.

발화 "send mail to Bob" 또는 "send Bob mail"에 대하여, SPL 런타임 플랫폼은 SendMailCommand 명령에 대하여 분석한다. 도 4는 본 발명의 일 실시예에 따른 SendmailCommand 코드를 통해 분석을 추적하는 흐름도이다. 당업자는 본 발명에 따라 명령의 분석이 변할 수 있음을 이해하여야 한다. 예를 들어, 표 78을 참조하면, Begin, Success, 및 Failure 절 각각은 선택적이다. OnResolve 절은 특정 구현예에 따라, 절 중 임의의 하나, 절의 임의의 조합을 포함하거나, 또는 어떤 절도 포함하지 않을 수 있다.

도 4의 흐름도의 목적으로, 분석 엔진이 선언형 스키마에서 한정되고 LOM에서 유도된 유형으로 발화를 이미 매핑하였음을 이해하여야 한다. 표시자 객체는, 예를 들면, 분석 엔진에 의해 이미 고려되었다. 또한, 코드는 Begin 절, Success 절, 및 Failure 절을 각 요소에 대하여 포함한다고 가정된다. 또한, 몇몇 세부사항이 흐름도에서 생략되는데, 이는 이러한 세부사항이 구현에 특정적이고 설명을 불필요하게 복잡하게 할 수 있기 때문이다.

이하 도 4를 참조하면, 발화의 수신 시에, SenMailCommand의 개시 분석절은 호출된다(블록 400). 개신 분석절이 성공하지 않으면, 상이한 명령이 호출될 수 있거나, (선택적으로) 인터프리터가 특정 구현예에 따라 또는 응용 프로그램에서 이용가능할 수 있는 다른 명령에 따라 분석을 단순히 중지할 수 있다(블록 402).

SendMail 명령의 개시 분석절이 성공적으로 호출되면, SPL 인터프리터는 SendMail 명령이 사용하는 MySend 프레임에 대한 개시 분석절을 호출한다(블록 404). MySend에 대한 개시 분석절이 실패하면, SendMail 명령 실패절이 호출되고(블록 406), SPL 인터프리터는 상이한 명령을 선택적으로 호출하거나 분석을 중지한다(블럭 402).

MySend 프레임에 대한 개시 분석절이 성공하면, MailEntity 개시 분석절이 호출된다(블록 408). MailEntity에 대한 개시 분석절의 호출이 실패하면, 다음에는 통상 구현예에 특정한 것이 발생한다. 도시한 바와 같이, 특정 구현예에 따라, MailEntity 개시 분석절의 실패는 일반 실패를 암시할 수 있거나(옵션 1), 무시될 수 있거나(옵션 2), 또는 다른 동작을 발생시켜 발화 모호성을 제거할 수 있다(블록 410). 이들 "다른 동작"은 분석되고 있는 입력의 일부에 대한 상이한 제한 절을 사용하려는 것을 포함할 수 있다. 제한 절은 모호성으로 인해 심지어 완전히 상이한 제한에 대한 것일 수 있다.

실패가 일반 실패를 암시하는 것으로 이해되는 경우(옵션 1), SPL 인터프리터는 선택적으로 상이한 명령을 호출하거나 분석을 실패한다(블록 402). 실패가 무시되는 경우(옵션 2), SPL 인터프리터는 MySend 프레임의 성공적인 절을 간단히 호출하고, SendMail 명령의 성공적인 절을 호출하며, "실제 해석" 리스트에 SendMail 명령 객체를 추가할 수 있다(블록 424). 다른 동작이 개발자 코드에 의해 요구되는 경우, SPL 인터프리터는 자연어 분석 엔진과의 통신 및/또는 클라이언트 응용 프로그램을 다시 호출하여 발화 모호성을 제거하려는 등의 추가 처리를 수행할 수 있다.

MailEntity의 개시 분석절의 호출이 성공하는 경우, MailEntity 성공 절이 호출된다(블록 412). 다음으로, 제한 개시 분석절이 호출된다(블록 414). 제한 개시 분석절이 실패하는 경우, 흐름은 (상술한)블록(410)으로 진행한다. 제한의 개시 블록절이 성공하는 경우, 제한 성공절이 호출된다(블록 416). 제한절은 그 후 MailEntity 슬롯을 갖는 MySend 프레임 상에 호출된다(블록 418). 이러한 호출이 실패하는 경우, 흐름은 다시 한번 (상술한)블록(410)으로 진행한다. 호출이 성공한 경우, MySend 프레임의 성공절이 호출되고(블록 420), SendMail 명령의 성공 절이 호출되며(블록 422), SendMail 명령 객체는 "실제 해석" 리스트에 추가된다(블록 424).

코드 블록은 응용 프로그램과 개발자에 따라 거의 무한의 순열이 됨을 이해하여야 한다. 일 실시예에서, 임의의 실패 분석에 대한 기준이 실패 절을 호출하여 실행을 중지하려는 것일 수 있다. 다른 실시예에서, 개발자는 부분 객체를 인스턴스화하기를 원하여 응용 프로그램이 도메인 문맥을 사용하여 모호성을 분석하고 발화의 부분 실행을 수행할 수 있다. 수많은 가능성이 고찰될 수 있으며, 각 절에서, 개발자는 응용 프로그램 특정 기능을 수행하는 코드를 자유롭게 작성한다.

바람직한 실시예에서, RecipientEntity는 RecipientName을 슬롯으로 취하는 네임드 제한 절을 사용하여 작성될 수 있다. RecipientName은 수신자명의 인스턴스가 의미 처리가 수행되기 전에 전체 사용자 입력에 위치할 수 있도록 NamedEntity 한정될 수 있다. 이는 RecipientEntity 인스턴스의 강력한 인식을 가능하게 한다.

상술한 바와 같이 "Bob"이 유효 RecipientEntity라고 가정하면, RecipientEntity는 이 프로그램 내의 어딘가에 정의된다. 이러한 인스턴스에서, "with restriction"은 SendMailCommand에 의해 사용되는 MySendFrame 내에 있다. "with restriction" 절 내의 코드가 호출된다. "with restriction" 내의 코드는 개발자에게 일부 유연성을 제공하여 이러한 제한을 거부한다. 절이 성공하면, 제한이 승인된다. 다르게는, 다른 "with restriction" 절이 이들 중 하나가 성공할 때까지 연속으로 호출될 수 있으며, 이들 중 어느 것도 성공하지 않으면, 제한은 무시된다. 다른 실시예에서, 분석 절이 실행하는 경우, 실패 분석이 호출된다. 마지막으로, MySendFrame과 SendMailCommand의 성공 절이 이 순서대로 호출된다(블록 420 및 422).

통상, 당업자는 LOM 내에서 SPL에 의해 구현되는 제한 및 다른 객체가 성공 또는 실패의 임의 개수의 펑션 또는 프로세스를 호출하도록 구성될 수 있다. 흐름도는 예시적인 흐름이 진행하는 방식을 나타내는 단지 일 예이다. 그러나, 수많은 다른 변형이 예측되며 본 발명이 적용될 수 있는 가능한 클라이언트 응용 프로그램만큼 다양하다.

이러한 분석 처리 동안, 연결된 그래프가 작성된다. 각 엔티티는 연결 그래프의 노드이고, 엔티티들 간의 관계는 LOM으로 정의되고 응용 프로그램 도메인에 대하여 유효화된다. 당업자는 노드 및 관계가 강하게 유형화됨을 이해할 것이다. 연결 그래프는 도메인 언어에서 언급된 것을 나타낸다.

SPL 객체(명령, 엔티티, 프레임 및 제한)의 존재는 의미 분석에 관련하여 작성된 코드에 의해 분석됨을 인식하는 것이 중요하다. 통상, 프레임, 엔티티, 명령 또는 제한에 대한 분석은 응용 프로그램 도메인에 대하여 이들 객체의 존재/유효성을 분석하는 것을 포함한다. 이 객체는 이들의 제한이 충족될 때까지 실제 존재하지 않는다(유효하지 않는다). 이의 유추는 C# 객체 구성으로 작성될 수 있다. C#에서, 객체는 개발자가 예외를 처리하는 코드를 작성할 수 있는 구성을 갖는다. 이 예외는 일부 제한이 충족되지 않으면 객체의 존재를 방해한다.

"system"은 객체를 생성하려하는 경우 이들 구성자를 호출한다. 따라서, 구성자 내에 작성된 코드는 클래스의 존재를 분석할 수 있다. 개념적으로, 이의 주요 유형의 SPL 분석은 이러한 개념을 한 단계 더 취하며, 이를 유형화하고, 보다 풍요하게 하며, 시스템의 네이티브 일부가 되도록 한다. 충족되어야 하는 제한은 발화의 의미 분석과 도메인 작성 지식의 조합이다.

D3. 상속

개념 캡슐화 및 조성은 종래 객체 지향 기술(객체 재사용, 상속, 다형성 등)을 통해 달성된다. 예를 들면, "send mail to Bob"과 "send instant message to Bob"을 모델링하기 위해서, MySendFrame을 선언하여 MailEntity와 InstantMessage의 수퍼 타입을 취할 수 있다. 표 82는 본 발명의 일 실시예에 따른 MySendFrame을 나타낸다.

표 82: MySendFrame

Entity ItemEntity

{

}

entity MailEntity:ItemEntity

{

}

entity InstantMessage:ItemEntity

{

}

frame MySendFrame: send<DoneTo.what:=ItemEntity>

{

on resolve

{

with restriction Goal<goal:=RecipientEntity>

{

}

}

}

그 후, 후술하는 "send mail"과 "send instant message"에 대한 개별 명령을 정의할 수 있다.

command SendIMCommand uses MySend<DoneTo.what:=InstantMessage>;

Command SendMailCommand uses MySend<DoneTo.what:=MailEntity>;

"send item to Recipient"의 개념은 SendIMCommand와 SendMailCommand에 의해 재사용될 수 있고 MySendFrame에 의해 캡슐화된다. 또한, MySendFrame을 조성적으로 재사용할 수 있다. 이의 예가 표 83에 제공된다.

표 83: MySendFrame

entity MailEntity

{

on resolve

{

with frame MySendFrame <DoneTo.what:=this>;

}

}

넓은 의미에서, 상기 설명은 "mail sent to Bob"의 의미를 캡처한다.

통상, SPL은 응용 프로그램 도메인에 대하여 추론하고 이러한 추론이 깊고 유의미한 방식으로 분석에 영향을 미치게 하는 능력을 개발자에게 제공한다. SPL은 이러한 추론은 선언적이고 절차적으로 행해질 수 있게 한다. MailEntity 구문을 다시 참조하면, 구문은 MailEntity가 MailWord에 규정된 단어 리스트에 의해 지정된 엔티티라고 하는 선언형 제한을 설정하며, 이는 MailFolder 위치로 제한될 수 있다. 표 84는 MailEntity를 나타낸다.

표 84: MailEntity

entity MailEntity denoted by MailWords

{

on resolve

{

with restriction Location<loc:=MailFolder>;

}

}

entity MailFolder denoted by FolderWords

{

on resolve

{

with restriction Named<name:=string>;

}

}

"mail in Foo", "mail located in folder Foo" 등과 같은 발화는 MailFolder에 대한 네임드 제한 절이 모든 문자열을 허용하기 때문에 MailEntity에 대하여 성공한다.

몇몇 경우, "Foo"가 실제 현재의 사용자 우편함에서 현재 유효한 폴더인지를 판정하는 코드를 작성하는 것이 바람직할 수 있다. 이를 행하는 유일한 방식은 런 타임에 "Foo"의 유효성을 확인하는 절차 코드를 작성하는 것이다. 표 85는 런타임에 폴더명의 유효성을 점검하는 MailFolder 엔티티에 대한 구문을 나타낸다.

표 85: 절차 점검 코드를 갖는 MailFolder

entity MailFolder denoted by FolderWords

{

on resolve

{

bool haveName=false;

on success

{

return haveName;

}

with restriction Named<name:=string>

{

haveName = IsValidFolderName(Named.name);

return haveName;

}

}

}

"Foo"가 현재 유효한 폴더가 아닌 경우, MailFolder의 분석이 실패한다. 특정 구현예의 세부사항에 따라, 실패는 일반 실패를 암시할 수 있다. 다르게는, 분석의 실패는 제한의 무시를 야기할 수 있다. 일 실시예에서, MailFolder 분석이 실패하면, MailEntity는 또한 실패하여 분석 체인(예를 들면, 일반 실패를 암시)으로 계속 진행한다. 바람직한 실시예에서, MailFolder 분석이 실패하면, MailFolder 제한이 단순히 무시된다. 당업자는 이는 단지 일 예임을 이해할 것이다. 구현예에 따라, 훨씬 더 복잡한 유효성 점검이 사용될 수 있다.

이러한 효과를 달성하는 다른 방법은 NamedEntity 유형의 FolderName을 생성하여 이를 네임드 제한의 슬롯으로서 사용할 것일 수 있다.

절(begin, success, failure 및 with restriction)을 호출하는 긍정 효과는 개발자가 의미 객체를 응용 프로그램 객체에 결합하는 코드를 작성할 수 있다. 예를 들면, 네임드 제한 절에서, 개발자는 명칭이 유효하면 폴더 응용 프로그램 객체에 대한 기준을 획득하는 코드를 작성할 수 있다. 표 86은 이러한 기준에 대한 구문을 나타낸다.

표 86: 의미 객체를 응용 프로그램 객체를 결합하는 코드

entity MailFolder denoted by FolderWords

{

MAPIFolder folder;

on resolve

{

with restriction Named<name:=string>

{

folder=GetFolder(name);

if(folder=null) return false;

}

}

}

이러한 구문은 응용 프로그램 특정 객체, MAPIFolder를 의미 객체, MailFolder에 유효하게 결합한다.

통상, 개발자는 분석에서 주요 지점에서 이들의 응용 프로그램 문맥 및 상태에 대하여 추론하는 코드를 용이하게 작성할 수 있다. 이러한 추론은 마지막 분석 분석에 영향을 미칠 수 있다. 예를 들면, "Bob"이 유효한 수신자인지를 분석하기 위해서, 개발자는 시스템의 현재 사용자의 데이터베이스에 진행하는 코드를 작성할 수 있다. 그렇지 않은 경우, 개발자는 실패를 처리할 코드를 작성할 수 있다. 예를 들면, 개발자는 실패 시에 바로 사용자 명확화를 위한 팝업 윈도우 또는 대화를 표시하고, 재발화를 생성하는 등을 표시할 수 있다. 실패 시에는 사용자에게 즉시 피드백을 제공함으로써, 시스템은 현명하고 잘 개발된 응용 프로그램의 외관을 조성한다.

다르게는, 개발자는 최상위 레벨 SendMailCommand에서 응용 프로그램 적절한 상태에 있지 않은 경우 명령에 대한 분석을 방지하는 코드를 작성할 수 있다. 의미 분석과 도메인 지식에 대한 이러한 깊은 통합은 자연어를 이해하고 모호성을 제거하는데 매우 중요하다.

개발자가 분석을 거부하는 절에서 코드를 작성할 수 있게 함으로써, SPL은 개발자가 부정확한 분석의 빠른 거부를 행할 수 있게 한다. 통상, 작성자는 성공한 해석과 실패한 해석에 대한 많은 제한을 가할 수 있다. 몇몇의 경우, 작성자가 과정의 초기 단계에서 몇몇 해석을 거부하는 것이 바람직할 수 있다. 통상, 작성자가 더 일찍 모호성을 밝힘에 따라(모호성을 제거함에 따라), 응용 프로그램이 모호성을 더 용이하게 관리한다. 모호성의 감소는 보다 적은 해석을 의미한다. 자연어로 작성된 임의의 응용 프로그램은 여러 해석을 관리하는 몇몇 메커니즘을 구비하여야 한다. 작성자는 인터프리터가 분석하고 있을 때 해석의 정상여부를 평가하는 코드를 작성하거나, 의미 분석이 모호성을 제거하기 위해 행해지고 해석(후처리) 집합 중에서 선택한 후에 발생하는 코드를 작성한다. 전자가 관리 및 코딩하기에 보다 용이함을 인식하는 것은 어렵지 않다.

또한, 보다 빨리 해석이 거부될 수 있으며, 보다 빨리 그리고 보다 정확하게 최선의 해석이 발견될 수 있다.

몇몇 경우, 작성자는 프로세스에서 해석을 더 느리게 거부하기를 원할 수 있다. 보다 이른 해석의 거부는 클라이언트 응용 프로그램으로 콜백하여 상태 및/또는 문맥을 점검하여 응용 프로그램의 객체 모델에 대하여 추론하는 것을 종종 포함한다. 콜백이 네트워크 상으로 이동할 필요가 있는 경우, 콜백을 자주 호출하는 것은 시스템을 보다 느리게 동작하게 할 수 있다. 예를 들면, 전송 지연은 시스템이 사용불가능하게 할 수 있다. SPL은 작성자가 콜백이 언제 그리고 어디에 행해지는지에 대한 완전한 제어를 할 수 있게 한다. 따라서, 개발자는 콜백의 올바른 균형 및 후분석(post-analysis) 모호성이 무엇인지를 클라이언트 응용 프로그램의 속성에 따라 스스로 분석할 수 있다.

다르게는, 몇몇 구현예에서, 개발자는 분석을 거부할 지를 분석하기 전에 전체 분석에 대하여 추론하기를 원할 수 있다. 분리 시에 일부가 성공 또는 실패를 분석할 수 없고 분석된 트리에 대한 글로벌 추론이 요구하는 경우가 필요할 수 있다.

SPL은 개발자가 클라이언트 응용 프로그램의 요구 및 그들의 요구에 따라 빠른 거절과 느린 거절 간에 밸런스하는 방식을 선택하게 한다.

상술한 바와 같이, SPL 런타임에 의한 프레임, 제한, 및 엔티티의 분석은 발화의 도메인 의존 모델을 기본적으로 구축하고 있다. 이러한 발화는 구현화를 보증한다.

자연어에서, 구문 구성자는 여러 의미를 표현하는데 사용될 수 있다. 매우 간단한 예로서, 전치사 "on" 다음에 명사가 있는 경우를 고려한다. 예를 들면, 어구 "on Foo"를 고려한다. 어구 "on Foo"는 위치를 지칭할 수 있으며("book on table"에서와 같이) 또는 토픽을 의미할 수 있다("book on Seattle"에서와 같이). 어느 어구가 올바른지를 분석하기 위해서, 어구는 모호성이 제거되어야 한다. 이러한 모호성 제거는 응용 프로그램에 의해 행해질 수 있을 뿐이다. 예를 들면, 표 87은 Amazon.com을 구현하는 구문을 나타낸다.

표 87: 책 판매 구문

entity BookEntity denoted by "book"

{

on resolve

{

with restriction Topic<topic:=string>;

}

}

"book on Foo"를 분석하는 경우, 의미 분석은 Entity가 단지 토픽만을 이해하기 때문에 위치 객체를 생성하지 않을 수 있다. 언급된 것의 분석된 모델은 위치를 포함하지 않을 수 있다. 이러한 "지시(directing)"는 조정(coordination; 및/또는), 부정 및 절의 모델링에서 보다 명확해진다.

조합에서, SPL 코드는 논리곱과 논리합으로 엔티티와 이들의 수식어구가 분포되는 방식을 정의한다. "find mail and notes created yesterday" 발화에 대하여, 가능한 모델링 선택은 다음을 포함한다:

1. Find (mail created yesterday) and (notes created yesterday).

2. Find (mail) and (notes created yesterday).

3. Find (mail created yesterday) and find (notes created yesterday).

4. Find (mail) and find (notes created yesterday).

"created yesterday"와 "find"가 엔티티 "mail"과 "notes"에 분포되는 방식은 작성된 코드에 의해 분석된다. 논리합과 논리곱을 모두 포함하는 발화에 대하여 보다 많은 개수의 판독이 가능하다. 작성자는 모든 가능성을 이해할 필요는 없다. 작성자는 이들의 응용 프로그램의 의미에 대하여 고려할 뿐이다. 예를 들면, SPL 작성자로서, my FindMailCommand 만이 MailEntity 유형의 엔티티를 이해하고 my FindNotesCommand 만이 NotesEntity 유형의 엔티티를 이해하도록 FindMailCommand를 코딩할 수 있다. 더욱이, MailEntity는 생성 시간의 개념을 갖지 않지만(이는 단지 예시 목적임), NoseEntity는 그 개념을 갖는다. 따라서, 상기 발화 "find mail and notes created yesterday"에서, 의미 분석은 상기 리스트에서 판독 4만을 생성할 수 있다.

부정에 대하여, 작성된 코드는 부정 범위 모호성이 모델링되는 방식을 분석한다. 예를 들면, 발화 "Don't allow mail from Joe"를 취한다. 어구는 다음과 같이 해석될 수 있다:

1. Don't allow mail from Joe (block it instead): 부정 범위 "allow";

2. Don't allow mail from Joe (but allow messages from him): "mail"에 대한 부정 범위; 또는

3. Don't allow mail from Joe (but allow mail from someone else): "Joe"에 대한 부정 범위.

작성된 SPL 프로그램은 부정의 범위지정과 모델링되는 방식을 분석한다. 의미 분석 엔진은 모든 가능한 판독을 제공한다.

절에서, 작성된 코드는 절이 프레임 기반으로서 또는 소정 제한 중 하나로서 모델링되는지를 분석한다(동사 어두에 있는 제한). 예를 들면, "book that discusses Foo", 절, "that discusses Foo"는 토픽 제한으로서 모델링될 수 있으며, "book"에 대한 프레임 기반 제한으로서 모델링될 수 있다. 표 88는 BookEntity에 대한 구문의 일 예를 제공한다.

표 88: BookEntity

Entity BookEntity denoted by "book"

{

on resolve

{

with frame discuss<DoneTo.what:=string>;

}

}

통상, SPL의 관점에서, SPL 프로그램의 규칙은 응용 프로그램 도메인의 자연어 의미 모델을 정의하는 것이다. 의미 분석의 역할은 언어 분석 엔진의 이해에 따라 SPL 프로그램 정의 모델에 발화를 매핑하는 것이다.

플랫폼의 관점에서, 의미 플랫폼의 역할은 매우 추상적이고, 도메인 독립적인 언급된 것의 객체 모델을 정의하는 것이다. 이러한 관점에서, SPL의 역할은 플랫폼이 제공하는 가능성으로부터 선택하는 것이다.

통상, SPL 프로그램의 분석은 언급된 것의 도메인 의존 의미 모델을 구축하는 것으로서 이해될 수 있다. 이러한 도메인 의존 모델의 구축 과정에서, 도메인 독립 객체는 강하게 유형화되며 응용 프로그램 객체에 고정(매핑)될 수 있다.

E2. 유형 시스템

통상, 코어 SPL 유형은 명령, 프레임, 엔티티 및 제한이다. 이들은 분석 의미를 요구하여 이들의 존재를 분석하기 때문에 분석가능한 유형으로 불린다.

[분석이능 유형]

{

on resolve

{

begin

{

}

success

{

}

fail

{

}

}

}

"on resolve" 절 내의 모든 것은 분석 의미에 관련된다. 개시, 성공 및 실패 절은 모두 선택적이다. 이들은 "on resolve"에서 각 절 중 최대 하나일 수 있다.

개시 절은 분석이능 유형의 분석 개시에서 호출된다. 기본으로서, 절은 "참"을 리턴한다. 개발자는 SPL 인터프리터에 이러한 유형에 대한 분석 중지를 알리는 "거짓"을 리턴할 수 있다. 이는 분석 실패를 의미하며, 실패 절이 호출된다. 개시 절은 개발자가 초기화를 수행하여 응용 프로그램이 이 유형을 처리하기에 적절한 문맥/상태에 있는지를 점검하기에 편리한 장소이다.

성공 절은 유형 분석이 성공한 경우에 호출된다. 이는 개발자가 자원을 클린업하거나 분석 결과를 패키지화하는 코드를 작성할 수 있다. 개발자는 또한 거짓을 리턴하여 분석을 거부할 수 있다.

실패 절은 분석이 실패한 경우에 호출된다. 개시 및 성공 절과 같이, 실패 절은 유형의 실패 분석이 효과적으로 성공하게 할 수 있는 "false"를 리턴한다.

일 실시예에서, 모든 분석이능 유형은 명령을 제외하면 임의 개수의 제한 절을 가질 수 있다. 이는 슬롯 및 "with restriction/프레임 제한"에서 보다 상세히 설명한다. 다른 실시예에서, 명령 유형을 포함하는 모든 분석이능 유형은 임의 개수의 제한 절을 가질 수 있다. 분석이능 유형(명령, 프레임, 엔티티, 및 제한) 각각은 이하 상세히 설명한다.

명령 및 자연어(NL) 구현 작업은 클라이언트 응용 프로그램에 의해 지원된다. 클라이언트 응용 프로그램의 개발 동안, 작성자는 이들이 처리하기를 원하는 동작을 나타내는 명령을 작성한다. 명령은 응용 프로그램으로의 작업 진입점을 의미 분석에 제공한다. SPL 분석은 명령에서 개시하여 트리를 반복한다. 명령은 사용자 명령에 응답하여 호출된다. 이는 마우스 클릭과 같은 윈도우 이벤트가 사용자가 마우스를 클릭하는 것에 응답하여 호출되는 것에 유사하다. 표 89는 본 발명의 일 실시예에 따른 사용자 명령 선언의 구문을 나타낸다.

표 89: 명령 선언

Command CommandName uses FrameObject <optional slots>

{

}

예를 들면, "Command SendMailCommand uses MySendFrame"은 MySendFrame 객체를 사용하는 SendMailCommand 객체를 정의한다. 명령은 기본적으로 프레임 객체를 감싼다. 단지 하나의 프레임 객체만이 명령으로 규정될 수 있다.

명령에서 개시 절은 응용 프로그램이 명령을 처리하기에 적절한 문맥 및/또는 상태에 있는지를 점검하는 유용한 장소이다. 이는 응용 프로그램 지식에 기초하여 명령을 매우 빨리 거부할 수 있게 한다.

성공 절에서, 개발자는 직접 명령을 실행하거나 명령을 실행할 데이터가 무엇이든지 패킷화할 수 있다. 이러한 패킷화된 데이터는 URL의 형태, 작업의 XML 설명, 명령을 실행할 수 있는 펑션의 델리게이트 등일 수 있다. 작성자는 또한 성공절에서 추가 추론을 행할 수 있으며, "거짓"의 값을 리턴하여 해석을 거부할 수 있다. 이는 작성자가 전체 발화에 대하여 글로벌하게 추론할 수 있게 하기 때문에 유용하다. 즉, 작성자는 분석이 전체로서 일관하는지를 점검하기 위해서 완전 분석된 의미 트리에서 확인할 수 있다. 부분들은 한정된 문맥으로 또는 독립적으로 일관될 수 있지만, 함께 의미를 갖지 않을 수 있다.

"Unknown" 명령은 작성된 명령에 매핑하지 않는 발화를 처리하다. 일 실시예에서, SPL은 이 명령이 존재하게 한다.

통상, 프레임은 동사를 의미한다. 2가지 종류의 프레임이 존재한다: 기본 프레임 및 복합 프레임. 기본 프레임은 하나의 동사를 의미한다. 예를 들면, 프레임 find는 동사 "find"를 나타낸다. 복합 프레임은 동일한 의미를 통상 갖는 여러 동사의 그룹이다. 복합 프레임과 이의 여러 동사는 동의어 리스트로서 간주될 수 있다. 통상, 의미 플랫폼은 소정 집합의 기본 프레임을 모든 동사에 대하여 하나씩 제공한다. 일관성을 위해서, 규약에 의하면 기본 프레임명은 소문자이고 이들의 대응 어휘집 단어와 동일한 명칭을 갖는다. 이와 달리, 복합 프레임의 명칭은 대문자로 개시한다. 의미 플랫폼은 공통인 일련의 복합 프레임을 제공한다. 예를 들면, 플랫폼은 "find", "search", "look" 및 "rummage"를 함께 그룹화하는 Search 복합 프레임을 제공할 수 있다.

표 90은 기본 프레임을 정의하는 구문을 나타낸다.

표 90: 기본 프레임

frame FrameName denoted by "word" behaves as VerbClass

{

}

예를 들면, find 프레임에 대한 구문이 표 91에 도시되어 있다.

표 91: find 프레임

frame find denoted by "find" behaves as DefaultVerbClass

{

}

이 구문은 어휘집 단어 "find"에 의해 한정되고 DefaultVerbClass에서 동작하는 기본 프레임, find를 정의한다. "find"라는 용어는 프레임, find를 지칭하는 표시자이다. 의미 플랫폼은 모든 동사를 커버하는 일련의 동사 클래스 동작을 정의한다. 많은 동사는 DefaultVerbClass의 일부인 동작이다.

어휘집 단어는 인라인으로 나타낼 필요는 없다. 사실상, 다수 언어를 지원하기 위해서, 단어는 인라인으로 나타내지 않을 것이 바람직하다. 이들은 자신의 객체에 한정되어야 한다. 표 92는 정의된 표시자 객체에 대한 구문을 나타낸다.

표 92: 표시자 객체

denoter FindWord

{

English:="find";

French:="chercher";

}

프레임 정의를 갖는 인라인 대신, 이러한 방식으로 표시자 용어를 개별적으로 열거하여, 언어 의존 요소가 언어 독립 요소와는 잘 분리된다.

의미 플랫폼에 의해 제공되는 모든 기본 프레임은 이 방식으로 SPL 코드로 정의된다. 또한, 개발자는 이 방식으로 이들 자신의 동사를 정의할 수 있다. 예를 들면, 일 실시예에서, 개발자는 다음과 같은 fop 베이스 클래스를 정의할 수 있 다:

frame fop denoted by "fop" behaves as DefaultVerbClass;

다르게는, 바람직한 실시예에서, 개발자는 다음과 같은 fop 베이스 클래스를 정의할 수 있다:

frame fop denoted by "fop";

많은(약 95%) 동사는 어휘집 단어 자신으로서 언어학적 구현을 가질 수 있다. 대부분의 경우, 다른 언어로의 직접적인 번역일 수 있다. 언어에 대하여 이러한 방식으로 동작하지 않은 동사에 대하여, 표시자에서 이들 동사의 언어학적 구현을 규정하는 메커니즘이 제공된다.

상술한 바와 같이, 복합 프레임은 동사의 그룹이다. 이들은 기본적으로 동의어 리스트이다. 복합 프레임의 생성 시에, 단지 그룹 내에 사용된 프레임의 표시자가 복합 프레임에 의해 "상속"된다.

SPL은 기본 및 복합 프레임으로부터 이들 자신의 그룹을 생성할 능력을 개발자에게 제공한다. 일 예가 표 94에 제공된다.

표 94: 복합 프레임

frame CompositeName groups frame₁, ..., frame_n

except frame_x,..., frame_y

{

}

기본적으로, 이러한 선언은 group 절에 규정된 프레임의 모든 표시자의 논리적 결합을 설정하고, 중복을 제거하면 후, except 절에 규정된 프레임의 표시자를 제거한다. except 절은 선택적이다. 예를 들면, 표 95는 정의에서 except 절을 포함하는 복합 프레임을 나타낸다.

표 95: except 절을 갖는 복합 프레임

frame MySearchFrame groups Search, fop except find

{

}

이는 find 프레임의 표시자를 제외하면 Search와 fop의 표시자를 함께 그룹화하는 MySearchFrame을 정의한다.

또한, 기본 프레임 또는 복합 프레임인 다른 프레임으로부터 상속한 유도된 프레임이 생성될 수 있다. 표 96는 유도된 프레임에 대한 구문을 나타낸다.

표 96: 유도된 프레임

Frame DerivedFrame: BaseFrame<slot₁, ..., slot_n>

{

}

상속의 주어는 이하 단락 E3에서 보다 상세히 설명한다.

엔티티는 응용 프로그램에서 명칭 또는 설명에 의해 나타낼 수 있는 객체이다. 엔티티는 파일 항목 및 이메일 항목과 같은 구체적인 것일 수 있지만, 또한 색, 질감 등의 추상 개념을 나타낼 수 있다. 엔티티는 통상 어휘집 단어에 의해 나타낸다. 표 97은 엔티티를 선언하는 구문을 나타낸다.

표 97: 엔티티 선언

entity EntityName denoted by "word₁", ..., "word_n"

{

}

예를 들면:

entity MailEntity denoted by "mail", "electronic mail", "email"

{

}

프레임과 같이, 표시자는 다수 언어를 지원하기 위해서 인라인으로 규정되지 않는 것이 바람직하다. 표 98은 이러한 표시자의 일 예를 제공한다.

표 98: 표시자

entity MailEntity denoted by MailWords

{

}

denoter MailWords

{

Japanese:=noun(" "), noun(" ");

English:=noun("mail"), noun("email"), noun("electronic mail");

}

denoted by절은 작성자가 엔티티를 표시하는 자연어 단어의 리스트를 규정할 수 있게 한다. denoted by 절은 개발자가 어휘집 단어로의 엔티티에 기반하는 수단이다. 엔티티는 단어 또는 단어 그룹에 의해 표시될 필요는 없다. 엔티티는 이들의 제한에 의해 나타낼 수 있다. 개발자는 형태가 의미 플랫폼에 의해 관리되기 때문에, 여러 단어 형태("file"과 "files")를 규정할 필요는 없다. 또한, 표시자는 엔티티가 성공하기 위해서 발화 내에 규정될 필요는 없다. 그러나, 표시자가 발화 내에 포함되면, 이 표시자는 엔ㅌ티 리스트 내의 표시자들 중 하나와 일치하여야 한다.

몇몇 실시예에서, 표시자는 선언에서 선택적인 것이 바람직하다. 또한, 몇몇 구현예에서, 의무적인 표시자(엔티티의 성공을 위해 발화 내에 포함되어야 하는 단어)를 추가하는 것이 바람직할 수 있다. "의무(obligatory)" 표시자의 존재는 success 절에 포함된 코드를 통해 구현될 수 있다. 표 99는 success 절을 통해 구현된 의무 표시자의 일 예를 나타낸다.

표 99: success 절을 통한 의무 표시자 구현

entity MailEntity denoted by MailWords

{

on resolve

{

success

{

if (this.Denoter==null)

return false;

}

}

}

통상, 제한은 유형화된 의미 관계이다. 플랫폼은 소정의 기본 관계 집합을 제공한다. 관계에서 가장 중요한 것 중 하나는 한 언어 또는 교차 언어에서 모두 구문 내 변화의 정규화이다. 제한은 구문론적이 아닌 의미론적이다. 따라서, 이 제한은 개발자가 구문이 아닌 언어의 의미에 대하여 코딩할 수 있게 한다. 제한은 작성 부담을 상당히 경감하여 다른 언에서의 구현을 가능하게 한다.

몇몇 제한은 특정 의미를 갖는 시스템 한정 슬롯으로 나타난다. 상기 단락 D에서 LOM의 설명은 코드 샘플과 슬롯의 몇몇 설명을 제공한다. 몇몇 공통 제한이 아래 표 100에 열거되어 있다.

표 100: 공통 제한 리스트

제한 구문	응용 프로그램
Doer<who:=Entity>	프레임에 적용. 이는 동작을 행하는 엔티티를 나타냄. 예: "Bob opened the file", "the file was opened by Bob"
DoneTo<what:=Entity>	프레임에 적용. 동작이 행해질 엔티티를 나타냄. 예: "open the file", "the file was opened".
Location<loc:=Entity>	어딘가에 위치한 의미를 모델링. 예: "mail in Inbox", "file located on the desktop".
Time	실제 시간 표현, 예를 들면, 시점 및/또는 시간 간격으로 변환될 수 있는 표현을 모델링. 예: "delete after 3 days", "mail from yesterday", 'schedule for tomorrow from 1-3 pm".
Topic<topic:=Entity>, Topic<topic:=string>	주체 대상을 모델링. 예: "book about dogs", "book regarding dogs", "book with the subject dogs".
Source<src:=Entity>	객체 또는 소스를 모델링. 예: "mail from Bob"
Order	예: "sort in alphabetical order", "display in reverse order by name".
Cardinal	예: "3 files"
Ordinal	예; "first file"
Means<instrumnet:=Entity>	예; "search using Google", "open with Word"
Possessor<owner:=Entity>	예; "my book", "Bob's book"
Accompaniment	예: "meeting with Bob"
Degree	예: "almost in the box", "extemely red", "very large", "more to the left"
Negation	예: "not from Bob", "don't send mail", "except for Bob"
Named<name:=string>	엔티티의 명칭을 나타냄. 예: "Inbox folder", "file named foo.txt"
Modifier<mod:=Denoter>	형용사 수식어구를 나타냄. 예: "large file", "school bus"

디폴트 제한으로 불리는 특별 제한이 있다. 디폴트 제한은 분석이능 유형에 대한 미분석 또는 비인식 제한이 있는 경우 SPL 런타임에 의해 기동된다.

개발자는 프레임 기반 제한을 생성하거나 패턴을 규정하여 소정의 제한 집합 중 하나로부터 상속하여 이들 자신의 제한을 생성한다.

통상, 제한은 엔티티와 프레임뿐만 아니라 다른 제한에 적용될 수 있다. 일반 규칙으로서, SPL은 특정 제한의 적용은 의미론적으로 의미가 있는지를 실시하지 않는다. SPL은 의미 모델링을 간략화하고 또는 모호성을 감소하는 일부 예외를 갖 는다. 이 예외는 아래 표 101에 제공된다.

표 101: SPL 예외

1. 정도 제한은 제한 상에만 허용된다.

2. Doer 및 DoneTo 제한은 프레임 상에서만 허용된다.

3. 부정은 엔티티 상에서 허용되지 않는다.

제한은 다음 구문을 사용하는 형태에 적용된다:

with restriction RestrictionName<slot₁:=type,..., slot_n:=type>;

꺾음 괄호 내의 인수는 슬롯으로 불린다. "with restriction" 문장은 제한 절이라 불린다. "restriction" 라벨은 특정 문제를 방지하도록 선택되었다. 예를 들면, 제한은 "properties" 라벨일 수 있지만, 속성은 디스크립터로서 항상 동작하는 것은 아니다. 예를 들면, "수신함 우편"을 "수신함 폴더의 속성을 갖는 메일"로서 생각할 수 있다. 그러나, 이러한 동일 관계는 서수 및 기수와 같은 수량사에서 존재하지 않는다. "3 파일"이라는 어구는 "3의 속성을 갖는 파일"과 대응하지 않다. 더욱이, "property"라는 단어는 종래 프로그래밍 패러다임(예를 들면, "properties of a list box")에서 이미 사용된다. 통상, "properties"라는 용어를 많이 사용하는 것은 바람직하지 않으며, 이는 "attribute" 단어도 마찬가지다.

그 대신, 엔티티는 집합 개념을 전달하려는 것이다. SPL로의 "entity" 선언은 일련의 엔티티를 실제 규정하고, 제한의 적용은 이 집합을 제한하는 것이다. 예를 들면, 메일로 표시된 MailEntity를 선언하는 구문

entity MailEntity denoted by "mail"

은 모든 메일 항목의 집합을 나타내는 객체의 선언이다. 표 102는 엔티티에 적용된 제한에 대한 구문을 나타낸다.

표 102: 엔티티에 적용된 제한

Entity MailEntity denoted by "mail"

{

on resolve

{

with restriction Location<loc:=MailFolder>;

}

}

여기서, 메일 항목 집합은 MailFolder 위치에 제한된다.

제한을 프레임에 적용하는 것은 이 동작을 제한하는 것으로서 간주되어야 한다(프레임은 통상 동사 또는 동작을 모델링). 표 103은 제한을 갖는 프레임을 나타낸다.

표 103: 프레임 상의 제한

frame MyOpen: open<DoneTo.what:=FileEntity>

{

on resolve

{

with restriction Means<instrument:=NotepadEntity>;

}

}

여기서, 수단 제한이 MyOpen 프레임 상에 적용됨으로써, Notepad를 사용하는 파일 열기 동작을 제한한다.

동일하게 제한 상에 제한이 적용된다. 예를 들면, 기수 제한은 엔티티의 기수를 나타낸다. 어구 "3 files"는 임의의 3 파일을 의미한다. 그러나, 기수는 "처음 3 파일"에서와 같은 서수에 의해 제한될 수 있다. 표 104는 제한 상에 적용된 제한을 나타낸다.

표 104: 제한 상의 제한

restriction OrdinalCardinal:Cardinal

{

on resolve

{

with restriction Ordinal;

}

}

여기서, 제한 절은 서수를 적용하여 기술을 제한한다.

통상, 명령을 제외한 분석이능 유형은 이들에 적용된 임의 개수의 제한을 가질 수 있다. 각 제한 유형은 서명이 고유하는 한 여러번 적용될 수 있다. 표 105는 고유 서명을 사용하여 여러 제한을 갖는 프레임을 나타낸다.

표 105: 여러 제한을 갖는 프레임

frame MyOpen: open<DoneTo.what:=FileEntity>

{

on resolve

{

with restriction Means<instrument:=NotepadEntity>;

//유효 제한절

with restriction Means<instrument:=MSWordEntity>;

//서명이 고유하지 않기 때문에 무효 제한절

with restriction Means<instrument:=NotepadEntity>;

}

}

제한 절 기동하는 순서는 의미 분석에 의존한다. 통상, 이 순서는 언어학적 증거, 통계 순위, 및 도메인 의존 습득에 기초한다. 특정 구현예에서, 분석된 순서를 실시하는 메커니즘이 추가될 수 있다. SPL 런타임은 SPL의 언어 의미 및 의미 분석에 따라 제한 절을 기동한다.

상술한 바와 같이, 슬롯은 꺾음 괄호(<>)로 나타난 인수이다. 슬롯 구문은 사용 지점에서 슬롯을 서브타입화하는데 사용된다. SPL은 복수의 소정 제한 슬롯을 갖는다. 예를 들면, 의미 시스템은 Goal 제한을 다음과 같이 정의한다:

Goal<goal:=Entity>

goal 슬롯은 기본 엔티티 유형을 가지며, 도메인 독립 규정으로 불릴 수 있다. 개발자가 이러한 도메인 독립 Goal을 분석이능 유형에 적용하는 경우, 개발자는 응용 프로그램 시점에서 goal 슬롯을 서브타입화할 수 있다. 표 106은 서브타입화된 goal 슬롯을 포함하는 프레임 구문을 나타낸다.

표 106: 서브타입화된 Goal 슬롯을 갖는 프레임

frame send denoted by "send"

{

on resolve

{

//"send to ContactItem"을 모델링

with restriction Goal<goal:=ContactItem>;

}

}

여기서, 개발자는 goal 슬롯을 ContactItem에 서브타입화한다(ContactItem은 엔티티 유형이어야 한다).

제한 절의 코드에서, 제한은 객체로서 액세스될 수 있다. 표 107는 객체로서 제한을 액세스하는 구문을 나타낸다.

표 107: 객체로서 제한을 액세스

with restriction Goal<goal:=ContactItem>

{

item=Goal.goal;

}

통상, 분석이능 유형은 C++ 템플릿으로의 유사성을 사용하여 개념화될 수 있다. 예를 들면, Goal 제한은 기본형의 goal 데이터 멤버를 갖는 템플릿 Goal 클래스로서 간주될 수 있다. 그 후, 상기 Goal 제한 절에 대한 의사 C++ 코드가 다음과 같다:

bool OnGoalClause(GoalTemplateClass<ContactItem> Goal);

SPL 컴파일러는 goal 슬롯의 적절한 서브타입화를 실행한다.

분석이능 유형의 소비자는 유형의 제한 절을 서브타입화하기를 원할 수 있다. 예를 들면, 상기 send 프레임의 소비자는 다음과 같은 슬롯 구문을 사용하여 Goal 제한 절의 goal 슬롯을 서브타입화하기를 원할 수 있다:

command MySendCommand uses send<Goal.goal:=MyContactItem>;

send 프레임에 적용된 많은 Goal 제한 절이 많이 있을 수 있기 때문에, 개발자는 어느 것을 참조할 지를 규정할 수 있어야 한다.

다른 종류의 제한은 AsProperty 제한이다. asproperty 속성은 분석이능 유형의 소비자가 슬롯 구문을 사용하여 제한 절의 슬롯을 서브타입화한다. 이러한 속성은 표 108에서 나타낸 바와 같이 제한 절에서 규정된다.

표 108: AsProperty 속성

frame send denoted by "send"

{

on resolve

{

with asproperty restriction Goal<goal:=ContactItem>;

}

}

여기서, send 프레임의 개발자는 send 프레임의 Goal 제한 절이 다음과 같은 슬롯 구문을 사용하여 소비자에 의해 서브타입화될 수 있음을 선언한다:

command MySendCommand uses send<Goal.goal:=MyContactItem>;

이 선언에 의하면, MySendCommand는 send 프레임을 사용하여 send 프레임의 Goal 제한절을 MyContactItem에 서브타입화한다.

통상, asproperty 속성은 또한 send 프레임 내의 코드가 속성 구문을 사용하여 이러한 Goal 객체를 액세스할 수 있게 한다. 모든 분석이능 유형은 코드가 현재 분석가능한 제한 모음에 도달할 수 있게 하는 RestrictionCollection 속성을 갖는다. asproperty 속성을 사용하여, 표시된 제한은 표 109에 나타낸 바와 같은 속성 구문을 사용하여 액세스도리 수 있다. 예를 들면:

표 109: 속성 구문을 사용하여 표시 제한을 액세스

frame send denoted by "send"

{

ContactItem Item;

on resolve

{

with asproperty restriction Goal<goal:=ContactItem>;

success

{

//일반 구문

if(this.RestrictionCollection("Goal").count>0)

{

item=this.RestrictionCollection("Goal")[0].goal;

}

//속성 구문

if(this.Goal.goal!=null)

{

item=this.Goal.goal;

}

}

}

}

또한, 각 유형의 단지 하나의 제한이 아래 표 110에 나타낸 바와 같은 제한 슬롯의 유형에 관계없이 asproperty 속성으로 표시된다.

표 110: AsProperty 제한 한정

frame send denoted by "send"

{

on resolve

{

with asproperty restriction Goal<goal:=ContactItem>;

/불법

with asproperty restriction Goal<goal:=UserItem>;

}

}

그러나, 이 구문은 개발자에 의해 변경되어 하나 이상의 유형 제한이 다음과 같이 asproperty로 표시될 수 있다:

restriction Goal2 : Goal<goal:=UserItem>;

이는 문제점을 분석하여 프레임이 아래 표 112에 나타낸 바와 같이 분석할 수 있게 한다.

표 112: 제한 구문

frame send denoted by "send"

{

on resolve

{

with asproperty restriction Goal<goal:=ContactItem>;

//여기서의 슬롯사용이 필요한 것은 아니지만,

//문서화 목적으로 사용됨

with asproperty restriction Goal2<goal:=UserItem>;

//이 절은 "with asproperty restriction Goal2"로 기재.

}

}

제한 절에서 슬롯의 정렬에 대하여, 몇몇 제한이 시스템 슬롯으로 정의됨을 이해하는 것이 중요하다. 예를 들면, Goal 제한은 goal 슬롯으로 정의된다. 사용 지점(즉, 제한 절)에서의 서브유형화 시에, 시스템 슬롯은 표 113에 나타낸 바와 같이 규정되어야 한다.

표 113: 슬롯 정렬

restriction Goal2:Goal<goal:=Item>

{

on resolve

{

with asproperty restriction Modifier<mod:=Denoter>;

}

}

frame send denoted by "send"

{

on resolve

{

//불법

with asproperty restriction Goal2<Modifier.mod:=MyDenoters,

goal:=ContactItem>;

//불법

with asproperty restriction Goal2<goal:=ContactItem,

Modifier.mod:=MyDenoters>;

}

}

asproperty로 표시된 제한 절을 갖는 엔티티는 사용 지점에서 서브유형화된 제한 절을 가질 수 있다. 예를 들면, 표 114에 나타낸 바와 같이, ContactItem이 asproperty로 표시된 위치 제한 절을 갖는다고 가정하자.

표 114: AsProperty로 표시된 위치 제한

frame send denoted by "send"

{

on resolve

{

with asproperty restriction Goal<goal:=ContactItem

<Location.loc:=DerEntity>>;

}

}

또한, 제한 절은 obligatory로 표시될 수 있으며, 이는 절이 실행되어야 하거나, 성공 또는 유형 분석이 실행함을 의미한다. 절이 성공하기 위해서, 다음 기준이 충족되어야 한다:

1. 제한은 발화 내에 있어야 한다;

2. 절(슬롯 유형)의 선언형 제한이 충족되어야 한다; 및

3. 절(코드)에서의 절차 제한이 참으로 평가되어야 한다.

아래 표 115에서 일 예가 제공된다.

표 115: Obligatory 제한

frame send denoted by "send"

{

on resolve

{

with obligatory restriction Goal<goal:=ContactItem>;

}

}

표 115에서 프레임 구문은, send 프레임이 성공적으로 분석하기 위해서, 발화 내에 "send"의 목적으로서 ContactItem이 있어야 함을 선언한다. 따라서, "send mail"은 분석할 수 없지만, "Bob"이 분석된 ContactItem인 경우, "send to Bob"은 분석할 수 있다.

E3. SPL 상속

상속은 엔티티, 프레임, 및 제한 상에 허용된다. 현재, 명령은 상속을 지원하지 않는다. 통상, (이 시점에서)명령의 상속을 지원할 필요가 없다. 명령은 상속을 요구하지 않은 작업 엔트리 포인트이다.

모든 "상속가능" 코드는 명령이 사용하는 프레임 내에 있다. 상술한 바와 같이, on resolve 절 내의 분석 의미를 제외하면, 분석이능 유형은 단지 일반 객체이다. on resolve 절의 외부에서, SPL은 C# 상속 의미를 채택하며, 이는 당업계에 공지되어 있다. 이러한 설명을 위해서, 본 발명은 종래의 (C#) 상속 의미를 따르지 않는 on resolve 절 내의 상속 의미에 집중한다. 그러나, 특정 구현예에서, 상속을 사용하는 실제 응용 프로그램에서 특정 기능을 구현하는 종래의 C# 상속 의미에서 변하는 것이 바람직할 수 있다. 간이함을 위해서, 이 설명은 모든 이러한 가능성을 고찰하지는 않고, 간단한 설명을 하려는 시도에서 규범적인 오류를 선택한다.

우선, on resolve 절에서 펑션, 제한 절 및 변수 내에서 영역을 지정하는 것을 이해하는 것이 중요하다. 표 116은 영역의 설명을 용이하게 하기 위해서 메일 엔티티에 대한 구문을 나타낸다.

표 116: 메일 엔티티

entity Mail

{

int x;

on resolve

{

int y;

with restriction Goal<goal:=Entity>;

void foo();

}

void bar();

}

on resolve 영역에 한정된 변수는 on resolve 영역 내의 제한 절에 액세스가능하지만, on resolve 절 밖에는 액세스가능하지 않다. 상기 예에서, 정수 y는 Goal 제한 절과 함수 foo()에 액세스가능하지만, 함수 bar()에는 액세스가능하지 않다.

on resolve 절에 선언된 함수는 절에 전용이므로, 이러한 함수는 on resolve 절의 외부에는 액세스가능하지 않다. 따라서, foo()는 bar()에서 액세스가능하지 않다. 제한 절은 또한 on resolve 절에 전용이기 때문에, 이의 외부에는 액세스가능하지 않다.

유형의 영역에 선언된 변수는 outer 키워드의 사용을 통해 on resolve 절 내의 절과 함수에 액세스가능하다. 예를 들면, 정수 x는 outer.x로서 함수 foo()와 Goal 제한에 액세스가능하다. 유형 영역 내에 선언된 함수는 on resolve 절에 액 세스가능하다. 따라서, 함수 bar()는 outer.bar()로서 함수 foo()와 Goal 제한에 액세스가능하다.

on resolve 절은 확장 구성자로서 개념화될 수 있어, 이 구성자에 관한 모든 것이 구성자에는 전용이다. 이는 유도 클래스는 베이스 클래스에서 제한 절 중 임의의 것을 호출할 수 없음을 의미한다.

엔티티는 하나의 다른 엔티티로부터 상속될 수 있다. 엔티티의 어느 다중 상속도 허용되지 않는다. 베이스 엔티티의 표시자는 유도 엔티티의 표시자에 병합된다. 병합된 표시자 리스트에 표 117에 나타낸 바와 같이 계층이 없다(표시자가 평평하게 된다).

표 117: 병합 표시자 리스트

entity MailEntity denoted by "mail", "email"

{

}

entity MyMailEntity denoted by "electronic mail":MailEntity

{

}

MyMailEntity의 표시자 리스트는 "mail", "email", 및 "electronic mail"로 이루어질 수 있다.

정의에서, 유도 엔티티는 asproperty로 표시된 베이스 엔티티의 제한 절을 서브타입화할 수 있다. 예를 들면, MailEntity가 asproperty로 표시된 위치 제한 절을 가지면, MyMailEntity 정의는 다음과 같을 수 있다:

entity MyMailEntity denoted by "electronic mail":

MailEntity<Location.loc:=MyEntity>

{

}

이 코드 블록은 MyMailEntity는 MailEntity의 위치 이해를 상속하지만 실제 위치에 보다 구체성을 추가함을 나타낸다.

엔티티와 같이, 프레임은 하나의 다른 프레임으로부터만 상속할 수 있다. 어느 다중 상속도 허용되지 않는다. 정의에서, 유도 프레임은 임의의 프레임 그룹을 규정할 수 없다. 복합 프레임과 프레임 상속이 분리된다. 엔티티와 동일한 방식으로 프레임에 대한 상속을 처리할 수 있다. 복합 프레임에서, 예를 들면, 표시자 리스트는 함께 그룹된다. 몇몇 경우, 모든 프레임은 프레임이 그룹되는 경우 동일한 동작 클래스에 속하는 요건을 실행하는 것이 바람직할 수 있다. 그룹 내의 프레임이 동일한 LSS 클래스에 속할 필요가 없는 경우, 프레임과 엔티티는 동일한 방식으로 처리될 수 있다.

프레임 및 엔티티와 같이, 유도 제한은 하나의 다른 제한으로부터만 상속할 수 있다. 베이스 제한의 제한 절의 서브타입화는 또한 유도 제한의 정의에서 발생할 수 있다.

특정 제한 유형의 제한절은 베이스 유형에 진행하기 전에 유도형으로 시도된다. 이는 또한 아래 표 118에서 나타낸 바와 같은 디폴트 제한에 적용된다.

표 118; 디폴트 제한

entity MailEntity denoted by "mail", "email"

{

with restriction Location<loc:=Entity>

{

}

with restriction Default

{

}

}

entity MyMailEntity denoted by "electronic mail":MailEntity

{

with restriction Location<loc:=MailFolder>

{

}

with restriction Default

{

}

}

MyMailEntity 상의 위치 제한을 분석하는 경우, 제한 절의 기동 순서는 다음과 같다:

1. MyMailEntity.Location

2. MailEntity.Location

3. MyMailEntity.Default

4. MailEntity.Default

현재 공용/전용 제한 절의 어떤 개념도 없고 제한 절을 무효화하는 어떤 개념도 없다. 일부에서, 이는, 제한 절이 클래스 분석을 위해 사용되고 이 절이 on resolve 절에 전용이라면, 제한 절의 무효화가 거의 의미가 없기 때문에다. 그러나, 제한 절이 특정 구현예에서 무효화될 수 있게 하는 것이 바람직할 수 있다.

구현예에 따라, 유도된 클래스가 베이스 클래스 내의 멤버(메소드 및 변수)를 (분석 동안)액세스할 수 있게 하는 것이 필요할 수 있다. 베이스 클래스는 아직 분석되지 않기 때문에, 이는 문제성이 있다. 베이스 클래스가 분석될 때까지 유도 클래스가 베이스 클래스의 멤버를 액세스할 수 없는 경우, 유도 클래스는 (할당을 통해 함수에 진행하는 등)분석 동안 베이스에 다형성으로 설정되는 것이 방지되어야 한다. 어느 경우이든, 유도 클래스는 베이스가 분석되기 전에 베이스 상의 제한 절을 직접 호출할 수 있게 된다.

상속은 기존 엔티티에 추가 이해를 더하는데 사용될 수 있다. 표 118의 상기 MailEntity 코드를 다시 참조하면, MailEntity는 위치 제한을 단지 이해함을 주목하는 것이 중요하다. MyMailEntity에서 작성된 위치 논리를 영향을 미치고 토픽 이해를 추가하는 엔티티를 생성할 수 있다. 또한, 베이스와 동일한 유형의 제한 절이 아래 표 119에 나타낸 바와 같이 추가될 수 있다.

표 119: MyMailEntity

entity MyMailEntity denoted by "electronic mail":MailEntity

{

with restriction Location<loc:=MailFolder>;

}

entity MailEntityWithTopic:MailEntity

{

with restriction Topic<topic:=string>

{

//토픽 처리

}

//MyMailFolder에서 위치 처리. 다른 모든 위치가 베이스로 진행

with restriction Location<loc:=MyMailFolder>

{

}

}

제한 절이 호출되고 절에서 작성된 코드에 의해 거부되면, 인터프리터는 다형성으로 등가인 수퍼 타입 중 임의의 것에서 또는 현재 유형에서 제한 절을 호출한다. 다형성으로 등가인 것을 고려하면, 제한 유형 및 이 슬롯의 유형이 아래 표 120에 나타낸 바와 같이 모두 다형성이어햐 한다.

표 120: 다형성

entity SlotEntity2:SlotEntity1;

entity MyEntity

{

with restriction Location<loc:=SlotEntity2>

{

/*이 파일이 실패하기 때문에, 인터프리터는 슬롯을 다시 분석하지

*않고, 다형성 등가에 따라 후속 위치 절을 자동 호출할 수 있다.*/

return false;

}

with restriction Location<loc:=SlotEntity1>

{

/*이 코드는 SlotEntity1처럼 다형성으로 동작하는 SlotEntity2로

*호출됨. 이 절이 실패하면, 인터프리터는 슬롯이 등가이더라도

*토픽이 위치에 등가이지 않기 때문에 아래 토픽 제한을 자동으로

*호출하지 않을 수 있다*/

}

with restriction Topic<topic:=SlotEntity1>

{

}

}

이들이 정확히 등가가 아니더라도, 표 121에 나타낸 바와 같이 슬롯에서 서브타입화 대신에 상속을 사용할 수 있다.

표 121: 상속

entity MailEntity denoted by "mail"

{

with asproperty restriction Location<loc:=MailFolder>

{

}

}

entity MailEntity2:MailEntity<Location.loc:=MyMailFolder>

{

}

entity MailEntity3:MailEntity

{

with restriction Location<loc:=MyMailFolder>

{

}

}

"mail in Inbox"를 MailEntity3에 대하여 분석하는 경우, MailEntity3.Location 절은 MailEntity.Location 절에 우선할 수 있다. 이 경우, MailEntity3에 대한 2개의 위치 제한 절이 있다. 그러나, MailEntity2에 대해서는 단지 하나의 위치 절이 있다. 슬롯에서 서브타입화는 MailEntity2에 대한 위치가 MailEntity의 위치 제한 절에 의해 그러나 MyMailFolder 유형을 사용하여 평가되어야 하는 것과 같이 해석될 수 있다.

obligatory 속성을 사용하여 제한 절을 선언하는 경우 주의를 기울여야 함이 중요하다. 의무 절은 유형이 성공적으로 분석하기 위해서 기동 및 성공하여야 한다. 베이스 유형이 obligatory로서 절을 선언하면, 유도 클래스는 베이스로 진행하여야 하는 분석을 처리하지 않도록 보장하여야 한다. 유도형은 이들의 베이스 유형의 제한 절을 호출할 수 없다. 그 대신, 유도형은 일반 분석 의미에 의존하여 베이스에서 obligatory 제한 절을 호출한다.

E4. 분석 의미

SPL의 분석 의미는 SPL 런타임에 의해 구현된다. 런타임은 SPL의 언어 의미에 따라 발화의 도메인 의존 모델을 구성한다. 런타임은 작성된 SPL 유형에 대하여 자연어 명령을 분석하여 언어학적 규칙과 SPL 언어를 준수한다.

일 실시예에서, 유형 분석은 탑 다운 접근법을 사용하여 수행된다. 도 5는 본 발명의 일 실시예에 따른 유형 분석의 탑 다운 접근법의 간략 흐름도를 나타낸다. 우선, 런타임은 발화에 대하여 분석될 수 있는 가능한 명령을 발견한다(단계 500). 다수의 가능한 명령이 있는 경우, 하나의 명령이 분석을 선택된다(단계 502). 어느 명령도 발견되지 않으면, Unknown 명령이 호출된다(단계 504). 하나 이상의 명령이 발견되면, 런타임은 별견된 명령을 분석하려 한다(단계 506). 명령 분석이 실패하면, 런타임은 리스트 내의 다음 명령에 진행하고 더이상 가능한 명령이 없을 때까지 단계 502 내지 510을 반복한다. 명령 분석이 성공하면, 이 명령은 해석 리스트에 추가된다(단계 510). 마지막으로, 발화 내에 포함된 더이상의 가능한 명령이 없을 때까지 또는 요청 해석이 특정 개수에 도달할 때까지 런타임이 단계들(단계 502 내지 510)을 반복한다.

당업자는 분석 프로세스에서 수많은 변화가 가능함이 이해하여야 한다. 예를 들면, 특정 경우에서, 분석의 실패는 일반적인 실패를 구성할 수 있으며, 이는 프로그램이 분석을 종료하게 한다. 다른 경우에서, 실패는 유형의 실패 절의 호출을 야기할 수 있으며, 이는 분석의 실패가 되거나 되지 않을 수 있다. 또한, 실패 절, 성공 절 및 개시 절 내에서, 프로그램 개발자는 응용 프로그램 특정 코드를 자유롭게 삽입하여, 프레임워크가 수많은 방식으로 채택될 수 있게 한다. 예를 들면, 개발자는 실패 절에 코드를 삽입하여 분석의 실패가 실패가 되지 않도록 "성공" 플래그를 리턴할 수 있다. 실패한 분석은 무시될 수 있으며, 또는 다른 프로그램 코드는 프로세스가 클라이언트 응용 프로그램에 콜백하게 하여 특정 분석의 모호성을 제거하게 한다. 도면은 단지 일 예를 제공하려는 것으로서 가능한 구현예를 모두 나타내는 것이 아님이 이해되어야 한다.

도 6에 도시한 바와 같이, 명령 분석의 하나의 가능한 실시예는 다음과 같이 진행한다. 명령의 개시 절이 호출된다(단계 600). 개시 절이 실패하면, 런타임은 명령에서 나온다(단계 610). 개시 절이 성공하면, 런타임을 프레임 분석을 시도한다(단계 604). 프레임 분석이 실패하면, 프레임 실패 절이 호출되고, 구현예에 따라, 런타임은 명령 밖으로 나오거나 다른 동작을 수행할 수 있다(단계 602). 다르게는, 런타임은 성공 절을 호출한다(단계 606).

상술한 바와 같이, 본 발명의 의미 프로그래밍 언어는 프로그램 개발자가 다양한 요소의 동작에 대한 제어를 할 수 있게 한다. 따라서, 본 발명의 분석 의미는 특정 응용 프로그램에 대하여 바람직한 동작을 구현하는 수많은 방식으로 변형될 수 있다. 따라서, 분석이 실패할 때, 몇몇 경우에서, 실패를 무시하여 진행하는 것이 바람직할 수 있다. 다른 경우, 분석이 성공할 수 있도록 분석 모호성을 제거하는 단계(클라이언트 응용 프로그램으로의 콜백 등)를 취하는 것이 바람직할 수 있다. 다른 경우에서, 분석이 실패하면 분석을 단지 밖으로 나오는 것이 바람직할 수 있다.

도 7에 도시한 바와 같이, 일 실시예에서, 프레임 분석은 다음과 같이 진행한다. 프레임의 개시 절이 호출된다(블록 700). 프레임 분석이 실패하면, 실패 철이 호출되고(블록 702), 런타임은 선택적으로 다른 명령을 분석한다(블록 704).

프레임 분석이 성공하면, 런타임은 제한 절의 호출을 시도한다(블록 706)(도 4의 블록(408)과 시퀀스에 대응). 제한 절이 분석을 실패하면, 런타임은 분석에 대한 임의의 유도 태그를 고려한다(블록 708). 예를 들면, 유도형 Mail과 Note를 갖는 엔티티형 Item이 주어지면, Item을 취하는 다른 형태 SendItem에 대한 절이 Mail 또는 Note의 인스턴스에 의해 분석될 수 있다.

런타임이 유도형을 성공적으로 호출하면, 구현예에 따라, 프레임의 실패 절이 호출될 수 있으며(블록 709), 그 후, 명령의 실패 절이 호출될 수 있다(블록 702).

다르게는, 제한 절이 단순히 무시될 수 있다. 제한 절이 무시되면, 런타임은 프레임과 명령의 성공 절을 호출한다(블록 712). 그 후, 런타임은 명령 객체를 "실제 해석" 리스트에 추가하고(블록 714), 다른 명령의 분석을 시도한다(블록 704).

런타임이 성공적으로 제한 절을 호출하거나(블록 706) 분석을 위한 유도형의 발견에 성공하면(블록 708), 런타임은 제한의 성공 절을 호출한다(블록 710). 그 후, 런타임은 프레임과 명령의 성공 절을 호출하고(블록 712), 명령 객체를 "실제 해석" 리스트에 추가한다(블록 714). 그 후, 런타임은 모든 가능한 명령에 대한 분석이 시도될 때까지 다른 명령의 분석을 시도한다(블록 704).

상술한 바와 같이, 프로세스 흐름은 단지 예시 목적이며, 많은 가능한 구현예를 모두 나타내는 것은 아니다. 실제, 분석 프로세스는, 특정 구현예에 의해 분석되는 크지 않더라도 적어도 일부이다. 따라서, 나타낸 바와 같이, 제한 분석의 실패는 (블록 709 및 702에 나타낸 바와 같이)일반적인 분석 실패를 야기할 수 있거나, 또는 제한 분석이 단순히 무시될 수 있으며 명령 분석이 진행한다. 다른 실시예에서, 실패한 제한(예를 들면, 제한이 의무적이면)은 런타임이 클라이언트 응용 프로그램에 콜백하게 하거나 흐름 제어 정보를 분석 엔진에 전송하게 하여 명령의 모호성을 제거하게 할 수 있다. 이러한 분석은 통상 구현예에 특정적이기 때문에, 의미 프로그래밍 언어의 프로그래밍 구성자는 자연어 프로그래밍을 용이하게 하여 특정 구현예에 적합하게 하도록 자연어 처리를 최적화하는데 사용될 수 있다.

도 8에 나타낸 바와 같이, 제한 절 분석의 하나의 가능한 실시예는 다음과 같이 진행한다. 각각의 제안된 제한에 있어서, 제한에 대한 임의의 제한 슬롯이 있으면, 런타임은 ResolveSlot 펑션을 호출하여 각 슬롯을 분석한다(블록 800). ResolveSlot 펑션이 실패하면, 런타임은 다음 제안된 제한을 선택하고(블록 802), ResolveSlot 펑션을 다시 호출하여 슬롯의 분석을 시도한다(블록 800). ResolveSlot 펑션이 성공하면(처음에 또는 다음 제안된 제안 중 하나에), 런타임은 제한 절을 호출한다(블록 804).

제한 절이 실패하면, 런타임은 현재 클래스 내의 다형성으로 등가인 절을 검색한다(블록 806). 다형성으로 등가인 절이 현재 클래스에 발견되지 않으면, 런타임은 이의 상속 체인 내에서 하나를 검색한다(블록 808). 다형성으로 등가인 절이 발견되면, 런타임은 등가의 절을 호출한다(블록 810). 런타임은 더이상의 등가 절이 발견되지 않을 때까지 또는 등가 절이 성공할 때까지 반복한다(블록 808).

필요시에, 런타임은 디폴트 제한을 호출한다(블록 812). 모든 제한 절이 성공적으로 분석하면, 런타임은 성공 절을 호출한다(블록 814). 다르게는, 런타임은 제한을 무시하여(블록 816) 프레임의 성공 절을 호출한다(블록 818).

다른 실시예에서, 디폴트 제한 절이 실패하면, 제한은 단순히 무시된다. 이것이 상술한 바와 같은 네임드 또는 부정 제한일 때까지, 분석은 여전히 성공한다.

제한 절이 동일한 분석이능 유형 상에서 여러번 기동할 수 있음을 인식하는 것이 중요하다. 예를 들면, 명령 "show files in c: in temp folder"는 "file" 엔티티에 대한 두개의 위치 제한("in c:"와 "in temp folder")을 갖는다. 현재, 제한 절의 분석의 유일하게 구현된 정렬은, 프레임 상에 Doer와 DoneTo 제한이 우선 분석되고(이 순서로), 디폴트 제한이 마지막으로 분석된다는 점이다. 그러나, 부정 및 네임드와 같은 다른 형태에 대한 정렬을 구현하는 것이 바람직할 수 있다.

도 9에 나타낸 바와 같이, 일 실시예에서, NamedEntity 분석은 다음과 같이 진행한다. 런타임은 엔티티의 개시 절을 호출한다(블록 900). 이것이 실패하면, 런타임은 엔티티 분석 밖으로 나온다(블록 902). 엔티티의 개시 분석 절이 성공하면, 런타임은 발견되고 Entity에 대응하는 NamedEntity에 대하여 네임드 제한을 호출하려 한다(블록 904). 블록(904)은 여러 분석 단계를 겪지만 이는 간이함을 위해서 여기서 생략될 수 있다.

네임드 제한의 호출이 실패하면, 엔티티의 실패 절이 호출되고 런타임이 종료한다(블록 906). 호출이 성공하면, 런타임은 엔티티의 성공 절을 호출한다(블록 908).

본 발명의 프로그래밍 언어는 수많은 방식으로 분석 단계를 변경하는데 사용될 수 있음을 이해하여야 한다. 예를 들면, 성공 분석 절은 특정 경우에서 "false" 또는 "failure"를 리턴하도록 변형될 수 있다. 유사하게, 실패 분석 절은 특정 구현예에 따라 "참" 또는 "성공"을 리턴하도록 프로그래밍될 수 있다. 따라서, 여기서 제시된 예는 한정하려는 것이 아니며 분석 의미의 하나의 가능한 구현을 제공하려는 것이다. 수많은 변형이 예측되며, 프로그래머는 특정 자연어 응용 프로그램의 필요를 충족하는 분석을 채택할 수 있다.

디폴트 제한은 작성된 코드에 의해 처리되지 않는 제한 및/또는 런타임에 의해 이해되지 않는 제한을 분석하는데 사용된다. 디폴트 제한은 분석이능 유형마다 한번 호출되며, 항상 마지막으로 호출된다. 분석이능 유형마다 최대 하나의 디폴트 제한만이 있을 수 있다.

기본의 객체 모델은 구현예에 따라 변할 수 있다. 일 실시예에서, 기본 객체 모델은 제안된 제한을 갖는 텍스트의 토큰(요소, 항목 또는 간격)의 격자를 제공한다. 이 토큰은 격자 내에서 연속일 필요는 없다. 예를 들면, 발화 내의 다음 토큰, token₁, token₂, 및 token₃을 갖는 것으로 가정하자. 기본 하에서, 런타임은 표 122에 나타낸 격자를 생성할 수 있다.

표 122: 기본으로 생성된 격자

Span[0]

Tokens={token₁, token₂}

Hypothesis[0]

RestrictionType=restriction_i

SucceededResolution=boolean

...

Hypothesis[n]

RestrictionType=restriction_j

SucceededResolution=boolean

...

Span[n]

Tokens={token₁, token₃}

Hypothesis[0]

RestrictionType=restriction_i

SucceededResolution=boolean

...

Hypothesis[n]

RestrictionType=restriction_i

SucceededResolution=boolean

원문 텍스트는 항상 이용가능하다. SPL은 성공 분석에 참여한 텍스트의 토큰인지에 대한 정보를 작성자에게 제공할 수 있다.

통계 의미 모델링 및 학습은 SPL에 중요한 역할을 한다. 제한 절이 호출되는 순서는 언어학적 증거, 통계 순위(예를 들면, SGM), 및 자동 학습에 따라 몇몇 통계에 의존할 수 있다. 도 10에 도시한 바와 같이, 시스템(1000)은 런타임(1002)과 데이터베이스(1004)를 포함한다. 통상, 런타임(1002)은 발화 및 분석 결과의 저장소인 데이터베이스(1004)를 관리할 수 있다. 이러한 저장소 내의 데이터는 분석의 특정 임계치에 도달한 후에 (예를 들면)분석 도구(1006)에 의해 마이닝되어 (오프라인)분석될 수 있다. 데이터베이스(1004) 내의 정보는 분석 도구(1006)에 의해 분석될 수 있으며, 그 후, 이 결과는 런타임(1002)에 피드백되어 이의 선택과 피드백되어 분석할 명령의 순서 및 제한 절의 호출 순서를 개선할 수 있다. 그 결과, 보다 많은 발화가 분석됨에 따라, 분석은 작성된 코드의 변화없이 보다 우수하고 빠르게 수행될 수 있다. 넓은 의미에서, 시스템(1000)은 기록의 필요없이 이 성능을 개선할 수 있는 지능형 시스템이다.

일 실시예에서, 개선된 작성자는 저장소에 대하여 관리 및 프로그램할 수 있다. 다른 실시예에서, 개선된 작성자는 단지 참/거짓 값 대신에 절에서 확신 레벨을 나타내는 확률을 리턴할 수 있다. 이는 프로그래밍 모델을 복잡하게 할 수 있지만, 불리언 값 대신에 확신 레벨을 유도할 능력은 작성자가 의미 분석에 통계적으로 참가할 수 있게 한다.

통상, 모호성은 SPL 클라이언트에서 작성자에 제공되어 처리된다. 이 코드에 의해 처리되지 않은 모호성은 여러 해석을 발생시킨다. 런타임은 해석 순위를 정하여, 응용 프로그램에 의해 규정된 최대 해석 수까지 응용 프로그램에 리턴한다. 일 실시예에서, 해석 리스트는 (API 콜의 일부로서)동기적으로 리턴된다. 다른 실시예에서, 해석은 이벤트를 사용하여 비동기로 리턴된다.

런타임은 리스트로부터 의미론적으로 등가인 해석을 제거한다. 또한, 런타임은 두개의 해석의 의미 증거를 분석하는 기본 구현을 제공한다. 기본 구현은 작성자에 의해 무효화될 수 있다.

일 실시예에서, 의미 등가는 의미 해석을 재발화하여 생성되는 문자열을 비교하여 분석된다. 그러나, 다른 기술이 또한 등가를 분석하는데 사용될 수 있다.

통상, 개발자는 발화에서 발생할 수 있는 모든 가능한 제한을 처리하는 코드를 작성할 필요가 없다. 작성자는 단지 이해 및 처리하기를 원하는 제한에 대하여 코딩할 뿐이다. 미작성/미처리 제한이 제거된다. 즉, 미작성/미처리 제한은 발화 내에서 발생하지 않은 것처럼 무시된다. 단지 예외는 처리되어야 하는 부정 및 네임드 제한이다.

의미는 상속을 사용하여 구현된다. 분석이능 유형은 모두 기본 클래스에서 상속한다. 따라서, 베이스 엔티티, 베이스 프레임 및 디폴트 제한 클래스가 있다. 기본 분석이능 유형은 표 123에 나타낸 바와 같이 하나의 제한 절, 기본을 갖는다.

표 123: 베이스 분석이능 유형

[분석이능 유형]

{

with restriction Default

{

// 미처리/미분석 제한이 부정이거나 네임드이면, 분석을 실패.

// 다르게는, 분석 절이 성공.

if(Default.TopHypothesis.RestrictionType==Negation||

Default.ToHypothesis.RestrictionType==Named)

{

return false;

}

else

{

return trune;

}

}

}

베이스 분석이능 유형에서 디폴트 제한은 부정 및 네임드를 제외한 모든 제한에 대하여 성공한다. 표 124는 메일 엔티티에 대한 구문을 나타내다.

표 124

entity MailEntity denoted by "mail"

{

on resolve

{

with restriction Location<loc:=MailFolder>;

}

}

"mail received yesterday"와 같은 발화에서, SPL 런타임은 MailEntity의 작성된 제한 절에 대하여 "received yesterday"의 분석을 시도한다. "received yesterday"는 위치 제한에 매핑하지 않을 수 있고 MailEntity 내에 디폴트 제한이 없을 수 있기 때문에, SPL 런타임은 엔티티인 MailEntity의 베이스에 대하여 "received yesterday"를 분석하려 한다. 엔티티에서 디폴트 제한 절은 참이고, 따라서, MailEntity 분석이 성공한다. 분석은 단지 "mail"이 발화 "mail received yesterday"에서 인식된 것처럼 성공한다.

이것이 원하는 동작이 아니면, 개발자는 표 125에 나타낸 바와 같이 미인식/미처리 제한을 거절하는 코드를 용이하게 작성할 수 있다.

표 125: 미인식 제한을 처리하는 코드를 갖는 MailEntity

Entity MailEntity denoted by "mail"

{

on resolve

{

with restriction Location<loc:=MailFolder>;

// 미인식된 모든 것을 거절

with restriction Default

{

return false;

}

}

}

여기서, MailEntity 내의 디폴트 제한 절은 베이스 엔티티가 호출되기 전에 점검된다. 따라서, "mail received yesterday"는 MailEntity에 대하여 성공적으로 분석하지 않을 수 있다.

통상, on resolve의 영역 밖은 모든 것은 종래 C# 규칙에 따라 처리된다. 분석 절 내의 코드도 또한 C# 코드이다. 따라서, 이들 구성을 분석하는 특정 코드를 사용하여 특화된 C# 클래스로서 분석이능 유형을 간주할 수 있다.

E5. LOM 프로그래밍

LOM 프로그래밍은 LOM에 의해 제공된 제한을 사용하여 의도한 결과를 달성하는 것을 포함한다. 이는 몇몇 예를 통해 가장 잘 이해할 수 있다. 따라서, 다음 설명은 다수의 예를 제시하고, 보다 복잡한 의미 모델링 제한과 절(조정, 비교, 부정 등)을 살펴보며, 일부 "최적"의 실시를 설명한다. 어떤 종류의 발화가 어느 제한과 이 제한이 포함하는 정보를 생성하는지에 대한 세부설명은 단락 D에 상술하였다.

LOM의 모든 제한 유형이 SPL에 노출된 것은 아니다. SPL은 명령 및 제어 시나리오에 대한 제한 유형을 집중한다. 이와 달리, LOM은 훨씬 넓은 이용가능성을 갖는다. 새로운 릴리스가 이용가능하게 됨에 따라, 이전에 커버되지 않은 의미 관계를 새로운 제한 유형으로 나타내는 것이 후행 호환성의 이유로 추후 릴리스에서 노출된 제한 유형을 좁히거나 변경하려 하는 것보다 용이할 수 있다. 아래 설명에서, SPL 코드를 모델링하는 제한을 사용하는 방식에 대부분 집중한다. 통상, 제한은 사용자에 대하여 마이크로소프트

의 .NET 런타임에 대한 프레임워크 클래스 라이브러리(FCL)와 유사한 클래스 라이브러리로서 공표된다.

대동 제한은 호스트를 수반하는 엔티티를 모델링한다. 대동은 엔티티와 프레임 상에서 허용된다. 몇몇 예는, meeting with my manager, chat with Bob, email with attachments, 및 merge File A with File B를 포함한다. 대동 제한은 호스트를 수반하는 엔티티를 나타내는 유형 엔티티의 하나의 시스템 슬롯, accomp를 포함한다. 작성자는 표 126에 나타낸 바와 같이 호스트를 수반할 수 있는 엔티티 유형을 제한할 수 있다.

표 126: "email with attachments"

entity MailEntity denoted by "email"

{

on resolve

{

with restriction Accompaniment<accomp:=AttachmentEntity>;

}

}

AsBeing 제한은 동사가 동작하는 DoneTo.what 엔티티의 몇몇 속성을 선택한다. AsBeing 제한은 프레임 상에 허용된다. 몇몇 예는, "show status as busy", "save as text file" 및 "make the font large"를 포함한다. AsBeing 제한은 하나의 시스템 슬롯, restr을 가지며, 이는 선택되고 있는 제한을 나타낸다. 임의의 제한 유형이 슬롯을 채울 수 있게 하는 대신, 제한 유형은 특정 제한 유형에 제한된다. 제한은 시스템 슬롯에서 여러 지원된 유형을 취하는 과도한 AsBeing제한을 제공하여 특정 유형에 한정된다. 다음 제한이 지원된다(예를 들면):

AsBeing<restr:=Modifier>: "mark message as low priority"

AsBeing<restr:=Possessor>: "make this file mine"

AsBeing<restr:=Ordinal>: "put this message first"

몇몇 실시예에서, "log in as my manager"와 같은 어구는 성공적으로 분석할 수 있다. 그러나, 이는 슬롯형으로서 엔티티가 허용되도록 요구한다.

AsBeing 제한은 동사, 이의 DoneTo.what 엔티티, 및 이러한 엔티티의 제한 간의 3자 관계를 정의한다. SPL은 이의 관계의 강한 결합을 실행하지 않으며, 최선의 실시는 표 127에 나타낸 바와 같이 관계를 실행하는 것일 수 있다.

표 127: "show my status as busy"

denoter BusyWords

{

English:="busy";

}

entity StatusEntity

{

on resolve

{

// "busy status", "status is busy"를 모델링

with restriction Modifier<BusyWords>;

}

}

/* 다음의 AsBeing 제한은 "show status as busy"를 결합 강도의 가변 레벨로 결합한다 */

frame ShowStatusFrame<DoneTo.what:=StatusEntity>

{

on resolve

{

/* 여기서, DoneTo.what 또는 이의 수식어구에 강한

결합을 하지않음*/

with restriction AsBeing<BusyWords>;

/* 여기서, StatusEntity의 수식어구를 사용하여 보다 강한 결합

(2개)를 선언하지만, 동사의 DoneTo.what에 강하게

연결하지 않는다. */

with restriction AsBeing

<typeof(StatusEntity.Modifier.mod)>;

/* 여기서, 프레임의 DoneTo.what 엔티티와 이의 수식어구를

사용하여 매우 강한 결합(3개)을 선언한다*/

with restriction AsBeing<typeof(DoneTo.what.Modifier.mod)>;

}

}

기수 제한은 수량사(예를 들면, "3 파일")로 표현된 기수를 모델링한다. 기수 제한은 엔티티 상에 허용된다. 기수 객체, Cardinal.number가 있으며, 이는 표 128에 나타낸 바와 같은 실제 기수값을 제공한다.

표 128: "3 email"

entity MailEntity denoted by "email"

{

int CountOfEmail;

on resolve

{

with restriction Cardinal

{

CountOfEmail=Cardinal.number;

}

}

}

비교 제한은 하나의 엔티티와 다른 명시적으로 식별된 엔티티와의 비교를 모델링한다. 비교할 엔티티 또는 엔티티들은 묵시적으로 남겨지는 "bigger file"과 같은 표현에 사용되지 않는다. 두개의 시스템 슬롯은 비교에 한정된다: dimension, 이는 비교가 수행되는 차원이고, compareTo, 이는 비교되는 엔티티이 다. 예를 들면, "bigger file than mydoc.txt"에 대하여, "bigger"는 비교의 차원이고, "mydoc.txt"는 compareTo 엔티티이다. dimension은 제한 유형이다. 통상, 비교 제한은 엔티티의 일부 속성에 대한 두개의 엔티티의 비교이다.

비교의 몇몇 예는 "book more about cats than dogs", "mail larger than 10KB", 및 "make font smaller than 12pts"를 포함한다. 몇몇 실시예에서, dimension 제한은 이에 부착된 Degree 수식어구를 갖는다는 요건을 구비하는 것이 바람직할 수 있다. 예를 들면, "file big than mydoc.txt"라는 어구는 dimension 제한이 제한 유형이 아니기 때문에 분석하여서는 안된다.

정도 제한은 제한의 정도를 모델링하고, 제한 상에 허용된다. 이는 very, extremely, slightly, alomost, more, less, most 및 least와 같은 단어를 함께 그룹화한다. 몇몇 예는 "almost in the box", "extremely red", "very large" 및 "more to the left"를 포함한다. 그룹화된 단어는 "degree-ness"를 나타내는 집합으로 카테고리화된다. 정도 유형은 다음과 같다:

More: bigger, more relevant

Most: biggest, most relevant

Less: less relevant

Least: least relevant

Same: as big

High: very big, extremely popular

Low: not very big

"smaller"는 "less big"이 아닌 "more small"로서 모델링됨이 이해되어야 한다.

"10KB larger file"과 같은 발화에 있어서, 이는 "more"(정도)를 변형하는 "10KB" (수식어구) 및 "large"를 변형하는 결합된 "10KB more" 개념으로서 변형된다. 이와 달리, "10KB large file"라는 발화는 ("large, 10KB file"과 등가인) "file" 엔티티 상에서 두개의 수식어구 제한 "10KB" 및 "large"로서 모델링된다. 표 129는 "large"를 표시하는 어휘집 단어의 표시자 리스트에 대한 구문과 제한이 적용되는 파일 엔티티에 대한 구문을 나타낸다.

표 129: "LARGE" .//"large"를 표시하는 어휘집 단어

denoter LargeWords

{

English:="large", "big"

}

/* 이를 변형하는 몇몇 MeasureEntity를 가져야 하는 정도를 정의. 이는 "10KB more"와 가은 발화를 모델링 */

restriction ExtentDegree:Degree

{

on resolve

{

with obligatory restriction Modifier<mod:=MeasureEntity>;

}

}

/* 수식어구가 LargeWords이어야 하는 수식어구 제한을 정의 */

restriction LargeModifier:Modifier<mod:=LargeWords>;

/* 정도 제한을 가져야 하는 LargeModifier 제한을 정의. 이는 "larger", "less large" 및 "very large"와 같은 발화를 모델링 */

restriction LargeDegreeModifier:LargeModifier

{

on resolve

{

with obligatory restriction Degree;

}

}

/* ExtentDegree 제한을 가져야 하는 LargeModifier를 정의. 이는 "10KB larger"를 모델링 */

restriction LargeExtentDegreeModifier:LargeModifier

{

on resolve

{

with obligatory restriction ExtentDegree;

}

}

// 이들 제한을 엔티티에 적용

entity FileEntity denoted by "file"

{

on resolve

{

// "large file"

with restriction LargeModifier;

// "10KB file"

with restriction Modifier<mod:=MeasureEntity>;

// "larger filer", "extremely large file",

"less large file", "less large file" 등

with restriction LargeDegreeModifier;

// "10KB larger file"

with restriction LargeExtentDegreeModifier;

// "larger file than mydoc.txt"

with restriction Comparison<dimension:=LargeDegreeModifier,

compareTo:=FileEntity>;

// "10KB larger file than mydoc.txt"

with restriction Comparison<dimension

:=LargeExtentDegreeModifier, compareTo:=FileEntity>;

}

}

통상, "more large" 및 "10KB larger"에 대한 개별 제한 유형을 생성할 필요는 없다. 이들 모두는 LargeModifier 아래에 배치될 수 있다. 그 후, FileEntity와 같은 소비자는 필요시 표 130에 도시한 바와 같이 발화 내의 "10KB more" 및 "more"의 존재에 대하여 LargeModifier의 RestrictionCollection 속성을 단순히 점검한다.

표 130: 큰 수식어구

Restriction LargeModifier:Modifier<mod:=LargeWords>

{

on resolve

{

with restriction Degree;

with restriction ExtentDegree;

}

}

entity FileEntity denoted by "file"

{

on resolve

{

/* "large file", "larger file", "10KB larger file" */

with restriction LargeModifier

{

if(LargeModifier.RestrictionCollectoin("Degree").count>0)

{

...

}

...

}

}

}

Doer 제한은 동작을 행하는 엔티티를 나타내며, 프레임 상에서 허용된다. 예를 들면, "Bob opened the file" 또는 "the file was opened by Bob"은 모두 Doer 제한을 트리거한다. Doer 제한은 실제 행위자를 나타내는 엔티티 유형인 하나의 시스템 슬롯, 'who'를 포함한다.

통상, 프레임이 명령에 의해 사용되는 경우, Doer는 컴퓨터이다. 그러나, 프레임은 프레임 기반 제한으로서 사용되는 경우(예를 들면, "file opened by Bob"), 행위자의 아이덴티티가 관련된다. 작성자는 Doer 제한을 사용하여 행위자의 유형을 강요할 수 있다.

모든 베이스 프레임은 Doer 제한은 asproperty로 정의되어 표 131에 나타낸 바와 같이 소비자에서 용이한 서브타입화를 가능하게 할 수 있다.

표 131: 베이스 프레임(오픈)

frame open denoted by "open" behaves as DefaultVerbClass

{

on resolve

{

with asproperty restriction Doer<who:=Entity>;

}

}

// open 프레임을 사용하지만 Doer.who의 유형을 강요하지는 않음

command OpenFileCommand uses open

{

}

entity FileEntity denoted by "file"

{

on resolve

{

// FileUserEntity로의 파일을 오픈할 수 있는 엔티티를 강요

with frame open<Doer.who:=FileUserEntity>

{

}

}

}

DoneTo 제한은 동작이 행해질 엔티티를 나타낸다. 예를 들면, "open the file"과 "the file was opened"는 DoenTo 제한을 호출한다. 이는 동작의 객체를 나타내는 엔티티 유형의 하나의 시스템 슬롯인 what을 포함한다.

모든 베이스 프레임은 DoneTo 제한이 asproperty로 정의되어 표 132에 나타낸 바와 같이 소비자 사이트에서 서브타입화를 용이하게 할 수 있다.

표 132: 베이스 프레임 오픈

// 베이스 프레임, 오픈

frame open denoted by "open" behaves as DefaultVerbClass

{

on resolve

{

with asproperty restriction Doer<who:=Entity>;

with asproperty restriction DoneTo<who:=Entity>;

}

}

// open 프레임을 사용하고 DoneTo.what을 FileEntity에

// 구속하는 명령을 정의

command OpenFileCommand uses open<Doneto.what:=FileEntity>

{

}

Goal 제한은 동작 또는 변형의 종점을 모델링한다. Goal 제한은 프레임 상에서 허용된다. 몇몇 예들은 "send mail to Bob", "change password to XXX"를 포함한다. 표 133에 나타낸 바와 같이 종점을 나타내는 엔티티 유형의 하나의 시스템 슬롯, goal을 갖는다.

표 133: "send mail to Bob"

frame MySendFrame:send<DoneTo.what:=MailEntity>

{

on resolve

{

with restriction Goal<goal:=RecipientEntity>;

}

}

반복 제한은 동작의 반복을 모델링하고, 프레임 상에 허용된다. 예를 들면, "print 3 times"는 표 134에 나타낸 반복 제한을 트리거한다.

표 134: 반복 제한

// "3번 인쇄"

frame PrintFrame:print

{

int NumberOfIterations;

on resolve

{

with restriction Iteration

{

NumberOfIterations=Iteration.Number;

}

}

}

위치 제한은 어딘가에 위치한 의미를 모델링한다. 위치 제한은 프레임과 엔티티에 허용된다. 예를 들면, "mail in Inbox", "file located on the desktop", 및 "search the web"은 위치 제한을 모두 트리거한다. 이는 표 135에 나타낸 바와 같이 실제 위치를 나타내는 엔티티 유형의 하나의 시스템 슬롯, loc을 갖는다.

표 135: 위치 제한

frame SearchFrame:search // "웹 검색"

on resolve

{

with restriction Location<loc:=WebEntity>;

}

}

수단 제한이 프레임 상에 허용되며, 단락 D에서 LOM 내에 상세히 설명한다. 수식어구 제한은 프레임, 엔티티 및 제한 상에 허용된다. 수식어구 제한은 "large file", "school bus", "font that is red" 및 "print slowly"와 같은 형용사 수식어구를 나타낸다. 이는 형용사를 나타내는 표시자 유형의 하나의 시스템 슬롯, mod를 갖는다. "MSN consumer application"과 같은 명사-명사 복합어에서, 이는 다음과 같이 모델링될 수 있다:

Modifier("MSN") and Modifier("consumer") on Entity("application");

Modifier("MSN consumer") on Entity("application");

Modifier("MSN") and Entity("consumer application"); 및/또는

Entity("MSN consumer application")

네임드 제한은 엔티티의 명칭을 나타낸다. 몇몇 예는, "Inbox folder", "file named foo.txt", "file with the name foo.txt", "open foo.txt" 및 "the file foo.txt"를 포함한다. 시스템 슬롯, name은 표 136에 나타낸 바와 같이 실제명칭이다.

표 136: "명칭이 foo.txt인 파일"

entity FileEntity denoted by "file"

{

on resolve

{

with restriction Named<name:=string>

{

// Named.name은 "foo.txt"를 포함

}

}

}

호스트 상의 부정 제한은 그 제한 절이 부정되는 것이 아닌 호스트가 부정됨을 의미한다. 몇몇 예는 "don't allow mail from Joe" 및 "mail not from Joe"를 포함한다. 표 137는 부정을 갖는 프레임에 대한 구문을 나타낸다.

표 137: 부정을 갖는 프레임

// "look on the table"

frame LookFrame:look

{

on resolve

{

with restriction Negation

{

// "don't look"을 모델링

}

}

}

restriction NegatedLocation:Location<loc:=TableEntity>

{

with restriction Negation

{

// "not on the table"을 모델링

}

}

발화는 부정을 갖지만 SPL 코드는 부정 제한 절을 갖지 않은 경우, 발화는 분석에 실패할 수 있다. 이는 작성되지 않은 경우 단지 드롭되는 다른 제한과는 상이하다.

부정 제한은 엔티티 상에 허용되지 않는다. SPL에 있어서, 엔티티가 발생하는 "universe"는 엔티티가 사용되는 방식에 의존하므로, 엔티티의 부정은 필요하지 않다. 예를 들면, "Display everything but the mail"과 같은 발화에서, 범용(universe)는 응용 프로그램이 디스플레이할 수 있는 모든 것이지만, 응용 프로그램이 모델링하는 모든 엔티티일 필요는 없다. "don't allow mail from Bob"의 발화에서, 허용 또는 허용하지 않을 수 있는 것의 범용은 단지 메일에 매우 제한될 수 있으므로, 메일의 부정은 이 경우 의미가 없다. 이러한 이유로, 엔티티 부정은 "!" 구문을 사용하여 엔티티의 소비자에 의해 처리될 수 있다.

부정 영역 모호성 제거는 SPL 코드에 의해 분석된다. 예를 들면, "don't look on the table"은 다음 부정 영역 모호성을 가질 수 있다:

Don't look on the table(but sit on it instead): look 프레임 상의 부정 영역

Don't look on the table(but look under it): 위치 제한 상의 부정 영역, 또는,

Don't look on the table(but look on the chair): Location.loc 엔티티 상의 부정 영역.

의미 해석은 코드가 작성되는 방식에 따라 분석된다. 사실상, 작성된 코드에 따라, 모든 판독은 성공적으로 분석할 수 있기 때문에, 여러 해석을 생성한다. 런타임은 항상 영역 모호성의 선호를 가지므로 여러 해석의 순위가 분석된다. 표 138은 부정을 모델링한다.

표 138: 부정 영역

// "Look"에 대한 부정 영역

// "don't look on the table(but sit on it)"

frame LookFrame:look

{

on resolve

{

with restriction Negation;

with restriction Location<loc:=TableEntity>;

}

}

// 위치에 대한 부정 영역을 모델링

// "don't look on the table(but look under it)"

frame LookFrame:look

{

on resolve

{

with restriction NegatedLocation<loc:=TableEntity>;

}

}

// Location.loc 엔티티에 대한 부정 영역을 모델링 -- "don't look on the

// table(but look on the chair)"

frame LookFrame:look

{

on resolve

{

with restriction Location<loc:=!TableEntity>;

}

}

"!" (NOT) 구문은 표 139에 나타낸 바와 같은 약식 표기로서 프레임 및 제한에 적용될 수 있다.

표 139

// look에 대한 다음 부정은 등가이다. 제1은 작성자가 부정을 처리하는

// 명령 코드를 삽입할 수 없게 하지만, 제2는 LookFrame은 가능하다

// 즉, 부정 절을 허용.

command NegatedLook uses !look;

frame LookFrame:look

{

on resolve

{

with obligatory restriction Negation;

}

}

command NegatedLook2 uses LookFrame;

restriction NegatedLocation:Location<loc:=TableEntity>

{

on resolve

{

with obligatory restriction Negation

}

}

// 유사하게, 부정 절에서 코드를 가질 능력을 제외하면,

// 다음 부정 위치가 등가이다.

frame LookFrame:look

{

on resolve

{

with restriction !Location<loc:=TableEntity>;

with restriction NegatedLocation;

}

}

서수 제한은 시퀀스 내의 몇몇 위치 개념을 표현하는 previous와 같은 수수 및 다른 수식어구를 모델링한다. 몇몇 예는, "first file", "third book" 및 "last email"을 포함한다. 서수 제한은 표 140에서 나타낸 바와 같이 기수("3") 제한을 변형하는 서수("first") 제한으로서 모델링되는, 예를 들면 "first 3 books"와 같은 다른 제한에 적용될 수 있다.

표 140: 서수 제한

// "first 3" 모델링

restriction OrdinalCardinal:Cardinal

{

int Position;

on resolve

{

with obligatory restriction Ordinal

{

Position=Ordinal.distance;

}

}

}

entity FileEntity denoted by "file"

{

on resolve

{

// "first file"

with restriction Ordinal;

}

}

소유자 제한은 엔티티의 소유자를 모델링하고, 엔티티에 적용된다. 몇몇 예는 "my book"과 "Bob's book"을 포함한다. 엔티티 유형의 시스템 슬롯, owner는 엔티티의 소유자를 나타낸다. "Bob's book"에서와 같이 소유자가 명시적으로 언급되면, "Bob"이 owner 슬롯에 대하여 분석될 수 있다. "her file"에서와 같이 소유자가 대명사이면, 런타임이 어두 반복 분석을 통해 대명사를 분석하려 한다. 이러한 어두 반복 분석이 소유자 엔티티의 발견을 실패하면, owner 슬롯은 널이 될 수 있다. 표 141은 소유자 제한에 대한 구문을 나타낸다.

표 141: 소유자 제한

entity FileEntity denoted by "file"

{

on resolve

{

with restriction Possessor<owner:=Entity>;

}

}

수량사 제한은 엔티티 상에 허용되며, 수량 표현을 모델링한다. 몇몇 예는 "all files", "a few books", 및 "one third of the page"를 포함한다. 다음은 수량사 유형이다:

All: all ((of) the), every, each (of the)

None: no, none (of the)

Some: some (of the)

Most: most (of the), the majority of

Many: many (of the)

Few: few (of the), not many (of the)

Percentage: a half of, 1/3 of, 40% of

몇몇 실시예에서, 수량사와 서수 간의 계층 관계가 존재할 수 있다.

정렬순서 제한은 정렬의 스타일을 모델링한다. 몇몇 예는 "sort in alphabetical order"와 "display in reverse order by name"이다. 이 제한은 표 56에 대하여 상세히 설명한다.

시간 제한은, 실제 시간 표현, 즉, 시점 및/또는 시간 간격으로 변형될 수 있는 시간 표현을 모델링한다. 예들은, "delete after 3 days", "mail from yesterday", 및 "schedule for tomorrow from 1-3 pm"을 포함한다. 시간 제한은 상기 단락 D에서 상세히 설명하였다.

토픽 제한은 주요 사상을 모델링한다. 몇몇 예는, "book about dogs", "book, regarding dogs" 및 "book with the subject dogs"를 포함한다. 토픽 문자열을 나타내는 string 유형의 하나의 시스템 슬롯, topic을 갖는다. 이러한 제한은 상기 단락 D에서 상세히 설명하였다. 표 142는 토픽을 갖는 BookEntity 코드 블록을 나타낸다.

표 142: BookEntity

// 개에 대한 책

entity BookEntity denoted by "book"

{

on resolve

{

with restriction Topic<topic:=string>

{

// topic은 토픽 문자열 "dogs"를 포함할 수 있음

}

}

}

논리곱("and")과 논리합("or")은 명령, 엔티티 및 제한에 발생할 수 있다. 논리곱 및 논리합은 조정의 머리말에 해당한다. 통상, 조정의 모호성은 엔티티와 수식어구가 논리곱과 논리합에 대하여 분포되는 방식으로부터, 그리고, 여러 "and" 및 "or" 연산자를 갖는 발화 내의 모호성을 괄호를 묶는 것에 기인한다. 부정과 같이, 이러한 모호성 제거는 작성된 코드에 의해 분석된다. 예를 들면, 발화 "find mail and notes created yesterday"에 대하여, SPL 작성자는 다음과 같이 이를 모델링할 수 있다:

a. (Find (mail created yesterday) AND (notes created yesterday)).

b. (Find (mail) AND (notes created yesterday)).

c. (Find (mail created yesterday)) AND (Find (notes created yesterday)).

d. (Find (mail)) AND (Find (notes created yesterday)).

"created yesterday"와 "find"가 엔티티 "mail"과 "notes"에 분포되는 방식은, 작성된 SPL 코드에 의해 분석된다. 설명의 목적을 위해서, 작성자는 유형 MailEntity의 엔티티만을 이해하는 FindMailCommand와 유형 NotesEntity의 엔티티만을 이해하는 FindNotesEntity를 코딩한다고 가정하자. 더욱이, 작성된 코드는 MailEntity가 생성 시간 개념을 갖지 않지만, NotesEntity는 표 143에 나타낸 바와 같이 갖도록 제공한다.

표 143: 조정

command FindMailCommand uses find<DoneTo.what:=MailEntity>;

command FindNotesCommand uses find<Doneto.what:=NotesEntity>;

entity MailEntity denoted by "mail"

{

}

entity NotesEntity denoted by "notes"

{

on resolve

{

with frame CreateNotesFrame;

}

}

frame CreateNotesFrame:create<DoneTo.what:=NotesEntity>

{

on resolve

{

with restriction Time;

}

}

이러한 작성된 코드를 사용하여, 발화 "find mail and notes created yesterday"에 있어서, 의미 분석은 (d) 상기 리스트에서 판독을 생성한다("Find (mail) and find (notes created yesterday)"). SPL 작성자는 모든 가능성을 이해할 필요는 없다. 작성자는 이들의 응용 프로그램의 의미만을 생각할 수 있다(예를 들면, MailEntity는 생성 시간을 이해하지 않지만, NotesEntity는 이해한다).

조정 엔티티는 "and" 또는 "or"의 조정 유형으로 함께 연결된 엔티티 리스트로서 나타낸다. 리스트 내의 모든 엔티티는 동일한 조정 유형으로 함께 연결되어야 한다. 더욱이, 리스트 내의 모든 엔티티는 동일 프로그래밍 유형이어야 한다(예를 들면, 모든 MailEntity 요소).

일반 규칙으로서, 런타임은 동일 유형의 조정에 기인한 브래킷 모호성을 모델링할 여러 해석을 생성할 수는 없다. 그 대신, 동일 유형의 조정(즉, 모두 "and" 또는 모두 "or"로)함께 조정된 엔티티는 플랫 리스트로서 모델링되고, 문제가 생기면 적절한 브래킷 상에 분석하는 응용 프로그램에 남겨진다. 예를 들면, 이 발화 "find mail and books and files"를 취한다. 이는 "find mail and (books and files)" 또는 "find (mail and books) and files)"를 의미할 수 있다. 이러한 모호성의 브래킷은 모델링되지 않으므로, 모든 엔티티가 동일 SPL 유형이라고 가정하면, 단지 하나의 가능한 판독이 생성될 수 있다. 이러한 발화는 요소의 순서가 발화 내의 순서를 반영하는 플랫 리스트로서 모델링된다.

그러나, "and" 및 "or"로 혼합되면, 런타임은 여러 판독을 생성하여 브래킷 모호성을 모델링한다. 작성된 코드에 따라, 이들 여러 판독은 여러 분석된 해석을 야기하거나 야기하지 않을 수 있다. 발화 "find mail or books and files"에 있어서, 요소 리스트는 동일한 조정 유형으로 조정되어야 하기 때문에, 다음 런타임은 다음의 가능한 판독을 생성한다("mail", "books" 및 "files"은 동일한 SPL 유형으로 분석되고 Find 명령은 엔티티 리스트를 취한다고 가정):

(Find (mail OR books)) AND (Find (files))

(Find (mail)) OR (Find (books AND files))

"find"는 "and"와 "or" 상에서 분포된다.

통상, 혼합된 "and" 및 "or" 연산자는 발화 내에 흔하지 않기 때문에, 여러 해석을 생성하여 브래킷 모호성을 모델링하는 것이 너무 부담이 되지 않아야 한다.

몇몇 구성에서, 표 114에 나타낸 바와 같은 [] 구문을 사용하여 엔티티의 소비자에 의해 규정될 수 있는, 엔티티 리스트를 구현할 필요가 있을 수 있다.

표 144: 엔티티 리스트

command FindMailCommand uses find<DoneTo.what:=[MailEntity]>;l

entity MailEntity denoted by "mail"

{

on resolve

{

with restriction Location<loc:=[MailFolder]>;

}

}

해석은 SPL 프로그램에 대하여 발화의 분석된 해석을 나타낸다. 각각의 분석된 해석은 적어도 하나의 분석된 명령을 포함한다. 발화는 해석에 대한 여러 명령을 발생시킬 수 있다. 예를 들면, "find file foo.txt and print it" 이 발화에서 두개의 명령이 있다. 해석 내의 명령은 몇몇 조건과 함께 연결된다. 현재, AND 또는 OR의 조정 유형에 의해 연결된다(다른 모델링 조건이 또한 가능하다). 해석 내의 명령은 동일한 분석 유형일 필요는 없다.

다음 설명은 요소가 논리곱과 논리합으로 분포되는 방식과 작성된 코드가 조정을 모델링하는 방식을 살펴보기 위한 여러 조정 예를 나타낸다. 또한, 이 설명은 명령, 엔티티 및 제한에 대한 조정을 점검한다. 해당 발화에서, 가능한 판독이 모호성과 분포를 나타내도록 도시되어 있다.

반복하면, SPL 작성자는 그들의 응용 프로그램의 의미에 대하여 고찰한다(예를 들면, 나의 FIND 명령은 MailEntity 리스트 상에서 동작할 수 있다). 런타임은 논리곱과 논리합 상으로 요소의 분포 규칙의 언어학적 이해에 따라 작성되는 것으 로 발화를 매핑하려 한다. 표 145에서의 코드 샘플은 아래 제시된 예에 대하여 사용된다.

표 145: 예시 코드

command OpenMailCommand uses open<DoneTo.what:=MailEntity>;

command OpenFileCommand uses open<DoneTo.what:=FileEntity>;

command ReplyMailCommand uses reply<DoneTo.what:=MailEntity>;

command CreateMailCommand uses create<DoneTo.what:=MailEntity>;

entity MailEntity denoted by "mail":ItemEntity

{

on resolve

{

with restriction Source<src:=SenderEntity>;

with restriction Location<loc:=MailFolder>;

}

}

entity NotesEntity denoted by "notes":ItemEntity;

entity JournalEntity denoted by "journal items":ItemEntity;

entity FileEntity denoted by "file";

// 이 엔티티는 CreatedItemsFrame에서 다형성이다

entity ItemEntity

{

on resolve

{

with restriction CreatedItemsFrame<DoneTo.what:=this>;

}

}

// "created yesterday" 모델

frame CreatedItemsFrame:create<DoneTo.what:=ItemEntity>

{

on resolve

{

with restriction Time;

}

}

상기 코드는 다음과 같은 "Find mail from Bob and delete them" 명령을 분석한다:

FindMailCommand<MailEntity₁("mail from Bob")> AND DeleteMailCommand <MailEntity₁>

명령 "Find and/or delete mail from Bob"은 다음과 같이 4 해석을 갖도록 분석된다:

해석 1: "mail from Bob"이 "and"/"or" 상에 분포.

FindMailCommand<MailEntity₁("mail from Bob")>AND/OR

DeleteMailcommand<MailEntity₁>

해석 2: "mail from Bob"이 "and"/"or" 상에 분포되지 않음.

FindMailCommand<MailEntity₁(empty)> AND/OR

DeleteMailCommand <MailEntity₂("mail from Bob")>

해석 3: "mail from Bob"은 "and"/"or" 상으로 분포되지 않는다. 이 해석은 조정 모호성이 아닌 작성된 코드에 기인한다. 3개의 "find" 명령이 있고 "empty" 엔티티는 유효 엔티티이기 때문에, "find"는 이들 명령 중 임의의 것에 분석할 수 있다.

FindNotesCommand<NotesEntity₁(empty)> AND/OR

DeleteMailCommand <MailEntity₁("mail from Bob")>

해석 4: 해석 3과 동일

FindJournalCommand<JournalEntity₁(empty)> AND/OR

DeleteMailCommand <MailEntity₁("mail from Bob")>

모든 열건된 해석은 상기 작성된 코드에 대하여 가능하다.

명령 "Find mail from Bob and/or delete"는 상기 작성된 코드에 대하여 분석되고 다음과 같이 두개의 해석이 가능하다:

해석 1: "mail from Bob"은 "and"/"or" 상에서 분포됨.

FindMailCommand<MailEntity₁("mail from Bob")> AND/OR

DeleteMailCommand<MailEntity₁>

해석 2: "mail from Bob"은 "and"/"or" 상에 분포되지 않음.

FindMailCommand<MailEntity₁("mail from Bob") AND/OR

DeleteMailCommand<MailEntity₂(empty)>

이 예에서의 어구와 이전 예에서의 어구와의 유일한 차이는 엠프티 MailEntity를 갖는 명령 "delete"이다. 두 해석은 모두 상기 작성된 코드로 가능하다.

명령 "Open file and reply or create mail"는 코드에 대하여 분석되어, 다음과 같은 해석이 가능하다:

해석 1: "mail"은 "reply"에 부착하는 "or" 상으로 분포된다

OpenFileCommand<Entity₁("file")> AND

ReplyMailCommand<Entity₂("mail")> OR

CreateMailCommand<Entity₂>

해석 2: 엔티티의 분포가 없음

OpenFileCommand<FileEntity₁("file")> AND

ReplyMailCommand<MailEntity₁(empty)> OR

CreateMailCommand<MailEntity₂("mail")>

해석 3: "file"은 "and" 상으로 분포되어 "reply"에 부착한다. 이러한 판독은 FileEntity를 취하는 "reply" 명령이 없기 때문에 상기 작성된 코드에 대하여 분석되지 않을 수 있다.

OpenFileCommand<FileEntity₁("file")> AND

ReplyMailCommand<FileEntity₁> OR

CreateMailCommand<MailEntity₂("mail")>

명령 "Open file or replay and create mail"은 다음과 같은 3개의 해석이 가능하다:

해석 1: "file"은 "or" 상으로 분포되어 "reply"에 부착한다. 이러한 판독은 "FileEntity"를 취하는 "reply" 명령이 없기 때문에 상기 작성된 코드에 대하여 분석되지 않을 수 있다.

OpenFileCommand<FileEntity₁("file")> OR

ReplyMailCommand<FileEntity₁> AND

CreateMailCommand<MailEntity₁("mail")>

해석 2: "mail"은 "and" 상에 분포되어 "reply"에 부착한다

OpenFileCommand<Entity₁("file")> OR

ReplyMailCommand<Entity₂("mail")> AND

CreateMailCommand<Entity₂>

해석 3: 엔티티의 분포 없음

OpenFileCommand<FileEntity₁("file")> OR

ReplyMailCommand<MailEntity₁(empty)> AND

CreateMailCommand<MailEntity₂("mail")>

통상, 제한용 "and"는 SPL의 의미에 의해 암시된다. 예를 들면, 명령 "find mail from Bob and in Inbox"는 두개의 제한이 MailEntity, 소스 제한 및 위치 제한을 기동하게 한다. 따라서, 다음 설명은 제한에 대한 논리합을 점검한다.

상기 코드에 더하여, 코드의 다음 라인을 사용하여 MailEntity의 리스트를 이해하는 FindMailListCommand를 추가할 수 있다.

command FindMailListCommand uses find<Doneto.what:=[MailEntity]>;

명령 "find mail from Bob or created yesterday"는 다음 해석으로 분석한다:

해석 1: "mail"은 "or" 상으로 분포됨. 이는 MailEntity의 리스트가 된다.

FindMailListCommand<[MailEntity₁("mail from Bob") OR

MailEntity₂("mail created yesterday")]>

FindMailListCommand는 성공적으로 존재하거나 분석하지 않는 경우, "find"는 엔티티 상으로 분포되어 두개의 FindMailCommand를 생성할 수 있다:

FindMailCommand<MailEntity₁("mail from Bob")> OR

FindMailCommand<MailEntity₂("mail created yesterday")>

명령 "find mail from Bob or created yesterday and in Inbox"는 다음과 같이 해석된다:

해석 1: 브래킷, 즉, "or" 상으로 분포된 "in Inbox"으로 (mail from Bob or created yesterday)의 브래킷.

FindMailListCommand<[MailEntity₁("mail from Bob and in Inbox") OR

MailEntity₂("mail created yesterday and in Inbox")]>

또한, FindMailListCommand가 성공적으로 존재하거나 분석하지 않는 경우, "find"는 엔티티 상에서 분포되어 두개의 FindMailCommand를 생성할 수 있다.

해석 2: (mail created yesterday and in Inbox)의 브래킷. "mail from Bob"이 논리합으로 연결되기 때문에, 브래킷 상으로 이의 분포는 없음.

FindMailListCommand<[MailEntity₁("mail from Bob") OR

MailEntity₂("mail created yesterday and in Inbox")]>

또한, FindMailListCommand가 성공적으로 존재하거나 분석하지 않는 경우, "find"는 엔티티 상에서 분포되어 두개의 FindMailCommand를 생성할 수 있다.

해석 3: 수식어구의 브래킷이 없으며, "mail"은 모든 수식어구 상에 분포.

FindMailListCommand<[MailEntity₁("mail from Bob") OR

MailEntity₂("mail created yesterday") AND

MailEntity₃("in Inbox")]>

또한, FindMailListCommand가 성공적으로 존재하거나 분석하지 않는 경우, "find"는 엔티티 상에서 분포되어 두개의 FindMailCommand를 생성할 수 있다.

상기 명령에 더하여, 메일 리스트, 노트, 및 저널 항목을 발견할 수 있는 일반적인 FindCommand가 추가된다. FindCommand가 표 146에 나타낸다.

표 146: Find 명령

command FindCommand uses find<DoneTo.what:=[GeneralEntity]>;

entity GeneralEntity denoted by "mail", "notes", "journal items":ItemEntity

{

on resolve

{

with restriction Source<src:=SenderEntity>;

}

}

이 명령의 추가는 아래 예에서 알 수 있는 바와 같이 해석의 수를 증가시킨다.

명령 "Find mail and/or notes created yesterday"는 다음 해석이 가능하다.

해석 1: "and"/"or" 상에 분포된 "created yesterday".

FindCommand<[GeneralEntity₁("mail created yesterday") AND/OR

GeneralEntity₂(notes created yesterday")]>

해석 2: "created yesterday" 분포 없음.

FindCommand<[GeneralEntity₁("mail") AND/OR

GeneralEntity₂("notes created yesterday")]>

FindCommand가 성공적으로 존재하거나 분석하지 않는 경우, "find"는 논리곱 상에서 분포되어 다음 둘 이상의 해석을 제공할 수 있다.

해석 3: 1과 동일하지만, 엔티티 상에서 "find" 분포됨.

FindMailCommand<MailEntity₁("mail created yesterday")> AND/OR

FindNotesCommand<NotesEntity₁("notes created yesterday")>

해석 4: 2와 동일하지만, 엔티티 상에 "find" 분포됨

FindMailCommand<MailEntity₁("mail")> AND/OR

FindNotesCommand<NotesEntity₁("notes created yesterday")>

명령 "Find mail from Bob and/or notes created yesterday"는 다음의 해석이 가능하다.

해석 1: 예 1과 달리, 수식어구의 분포가 없음.

FindCommand<[GeneralEntity₁("mail from Bob")> AND/OR

GeneralEntity₁("notes created yesterday")]>

해석 2: FindCommand가 분석하지 않으면, 엔티티 상에 "find" 분포를 얻지 않음.

FindMailCommand<MailEntity₁("mail from Bob")> AND/OR

FindNotesCommand<NotesEntity₁("notes created yesterday")>

명령 "Find mail, notes, or journal items created yesterday"는 다음 해석이 가능하다.

해석 1: "created yesterday"는 "mail", "notes", 및 "journal items" 상에 분포됨.

FindCommand<[GeneralEntity₁("mail created yesterday") OR

GeneralEntity₂("notes created yesterday") OR

GeneralEntity₃("journal items created yesterday")]>

해석 2: 수식어구 분포가 없음

FindCommand<[GeneralEntity₁("mail") OR GeneralEntity₂("notes") OR

GeneralEntity₃("journal items created yesterday")]>

FindCommand는 성공적으로 존재하거나 분석하지 않은 경우, "find"는 논리곱 상에 분포되지 않고, 다음 두개의 추가 해석이 발생한다:

해석 3: 1과 동일하지만, 엔티티 상에 "find"가 분포됨

FindMailCommand<MailEntity₁("mail created yesterday")> OR

FindNotesCommand<NotesEntity₁("notes created yesterday") OR

FindJournalCommand<JournalEntity₁("journal items created

yesterday")>

해석 4: 2와 동일하지만, 엔티티 상에 "find"가 분포됨

FindMailCommand<MailEntity₁("mail")> OR

FindNotesCommand<NotesEntity₁("notes") OR

FindJournalCommand<JournalEntity₁("journal items created

yesterday")>

명령 "Find mail and notes or journal items created yesterday"은 브래킷 이슈가 발생한다. 혼합된 논리곱 유형(즉, "and" 및 "or"이 발화에 나타남)과 엔티티의 리스트와 싱글톤(singleton) 엔티티를 모두 취하는 "find" 명령의 존재로 인해, 많은 해석이 가능하게 된다. 따라서, 몇몇 엔티티의 리스트를 취하는 명령뿐만 아니라 싱글톤 엔티티를 취하는 명령을 갖지 않는 것이 바람직하다. 이 코드 는 가능한 한 많은 해석을 생성하도록 작성된다.

해석 세트 1: "created yesterday"의 분포 없음

"mail"과 "notes"의 브래킷

FindCommand<[GeneralEntity₁("mail") AND

GeneralEntity₂("notes")] OR

FindJournalCommand<JournalEntity₂("joural items created

yesterday">

이 경우, FindCommand가 FindJournalCommand 대신에 단지 하나의 요소를 취하는 해석을 생성할 필요할 수 있다.

"notes" 및 "journal items"의 브래킷

FindMailCommand<MailEntity("mail")> AND

FindCommand<[GeneralEntity₁("notes") OR

GeneralEntity₂("journal items created yesterday")]>

브래킷 없음

FindMailCommand<MailEntity("mail")> AND

FindNotesCommand<NotesEntity("notes")>

ORFindJournalCommand<JournalEntity("journal items created

yesterday")>

해석 세트 2: "or" 상으로 "created yesterday"의 분포하여 "notes"에 부착

"mail"과 "notes"의 브래킷

FindCommand<[GeneralEntity₁("mail") AND

GeneralEntity₂("notes created yesterday")]> OR

FindJournalCommand<JournalEntity₁("journal items created

yesterday">

"notes"와 "journal items"의 브래킷

FindMailCommand<MailEntity("mail")> AND

FindCommand<[GeneralEntity₁("notes created yesterday") OR

GeneralEntity₂("journal items created yesterday")]>

브래킷 없음

FindMailCommand<MailEntity("mail")> AND

FindNotesCommand<NotesEntity("notes created yesterday")> OR

FindJournalCommand<JournalEntity("journal items created

yesterday")>

해석 세트 3: "모든 엔티티 상으로 "created yesterday"의 분포

"mail"과 "notes"의 브래킷

FindCommand<[GeneralEntity₁("mail created yesterday") AND

GeneralEntity₂("notes created yesterday")]> OR

FindJournalCommand<JournalEntity₁("journal items created

yesterday">

"notes"와 "journal items"의 브래킷

FindMailCommand<MailEntity("mail created yesterday")> AND

FindCommand<[GeneralEntity₁("notes created yesterday") OR

GeneralEntity₂("journal items created yesterday")]>

브래킷 없음

FindMailCommand<MailEntity("mail created yesterday")> AND

FindNotesCommand<NotesEntity("notes created yesterday")> OR

FindJournalCommand<JournalEntity("journal items created

yesterday")>

몇몇 경우, 제한에 대한 여러 언어학적 현상 간의 그 또는 그녀 자신의 매핑을 개발자가 규정할 수 있는 것이 바람직할 수 있다. 또한, 기본에서 "후분석" 프로그래밍과 달리, 어느 제한이 기동되는지를 패턴이 영향을 미치는 "후분석" 프로그래밍을 제공하는 것이 바람직할 수 있다. 통상, 문자열 기반에서 언어학적 기반으로의 패턴 범위를 허용하는 것이 바람직하다.

일 실시예에서, LOM 개발자에 의해 내부적으로 그리고 SPL 개발자에 의해 외부적으로 사용되는 패턴을 규정하는 일반적인 메커니즘이 제공된다. 외부 개발자 는 단순한 것에서 복잡한 것으로 패턴 범위를 사용할 수 있어야 한다.

일 실시예에서, 패턴의 적용은 표 147에서 나타낸 바와 같이 C# 속성을 사용한 것과 같을 수 있다.

표 147: 패턴 적용

entity FlightEntity

{

[MyPattern("departing from")]

with restriction Source<src:=City>

{

}

}

통상, 본 발명은 가능한 한 공개적이며, 개발자가 임의의 소정 세트와 독립적으로 그들 자신을 패턴을 생성할 수 있게 한다. 이는 개발자가 정형화된 의미 관계(즉, 제한 유형)를 우회하여 그들 자신의 것을 원하는 대로 생성할 수 있게 한다.

모델링 조건에 있어서, 몇몇 실시예에서, 모델링 조건 명령은 매우 중요할 수 있다. 몇몇 단순 예는 "if Bob sends me mail, delete it", "page me when mail comes from Bob", "move the file to c:\doc after copy it", 및 "warn me before permanently deleting a message"를 포함한다. 통상, 이를 모델링하는 메커니즘은 조정된 명령의 메커니즘과 유사해야 한다. 다른 실시예에서, 조건은 특 정 제한 유형을 통해 제공될 수 있다.

몇몇 실시예에서, 작성자는 보다 좁은 해석을 제공하기 위해서 제한 절 내의 여러 제한에 대하여 추론하기를 원할 수 있다. 작성자는 정교하게는 아니더라도 제한 절 내에 데이터를 저장하고 성공 절 내에서 이를 추론하여 AND 추론을 모방할 수 있다. 작성자는 공통 함수를 호출하여 OR 속성 추론을 모방할 수 있다.

바람직한 실시예에서, 작성자는 명령 코드를 사용하여(예를 들면, 데이터베이스에 호출하여) 표시 리스트를 규정할 수 있다. 이에 대한 개념은 특정 구현예와 관련 데이터베이스에 따라 변할 수 있다.

통상, 네임드 제한은 작성자에게 문자열로서 명칭을 제공한다. 일 실시예에서, 작성자는 해당 발화에서 인식된 명칭 리스트에 대한 런타임에 의해 조회될 수 있는 네임 클래스를 생성할 수 있다. 예를 들면, 어구 "find Gond with the Wind movie"를 고려하면, 작성자는 영화명으로서 "Gone with the wind"를 인식할 수 있는 네임 클래스를 생성할 수 있다. 일 실시예에서, SPL은 표 148에서 도시한 바와 같은 네임 클래스를 취하는 네임드 제한의 과부하가 제공된다.

표 148; 과부화된 네임 제한

name MovieNames

{

// 런타임이 해당 발화에서 인식된 명칭의 리스트를 얻도록

// 호출할 수 있는 몇몇 방법

NameList FindRecognizedNames(string Utterance);

}

entity MovieEntity denoted by "movie"

{

on resolve

{

with restriction Named<name:=MovieNames>;

}

}

바람직한 실시예에서, NamedEntity 유형은 다음과 같은 NamedEntity Recognizer에 관련된다:

NamedEntity MovieName uses MoveNameRecognizer;

class MovieNameRecognizer:NamedEntityRecognizer

{

public override void Recognize(string input, /* 다른 인수 */)

{

// 'input'에서 영화명의 인스턴스를 인식

}

}

바람직한 실시예에서, 개발자는 미지의/미작성된 명령(예를 들면, 명사구)가 처리되는 방식을 규정할 수 있다. 작성자는 응용 프로그램을 코딩하여 이들을 그 자리에서 처리하거나, 런타임이 특정 엔티티에 대한 특정 명령(명령 집합)을 호출하고, 또는 기본 명령 핸들러를 제공할 수 있다.

일 실시예에서, 유도 클래스는 표 149에 나타낸 바와 같은 베이스 클래스의 제한 절을 호출할 수 있다.

표 149: 유도 클래스가 베이스 클래스의 제한 절을 호출

entity Entity1

{

with restriction Location<loc:=SomeEntity>

{

}

}

entity Entity2:Entity1

{

/* Entity1에 의해 처리되지 않은 모든 위치 유형을 처리하기를

원하지만, SomeEntity 유형의 위치에 대한 Entity1에 진행한다.

다음을 행하면, 이 절이 Entity1의 절 이전에 시도되기 때문에

Entity1::Locations이 호출되지 않을 수 있다.

with restriction Location<loc:=Entity>

{

//처리 실시

}

}

절의 분석은 런타임에 의해 통상 제어되기 때문에 직접 호출이 바람직하지 않을 수 있다. 공용/전용/보호 및 다른 제한 절의 도입과 각각이 분석 의미에 무엇을 의미하는지를 파악하려는 시도는 불필요한 복잡성을 추가할 수 있다. 그 대신, 베이스 절이 성공하면 그 자신의 절을 호출하기 전에 인터프리터에 베이스 제한 절을 호출하도록 지시하는 보다 많은 제한(예를 들면, 보다 선언형 제한)이 추가될 수 있다. 컴파일러는 표 150에 나타낸 바와 같이 베이스에서 정확한 슬롯 유형을 사용하여 절의 존재를 구현할 수 있다.

표 150

entity Entity2:Entity1

{

with invokebase restriction Location<loc:=SomeEntity>

{

}

with restriction Location<loc:=Entity>

{

}

}

invokebase의 의미는 베이스의 제한 절(평서 및 명령 제한 모두)은 invokebase를 구비한 절이 호출되기 전에 성공하여야 한다는 것이다. 의미를 변경하는 것이 바람직하면(즉, 베이스 전에 유도 절을 호출), 다른 구문이 사용되어야 한다. "with" 절 구문은 절에 부착된 코드가 실행되기 전에 절에 의해 규정된 제한이 충족되어야 함을 의미한다.

몇몇 동사는 목적 및 위치를 교환한다. 예를 들면, "print to my printer"는 "print on my printer"와 동일한 의미이다. 작성자는 위치가 구문적으로 실현되는 방식에 따라(즉, "to"와 "on") 두개의 상이한 제한에 대하여 코딩하여서는 안된다. 두 제한이 모두 작성된 것에 따라 이들 동사에 대하여 제공될 수 있다. 그러나, 몇몇 경우, "to"가 목적으로 항상 구현될 수 있고, 몇몇 동사에서는 목적이 위치일 수 있지만 다른 것에는 위치일 수 없음을 설명하려는 것을 잊을 수 있음을 작성자에게 설명하는 것이 보다 용이할 수 있다.

추가 유형이 인스턴스화될 수 있지만(즉, 이에 대하여 직접 분석될 수 없음) 다형성과 공통 기능을 지지하는데 유용함을 이해하는 것이 중요하다. 작성자가 "send mail to Bob"에 대한 명령을 기입하면, 발화 내에 어떤 "mail"이 없는 경우에도 "send to Bob"은 또한 이 명령에 대하여 분석하여야 한다. 그러나, 이러한 기준 작성은 많은 해석을 생성할 수 있다. 몇몇 실시예에서, 이러한 기능은 바람직할 수 있다. 빈 엔티티가 허용되고 기본으로 유효한 것으로서 처리되면, 작성자는 빈 엔티티를 거부하는 엔티티의 성공 절에서 코드를 작성할 수 있다. 빈 엔티티가 기본으로 허용되지 않으면(즉, 발화 내의 엔티티의 증거가 없는 경우, 분석할 수 없음), 명령이 널 엔티티를 승인할 수 있게 하는 슬롯 수량사가 도입될 수 있다("선택적"). 바람직한 실시예에서, MailEntity를 포함하는 제한이 없을 수 있으며, 프레임 또는 명령은 작성자가 이 경우를 점검하려는 경우 명시적으로 분석을 중지할 수 있다.

본 발명은 특정 실시예를 참조하여 설명하였지만, 당업자는 본 발명의 취지 및 범위를 벗어나지 않으면서 형태 및 세부사항에서 변경을 행할 수 있음을 이해할 것이다.

부록 I-시나리오: 마이크로소프트 아웃룩

프로토타입

이 실시예에서, 마이크로소프트 아웃록

은 SPL과 LOM을 사용하여 텍스트 및 음성 입력에 대하여 구현되었다. 대부분의 구현은 어떤 언어학적 지식 또는 훈련이 없는 섬머 인턴에 의해 수행되었다. SPL 코드는 마이크로소프트 .NET 플랫폼에 컴파일되고 이에 동작하도록 설계되고 코드는 아웃룻 2002 객체 모델과 CDO(협력 데이터 객체)을 통해 마이크로소프트 아웃룩과 상호동작하여 결합을 실시하고 명령을 실행한다.

몇몇 개선된 탐색이 구현되며, 이는 상이한 데이터 소스를 추론한다. 몇몇 예는 다음 시나리오를 포함한다:

배포 리스트에서 추론하는 "search for mail that was sent by people on Conference Group";

연락 폴더에서 사람에 대하여 추론하는 "show mail from my contacts"; 및

기관 차트에 추론하는 "find mail from my direct reports".

또한, 시스템은 또한 어두 반복 분석을 실시한다. 예를 들면, "show me David's manger" 다음에 "send mail to him"은 "him"이 "David's manager"를 나타냄이 개발자에게는 명확하게 된다.

또한, 시스템은 다음과 같은 개선된 추론과 모델링을 수행한다:

부정에 대하여 추론하는 "send mail to everyone on nlgcore except David Bradlee"; 및

복잡한 시간 표현에 대하여 모델링 및 프로그램하는 "schedule a meeting every Tuesday with my manager at 2:00 for 1 hour".

부록 II: 마이크로소프트 아웃룩

코드 일람

다음 설명은 개발자의 관점에서 명령을 분석한다. 설명은 개발자가 그/그녀가 코드를 디버깅할 대 보는 것을 모방한다. 이 명령은 "send mail about package to Seattle group"이다. 이 문장은 두개의 가능한 의미를 갖는다:

1. 메일의 제목이 "package to seattle group"인 "send mail about package to seattle group.

2. 메일의 제목이 "package"이고 "send"(즉, 메일 전송 장소)의 상이 "seattle group"인 "send mail about package to seattle group"

도메인 지식에 따라, 이들 해석 중 하나 또는 둘은 최종 해석 리스트에 있을 수 있다.

아래는 그 코드 전체이다. SPL 키워드 또는 예약어는 굵은 서체이다. 코드 스니핏은 분석이 단계를 통해 진행할 때 무시할 수 있다.

해석 1

명령을 다시 참조하면, 제1 해석은 다음과 같이 메일의 제목이 "package to seattle group"이라는 것이다:

"send mail about package to seattle group"

호출되는 제1 객체는 SendMailCommand의 "on resolve" 절의 "on begin"절이다:

명령의 구성자가 호출되고 절 내의 코드가 실행된다. 절이 "false"를 리턴하면, 이 명령에 대한 추가 분석이 중지된다. 이 경우, SendMailContext()는 false를 리턴하면(즉, 응용 프로그램은 현재 메일 전송의 경우가 아님), 분석이 중지한다.

응용 프로그램이 메일을 전송할 수 있다고 가정하면, SPL 인터프리터는 이 분석을 계속한다. 호출되는 다음 객체는 SendMailCommand가 이것이 SendMailFrame을 사용한다고 언급하기 때문에 SendMailFrame이다. 인터프리터는 어구 내의 단어 "send"를 SendMailFrame에 매핑함을 인식한다.

SendMailFrame에 대한 구성자가 없기 때문에, 기본 구성자가 호출된다. 기본 구성자는 항상 성공한다. 인터프리터는 'send'에 대한 제한을 계속 분석한다. 분석될 제1 제한은 "DoneTo" 제한으로서, 이는 본 경우에서 'mail'인 'send'의 객체를 나타낸다.

이 코드에 따르면, DoneTo의 슬롯(도메인의 특정 유형을 지시)은 MailEntity이다. 즉, 'send'의 객체는 MailEntity일 필요가 있다. 그 후, 인터프리터는 MailEntity의 분석을 시도한다:

다른 객체와 마찬가지로, 인터프리터는 구성자를 호출한다. 구성자가 없기 때문에, 기본 구성자가 호출되어 성공할 수 있다.

엔티티는 단어 리스트에 의해 표시되는 개념을 갖는다. 이 경우, 인터프리터는 'mail'이 MailEntityWords에 대한 영어 리스트를 관찰하여 MailEntity의 표시자인지를 확인한다:

이는 언어 특정 세부사항이 코딩되는 경우이다. 인터프리터는 'mail'이 리스트에 있음을 확인한다.

다음으로, 인터프리터는 MailEntity에 코딩된 것에 대하여 'mail' 상의 제한을 분석하려 한다. 이 경우, 'about package to seattle group'은 실제 토픽이 "package to seattle group"인 토픽 제한이다.

인터프리터는 토픽 제한의 슬롯에 대하여 실제 토픽의 분석을 시도한다. '토픽' 슬롯은 문자열이기 때문에, 어떤 분석도 필요하지 않다. 토픽 절 내의 코드가 실행된다.

코드는 토픽 텍스트를 멤버 변수, MailSubject에 저장한다. 토픽의 실제 텍스트는 언어 객체 모델(LOM)을 통해 검색된다. 인터프리터는 이제 MailEntity 객체를 사용하여 실시된다. 이는 코딩되지 않았기 때문에 MailEntity에 대한 기본 성공 해체자를 호출한다.

제어 흐름은 코드가 DoneTo 절에 실시되는 SendMailFrame에 리턴된다:

이 코드는 단지 MailEntity 객체를 멤버 변수에 저장한다. {주의: 이는 (후술하는) 제2 해석이 개시하는 경우이다}. 인터프리터는 SendMailFrame 객체를 분석하여 행해지며 제공되지 않았기 때문에 기본 성공 해체자를 호출한다.

제어 흐름은 SendMailCommand에 리턴된다. 이 시점에서, 인터프리터는 완전 명령을 분석하여 수행된다. SendMailCommand에 대한 성공 해체자가 호출된다.

이 코드가 실행되고 SendMailCommand 객체가 응용 프로그램에 리턴된다.

해석 2

이제 가능한 제2 해석을 참조하면:

"send mail about package to seattle group"

"send mail about package"에 대한 분석 단계는, 토픽이 'package to seattle group' 대신 'package'인 점을 제외하면, 표시된 슬롯까지 정확하게 동일하다.

인터프리터는 "to seattle group"은 'send'에 대한 목적 제한임을 인식한다.

이 코드는 실제 목적이 DLEntity일 필요가 있으므로 인터프리터가 DLEntity에 대하여 "seattle group"을 분석하려 함을 의미한다.

인터프리터는 'group'이 DLEntity의 표시자이어야 함을 인식한다. 이는 표시자 리스트, DLEntityWords를 점검한다:

매칭이 발견된다. 그 후, 인터프리터는 네임드 제한 절에 대하여 'seattle'의 분석을 시도한다. 네임드 제한의 슬롯이 문자열이기 때문에, 'seattle'은 이에 대하여 분석할 수 있다. 네임드 제한 절이 성공하고 절 내의 코드가 실행된다:

코드는 단지 'seattle'은 유효 분포 그룹인 경우에만 'true'를 리턴할 수 있다. 이것이 인식된 분포 그룹이 아닌 경우, 절은 'false'를 리턴한다. 이는 SPL 인터프리터가 리턴하는 해석에 도메인 특정 지식이 영향을 미치는 방식이다. 'seattle'이 분포 그룹이 아니면, 이 해석의 분석은 실패할 수 있으며 단지 제1 해석이 리턴될 수 있다.

인터프리터는 명령을 분석하여 실행된다. 'seattle'이 인식 분포 그룹인지에 따라, 성공 또는 실패 해체자가 호출될 수 있다.

제어 흐름은 SendMailFrame에 리턴한다. DLEntity의 분석이 실패하면, 목적 절 내의 코드는 실행될 수 없으며 SendMailFrame이 분석을 중지한다. 다르게는, 이 코드가 실행되어 분석이 성공한다.

제어 흐름은 SendMailCommand에 리턴하고, SendMailFrame의 성공 여부에 따라, 성공 해체자가 호출되거나 실패 해체자가 호출된다.

상술한 본 발명에 따르면, 자연어 응용 프로그램 프로그래밍을 위한 소프트웨어 개발 도구에 있어서, 자연어 프로그래밍을 용이하게 하는 일련의 프로그래밍 구성자를 갖는 프로그래밍 언어와, 일련의 프로그래밍 구성자의 인스턴스를 포함하는 소프트웨어 프로그램을 취하고 소프트웨어 응용 프로그램을 생성하기에 적합한 상기 컴파일러를 구비함으로써 자연어 응용 프로그램의 프로그래밍을 용이하게 할 수 있다.

Claims (50)

1. 인코딩된 언어 객체 모델(linguistic object model)이 저장되어 있는 컴퓨터 판독 가능 기록 매체로서,

   상기 인코딩된 언어 객체 모델은 자연어(natural language)의 의미 요소들(semantic elements)을 모델링하기 위해 컴퓨터에 의해 사용되도록 적응되어 있고,

   상기 인코딩된 언어 객체 모델은,

   자연어의 의미들을 모델링하기 위한 일련의 유형들을 포함하고,

   상기 일련의 유형들은 임의의 특정 자연어에 독립적이고, 상기 일련의 유형들은 입력 문자열들에 대한 사용자-정의형 카테고리들을 모델링하기 위한 표시자 유형(Denoter type)을 더 포함하고, 상기 표시자 유형을 기술하는 데이터 멤버는 상기 일련의 유형들 중의 한 유형과 자연어 발화(utterance) 중의 한 요소 간의 매치를 수행하도록 표시자 유형의 표시자 객체(Denoter object)에 있어서 어느 사용자-정의형 카테고리의 입력 문자열들이 런타임에 분석 엔진에 의해 채워지는지의 기록을 포함하는,

   컴퓨터 판독 가능 기록 매체.
2. 제1항에 있어서,

   상기 일련의 유형들은,

   명사구들(noun phrases)의 의미들을 모델링하기 위한 엔티티 유형(Entity type);

   형용사구들의 의미들을 모델링하기 위한 엔티티 유형;

   이벤트들의 의미들을 모델링하기 위한 프레임 유형(Frame type);

   의미 요소들의 속성들을 모델링하도록 적응된 제한(Restriction);

   의미 객체들을 모델링하도록 적응된 엔티티들과 이벤트들 및 하나 이상의 객체들 간의 연관된 관계들을 모델링하도록 적응된 프레임들과 다른 엔티티들, 프레임들 또는 제한들 간의 관계 및 이들의 속성들을 모델링하도록 적응된 제한들; 및

   네임드(named) 엔티티들을 모델링하도록 적응된 네임드 엔티티 유형 - 상기 네임드 엔티티 유형은 개별적으로 정의된 클래스로부터 획득되거나 또는 인터페이스를 사용해서 직접 액세스됨 -;

   중 적어도 하나를 포함하는,

   컴퓨터 판독 가능 기록 매체.
3. 인코딩된 언어 객체 모델이 저장되어 있는 컴퓨터 판독 가능 기록 매체로서,

   상기 인코딩된 언어 객체 모델은 자연어의 의미 요소들을 모델링하기 위해 컴퓨터에 의해 사용되도록 적응되어 있고,

   상기 인코딩된 언어 객체 모델은,

   자연어 발화들의 요소들을 나타내는 일련의 유형들을 포함하고,

   각각의 유형은 발화의 의미적으로 유효한 요소들에 대응하고, 상기 일련의 유형들은 입력 문자열들에 대한 사용자-정의형 카테고리들을 모델링하기 위한 표시자 유형을 더 포함하고, 상기 표시자 유형을 기술하는 데이터 멤버는 상기 일련의 유형들 중의 한 유형과 자연어 발화 중의 한 요소 간의 매치를 수행하도록 표시자 유형의 표시자 객체에 있어서 어느 사용자-정의형 카테고리의 입력 문자열들이 런타임에 분석 엔진에 의해 채워지는지의 기록을 포함하는,

   컴퓨터 판독 가능 기록 매체.
4. 자연어를 모델링하는 컴퓨터 구현 방법으로서,

   언어 표현들(linguistic expressions)을 발화의 요소들에 대응하는 클래스들로 카테고리화하는 단계; 및

   상기 클래스들을 추상 객체들로서 나타내도록 적응된 일련의 유형들을 획득하는 단계를 포함하고,

   상기 일련의 유형들은 입력 문자열들에 대한 사용자-정의형 카테고리들을 모델링하기 위한 표시자 유형을 더 포함하고, 상기 표시자 유형을 기술하는 데이터 멤버는 상기 일련의 유형들 중의 한 유형과 자연어 발화 중의 한 요소 간의 매치를 수행하도록 표시자 유형의 표시자 객체에 있어서 어느 사용자-정의형 카테고리의 입력 문자열들이 런타임에 분석 엔진에 의해 채워지는지의 기록을 포함하는,

   컴퓨터 구현 방법.
5. 자연어를 모델링하기 위해 컴퓨터에 의해 사용되도록 적응된 컴퓨터 판독 가능 데이터 구조들을 저장하는 컴퓨터 판독 가능 기록 매체에 있어서,

   자연어의 의미들을 모델링하기 위한 일련의 유형들을 포함하는 언어 객체 모델을 포함하고,

   상기 일련의 유형들은 임의의 특정 응용 프로그램에 독립적이고, 상기 일련의 유형들은 입력 문자열들에 대한 사용자-정의형 카테고리들을 모델링하기 위한 표시자 유형을 더 포함하고, 상기 표시자 유형을 기술하는 데이터 멤버는 상기 일련의 유형들 중의 한 유형과 자연어 발화 중의 한 요소 간의 매치를 수행하도록 표시자 유형의 표시자 객체에 있어서 어느 사용자-정의형 카테고리의 입력 문자열들이 런타임에 분석 엔진에 의해 채워지는지의 기록을 포함하는,

   컴퓨터 판독 가능 기록 매체.
6. 자연어 사용가능 소프트웨어 응용 프로그램들(natural language enabled software applications)을 생성하기 위해 프로세서에 의해 실행가능한 프로세서 판독 가능 명령어들이 구현되어 있는 컴퓨터 판독 가능 기록 매체로서,

   언어 요소들 자체와는 상이한 상기 언어 요소들의 표현들 및 자연어 입력의 상기 언어 요소들 사이에서의 상호관련성들(interrelationships)을 포함하는 분석가능한 유형들(resolvable types) - 상기 언어 요소들은 상기 자연어 입력의 단어들임 -; 및

   자연어 사용가능 소프트웨어 응용 프로그램의 상기 분석가능한 유형들의 인스턴스들의 유효성을 분석하기 위한 프로시저 규칙들(procedural rules)을 정의하는 분석 의미들(resolution semantics)을 포함하고,

   상기 분석 의미들은,

   상기 프로세서가 상기 분석가능한 유형을 초기화하여 상기 분석가능한 유형의 객체를 생성하고 상기 자연어 사용가능 소프트웨어 응용 프로그램이 상기 분석가능한 유형을 처리할 수 있는 상태에 있는지 판정하도록 하는 제1 절(clause);

   상기 초기화가 성공하고 상기 자연어 사용가능 소프트웨어 응용 프로그램이 상기 분석가능한 유형을 처리할 수 있는 상태에 있을 때 상기 프로세서가 사용하지 않는 객체들을 제거하고 상기 분석가능한 유형과 연관된 결과를 처리하도록 하는 제2 절; 및

   상기 초기화가 실패하거나 또는 상기 자연어 사용가능 소프트웨어 응용 프로그램이 상기 분석가능한 유형을 처리할 수 있는 상태에 있지 않을 때 상기 프로세서가 실패 지시자(failure indicator)를 리턴(return)하도록 하는 제3 절을 포함하는 구성가능한 프레임워크(configurable framework)를 포함하는,

   컴퓨터 판독 가능 기록 매체.
7. 제6항에 있어서,

   상기 분석가능한 유형들은,

   클라이언트 응용 프로그램에 의해 지원되는 자연어 사용가능 작업들을 모델링하기 위한 명령 유형(Command type); 및

   제약들(constraints)을 승인하도록 적응된 제한 호스트 유형(restriction hots type) 중 하나를 포함하는,

   컴퓨터 판독 가능 기록 매체.
8. 자연어 사용가능 소프트웨어 프로그램에서 분석가능한 유형의 실체화(instantiation)의 유효성을 판정하기 위한 방법으로서,

   컴퓨팅 시스템의 프로세서 상에서 실행되는 자연어 사용가능 소프트웨어 프로그램을 사용하여 자연어 입력의 제안된 해석들(interpretations)을 포함하는 제안된 해석 리스트를 어셈블링하는 단계 - 각 제안된 해석은 하나 이상의 명령어를 포함하고, 분석가능한 유형들에 매핑된(mapped) 비명령 요소들(non-command elements)을 선택적으로 포함함 -; 및

   상기 자연어 사용가능 소프트웨어 프로그램을 통해 각각의 제안된 해석과 연관된 실체화의 유효성을 판정하는 단계를 포함하고,

   상기 유효성을 판정하는 단계는,

   상기 분석가능한 유형의 객체를 생성하기 위해 상기 분석가능한 유형을 초기화하고 상기 자연어 사용가능 소프트웨어 프로그램이 상기 분석가능한 유형을 처리할 수 있는 상태에 있는지 판정하도록 구성되는 의미 분석 프레임워크(semantic resolution framework)의 제1 절을 통해 분석가능한 유형들의 분석을 개시하는 단계;

   상기 초기화가 성공하고 상기 자연어 사용가능 소프트웨어 프로그램이 상기 분석가능한 유형을 처리할 수 있는 상태에 있을 때 사용하지 않는 객체들을 제거하고 상기 분석가능한 유형과 연관된 결과를 패키징(package)하는 상기 의미 분석 프레임워크의 제2 절을 실행하는 단계; 및

   상기 초기화가 실패하거나 또는 상기 자연어 사용가능 소프트웨어 프로그램이 상기 분석가능한 유형을 처리할 수 있는 상태에 있지 않을 때 상기 의미 분석 프레임워크의 제3 절을 통해 실패 지시자를 리턴하는 단계를 포함하는,

   유효성 판정 방법.
9. 자연어 사용가능 소프트웨어 응용 프로그램을 생성하기 위해 프로세서에 의해 실행가능한 프로세서 판독 가능 명령어들을 구현하는 컴퓨터 판독 가능 기록 매체로서,

   상기 프로세서 판독 가능 명령어들은,

   자연어 프로그래밍을 위한 자연어의 의미들을 모델링하도록 적응된 일련의 분석가능한 유형들 - 상기 일련의 분석가능한 유형들은 자연어 입력의 명령들을 모델링하도록 적응된 명령 유형(command type) 및 상기 자연어 입력의 비명령 요소들을 나타내도록 적응된 제한 호스트 유형(restriction host type)을 포함하고, 상기 제한 호스트 유형은 런타임에 선택된 명령 유형들과 연관된 호스트 제약들에 적응됨 -; 및

   상기 선택된 명령 유형들을 처리하도록 구성되는 의미 프레임워크를 포함하고,

   상기 의미 프레임워크는,

   각각의 명령 유형을 초기화하고 상기 자연어 사용가능 소프트웨어 응용 프로그램이 상기 명령 유형을 처리할 수 있는 상태에 있는지 판정하는 제1 절;

   상기 자연어 입력과 연관된 분석된 의미 트리를 점검하여 상기 분석된 의미 트리가 일관성(coherent)이 있는지 판정하고 상기 분석된 의미 트리가 일관성이 있고 상기 자연어 사용가능 소프트웨어 응용 프로그램이 상기 명령 유형을 처리할 수 있는 상태에 있을 때 상기 명령 유형을 처리하는 로직을 포함하는 제2 절; 및

   상기 초기화가 실패하거나 또는 상기 자연어 소프트웨어 응용 프로그램이 상기 명령 유형을 처리할 수 있는 상태에 있지 않을 때 실패 지시자를 리턴하는 제3 절을 포함하는,

   컴퓨터 판독 가능 기록 매체.
10. 컴퓨터 상에서 자연어 입력의 의미들을 모델링하고 해석하기 위한 어휘 의미 시스템(lexical semantic system)으로서,

    상기 자연어 입력의 내용을 모델링하기 위해 선택된 일련의 어휘 의미 카테고리들 - 상기 일련의 어휘 의미 카테고리들은 컴퓨팅 시스템의 프로세서 판독 가능 저장 매체에 저장되고, 상기 일련의 어휘 의미 카테고리들은 구문 카테고리, 특정 자연어 발화 내의 특정 구문 카테고리의 기능을 식별하는 의미 역할(semantic role), 및 상기 구문 카테고리와 상기 의미 역할 간의 매핑을 포함하고, 상기 의미 카테고리들은 문장의 구조 요소들을 정의하며, 상기 일련의 어휘 의미 카테고리들은 명사, 수식어구 및 동사 클래스들을 포함하는 음성의 유형을 더 포함하고, 각 의미 역할은 상기 명사 및 동사 클래스들의 범위에 걸쳐 인수(argument) 또는 수식어구를 나타냄 -; 및

    상기 시스템의 기능적인 컴포넌트이며, 상기 일련의 어휘 의미 카테고리들에 액세스하고 상기 자연어 입력에 의해 활성화되어 상기 자연어 입력의 내용을 상기 일련의 어휘 의미 카테고리들 중 하나 이상의 카테고리와 연관시키는 방법을 수행하는 프로세서를 포함하고,

    상기 방법은,

    상기 일련의 어휘 의미 카테고리들에서 상기 자연어 입력의 구문 카테고리들에 매핑된 상기 자연어 입력의 의미 역할들을 식별하여 매핑된 요소들을 생성하는 것을 포함하는, 상기 자연어 입력의 내용을 상기 일련의 어휘 의미 카테고리들에 연관시키기 위해 프로시저들의 집합(collection)을 상기 자연어 입력에 적용하는 일련의 규칙들을 프로세서에 의해 실행하는 단계;

    상기 프로세서에 의해 구현되는, 상기 매핑된 요소들을 자연어 분석 엔진에 제공하는 단계 - 상기 자연어 분석 엔진은 상기 자연어 입력을 나타내는 의미 모델 객체를 획득하기 위해 상기 매핑된 요소들을 언어 객체 모델과 연관시키고 상기 언어 객체 모델을 상기 매핑된 요소들에 연관시키는 2방향 연관(two-way association)을 수행함 -; 및

    실체화를 위하여 상기 의미 모델 객체를 상기 자연어 입력의 해석으로서 출력하는 단계를 포함하는,

    어휘 의미 시스템.
11. 자연어 입력의 의미들을 모델링하고 해석하기 위한 어휘 의미 시스템으로서,

    상이한 언어들에 걸쳐 구문 구조의 변형들을 나타내는 크로스 언어 형태(cross linguistic behavior)에 기초하여 상기 자연어 입력의 내용을 모델링하기 위해 선택된 일련의 카테고리들 - 상기 일련의 카테고리들은 컴퓨팅 시스템의 프로세서 판독 가능 저장 매체에 저장되고, 상기 일련의 카테고리들은 문장의 구조 요소들을 정의하고 명사, 수식어구 및 동사 클래스들을 가지는 음성의 유형들을 정의하는 구문 카테고리들을 포함하고, 상기 일련의 카테고리들은 상기 자연어 입력의 특정 발화 내의 특정 구문 카테고리의 기능을 정의하는 의미 역할들을 더 포함하고, 각 의미 역할은 상기 명사 및 동사 클래스들의 범위에 걸쳐 인수 또는 수식어구를 나타내고, 상기 일련의 카테고리들은 각 구문 카테고리와 각 의미 역할 간의 매핑을 더 포함함 -; 및

    상기 자연어 입력의 내용을 정규화하여 상기 자연어 입력이 복수의 상이한 언어들에서 상기 일련의 카테고리들 중 하나 이상의 카테고리와 연관될 수 있도록 하는 방법을 수행하는 컴퓨터 프로세서를 포함하고,

    상기 방법은,

    상기 자연어 입력의 구문 카테고리들의 클래스들의 인수들을 식별하기 위해 상기 프로세서에 의해 실행되는 프로시저들의 집합을 상기 자연어 입력에 적용하기 위해 일련의 규칙들을 따르는 단계; 및

    어휘 구조를 생성하기 위해 각 식별된 인수를 상기 일련의 카테고리들로부터의 적어도 하나의 카테고리와 연관시키는 단계;

    상기 어휘 구조가 복수의 상이한 언어 중 주어진 한 언어에 독립적이고 복수의 상이한 소프트웨어 응용 프로그램 중 임의의 특정한 소프트웨어 응용 프로그램에 독립적인 구조를 가지도록, 상기 복수의 상이한 언어에 걸쳐 상기 자연어 입력을 나타내는 상기 어휘 구조를 정규화하는 단계;

    상기 자연어 입력의 가능한 의미 해석을 나타내는 객체를 획득하기 위해 상기 어휘 구조를 어휘 객체 모델에 매핑하는 단계; 및

    용용 프로그램에서의 실체화를 위하여 상기 객체를 출력하는 단계를 포함하는,

    어휘 의미 시스템.
12. 자연어 입력의 의미들을 나타내고 해석하기 위한 어휘 의미 구조 시스템으로서,

    문장의 구조적 요소들, 구문 카테고리들 및 의미 역할들을 포함하는 어휘 의미 카테고리들의 인벤토리(inventory) - 상기 구조적 요소들은 명사, 수식어구 및 동사 클래스들을 가지는 음성의 유형들을 포함하고, 상기 인벤토리는 복수의 상이한 언어 중 임의의 특정한 하나에 독립적인 상기 자연어 입력의 내용을 나타내고, 상기 구문 카테고리들은 명사들, 동사들 및 수식어구들을 나타내고, 상기 의미 역할들은, 특정 자연어 발화 내의 특정 구문 카테고리의 기능과 상기 의미 역할들과 구문 카테고리들 간의 매핑을 정의하고, 각 의미 역할은 명사 및 동사 클래스들의 범위에 걸쳐 인수 또는 수식어구를 나타냄 -; 및

    상기 자연어 입력의 내용을 상기 인벤토리에 연관시키는 방법을 수행하는 컴퓨터 프로세서를 포함하고,

    상기 방법은,

    상기 프로세서에 의해 상기 자연어 입력의 구문 카테고리들의 클래스들의 인수들을 식별하고 상기 식별된 인수들을 상기 어휘 의미 카테고리들의 상기 의미 역할들에 연관시키기 위한 규칙들을 실행하는 단계;

    상기 어휘 의미 역할들을 이용해서 상기 식별된 연관된 인수들을 정규화하여 복수의 상이한 분석 엔진에 독립적인 구조를 가지도록 상기 복수의 상이한 분석 엔진에 걸쳐 정규화된 정규화 구조(normalized structure)를 획득하는 단계;

    상기 프로세서에 의해 구현된 분석 엔진으로 언어 객체를 획득하기 위해 상기 정규화 구조를 언어 객체 모델에 적용하도록 하는 로직을 실행하는 단계; 및

    상기 자연어 입력의 의미 해석을 획득하기 위한 실체화를 위하여 상기 언어 객체를 출력하는 단계를 포함하는,

    어휘 의미 구조 시스템.
13. 자연어 소프트웨어 응용 프로그램들을 프로그래밍하기 위한 소프트웨어 개발 도구가 저장된 컴퓨터 판독 가능 기록 매체에 있어서,

    상기 소프트웨어 개발 도구는,

    자연어 프로그래밍을 용이하게 하기 위한 일련의 프로그래밍 구성자들(constructs)을 포함하는 프로그래밍 언어 - 상기 일련의 프로그래밍 구성자들은 언어 객체 모델의 선언적인 언어 요소들에 대응하는 복수의 유형을 포함하고, 상기 복수의 유형 중 각 유형은 특정 음성 언어에 독립적이고, 상기 복수의 유형은, 데이터 멤버들, 속성들 및 메소드들을 가지는 엔티티 기반 클래스(entity base class)로부터 획득되는 엔티티 유형, 프레임 기반 클래스로부터 획득되고 동사들 및 명사들을 포함하는 의미 이벤트들을 모델링하도록 적응된 프레임 유형(frame type), 제한 기반 클래스로부터 획득되고 오블리크 인수들(oblique arguments), 수식어구들 및 다른 의미 요소들을 모델링하도록 적응된 제한 유형(restriction type)을 포함하고, 상기 엔티티 유형은 명사구들 및 형용사구들을 모델링하도록 적응되며, 상기 제한 유형은 상기 복수의 유형으로부터 획득된 객체들에 대한 엔티티들과 제한들 간의 의미 관계들을 정의하며, 상기 제한 유형은 구문 표현들에 걸쳐 관계 의미들을 정규화하도록 적응됨 -; 및

    메모리로부터 소프트웨어 프로그램을 수신하는 프로세서에 의해 실행가능한 컴파일러를 포함하고,

    상기 소프트웨어 프로그램은 상기 일련의 프로그래밍 구성자들의 인스턴스들을 포함하고, 상기 프로세서에 의해 실행가능한 상기 컴파일러는 상기 일련의 프로그래밍 구성자들의 인스턴스들로부터 소프트웨어 응용 프로그램을 생성하고, 상기 생성된 소프트웨어 응용 프로그램은 자연어 소프트웨어 응용 프로그램을 포함하는,

    컴퓨터 판독 가능 기록 매체.
14. 자연어 소프트웨어 개발을 위한 시스템으로서,

    명령어들을 저장하는 컴퓨터 판독 가능 기록 매체; 및

    상기 컴퓨터 판독 가능 기록 매체에 대한 액세스를 가지는 프로세서를 포함하고,

    상기 컴퓨터 판독 가능 기록 매체는,

    자연어 소프트웨어 응용 프로그램들의 프로그래밍을 용이하게 하기 위한 일련의 프로그래밍 구성자들을 포함하는 프로그래밍 언어 - 상기 일련의 프로그래밍 구성자들은 언어 객체 모델의 선언적인 언어 요소들에 대응하는 복수의 유형을 포함하고, 상기 복수의 유형 중 각각의 유형은 특정 음성 언어에 독립적임 -;

    상기 복수의 유형의 각각에 연관된 복수의 절을 포함하는 프레임워크 - 상기 복수의 절은 런타임에 상기 복수의 유형의 각각의 존재를 분석하기 위한 시작 절, 계속 절(success clause) 및 실패 절을 포함함 -; 및

    상기 일련의 프로그래밍 구성자들의 인스턴스들 및 상기 프레임워크를 포함하는 소스 코드를 취하고 컴퓨터 판독 가능 기계 코드 및 선언적인 스키마(declarative schema)를 생성하도록 적응된 컴파일러를 포함하고,

    상기 프로세서는 상기 일련의 프로그래밍 구성자들 및 상기 프레임워크로부터 선택된 구성자들을 포함하는 일련의 명령어들을 수신하도록 적응되고, 상기 프로세서는 상기 일련의 명령어들을 자연어 소프트웨어 응용 프로그램으로 컴파일하기 위해 상기 컴파일러를 실행하도록 적응된,

    자연어 소프트웨어 개발을 위한 시스템.
15. 자연어 사용가능 소프트웨어 응용 프로그램을 생성하기 위한 방법으로서,

    자연어 프로그래밍을 용이하게 하기 위한 언어 객체 모델의 선언적인 요소들과 관련된 복수의 유형을 포함하는 일련의 프로그래밍 구성자들로부터 프로그램을 생성하는 단계 - 상기 복수의 유형의 각 유형은 특정 음성 언어에 독립적이고, 상기 프로그램은 자연어 입력에 의존하는 상기 소프트웨어 응용 프로그램의 특징들을 기술하고, 상기 복수의 유형은, 데이터 멤버들, 속성들 및 메소드들을 가지는 엔티티 기반 클래스로부터 획득되고 명사구들 및 형용사구들을 모델링하도록 적응된 엔티티 유형, 프레임 기반 클래스로부터 획득되고 동사들 및 명사들을 포함하는 의미 이벤트들을 모델링하도록 적응된 프레임 유형, 제한 기반 클래스로부터 획득되고 오블리크 인수들, 수식어구들 및 다른 의미 요소들을 모델링하도록 적응된 제한 유형 및 상기 엔티티 유형으로부터 실체화된 엔티티 객체들을 자연어 단어들로 매핑하는 특권 데이터 멤버(priviledged data member)를 나타내는 표시자를 포함하고, 상기 제한 유형은 상기 복수의 유형으로부터 획득되는 객체들에 대한 엔티티들과 제약들 간의 의미 관계들을 정의하고, 상기 제한 유형은 구문 표현들에 걸쳐 관계 의미들을 정규화하도록 적응됨 -;

    프로세서를 통해 상기 프로그램을 소프트웨어 응용 프로그램으로 컴파일링하는 단계; 및

    상기 소프트웨어 응용 프로그램을 메모리에 저장하는 단계를 포함하는,

    자연어 사용가능 소프트웨어 응용 프로그램 생성 방법.
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제
41. 삭제
42. 삭제
43. 삭제
44. 삭제
45. 삭제
46. 삭제
47. 삭제
48. 삭제
49. 삭제
50. 삭제

Images