我正在构建一个具有“Artifact”类型的主LuceneDocument的解决方案。
在工件中,我们正在提取复杂的数据类型,以进一步分类和组织数据。作为Solr索引的一部分,我们的目标是允许用户跨工件的全文以及跨这些复杂数据类型执行搜索查询。
示例文字:
“这个名叫约翰·多伊的年轻人跳过这只懒狗,然后在宾夕法尼亚州匹兹堡的123 Indiana Blvd与棕色狐狸共进晚餐。过了一段时间,棕色的狐狸飞到宾夕法尼亚州的1600总统那里。 Ave,Washington,DC 20500“我们的提取过程将提取三个有用的实体:
我们需要进一步分解#2& #3进入
在Solr发布期间,我们将使用以下字段创建一个可索引对象(使用Solr4J):
@Field
String artifactBody;
@Field
List<String> streetAddressOne;
@Field
List<String> city;
@Field
List<String> state;
@Field
List<String> zipCode;
@Field
List<String> person;
一切顺利,我们将这些记录发布给Solr,没有任何问题。
在用户搜索“streetAddressOne:Indiana AND city:Washington”中,我们会收到误报。现在,事实是华盛顿特区实际上确实有印第安纳大道,所以搜索是一个有效的地址描述。
这是我们用例的整体描述,我正在询问一些替代方法,这些方法可以保证不会返回这种误报,但仍然可以在复杂类型上进行匹配。
我开始使用PolyField类型,但是当您想要搜索集合中所有字段的子集时,这似乎不适用。
我还研究了将Address发布为Solr的LuceneDocument项的路径。挑战在于结果集需要反映工件列表,而不是地址列表。这种“类似连接”的功能在搜索引擎中是不可用的,所以我放弃了这个想法。