Tsutomu Kamimura [X] (Inactive) added a comment - 16/Oct/17 6:55 AM Based on discussions at TC and interactions with Yoshida-san, this change is not a clear improvement. Therefore, we decided not to implement the proposal.

Tsutomu Kamimura [X] (Inactive) added a comment - 16/Oct/17 6:53 AM Exchanged mails with Yoshida-san to discuss its implications. Mail of September 14, 2017 吉田さん、 この件昨日のTCで議論しました。と言っても私と薮田さんでの議論でしたが。 結論から言うと、どの変更案でも現状の課題が解決され他の問題もなくなるかと言うとそうとも思えないと言うことでは一致したので、とりあえずは現状のままで変更しないのが良いと言う方向になりました。 いくつかコメントをします。 モデルとスキーマの一致については現在でも既に不一致の部分が出ていて、完全に一致させると言うことではないと思います。ただ不一致の部分はUMLのクラス定義とRDFでのリソース定義の違いと、実装によって使い勝手がよくなるため等が主な部分で、主要コンセプトの違いまで許容すると言うことにはなってないと思います。 吉田さんの人と国籍の議論はわかりますが、PlanやReportなどのManagedItemCollectionとManagedItemの関係については、作られた全てのManagedItemがどれかのManagedItemCollectionに入るとの保証はないので、リンクをたどることではどのProjectに入るかはわからないものが出てくる可能性があると思います。それでManaagedItemにProjectへのリンクをもたせるのが良さそうにも見えますが、そうすると冗長性が多くなり、例えばExcel adaptor等でManagedItemの中身をExcelに読み込む時に全てのManagedItemの部分にProjectが入るのは流石に違和感を覚えます。ほとんどのツールではManagedItemに相当する情報を作った時は、Projectがわかっていてそれに相当するエリアやdirectoryに作るでしょうから、Projectをアクセスするためには他のやり方の方がいいように思えてきました。ただRDFではリソースとそれらをつなぐグラフのみなので、直接リンクを作るかqueryによるかしかないのでしょう。それでManagedItemCollectionに入っていないManagedItemのProjectがどうしても必要になる場合は例えばProjectがわかっているManagedItemと何らかのリンクでつながっているなどのqueryを使うということでしょうか。 ScopeItemのactualSizeとplannedSizeをMeasureにするのは私もいいように思いましたが、薮田さんは現実のプロジェクトでバラバラにSizeを決めてトラブルを起こすことがよくあるので、Sizeはプロジェクトレベレで決めるのがGovernanceを効かせるのは重要とのことで、やはり反対の立場です。 と言うわけでおさわがせしましたが、とりあえず、この件に関しては今は修正なしということでお願いします。若尾さん、青山先生の意見でまた変わる場合は再度連絡します。 上村