IPDTPのプロトコル決めないとな。

IPDTPのプロトコル決めないとな。

 ipd://ipd.jjj.co.jp/JP19960183497

つまり

 ipd://サーバ名/国・文献番号

国・文献番号はhttp://www.european-patent-office.org/espacenet/info/access.htmと同形式。

問題となるのはhttp://www.european-patent-office.org/espacenet/info/access.htm形式だと文献種別の指定が難しいのではないか？と思ってこれから検索してみる。

 Belgium BE 1964 1920
 Canada CA 1970 unique2
 Eurasian Patent Organisation EA 1996 No
 European Patent Organisation EP 1978 1978
 Japan JP 1973 1980
 Kenya KE 1975 No
 United States of America US 1968 1920
 WIPO WO 1978 From beginning

ってな感じでコード化されているな。

◇種別は統一化されていない模様。

A A2 A3 B となっている。
日本との整合性は取れない。

どうしようかな？

文献種別はコンテンツ自身を一義的に指し示すものだから国・文献番号と同一レベルにしたいのが本当なのだが、日本のものとEPOのものがずれているのも使い勝手が悪いといえばわるい。

あと、段落番号・図面等を指し示すために

 ipd://サーバ名/国・文献番号#段落番号
 ipd://サーバ名/国・文献番号?f=図面番号

と、一義的に指せるようにすると便利だろう。
プログラムを書くにしても相当便利そうだ。
（ほんとのこというと、?f=図面番号はあまり好きではない）

返値について
希望としてはXMLであろうと考えられる。
図面のときのXMLの返し方は今後の勉強であろうと考えられるが、まあ、XMLヘッダのついたgifファイルみたいなものだろうと思われる。
最悪HTML+gifであろう。
HTML中のimgタグによってipd://サーバ名/国・文献番号?f=図面番号 はロードされる。

まあ、こんな感じで策定しておいて

とりあえずの実装は

 http://kenshu/ipd.cgi#段落番号?d=国文献番号&c=文献種別&f=図面番号

の組み合わせで呼び出す。

 http://kenshu/ipd.cgi

が

 ipd://サーバ名/

に相当するってことね。

一瞬非○文献もipdで扱うことを考えたが、httpがあるため別にいいかと思ってしまった。
ひょっとしたら学会論文誌等でも使えるかもしれない。
文献種別は別レイヤーの考え方を持ったほうがいいかもしれない。

ってなとこかな。

あと、経過情報を問い合わせる質問式とかあるといいかも。

http://www.alib.jp/html/uri.html

 おす　いそがしくなかったら話さないか？
 kinugim: おう
 kinugim: いいぞ
 n9dn9d: 大丈夫なのか？
 kinugim: ん
 kinugim: うん
 n9dn9d: http://www.n9d.no-ip.com/kwiki2-release2/index.php?c=view&t=%A3%B2%A3%B0%A3%B0%A3%B2%C7%AF%A3%B9%B7%EE%A3%B2%A3%B8%C6%FC
 n9dn9d: これどう思った？
 kinugim: いいとおもうぞ。
 kinugim: http://kenshu/ipd.cgi#段落番号?d=国文献番号&c=文献種別&f=図面番号
 n9dn9d: 問題点なし？
 kinugim: ＸＭＬにするなら、図面番号とか要らないような気がする。
 kinugim: 「あと、経過情報を問い合わせる質問式とかあるといいかも。」
 n9dn9d: http://kenshu/ipd.cgi?f=図面番号
 n9dn9d: で図面がくると <img src="http://kenshu/ipd.cgi?f=...>が使えるかな？とおもったんだ。
 kinugim: 必要な情報を小分けに取り扱うのか、一まとめに取り扱うのかと言う話で、
 kinugim: Mのやり方は、小分けにしようという話なんだよな。
 n9dn9d: うん。
 n9dn9d: 一まとめだと不利なこともあるよな。
 n9dn9d: [[ipd:JP2002123456/fig1]]とかできるとうれしいかな？とおもった。
 kinugim: まーね。
 n9dn9d: △’メモをつけているときに図1に○○の記載が・・・ってかくよな。
 n9dn9d: 文献内の絶対座標を知るための指標が必要だなーって考えてた。
 kinugim: いや、ＵＲＩとしての仕様を考えるときに、単にＣＧＩとしての使いやすさとは別の考え方が必要かもしれないかと思ったのでな。
 n9dn9d: HTTPはデータが小分けになっているのだがXMLでは常にセットで考えるのか？
 kinugim: それはわからん。
 kinugim: HTTPで小分けになってるのは歴史的背景だろ。
 n9dn9d: とりあえず、XMLの本買って読んでたんだけどな（笑）
 n9dn9d: 歴史的背景ではあるとは思う。
 n9dn9d: でも、それなりにメリットがあったからかなー　と、考えてしまった。
 kinugim: http://www.iana.org/assignments/uri-schemes
 kinugim: 参考
 kinugim: ・・・にならんな（笑
 n9dn9d: だな。
 n9dn9d: （笑）
 n9dn9d: まあ、結局どこに重きを置くかってことになるんだろうな。
 n9dn9d: 今回のIPDLFSとか考えてみると CDROM◇タイプのHTML + GIFファイルｘ図面分　ってことになるんだろ？
 kinugim: さっきの経過情報とかは？
 n9dn9d: で kinug製作ルーチンは txt.cgi(HTML) + img.cgi(PNGx図面分)ってことで　似てるよな。
 n9dn9d: ああ、経過情報ってのは　任意のがんばんのデータをすべてほしいって時に問い合わせルールが必要かな？とおもったんだ。
 n9dn9d: > ICMPみたいなもん。
 n9dn9d: というより、DNSみたいなものかな？
 kinugim: ひとつの△番号に属する情報を小分けで考えると、書誌事項データとか、請求項とか、要約とかも、図面と同じように別々にポイントできるといいかもなぁ。
 n9dn9d: うん。それは考えてた。＞ポイント
 n9dn9d: で、kinugが最初に言ってたXML化って話を思い出してた。
 n9dn9d: 書誌事項データというのは　実は経過情報と重複することが多いので　この辺の整理をどうするか？なんて考えてた。
 kinugim: ipd:JP2002123456/* で全部とか（＾＾；
 n9dn9d: HTMLのまねをするなら　#がつかないなら全部かな？とおもったんだけどな。
 n9dn9d: ipd:JP2002123456/*　ってのは文献のポイントに対してマルチキャストできるようにするってこと？
 kinugim: マルチキャストって何だっけ？
 n9dn9d: マルチキャストというよりはマルチポイントか・・・
 n9dn9d: ipd:JP2002123456/1-10,15-20　で段落番号1-10 15-20ってことかな？
 kinugim: んー、そこまで行くと微妙だな。
 n9dn9d: だろー（笑
 kinugim: 段落の無い◇もあるし。
 kinugim: URI で△そのものを指したいのか、◇を指したいのか・・
 n9dn9d: でも、段落番号【０００２】〓【００２０】には　が記載されている　って拒絶理由書くよな。
 n9dn9d: URIで△そのものを指すことは　難しいんじゃないかな？
 n9dn9d: ◇種別がたくさんありすぎる
 n9dn9d: 任意のひとつの△すべてのデータがやってくるぞ？
 kinugim: http://www.faqs.org/rfcs/rfc2396.html
 kinugim: だな
 n9dn9d: URLとURNを足すとURIだよな？
 n9dn9d: 場所　L 名前 N　識別子 I
 kinugim: http://www.alib.jp/html/uri.html
 kinugim: どうなんだろうな。
 n9dn9d: まあいいか
 kinugim: なんとなく、そういう感じっぽいな。
 n9dn9d: おそらく、karoとkinugがちっこいプログラムを乱発するだろうから、それに対応しなくてはとかんがえた。
 n9dn9d: ○の５Fの◇かも　何度も訂正◇を出す羽目になるから
 kinugim: urn:isbn:4-7561-3321-5
 kinugim: こういう表現方法も良いな。
 n9dn9d: ほんとは、経過情報にすべての◇のリンクが入っていて　実際の◇をたどるってことかなーとおもった。
 n9dn9d: urnをのぞけば　isbnコードを書いてるだけだろ？
 kinugim: 一番きれいなのは、△ごとにリソースがまとめられてる状態なんだろうけどなぁ。
 kinugim: だな
 n9dn9d: kinugがそういうってことは何らかのメリットがあるんだろうけどいったいなんだ？
 kinugim: urn:isbn:4-7561-3321-5　こっちの話？
 n9dn9d: いや、リソースをまとめる。ってこと。
 kinugim: いや単に、データの管理が美しいかと思っただけなんだけど・・
 kinugim: ひとつの△番号で指定されるデータに、その◇とか、経過情報が含まれる。
 n9dn9d: 図面を含め、すべてが単一のXMLに入れば美しいとは思うけど　所詮図面は分離するし、　◇種別も時間的に分断されて発行される。
 kinugim: 経過情報ってのは、◇に関するものじゃなくて△に関するものだからな。
 n9dn9d: たしかに、スナップショットとして全部一つの情報に入ってるってのは美しいな。　キャッシュもしやすいだろうし。
 kinugim: XML データにバイナリ含めること出来なかったっけ。
 n9dn9d: せっかく計算機だからそこまでしろってこと？
 n9dn9d: まだそこまで読んでない>XML
 kinugim: PCDATA とかいうやつ。
 n9dn9d: なるほど、それで保存することには異議はないが、単一だとクライアント側の実装が大変じゃないかな？
 n9dn9d: cocoonみたいに　保持＝XML　出力=HTMLってのが現時点でのテクノロジーでベストのような気が・・・
 kinugim: まーでも、△番号でも◇番号でもリソースを示せると言う仕組みにしても良いかもな
 n9dn9d: aliasってこと？
 kinugim: まーそんな感じ
 n9dn9d: △番号#B　だと　◇がでるってことかな？
 kinugim: でもって、「◇番号」とかいても、◇が出ると。
 9dn9d: なるほど。現時点でのデータベースだとちょっと辛そうだけどな。
 n9dn9d: （笑）
 n9dn9d: 外国は△番号＝◇番号だからなー
 n9dn9d: おそらく、◇課がぐれたんだろうな・・・番号調整死にそうだと思うし。（笑）
 n9dn9d: まあ、○になったときの○番号もあるからな。
 n9dn9d: 3種のエイリアスがあるわけだな。
 n9dn9d: 審判番号まであったりするな。
 kinugim: だな。
 n9dn9d: まあ、alias機能の実装はさておきそれを包含できる企画にしておいたほうがいいよな？
 kinugim: 単に、ＣＧＩで◇を取得する仕組みを作ろうというのでなく、ＵＲＩを定義しようと言うからには、それなりの深みが有っていいかなとは思う。
 n9dn9d: そうだな。
 kinugim: 丸あたりがこの辺の話に詳しいかな。
 n9dn9d: たしかに、URIを利用するとリソースが一義的に指定できるってことだもんな。一種のデータベース検索と同じなのか。
 kinugim: んー
 kinugim: まー、普通に「識別子」と思えば良いと思うんだけど。
 kinugim: 何を識別したいのかをはっきりさせとかないとな。
 n9dn9d: なんかアイデアある？
 kinugim: ◇、経過情報、書誌事項
 kinugim: 他に何かあるかな。
 kinugim: 書誌事項は◇に含まれてはいるんだな。
 n9dn9d: 書誌事項って常に変化する要素も含んでいるだろ？
 n9dn9d: そこが不安でな。
 n9dn9d: せっかくだからデータベースのミラーリングで全部済まそうとしてるesp@cenetとは違った形にしたいもんな。
 kinugim: ちょっと思ったんだけど、
 kinugim: ◇は、一般に見せたい情報と言うことで良いと思う。
 kinugim: 経過情報とか、書誌事項は、ＵＲＩなりＵＲＮみたいので識別する必要がないかも。
 kinugim: isbn があるんだから、○◇にも、ＵＲＮをつけてもいいかなと。
 n9dn9d: なるほど。
 kinugim: 経過情報とかは、自発的に欲しいと思った人が取得できればいい情報であって、ＵＲＮが定義されれば、何かの自動化には便利かもしれないけど、かえって混乱を招く要因にならないかと思ってな。
 kinugim: みんなが知ってるＵＲＮ表記なら良いけど、知るひとぞ知るＵＲＮ表記みたいなことになるとねぇ。
 n9dn9d: 実装面でもかなりの労力を必要としそうだ品。
 n9dn9d: ということは、 ipd:サーバ名/国　◇番号　文献種別　ってことでいいってことだな？
 kinugim: だな
 n9dn9d: 経過情報検索には別のURIを提供すればいいんだろうな。
 kinugim: ＵＲＬ表記ってことだな。
 n9dn9d: というか、データベース引けってことだな。
 kinugim: そうそう＞ＤＢ引け
 kinugim: フジテレビ
 kinugim: えいチャンのそっくりさん。
 kinugim: ・・・終わった。
 n9dn9d: はやくいえよー
 n9dn9d: いきなり江ノ島で気まずかった。（笑）
 kinugim: はは
 kinugim: そのあとのは面白かったけどな。
 kinugim: ・・・一人で見てる場合。
 n9dn9d: もー（笑）
 n9dn9d: んじゃ、あとはまとめるかどうかの話だな？
 kinugim: だな。
 kinugim: ＵＲＩの記法には特に細かいルールはないっぽいし。
 n9dn9d: なにせ　Uniform Resource Identifer (URI) SCHEMES 　だもんあ。
 n9dn9d: 両方実装できる方法考えてみるか。
 n9dn9d: 双方メリットありそうだしな。
 kinugim: たぶんな。
 n9dn9d: ん？単に　ipd:---- にオプションも受ければいいだけか。
 n9dn9d: 返値がばらばらとひとつになっているのが選択できればいいだけだもんな。
 kinugim: だな
 n9dn9d: つまり HTML+GIFx画面数　と XMLのどちらかで受けることを明示的に指定すればいいと
 kinugim: ＵＲＮでは、まとめてひとつの◇を指す表記を考えて、ＵＲＬで個別に指定する表記を提供するとか。
 n9dn9d: おお。いいかも
 n9dn9d: URN表記だとどうなるんだ？
 kinugim: だな。
 kinugim: 単に　urn:ipd:◇番号 みたいな漢字かなぁ
 kinugim: 感じ
 n9dn9d: おし、とりあえず、そうしよう。
 n9dn9d: 実装方法は　urnipd.cgi でいいわけだな？
 kinugim: urn の方はとりあえず実装しなくていいかも。
 kinugim: たとえば、ブラウザの入力欄に urn:ipd:◇番号 見たいのが入力されたら、プラグインが適当に近場のサーバにアクセスしてくれると。
 n9dn9d: やっぱり、それ考えてた？＞プラグイン
 kinugim: この前そういう話してたろ。
 n9dn9d: だな。
 n9dn9d: XMLなら新しいブラウザでいけば プラグインなしでいけそうだけどな。
 kinugim: 表示はね。
 kinugim: 問題は、urn にはサーバ名は含まれてないところ。
 n9dn9d: あそっか、ブラウザでurnの解決ってどうやるんだろうな？
 kinugim: 一瞬調べようかと思ったんだけど、
 kinugim: ブラウザによって違うしな。
 n9dn9d: んー、背景にはDNS並みのDBが必要そうだなー
 kinugim: 実際には裏で、URLに変換するだけで良いんじゃないかとは思う。
 kinugim: 多分、今の◇番号が実質ＵＲＮの役割をしてるんだろうな。
 n9dn9d: たしかに。＞URN
 kinugim: でも、今の◇番号は、Unify されてないから、そこを何とかする感じで。
 n9dn9d: 単一化はされてるだろ？
 kinugim: あそっか（笑
 kinugim: Uniform だな。
 n9dn9d: Uniformってどういうこと？
 n9dn9d: （すまんな英語は苦手なので・・・）
 kinugim: 定型化みたいな意味があるんじゃないかと思うけどな。
 kinugim: http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi?MT=uniform&sw=0
 n9dn9d: 文献自身というリソースと一意的に文献番号は結びついてるよな？
 kinugim: うん
 n9dn9d: そういう意味で言ったら　espa@cenetの文献番号はまさにURNであるといえるな。
 kinugim: 日本の◇番号も一意になってるけど、表記が統一化されてないんじゃないの？
 n9dn9d: 日本だけが統一化されていないのではないかと思われる。
 n9dn9d: アメリカ＝○になったやつのみ◇、ヨーロッパ＝△番号＝◇番号
 n9dn9d: △番号と◇番号が違うのは日本だけじゃないかな？
 kinugim: まー、ここではＲＦＣに定義されたフォーマットに沿わせるところに意味があるんじゃないかと思うから、とりあえずそこは考えなくて良いと思う。
 n9dn9d: ○番号と◇番号もちがうけど。
 n9dn9d: URL は URN の様に url: といった特別なスキームは持ちません。後方互換性のためとも考えられますが、http: とか ftp: といったスキームを持ちます。単純に URN を示す urn: 以外の URI スキームは URL スキームだと認識して構いません 
 n9dn9d: ってことで、終わらすって事？
 n9dn9d: それとも、　urn: ipd: JP2002123456 とあらわすってこと？
 kinugim: 両方あっていいかなと思ったんだけどな。
 n9dn9d: たしかにそれはいえる。
 kinugim: もし、他の国がそれにあわせてくれたりしたら、とっても幸せな状況が（笑
 n9dn9d: 単に　日本の△に対しては urn解決のコストが高いってことだな。
 n9dn9d: それは思いっきり意識してる>他の国があわせる
 kinugim: まね。
 n9dn9d: んじゃ、urn: ipd: JP2002123456Aって感じになるのね。
 n9dn9d: isbnコードと同じでいいんじゃないかな？
 kinugim: urn はサーバに依存しないから上手くいくと頼りになる表記法になるだろうな。
 n9dn9d: なるな。
 kinugim: うん＞isbn と同じ。
 n9dn9d: サーバがいずれにあろうが関係ないってことでアプリケーションおよび人間には理解しやすいコードだ
 kinugim: うん
 kinugim: 問題は、今の◇番号との違いを主張しにくい（笑
 n9dn9d: いいじゃん、べつに。
 n9dn9d: DNSwo
 n9dn9d: DNを
 n9dn9d: DNSを実装するときに　利用者およびアプリケーションは 名前空間だけを意識して　bindではipアドレスおよびそれを保持しているサーバを意識しまくっているんだから。
 n9dn9d: /etc/resolve.confみたいなファイルで　どのサーバに頼るか決定するんだろうな。
 n9dn9d: ブラウザで利用することを考えるとURL表記のほうが　利点は多い気もしないでもないな・・・
 kinugim: 思うんだけど、
 n9dn9d: ん？
 kinugim: １．urn でサーバによらない文献の指定法を提供する。
 kinugim: ２．http:// のurl で文献のアクセス方法を提供する。
 kinugim: で良いのかなと。
 n9dn9d: うん。
 kinugim: ipdtp プロトコルが完成したら（するのか？）、ipdtp://サーバ名/ホニャララ でもアクセスできると。
 n9dn9d: この辺の会議内容をSさんに見せてwebDAVと整合性を測ってもらうというのも手かな。
 kinugim: その辺は、知識のある人にいろいろ意見を聞いたほうがよさそう。
 n9dn9d: だな。
 n9dn9d: Sさんはマルチキャストがどうたらこうたらいってたような。
 n9dn9d: ipdtpプロトコルってすでに完成したも同じじゃないのか？
 n9dn9d: ipdtp:get 文献番号
 n9dn9d: 返値が文献のあるなしとか本体とか。
 n9dn9d: こんな適当じゃ気持ち悪い？（笑
 n9dn9d: httpとかsoapとか参考にすればいいんじゃないかな？
 kinugim: だな
 kinugim: まー、ipdtp はあとで良いよな。
 n9dn9d: あとでいいのか？
 n9dn9d: IPDLFSとCDROM◇のインターフェイス策定がいるんじゃないのか？
 inugim: だな
 kinugim: まー、ipdtp はあとで良いよな。
 n9dn9d: あとでいいのか？
 n9dn9d: IPDLFSとCDROM◇のインターフェイス策定がいるんじゃないのか？
 n9dn9d: それで、あせって考えてるんだけど。
 n9dn9d: おっ、△番号・◇番号・○番号のコンバートは簡単だ。　http://www1.iiii.jjj.co.jp/RS1/cgi-bin/RS1P001.cgi
 kinugim: む、サーバが込み合ってる（笑
 n9dn9d: そなの？
 n9dn9d: どこの？
 kinugim: http://www1.iiii.jjj.co.jp/RS1/cgi-bin/RS1P001.cgi
 n9dn9d: http://www1.iiii.jjj.co.jp/RS1/cgi-bin/RS1P001.cgi
 n9dn9d: おなじだな。
 n9dn9d: http://www1.iiii.jjj.co.jp/RS1/html/n_input.htm
 n9dn9d: これでどうだ？
 n9dn9d: これがトップだったんだな。
 n9dn9d: オートリダイレクトされてる。
 kinugim: なるほど。
 n9dn9d: ま、この辺使えば urnも実装可能ってことだな。
 kinugim: また、Javascript かー。
 kinugim: 原理的にはね（笑
 n9dn9d: しょうがねえな・・・まったく。
 kinugim: まったくだな。
 n9dn9d: ま、もちっとかんがえてみることにするわ。
 kinugim: おう