상태 :
Dgidx 매핑 라틴, 라틴 확장-A, 및 Windows CP1252 인덱싱 동안 자신의 간단한 ASCII 상응하는 국제 문자를 지원합니다.
이것은 그리스어가 이러한 문자 집합에 속하지 않으므로 지원되지 않는다는 것을 의미합니다 (그리스어가 라틴어 -7라고 생각합니다). 즉, 각 언어가 자체 레코드를 가지고 있거나 dgidx
및 dgraph
매개 변수를 사용하여 글로벌 언어를 구현하려고한다고 가정하면 레코드 수준에서 언어 플래그를 설정할 수 있습니다 (데이터에 영어와 그리스어가 모두 포함되어 있음을 나타 내기 때문에). 글로벌 언어가 아닌 레코드 나 속성의 형태소 분석에 영향을 미칩니다.
dgidx --lang el
dgraph --lang el
원본 문장을 기반으로 작동하는지 확신 할 수 없지만.
또는, atg.repository.search.indexing.PropertyAccessorImpl
클래스 확장하는 사용자 정의 Accessor
사용하여 발음 구별 제거의 과정을 구현할 수 있습니다 (당신이 Nucleus
을 참조하기 때문에 옵션을, 그래서 당신은 ATG/오라클 상공를 사용한다고 가정). 이를 사용하여 현재 색인의 검색 가능한 필드를 복제하지만 이제 모든 발음 구별 부호가 제거 된 색인의 정규화 된 검색 가능 필드를 지정합니다. Accessor
에서 적용한 동일한 논리를 검색 조건의 전처리기로 적용해야 입력을 정규화하여 인덱싱 된 값과 일치시킬 수 있습니다. 마지막으로 색인의 원래 필드를 강조 표시 문자로 표시 전용으로 만들고 정규화 된 필드를 검색 가능으로 표시하지만 표시하지는 마십시오.
결과는 정규화 된 텍스트와 일치하지만 색인이 더 커지도록 중복 된 데이터가 있다는 단점이 있습니다. 작은 데이터 세트에는 큰 문제가 아닙니다. 형태소 분석과 같은 OOTB 기능이 정규화 된 데이터 세트와 함께 작동하는 방법에 영향을 미칠 수도 있습니다. 정밀도와 리콜에 악영향을 미치는지 알아 보려면 그리스어와 영어로 다양한 시나리오를 테스트해야합니다.
안녕 Radimpe. 귀하의 답변에 감사드립니다. 그리스어 oob은 OLT이지만 우리는 선입견과 와일드 카드가 필요하므로 Latin-1을 사용합니다. –
그런 경우 인덱스의 입력 데이터를 정규화 한 다음이를 입력 전으로 전달하기 전에 즉석에서 정규화하면 긍정적 인 결과가 발생할 수 있습니다. – radimpe
형식 전달을위한 formhandler에서 우리는 발음 구별을 모두 음역하고 ProductCatalogIndexingAdmin에 서비스를 추가하여 Endeca 데이터에도 동일한 작업을 수행했습니다. 매력처럼 작동합니다. – bated