マイクロフォーマットとエンティティが結びつくと。。。

　きょう、セマンティックWebコンファレンス２００８に、「午後から」行ってきました
（午前中は用事があった）。

で、そこで、マイクロフォーマットっていう話が出ていた。
　たしかに、HTMLのなかに、Classとかよく書くけど、もっとも、物理的スタイルのために書いちゃうことも多い気がします。

　ここで、ちょっと話は変わるけど、

　エンティティとRDBのテーブルの関係っていうのは、まあ、おんなじようなもんで、ほぼ対応づけられる。
　
　RDBからRDFっていうのは、RDBのレコードと項目値の組からRDFに置き換えられる・・・かな？

　なので、ここで、エンティティと、マイクロフォーマットのクラスが対応づけられれば、

　HTML（マイクロフォーマット）－ER図－テーブル－RDF

　間で、相互関係を保てるのかも・・

　で、エンティティとマイクロフォーマットのClassの関係だけど、
　マイクロフォーマットのclassは、エンティティそのものと、エンティティの属性両方を表すことがあるっていう感じかなあ。。。
　ということは、エンティティ名、属性名を、マイクロフォーマットのclassの名前を合わせれば、DBのORマッピングのように、画面に対するORマッピングもできるし、セマンティックWebへの対応もできてくるのかもしれない。。。

・・・と、ちょっと、頭の体操をした。

オントロジーWikiっていうのを、見てみた!

そいつは、ここ
http://nike.ohsuga.is.uec.ac.jp/OntoWiki/
にあるらしい。
(リダイレクトされて、ポート８１８０になる）

（１）まず、検索ボタンを押すのかしら？


（２）とりあえず、検索クリックして、検索してみましょう


（３）何かを選択すると、下に、グーグルブログの検索結果が・・


（４）検索終了後（（３）終了後でもOK)
　　　選択ボタンをクリックして（クリックしないと（５）は出ない）
　　　グラフをクリックすると・・


（５）こんな感じのものが・・・


これ以降は、まだ良くわかんない

翻訳機を使って、ローカライゼーションする場合の手順をまとめてみる－その３

　シリーズ化してしまった「翻訳機を使って、ローカライゼーションする場合の手順をまとめてみる」のつづき

ローカライズするには、たぶん、次の３つの手順が必要だと思う。

（１）国際化対応プログラムになっているか確認
（２）翻訳＆前のバージョンのものを入れる
（３）翻訳したものを戻し、稼動するか確認

　前回は、（２）の手順を示しました。大きく、自動化できる部分と、手作業でやる部分に分かれるのですが、今回は、自動化される部分について書きます。
　なお、話を簡単にするため、英語から日本語訳への変換を例にとります（ほかの言語は適当に置

き換えて考えてください）

---

■自動化部分の手順

　いちおう、前回書いた自動化部分の手順を振り返っておくと

（１）翻訳機で翻訳する
（２）前バージョン上書き
（３）翻訳ワークベンチ用DBにいれる
（４）ID＋ステータス用を作成

以下、それぞれについて説明します。

<HT>

■（１）翻訳機で翻訳する

　翻訳すべき英語の文を翻訳機で翻訳します。
　このとき、辞書には、もし、前回のバージョンを作った時に、用語統一辞書があれば、その辞書を使います。
　とすると、今回初めてのときは、ユーザー辞書はないことになります。
　で、よいのですが、（次回説明すると思いますが）、用語統一辞書を先に作る方法もあります。

その場合は、用語統一辞書ができているので、それを使います。

　また、翻訳用ワークベンチに翻訳機能が付いているものや、翻訳させない（ワークベンチに複数の訳が出て、選択する形のもの）場合は、この作業自体がありません。

　ま、とにかく、それで、訳したものができます。

---

■前バージョン上書き

　前バージョンで翻訳してあるものは、上書きします。

　このとき、メッセージIDが動かない方式と動く方式でやり方が違います。

●メッセージIDが動かない方式の場合
　あるバージョンで一度IDを降ったら、以降のバージョンでも同じIDを
　使います。このため、そのメッセージが必要無くなり、プログラムから
　削除されたら、そのIDは空番になります。
　　逆に、追加される場合は、最後の最大IDに１足して、新たなIDを
　作っていくという方式の場合です。

　このときは、IDがキーになっているので、
　前バージョンの翻訳元のIDに対応する訳を、
　（１）で翻訳したものの同じIDのメッセージ部分に上書きすれば
いいことになります。
　単純です。

●メッセージIDが動く方法の場合
　バージョンごとにメッセージIDが異なるものです
　メッセージカタログが実は存在しないというケースで、自動生成で
　メッセージカタログを作るような場合にありえます。

　この場合、メッセージIDは対応しないので、メッセージ内容自体で
比較します。

　前バージョンの翻訳元ファイルのメッセージ部分（英語の部分）と、
　今回のバージョンの翻訳元のメッセージ部分（英語の部分）が、

同じであれば

　前バージョンで翻訳したメッセージ部分（日本語の部分）を、
　上記（１）の翻訳結果に上書き

します。

　ただし、watchが時計と、監視の２つの意味で使われている
（前バージョンの翻訳元が同じメッセージで訳が２種類以上でてくる）
場合は、この上書き対象から外します。

---

■（３）翻訳ワークベンチ用DBにいれる

（２）まででできた結果を、翻訳ワークベンチ（Babelとかが、それに当たる）
のDBにいれます。ふつうDBです（共同作業するので）
　ファイルだったら、べつに（３）の作業はありません。

---

■（４）ID＋ステータス用を作成

　あとの画面の仮訳のために作るものです。

　メッセージカタログは普通IDとメッセージの組み合わせです。
　で、メッセージに翻訳したものが入るのですが、ここで、メッセージに
　メッセージIDとステータスをあわせたものを、（自動生成して）書きます。
　ステータスは、

　X　翻訳できない
　A　翻訳機で翻訳した
　B　前バージョンで上書きした

　となります。ちなみに、このあとも、ステータスはつづき

　C　仮訳
　D　用語統一後、翻訳（確認）

　全体に対するDの割合が翻訳率になります。

　ということで、具体的に、
　　　　メッセージIDが、12345
　　　　現在、翻訳機で訳した状態（前バージョンにはない）
　だったら、メッセージに入るのは

　　　　12345 A

　となります。

　このメッセージカタログを作成し、それを画面で開くと、メッセージIDと状態が一気にわかるということができます（実は、このID＋ステータスを翻訳したものの前に入れるという手もあるのですが、それはそれで便利なのですが、画面が崩れるので、あまりよくない気もします）。

　これにより、
　　　・オフラインで翻訳できる
　　　・画面ごとに分け、画面項目から訳していくことが可能になる
　　　　→上記のメッセージID＋ステータスのメッセージカタログ
　　　　　のプログラムを起動し画面を見れば、IDがわかる。
　などのメリットがあり、そのためで作ります。

　なお、どーやって、ステータスを自動生成でわかるかというと、
　（１）の翻訳が、翻訳できない状態になっていれば、X
　（２）で置き換えたらB、ステータスがこの時点で入ってなければA
　ということで、実は（２）の置き換えで、このステータスファイルを
　同時に作ってしまうほうが楽です。

---

ということで、次回は手動部分です。