情報のかたちと理解

  • InformationはFormを持つ
    • 情報を構成する枠組みを知る
    • 情報を既存の知識と関連付ける
    • 錯綜するデータを整理して形を与え、既存の知識に関連付けられるようにする
  • エージェントに伝える形、ユーザに伝える形
    • マークアップによってUAに形を伝え、CSSを経由してユーザに分かりやすい形で表現する
  • ウェブの「型」を身につけよう
    • 文学や芸術に“形式”があるように「フォーム」は重要
    • ウェブの「型」 → ユニバーサルアクセスとデータ共有・再利用

情報のかたちと名前

  • コンピュータと形式と名前
    • 形式化：形（枠組み）に名前を与えて共有可能にする
    • 形式化された情報はコンピュータ処理が可能
    • 情報を抽出する、変換する、推論する…
    • 錯綜するデータを整理して形を与え、共有できる名前を付ける
  • 名前とコンテクスト
    • おーい、あれ持ってきて（完全にローカルコンテクスト）
    • オペラが好きだ（コミュニティによる違い）
    • 東京都中央区銀座1丁目（コンテクストに依存しない）
    • 名前は共有できてはじめて意味がある
      • ウェブページで使われる名前はどんなスコープで通じるか

HTMLと情報のかたち

  • 文書のかたちを示すマーク付け
    • シンプルな文書構成要素の枠組みとしてのHTML
    • 機能としてのかたちを示すマーク付け
      • div要素型の役割
  • かたちの名前：要素型名
    • タグによるマーク付けは、文書情報のかたちと名前を示す
    • タグで形を示し、要素型名で名前を与える
    • グローバルに理解できる名前、そうでない名前
      • DTDで定義される名前 ←→ 文書作者が付ける名前

XHTMLと情報のかたち

  • より汎用性の高い情報のかたち
    • HTMLの文法知識を前提としないパース（Well-formedness）
    • 汎用ツールでも処理が可能な形式化
  • XMLツールで処理ができるからこそXHTML
    • オープンソースのXMLツール、処理言語のXMLライブラリ
    • IE、Firefox（Opera9が一部）がサポートするXSLT
    • 整形式でなければXHTMLじゃない
      • 世の中の「XHTML」の半数はill-formed?
  • XHTMLくずれはご勘弁
    • 終了タグ不在（→ 空要素タグは /> で閉じる）
    • 裸の&（→ 常に実体参照。属性値でも）
    • 裸の属性値（→ 数字だけでも属性値は引用符で囲む）

    ※XHTMLの書き方と留意点を参照。

文書情報の枠組みの拡張

  • (X)HTMLの基本要素型名で表現できない意味構造
    • 文書に含まれる個別情報
      • 見出し要素によってアウトラインは与えられるが、文書に含まれる個別情報のタイプを示す手段がない。
    • メディア（表現）としての文書の持つ機能の構造
      • form要素でコントロール機能は示されるが、メニュー、目次といった機能を明示できない
  • 拡張の方法
    • 基本要素の細分化
      • class属性によるサブクラスの生成
    • div要素による新しいかたちの表現

拡張構造に名前を与える

  • 再利用可能な役割：class
    • 情報のタイプあるいは役割を示すために名前を与える（普通名詞）
    • このイベントは<em class="date">2006-07-20</em>に行われる
  • 要素の固有名：id
    • リソースを直接名指しする（固有名詞）
    • 情報表現の主語
    • <p id="cssnite10">このイベントは…

共有可能なクラス名を考える

  • わかりやすいアプローチ：一般に通用しそうな言葉をclass属性値に
    • 「date」など（英語がわかる人間なら）誰でも理解できる言葉を用いる
    • 普及しているアプリケーションのタグ名を流用する
  • たとえばhCalendar
    • 情報ブロックとしてのveventクラスと、その中での日付などのクラス
    • <p class="vevent" id="cssnite10">
 <span class="summary">第10回CSSNite</span>が
 <em class="dtstart">2006-07-20</em>に
 <span class="location">銀座アップルストア</span>で行われます。
</p>
    • hCalendar対応アプリケーションはカレンダー情報を抽出できる
    • hCalendarからiCalendarの情報を抽出できる

クラス名の共有範囲

  • コミュニティを名前のスコープとして持つとき
    • 名前付けの約束を共有する（ローカルルール）
    • 会社内などコンテンツ管理が可能な範囲では有効なアプローチ
    • コミュニティ外では必ずしも正しく理解できない
  • microformats“コミュニティ”
    • hCalendar、hCardなどの独自の約束を公開
    • この場合の名前（クラス名）のスコープは？
    • コミュニティ内部では通じる名前も、スコープの外では理解できないことがある
    • コンピュータは定義がないと処理できない

グローバルな情報共有と形式

  • 任意のルールに基づく（特定範囲での）情報交換
    • microformatsなどコミュニティ単位の語彙、ウェブサービスごとのAPI
    • コミュニティごとに語彙やAPIが異なると、NxNの変換が必要になる
  • 特定ルールを前提としない（グローバルな）情報共有の枠組み
    • データモデル：RDF、（交換フォーマット：XML, Turtle, JSON、）クエリ言語：SPARQL
    • RDF/SPARQLをハブとすることで、Nx1の変換があれば相互運用ができる

RDFとデータのかたち

  • トリプルによるリソース表現
    • 主語-述語-目的語のトリプルで関係を記述
    • URIを用いたグローバルな名前付け
    • &lt;http://cssnite.jp/event/vol10&gt -- http://purl.org/dc/elements/1.1/date --&gt; &quote;2006-07-20&quote;
  • 対象（ノード）をURIで示す
    • 分散記述とグラフの併合が可能
    • グローバルな「ネットワーク効果」がもたらされる
  • ノードの関係（プロパティ）もURIで示す
    • 語彙の明確化と共有、語彙のマッピングが可能
    • date → http://purl.org/dc/elements/1.1/date（dc:date）

class属性からRDFへ

  • ローカルルールをグローバル化する
    • プロファイルURIの利用＝ルールの別途定義
    • <head profile="http://purl.org/net/ns/metaprof">
    • link要素によるスキーマ指定
    • <link rel="schema.dc" href="http://purl.org/dc/elements/1.1/" />
  • 接頭辞を使ったclass属性値
    • link要素で指定した接頭辞を応用
    • このイベントは<em class="dc.date">2006-07-20</em>に行われる
    • スタイル規則ではエスケープを利用
    • em.dc\.date {color: green}

XSLTによる変換

  • クラスの拡張表現を汎用モデルに変換
    • ローカルな"date"をDublin Coreの"dc:date"にマッピング
    • <xsl:template match="*[@class='date']">
 <dc:date>
  <xsl:value-of select="."/>
 </dc:date>
</xsl:template>
  • 機能デザインも意味情報へ
    • ページ内リンクは目次データになる
    • <xsl:template match="h:div[@class='menu']">
 <dcterms:tableOfContents>
  <xsl:value-of select="."/>
 </dcterms:tableOfContents>
</xsl:template>

変換スタイルシートを示す

  • GRDDL
  • profile属性とlink要素で文書にXSLTを結びつける
    • 抽出（変換）のXSLTを明示することで、class属性などのセマンティクスをグローバル化する
    • link要素によるXSLTの直接指定
    • <head profile="http://www.w3.org/2003/g/data-view">
 <link rel="transformation" href="(XSLTのURI)" />
    • プロファイルにXSLTの指定を埋め込んで、間接的にリンクしても良い
      • この場合はlink要素は不要

RDF化されたデータを検索する

  • SPARQL: ウェブデータのためのSQL
    • RDFで記述されたデータの汎用クエリ（SPARQL Query Language: 2006年4月に勧告候補）
    • データのウェブから情報を取り出すためにサービスごとのAPIに依存していては限界がある
    • RDFはURIによる語彙とグラフ構造 → グローバルな規模での横断検索が可能
  • SPARQLプロトコルと結果フォーマット
    • クエリのやり取りの方法をRESTなどで定義（SPARQL Protocol: 2006年4月に勧告候補）
    • クエリの結果をXMLやJSONとして取り出す（SPARQL Results XML Format: 2006年4月に勧告候補、SPARQL Results in JSON: 2006年3月にエディタ草案）
    • 共通の方法でどんなRDFデータに対しても検索を実行できる

メタデータがあれば…

フォーマルであるということ

  • XHTMLとクラス属性による形式化
    • 標準XMLツールが利用できる
    • さまざまな自動処理への道を開く
  • フォーマルな名前
    • 取り出したデータの意味・役割を共有できる
    • URIを用いたグローバルな名前ならば、誰が利用しても同じ意味を共有できる
    • microformatsなどのコミュニティ単位の名前は、適当な変換規則を示して共有化する
      • XSLTでURIによる語彙に変換するなど

XHTMLフォーマリズムの課題

  • 主語は何なのか
    • 文書自体が主語になるケース
      • link、meta要素による文書情報
    • 文書の「トピック」が主語になる場合
      • 多くのメタデータは、文書自身ではなくそのトピックが主語になるはず
      • WWW会議の開催地、CSS Niteの開催日とテーマ…
  • 主語を示すためのアプローチ
    • ブロック要素単位で「トピック」を設定する
      • locationクラスを含むパラグラフ、イベント情報を持つtr要素…
      • まだ個別のXSLTや推論規則が必要
    • 汎用的な変換XSLT（例：汎用RDF抽出XSLT）
    • RDFaで提案されているabout属性

フォーマルなインフォーマリズム

  • インフォーマリズムがウェブの強みでもある
    • ソフトウェアのインフォーマリズム（オープンソースを学問する by Walt Scacchi）
      • ソフトウェア工学では、システム開発のための要求仕様を聞き出し、把握することが必要
      • オープンソースのプロジェクトでは、明文化された要求仕様がない代わりに、スレッド化されたEメールによる議論、ソースコードの中にある一連のコメントなどがある
  • ウェブのインフォーマリズムを生かしつつ
    • 無数に存在するインフォーマリズム情報をどうやって共有するか
    • 厳密な（非現実的な？）形式化ではなく、現実的なアプローチで
    • 最小限のフォーマリズムがインフォーマリズムを生かす

参照先