ウェブの目標である「マシンに理解可能な情報」の表現のためには、メタデータなどのリソース相互の関係を、特定のアプリケーションに依存しない形で叙述的に示す共通の方法が必要です。RDFは、主語（リソース）と述語（プロパティ）、そしてその目的語（オブジェクト：プロパティの値）の三者関係によって、関係の連鎖を辿ることができるようなデータモデルを記述します。 マシンに理解可能な情報の記述 RDFの基本データモデルとXML構文 シンプルなRDFモデルとグラフ 基本データモデルを表現するXML構文 コンテナモデル 具体化：文についての文 とりあえずのまとめ 本稿で取り上げなかったこと 参照文献 ※体系的な解説『RDF/OWL入門』を上梓しました。 マシンに理解可能な情報の記述 バーナーズ・リーが描いていたウェブの目標は、「コンピュータで読みとれる形の情報の空間が、人々の思考、やり取り、仕事のパターンの状態

メタデータをコンピュータが理解して有益な情報とするには、その意味が共通の認識となっている語彙が必要です。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

コンピュータは主にアメリカで発達してきたため、未だにアルファベットや数字などの1バイト（7/8ビット）を基本単位として扱う前提で作られているものが中心です。そのなかで日本語のように多くの文字を必要とする言語は、1文字を表わすのに2バイト以上を要するため、いろいろな困難が伴います。特にインターネットを通じて様々な環境の情報を交換するにあたって、思わぬ問題に遭遇するケースが増えてきました。ここでは、こうしたことを考えるために必要な、日本語の文字コードに関する基本を整理しておきます。 JIS漢字コード（情報交換用符号化漢字集合） 区点コード JISコード（符号化方式） シフトJISコード EUCコード ASCIIとJISローマ字 Unicode 主要コード規格のまとめ 参考文献、リソース 文字化けしたメールの復元 | The Web KANZAKI ホームページ JIS漢字コード（情報交換用符号

検索、オンラインショップ、掲示板投稿など、インタラクティブなウェブのためにフォームは欠かせません。利用者がデータを入力してサーバーに送るというこの機能については、WWWの初期からさまざまな意見が出され、現在も改良が続けられてます。 1 WWW初期のインタラクション 2 フォームとコントロール 3 フォームデータの送信 4 より高度で利用しやすいフォームへ 1 WWW初期のインタラクション 1.1 サーチインデックスと問い合わせURI 初期のWWWにはフォームという概念はありませんでしたが、必要な情報を探すために利用者が「問い合わせ」を行う仕組みは用意されていました。この一種の検索ゲートウェイは「インデックス」と呼ばれ、問い合わせのためには、インデックスのURIにキーワードを '?' でつなぐという方法が採られました。キーワードは '+' で連結して複数指定することもできます。バーナーズ＝リ

テーブルや画像、マルチメディアは現在のウェブづくりには欠かせない手段ですが、これらがHTMLに取り入れられたのは比較的最近です。実装状況にばらつきがあったりして正確な用法がいまひとつ分かりにくいこれらの要素タイプを、導入の背景も含めて少し詳しく紹介してみましょう。 1 HTMLのテーブルモデル 2 インライン画像を扱うimg要素 3 さまざまなオブジェクトを扱うobject要素 1 HTMLのテーブルモデル 1.1 初期のHTMLとテーブル WWWが誕生してからしばらくの間、HTMLにはテーブルは存在せず、データを「表」の形で示したいときには、pre要素などを利用して、空白文字でテキストを揃えるという方法が採られていました。テーブルモデルをHTMLに導入する試みは、初期のHTML拡張であるHTML+に遡ります。 This specification provides a superset

HTML4の仕様書第9章は「Text」と題され、インライン（テキスト）レベルの構造を記述するための要素タイプが取り上げられています。ここは、仕様書を読んだだけでは具体的な用法が理解しにくかったり、あまり合理的とは思えない記述があったりするので、要注意のセクションです。 1 フレーズをハイライトする 2 HTML2以来のフレーズ系要素タイプ 3 HTML3.2とフレーズ系要素タイプ 4 フレーズ系要素タイプの精緻化と問題 5 テキストの編集 1 フレーズをハイライトする body要素内に記述するHTMLの要素タイプには、文章の骨格を示すブロックレベルの要素と、ブロック内の一部をマーク付けするインラインの要素という2つのグループがあります。インライン要素のうち、仕様書の9.2.1で語句（フレーズ）の役割を示すものとして定義されているのが、EM, STRONG, DFN, CODE, SAMP,

ハイパーテキストとリンク - 仕様書に見る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

3.3 属性リスト宣言と実体宣言 また、DTDでは要素タイプがどんな属性を持つのかも定義します。属性は、<!ATTLIST で始まる宣言文で、属性名、属性値のタイプ、省略時の扱いについて定義します。 さらにDTDでは、さまざまな名前や値の別名を定義しておき、個々の宣言ではこの別名を使うのが普通です。この別名の定義を実体宣言といい、<!ENTITY で始まる宣言で定義しています。 仕様書の3.3ではこれらについても詳しく説明されています。それほど複雑ではないので、できればひととおり目を通して、DTDの読み方を身につけておきましょう。 4 HTML文書の構造 では、HTML4の仕様書のさまざまな要素タイプの定義の中から、注目しておきたい部分を拾い読みしていきます。HTMLを書くときに、「ここはどうなっているんだろう」と疑問に思うような点の多くは、実は仕様書できちんと解説されているものなのです。

WWWの誕生から「ブラウザ戦争」に至る流れ（1989年〜2001年）の中で登場した様々なブラウザの足跡を辿ってみます。『Web Designing』誌2001年12月号に寄稿した記事をほぼそのまま再掲載するものです（年表はかなり追加調査しています）。 WorldWideWebの誕生 CERNの外で 多様なブラウザの登場 Mosaicから商用ブラウザへ ブラウザ戦争、そして標準化への道 ブラウザ関連年表 WorldWideWebの誕生 1989年3月、ティム・バーナーズ＝リーは Information Management: A Proposalと題するペーパーをCERNの関係者に配布した。ウェブの歴史の第一歩が、静かに踏み出されたのだ。 この提案を目に見える形にするためのハイパーテキスト処理プログラム、すなわち最初のウェブ・ブラウザは、翌1990年のクリスマスまでには完成する。 バーナーズ

日付の表記方法は、文化的な背景の違い、また用途の違いによって様々なフォーマットがあります。多くの場合、特に断り無く使っても問題なく正しい日時を伝えることができますが、文脈や利用者の環境によっては、意外な落とし穴にはまることもあります。誤解なく、かつ効率的に処理しやすい日時表記方法としては、2001-08-02T10:35Zというスタイルの、ISO/W3Cフォーマットがあります。 文化と日付表記 日時表記の国際標準とW3Cノート W3Cの日時フォーマット XML Schemaの日時データ型 タイムスタンプのインターネット標準 そのほか広く用いられる日時の書式 ピリオド区切りによる日付 電子メール、HTTPヘッダなどの日時表記 継続期間の表記 ISO 8601の期間表記 Dublin Coreの期間表記 読みやすさと処理しやすさのバランス 参照文献 文化と日付表記 よく見かける日付の表記法とし

HTMLは本来簡単で便利なものです。「30分間HTML入門」で基本は十分。まずシンプルに自分の情報を表現してみてください。 You can write a document as simple as you like. In many ways, the simpler the better. -- Tim Berners-Lee 簡単なHTMLの説明 少し詳しいHTMLの説明 XHTMLから次世代ウェブへ 電子テキストで情報発信 簡単なHTMLの説明 だんだん説明の量が増えてきたので、コンパクトな入門ページを用意しました。 基本がきちんと分かる30分間(X)HTML入門 HTMLを使った人間・コンピュータ双方にわかりやすい表現 （スライドのHTML版） 何のためのHTML？ HTMLは画面をレイアウトするためではなく、文書を環境に依存せずに共有できるように記述するための約束です。そこを正

所有者識別子 (OwnerID) 公開文書の所有者を示します。ISO（国際標準化機構）出版物*はその出版物番号を用います。JISなどの国家規格あるいは工業規格もしくはISO 9070に従って割り当てた所有者（登録所有者）の場合は先頭に+//を、それ以外の未登録所有者は先頭に-//を加えます。W3CはこのHTMLを策定したWorld Wide Web Consortiumを示します（HTML2.0だとIETFになります）。 公開文種別 (Public Text Class) 公開されている文書の内容を示します。この場合はDTDを公開しているわけです。必ず大文字でなければなりません。 公開文記述 (Public Text Description) 公開文書がどんなものであるかを記述します。この場合はHTMLのバージョン4.01のために公開している文書ということになります。 公開文言語 (Pub

XMLでは自由に独自のマークアップ言語（タグセット）を設計できますが、ウェブ上で情報を共有するときに、同じタグ名が異なる要素タイプを意味して衝突してしまう可能性があります。この問題を解決するためにXML名前空間は、それぞれのタグセットに固有のURIを割り当て、名前をURIで修飾することでお互いを区別します。名前空間は、ウェブ上で「意味」を明確に定義し、相互理解を可能にするために非常に重要な役割を果たします。 名前空間の導入 名前空間URIによる修飾と接頭辞 デフォルト名前空間 名前空間URIの意味するところ 名前空間の区画と属性の名前空間 参照文献 名前空間の導入 XMLでは独自のマークアップ言語（語彙）を自由に設計できますが、多くの人が利用する語彙は、標準的な語彙を共有する方が効率が良く、相互運用性も高まります。そこで、ひとつのXML文書を作成するのに、さまざまなマークアップ言語から語彙

例えば、辞書型定義リストDLの場合は <!ELEMENT DL - - (DT|DD)+> となっていますが、これは開始タグ、終了タグとも必須で、内容としてはDTもしくはDDが1回以上出現しなければならないということを意味しています。 例外についての注意 +(E)という書き方は、要素（群）Eは内容モデルの「例外」として出現して良いことを示します。この例外は「その要素の実現値の中の全ての場所に適用する」とされ、その子孫にわたって内容モデルにかかわらず出現して良いという意味になります。これは結果的にDTDの読み方を少し難しくしているので注意が必要です。例えばBODY要素タイプの定義を見てみましょう。 <!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) > BODY要素の内容にはブロックレベル要素（%block;）もしくはSCRIPT要素が1回以上出現

巨大なグローバル・グラフ 関心があるものを結びつけるネットワーク インターネット：コンピュータを結びつける巨大なネット 関心があるのはコンピュータどうしのつながりであって、それがどんなケーブルや通信手段を使っているかじゃないんだ ウェブ：文書を結びつける巨大なネット 関心があるのは文書であって、それがどんなコンピュータや端末にあるかじゃないんだ 次は？：ものごとを結びつける巨大なネット 関心があるのは「ものごと」であって、それがどんな文書に書かれているかじゃないんだ 社会グラフとしてのつながり 関心があるのは仕組み（ネットワーク）ではなくものごととそのつながり（グラフ） 人々がどうつながっているか、どんな記事を書いているか、何を読んだり聴いたりしたか… このつながり＝グラフ＝を、文書のレベルではなく、共有・再利用可能な形で記述するもの：セマンティック・ウェブ バーナーズ＝リーの言うGian

国立国会図書館関西館を訪問して、電子図書館課の方々と懇談をする機会をいただいた。情報を電子化する現場の話には興味深い点がたくさんあったのだが、中でも書籍（書誌）のIDとして、全国書誌番号を用いてISBNに代わる（もしくは補完する）識別子を考える可能性は、掘り下げて取り組んでみる必要がありそうなテーマだ。 最近FOAF-IRC(#foaf)でも少し話題になっていたが、ISBNは永続的な識別子として使うには若干問題がある。この10桁のコードは、上位桁の番号が出版社に割り当てられ、下位桁の番号は出版社が独自で付与するという仕組みだ（最初の1桁は国/地域、最後の一桁はチェックサムなので、実質的には国内でわずか8桁）。使える桁数は出版社ごとに異なるのだが、たとえば4桁の自社番号領域を持つ出版社は、1万点の書籍を発刊すると番号が足りなくなってしまう（補足：必要に応じて出版社番号が追加割り当てされる）。