Monthly Archives: 11月 2013

ヤフカテLODからDBpediaJapaneseへのトリプルを追加

Yahoo!カテゴリLODのカテゴリリソースからDBpedia Japaneseのリソースへのトリプルを追加した。

単純な文字列探索でマッチしたリソースへ、rdfs:seeAlsoプロパティでリンクした。

ヤフカテでは「レストラン、飲食店」のように読点で区切られているカテゴリ名が多く存在する。この場合、句点で区切った単位で文字列探索を行った。例えば先ほどの例で「レストラン、飲食店」カテゴリは「http://ja.dbpedia.org/resource/レストラン」と「http://ja.dbpedia.org/resource/飲食店」へリンクする。

DBpedia Japaneseのリソースを値に持つトリプル数は279039となった。

次はまた違ったアプローチで他LODへのリンクを試みたい。

安直なowl:sameAsリンクの危険性について考える

最近まで、ねじLODのリソースからDBpediaJapanese内の同意義のリソースへowl:sameAsでリンクしていた。

夏に研究会発表した時にowl:sameAsはやめたほうが良いよという意見を頂いたので、一時は使わないことを考えたものの、結局他のLODもowl:sameAsをよく使っていたので自分も使っていた。

最近になってまた色々考えたり調べたりしたところ、owl:sameAsでのリンクはやはりまずいかなと思い始めた。

Continue reading

java.lang.InstantiationError: com.hp.hpl.jena.sparql.engine.binding.BindingMap

Jenaのバージョンをあげてみたら下のようなエラーが

java.lang.InstantiationError: com.hp.hpl.jena.sparql.engine.binding.BindingMap

ググってみたらどうやらarqのバージョンのせいらしい。

jena-arq-2.x.x.jarからバージョン2.5.5に同梱されていたarq.jarに戻してみるとエラーが消えた。

参考

java.lang.InstantiationError while running sparql query in jena

Linux(CentOS) Java SE アップデート JDK1.6→1.7

CentOSのJava SEをアップデートしたのでメモ

今回はjdk1.6.0_24→jdk1.7.0_45のつもりだったが、どうやら前に1.7.0_11を入れた痕跡があっので面倒だった。

Java SE Downloadsからrpmをダウンロード。64bit環境なのでjdk-7u45-linux-x64.rpmをダウンロードした。

バージョン確認

# java -version
java version "1.6.0_24"

先ほどDLしたrpmの実行

# rpm -ivh jdk-7u45-linux-x64.rpm
準備中...                ########################################### [100%]
        ファイル /etc/init.d/jexec (パッケージ jdk-2000:1.7.0_45-fcs.x86_64 から) は、パッケージ jdk-2000:1.7.0_11-fcs.x86_64 からのファイルと競合しています。

以前にjdk1.7.0_11を入れた痕跡があった。しかもパスが通っていなかったらしく、バージョン確認の段階で分からなかった。

とりあえず1.7.0_11をアンインストール

# rpm -e jdk-1.7.0_11-fcs.x86_64

そしてもう一度

# rpm -ivh jdk-7u45-linux-x64.rpm
準備中...                ########################################### [100%]
   1:jdk                    ########################################### [100%]
Unpacking JAR files...
        rt.jar...
        jsse.jar...
        charsets.jar...
        tools.jar...
        localedata.jar...
        jfxrt.jar...

成功。次にパスを通す。

設定の確認

# alternatives --display java
java -ステータスは自動です。
リンクは現在 /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java を指しています。
/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java - 優先項目 16000
 (略)
現在の「最適」バージョンは /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java です。

alternativesに新しくインストールしたバージョンの追加。1.7.0_45なので優先項目を17045とした。

# alternatives --install /usr/bin/java java /usr/java/default/bin/java 17045

変更結果の確認

# alternatives --display java
java -ステータスは自動です。
リンクは現在 /usr/java/default/bin/java を指しています。
/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java - 優先項目 16000
(略)
/usr/java/default/bin/java - 優先項目 17045
(略)
現在の「最適」バージョンは /usr/java/default/bin/java です。

使用するJavaバージョンの変更

# alternatives --config java

2 プログラムがあり 'java' を提供します。

  選択       コマンド
-----------------------------------------------
 + 1           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
*  2           /usr/java/default/bin/java

Enter を押して現在の選択 [+] を保持するか、選択番号を入力します:

2を入力してEnter

確認

# java -version
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

完了。

Virtuoso SPARQL Query EditorでのTransaction timed out

日本語DBpediaのSPARQLエンドポイントで下の様なクエリを実行する

select distinct * where {?s rdfs:label ?o filter regex(?o, "東京", "i") }

少々時間はかかるが結果は表示される。

しかしヤフカテLODのSPARQLエンドポイントでは同様のクエリで結果はTransaction timed outになる。

この違いは何なのだろうか。

ためしにLimitを100にしてみると、結果は普通に表示された。

ここでやっと気づく。

ヤフカテLODではlabelにアンダースコアで上位カテゴリをくっつけている(同名カテゴリとの区別のため)ため、東京という文字列が含まれる結果を返そうとすると、東京都カテゴリ以下全てのカテゴリ+東京という文字列が含まれるサイトを返してしまう。

すなわち膨大な数の結果を返すことになるのでTransaction timed outが発生してしまうのではないか。と思ったんだけど、本家DBpediaでも日本語DBpediaでも、それなりに結果数が多くなりそうなクエリをかけてみてもTransaction timed outにはならない。これはやはりVirtuosoの方で設定があるんだろうか?

とりあえず解決策としてLimitをつける。また、ヤフカテLODの場合、カレントカテゴリの名前のみの値はrdfs:labelの代わりにdcterms:titleを使っているのでそちらに置き換える。

そんなわけでTransaction timed outにならない方法知ってる方いたら教えてください。