PDIC Dictionary Server Project |
---|
PDICの辞書をインターネット上でリアルタイムに共有しよう、というプロジェクトです。
日本であれば英和辞書は英辞郎をはじめとして立派な辞書が数多くありますが、それ以外の辞書は相変わらず”紙”の辞書であったり、語数が少なかったりいい辞書はなかなか見つかりません。マイナーな言語であってもユーザー同士で情報を提供し合えば立派な辞書ができる可能性は十分あります。古きよき時代にあった"Give and Take"でいい辞書を作ることができればいいな、と思います。
PDICを作り始めた頃は、紙の辞書を引き、いくつかある訳語の中から自分が今読んでいる文章の中でもっとも一番近い訳を入力したり、無ければ自分で考えて訳語を入力していました。それが実は英語の勉強としては効果的だったかもしれません。PCのおかげで簡単に検索結果を出せるようになったのはいいのですが、それに反して語学力アップになかなかつながらなくなっているような気がします。
やはり一つ一つの単語を時間をかけて理解することが大切かもしれません。ネット共有辞書機能はそういう学習をする一つの方法かもしれません。辞書は単なる訳語・例文が載っているだけではなく、様々な情報を載せた方が印象に強く残ったり。。使い方は色々と考えられると思います。
メインはこちらの開発メモにあるMLにします。(PDIC Development ML)
たぶん盛り上がることはないと思うので、pdic-wwlはcloseします。
掲示板:PDIC Dictionary Server Project→廃止します
Web サーバーのCGIを利用して、複数のPDICを使用しているユーザー同士でリアルタイムで辞書を共有することを目的とします。PDICの辞書グループ編集でインターネット上で共有したい辞書と、指定したURLの辞書サーバーを関連付けることによって、その辞書が共有可能です。例えば、あるユーザーが
abc という単語を登録すると、そのサーバーを利用しているほかのPDICユーザーの辞書に自動的にその単語が登録されます。単語単位の衝突検知も可能ですので、編集中の単語がほかの人によって変更された場合でも、それを検知して更新内容の確認を行うことができます。
常時接続のネットワーク環境でなくても、非接続時に登録した内容をネットワーク接続時にまとめてサーバーへ送ることも可能です。
認証機能があるため、不正ユーザーによる登録・削除・閲覧を防ぐこともできます。
アクセス権限も詳細に設定できるため、信頼できるユーザーと一般ユーザーそれぞれが利用できる更新作業を制限することが可能です。(サーバー側の実装による)
このHPおよびML,掲示板では、今までPDICを使ってこられた方を対象に、開発途上であるこの機能の改善・要望や、辞書サーバーを実際に立ち上げて利用してみたい人達のサポート、情報交換を行っていきます。
この辞書サーバーは大量のデータのダウンロードには向いていないと思います。数千語くらいの単語が溜まったら、別ファイルにまとめてダウンロードできるようにしたほうがいいと思います。
※このページにあるものは開発を目的としたものです。
※こちらに正式運用中のものがあります。
こちらのページのUnicode版をダウンロードしてください。
通信プロトコルおよびサーバーの仕様はこちら。
上記Unicode版にあります。
注意:
・共有できる情報は、見出語、訳語、用例、発音記号、単語レベルです。
・読取専用の辞書はインターネット共有辞書にはできません。
・辞書の内容を一括してサーバーに送る機能はありません。一度1行テキスト形式などのテキストファイルに変換し、サーバーに直接アップロードして登録してください。これはサーバーの管理者が行うものですので、PDICには搭載していません。(サーバー側の対応が必要)
・共有辞書ファイルと同じところに、拡張子が.nd
というファイルが作成されます。このファイルには様々な設定情報が保存されるので、削除しないでください。誤って削除した場合は再度設定を行う必要があります。
・共有辞書ファイルの置き場所(フォルダー)を変更した場合は、拡張子が
.nd のファイルも一緒にコピーしてください。
テスト用サーバー
※旧サーバー、機能アップしたものは試作版のダウンロードページにあります
テスト用のサーバーを設けてあります。登録はご自由に。
URL | https://pdic.sakura.ne.jp/cgi-bin/inetdic/inetdic.xml |
User ID | guest |
Password | guest |
Tools - ネット共有辞書の状態 を選択すると、現在の辞書共有状況がわかります。
パスワードが間違っているなど、ネットワークに関するエラーはすべてこのウィンドウに表示されます。
表示される情報は、
・共有している辞書ファイル名
・登録ができなかった単語の一覧
・LastID、サーバーURLの表示
・エラーメッセージなど
LastIDについて:
サーバー側のLastIDと自分のPCのLastIDを比較することによって、自分の辞書が最新の情報に更新されているかどうかの判断を行います。もし、自分のPCのLastIDが小さい場合は、サーバー上から最新の差分情報のみをダウンロードして、自分の辞書を最新にします。
テンポラリファイル:
共有辞書を設定すると、テンポラリファイルが作成されます。このファイルにはネットワークエラーなどにより登録できなかった単語を一時的に保存したり、サーバーのURLやユーザーIDの保存に利用されます。
ファイル名は、共有辞書ファイル名の拡張子を
.nd にしたものです。
このファイルの中身はPDIC辞書であり、この辞書の識別子を利用して、パスワードをregistryに保存しています。
したがって、誤ってこのテンポラリファイルを削除した場合は、LastID、URL、ユーザーID、パスワード、登録保留されている単語が失われることになります。保留された単語は元に戻せませんが、URL、ユーザーID、パスワードは再度設定しなおせば継続利用できます。
必要な知識として、Webサーバーの設定が可能であることが前提です。もし、Linuxを利用しているのであればサンプルのサーバープログラムをそのまま利用できますが、WindowsのIISなどを使用する場合は、スクリプトを多少変更しないと動作しないと思うので、なんらかのスクリプトを作成する知識・技術が必要です。
PDIC Dictionary Serverのコアの部分は、200〜300行もあれば動作するくらい簡単です(言語によりますが)。それ以外のユーザー管理などの機能を追加して本格的なサーバーにする場合でも、数千行もあればかなり立派なものになるでしょう。
※逆にクライアント側はダウンロード機能だけであれば容易ですが、フル実装となると複雑になります。
サンプルのサーバープログラムはこちらにあります。
inetdic.tar.gz
scriptは Perl用に書かれています。Linux上で作成しました。
詳細は付属のreadme.txtをご覧ください。
※注意:このサンプルプログラムは複数のセッションに対応していません(同一ユーザーによる複数の共有辞書利用)。不具合は発生しないと思いますが、本格的に運用する場合は適切ではありません。
※注意:2005.7.30時点の仕様を元に作ってあるので、その後に追加された機能が入っていません。
もしご自分で独自のサーバーを作られたときのために、テストツールおよびそのソースコードを用意してあります。
inetdictest.LZH
PDICで動作テストをする場合に比べ、ログメッセージが出ますのでデバッグに役立つと思います。
自動チェックプログラムも含まれていますので、それでOKが出ることを必ず確認してください。
(このチェックプログラムでパスできても動作を保証するわけではありません)
このチェックプログラムは2005.7.30時点での仕様を元にして作ってあるため、その後に追加された項目についてはテストされません。
詳細は付属のreadme.txtをご覧ください。
サーバーの検索のためのリストへの追加
一般に公開したのはいいけど、それを多くのユーザーに知らせるには簡単なことではありません。
そこでPDICには辞書サーバーを検索する機能があります。
詳細な仕様は、PDIC用辞書サーバーのサーバーの検索にあります。ご自分のサーバーを誰からも参照できるようにしたい場合は、PDIC作者または、サーバーリストを管理している管理者へご連絡ください。
サーバーリストの例はこちらにあります。(これは実際に使用されているサーバーリストのファイルです)
一般公開向けにする場合の注意事項
セキュリティに対する考慮
・無意味なデータの登録、宣伝目的のデータの登録、データの改ざん、不正なデータ(著作権侵害など)
→信頼できるユーザーのみを参加させる、ユーザー登録の仕組みが必要。不正なユーザーは直ちにロックアウトできる仕組み・監視協力体制
・PDICの代わりに独自に作った悪意のあるプログラムによるデータ登録
- 予測外のデータを送ることによるサービスの停止
→サーバー側のセキュリティホールを無くすことはもちろん、あらかじめ予測できる攻撃に対する次善の防衛策をする
→例:通常ありえないデータが送られてきた場合は、そのIPアドレスに対する使用をしばらく(例えば1分間)停止させるなど
ログを取っておくことも重要(日時、IPアドレス、コマンド、エラー内容などの記録)
PDIC用の辞書サーバーが完成した後の話ですが、予定する内容を記しておきます。
PDICはマルチ辞書に対応しているので、その中の辞書をWWL共有に指定することにより、普段のPDICを使う感覚で世界中あるいは目的を同じする人達と辞書をシームレスで共有できることを目標とします。
WWLがUnicodeを使用していることから、Unicode版のPDICでのみサポートする予定です。
シナリオ1:単語の登録
「この単語の意味がわからない・・・PDICで調べてみよう」
「載っていた」
「でも意味が違う」
「どうやらWWLに登録されている辞書にまだ登録されていないようだ」
「それじゃ、自らこの意味を登録しておこう」
・・・
シナリオ2:辞書に無い単語
A:「この単語の意味がわからない・・・PDICで調べても載っていない」
A:「とりあえずserverに登録!」
・・・そのserverを使用しているユーザーのPDIC
WWL windowに不明単語リストへ表示される
B:「この単語知っているぞ、訳語を登録してあげよう」
・・・不明単語を入力したユーザーが再度その単語を検索したら・・登録されていた(または、不明単語が入力されたという通知を受ける)
A:「なるほどそういう意味だったのか。登録してくれた人ありがとう!(と心の中で感謝)」
シナリオ3:ボランティア活動
「ほっと一息、PDIC WWL windowを見てみよう。不明単語はないかな・・・」
「あったあった、・・・ほとんど知らない単語ばかりだけど・・」
「あ、この単語なら自分の得意分野だ!早速登録してあげよう」
シナリオ4:新着単語の評価
PDIC WWL windowで新着単語リストを表示・・・
まだ勉強を始めたばかりなので間違いはあると思います。ご注意を。
WWL はHTTP/SOAPを使用したプロトコル(通信規約)の一つで、辞書の翻訳・検索・作成に特化したものです。
まだ標準プロトコルではありませんが、いずれ標準化するようです。(RFC)
特徴としては次の点が挙げられます。
・本質的には server-client型の辞書検索
・複数のサーバーを介して検索することができる
・serverにユーザーが単語を登録できる
・登録された単語は参加しているユーザーが点数をつけることにより、訳語の信頼度を評価できる
・辞書の指定ができる(english → japaneseのように翻訳前の言語と翻訳後の言語を指定する)
・文字コードはUTF-8(Unicode)を使用
・未知の単語を取得することができる
・serverはnetwork上に複数存在し、それらのserverを自動的に探すことができる(必要なserviceに応じて)
ただし、上記の機能はすべてのserverで提供されるとは限りません。単純な辞書検索serverとして提供される場合もあります。
WWL Ver.2に準拠(SOAPは使わない)
HTTPおよびHTTPSのサポート
HTTP Proxyのサポート
サーバー上の辞書への自動登録・削除・修正、自動取得
(サーバー上の辞書の直接検索はPDICではサポートしない
- Webブラウザーを使用)
サーバー認証 - BASIC認証およびCGIによる認証(PDIC独自はなるべく作らない)
データはUTF-8
ポップアップ検索ではWWLの翻訳機能を使用し、ローカルにある辞書以外の結果も得られるようにする。応答速度が遅い可能性もあるので当初は実験のみ。その翻訳機能でそれ以外の機能的な可能性も考えてみる。
WWLFindServers
WWLMethods
WWLSearchText
WWLTranslate, WWLTransliterate - ポップアップ検索で使用
WWLCount
WWLIsoCode
wwlRecord
※WWLと同じprotocolを使用しますが、WWLの規格ではないため、prefixを小文字で示します。
見出語
発音記号(拡張)
レベル(拡張)
訳語
用例
ID(見出語の識別に使用する)
更新方法
更新日
更新ユーザーID
見出語
発音記号
レベル
訳語
用例
URL
Launguage Domain (ISO-639-2)
wwlRecord
word - 見出語
pron - 発音記号
level - レベル
trans - 訳語
exp - 用例
O'Reilly Network : Building a Worldwide Lexicon - WWLについて実例を挙げて易しく説明してあります。
http://picto.weblogger.com/stories/storyReader$156より
World Wide Lexicon Protocol は、簡単なHTTP/CGIインターフェースの上に作られています。クライアントアプリケーションは次に示すような標準的なCGIクエリー(GET
or POSTメソッド)でサーバーに問い合わせます。
http://www.foo.org/wwlfindservers.asp?source_language=en&;target_language=es&servertype=mt
サーバーアプリケーションやスクリプトは、自由なフォーマットで記述されたXMLドキュメントとして応答します。XMLコードはHTMLドキュメントの中に埋め込むこともでき、機械にも人間にも理解できる表現方法でサーバーは応答を返すことができます。
Worldwide Lexicon Protocol は、そのプロトコルの単純さから、容易に実装することができます。次の事柄は特に断り無しで適用するものとします。
・WWLの仕様では、エンドポイント同士の通信にHTTP(ポート番号80)をデフォルトトランスポートのプロトコルとして使用します。HTTPSもセキュアな通信のために使用することは可能ですが、必須ではありません。
・テキスト情報は、UTF-8またはUnicodeエンコーディングで送るものとします。すべてのクライアントおよびサーバーアプリケーションは、国際文字符号セットを扱えるものとして設計する必要があります。特に、誤動作を引き起こすような8bitエンコーディングを前提としたコーディングは避けなければなりません。常にこの拡張された書式にアプリケーションが対応するように注意する必要があります。また、クライアントアプリケーションはCGI
GETメソッドでWWLサーバーにリクエストを発行するときは、正しい書式の
URL になるよう注意してください。
・GETおよびPOSTメソッドをサーバーアプリケーションは扱える必要があります。
・Jabber instant messaging は、ボランティアによるフィードバックにおいて、リアルタイムリクエストの転送のために使用します。
WWLPで実装されている関数(function)は、次の基本的なカテゴリーからなります。
Discovery and Network Monitoring functions
Query functions
Utility functions
client signaling (distributed human computing)
functions
それぞれの関数は、一つのWWLサーバーにそれぞれ独立したスクリプトとして実装します。(例えばwwlfindservers.asp
は稼動しているWWLサーバーを探すためのリクエストを扱う、wwlregister.asp
はWWLサーバーからの登録リクエストを扱う、といったように)
クライアントアプリケーションは、{baseurl}/{functionname}.{scriptsuffix}
という書式を使って必要とするスクリプトのためのターゲットURLを作成します。この命名方法により、WWLサーバーの所有者はサーバー側のアプリケーションで使用する言語をどれにするのか決めることになります。スクリプトとして、ASP,
PHP, Perl, またはコンパイル言語が考えられます。
始めるにあたり、WWLサーバーはwwlregisterメソッドを使って一つまたはそれ以上のスーパーノードとして登録する必要があります。これによりそれぞれのサーバーが検索要求に用いる次に述べる情報を発行することが可能になります。
server location, IP address
language domains hosted on the server
types of language services provided (例えば、辞書なのか、機械翻訳なのか、リアルタイムな人間翻訳なのか・・・)
base url and url suffix for CGI scripts (クライアントアプリケーションにサーバーへ要求を出す際の適当な書式を教える)
other optional information as needed
WWLサーバーは通常、次のような要求を (1つの)WWL
supernode に発行することにより実行します。
http://www.wwl.net/wwlregister.asp (POST/form submitによる長いパラメーターを伴う)
NOTE:
WWL supernode(実は通常WWL serverである)は、wwlmethod応答で
wwlmethods.htmlページに対する要求を答えられるように設定しなければならない。これによりクライアントアプリケーションは
supernode上のCGI scriptをどんなふうに扱えばいいのか自動的に見つけることができ、supernodeの管理者が選択したスクリプト言語で、これらの必要な関数を実装することができるようになります。例えば、clientが
http://www.wwl.net/wwlmethods.html をロードすると、応答するXMLドキュメントにその
methodは supernodeがサポートしていると返し、どうすればCGI要求に答えることができるのか知ることができる。
WWLFindServers [v2.0] - この関数はクライアントが 言語領域やIPアドレス範囲に基づいたWWLサーバーのリストを問い合わせるために使用します。WWL
clientを自動的に見つけるために使用します(?)。この関数は、一つのXMLオブジェクトを使って、ユーザーの検索基準にマッチしたサーバーのリストを返します。
[send:client] [recv: server, supernode]
WWLMethods [v2.0] - this function allows
a client to interrogate a WWL server to discover
what version it is running, and what WWLP
methods are implemented. [send:all] [recv:
server, supernode]
WWLRegister [v2.0] - this function is used
to register a WWL server with a supernode
upon initialization. The WWL server uses
this method to identify itself, to list the
language domains it serves, and to declare
which services it provides. [send: server]
[recv: server, supernode]
WWLServerStatus [v2.0]- this function is
used to transmit server status information
to peer servers and supernodes (e.g. starting
up, shutting down, busy, etc). [send: server,
supernode] [recv: server, supernode]
開発日記
現在、test server作成中。
serverはperlで記述。問題はclient。MSXMLを使おうとしたが、C++Builderではcompileできず。(MSの陰謀)
VC++でSAXを使ってDLL moduleとして利用しようとしたが、いまさら(貧弱な)MFCを覚えてもしょうがない。。。と思ったら面白いものを見つけた。(しかも日本語だ)
C++BuilderでXMLパーサー Xerces-C++ を使う - しかし情報が古い。2000年
このままXerces-C++に流れると思いきや、このページに載っていたVC++プロジェクト変換を見て、これを使えばVC++で作ったMSXMLを使用したDLLが動くかも?と違うほうへと走ってしまった。(^^;;
しかし、結果は最初に作ったときと異なるところでcompile
error。
__uuidof(SAXXMLReader) でGUIDが関連付けられていないだとか・・・
@nifty |