@＃382と＃367は関連しています

関連するディスカッションスレッドはhttp://www.mail-archive.com/[email protected]/msg00965.htmlにあります。

@mekarpelesコメントしてくれませんか？

@LeadSongDogタグありがとうございます！ ImportBotの改善を終えたらすぐにこれに対応しようと思います（これにより、Open Libraryに最大10万の読み取り可能なアイテムがもたらされることを願っています）。 おそらく今週末。 彼が量り込みたい場合に備えて、@ horncもccします。

@LeadSongDogに改めて感謝します。 このスレッドでは多くのことが起こっています。

メーリングリストへの応答：
1） @bfallingと私は、WorkページとEditionページをいくらか統合することを目指しています。 URL構造は同じように見えますが、ユーザーエクスペリエンスから、どのエディション（およびそのデータ）が選択/アクティブであるかを変更できるワークページに常に表示されます。
2）作品のタイトルを英語で維持することは実用的なアイデアだと思います。 反対の考えはありますか？ @ hornc 、 @ tfmorris 、@ dvanduzer？
3）エディションのタイトルを母国語/エンコーディングで維持することに部分的です

（編集：元の翻訳へのリンクがある場合がある隠された「ライブラリアン」機能とは何ですか？）

私は、翻訳に万能のルールがあるとは思いません。 「正しい」答えに最も近いのは、おそらく最初に公開されたバージョンです。 古代からの文学は、この規則の重要な例外です。 ホメロス、プラトン、または聖書のほとんどの代替翻訳には、それらすべてを1つの作品にまとめたくないほどの十分なオリジナルの奨学金が含まれています。

厳密に言えば、作品はすでにクラッジであるため、作品にタイトル情報を保存する必要はありません。 ガルシアマルケスのCienAñosdeSoledadについて話している場合でも、Intro to Calculusの第4版（および最新版）について話している場合でも、常に正規版があります。 Workオブジェクトがあると、UIを開発するのに便利です。 （ハードカバーかペーパーバックか、ギャレーコピーか作者のタイプライターか、パピルスのどの断片に作品の本質が含まれているかという形而上学を捉えようとしても意味がありません。）別の言い方をすれば、作品には「1ページ」から「1ページ」に私たちを連れて行く以外に何もしないでください-本または電子ブックを本に具体化すること。

「の翻訳」や「の改訂」などの関係が可換で推移的である場合は必ずしも明確ではないため、これはさらに複雑になります。 「オーディオブック」や「転写」のようなものは、さらに複雑な一方向の関係を持っています。

したがって、2）については、今のところWorkの下に正規のタイトルを保存する便利さを維持することは確かに実用的です。 将来のウィッシュリストは、常にユーザーのロケールに基づいてタイトルを表示し、ユーザーのロケールと異なる場合は常に元の言語のタイトルを含めることです。

確かに、二次的著作物はオリジナルよりもかなり優れていることがよくありますが、「作者」は、明らかにオリジナルのものであると私は思います。 翻訳者、編集者、およびその他の寄稿者は、実際に混同されるべきではありません。 最初に発行された版を特定することは、簡単に自動化できる単純なルールだと思います。 英語以外のエントリの場合、PubMedは英語のタイトル（およびその他のメタデータ）と元の言語の単語のタイトルの両方を保存することに注意してください。 これは、英語化のバリエーションの影響を受けますが、堅牢なアプローチです。

翻訳がどのように扱われるべきかについての議論の私の理解を凝縮しようとしています：

1. 翻訳版はオリジナル作品の版である必要があります
2. 翻訳された作業記録はすべて元の作業とマージする必要があります（つまり、リダイレクトになり、すべてのエディションを元の作業に移動します）

したがって、translation_ofフィールドは必要ありませんか？ 正しく設定されたtranslated_from（ライブラリアンモード）、理想的には翻訳者の役割。

これは、寄稿者の下に翻訳者を表示するために設定した例であり、エディションは英語で書かれており、古代ギリシャ語から翻訳されています。 https://openlibrary.org/books/OL18836004M/The_Iliad

作品のタイトルが英語であるということに関しては、それは大丈夫なデフォルトだと思います。たとえば、一般的な英語のタイトルを使用した古典的なギリシャ語とラテン語の作品には満足しています。 実際、私は、英語のタイトルは、ギリシャ語のアルファベットで元のギリシャ語のタイトルを試すよりも一般的に役立つと主張します。 ただし、ポリシーの問題として、フランス語、ロシア語、タイ語、またはアラビア語の元の作品のタイトルを必ずしも英語に変更する必要はないと思います。 作品のタイトルは、その作品で一般的に国際的に認められているタイトルであるというのがルールだと思います。 複数の候補者がいる場合、著者の場合は「別名」セクションが必要になるかもしれません。

translation_ofフィールドを削除/無視し、 is_translationフィールドに正しく入力するように努めることを提案します。

マージの実行を支援するために一時的にtranslation_ofに作業用OLIDを入力したい場合は、実際にはフリーテキストフィールドを使用した場合と同じように機能し、役立つ可能性があります。 マージを行う方が簡単かもしれませんが、作業マージインターフェイスを作成したら。

私は、作品が単なるUIの応急修理であることに同意しません。 便利なプロパティがたくさんあります。 私は、OpenLibraryが、作品は消耗品であると考える滑りやすい坂道を下り始めるのを見たくありません。

作品のタイトルには英語のみが適切だとは思いません。 それらはローカライズする必要があります。 作品は異なる言語で異なる一般名を持っており、OpenLibraryはそれに対応する必要があります。 ローカライズされた各タイトルにはその言語のタグを付ける必要があります。そうすれば、レンダリングコードは、ユーザーごとに適切なフォールバックを選択できます。たとえば、英語、フランス語、残りのロマンス諸語、その他の言語を選択できます。

translation_ofとtranslated_fromの違いがわかりません。 それらは私には同義語のように聞こえます（または、一方はWorkプロパティで、もう一方はEditionプロパティですか？）。

同じ作品に接続されているすべての言語のエディションが正しい方法です。

Freebaseは、実際には別のオブジェクトを使用して翻訳情報をキャプチャしました。 Work-Editionリンクに加えて、Translationオブジェクトにソース言語、ターゲット言語、翻訳者、および翻訳日が含まれるWork-Translation-Editionパスもありました。 これのいくつかはWork / Editionのペアから推測できますが、多くの場合、翻訳は特定のものとして語られ、複数のエディションで公開されることがよくあります。 これが必ずしも正しい方法であると言っているわけではありませんが、別のモデリングの代替手段としてそれを捨てることができます。

実用的なデータラングリングの観点から、最初にタイトルをNFC / NFKCに正規化すると、その後の比較と処理がはるかに簡単になると思いました。 http://unicode.org/reports/tr15/#Norm_Forms

申し訳ありませんが、用語はあまり明確ではありませんが
translation_ofはオリジナル作品のタイトルです
translation_fromは言語コードです

translation_of:イリアス
translated_from ： grc （古代ギリシャ語（1453年まで））

かなり長い間シャルル・ペローを打ちのめした後、「翻訳」と「元の言語」の編集は完全に無駄な努力であることが明らかになりました。 よく考えられたシステムで起こるべきことは、編集者が同じ著者の作品のリストから1つを選ぶことです。 この例では、数百のエディションと数十の翻訳がありますが、オリジナルの作品はほとんどありません。 複数の作業記録が単一の作業を反映している場合、リストには、最も編集されたものまたは最初に発行されたもの（日付のない記録は無視）のいずれかが表示されます。
余談ですが、収集された作品をより適切に処理する必要性も例示されています。エディションは、さまざまなサブセットを選択したり、さまざまな著者のストーリーをコレクションにまとめたりします。 いくつかのまたは選択されたものは、最初の出版物である可能性があります。Mmed'Aubreyによる物語は、いくつかの版で彼のContesdesféesと一緒にまとめられています。

@mekarpeles
これと
https://github.com/internetarchive/openlibrary/blob/7195f181742af7389843f275eefb2e675055b727/openlibrary/templates/books/edit/edition.html#L229 -242
おそらくと同様のアプローチを採用する必要があります
https://github.com/internetarchive/openlibrary/blob/7195f181742af7389843f275eefb2e675055b727/openlibrary/templates/books/edit/edition.html#L169 -188

タイトル、他のタイトル、および翻訳元は、すべて単一の作品を示す方法です。

@cdrini最後はあなたの仕事でしたね。 このビットも気になりますか？

おそらくこれに対する解決策は、これを「これはどのエディションの作品ですか」フィールドのように動作させることです。作品IDまたは作品の固有のタイトルの入力を許可してから、作品IDに関連付けられたタイトルを検索します。 IDと俗称の両方を保存、索引付け、表示する必要があります。
-改訂：または単にフィールドを削除して、意図したとおりに作業を使用します-

@seabelisすでに言われていることに加えて、何か追加するものはありますか？

また、 @ hornc 、この問題の担当者になりますか？ 譲受人であるということは、必ずしもあなたが仕事をする責任があることを意味するのではなく、問題に対処するための情報を収集/提供する責任があることに注意してください。 Wikiから。

割り当てられた所有者は、必ずしも問題を修正する人ではありません（問題が修正されるかどうか、またはいつ修正されるかは、その時点で必ずしも確立されているわけではありません）。問題を処理するために必要なものはほとんどありません（質問、入力の要請、優先度の確立と更新、重複しているかどうかの確認など）。

問題に「状態：進行中の作業」というラベルが付けられると、所有者は作業を行っている個人、または作業を行っているグループを主導/調整します。

コンテキストごとにラベルを追加しました：あなたの考えを教えてください

これは、作業から自動入力される可能性があると思います。 おそらく、作品には言語フィールドが必要です。そうでない場合は、各エディションの元の言語を入力する必要があります。これは、理論的には不要です。 これらを管理するための確固たる戦略がないため、マルチワークエディションでは厄介になる可能性があります。

まだ持っていない場合は、作業のoriginal_languageが便利な追加になります。 これにより、 @ horncがtranslated_fromを提案した情報を暗黙的にエンコードできます。

@LeadSongDog （または他の誰か）は、現在の提案がここにあるものの要約を与えていただけませんか？ すべての議論の後、私は望ましい変更が何であるかを理解するのに苦労しています。

おそらくこれに対する解決策は、これを「これはどの作品のエディションですか」フィールドのように動作させることです。作品IDまたは作品の固有のタイトルのいずれかを入力できるようにしてから、作品IDに関連付けられたタイトルを検索します。 IDと俗称の両方を保存、索引付け、表示する必要があります。

タイトルが表示されないという事実を除いて、これが「このエディションの機能」フィールドの機能です。 これは、この問題が解決されたことを意味しますか？

@cdriniスレッドの要約（何か見落とした場合は、他の人がこのコメントを自由に編集してください）。

プレマブル

これを入力すると、この問題をいくつかの問題に分割するか、 Epicにする必要があることに気付きました。

元の問題

多くの翻訳は、実際には翻訳元の元の作品のエディションである必要があるのに、独自の作品です。

現在、作品のタイトルのフリーテキストを受け入れるフィールドtranslation_ofと、言語コードを受け入れるフィールドtranslation_formがあります（つまり、古代ギリシャ語（1453年まで）の場合grc ）。

@LeadSongDogは、 translation_ofにWorks olidを受け入れさせて、翻訳を強制的に作品に関連付けることを提案しました。

後続の問題

1. 翻訳が「正規の作業」と見なされる場合や、いくつかの異なる翻訳が異なるロケールでの「正規の作業」と見なされる場合があります。 つまり、元の古代ギリシャ語でオデッセイを読みたいと思う常連客はほとんどいません。

2. 小説が別の国で出版されると、タイトルが変わる場合があります。 例：最初のハリーポッターの小説は、英国ではハリーポッターと賢者の石と題されていますが、米国ではハリーポッターと賢者の石と題されています。 これは翻訳ですか？

3. 翻訳自体に複数のエディションがある場合があります。 えっ！

提案されたソリューション

• 翻訳されたすべての作品を元の作品にマージします
  
  
  
  • 続いて、 translation_ofにworks_olidを要求させます/編集UIの表示はフリーテキストから機能し、ユーザーが関連する作品を選択できるようにします。
  
  
• 作品のタイトルはローカライズする必要があります。 そのため、「Communautédel'Anneau」を検索すると、「指輪の仲間」の作品ページのローカライズ版が作成されます。
• すべての作品にはoriginal_languageフィールドが必要です
• Freebaseの実装と同様の新しいWork-Translation-Object関係を導入します

小説が別の国で出版されると、タイトルが変わる場合があります。 例：最初のハリーポッターの小説は、英国ではハリーポッターと賢者の石と題されていますが、米国ではハリーポッターと賢者の石と題されています。 これは翻訳ですか？

いいえ、翻訳ではありません。 単なるマーケティングの決定。

エディションが元の作品に正しくリンクされると、「translation_of」エントリは冗長になります。 現在、多くのエディションレコードは、作業レコードがないか、間違ったレコードにリンクされているため、暫定的にデータに価値があります。 そうは言っても、私の以前の提案はよく考えられていなかったと思います。 @seabelisによるコメントは理にかなっています。それを表示すると、作業レコードから自動入力されるはずですが、なぜ同じことを2回言う必要があるのでしょうか。

修正されないので、これを閉じる必要がありますか？ 作業記録を2回保存するのは冗長に思えることに同意します。

（マージフローの作成（＃805）、およびすべてのエディションに機能があることの確認（＃2629）については、他にも問題があります）

これが最終的に別の問題によって間接的に解決されるのであれば、それを閉じることは問題ないと思います。

上記の2つの問題によって間接的に解決されると思います。

@ cdrini ＃805および＃2629は、複数のエディションを持つ翻訳には対応していません。

たとえば、ホーマーのオデッセイには、さまざまな言語の作品が複数あります。 これらすべてのエディションを1つの作品に統合することが、これを処理するための最良の方法ではないと思います。

この状況を処理する最も堅牢な方法は、独自のエディションを持つことができるが、 Original Workにリンクする必要があるTranslated Workオブジェクトを用意することだと思います。 ただし、これを実装するのにどれだけの作業が必要かはわかりません。

おそらく最も簡単な修正は、Worksページでエディションを検索およびフィルタリングできるようにすることです。

@guyjeangillesスキーマ内の新しいオブジェクトへの扉を開くことができれば、それは単なる翻訳以上のことに役立つはずです。 作業識別子のリストを取得できる「based_on」など、より一般的な回答を検討します。 そうすれば、翻訳だけでなく、アンソロジー、大要、収集された作品、翻案などを取り込むことができます。

@LeadSongDog based_onの実装が簡単な場合、これにより、コンパニオンガイド、スパークノート、ボックスセットなどの検索結果から関連メディアを除外することもできます。 例： https ：//openlibrary.org/search？q = the + hunger + games＆mode = everything

これらの目録基準（私がやろうとしていた）に従えば、すべての翻訳は、改作やコンパニオンなどがそうではない方法で、元の作品に属します。 https://www.isko.org/cyclo/work1.jpg

翻訳版の意味を完全に理解しているのかわかりません。 OL Work-Editionモデルは、表現と表現を実際には区別しません。 これはすべて「エディション」としてまとめてキャプチャされます。 これは、元の言語の「エディション」にも当てはまります。

そうは言っても、ある程度分離することにはメリットがあると思います。 これはトリッキーであり、翻訳（先週詳細に説明したように）やサイトのユーザーの言語設定を設定するだけではありません。 たとえば、特定の作品のウィキペディアの記事に頻繁にリンクします。 私は通常、作品の元の言語で記事にリンクしています。 作品が20の言語に翻訳されている場合、ウィキペディアだけで20のリンクが存在する可能性があります。 リストが非常に長くなるため、追加しません。 また、ウィキペディアの記事は一般的にエディション固有ではなく、これを複数のエディションに追加したくないため、個々のエディションのページへのリンクは追加しません。 これは、他の種類のリンク、つまり書評にも当てはまります。

仕事のレベルで言語でフィルタリングする方法があれば、これはユーザーにとって役立つと思います。 したがって、1）特定の言語のエディションのみを表示し、2）その言語で作業レベルのコンテンツを表示します。 多くの人が多言語であり、サイトコンテンツの設定が母国語に設定されていても、複数の言語で読み書きできるため、これはサイトの言語設定とは無関係である必要があります（ただし、デフォルトの動作を確立する必要があります。ユーザーは自分の好みを特定できます。つまり、「自動フィルターは私の言語設定で機能します」/「ショーは母国語で機能します」）。

@guyjeangillesが示唆しているように、Translated Workオブジェクトがあれば、これまたはこのようなものを実現できます。
＃1808に関連しますか？

@cdriniは、＃805も＃2629も複数のエディションの翻訳に対応するとは思わないので、これをぶつけます。 おそらく、別の問題を作成する必要がありますか？

議論がかなり長くなったので、私はこれのいくつかを見失ったかもしれませんが、最終的な決定はtranslation_ofを廃止し、既存の作業関係（現在のシステムがどのように機能するか）を使用することだと思いました正しい作業の下で翻訳を移動するための大規模な過去の取り組みがあります）。 この_does_は、複数のエディションがリンクされていない状態で翻訳された作品を残します。これは注目すべき素晴らしい点だと思いましたが、これは他の場所でも受け入れられている標準的な問題のようです。

現在のシステムは、翻訳を独自の作品に分離することもサポートできると思います（A.教皇の_Illiad_は、それが完全に正当化されると思う私の例です）が、作品をマージしてから試行する編集戦争に終わる可能性があるようです誰もが同意する明確な線を引くのは難しいので、それらを分割する。 「翻訳はすべて1つの作業に属します」は、作業が簡単です。

私たちはすでに同じ作品の下で異なる出版社による異なる版を混ぜ合わせています、これは実際にはそれほど違いはありません。 言語でエディションをフィルタリングまたは検索する適切な方法があれば、ユーザーに影響を与える実際的な問題はおそらく解決されるでしょう。

統合されていない作品については、既存のデータは保持されますか？

2601はここに関連しています。