의미격차
Semantic gap이 글은 검증을 위해 인용구가 추가로 필요하다. – · · · (2011년 10월 (이 템플릿 를 |
의미적 간격은 언어 또는 기호 등 다른 언어 표현에 의해 사물에 대한 두 설명 사이의 차이를 특징짓는다.안드레아스 하인에 따르면 의미격차는 "다른 표현체계 내에서 형성된 구성물들 사이의 의미 차이"로 정의할 수 있다.[1]컴퓨터 과학에서, 이 개념은 일반적인 인간의 활동, 관찰, 과제가 컴퓨터 표현으로 옮겨질 때마다 관련이 있다.[2][3][1]
좀 더 정확히 말하자면, 그 간격은 강력한 언어(예: 자연 언어)에서의 문맥적 지식의 애매한 공식화와 공식 언어(예: 프로그래밍 언어)에서의 소리, 재현 및 계산적 표현 사이의 차이를 의미한다.사물의 의미론은 사물이 내부에서 간주되는 맥락에 따라 달라진다.실제 적용의 경우, 이는 실제 작업의 공식적 표현은 응용 프로그램의 상황별 전문가 지식(높음)을 컴퓨팅 머신의 초기 및 재현 가능한 작동(낮음)으로 변환해야 함을 의미한다.자연어는 공식적인 언어로 계산할 수 없는 작업의 표현을 허용하기 때문에 일반적인 방법으로 이 번역을 자동화할 수 있는 수단이 없다.더욱이 촘스키 서열 내의 언어에 대한 조사는 특정 수준의 표현력보다 한 언어에서 다른 언어로 번역하는 형식적이고 결과적으로 자동화된 방법이 없다는 것을 보여준다.
이론적 배경
아직 증명되지는 않았지만 일반적으로 받아들여지는 Church-Turing 논문은 튜링 기계와 람다 미적분학과 같은 모든 동등한 공식 언어가 컴퓨팅 인간이 적용하는 모든 공식 작업을 각각 수행하고 나타낸다고 말한다.그러나 정확한 계산 자체에 대한 적절한 연산의 선택은 공식적으로 설명할 수 없으며, 더욱이 기초적인 문제의 연산 가능성에 달려 있다.중단문제와 같은 과제는 자연어로 포괄적으로 공식화할 수 있지만, 계산적 표현은 종료되지 않거나 사용 가능한 결과를 제공하지 않으며, 이는 라이스의 정리에 의해 증명된다.괴델의 불완전성 정리에 의한 규칙 기반 추론에 대한 한계의 일반적인 표현은 의미적 차이가 결코 완전히 닫히지 않아야 한다는 것을 나타낸다.이는 의미격차가 나타나는 최고 수준의 추상화에 대한 계산의 일반화된 한계를 고려한 일반적인 진술이다.그러나 특히 촘스키 계층의 높은 수위에서는 자동으로 번역될 수 있는 문제들의 하위 집합이 많다.
격식어
실제 업무는 프로그래밍 언어에 의해 공식화되는데, 폰 노이만 아키텍처를 기반으로 한 컴퓨터에서 실행된다.프로그래밍 언어는 튜링 머신의 편안한 표현일 뿐이기 때문에 폰 노이만 컴퓨터의 프로그램은 튜링 머신이나 그와 동등한 표현과 동일한 특성과 한계를 갖는다.따라서 CPU 레벨 머신 코드, 조립자 또는 어떤 고급 프로그래밍 언어와 같은 모든 프로그래밍 언어는 기본 튜링 머신이 계산할 수 있는 것과 동일한 표현력을 가진다.프로그램이 높은 수준의 언어에서 사용자 상호작용 없이 튜링 기계에서 실행되는 컴파일러와 같은 프로그램에 의해 기계 코드로 전달되기 때문에 이들 사이에는 의미적 차이가 없다.실제로 규칙의 선택과 과제의 표현 사이에 의미적 격차가 벌어진다.
실제적 결과
실제 응용 프로그램의 공식 표현을 위한 규칙의 선택은 프로그램 작성에 해당한다.쓰기 프로그램은 실제 프로그래밍 언어와는 독립적이며 기본적으로 사용자의 도메인별 지식을 튜링 머신을 운영하는 공식 규칙으로 변환해야 한다.그것은 계산의 이론적 한계와 관련하여 자동화할 수 없는 문맥적 지식에서 형식적 표현으로의 전환이다.결과적으로, 현실 세계 애플리케이션에서 컴퓨터 애플리케이션으로의 매핑은 의미 격차 자체가 나타나는 사용자에 의한 일정량의 기술적 배경 지식을 필요로 한다.
응용 프로그램 특정 지식과 기술적으로 실행 가능한 공식화 사이의 격차를 줄이는 것은 소프트웨어 엔지니어링의 근본적인 과제다.이러한 목적을 위해 특정 도메인(높은 수준)의 지식은 알고리즘과 그 매개변수(낮은 수준)로 전달되어야 한다.이를 위해서는 사용자와 개발자 간의 대화가 필요하다.목표는 항상 사용자가 구현의 세부사항을 알지 못한 채 알고리즘의 매개변수로 자신의 지식을 표현할 수 있도록 하고, 개발자의 도움 없이 알고리즘의 결과를 해석할 수 있도록 하는 소프트웨어다.이러한 목적을 위해 사용자 인터페이스는 소프트웨어 설계에서 핵심적인 역할을 하는 반면 개발자들은 상황별 정보의 통합을 조직하는 데 도움이 되는 프레임워크에 의해 지원된다.
예
문서 검색
간단한 예는 알려진 컴퓨터 시스템에서 로컬로 존재할 수도 있고 존재하지 않을 수도 있는 대상 문서를 찾기 위해 점점 더 어려워지는 일련의 자연어 질의로 공식화될 수 있다.
쿼리 예:
- 1) 알려진 디렉토리 "/usr/local/funny"에서 파일을 찾으십시오.
- 2) funny라는 단어가 파일 이름에 나타나는 파일을 찾아라.
- 3) 텍스트에 "funny" 또는 "humor"라는 단어가 나타나는 텍스트 파일을 찾으십시오.
- 4) "재미", "코믹" 또는 "휴머"가 메타데이터에 나타나는 모든 mp3 파일을 찾는다.
- 5) 유머와 관련된 모든 형식의 파일을 찾아라.
- 6) 할머니를 웃길 것 같은 이미지를 찾아라.
이러한 질의의 진행적 난이도는 시스템 아키텍처(알려진 컴퓨터의 디렉터리와 파일)를 정의한 유형과 의미론에서 일반적인 인간 담론의 영역을 점유하는 유형과 의미론("humor"와 같은 주체, "나의 할머니"와 같은 실체)으로 추상화의 정도가 증가하는 것으로 표현된다.더욱이, 이러한 현실의 격차는 대상 문서가 존재할 수 있지만, 사용자나 쿼리 처리 시스템의 설계자가 예상하는 방식으로 "메타데이터"를 캡슐화하지 않을 수 있는 질의 4의 경우에 흔히 있는 것과 같은 누출된 추상화에 의해 더욱 복잡해진다.
영상분석
이미지 분석은 낮은 수준의 방법에서 높은 수준의 추상화가 필요한 대표적인 영역이며, 의미적 차이가 사용자에게 즉시 영향을 미치는 영역이다.영상의 의미를 이해하기 위해 영상 콘텐츠를 식별해야 하는 경우, 사용할 수 있는 유일한 독립 정보는 낮은 수준의 픽셀 데이터뿐입니다.텍스트 주석은 항상 주석자의 지식, 표현 능력 및 특정 언어에 의존하므로 신뢰할 수 없다.영상의 원시 데이터에서 표시되는 장면을 인식하려면 픽셀의 선택과 조작을 위한 알고리즘을 적절한 방식으로 결합하고 파라미터화하여 최종적으로 자연 설명과 연결해야 한다.원형이나 노란색과 같은 모양이나 색상의 단순한 언어적 표현에도 전혀 다른 수학적 형식화 방법이 필요하며, 이는 직관적이거나 독특하지 않고 건전하지 않다.
레이어드 시스템
많은 계층화된 시스템에서 높은 추상화 수준의 개념을 보다 낮고 구체적인 유물로 번역해야 할 때 일부 충돌이 발생한다.이 불일치는 종종 의미적 격차라고 불린다.
데이터베이스
OODBMS(객체 지향 데이터베이스 관리 시스템)를 옹호하는 사람들은 이러한 데이터베이스가 애플리케이션 도메인(미니월드)과 기존 RDB 사이의 의미 차이를 줄이는 데 도움이 된다고 주장한다.MS 시스템.[4]그러나 관계형 지지자들은 정의에 의해 기록되는 데이터를 단일 바인딩 추상화로 고정시키기 때문에 정반대의 입장을 취할 것이다.
참고 항목
참조
- ^ a b Hein, A. M. (2010). "Identification and Bridging of Semantic Gaps in the Context of Multi-Domain Engineering". Abstracts of the 2010 Forum on Philosophy, Engineering & Technology. Colorado.
{{cite web}}
: CS1 maint : url-status (링크) - ^ Smeulders, A. W. M.; et al. (2000). "Content-Based Image Retrieval at the End of the Early Years". IEEE Trans Pattern Anal Mach Intell. 22 (12): 1349–80. doi:10.1109/34.895972.
- ^ Dorai, C.; Venkatesh, S. (2003). "Bridging the Semantic Gap with Computational Media Aesthetics". IEEE MultiMedia. 10 (2): 15–17. doi:10.1109/MMUL.2003.1195157. hdl:10536/DRO/DU:30044313.
- ^ Schlatter, M.; et al. (1994). "The Business Object Management System". IBM Systems Journal. 33 (2): 239–263. doi:10.1147/sj.332.0239.