URN (Uniform Resource Name) とはネットワーク上のリソースを、「場所」という概念に依存せず、「名前」によって永続的（persistent）に特定しようという識別子です。リソースを永続的に特定できればそれをURNと呼ぶ広い意味での用法もありますが、IETFで討議されRFC化された意味では、定められた書式に則り、登録された名前空間のもとでそれぞれのルールに従って記述することになっています。 URNの一般概念 URNの構文と登録 登録されているURNのいくつか OASIS空間 公開識別子空間 IETF空間 ISBN空間 永続性に関するノート 永続性にこだわらないinfo:スキーム URIの時間スライスで「永続性」を確保する試み RFC 8141によるURN 参照文献 URNの一般概念 URIの概念を定義している[RFC2396]では、URNは次のように定義されています：
先日登場した新しいブックマークサービス Faviki は、ユーザがタグを与えるときに、英語版Wikipediaに登録された語句を候補として提供することで、語彙のゆれ（同義語の問題）を解消しようという特徴を持つ。さらに、タグとWikipediaの連動により、多義語の問題（Operaは歌劇かブラウザか）をも解決する可能性を示す。UIも工夫されており、タグを巡る困難へのひとつの答えともいえる。 タグの共有 以前「タグとオントロジー」で検討したように、タグを広く共有するためには、同義語、多義語の問題を処理する必要がある。アプローチとしては、 従来のタグシステムを前提として、ユーザが自由に与えたタグから、統計的な手法を利用して共通項を見出していく方法と、 ユーザがタグを与える時点で、そのタグを共有可能なもの（統制されたもの）にする方法 が考えられた。Favikiの場合は、後者の立場で、与えられるタグ
W3Cのメンバー提案という形で新OWL作業部会で検討されてきたOWL 1.1の3仕様（構造仕様および関数型構文、モデル理論セマンティクス、RDFグラフへのマッピング）の最初の草案が1月8日付でW3Cから公開された。OWL 1.0との後方互換性を維持しつつ、それ以降の記述論理分野の進展を取り込み、かつOWL 1.0の実装経験から得られた改良が盛り込まれており、関係者の期待は高い。 エンティティの型と名前 OWL 1.0と1.1の大きな違いは、前者は構文からエンティティの型（クラス、オブジェクトプロパティなど）を特定できなかったのに対し、後者は型を明示する構文を導入したこと。たとえば、OWL 1.0で「P rdfs:range X」と記述しても、Pがオブジェクトプロパティなのかデータ型プロパティなのか、Xがクラスなのかデータ型なのかは分からなかったわけだが、OWL 1.1では「P owl11:
This document, http://purl.org/net/ns/metaprof, is a metadata profile for XHTML, as well as an RDDL namespace document for GRDDL transformation. (Note: please use this profile for Well-formed XHTML (not HTML4 etc.) because GRDDL agent will want to try XSLT transformation.) この文書http://purl.org/net/ns/metaprofは、XHTML文書内のメタデータ解釈を定義したプロファイルです。同時に、GRDDLの仕組みを利用して、XHTML文書からXSLTでメタデータ（RDFグラフ）を抽出する機能も備えていま
情報は伝わるか？ そもそも情報は伝わらない… 生命情報：生物が世界と関係することで出現する、意味のある（識別できる）パターン 観察者（主体）が世界をどのように捉えるか（関係）を表すパターン。人によってその関係＝パターンは異なるので、完全には伝えられない。 社会情報：生命情報を人間が（ことばとして）記述する 共同体（国家、コミュニティ…）での共通了解＝意味のとりあえずの固定（規範化作用） 機械情報：言葉の記号作用の「記号表現」だけを取り出したもの コンピュータ、ネットワーク上のデータとして蓄積、交換される （西垣通 『ウェブ社会をどう生きるか』） そこを何とかうまく伝えるためには 明晰な論理と文章 分かりやすい情報のかたち 互いに理解できる名前 情報の伝達と名前 機械情報を介した情報のコード化と再構築 情報が伝わるためには、まず社会情報が適切に再現される必要がある 同じ社会情報でも人によって
XHTMLなどからRDFグラフを抽出するGRDDLがW3C勧告となった。最初の草案が昨年10月下旬に出てから1年未満、GRDDL作業部会が設置された昨年6月から数えても15ヶ月と、最近のW3C規格の中では異例のスピードだ。現在のXHTMLとして完全に妥当な文書にRDF互換データを埋め込むことができ、使い方も分かりやすい。普及することを願うばかりだ。 HTML文書内にRDFメタデータを埋め込むという考えは、最初のRDFが1997年に勧告されたときから話題になっており、さまざまなアイデアが出されてきた。当初はXHTMLの中にRDF/XMLをそのまま記述するにはどうするか、いや、やはり妥当性検証ができないから外部RDF/XML文書にリンクすべきだ、といった議論が続いていたが、「どっちみち人間が読むための文書は作るんだから、そこからマシン用のデータを抽出するのがいいよね」という現実的な考えが出てく
HTML4の仕様書第9章は「Text」と題され、インライン（テキスト）レベルの構造を記述するための要素タイプが取り上げられています。ここは、仕様書を読んだだけでは具体的な用法が理解しにくかったり、あまり合理的とは思えない記述があったりするので、要注意のセクションです。 1 フレーズをハイライトする 2 HTML2以来のフレーズ系要素タイプ 3 HTML3.2とフレーズ系要素タイプ 4 フレーズ系要素タイプの精緻化と問題 5 テキストの編集 1 フレーズをハイライトする body要素内に記述するHTMLの要素タイプには、文章の骨格を示すブロックレベルの要素と、ブロック内の一部をマーク付けするインラインの要素という2つのグループがあります。インライン要素のうち、仕様書の9.2.1で語句（フレーズ）の役割を示すものとして定義されているのが、EM, STRONG, DFN, CODE, SAMP,
日付の表記方法は、文化的な背景の違い、また用途の違いによって様々なフォーマットがあります。多くの場合、特に断り無く使っても問題なく正しい日時を伝えることができますが、文脈や利用者の環境によっては、意外な落とし穴にはまることもあります。誤解なく、かつ効率的に処理しやすい日時表記方法としては、2001-08-02T10:35Zというスタイルの、ISO/W3Cフォーマットがあります。 文化と日付表記 日時表記の国際標準とW3Cノート W3Cの日時フォーマット XML Schemaの日時データ型 タイムスタンプのインターネット標準 そのほか広く用いられる日時の書式 ピリオド区切りによる日付 電子メール、HTTPヘッダなどの日時表記 継続期間の表記 ISO 8601の期間表記 Dublin Coreの期間表記 読みやすさと処理しやすさのバランス 参照文献 文化と日付表記 よく見かける日付の表記法とし
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=...のような「マシン・タグ」との関係を
FlickrがMachine tagsを実装したというアナウンスがあり、某界隈で話題になっている。これは、従来のタグの書式を拡張して、medium:paint=oilという具合に「名前空間:プロパティ=値」というトリプルタグ（！）を用いてより詳細なタグ付けをし、API経由で処理できるようにするというものだ。一見「おぉ、これは」という感じだが、実際のところはどうだろうか。 まず、ここで「名前空間」はmedium:と名前空間URI接頭辞のような形式になっているが、実際はプロパティや値と同じくユーザが任意に与えるラベルになる（後述のようにURIと結びつける方法があるとされているが、怪しげ）。dc:とかfoaf:といったよく使われるものは収斂していく可能性は高いものの、「Machine tags」と呼ぶにはちょっと弱い。が、まぁそこは「タグ」の世界だから、いいことにしよう。 少しまともなプロパティ
タグとは何か del.icio.usのWhat are tags?から ブックマークなどを整理したり後で思い出すために、自分で自由に与える1語の説明 タグは階層がなく自由なので、あてがいぶちの分類に無理に合わせる苦労がなく、扱いやすい ほかの人のタグと合わせて、関心事項についての協調型レポジトリを構築できる 統制されない自由なキーワード 手軽に利用でき、新しい現象もすぐタグにできる 既存の統制語彙では新しい動きに対応できない 一方、多数のユーザが与えるキーワードには、同義語、多義語が必然的に含まれる 体系化のないフラットな空間 階層ではなく、キーワードの組み合わせで詳細概念を柔軟に表現 一方、階層を利用したグループ化や関連概念の検索はできない 統計的なグループや関連付けはある程度可能 タグのかたち 対象、ユーザ、キーワードの3大要素 タグは、タグを与える対象、タグを与えるユーザ、タグに用い
ウェブログなどのシステムでは、誰か別の作者の記事にコメントを付けたということを通知して、一種のコミュニケーションを形成していく「トラックバック」という機能がよく使われます。この仕組みとRSSを組み合わせることで、文書の関連をメタデータとして示すことができるか、DCのような汎用語彙との関係はどうか、少しだけ検討してみます。 RSSのTrackbackモジュール トラックバックと文書間の関連 TrackBack URLと文書の関係 トラックバックの'RSSモード' Dublin Coreによる参照、被参照関係の記述 参照文献 RSSのTrackbackモジュール RSSで利用できるモジュールのひとつとして、トラックバックのPING URIを記述するための仕様が定義されています。[TBMOD] 名前空間宣言 xmlns:trackback="http://madskills.com/public
Scientific American誌の2001年5月号に The Semantic Web が登場してからちょうど5年目のタイミングで、IEEE Intelligent Systems誌に The Semantic Web Revisited が掲載され、話題になっている。こちらもバーナーズ=リーが執筆陣に加わっており、現時点でのセマンティック・ウェブの総括といえる内容だ。 記事抄録を訳して紹介しておこう。 サイエンティフィック・アメリカンに最初のセマンティック・ウェブの記事が登場したのは2001年のこと。そこでは、主として人間が読むための文書で構成されれているウェブから、コンピュータが処理できるデータや情報を含むウェブへの発展が語られていた。セマンティック・ウェブとは、作動可能な（actionable）情報、すなわちシンボルを解釈するための意味理論を通じてデータから取り出された情報の
What Is RDFという、xml.comに8年前から掲載されている記事がある。Tim Brayによるオリジナル版のあとで2001年にDan Brickleyによる改訂版が出て、またまた今回Joshua Taubererによる再改訂版が登場した。RDFの現在の位置づけやセマンティック・ウェブとの関連を踏まえて新たに書き下ろしたものだが、新改訂版を以前からあるURLで公開し、旧版を別のURLに移動しているのが面白い。 旧版ではRDFを「メタデータを記述してウェブでの検索を高度にするもの」という形で捉えていたが、最新版ではどういう紹介になっているのか、かいつまんで見ていくことにしよう。まず導入部分。 セマンティック・ウェブ（以下SW）では、コンピュータが私達のためにブラウジング（それに探索や照会など…）を行ってくれる。SWは、コンピュータがウェブ上に分散している知識を探し出し、それをかみ合わ
3月末にアナウンスされていたJSON仕様のRFCが、RFC 4627 The application/json Media Type for JavaScript Object Notation (JSON)として公開された。メディアタイプは表題の通りapplication/jsonで、標準ファイル拡張子は.jsonとなっている（拡張子の話は前回書き忘れた）。一部のミス修正以外は最終I-Dとほぼ同じ内容でRFCとなった。 XMLHttpRequestでの処理にはメディアタイプはあまり関係ないが、ブラウザで直接ファイルを開こうとするとapplication/jsonの場合はダウンロードが始まってしまう（Opera9では「XMLの解析に失敗しました」となる…？？）。実用には支障ないものの、手軽にデータを確認できないのは残念なところ。.jsonにapplication/jsonをマッピングするか
バーナーズ＝リーが18日のアメリカ人工知能学会の基調講演を行ったときに、Googleの検索担当ディレクタのPeter Norvigが疑問を投げかけたという話がZDNetで取り上げられている（Google exec challenges Berners-Lee）。内容は特に目新しくはないのだが、Googleという立場でセマンティック・ウェブの課題に対する考えが述べられているのは、興味深いところ。 基調講演でバーナーズ＝リーは、永続的なURIとRDFで情報を識別することの重要性を強調し、これらの仕様を一貫して用いることで、ウェブが本来目指していた協調的な性質をセマンティック・ウェブが獲得できるのだという持論を展開する。その講演後のQAセッションで、最初にマイクを握ったのがNorvigだったというわけだ。 Norvigは、セマンティック・ウェブに反対するわけではないが、Googleの視点からする
検索の手順：何をコンピュータに任せられるか どこに情報があるか データベース検索 → DB推薦？ 一括検索？ 文書検索 → 文書からデータを取り出すには 何をどう検索するか 適切な検索語句 → シソーラスや検索候補 適切な検索式 → フリーキーワード v.s. 多項目検索 結果をどう利用するか 検索結果を見る → より分かりやすいプレゼンテーション 結果を評価・判断する → ページランク、適合度、信頼度評価 継続検索 → 検索式の自動補正、絞込み 次のアクション → 別のサービスへの自動接続、結果からの推論 文書の検索と情報の検索 情報を知るためには 情報が記述されている文書（書籍、ウェブページ）を検索して内容を読む 情報を（あらかじめ整備されたデータベースなどで）直接調べる 文書の中の情報が検索できたら？ 人間に代わってコンピュータが文書内から情報を取り出してくれたら？ 2006年5月の
ダブリン・コアをRDFで使う時のモデルを定めるExpressing Dublin Core metadata using RDFの草案が公開されている。注目すべきは、いくつかのケースを除いて、プロパティ値（目的語）としてリテラルが認められなくなっているところ。具体的に言えば、<dc:creator>神崎正英</dc:creator> という記述は不可で、目的語は<foaf:Person>などのエンティティにしなければならなくなる。RSSをはじめとする現在のRDFデータにかなり大きな影響が出るのは必至だ。 例外としてリテラルを目的語にできるのは、大まかにまとめると (1)値となるのが一つの文字列だけ；(2)そのEncoding Scheme（クラスに相当）がデータ型もしくはrdfs:Literal；(3)RDFのリテラルとして矛盾無く記述できる（たとえばデータ型と言語タグの両方を持っていたり
JSONの文法などについて、今年の2月1月からインターネットドラフト（I-D）が出されているが、はやくもInformational RFCとすることが決まった（I-Dは現在04版draft-crockford-jsonorg-json-04.txt）。MIMEタイプはapplication/jsonとされている。 このI-D/RFCは、JSONの構文とMIMEタイプをオフィシャルな形で定義しようというもので、内容は基本的には既に知られている文法と違いはない。大まかに言えば、次のようなことが書かれている。 JSONは4つの基本型（string, number, boolean, null）と、2つの構造型（object, array）で表現される。 objectは、名前:値 の組の順不同のコレクションで、これらの組を , で区切り、{ と } で囲む。名前はstringで、値は上記6つの型の
RDBMSとRDFをマップすれば、両者の特徴を生かした「セマンティック・ウェブ的な応用」への道が開ける。しかし、RDFの背後にあるデータベースには、外部から直接SQLで問い合わせを行うことができない。ここをカバーするのがRDFのクエリ言語であるSPARQLだ。これは、"Web 2.0アプリケーション"にとってもキーになる可能性がある。少し古い記事だが、Kendall ClarkによるSPARQL: Web 2.0 Meet the Semantic Web を取り上げてみよう。 これは、SPARQLプロトコルの3回目の草案が出たことを受けて、2005年9月16日に書かれたO'Reilly Developer Weblogsの記事。10月の「Web 2.0 Conference 2005」を前に、"Web 2.0"への関心が一般にも高まっていたタイミングで、かなり注目されたものだ。冒頭で、セ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く