RDFとメタデータの相互運用
（メタ）データ相互運用の課題 データモデルと名前の相互運用 どんなモデル（データ構造、スキーマ）を採用するか プロパティ（関係記述語彙）はどの程度詳細に設計すべきか、独自語彙か汎用語彙か 人物などの典拠、主題などの語彙（ノードの名前）をどうやって共有するか 記述対象をどのように識別するか（リソースの同一性） （※本稿では、最初の2つ、モデルとプロパティについて検討します） 相互運用のスコープ データの共有：統合レポジトリの構築や横断検索の実現 データの交換：AのデータをBが取り込みたいとき データ相互運用とRDF/OWL なぜRDF/OWLか 柔軟性：シンプルで柔軟なグラフ構造でさまざまなモデルを表現できる 意味論：グラフの意味論が定義されており、予備知識のないデータも共通の解釈ができる 語彙の連携：語彙間の関係を記述することができ、その関係を利用した基本的な推論ができる 識別と統合：UR
ちょっとしたメモ - Tim Brayのurn:tag:スキーム案
Tim Brayが2月1日の記事「Tag Scheme?」で、URNのNIDとして"tag"を導入し、urn:tag:というスキームで「タグ」を識別するというアイデアを示した。これを受けて、コメント欄などでちょっとした議論が展開されている。もともとはAtomフィードのcategory要素のscheme属性のために使おうというものだったようだが、タグ文字列がそのままURIに対応することになるので、面白いと同時に危うい面も併せ持つURNだ。 コメント欄に出ている意見は、概ね次のような感じ。 わざわざ新しいURNを登録しなくても、http:で同じことができる、あるいはURNでは参照を辿れないからhttp:の方がよい。 タグあるいはカテゴリを一意に示すには、WikipediaのページURIを利用すればよいではないか。 タグをURIで表すとき、geo:lat=...のような「マシン・タグ」との関係を
タグとオントロジー
タグとは何か del.icio.usのWhat are tags?から ブックマークなどを整理したり後で思い出すために、自分で自由に与える1語の説明 タグは階層がなく自由なので、あてがいぶちの分類に無理に合わせる苦労がなく、扱いやすい ほかの人のタグと合わせて、関心事項についての協調型レポジトリを構築できる 統制されない自由なキーワード 手軽に利用でき、新しい現象もすぐタグにできる 既存の統制語彙では新しい動きに対応できない 一方、多数のユーザが与えるキーワードには、同義語、多義語が必然的に含まれる 体系化のないフラットな空間 階層ではなく、キーワードの組み合わせで詳細概念を柔軟に表現 一方、階層を利用したグループ化や関連概念の検索はできない 統計的なグループや関連付けはある程度可能 タグのかたち 対象、ユーザ、キーワードの3大要素 タグは、タグを与える対象、タグを与えるユーザ、タグに用い
ちょっとしたメモ - IE7、Firefox2でもRSS1.0にXSLTを適用させる
IE7やFirefox2は、「フィード」をMIMEタイプで判別できないときは、コンテンツの先頭部分のテキストマッチで判断して「フィードプレビュー」を起動しているらしい。判定用の文字列パターンをRSSファイルで直接用いないようにしたら、確かにどちらのブラウザもプレビューではなくてXSLTを適用するようになった。ただし、一般のフィードリーダーの中にも同じような文字列マッチを使っているものがある模様で、方法によってはこれらのフィードリーダーでも修正版RSSを読めなくなってしまうので注意が必要だ。 Microsoft Team RSS BlogのWindows RSS Publisher's Guideによれば、MIMEタイプがapplication/xmlもしくはtext/xmlであるときは、IE7はコンテンツ冒頭の512バイトを読んで、その中に次の3つの文字列があればRSS1.0と判定するのだ
ちょっとしたメモ - Dublin CoreのRDFモデル新仕様案
ダブリン・コアをRDFで使う時のモデルを定めるExpressing Dublin Core metadata using RDFの草案が公開されている。注目すべきは、いくつかのケースを除いて、プロパティ値（目的語）としてリテラルが認められなくなっているところ。具体的に言えば、<dc:creator>神崎正英</dc:creator> という記述は不可で、目的語は<foaf:Person>などのエンティティにしなければならなくなる。RSSをはじめとする現在のRDFデータにかなり大きな影響が出るのは必至だ。 例外としてリテラルを目的語にできるのは、大まかにまとめると (1)値となるのが一つの文字列だけ；(2)そのEncoding Scheme（クラスに相当）がデータ型もしくはrdfs:Literal；(3)RDFのリテラルとして矛盾無く記述できる（たとえばデータ型と言語タグの両方を持っていたり
ちょっとしたメモ - 署名区切り行：sig-dashes
電子メールの末尾に区切り行"-- "を置くと、それ以降を署名とみなすのは、Usenetから受け継いだ伝統。よくできたソフトはこれを認識して署名部分をグレイ表示してくれたりする。パーソナル署名にちょっと仕掛けをしようと思っていろいろ実験をしていたら、これを返信にも賢く利用するメールソフトがあることに気がついた。 この署名のしきたりについて記述された文書としては、RFC 3676（RFC 2646の更新版）のセクション4.3. 'Usenet Signature Convention' がよく知られている。 There is a long-standing convention in Usenet news which also commonly appears in Internet mail of using "-- " as the separator line between the
ちょっとしたメモ - 困ったちゃんのprofile属性
「小文字のsemantic web」やGRDDLを検討していくと、忘れられかけていたhead要素のprofile属性の役割に期待が集まったりするのだが、もういちど仕様を確認して、その使えなさに改めてがっかりするわけだ。仕様書の定義には矛盾があり、具体的な使い方は実装依存で、複数のプロファイルを併用するのは想定外と来ている。まぁ仕方ないか。どれかひとつのプロファイルを記述するとすれば、やはりGRDDLということになるだろう。 今更ながらHTML4仕様書 7.4.1のprofile属性定義を引用してみる。 profile = uri [CT] This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user
ちょっとしたメモ - RDFとRDBMSの共存関係
昨日取り上げた getting the semweb exactly wrong スレッドの中で、RDBMSとRDFの長所や短所、使い分けといった話題が出て、「両者をマッピングするのが一つの方法」とバーナーズ＝リーが答えている。RDFの導入を検討するときに、既存のデータベースをどうすればいいかというのは、よく聞かれる質問だ。 以下は、Jan Algermissenが「RDF+OWLを使うほうが、RDBMSよりもうまく行く問題とはどんなものだろう。つまり、RDBMSをやめてRDFストアを使うキラー要因は何だろうか？」と問いかけたことに対する、バーナーズ＝リーの返信（1月4日付）から。 一つの答えは：（RDBMSをやめてRDFストアを使うということは）しないこと！ セマンティック・ウェブは、データをそれが意味するものに結びつける（conecting the data to what it me
ちょっとしたメモ - セマンティック・ウェブ、あるいはルーズさを生かした構造
Tim Falconerが1月2日に書いた getting the semweb exactly wrong というウェブログの記事と、それを紹介するsemantic-web-mlへの投稿をきっかけに、新年早々メールボックスが騒々しくなっている。似たような話を毎度繰り返すのも疲れるのだが、今回はバーナーズ＝リー親分もスレッドに参加してきているので、簡単に紹介しておこう。 Falconerの記事は、おおざっぱにいうとこんな内容だ。 セマンティック・ウェブについては、手の込んだ三段論法だとか、メタデータを標準化/正規化（normalize）、中央集権化してアプリケーション処理しやすくする一方でウェブの自由度を失うもの、といった批判があるが、本来は逆で、セマンティック・ウェブのアプローチは極めて「ルーズな」もの。RDFやOWLのいいところは、全然互換性のないデータをうまくつなぎ合わせて、構造を与
RDFとセマンティック・ウェブの現在
セマンティック・ウェブのレイヤーケーキ URI, Unicode, XMLを基盤に ウェブの蓄積をベースにグローバルなデータ（OpenWorld）を扱う マシンが読める形でデータや知識を共有 RDFによるシンプルで柔軟なデータ形式 RDFS 、オントロジーによる語彙と知識の記述 推論規則と論理フレームワーク 述語論理、記述論理を用いた推論、高度な検索 検索結果をエージェントが判断してさらに処理を継続 署名と証明と信頼 エージェントがなぜこの処理をしたかの論理的な証明 電子署名と暗号化によるデータの保証 セマンティック・ウェブ応用のいくつかの側面 「セマンティック・ウェブ」とひと括りにするとすれ違いや誤解が… 高度なリソース探索 全文検索 v.s. メタデータによる検索 最も分かりやすいセマンティックウェブのアプリケーション（出発点） 鶏と卵：誰がメタデータを与えるのか（SW利用の動機付け）
オンライン・ハイパーテキストのためのスタイルガイド
Style Guide for online hypertext オンライン・ハイパーテキストのためのスタイルガイド ©Tim BL 1992,93,94,95 All rights reserved. Translated by M. Kanzaki. See notes. 原文はhttp://www.w3.org/Provider/Style/を参照。 このガイドは、効果的にあなたの知識を読者に伝えることができるWWW ハイパーテキスト・データベースの作成を支援するために構想されました。 これは、読者のコメントと多くのオンラインドキュメントの提供者の要望に基づいて準備されてきたものです。部分的に個人の嗜好やあるいは一般常識のようなものに影響されていることろもありますが、論点全体としては待ち望まれてきたものなので、ここに提供することにしました。 このガイドは順を追って読むように構成されて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RAPによるRDF/XMLのチェックと視覚化