青空文庫の公開ページは、データベースによって更新されています。
そのデータベースからの、一般に向けた情報提供について、検討します。
情報提供の現状
総合インデックス>作家別>全てを表示の「ア」の上にある、「→「公開中 作家別作品一覧:全て(CSV形式、 zip圧縮)」をダウンロード」から、公開作品のリストを取得できる。(リンクしているので、ここからも引き落とせる。)
ただし、作家別という仕立ての性格から、著者と翻訳者がたっている作品は、このリストの二箇所に表示される。
リストで提供されるデータ項目が、これで良いのかにも、検討が必要だろう。
作品ファイルのURLが盛り込まれていない点については、かねてから、改善を求める声がある。
今後のあり方
現行の list_person_all.csv の拡充計画に対して、twitterや掲示板で、以下のようなコメントがついた
変更、拡張に際しては互換性重視を希望。
csvは現状でも1.9MBと巨大。現行の list_person_all.csv にURLを追加する場合は、冗長部分をカットするべきかと。
青空文庫書誌CSV増補なら、現行版とは切り分けて別提供が一番。それが無理なら既存ファイルの項目末尾に追加。ただ、現在のCSVでも、スマートフォンのアプリで利用するには巨大すぎる。
現行の list_person_all.csv を修正するより、新たな「作品一覧」を出力していただいたほうが、こちらとしてはありがたい。
人物の役割フラグ(著者、翻訳者、校定者、編者、その他)の出力を希望。
まとめると、
list_person_all.csvの名称で提供している作家別作品一覧は、そのままで維持。(すでに利用の仕組みを作っているが、手直しなしに使い続けられるように。)
追加するものには、作品名、作品名読み、ソート用読み、副題、副題読み、原題、仮名遣い種別、初出、著作権フラグ、作品の公開日、ファイルの種類、ファイルのURL、ファイルの最終更新日(ファイルの登録日は入れても使い道がなさそう。)、人物名、人物名読み、人物名ソート用読み、人物の役割フラグ、分類番号(現在は利用していないが、将来に備えて。)等の記載を検討。
将来のUTF-8(?)での提供に備えて、ファイルのエンコーディングも出力しておくべきか。
その他、data_item.csvに記載している項目で、載せた方が良いものはないか。
追加提供するCSVは、list_person_all.csv同様に、作家別とするのか。
それとも、作品別とするのか。
設けられているデータ項目
データベースに用意されている項目を、data_item.csvにまとめた。
右のNavigatorでFilesを選ぶとみえるので、クリックで。
青空文庫API(アルファ版)
もたもたしている間に、できちゃいました。
http://d.hatena.ne.jp/plasticscafe/20100921/1285023847
ざっと拝見して、「作品情報」に、ファイルが更新されたことの目印として使える「最終更新日」を望む人がいるのではないかと感じました。
「公開日」も、「作品情報」にあればあったでよいかもしれませんが、これはどこにも書いていないので、スクレイピングではとれません。データベースから出力する以外なし。
こうしたものが作られた以上、青空文庫としてはまず、拡充したCSVの提供にしぼって進めるということでしょうか。
なぜ書誌CSVの項目拡充か
青空文庫APIがあると良いという利用者からの声に対して以下の道が考えられます。
- 青空文庫自身がAPIを提供する
- 第三者がAPIを容易に作成できるようなお膳立てをする
- なにもしない
本来は1.がスジでしょうが、手が回らない現実があると思います。
現在は、第三者がAPIを提供するために、必要な情報を取得しようと思うと、誰にも得にならない無駄な手間をかけなければなりません。
具体的には、約1万ある図書カード一つ一つにWebアクセスして、スクレイピングし、自前のデータベースを構築するしかない。
これには、青空文庫のサーバ負荷もかかれば、ISPの通信量もかかれば、APIを作成する側でアドホックなスクレイピングをしなければならない手間もかかります。
(語弊があるかもしれませんが、岡崎図書館の事件 http://librahack.jp/ に似たところがあります。)
しかし、必要な情報がまとまった形で青空文庫から提供されていれば、このような無駄は省くことができます。
これには、以下のような選択肢が考えられます。
- 青空文庫データベースのダンプをdailyに提供する
- 書誌情報CSVの項目を増やしてdailyに更新する
1.は、ダンプ公開に問題さえなければ、外部でAPIを作成しようと思うときには一番自由度が高く、また提供自体も技術的には極めて簡単に実現できます。その反面、カジュアルな利用は難しいでしょう。
▼ここから富田
データ項目にはいくつか、公開しないほうがいいことが書かれています。それを避けてまとめられるのなら、ダンプ公開がいいと、私(富田)は、お話を聞いて思いました。
青空文庫の「中」はいつも、手薄でした。今後も同じでしょう。作品よりの人で構成される事情にも、変わりはないと思います。「中」は、集めて記録するところに集中して、データは世間に投げるのが、活用の近道と思います。
世話役作業を担っている呼びかけ人と点検グループに、話を向けてみます。データベースの開発者にも、問い合わせてみます。
▲ここまで
2.は、CSV形式であるため人間にも比較的容易に利用できるメリットがあります。その反面、一つのCSVで情報を提供する場合は、テーブルの正規化を崩さざるを得ず、今後の拡張性が難しくなるデメリットもあります。
▼ここから富田
たとえば私は、ダンプを前にしても手が出せないし、CSVの拡充もやった方がいいと思います。
1 list_person_all.csvの既存の列の後ろに、要素を追加するのか。(ファイルのURL、最終更新日など。それだけでも、ずいぶん肥大化するけれど。)
2 list_person_all.csvとは別に、補遺となるものを新設するか。新設の際は、データ項目は多めに盛り込んでかまわないか。やはり作家別にするのか。それとも作品別にするのか。
▲ここまで
▼ここから2SC1815J
現在list_person_all.csvを利用しているアプリケーションのことを考えると、list_person_all.csvとは別に新しいCSVを提供するのがベストだと思います(上記2の対応)。
もし何らかの事情で2つのCSVを提供することはできないということであれば、次善の策としてlist_person_all.csvの列の後ろに追加だと思います(上記1の対応)。
1の場合、既存のアプリケーションへのインパクトは、アプリの実装によってはゼロである場合もあるでしょうし(既存の項目以降の項目は無視する実装になっている場合)、ゼロでない場合もあると思います(既存の項目数と合わない場合エラーとする実装になっている場合)。(現在list_person_all.csvを利用している豊平文庫さんからのコメントでは、互換性重視を希望とのことでした。)
2のCSVを新設する場合を想定して、data_item.csvに記載されている項目で、追加が考えられるものを挙げてみました。
生成元テーブル名 | 項目名 | コメント |
---|
作品データ |
作品ID |
|
作品データ |
作品名 |
|
作品データ |
作品名読み |
|
作品データ |
ソート用読み |
|
作品データ |
副題 |
|
作品データ |
副題読み |
|
作品データ |
原題 |
|
作品データ |
仮名遣い種別 |
|
作品データ |
初出 |
|
作品データ |
著作権フラグ |
|
作品データ |
公開日 |
|
作品データ |
最終更新日 |
|
人物データ |
人物ID |
|
人物データ |
姓 |
|
人物データ |
名 |
|
人物データ |
姓読み |
|
人物データ |
名読み |
|
人物データ |
姓読みソート用 |
|
人物データ |
名読みソート用 |
|
人物データ |
姓ローマ字 |
|
人物データ |
名ローマ字 |
|
人物データ |
役割フラグ |
|
人物データ |
生年月日 |
|
人物データ |
没年月日 |
|
底本データ |
書籍名 |
|
底本データ |
出版社名 |
|
底本データ |
初版発行年 |
|
底本データ |
入力に使用した版 |
|
底本データ |
校正に使用した版 |
|
底本データ |
種別フラグ |
|
分類番号データ |
分類番号 |
|
工作員データ |
入力者 |
|
工作員データ |
校正者 |
|
ファイル |
ファイル形式 |
|
ファイル |
ファイルURL |
|
ファイル |
最終更新日 |
|
ファイル |
ファイルエンコーディング |
|
これらの項目で現在の図書カード相当のCSVになります。
ただし、もともと複数のテーブルで管理された情報を一つのテーブルにまとめて出力することにより、正規化が崩れてしまいます。
正規化の崩れとはなにか、このCSVが作品別である場合を考えてみます。
一作品に複数の人物(著者・翻訳者・校訂者等)が関わっている場合、上表の人物データの項目をCSVの1行の中で繰り返して持たなければなりません。
しかし、CSVとして項目数が一定しないのでは利用するプログラムの側で扱いにくいので、事前に「人物1」「人物2」……のように想定される最大人数分のカラムを用意しておくことになります。
この方式を採った場合、想定していた以上の人数が関与する作品が現れたときに破綻してしまいます。
同じ問題は、CSVが作家別であった場合でも、ファイルに関する項目で発生します。
事前に「テキストファイル」「XHTMLファイル」「PDFファイル」……と想定されるフォーマット分のカラムを用意しておくのは、先ほどと同じく拡張性に欠ける問題があります。
先ほどのリストは、いろいろ盛り込んだ場合の例ですが、逆に切りつめた場合の例を挙げてみました。
生成元テーブル名 | 項目名 | コメント |
---|
人物データ |
人物ID |
|
人物データ |
姓名 |
|
人物データ |
姓名読み |
|
人物データ |
役割フラグ |
|
作品データ |
作品ID |
|
作品データ |
作品名 |
|
作品データ |
作品名読み |
|
作品データ |
副題 |
|
作品データ |
副題読み |
|
作品データ |
仮名遣い種別 |
|
作品データ |
公開日 |
|
作品データ |
最終更新日 |
|
-
|
図書カードURL |
|
ファイル |
テキストファイルURL |
|
ファイル |
テキストファイル最終更新日 |
|
ファイル |
テキストファイルエンコーディング |
|
ファイル |
XHTMLファイルURL |
|
ファイル |
XHTMLファイル最終更新日 |
|
現在のlist_person_all.csvと同じように、一つの作品について関与した人物の数だけレコードが存在する作家別CSVを想定しています。
読みたい作品を検索する場合の主たる検索項目は、作者名・作品名・仮名遣い種別ではないかと考え、それらで検索してファイルに辿り着くために必要な項目等に絞っています。
(上記にない情報は、図書カードを閲覧してもらうことを想定。)
最終更新日は、情報を差分更新するために必要です。
第三者が最低限の検索機能を提供するAPIを作成する場合や、青空文庫アプリで目的の作品を検索する場合には、この程度の項目があれば十分だと思います。
ただ、上記の例では工作員データの記載がないので、入力された方・校正された方には気持ちよくないかもしれません(図書カードや本文の最後に記載があるとはいえ)。
ここで挙げた「いろいろ盛り込んだCSV」の場合、明らかにiPhone/iPad/Android等で利用するには巨大すぎます。第三者のサーバで一日一回取得して、API用のデータベースを更新するためのものになるでしょう。
「切りつめたCSV」の場合、これでも大きいかもしれませんが、スマートフォンのアプリ内で処理する向けになるでしょう。もちろん、検索項目が作者名・作品名・仮名遣い種別・最終更新日程度で良ければ、第三者によるAPI構築にも足るデータです。
作者の没年月日が提供されていれば、「今日が忌日の作家の作品をトップページに表示する」といった利用もできます。
初出の年が提供されていれば、青空文庫の作品を時代順に年表上 http://www.simile-widgets.org/timeline/ に並べて表示することもできます。
こうした、さまざまな楽しい(しかし現在の青空文庫では手が回っていない)切り口での青空文庫作品へのアプローチを可能にするには、CSVに項目全部盛りが良いでしょう。
その場合は、新設した一つのCSVで提供するのならば、先ほどの正規化の崩れの問題があります。
しかし、現在のlist_person_all.csvと同じような作家別CSVにすることでレコード内での人物データの繰り返しは回避し、ファイルデータについてはテキストとXHTMLの情報のみ提供することに割り切ってしまい、それ以外のフォーマットについては図書カードを見てくださいとしてしまうという考え方もあるかもしれません。
ここまでCSVの拡張(整理)を考えてきましたが、1つのCSVではなくて複数のCSVをZipで固めて提供することや、RSSで提供することなども考えられるかもしれません。
RSSで提供する場合は、OpenSearchの検索結果のような形で全作品のデータをまとめて提供するイメージです。この場合、上記の正規化云々の問題は生じません。
ダブリンコアを拡張して、作品名の読みは dcaozora:titleTranscription で返すなど、仕様を考えなければなりませんが。
▲ここまで
青空文庫側の作業量を最小に抑えるのであれば、データベースのダンプ提供。次に作業量が少ないのは書誌情報CSVの項目拡充だと思います(やると決まれば実作業には一日もかからないでしょう)。
より踏み込んで将来のことを考えると、実現したいAPIのアイデアを出し合い(例えばURLで検索リクエストを投げRSSで検索結果を得るOpenSearchに対応するなど)、そのために必要な項目で、現在の青空文庫データベースにない項目があった場合にどうするかという課題もあります。
▼ここから富田
この要素に関しては、私は皆さんの話を集約することも難しいので、どなたか、リードしていただけるとありがたいです。
現在のデータベースにない項目については、「補充すれば」と、素人の直感としては思います。
これについても、開発者に話してみます。
▲ここまで
青空文庫APIの参考になる事例:
・PORTA(国立国会図書館デジタルアーカイブポータル)のAPI
http://porta.ndl.go.jp/wiki/Wiki.jsp?page=%E5%A4%96%E9%83%A8%E6%8F%90%E4%BE%9B%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
・CiNiiのAPI
http://ci.nii.ac.jp/info/ja/if_opensearch.html
(この「なぜ書誌CSVの項目拡充か」セクションは2SC1815Jの私見であり、青空文庫の見解ではありません)
提供データの拡張方針
ここまでの検討を踏まえて、拡張の第一歩を、以下の通り提案する。(富田、2010年9月28日)
既存のlist_person_all.csvに加えて、同じく公開作品対象の作家別で、データ項目を拡張したCSVを新設する。
名称は、「公開中 作家別作品一覧:全て 拡張版(CSV形式、 zip圧縮)」、「list_person_all_extended」とする。
出力日を記載する。
データベースのダンプの提供は、先の検討課題とする。
記載項目と配列は、基本的には、2SC1815Jさんの提案(二つあるものの上)にそって、以下の変更を加える。
・「仮名遣い種別」の名称を、「文字遣い種別」に変更する。
・人物データの「没年月日」の後に、「著作権フラグ」を追加する。
・ファイルの、「最終更新日」の前に、「修正回数」を追加する。
・ファイル関連情報は、テキスト、HTML/XHTMLのみを出力する。
以下、確認事項。
・作品データの「作品集名読み」「作品集名」「作品について」「備考」「底本管理情報」「最終更新日」「更新者」は含めない。
・人物データの「email」「URL」「人物について」「備考」は含めない。
・工作員データの「工作員ID」「姓名読み」「e-mail」「URL」「備考」は含めない。
・底本データの「備考」は含めない。
・分類番号データの「分類名」「備考」は含めない。
・ファイル関連は、テキストとHTML/XHTMLのみを出力する。ファイルの「初登録日」「文字集合」「備考」は含めない。(なお、data_item.csvのファイルの項に、作品データと重複して「状態の開始日」を記載したのは、不適当でした。)
・関連サイトデータの各項目は、含めない。
・ファイル関連は、2SC1815Jさんの想定通り、CSVの最後に置く。将来、基本ファイルとして提供するものを増やした場合(ePubや、UTF-8版のテキスト、HTML/XHTMLなどがありうるか)は、最後に追加する。
▼ここから2SC1815J追記 2010/11/09
先日、青空文庫の底本をAmazonから探すサービスが公開されました。
底本の情報は、これまでの書誌CSVにも含まれていましたが、より多くの情報を含む書誌CSVが提供されれれば、よりさまざまなサービスが、図書カードURLに総アクセスして情報を集めたりすることなしに提供可能になるでしょう。
この機会に、改めて提供データ拡充の検討を再開できればと思います。
富田さんの挙げられた項目を追加して、以下の項目の作家別CSVはいかがでしょうか。
生成元テーブル名 | 項目名 | コメント |
---|
作品データ |
作品ID |
|
作品データ |
作品名 |
|
作品データ |
作品名読み |
|
作品データ |
ソート用読み |
|
作品データ |
副題 |
|
作品データ |
副題読み |
|
作品データ |
原題 |
|
作品データ |
文字遣い種別 |
|
作品データ |
初出 |
|
作品データ |
著作権フラグ |
|
作品データ |
公開日 |
|
作品データ |
最終更新日 |
|
人物データ |
人物ID |
|
人物データ |
姓 |
|
人物データ |
名 |
|
人物データ |
姓読み |
|
人物データ |
名読み |
|
人物データ |
姓読みソート用 |
|
人物データ |
名読みソート用 |
|
人物データ |
姓ローマ字 |
|
人物データ |
名ローマ字 |
|
人物データ |
役割フラグ |
|
人物データ |
生年月日 |
|
人物データ |
没年月日 |
|
人物データ |
著作権フラグ |
|
底本データ |
書籍名 |
|
底本データ |
出版社名 |
|
底本データ |
初版発行年 |
|
底本データ |
入力に使用した版 |
|
底本データ |
校正に使用した版 |
|
底本データ |
種別フラグ |
|
分類番号データ |
分類番号 |
|
工作員データ |
入力者 |
|
工作員データ |
校正者 |
|
ファイル |
テキストファイルURL |
|
ファイル |
テキストファイル最終更新日 |
|
ファイル |
テキストファイルエンコーディング |
|
ファイル |
テキストファイル修正回数 |
|
ファイル |
XHTMLファイルURL |
|
ファイル |
XHTMLファイル最終更新日 |
|
ファイル |
XHTMLファイルエンコーディング |
|
ファイル |
XHTMLファイル修正回数 |
|
ところで、図書カードにはファイルサイズの記載がありますが、data_item.csv を見るとファイルサイズの項目はありません。図書カード作成の際はどのようにしているのでしょうか。
↓ここから富田追記 2010年11月14日
ファイル登録時に、データベース側がファイルサイズをみて、自動的に書き込んでいます。
そうした仕様なので、登録フォームにはファイルサイズの項目はありません。
そのために、data_item.csvには書いていませんでした。
作品の文字数の指標が欲しいという話は、よくわかります。
ただ、ご指摘の要素を回避するには、手作業が必要になりそうで、そこが辛いところです。
↑ここで富田追記終わり。
長編/掌編を検索して読みたい、作品の長さを知りたいというニーズはあると思います。
図書カードにあるようにテキストを圧縮したZipファイルのサイズでも大体の目安にはなると思いますが、挿絵付き作品のZipファイルサイズではファイルサイズと作品の長さがかけ離れてしまいますし、圧縮率はテキストの内容によって変わってくるので、Zipファイルのサイズが分かっても、元のテキストファイルのサイ ズが正しく見積もれない問題があります。また、注記やルビが多い作品は、テキスト/XHTMLファイルのサイズが大きくてもページ数にすると少ないといったケースもあります。ルビや注記を取り払ったときに何文字になるといった情報があると良いのですが。
▲ここで追記終わり
▼ここから富田追記 2010年11月14日
提供データ拡充の検討を、再開しましょう。
決めて、一回出す。何ヶ月か出し続けて、その間に注文があれば、再検討ということでよいのでは。
▲ここで富田追記終わり。
▼ここから2SC1815J追記 2010年11月16日
賛成です。
現在のデータベースにない項目(ルビや注記を取り払ったときの文字数、底本のISBNなど)については、すぐに提供は難しいでしょうから、まずは現在提供可能な項目(上記の項目)で試験公開版として走り始めてみても良いと思います。
その際に、これは試験公開版であり項目は変更の可能性があること、追加項目の要望があれば検討に参加して欲しいことなどを明示すると良いのではないでしょうか。
青空文庫の注記記法は、すでに多くの利用システムがあり、改訂するのであればかなり慎重にならなければなりません。
しかし今回のCSVはまだ利用システムが一つも存在しない状態です。
完成品として利用するのではなく、一緒に作っていくものとして利用してもらえれば良いと思います。
また、Wikipediaがミラーリングやオフライン利用などのためにデータベースダンプを提供しているように、将来的には青空文庫でも全作品を圧縮して固めたものを提供してもらえると、第三者によるサービスや言語資源としての利用が広がると思います。
それは、今回の拡充書誌CSVと相補関係にあるものになるでしょう。
つまり、ある時点(年次とか月次とか)でのすべての登録作品が一つのファイルにまとめられた形でダウンロードでき、その全部入りファイルが作成されてから後に青空文庫に追加・更新された作品については、毎日提供される書誌CSVに記載された「テキスト/XHTMLファイル最終更新日」の情報を元に個別ダウンロードしてもらう。そうすることで、全作品をクローリングをすることなく、手元の作品群を最新の状態に保つことができます。
全部入りファイルは、書誌CSVの拡充よりも興味を持つ方が多いかもしれません。
そうした方々と更新頻度やサーバ負荷(ファイル容量と通信量)などについて検討することにして、まずは拡張CSVの提供から進めてはいかがでしょうか。
▲ここで2SC1815J追記終わり
▼実行に向けて富田追記 2010/11/21
次の形で、拡充版の提供を世話役に諮り、データベースの開発者に依頼しようと思います。
当初は暫定版とし、コメントを受けて仕様確定へと進めましょう。
世話役内の相談にも時間を要するし、データベース開発者が、いつ作業できそうかも、現時点ではわかりません。
そんなことなので、暫定版準備中のご意見も、お待ちします。(特に、これまで話に出ていなかった「文字集合」選択肢への、「Unicode」の追加について。)
・CSVファイル提示位置、名称
http://www.aozora.gr.jp/index_pages/person_all.html
の「→「公開中 作家別作品一覧:全て(CSV形式、 zip圧縮)」をダウンロード」の下。
「→「公開中 拡充版作家別作品一覧:全て(CSV形式、 zip圧縮)」として。
・公開の位置づけ
3ヶ月間を暫定運用期間とし、その間に寄せられた注文のうち、とるべきものはとって、仕様を固定する。
・提供データ項目
2SC1815Jさんによる、2010/11/09のリストに、以下の変更を加える。
「底本データ」の「種別フラグ」をトル:「底本」と「底本の親本」を分離。
生成元テーブル名に「底本の親本」を追加:項目名は「書籍名」「出版社名」「初版発行年」
ファイルデータ項目に「文字集合」を追加:ここがJIS X 0213であれば、JIS X 0208で包摂されているものを、表示段階で分離加工する必要はないが、0208であれば、分離加工することも考えられる、といった用途を想定して。
・データ項目に関する変更
この際、以下の変更を加える。
「仮名遣い種別」の名称を、「文字遣い種別」に変更する。
「文字遣い種別」の選択肢(「新字新仮名」「新字旧仮名」「旧字旧仮名」「その他」)に、「旧字新仮名」を追加する。)
「文字集合」の選択肢(「JIS X 0208」「JIS X 0213」)に、「Unicode」を追加する。←バージョンの違いには関わらず、単に「Unicode」としてはと思うが、良いか。)
▲ここで富田追記終わり
▼拡張CSV暫定版における項目の並び順 富田追記 2010/11/22
2SC1815Jさんの一覧をもとに、若干の変更を加えて、以下の項目名、配列順を想定してみました。
分類番号を、作品関連の項目が並んだところに移しました。
初出の出力順を、早めました。
行空きは、CSVには反映させません。
作品ID
作品名
作品名読み
ソート用読み
副題
副題読み
原題
初出 ← 出力順変更
分類番号 ← 出力順変更
文字遣い種別
作品著作権フラグ ← 項目名変更
公開日
最終更新日
人物ID
姓
名
姓読み
名読み
姓読みソート用
名読みソート用
姓ローマ字
名ローマ字
役割フラグ
生年月日
没年月日
人物著作権フラグ ← 項目名変更
底本名 ← 構成、項目名変更
底本出版社名 ← 構成、項目名変更
底本初版発行年 ← 構成、項目名変更
入力に使用した版
校正に使用した版
底本の親本名 ← 構成、項目名変更
底本の親本出版社名 ← 構成、項目名変更
底本の親本初版発行年 ← 構成、項目名変更
入力者
校正者
テキストファイルURL
テキストファイル最終更新日
テキストファイル符号化方式 ← 項目名変更(図書カードの表記にあわせて)
テキストファイル文字集合 ← 項目追加
テキストファイル修正回数
XHTMLファイルURL
XHTMLファイル最終更新日
XHTMLファイル符号化方式 ← 項目名変更(図書カードの表記にあわせて)
XHTMLファイル文字集合 ← 項目追加
XHTMLファイル修正回数
▲富田追記終わり
▼仕様検討に際してのメモ 富田 2010/11/22
・底本と底本の親本がそれぞれ複数あるケースへの対応
まれではあるが、複数の底本と底本の親本をもつ作品がある。(例えば、作品ID1704、みみずのたはことには底本が二つある。)最多でいくつになるのかは、確定できない。とりあえず、底本1、底本2、底本の親本1、底本の親本2を設け、その範囲で出力することで進める。(三つあれば、記載できないものがでる。)
※他の選択肢があれば、コメントをお願いします。
・初出の出力順
底本の親本の後においてはというコメントがあった。ただ、初出は作品の属性として決まるが、底本、底本の親本は決まらない。その点を考慮すれば、作品についての項目が並ぶ現在の位置で進めることも不適当ではないと考え、底本、底本の親本のそばに移すことは控える。
・テキスト版二つのケース
青空文庫開設当初は、ルビあり版からルビなし版を作っていた。その方針を変更し、ルビなしは作品にルビがない場合に限り、かつて両方作ったものについても、ファイル修正の機会に、ルビなしを削除するようにしてきた。だが、なお二つ関連づけたものが残っている可能性があるため、二つある場合はルビありを出力するよう、求める。
▲ここでメモ終わり
▼ここから2SC1815J追記 2010年11月22日
複数の底本と底本の親本をもつ作品ですが、該当する作品はどれくらいの数でしょうか。
元々複数のテーブルからなる現在のデータベースを一つのCSVで書き出すとした時点で、正規化の崩れが不可避に発生します。
上記に挙がっている項目でも、ファイルフォーマットごとの項目については、テキストファイルとXHTMLファイルの二つに絞ると折り合いを付けているものと思います。
もし、複数の底本を持つ作品が極めて少数なのであれば、底本1、底本2等とはせずに、上記の項目のまま(底本は一つだけ記載)にしてしまう手もあると思います。
ちなみに、「みみずのたはこと」 http://www.aozora.gr.jp/cards/000279/card1704.html については、現行のCSVでは
000279,"徳冨 健次郎",001704,"みみずのたはこと",新字新仮名,"","小林繁雄、奥村正明","小林繁雄",公開,2002-11-01,"みみずのたはこと(下)","岩波文庫、岩波書店","1996(平成8)年12月10日第25刷","2001(平成13)年11月7日第27刷"
000280,"徳冨 蘆花",001704,"みみずのたはこと",新字新仮名,"","小林繁雄、奥村正明","小林繁雄",公開,2002-11-01,"みみずのたはこと(下)","岩波文庫、岩波書店","1996(平成8)年12月10日第25刷","2001(平成13)年11月7日第27刷"
となっていて、底本は一つだけしか記載していませんね。
同様の正規化の崩れについては、入力者、校正者についても当てはまります。
入力者や校正者が複数というケースは存在し、また上限が何人であるとも決められません。
入力者や校正者が複数の場合、現行のCSVでは一つの項目のなかで「、」区切りで併記しています。
一つの項目のなかにそのような形式で複数の人物を記載するのがベストとは思いませんが(「藤岡弘、」のように名前に「、」が入っている人がいたら区切り目が分からないという問題もあります)、元々複数のテーブルからなる情報を一つのCSVで表現するという方式のなかでは、やむを得ないかなと思います。
書誌情報一覧をCSVではなくXML形式などで提供し、そうした問題をクリアすることも将来的にはあり得るのではないかと思いますが、現状でできることとしてCSVで出す以上は、ある程度の折り合いを付けることもやむを得ないのではないかと思いますがいかがでしょうか。
▲ここで2SC1815J追記終わり
▼ここから富田追記 2010年11月23日
複数の底本と底本の親本をもつ作品数は、把握できていません。
CSVで出す以上、どこかで割り振るしかないというのはおっしゃる通りで、底本、底本の親本、それぞれ1だけという選択もあって良いと思います。
暫定版は、1ではなく2で作ってはというのは、ぼんやり頭にある「複数のものはごく少数というわけではないよな」というイメージからの、直感です。
複数の入力者、校正者については、ご指摘の通り、既存のものの「、」で繋ぐ形の踏襲が良いと思います。
▲ここで富田追記終わり
▼作業状況に関する追記 富田 2010年11月27日
拡充CSVの暫定版は、12月末までの提供開始を目指して、準備を進めています。
現在は、仕様を渡して、データベースの開発者にみてもらっているところ。
データベースで直したい他の要素も、この際、一緒に片付けようということで、年末までのどこかに、作業予定を組み入れてもらうという話になりました。
▲ここで富田追記終わり
▼拡張版CSVの試作版 2010年12月31日
「拡張CSV暫定版における項目の並び順 富田追記 2010/11/22」にそって、ただし底本と底本の親本欄を、1、2の二つ用意したものを出力してみました。(list_person_all_extended.zip)
暫定版提供開始前の、アルファ版と位置づけてください。
・古いデータしか入っていない、テスト用の環境から出力したので、6541行分の古いデータしかありません。
・並び順は、人物の「姓読みソート用」>「名読みソート用」>作品名の「ソート用読み」で決まっています。(既存のlist_person_all.csvと変わりません。項目の並び順が違っているので、印象が異なると思いますが。)
・表計算ソフトで開くと、「生年月日」と「没年月日」で「-」と「.」がばらついて見えるかもしれません。エディターでみれば、「-」でそろっています。
・M列の「最終更新日」は、ファイルが差し替えられたタイミングに加え、書誌データが書き換えられた際にも、変わります。(個人的には、この項目は入らないかもしれないと思いました。)
▲富田追記終わり
Comments (0)
You don't have permission to comment on this page.