ContentsBusinessXML仕様のFAQ

項番 コメント内容 回答
1 最初にビジネス辞書あるいはｅｂＸＭＬではコアコンポーネントといっているかもしれませんが、この業界で使われている言葉の整理が辞書として国際的にも通用する内容になっているのか、それから、マルチメデイア・コンテンツを扱う為の技術辞書もしくは商品情報で使われる用語がこれで必要十分なのか、気になります。 (1) 辞書として国際的に通用するか
→当面国内のみを考慮しています。国際対応は将来検討する。
(2) コンテンツを扱うための辞書として十分か
→実際に使用されている紙の帳票を収集・整理したものなので実業務に耐え得ると判断しています。
2 ビジネス辞書で定義されたものは当然、ペイロードの交換でも使われることになりますが、更にコンテンツ詳細情報を従来のドキュメント情報のように定義して空タグがたくさんあろうがお構いなしにインターネット上で情報交換する仕組みをいつまでも使っていて良いのか疑問があります。製品情報の辞書で定義されていれば、できるだけ、その詳細情報はお互いに技術辞書を参照して自明の情報は送らないようにすべきではないでしょうか。どうせ、HTTPのプロトコルではＲｅｑｕｅｓｔとResponseの繰り返しでお互いの情報交換がなされるので一度に大量の情報を送る必要もないのではないかと考えています。RosettaNetではPIP2A9という標準があって、電子部品情報の交換を実現しようとしていますが、今までは製品情報交換しか想定していませんでしたが、これからは環境負荷情報もこうかんしないといけなくなったのでRNTDというRosettａＮｅｔの技術辞書を拡充して環境負荷情報すなわち有害物質情報の定義をすれば、同じようにPIP2A9の仕組みの上で環境負荷構成物質情報交換も実現できるのではないかという話があります。 現在は、参照可能な情報の蓄えなしに運用できる形態を想定しています。(交換された帳票のみで情報が完結する)。
将来的には共有の情報を参照するアーキテクチャの導入もあり得ると考えています。
3 コンテンツ配信・利用の許諾には、必ず申請側・許可側での利用料金に関する合意が必要と認識しています。
仕様書案では、料金に関する情報が、各所に現れています。
処理の簡便化を考慮すると、<料金>のようなクラスを設けて、その中で柔軟料金体系を設定した方が良い気がします。 		本仕様では、コンテンツ使用許諾／著作物利用許諾の交換に重点をおいており、利用料金の体系化は優先度がそれほど高くなかったことと、業界へのヒヤリングの結果、柔軟な体系化は困難との認識から、現状ではテキストで記述することとなっております。
今後、広くコンセンサスを得る必要があるとは、認識しています。
4 例えば、一つのビデオに複数のタイトルが入っているようなコンテンツがあります。
このようなコンテンツを扱うために、< コンテンツ情報 > の階層化が出来た方が良いと思います。 		現在の仕様では、著作物情報クラスの多重度(1..n)のところで、例えば、１つのＣＤアルバム中の特定の楽曲に対して、個別で利用許諾情報を出すことが可能になっています。
より上位の階層で表現できるようにすべきかどうかの検討が必要と考えます。
※配信許諾情報に関しては、例えば、１つのＣＤアルバム全体を扱うのみで、中の特定の楽曲に対して配信許諾情報を出すしかけにはなっておりません。業務要件として必要か否かの検討・確認が必要と考えます。
5 P8を見ると、首記の多重度は”1”になっています。つまり、コンテンツID毎に利用許諾、配信許諾が必要となります。
項番４が無い場合、複数コンテンツの一括許諾を可能にしては如何でしょうか？（多重度を”1..n”にする。）
例えば、CDアルバムの全コンテンツを一括許諾するという運用になります。 		同上
6 映像の部分利用などへの対応は必要ないのでしょうか。 現在の仕様では、利用許諾情報に関しては、１コンテンツ中で利用する著作物のタイトルごとに、利用時間を記述する形態になっていますが、業務要件として、利用部分（例えば、最初の３０分間等）を明記する必要が出て来た時には、対応が必要になってくると考えます。
7 データ形式の変換への対応は？
　　例：動画データをストリーミングデータに
　　※事前条件の「コンテンツを配信できる状態にある」の解釈は一意的か　 		配信許諾情報の「ブロードバンド」に「圧縮形式」や「ビットレート」などのデータ形式の変換に関する情報は含んでいます。
「コンテンツを配信できる状態にある」というのは、コンテンツ配信事業者のことですから、コンテンツを配信できる状態に無い事業者には、配信許諾の申請を行うための条件を満たしていないということで解釈は一意だと考えています。
8 静止画像は想定しないのでしょうか 将来での拡張は念頭にありますが、現状では対象として含んでいません。
9 制作までではないが、複数のコンテンツを組み合わせての配信は考慮する必要はないのでしょうか。
　　例：映像・画像とＢＧＭ 		現状の仕様では、コンテンツを単体で使用することを考慮しており、コンテンツを組み合わせて使用することは考慮していません。今後、業務を確認する必要が有ります。
10 可否結果は、本当に「可」と「否」だけでよいのでしょうか。
相手の情報からだけ間違いなく必ず「可・否」を判断できるのかということです。
例えば
・記述の間違い
・何かしらの誤解
・・・・・・
などで回答できない場合があるのではないかということです。これらは、日常の定型の書類を提出するときにもよくおきていることです。
入力アプリケーション側等でチェックするとか、その時はメールなど別な手段で交渉するということになるのかもしれませんが、「可・否」以外の結果も必要かなと感じました。 		「可・否」の他に追加するとしたら「保留」だと考えています。但し、業務要件として「保留」が実際に必要かどうかの確認・検討を今後行っていくことが必要だと考えます。
「可・否」以外の結果とは異なりますが、可否結果に付随する例外条件には「例外条件」の要素を、コメント等には「備考」要素が用意されています。
11 肖像権などような他の権利処理については触れる必要は、ないのでしょうか。 肖像権の問題もクリアされたもののみ、利用許諾が出されることになるため、現状の仕様で対応可能です。
12 担当者情報で、E-Mailアドレスは担当者のメールアドレスを表わすのだと思いますが、それに加え部署のメールアドレスがあった方が良いのではないでしょうか。ただメールアドレスと指摘した場合には、個人のアドレスを書かれる方も、役割にあてがわれたアドレスを書く方もおられます。個人の場合には、移動などで、的確な連絡先でなくなることが予想されます。また、確実に相手と連絡を取りたいときは、個人アドレスの方が有効です。そこで、個人と役割のアドレスを別々に指定しておいた方が便利かなと考えました。ただし、これらの情報は流通交渉のその時だけ利用可能ならよいということであれば、特に考慮しなくてもよいような気もします。 担当者情報のE-Mailアドレスには、担当者という役割にあてがわれたメールアドレス（例えば、webmaster@aaa.co.jp等)が用意されている場合にはそのアドレスを、無い場合には、担当者個人のメールアドレスを入力することになると考えます。
したがって、「部署のメールアドレス」を「担当者という役割にあてがわれたメールアドレス」と解釈すれば、別に用意する必要はないと思います。
また、個人アドレスが異動などにより無効になった場合は、電話やFAXなどの他の連絡手段の項目がありますので問題無いと考えています。
13 「配信許諾を得る」の前に、「利用・許諾問合せ」のような処理を考慮した方が実際的ではないでしょうか 「利用・許諾問合わせ」の処理を想定した場合、「配信許諾申請を行う」処理と処理内容は変わらないと考えられます。本仕様の本来の目的が効率化にあるため、処理の簡略化のためにそのような処理は含んでいません。
< - 仕様公開ページに戻る