ブログトップ 記事一覧 ログイン 無料ブログ開設

FrontRunner このページをアンテナに追加 RSSフィード

カウンター

2011-07-13

[]検索発見のためのデザイン 検索と発見のためのデザインを含むブックマーク

検索と発見のためのデザイン ―エクスペリエンスの未来へ

検索と発見のためのデザイン ―エクスペリエンスの未来へ

検索と題してはいるけど、なんだか検索を前提としていない雰囲気の本。

検索というのは発見のための1つのユースケース(もしくは実現方法であるという主旨が最初の方にくる。発見ではなくナレッジマネジメント(!)の一部であるというところまで行くあたりが、この本が技術要素としての「検索」をメインに扱っていないことを表している。

後半に登場するパターンは参考にならないことももちろんないが、どちらかというとそういう思考フレームワーク的な、手順を踏まえて検索を考える向きにとても面白い検索をよくするということは、発見やその体験をよくするということであって、検索という形だけじゃなくてもっと別なところも見ないといけない、というあたりはとても納得感がある。

検索というものをより良くするには、専門分野の垣根を越えたコラボレーションが必要だし、自分たちが思い描いている障壁を突破しないとね。

自由に考えるというより、きちんと筋道立てて考えているんだと思った。もしくは筋道立てて伝えてくれている。


どんなにセンスが必要な話であっても、本にまとまるときちんと目的からはじめてくれる。うれしいです。


以下はこの本と連動した(?)サイト

Search Patterns

トラックバック - http://d.hatena.ne.jp/Hayato/20110713

2011-05-08

[]ファイルをtikaで解析してSolrインデックスに入れるDataImportHandlerの設定 ファイルをtikaで解析してSolrのインデックスに入れるDataImportHandlerの設定を含むブックマーク

Solr 3.1からTikaEntityProcessorというDataImportHandler用のProcessorがついたけど、これをDataSourceや他のProcessorとどう組み合わせて良いかがさっぱりわからない。

ぐぐりつつ試してみて、あるディレクトリ以下のファイルを全て取り込むのは多分これで良いという結論になった。

data-config.xml

<dataConfig>
    <dataSource type="BinFileDataSource" name="bin"/>
    <document>
        <entity name="file" processor="FileListEntityProcessor"
                baseDir="/path/to/targetdir"
                fileName=".*"
                recursive="true"
                rootEntity="false"
                dataSource="null">
              <entity name="tika" processor="TikaEntityProcessor"
                      dataSource="bin"
                      url="${file.fileAbsolutePath}"
                      format="text"
                      transformer="LogTransformer"
                      logTemplate="file: ${file.fileAbsolutePath} processed"
                      logLevel="info"
                      onError="skip"
              >
                   <field name="Author" meta="true" column="author"/>
                   <field name="title" meta="true"  column="title"/>
                   <field name="text"               column="text" />
              </entity>
        </entity>
    </document>
</dataConfig>

TikaEntityProcessorはDataSource<InputStream>のサブクラスがdataSourceになってないといけない。なのでBinFileDataSourceが必要。で、BinFileDataSourceはファイル絶対パスが必要なのでFileListEntityProcessorからもらう。

FileListEntityProcessorはあるディレクトリの下にあるファイルを一つ一つ処理する感じ。正規表現ファイルをexcludeすることもできる。

  1. FileListEntityProcessorでファイルパスリストを作る
  2. 一つずつTikaEntityProcessorで処理する
    1. FileListEntityProcessorで作ったファイルパスを受け取る
    2. BinFileDataSourceにパスを渡す
    3. InputStreamになったデータを処理してスキーマに合わせて突っ込む

このFileListEntityProcessorとの組み合わせがあんまり情報ないんですよ。。。

対応するschema.xml(の一部)

 <fields>
   <field name="title" type="string" indexed="true" stored="true"/>
   <field name="author" type="string" indexed="true" stored="true" />
   <field name="text" type="text" indexed="true" stored="true" />
   
 </fields>

スキーマはこんな感じ。多分他にも増やせばTikaが抽出できるメタデータをもっと入れられるんだと思うけど、そこまで調べられていない。


やってみると、Tikaで処理できない旨のエラーが結構おきる。処理できなかったときには、特別なログに吐くなどしてエンドユーザに知らせたいんだけど、今のところSolr普通通りログに吐くことしかできない。onErrorで好きな処理を指定することができなくて、abortするかそのドキュメントskipするかしかできない。

トラックバック - http://d.hatena.ne.jp/Hayato/20110508

2011-01-12 このエントリーを含むブックマーク

トラックバック - http://d.hatena.ne.jp/Hayato/20110112

2010-11-28

[]ザ・ベロシティ ザ・ベロシティを含むブックマーク

そこそこのページ数だったが、夜なべして後半は一気に読んでしまった。

内容についてはザ・ゴールからつづく一連のやり方と大体同じで、ある問題が多い会社を舞台にTOCを活用して業績を上げるというおなじみかつ分かりやすいストーリー。楽しめたし、相変わらずいい読後感。

リーンだのTPSだのTOCだのみたいな概念について、いろんな人が共通認識として持っていると偉い楽だなあと思ってる。さらに、エンジニアだったらその工学的な側面では捉えていないと困るとも思う。「ボトルネック」という言葉が通じなかったりするとorzとなるし。

そのためにも、小難しく聞こえがちなものをこういう小説仕立てで見せるのはいい。もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら の偉いところもそこだよね。あれはもっとデフォルメが極端だけど、抽象的だったり分かりづらかったりするのを具体的なストーリーで見せるのは同じ。

そういうのが教養を形成する、と言うのかどうかはわからないけど、そういう方面の共通のコンテキストを作るのが会社という組織だけでは難しい側面もあるから、こういうのはもっと売れて欲しい。もしドラレベルとまでは言わないけど。

トラックバック - http://d.hatena.ne.jp/Hayato/20101128

2010-07-30

[]Lucene3.1でのQueryParserの挙動変更 Lucene3.1でのQueryParserの挙動変更を含むブックマーク

デフォルトでPhraseQueryを生成しなくなったQueryParserに注意(3.1)を読んで意味が分からなかったので、プログラムを実行してみた

public class TestLucene2458 {
	static final Version V = Version.LUCENE_31;

	public static void main(String args[]) throws CorruptIndexException,
			IOException, ParseException {
		Directory directory = createIndex();
		IndexSearcher searcher = new IndexSearcher(directory);

		QueryParser qp = new QueryParser(V, "F", new CJKAnalyzer(V));
		Query query = qp.parse("あいえお");
		TopDocs docs = searcher.search(query, 5);
		System.out.println(docs.totalHits);
	}

	private static Directory createIndex() throws CorruptIndexException, IOException {
		Directory directory = new RAMDirectory();
		Analyzer analyzer = new CJKAnalyzer(V);
		MaxFieldLength maxlen = new MaxFieldLength(100);
		IndexWriter writer = new IndexWriter(directory, analyzer, true, maxlen);
		Document doc = new Document();
		doc.add(new Field("F", "あいうえお", Field.Store.YES, Field.Index.ANALYZED));
		writer.addDocument(doc);
		writer.close();
		return directory;
	}
}

ようするに、"あいうえお"というドキュメントにたいして"あいえお"で検索している。なんと、これがhitする。

1

		qp.setAutoGeneratePhraseQueries(true);

を入れると0になる。

ええーーーー。議論読んでないんで、良く意味が分からない。。

トラックバック - http://d.hatena.ne.jp/Hayato/20100730
最新コメント一覧
プロフィール

Hayatoのブックマーク