HML5の最初の草案が公開されたが、まともに印刷すると400ページ以上になる分量を読むのはなかなか大変。それなのに仕様は、First, it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections ...なんてことを要求している。まぁそれはともかく、こんな巨大な仕様は、モジュール化するのが吉というのが、HTML4実装の教訓だったんじゃないのかな。適切に設計すれば、「HTML5の○○が気に入らない」という相反する意見も、モジュールの組み合わせでうまく行くかもしれないのに。 さまざまな機器でウェブにアクセスするようになり、またその利用目的もオンライン取引からソー

JSONのデータ記法は、RDF/Turtleで主語を明記しない（空白ノードである）トリプルの書き方によく似ている。多くの人やサービスがデータをJSONの形で提供してくれれば、これをTurtleに変換してRDFとして扱うこともできるだろうし、JSONに馴染んだ人なら、案外Turtleを（そしてRDFを）抵抗なく受け入れられるのではなかろうか、などと考えたりしていた。 Turtleは、RDFのグラフを、XML構文ではなくて、主語、目的語、述語をシンプルに列挙する形で記述する。たとえば、ある学生の学籍番号をURIに仕立てて主語を名前付けし、その名前を目的語/述語で表すRDFトリプルがあるとしよう。 グラフのXML構文は次のようになる（http://example.org/ns/はデフォルト名前空間として宣言されているとする）。 [例1] <rdf:Description rdf:about="h

今どきtagというと流行のfolksonomyのことと思ってしまいそうだが、これは全く別物で、tag:というスキームを用いる新しいURIを定義するもの。近くInformational RFCとなることが告知された。特徴としては、名前解決（リソース取得）を前提としないのでネットワーク上に存在しないものの名前付けに使いやすいこと；時間軸を持っているので、将来にわたって名前の衝突（重複）を回避できること；が挙げられる。 URIは、ブラウザなどでリソースを取得するための「アドレス」としてだけでなく、リソース一般を名前付け（識別）する役割を持つ。しかし、このときhttp:を使うと、そこには何か取得できるリソースがあるように思われやすいため、以前から混乱の要因になっていた。たとえば、名前空間URIにはその文書型のスキーマがあるべきかどうかとか、RDFのリソースはHTTPでアクセスできるのか、など。 t

http:スキームのURIは、ウェブサーバーから取得できるリソースであるべきか、それとも任意のリソースを識別する役割を与えて良いのか―W3CのTAGで議論されてきた難題、いわゆるhttpRange-14に、一応の解決策が示された。URIの示すサーバーが返す結果コードによって、URIのリソースを解釈しようというものだ。 httpRange-14は、バーナーズ＝リーが2002年にHTTP URIs (without "#") should be understood as referring to documents, not carsとしてTAGに提起した（起源はもっと古い）、URIの適用範囲を巡る問題。RDFでは、URI参照（URI＋オプションの#フラグメントID）でリソースを識別するが、「人」や「作者」といったネットワークで取得できないリソースの場合、http:スキームの「URI本体」（

久しぶりにウェブ上の話題を眺めていたら、目に付いたのがページ作者を特定するのにdc.creatorの値としてURIを使うという話。人にURIを与えるのは構わないけれども、その人の「ホームページ」URIとその人自身のURIを混同しそうな気配が垣間見られるのが、若干気になる。 少し考えれば分かることだけれど、人間を名前づけるURIと、その人間が作ったホームページのURIは当然異なる。だから、普通こんな記述はしない。 （誤解を生む例） <rdf:Description rdf:about="http://www.kanzaki.com/memo/2005/07/23-1"> <dc:creator> <foaf:Person rdf:about="http://www.kanzaki.com/"> <foaf:nick>masaka</foaf:nick> </foaf:Person> </dc

RDFのモデルを記述する方法は、グラフ、XML構文などがありますが、第3の扱いやすい記法としてバーナーズ＝リーが示しているのがNotation3です。コンパクトで分かりやすいだけでなく、XML構文では記述が困難な「引用」を表現でき、セマンティック・ウェブのRule、Logicレイヤーを具体的に書き表すことも可能です。 RDFのトリプルとN3：基本フォーマット 匿名ノードと構造化 N-Triples（参考） N3を用いた語彙の定義 フォーミュラとコンテクスト：論理の表現 参照文献 RDFのトリプルとN3：基本フォーマット RDFは、主語、述語、目的語の3つの組（トリプル：triple）を用いてリソースを記述します。たとえば、ある文書でMaestro、conducts、Orchestraという語彙が定義されているとき、「マエストロはオーケストラを指揮する」という関係は、次のようなグラフで記述で

クールなURIとは？ クールなURIとは変わらないもののこと。 どんなURIが変わってしまう？ URIは変わらない：人がそれを変更するのだ。 理屈の上では、人々がURIを変更するべき（もしくはドキュメントのメンテナンスをやめてしまう）理由は全くありません。しかし、現実には山ほど理由があります。 理論上では、ドメイン名空間の所有者はその空間を所有しており、したがってその中に含まれるURIも所有権を持ちます。ドメイン維持料が支払えない場合を除いて、その名前を保有し続けることを妨げるものはありません。そして理論上は、あなたのドメイン名のもとにあるURIは、完全にあなたの管理下にあり、望む限りそれを安定的に保つことができるのです。 ウェブからあるドキュメントが消えてしまう唯一の納得できる理由は、そのドメイン名を保持していた会社が廃業してしまうか、サーバーを維持できなくなったという場合ぐらいでしょう

FOAFはRDF/XMLを使って人々に関する情報（メタデータ）とそのつながりを公開、共有するための半ば実用的、半ば実験（少し遊び）的なプロジェクトです。FOAFを使ってマシンにも扱える自己紹介を記述したり、人や組織、関心領域のネットワーク情報をエージェントに処理させるといった応用が試みられており、RSSとの関連でウェブログなどでも注目され始めています。 FOAFとは FOAFを使った人物情報の記述 知人の記述によるメタデータの連鎖 FOAFの語彙一覧 FOAFと情報の信頼性 FOAFの作成と公開 - まず試してみたい人はこちら 参考文献 ※『RDF/OWL入門』、『セマンティックHTML/XHTML』を上梓しました。 FOAFとは FOAF (Friend of a Friend)とは、その名のとおり友達の友達の友達…という連鎖をメタデータとして表現することで、ネットワーク上の興味深い属性

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"への関心が一般にも高まっていたタイミングで、かなり注目されたものだ。冒頭で、セ

メタデータをコンピュータが理解して有益な情報とするには、その意味が共通の認識となっている語彙が必要です。Dublin Coreは、ウェブや文書の作者、タイトル、作成日といった書誌的な情報をメタデータとして記述するためのボキャブラリを定めています。15の基本要素と、そのRDFによる表現方法、またより精度の高い情報を提供するための拡張語彙について説明します。 DCMES:基本となる15のプロパティ DCMIメタデータ語彙 拡張プロパティ 符号化スキーム タイプ要素 ウェブ文書でのDublin Coreプロパティの利用 RDFでDublin Coreを使う RDFでDC拡張語彙を用いる 外部RDFメタデータをHTML文書にリンクする XHTMLにDCメタデータを直接記述する 参照文献 DCMES:基本となる15のプロパティ DCMI (Dublin Core Metadata Initiativ

ハイパーテキストとリンク - 仕様書に見るHTML(2) 1 WWWとは何か 2 ハイパーリンク 3 リンクとメタ情報 1 WWWとは何か 仕様書の第2章には、HTMLを理解する上での有益な導入が用意されています。いちどこのセクションに目を通して基本を振り返っておくと、仕様書の各部分に示されている考え方がよりよく納得できるようになるでしょう。 1.1 WWWの3つの技術 改めて「WWWって何？」と問われると、なかなか簡単には答えられないと思いませんか？　仕様書では、WWWとは「情報リソースのネットワーク」だとした上で、この情報を可能な限り多くの人に提供するための3つの基本技術をあげています。 A uniform naming scheme for locating resources on the Web (e.g., URIs). Protocols, for access to nam

Atomは、RSSのコンセプトを継承しつつ、シンジケーション/コンテンツ配信を主眼に発展的な新しいフィードのフォーマットを作ろうというプロジェクトで、2005年12月にRFCとなりました。元Echoと呼ばれたこの仕様は、フィードの記述だけでなくAPIなども定めていますが、ここではRSSとの対比でのマークアップのみを説明してみます。 Atomとは何か Atomの基本的なフィードの例 XHTMLマーク付けを含むコンテンツ RDFとAtom 参考資料 Atomとは何か RSSはサイトの要約や見出しを配信するフォーマットとして成長してきましたが、ウェブログなどの普及で、コンテンツそのものを配信するニーズが高まっています。また、RSSには異なるバージョンが存在（対立）したり、RDFのXML構文が若干煩雑だったりというややこしさもありました。 そこで、RSSの考え方は継承しつつ、既存の要素はいったん忘

セマンティック・ウェブを実現する上で大きな鍵になるのが、どうやってメタデータを余計な負荷なしに提供してもらうかという方法論です。XHTMLで構造的な要素タイプ、class属性、id属性を適切に使用していれば、XSLTでここからメタデータを変換・抽出することが可能です。これを共通オントロジーと結びつければ、わざわざコンテンツと別にメタデータを用意しなくても、通常のコンテンツ制作がそのままセマンティック・ウェブの基礎になってくれるのです。 セマンティック・ウェブの関門：メタデータの収集 XSLTとXHTMLのclass属性を活用する a要素を使ったリソースとしての目的語 メタデータ用XSLTの存在を知らせる より汎用的なアプローチ テーブルデータの変換：th要素の内容を使う テーブルでもclass属性を使ってみる head要素からのメタデータ抽出 XHTMLの拡張によるメタデータ埋め込み メタ

セマンティック・ウェブのレイヤーケーキ URI, Unicode, XMLを基盤に ウェブの蓄積をベースにグローバルなデータ（OpenWorld）を扱う マシンが読める形でデータや知識を共有 RDFによるシンプルで柔軟なデータ形式 RDFS 、オントロジーによる語彙と知識の記述 推論規則と論理フレームワーク 述語論理、記述論理を用いた推論、高度な検索 検索結果をエージェントが判断してさらに処理を継続 署名と証明と信頼 エージェントがなぜこの処理をしたかの論理的な証明 電子署名と暗号化によるデータの保証 セマンティック・ウェブ応用のいくつかの側面 「セマンティック・ウェブ」とひと括りにするとすれ違いや誤解が… 高度なリソース探索 全文検索 v.s. メタデータによる検索 最も分かりやすいセマンティックウェブのアプリケーション（出発点） 鶏と卵：誰がメタデータを与えるのか（SW利用の動機付け）

URN (Uniform Resource Name) とはネットワーク上のリソースを、「場所」という概念に依存せず、「名前」によって永続的（persistent）に特定しようという識別子です。リソースを永続的に特定できればそれをURNと呼ぶ広い意味での用法もありますが、IETFで討議されRFC化された意味では、定められた書式に則り、登録された名前空間のもとでそれぞれのルールに従って記述することになっています。 URNの一般概念 URNの構文と登録 登録されているURNのいくつか OASIS空間 公開識別子空間 IETF空間 ISBN空間 永続性に関するノート 永続性にこだわらないinfo:スキーム URIの時間スライスで「永続性」を確保する試み RFC 8141によるURN 参照文献 URNの一般概念 URIの概念を定義している[RFC2396]では、URNは次のように定義されています：

ごく簡単なHTMLの説明：ほかの文書、場所へのリンクで説明しているように、HTMLのハイパーリンクはURL (URI)という仕組みでリンク先を指定します。この記述方法は、ネットワーク上でのサーバーの指定方法と、サーバー内の特定のリソース（ファイルなど）の指定を組み合わせています。 URL : ウェブのアドレス指定方法 ディスクのディレクトリ構造とファイルパス 相対パスによる指定 URLで使用する文字 URIとURL URL : ウェブのアドレス指定方法 ウェブ上のリソースの「所在地」を示す方法としては、URL (Uniform Resource Locator) が用いられます（一般名称のURIについては本稿の最後で説明します）。これはお馴染みの （例） http://www.kanzaki.com/docs/html/htminfo-uri.html という形のものです。このhttp:で

セマンティック・ウェブでエージェントによるデータ活用を実現するには、豊富な語彙をカバーするオントロジーが不可欠です。英語のオントロジーとして提供されているWordNetに、和英辞書を使って日本語を結びつければ、とりあえずエージェントに理解可能な語彙にはなります。URIに日本語を使うことに関する問題はありますが、ひとつの試みとして検討してみます。 日本語メタデータとオントロジー 和英辞書EDICTからWordNetへ 複数の訳語がある場合 直接の訳がない漢字熟語の場合 否定の接頭辞を持つ熟語 日本語の同義語 対応するWordNet定義が見つからない場合 WordNet対応日本語ウェブ・オントロジーの試験 日本語とURI/IRI 参照文献 ※実験的な報告なので、今後内容をかなり書き換える可能性があります。 日本語メタデータとオントロジー セマンティック・ウェブで誰もがメタデータを提供できるよう