Giter Club home page Giter Club logo

animedb's People

Contributors

builtinnya avatar eru avatar haruyama avatar honeshabri avatar masayatoy avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

animedb's Issues

汎用IMEテキスト辞書形式の読みをカタカナでなくひらがなにして欲しい

Google日本語入力用の辞書データですが、読みをカタカナではなくひらがなにしていただけないでしょうか。
こうすることで、他のIMEでも利用できるようになり利用者が広がると思います。
汎用IMEテキスト辞書形式ではひらがな→漢字という変換データで用意するのが一般的だと私は思います。
ひらがなで記述する際、「ヴ」についてはカタカナのままで記録する(MS-IME)、「う」+「゛」で記録する(SKK/ATOK)など方言があるのですが、個人的には利用者が圧倒的に多いMS-IMEに合わせておくのがよいと考えます。(いまどきのIMEなら揺らぎがあってもちゃんと読めるはず)

MADB から加筆・修正した差分を明らかにする

背景

本 Anime DB は,README.md でも述べた通り,文化庁による メディア芸術データベースアニメーション分野のデータ (以下,単に MADB と表記する)を下敷きとして,最近のアニメの追加,主にタイトルやよみがななどの誤表記,表記ブレを修正したものである.

Anime DB を使って生成した Google IME の辞書を公開した(元記事辞書本体)ところ,それなりに大きな反響があった(はてなブックマークスラドねとらぼ など).
そのような状況の中,Twitter で「MADB のどのタイトル表記が間違っていたのか公開した方が良い」という意見(ツイート1ツイート2ツイート3)が寄せられた.

問題

  • MADB から加筆・修正した差分が明らかではない
  • MADB が Web ページ(HTML 形式)でしか公開されていないため,ユーザが差分を分析しづらい

予定している対応

  • 元々 Google IME 辞書がきっかけということ,分かりやすさ,差分が主にタイトル,よみがなであることから,MADB と Anime DB のタイトル,よみがなを併記した CSV ファイルを生成する(Excel などで閲覧可能)
  • こちらで取得した MADB のデータ(構造化された分析しやすい形式)を公開する

その他IME辞書として使ってみて気づいた点について

以下は仕様ということでも構わないと思っていますが気になった点についてご報告します。

  1. タイトルよりも長いふりがながついているものがある
    例:
    なつふくのしょうじょたちひろしましょうわにじゅうねんはちがつむいか 夏服の少女たち 固有名詞 TVスペシャル版 (1988/8/7)

  2. このタイトルが本当に存在しているのか不明 (OVA版とタイトルが微妙に違っておりWikipediaに載ってない)
    うるせいやつらでんきじかけのおにわばん うる星やつら 電気仕掛けのお庭番 固有名詞 劇場版 (1989)

  3. CSVファイルのコメント部分に「同じのがある」「同じのある」と書かれた重複エントリが存在する
    これらは機械的に抽出して確認した上で削除すべきかと思います

  4. ms-ime-dict.txtがシフトJISのためタイトルが文字化けして「?」になっているものがある
    BOMつきUTF-16LEかBOMつきUTF-8で収録したほうがよいのではないかと思います

以上です。たいへん便利な辞書をありがとうございました。

「識別名」でない識別子を作品に振る

背景

今のところ,Anime DB で扱っている情報は「タイトル」「よみがな」「放送開始日」といったアニメそのものの基本情報と,一部の各話情報(エピソード)のみである.
今後,スタッフやキャラクターといった情報を追加する場合,作品横断的な扱いが要求される(1対多ではなく多対多).その際,現在の「識別名」には変更可能性が存在するため,それを作品との関連付けに用いることは不適当である.
そのため,他のあらゆるデータベースと同様に,それ自体に意味がない識別子(e.g. 0000001abcdefg)を用いる必要がある.
喫緊の課題でなかったため先送りしていたが,そろそろ解決した方が良い.

主問題

  1. 多対多のような関連付けを行い易い識別子が作品に付けられていない
    • 「識別名」が全作品に対して一意であるため,今でも「識別名」を用いれば関連付けは可能だが,「識別名」は「タイトル」と「添え名」から構成されており,変更可能性が存在する

副問題

  1. 識別子として何を用いるか(識別子をどのように生成するか)
  2. 主問題1の識別子を導入した後,既存の「識別名」の扱いをどうするか

解決方法案

1. 識別子として何を用いるか(識別子をどのように生成するか)

前提として,現在・将来に渡って識別子に「一意である」以上の意味を持たせないようにする.つまり,ランダム文字列が望ましい.
その上で,作品に振る識別子の要件を,優先度が高いと思われる順に以下に挙げる.

  1. 識別子がすぐには枯渇しない
  2. 生成し易い
  3. 編集し易い(e.g. 一回のダブルクリックで識別子全体が選択される)
  4. 見易い
  5. 短い

以上の要件を良く満たす識別子の生成方法を以下に示す.

  1. UUID v4を生成する
  2. 生成した UUID を Base57 でエンコードする
  3. 生成した Base57 文字列の最初の 11 文字を識別子として使う(e.g. vytxeTZskVK

Base57 はデータを 57 種の文字でエンコードするため,57^11 = 20,635,899,893,042,801,193 サイズの空間を持つ.しかし,ランダムに生成する場合,Birthday problem と同様に,素朴な直感に反して生成数が非常に小さい段階で衝突確率が 50% 以上になる.
11 文字の場合,2つ以上の識別子が被る確率が 50% 以上になる生成数は,およそ 5,348,591,559 個である.

animedb コマンド以外にも,GitHub Pages などで識別子を生成できるようにする.

2. 主問題1の識別子を導入した後,既存の「識別名」の扱いをどうするか

「識別名」は元々,表示の際に同名の作品が現れないようにするために導入された.
今のところ,「識別名」自体を id として Anime DB に書いているが,代わりに識別子を id として記入することになる.
「識別名」は「タイトル」と「添え名」から容易に作れるので,それ単体で保存する必要はない.「識別名」という概念(つまり一意性の担保)だけ残しておく.

「AはB」の表記揺れについて

「でみちゃんはかたりたい」のような
「AはB」タイプの題名のふりがな情報が
「AわB」になっているものがいくつかあるようですのでご報告します。

ねんじゅうぎょうじあにめーしょんせつぶんふくわうちおにはそと 年中行事アニメーション 節分 福は内! 鬼は外! 固有名詞 劇場版 (1987/11/6)
きっちゅにあなぜあんぜんしんわわくずれたか キッチュニア-何故、安全神話は崩れたか? 固有名詞 OVA版 (2012/7)
しがつわきみのうそ 四月は君の嘘 固有名詞 TV版 (2014/10/8 - 2015/3/18) http://www.kimiuso.jp/
えぬえいちけーすぺしゃるあにめどきゅめんとあのひぼくらわせんじょうで NHKスペシャル アニメドキュメント あの日、僕らは戦場で 固有名詞 TVスペシャル版 (2015/8/10) http://www.nhk.or.jp/special/detail/2015/0811/
くりいむれもんぱーとつーえすかれーしょんこんやわはーどこあ くりいむレモン パート2 エスカレーション ~今夜はハードコア~ 固有名詞 OVA版 (1984/9/10)

`episodes` を `animedb.yml` から分離する

※ PR #45 がマージされてから取り組むこと

背景

ランダム文字列を識別子とする変更(issue #39,PR #45)に伴い,作品の基本情報以外のデータ(各話情報やスタッフ,キャラクターなど)を,識別子を用いて関連付けられるようになった(厳密にいえば変更前も識別名を用いて可能だったが,識別名には変更可能性が存在するため,難しかった).
各話情報は既に一部のアニメについて入力されている(refs: #6#10#43)が,その数は作品よりオーダーが大きい.そのため,見通しが悪くなったり,スクリプトでの処理時間が余計に長くなったりして,編集作業に支障をきたしている.

問題

  • 各話情報が膨大であり,編集作業の効率が低下している

解決方法案

スタッフやキャラクターなどのデータを将来的に追加することも見据えて,各話情報(episodes)を animedb.yml から分離する.つまり,各話情報は例えば episodes.yml ファイルに移される.
animedb.ymlanimes.yml にファイル名を変更した方が命名的に一貫しているが,変更するかどうかは考えどころ.

episodes.yml の構造は以下のようになる.各話情報にも作品と同様に id を用意する予定.

Z5bwa8ArLg5: # 作品の id
  - id: mR22RyrHEuU # 各話情報そのものの id
    prefix: 第1話
    title: チビッ子魔女がやってきた No.1
    literal_title: 第1話 チビッ子魔女がやってきた No.1
    annict_id: 78126
  - ...

`id`,`title`,`ruby` のミスマッチが起きている項目が存在する

ref: #19 (comment) by @haruyama

  • ANS000452200

    • id: ギャラクシーエンジェル(第3期) / title: ギャラクシーエンジェル / ruby: ギャラクシーエンジェルエース / ギャラクシーエンジェルダブルエース(変更前)
    • ruby は ギャラクシーエンジェルダブルエース としました. id や title も ギャラクシーエンジェルAA にするのが適当かもしれません
  • ANS000156600

  • ANS000806400

    • id: みなしごハッチ ママにだかれて / title: みなしごハッチ ママにだかれて / ruby: コンチュウモノガタリ ミナシゴハッチ ママニダカレテ
    • id, title, ruby で統一すべき?
  • ANS000604400

    • id: それいけ!アンパンマン おともだちシリーズ/ファンタジー / title: それいけ!アンパンマン おともだちシリーズ/ファンタジー/ ruby: ソレイケアンパンマン オトモダチシリーズ ファンタジー バタコサントソラトブマフラー
    • おいでよ!アンパンマン沼 バタコさんと空飛ぶマフラー アンパンまんの中の一話のようです. ruby にだけ バタコサントソラトブマフラー の情報があるので id, title に反映させたほうがいいかもしれません
  • ANS008051700

    • id: ガリレイドンナ / title: ガリレイドンナ / ruby: ガリレイドンナ Storia di tre sorelle a caccia di un mistero (変更前)
    • Storia 以下はタイトルに含めなくてよいのではないかと思い ruby も ガリレイドンナ のみにしています

識別名が重複しているものが存在する

以下の識別名をもつアニメ作品が2つ以上存在する。識別名は一意であるべき。

  • STRAIT JACKET ストレイト・ジャケット
  • 鉄人28号 ミラクル魔術団 海底基地
  • デジモンアドベンチャー
  • スパイラルゾーン
  • さすがの猿飛
  • 劇場版 空の境界 未来福音 extra chorus
  • しましまとらのしまじろう
  • 忍者ハットリくん+パーマン 忍者怪獣ジッポウVSミラクル卵
  • 鋼鉄天使くるみ
  • ゴールデンタイム
  • TRANSFORMERS THE MOVIE
  • それいけ!アンパンマン にんきものだいしゅうごう! キャラクターベスト15
  • 変ゼミ
  • カルルとふしぎな塔
  • ハヤテのごとく!!
  • 宇宙戦士バルディオス
  • 百花繚乱 サムライガールズ 〜乙女:hearts:嬉し恥ずかし将士の契り〜
  • 金田一少年の事件簿
  • エイトマン ロボット007 光線銃レーザー
  • 地球へ…
  • なりヒロwww
  • 【懺・】さよなら絶望先生 番外地

[提案] 日時の表記形式をISO 8601に準拠してはどうか

現在,animedbにおける日時は「YYYY/MM/DD HH:mm」という(本邦において一般的ではあるものの)明確な仕様・規格がない独自の形式を用いて表記されています。
これを国際規格及び日本産業規格に準拠した形式,具体的にはISO 8601-1:2019 “Date and time -- Representations for information interchange -- Part 1: Basic rules”及びJIS X 0301:2002『情報交換のためのデータ要素及び交換形式―日付及び時刻の表記』に変更することを提案します。

準拠すべき規格の内容

JIS X 0301:2002『情報交換のためのデータ要素及び交換形式―日付及び時刻の表記』5.4.2節「完全表記以外の表記」例a)の拡張形式に準拠することを提案します。

YYYY-MM-DDThh:mm
(具体例)2019-07-15T12:00

(参考)変更による利点・欠点

  • 利点

    • 機械処理がより容易になるでしょう。ISO 8601に準拠した表記形式ならば,自力で字句解析機などを作成せずとも,多くの言語が標準で提供している解析・変換の機構が利用できます。但し,残念ながらISO 8601の表記形式に完全に準拠したものは少ないと思われます。尤も,多くが部分的な対応に留まっているとは言え,上に挙げたYYYY-MM-DDThh:mm程度の形式ならばISO 8601(部分)対応を謳うほとんど全ての言語・ライブラリが処理できるでしょう。
    • 国際的に一意な表現による曖昧性の解消や文化の相違に因る誤解の減少が期待できます。現行のYYYY/MM/DDは例えば米国においては一般的とは言えないために,米国の利用者の目に不自然に映る可能性があります。国際規格に採用されている形式を用いれば,文化的な相違に依らない日時の解釈が実現できるでしょう。
  • 欠点
    過去互換性が喪失します。これは重大な問題でしょう。しかし独自形式とは言えYYYY/MM/DD HH:mmからYYYY-MM-DDThh:mmへの変換は斜線をハイフンマイナスに置換し欧文間隔をTに置換すればよいだけですから,ある程度少ない影響に抑えられるかも知れません……。

CSVファイルの誤記について

CSVファイルで、この行だけ題名がダブルクォートで囲まれており、処理系によっては題名の末尾のカンマ部分が正しく解釈できない可能性がありますのでご報告します

ANS000808400,劇場,,PzJjXWzLMU2,"科学忍者隊ガッチャマン 火の鳥対火喰い竜,",,カガクニンジャタイガッチャマン ヒノトリタイヒクイリュウ,1973,7,28,,,,東宝,-,,http://mediaarts-db.jp/an/anime_series/12795,,

Added hit numbers to animedb entries

はじめまして。
有用な辞書を公開してくださってありがとうございます。

Wikipedia本文内でgoogle-ime-dict.txtの表記を自動的に検索し、
ヒット数順に並べたものを作成しました。
ヒット数が0件のものは打ち間違いの可能性があるので、
校正の目安になると思います。
ただし全角半角の違いだったり「劇場版」の有無だけでも0件になるので、
0件でも多くのものは間違っていません。

ファイルはこちらです。
google-ime-dict.txt.hitnum.zip

// ファイル名は「anilogia-google-ime-dict.txt」などのほうが
// 内容をひと目で判断できて良いかもしれません。

検索はローカルで機械的に行ったので、Wikipediaサイトには負担をかけていません。
全然別の関係で最近同じような処理をたまたま作ったのでそれを利用しました。

私自身はアニメに詳しくないのですが、
例としてヒット数が0件で表記が実際に間違っているものを挙げます。
(正しいと思われる表記はGoogleで手動検索しました)
0 イリヤノソラユーフォーノナツ イリヤの空.UFOの夏 固有名詞
イリヤの空、UFOの夏
0 ウゴウゴルーガ ウゴ・ウゴルーガ 固有名詞
ウゴウゴルーガ
0 ウタノプリンスサマッマジラブセンパーセント うたのプリンスさまっ♪ マジ LOVE 1000! 固有名詞
うたの☆プリンスさまっ♪マジLOVE1000%
0 ウタノプリンスサマッマジラブニセンパーセント うたの☆プリンスさまっ♪ マジ LOVE 2000! 固有名詞
うたの☆プリンスさまっ♪マジLOVE2000%
0 ソウコウキヘイボトムズペールゼンファイルズゲキジョウバン 装甲機兵ボトムズ PAILSEN FILES 劇場版 固有名詞
装甲騎兵ボトムズ ペールゼン・ファイルズ 劇場版

みんなのうた「(題名)」の表記揺れについて

みんなのうた「(題名)」のふりがなが、「みんなのうた」を含むものと含まないものとがありましたのでご報告します。
個人的には「みんなのうた」を先頭に付与したほうが他のタイトルと統一感があってよいかと思いますが、どちらかに統一したほうがよいと感じました。
全部は抜き出せていませんが1つ気づいたのはここです

みんなのうたやさしいひーろー みんなのうた「優しいヒーロー」 固有名詞 TV版 (2011/6/1)
すまいるふらわー みんなのうた「Smileflower」 固有名詞 TV版 (2011/6/1)
おやすみ みんなのうた「おやすみ」 固有名詞 TV版 (2011/6/1) イラスト・アニメーション
としょかんろけっと みんなのうた「図書館ロケット」 固有名詞 TV版 (2013/10/1) http://www2.nhk.or.jp/minna/search/index.cgi?id=MIN201310_02
まわれとろいか みんなのうた「回れトロイカ」 固有名詞 TV版 (2013/10/1) http://www2.nhk.or.jp/minna/search/index.cgi?id=MIN201310_01

Windowsが未対応の文字(WAVE DASH等)を変更して欲しい

アニメ作品のタイトル名部分に、Microsoft WindowsのOSの標準APIが持つCP932←→Unicodeの変換テーブルにない、通常の方法では入力できない文字が含まれているエントリが多数存在します。MS-IME用辞書データについても同様です。

現在、この問題に該当すると思われる文字は以下の通りです。

「〜」 文字U+301C
「–」 文字U+2013

あいまいみーさーじかるふれんず	あいまいみー~Surgical Friends~

は波ダッシュにWindowsで入力可能なU+FF5Eが使われています。

せんごくちょうじゅうぎがおつ	戦国鳥獣戯画〜乙〜

は波ダッシュにWindowsで入力できないU+301Cが使われています。

ぴーぴんぐらいふうぃーあーざひーろー	Peeping Life – WE ARE THE HERO –

にはダッシュにWindowsで入力できないU+2013が使われています。

これは俗に言うところのWAVE DASH問題と呼ばれているものです。
……ある意味宗教論争的な不毛な話題と受け取られる可能性があることは重々承知しております。
私のようなWindowsの日本語入力IME開発者にとってはどうしても見過ごせない最重要テーマですので慎重に書きたいと思います。
しかしながらUnix利用者から見ると、この内容にはWindows利用者寄りのバイアスがかかっているということはご承知おきください。

詳細については以下の記事が詳しいです。
http://internet.watch.impress.co.jp/docs/special/691658.html
https://ja.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%B7%E3%83%A5_(%E8%A8%98%E5%8F%B7)

Anime DBにおいて核心となる部分を上記より引用します。

シフトJISからUnicodeへの変換先が、2つありうるというマッピングの問題。具体的にはシフトJISで0x8160(JIS X 0208では1-33)をUnicodeに変換した場合、Microsoftの製品群ではU+FF5E、それ以外の多くはU+301Cと異なってしまう。しかも大半のフォントはU+FF5EとU+301Cのグリフを同一にしているので、外見からは全く判定できない。

実はこの問題は上記だけではありません。上の引用ではSJIS→Unicodeの変換のことにしか書かれていませんが、この問題がさらに厄介なのはこういうことです

「ほとんどのWindows利用者には、U+301CやU+2013等の文字を入力する手段がない」

なぜなら、この文字がファイル名や文書内に紛れこんでしまったら最後、MS-DOS~Windows XP時代以前の古いアプリケーション(これらは今でもWindows 10上で動作しますし、使っている人が沢山います)から利用できなくなってしまうからです。このためMSはかなり慎重にこの文字がMS-DOS時代~WindowsXP時代くらいの古いアプリケーションに渡らないよう慎重に慎重を重ねてOSの各種処理を実装しているように見えます。
文字化けは標準のメモ帳のデフォルトのセーブ設定が今でもCP932だったりするので、ちょっとメモしてセーブしただけでU+3013の波ダッシュが「?」に書き変わってしまいます。下図はこのサイトで現在配布されているms-ime-dict.txtをWindows10標準のMS-IMEに読み込ませた状態でメモ帳で変換し何度かセーブを行なった状況です。

default

こうした厳しい現実を見て、「Windowsってしょうもないよね」「Unixならそんな事なんてないんだから放っておけばいいよ」で済ませるというポリシーもあることは理解しています。
しかしAnime DBのような多数の人の手による編集・改良が今後も必要となるデータにおいて、現時点で利用者が多いと思われるWindows利用者を対象とすることは開発の門戸を広げるという意味でメリットが大きいのではないかと思います。
余談になりますが、CSVの規格であるRFC4180において、改行がなぜUnixスタイルの\nではなくMS-DOSスタイルの\r\nなのか、などもこうした「開発者への門戸の広さ」を重視した結果ではないかとわたくしは考えております。

さて長々と書きましたが、この問題に対処するのは簡単です。文字を機械的に置換するだけです。ただ、どう変えるべきかについては判断が難しいかもしれません。私からは2つ提案があります。

  1. 理想を言うなら、全てのU+301Cの文字をWindows利用者でも入力可能なU+FF5Eの文字側に揃えて欲しいです。これにより、Windows利用者でもこのDBの直接編集が可能となり、たくさんの開発者を受けいれる可能性が出てくると思います。
  2. DB原本は現状維持とし、CSVとIME辞書データのみ変える。DB原本側のWAVE DASHはどちらの文字で記述されていても許容する。Windows側からも利用する可能性の高い、CSVファイルやIME用辞書ファイル内の文字はU+FF5E側で統一する。

何卒よろしくお願いいたします

MADB から取得した `episodes` の `prefix`,`title`,`literal_title` を修正する

ref: #10

目処がたったら,もっと細かい issue にわけるなどして対応すること.

問題例(#10 から引用)

  • titleで改行が含まれるものがある。

  • episodesが途中からしか入っていないアニメがある。

  • titleに本来はなかった日付が含まれているアニメが多数ある。

    • (11/27)のようにmm/ddが括弧書きで追加されている。
  • 鉄腕アトムの54話以降titleに話数が重複している。

    +  - ended_at: 1964/01/04 19:30
    +    title: 第54回 アルプスの決斗の巻*
    +    literal_title: 第54話 第54回 アルプスの決斗の巻*
    +    prefix: 第54話
    +    started_at: 1964/01/04 19:00
    +    ruby: ''
  • ドラえもんで、prefix = S1が複数ある。

    +  - ended_at: 1999/12/31 19:00
    +    title: S 未来を守れ! のび太VSアリ軍団
    +    literal_title: S1 S 未来を守れ! のび太VSアリ軍団
    +    prefix: S1
    +    started_at: 1999/12/31 18:50
    +    ruby: ''
    
    +  - ended_at: 2001/03/23 19:00
    +    title: 1617 タンポポ空を行く
    +    literal_title: S1 1617 タンポポ空を行く
    +    prefix: S1
    +    started_at: 2001/03/23 18:50
    +    ruby: ''
  • ドラえもんで、途中からtitleの数値の後ろの半角スペースが消える。

    • 1690 予言者ジャイアン
    • 1691メー演機
    • 1737物知~る
    • 1738 ナカナオリン <- ここで復活
    +  - ended_at: 2002/11/29
    +    title: 1690 予言者ジャイアン
    +    literal_title: 958 1690 予言者ジャイアン
    +    prefix: '958'
    +    started_at: 2002/11/29
    +    ruby: ''
    +  - ended_at: 2002/12/06
    +    title: 1691メー演機
    +    literal_title: 959 1691メー演機
    +    prefix: '959'
    +    started_at: 2002/12/06
    +    ruby: ''
    
    +  - ended_at: 2003/11/28
    +    title: 1737物知~る
    +    literal_title: 1001 1737物知~る
    +    prefix: '1001'
    +    started_at: 2003/11/28
    +    ruby: ''
    +  - ended_at: 2003/12/05
    +    title: 1738 ナカナオリン
    +    literal_title: 1002 1738 ナカナオリン
    +    prefix: '1002'
    +    started_at: 2003/12/05
    +    ruby: ''
  • 機動戦士SDガンダムprefixが全て-になっている。

    +  episodes:
    +  - ended_at: 1989/06/25
    +    title: 機動戦士SDガンダム MARK-Ⅱ 転がるコロニー事件
    +    literal_title: '- 機動戦士SDガンダム MARK-Ⅱ 転がるコロニー事件'
    +    prefix: '-'
    +    started_at: 1989/06/25
    +    ruby: ''
    +  - ended_at: 1989/06/25
    +    title: 機動戦士SDガンダム MARK-Ⅱ 元祖ガンダム迷場面集
    +    literal_title: '- 機動戦士SDガンダム MARK-Ⅱ 元祖ガンダム迷場面集'
    +    prefix: '-'
    +    started_at: 1989/06/25
    +    ruby: ''
  • それいけ!アンパンマンで、prefix = S1が複数ある。

    +  - ended_at: 1999/12/17
    +    title: アンパンマンと メリークリスマス! 前編
    +    literal_title: S1 アンパンマンと メリークリスマス! 前編
    +    prefix: S1
    +    started_at: 1999/12/17
    +    ruby: ''
    
    +  - ended_at: 2002/12/13
    +    title: 勇気のほのおとクリスマス(前編)
    +    literal_title: S1 勇気のほのおとクリスマス(前編)
    +    prefix: S1
    +    started_at: 2002/12/13
    +    ruby: ''
    
    +  - ended_at: 2006/12/22
    +    title: うたおう!おどろう!みんなのクリスマス
    +    literal_title: S1 うたおう!おどろう!みんなのクリスマス
    +    prefix: S1
    +    started_at: 2006/12/22
    +    ruby: ''
  • スパイラルゾーンprefixがいい感じじゃない。

    +  episodes:
    +  - ended_at: 1988/10/31
    +    title: Vol.1発進ゾーン・ライダー
    +    literal_title: 第1巻A Vol.1発進ゾーン・ライダー
    +    prefix: 第1巻A
    +    started_at: 1988/10/31
    +    ruby: ''
    +  - ended_at: 1988/10/31
    +    title: Vol.2悪魔の小箱
    +    literal_title: 第1巻B Vol.2悪魔の小箱
    +    prefix: 第1巻B
    +    started_at: 1988/10/31
    +    ruby: ''
  • ふしぎの海のナディアtitleにゴミ(「連続39回」)がついている。

  • ふしぎの海のナディアprefixがおかしい。

    +  episodes:
    +  - ended_at: 1990/04/13
    +    title: 第1回 エッフェル塔の少女 「連続39回」
    +    literal_title: 1 第1回 エッフェル塔の少女 「連続39回」
    +    prefix: '1'
    +    started_at: 1990/04/13
    +    ruby: ''
    +  - ended_at: 1990/04/20
    +    title: 第2回 小さな逃亡者 「連続39回」
    +    literal_title: 2 第2回 小さな逃亡者 「連続39回」
    +    prefix: '2'
    +    started_at: 1990/04/20
    +    ruby: ''
  • 新世紀エヴァンゲリオンprefixいい感じじゃない。

    +  episodes:
    +  - ended_at: 1995/10/04
    +    title: 第壱話 使徒、襲来
    +    literal_title: 第1話 第壱話 使徒、襲来
    +    prefix: 第1話
    +    started_at: 1995/10/04
    +    ruby: ''
  • 今、そこにいる僕 NOW AND THEN, HERE AND THEREで、prefixがいい感じじゃない。

    +  episodes:
    +  - ended_at: 1999/12/02
    +    title: 第八話 ひとりぼっちのふたり
    +    literal_title: 8 第八話 ひとりぼっちのふたり
    +    prefix: '8'
    +    started_at: 1999/12/02
    +    ruby: ''
  • Mr.Digital TOKORO the comical cartoon [第2期] で、prefixがいい感じじゃない。

    +  episodes:
    +  - ended_at: 2001/04/17
    +    title: '#126 サンダージョージ その①'
    +    literal_title: '126 #126 サンダージョージ その①'
    +    prefix: '126'
    +    started_at: 2001/04/17
    +    ruby: ''
  • フルーツバスケットで、prefixがいい感じじゃない。

    +  - ended_at: 2001/07/05
    +    title: 第一話・・・
    +    literal_title: 1 第一話・・・
    +    prefix: '1'
    +    started_at: 2001/07/05
    +    ruby: ''

各話情報を入力する(構造・方針)

アニメの各話情報(エピソード)を入力する.

構造

episodes キーに配列として表す.
各話ごとのスタッフ情報など,他にも様々な情報が考えられるが,一旦以下の例にあるように最低限の情報だけ記録する(それでも今記録されている全てのアニメを網羅するのは大変).

episodes:
  - prefix: "第1話" # エピソードの位置を指定する(と思われる)文字列
    title: "16の星と月が巡る日" # 基本的には literal_title から prefix を抜いたもの
    literal_title: "第1話 16の星と月が巡る日" # エピソードの無加工のタイトル
    ruby: "ジュウロクノホシトツキガメグルヒ" # title のヨミガナ
    started_at: "2000/04/20 18:30" # (最速)放送開始日時
    ended_at: "2000/04/20 19:00" #(最速)放送終了日時

入力方針

まずはメディア芸術データベースから各話情報を取得して加筆・修正を行っていく.
網羅率や正確性は高くないと思われるので,その他の起点になり得るデータベースを活用して情報を埋めていく.
但し,メディア芸術データベース以外を利用する場合は,名寄せの問題が難しい.

起点になり得る他データベース

データベースを CSV フォーマットにしたものを追加する

Anime DB は現在 YAML フォーマットで管理している.
YAML の可読性は高く(YAML は元々それを目的にして作られた),表現力も十分だが,Excel などで閲覧したい場合は不便である.
そこで,Anime DB の一部を CSV フォーマットで出力できるようにしたい.
出力結果は,dict/ 以下の Google IME 辞書フォーマットなどと同様に,animedb.yml の編集に合わせて animedb コマンドで出力し,コミットする.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.