アーカイブ

  • その145: グラフ・データベース利用を考察する(1)

    グラフ・データベースが登場してから、既に20年以上の歴史がありますが筆者の認識では、ここ数年になって注目度が一段上がってきたように思われます。データの視覚的イメージを元にした表現形式としては以前から利用されてきましたが、アプリケーションによる利用技術としてはネットワーク型の関係分析、インターネット等での個物の距離や結合度の強さ把握と云った領域で暫く注目されていた技術であったと考えています。またリンクト・オープンデータ(LOD)のような記述的データ表現(主語、述語、目的語のトリプル)を利用したデータの共有、連携のような点に着目し、その中から特徴を見出そうという流れがあったように思われます。

    更に注目度が向上してきたのは、ここ数年のAI人気が貢献していると云えるでしょう。グラフ表現技術の利用により、機械による大量データの取込み、そして意味表現の標準化と、そこから派生する意味取り・推論への連携といったことが高い精度で可能になりつつあるといった点だと思われます。ただこの推論品質の高いデータ利用を実現するには、単なるトリプル(三つ組み)表現データの大量集合というだけでなく、データの類似性、意味表現の高度化といった点をカバーする要求への対応性を上げる必要性に迫られることになります。これを行う技術がオントロジーを導入したモデル表現の取り入れになります。

    このオントロジー表現の取り入れというのは、使用するデータがリレーショナル・データベースに存在するきちんと整理・モデル化されたテーブル表現をそのまま利用する範囲であれば、ある程度の精度で利用可能でしょう(リレーション情報が体系化された上できちんと設計し、DBMS内のスキーマとして構築されたという前提があります)。そうでない場合、データの品質、精度といったものが犠牲にされ、利用者の信頼感を維持するのが難しいといった状況を生むことになりかねません。この意味で、既存のデータベースのモデル化適用が当初から行われていることが大切であり、後付けでオントロジー設計を行うという方針では立ちゆかないという現象が発生するといっても過言ではないといえます。

    実際には、オントロジー設計というのはリレーショナル・モデル設計と根本的な違いがあるということではありません。クラス、サブクラス(リレーショナルでは、エンティティ、サブタイプ)、プロパティまたは関係性と属性(リレーションルではリレーションシップと属性)、インスタンス化(リレーショナルではロウの識別)といった類似性があります。またどちらのモデル化方式でも、ロール(役割)の適切な把握が大切な位置付けとなります。ややもすれば(特に日本では)「動詞句」として扱われ、余り語彙管理が疎かにされていた部分では、オントロジーを用いた設計では、管理上重要視される点に注意が必要です。

  • 今後 分科会の議論の中で認識された考慮点等、折に触れこの欄で紹介したいと考えています。 游悠レポートとして関連資料を紹介していますので、当話題に興味ある方は合わせて参照下さい。
  • (先頭に戻る)
  • その144:  現在のユーザ・デジタル環境考(近頃の経験を通したレビュー)

  • サービスサイエンスという研究領域の始まりは1980年代に遡ります。応用領域の中心はマーケティング分野に始まり、顧客満足を取り込む流れでのサービス指向の形で適用領域が広がってきたというのが著者の認識です。今回この話題冒頭に持ってきたのは、最近筆者のスマートフォンを利用機種変更のための作業をしながら浮かんだ考えに端を発します。DXの推進というのが経産省を初めとして様々な官公庁の音頭で進められ、その際の一般利用者に向けたインタフェース領域の主役は主にスマートフォンであると言って過言ではないでしょう(総務省統計によれば、2022年の個人のスマートフォン普及率は84.9%に上ると報告されている)。この機器基盤をベースに、例えばマイナンバー基盤を用いたスマートフォンのアプリケーション(アプリと略)を通じて、様々な利用者情報管理を次々と行おうという流れが進んでいます。

    しかし一般利用者視点で改めて眺めて見ると、アーキテクチャやアプリケーション開発といった基本的な部分で、現在かなり無理が通されているのではないかと筆者は感じています。例えばスマートフォン上のアプリは、様々な企業が個別に自社サービスへの取込を狙う形で開発提供しているのが実情でしょう。この結果、利用者に取っては色々な会社のサービスを利用しようとすればするほど、際限のないアプリ導入を余儀なくされてしまいます。アプリというソフトウェアだけでなく、利用基盤であるスマートフォン(ハードウェア)は、電気を利用するという制約がある以上、バッテリー寿命を考慮せざるを得ないことにより2~5年程度といった比較的短期間でのユニット交換を迫られます(勿論、不便を受け入れた形で限界まで利用するという場合、もう少し利用期間は長くできるでしょう。新しい機種ではバッテリー充電量を大容量化しようという流れになっています)。また私企業によりOS開発側の都合により更新されたOS版を使うには、既存のスマホ資源(メモリ、CPU、グラフィックス機能等)が非力になってしまうことにもなります。

    新しい機種に容易に乗り換えられる一部の利用者を除 いて 、残された一般的スキル及び経済的環境に置かれる他の利用者にとって、率直に言って経済的・時間的・技術的・ 精神的負担は、もはや小さいものだと言い切れない状況と筆者は考えます。アプリ移行においても個別対応により、必要なIdやパスワード、承認方式が異なり、移行に際しての時間負担も小さいとはいえないのが現在のスマホ基盤提供の実態といえるでしょう。勿論、新機能が次々と開発され、それをスムーズに利用可能な「一部の利用者」に取ってはメリットが大きいという意見が出るのは承知の上ですが、ここでは残された(大多数ともいえる)利用者視点からの意見です(実際、筆者の周りの利用者の意見を聞くと、同様な意見をそれほど時間を使わずに集めるこができます。
  • また、アプリ提供・開発者側から見ても本当の意味での一般利用者を想定したサービスデザインという点は少しおざなりにされているのではないかと疑いたくなります。話題先行、不具合が起きた場合、後追いで対応すれば良いという傾向もあるように思えます(典型的にはマイナンバーの暗証番号を高齢者向けにはなくそうという変更の話題に突然仕様変更が起きるなど。これはアプリそのものだけの話ではありませんが)。この稿で筆者が述べたいことは、様々なリテラシーおよび経済レベルの多数の利用者が混在する環境向けには、必ずしも「最新の技術に則ったアーキテクチャやインタフェースを導入して環境として放り出せば良い」という訳にはいかないことを十分考慮した方策・設計が必要であり、その点が十分検討されてない状況という点です。

    (先頭に戻る)
  • その143:  オントロジー設計視点とデータモデルの課題考

    今回の話題は、6月18日に(財)データマネジメント協会(旧・米Dama日本支部)の月次勉強会で筆者が次の表題で発表した内容を概要紹介するものです。「オントロジー視点と データモデル課題探訪 (誘い編)」(本内容に興味のある方は、「お問い合わせ」ページから筆者宛連絡を下さい) 昨今、リポジトリーといった用語管理や知識グラフとの連携といった点から「オントロジー」に関する技術知識領域に目を向ける人たちが徐々に増えてきています。元来「オントロジー」は哲学領域の「存在論」から始まり、情報学や人工知能の分野では工学的な技術領域として1990年代から研究されてきたものです。その概要的定義は「大雑把にいえば、概念化に現れる個物や関係をインスタンスとしてもつ クラス(概念)を同定して、それらを上位下位関係に基づいて組織化したもの」と説明されています(※1)

    このオントロジー表現の構成要素の第1は、制約的集合で表される「概念クラス」。これは概念階層の親・子関係で示されます。親クラスの基本属性は子クラスに引き継がれます。その他の要素として、「意味リンク」。このリンクには「全体-部分リンク」「一般-特殊リンク」「抽象-具体リンク」といった代表的なものがあります。更に「属性」「関係」といった基本要素があります。また項目の果たす重要な捉え方に「ロール(役割)」があり、この考え方はデータモデルのエンティティ、リレーション、属性の捉え方(表現)にも影響を与えているといえます。

    次にオントロジー設計を考える上で必要な要素は、(1)どのようなクラスを定義すべきか(クラス分類の推奨基準)、(2)本質属性の簡単な基準、(3)作成される対象ドメイン(分類)、(4)ロール(役割)概念の整理と表現、などが上げられます。但しオントロジーは表現レベルや研究者の捉え方により必ずしも同一の標準的表現で表されてはいない点に注意が必要です。またオントロジー設計ツール(エディター)に何を使用するかによって表現の制約が生まれます。オントロジーは表現する概念の構成と構造を表すものであり、実際のデータベースとして利用するには、具体物(インスタンス)群を作成追加することになります。

    オントロジーを理解する上での逆の見方として、「オントロジーは何でないか?」を分かることも役立つでしょう。それを列挙すると、(a)オントロジーは単なる語彙集合ではない、(b) オントロジーは単なる概念階層ではない、(c)オントロジーは知識表現ではない、といった項目が上げられます。そして、このオントロジー設計を支援するツールの代表 的なものには、「法造」(大阪大学溝口研究室開発、2023年現在は、大阪電気通信大学古崎研究室にてサポート)「Protégé 」(スタンフォード大学開発)があります。いずれもインターネットページからダウンロード利用が可能です。以上の内容は、主に溝口教授及び研究室著書を参考に説明したものです(※2)

    最後に、 このオントロジー視点から考察する筆者の捉えるデータモデルの課題点について項目列挙しておきます。(1) データモデル記述方式との類似性と差異は?
    (2)用語の異同/類似性比較
    (3)ER図 動詞句の果たす役割とその管理
    (4)パーティモデルは過度な汎化(一般化)
    (5)製造物のオントロジーとインスタンス視点
    (6)オントロジー組立て妥当性の考慮例
    (7)マスタデータ、リファレンスデータ等、コード系情報整理への活用
  • 注※1 知の科学 オントロジー工学 p.6  溝口理一郎 著  人工知能学会 編   2005年 オーム社
    注※2. -オントロジー構築入門  古崎晃司 他3名著  溝口理一郎 編  2006年 オーム社
        -知の科学 オントロジー工学の理論と実践  溝口理一郎著  人工知能学会 編  2012年 オーム社
  • (先頭へ戻る)
  • その142:  「デジタル・サニハ」というスキルの重要性を考える

    諸々の筆者都合により原稿休載していましたが、久々の話題を投稿します。今回はMLB(メジャーリーグ・ベースボール)の世界で起きた晴天の霹靂とも言うべき話題を題材にしたものです。この話題は、野球というスポーツのルールに詳しくない方々でもドジャースの大谷選手に興味のある人なら世界的に誰でも知っている内容と言って過言ではないものでしょう(大谷選手が米国での活躍をする上で、最も信頼していると思われたM氏(通訳)による大規模横領の件)。ここは内容自体を詮索することが目的ではないため、これ以上の事件詳細は割愛します。

    ここでデータマネジメント、特にセキュリティの視点で着目したいポイントは以下の点です。 (1)他者の発するメッセージについて、元情報およびその出所を含めた信頼性の評価が必要(2)受け取ったメッセージについて、元情報およびその出所を含めた正確性の確認が必要 (3)起きている現象、プロセスに関して定期的、継続的なログ管理を行うことが必要 (4)現実的・物理的世界以上に「デジタル世界」では(1)~(3)を一層重要視したアクションが必要

    (1)については、どこから、どのように、何を根拠に発生したデータ/情報を見ているのかを、信頼性評価の目で捉えることが常に必要であることを示します。ここでは常日頃、データ/情報の出所がどこまで信頼して良いモノであるかを観察しておくという努力が求められます。(2)については、自分に届けられたメッセージそのものの内容がどのようなものであり、どこまで受け入れて良いモノなのかを見極める習慣が必要だということです。そのためには、なにを元にしてデータ/情報が正しいと判断できるかの判別基準を常日頃鍛えておくことが求められます。ここで課題となるのが、(1)も(2)も100%間違いない答えを得ることが大変難しいという点です。その意味で確率的判断にならざるを得ない 。

    そこで必要になるのが項目(3)であり、それを支える事象確認のための手段を用意することと、それが確実にアクション結果として表れていることを定期的にチェックすることが求められます。これが「管理する」という習慣です。過去・現在・未来の流れとして事象がどのように、いつ行われたかを確実に記録し、その結果がどうなったかを見定めることです。ここでは、予期しない事象が発生していないかを予防保守的に確認するという行動が含まれます。そして仮想的に構築された昨今のデジタル世界での事象(例えば金融取引、日常に的ショッピング等)については、より一層の管理習慣が必要であるというのが今回の事件を通じた教訓と言えるでしょう。この一連の習慣ポイントを、ここでは「デジタル・サニハ」習慣と呼んでおきます。
  • 実際、今回の事件を有名選手に偶々起きた出来事と見過ごしてしまうことなく、自分の行動習慣として見直しておきたいというのが筆者自身へのメッセージです。(また、事件捜査の経緯を通じて、数年に渡る様々な取引記録(トランザクション処理内容、メッセージ往来記録、電話音声等)が数年に渡って記録され、レビュー可能な状態が裏面で行われていることを確認できた事も、筆者の収穫です。)
  • (先頭に戻る)