先日登場した新しいブックマークサービス Faviki は、ユーザがタグを与えるときに、英語版Wikipediaに登録された語句を候補として提供することで、語彙のゆれ（同義語の問題）を解消しようという特徴を持つ。さらに、タグとWikipediaの連動により、多義語の問題（Operaは歌劇かブラウザか）をも解決する可能性を示す。UIも工夫されており、タグを巡る困難へのひとつの答えともいえる。 タグの共有 以前「タグとオントロジー」で検討したように、タグを広く共有するためには、同義語、多義語の問題を処理する必要がある。アプローチとしては、 従来のタグシステムを前提として、ユーザが自由に与えたタグから、統計的な手法を利用して共通項を見出していく方法と、 ユーザがタグを与える時点で、そのタグを共有可能なもの（統制されたもの）にする方法 が考えられた。Favikiの場合は、後者の立場で、与えられるタグ

alt要素なんて、もちろん今の仕様には存在しないわけだけれど、それらしきものが検討された様子がある…という話を、何かのページの一部に書いたような気がするのだが、消してしまったみたいなので、思い出しながら書き記しておこう。検討の痕跡が残っているのは、XHTMLモジュール化仕様のDTD実装ページだ。 このページのF.2.5. XHTML Qualified NamesのセクションBは、「XHTMLの全要素型の名前空間修飾名を提供するためのパラメータ実体を宣言する」とされている。つまり、このセクションでxxx.qnameという形の定義があれば、xxxはXHTMLの要素型名として用いられる（と想定されている）ことをあらわす。このセクションの最後には、次のような記述がある。 <!-- Provisional XHTML 2.0 Qualified Names ....................

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

"Web 2.0"やmicroformatに関心がある人は、昨日xml.comで公開されたUche Ogbujiの記事 Microformats in Context をぜひ読んでおこう。ここでは、microformatの可能性と限界、そしてその次のステップが、XMLの本質に照らして鮮明に描かれている。microformatは「インフォーマルな文脈における小さな島（コミュニティ）をうまくまとめる方向に目を向けている」が、それらの小さな島をつなぎ、集約するためには、もう少し先に進む必要がある。 Ucheの論点を大まかに列挙すると、次のようになる： microformatは新しい語彙を作るのではなくて、既存のよく普及したフォーマット（XHTML）を利用して情報を表現しようとするものだが、多くの場合、XHTMLの語彙の意味を拡大解釈し過ぎて、混乱を生む。 複数のmicroformatの間で語彙が

XHTML Media TypesがW3C Noteとして発行されて5年以上になるというのに、XHTML 1.0文書をずっとtext/htmlとして提供してきたわけだが、このほどAcceptヘッダにapplication/xhtml+xmlが含まれる場合はこのMIMEタイプでリソースを送る設定に変更した。最近のいろいろな試行を通じて、この必要性がかなりはっきり見えてきたからだ。 application/xhtml+xmlその理由 文書が整形式XMLになっていさえすれば、メディアタイプに関係なくXSLTなどのツールは利用できる。それに加えて、IE問題回避のために小細工する必然性が見出せなかったこともあり、このサイトではtext/htmlを使い続けてきた（その代わり整形式の重要性を一所懸命、訴えていた）。ここにきてそれが翻ったのは、この2～3ヶ月ほど繰り返していたLinked Dataの試行を

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 ハイパーテキスト・データベースの作成を支援するために構想されました。 これは、読者のコメントと多くのオンラインドキュメントの提供者の要望に基づいて準備されてきたものです。部分的に個人の嗜好やあるいは一般常識のようなものに影響されていることろもありますが、論点全体としては待ち望まれてきたものなので、ここに提供することにしました。 このガイドは順を追って読むように構成されて

誰にも読みやすいコンテンツとするためには、文字色と背景色のコントラストをしっかり確保しなければなりません。これを客観的にチェックするため、色の明るさの差などを計算する仕組みを用意してみました。 色の組み合わせ検証 テストの手法 コントラストの計算 色覚偏位のシミュレーション 当サイトが独自に加えたコントラストの段階評価 コントラストと読みやすさの相関関係 色の組み合わせ検証 検証してみたい文字色と背景色の組み合わせを入力してみてください。色の指定には3桁もしくは6桁の16進数カラーコード、あるいは色名（CSS2の色名＋SVGの色名、計147色）およびrgb()の表現が使えます（初期値は、読みにくい例が入っています）。また、入力欄左ボックスから216色のパレットを呼び出して入力することもできます。文字色2、3は、複数の文字色の組み合わせを表示するためのオプションで、コントラストなどの計算は行

CSS2.1がようやく（再度）勧告候補にこぎつけた。今度こそは草案差し戻しなどということなく進んでいくだろうが、テストケースや実装確認もあるので、年内はCRに留め置くということだ。このCSS2.1は、PDF版で405ページ。1998年のCSS2勧告は338ページだから、単純に分量だけでも2割増で、記述の修正なども含めると、実はかなり大きな違いがある。バグ修正やブラウザの実装に合わせただけのものではなく、よりモデルを厳密に定義したり詳しく説明しているので、CSSに関心がある人は、そろそろ2.1の内容を確認しておくのがよいかも。 今回の勧告候補は、昨年11月の草案をおおむね引き継いでおり、かなり安定しているといえるが、多少の修正や明確化もある。11月草案との違いが検討事項リストの形で示されているので、主なものを確認しておこう（以下、項目名の数字は検討事項番号、リンク先は検討事項リストの対応する

「名前のウェブとXHTML文書のプロファイル」をお話したとき、「ウェブログサービスなどでhead要素に手を加えることができない場合、body内部でプロファイル指定（あるいはGRDDL呼び出し）をする方法はないのか」という質問をいただきました。その場では即答できず、宿題ということにさせていただいたので、GRDDL仕様の検討事項（issues）での状況と、他の規格を組み合わせる可能性について報告しておきます。一言でいうと、「GRDDLではその必要性は提起されているが、結論は先送り。“リソース群”についての記述を利用すれば可能かも」というところです。 GRDDLのissue-tx-elementと題された検討事項では、ちょうど上記の質問と同様に、「XHTMLの一部だけを編集できる環境でクリエイティブ・コモンズ・ライセンスをa要素に記述するとき、rel属性値はどうすればよいのか」という疑問から出発

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は画面をレイアウトするためではなく、文書を環境に依存せずに共有できるように記述するための約束です。そこを正

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

RSSの構文は簡単ですが、更新情報などを毎回別途RSSとして記述するのは億劫です。簡単なスクリプトで、RSSを自動生成しましょう。 以下のPerlスクリプトは、更新情報のページが定義型リスト（dl,dt,dd）で記述され、dt要素の中に新着ページへのリンクが記述されているという例を想定しています。ご自身のスタイルに合わせて、適宜書き換えて利用してください。 （例） $item_title = "dt"; #タイトルとリンクを抜き出す要素 $item_descr = "dd"; #説明文を抜き出す要素 $host = "http://your.domain"; #ソースからタイトル、リンク、説明文を抽出 while(<>){ if(m|<${item_title}.*?><a href="(.*?)">(.*?)</a>|){ $link[++$items] = $1; $items_lis

昨年10月のバーナーズ＝リーのびっくり発言から約4カ月を経て、W3Cに新しいHTML作業部会が設置された。HTML4とXHTML1をベースに、新しい(X)HTML仕様を2010年を目標に策定していく。従来のHTML作業部会はXHTML2作業部会という扱いになる（HTMLとは違う狙いなので、名前を変えることも検討しているそうだ。そりゃ大いに結構）。 Charter（設立趣意書）によれば、この新作業部会は次のものを策定していく。 HTML4を発展させた、ウェブの文書とアプリケーションのセマンティクスを表現する言語 この言語をXMLによって記述（シリアル化）する拡張可能な形態 既存ブラウザの「クラシックHTML」パーサと互換性のある、XMLではない記述形態 この言語のためのDOMインターフェイス フォームその他のUIで用いるための、プログレッシブバー、メニューなどの共通部品 リンクづけられたメデ

HTML文書においてはimg要素を使ってインライン画像を表示することができますが、Lynxのようなテキストブラウザや画像表示をOFFにしている利用者のためにはalt属性によって画像の代わりとなる代替文字列を用意することができます。いえ、正しくは「用意できる」ではなく「必ず用意しなければならない」ものです。HTML4においては、altはオプションではなく「必須」の属性とされています。 WWW利用者の環境 alt属性の使い方の基本公式 伝えるべき情報 なぜalt文をうまく組み込めないのか alt="" ? img要素のtitle属性を使う WWW利用者の環境 近頃はNetscape NavigatorやInternetExplorerが全盛で、それらに合わせたページを作ることが当たり前のように思われていますが、実際は： これらのグラフィカル・ブラウザを使っているが、回線の事情や、よりスピーディ

FlickrがMachine tagsを実装したというアナウンスがあり、某界隈で話題になっている。これは、従来のタグの書式を拡張して、medium:paint=oilという具合に「名前空間:プロパティ=値」というトリプルタグ（！）を用いてより詳細なタグ付けをし、API経由で処理できるようにするというものだ。一見「おぉ、これは」という感じだが、実際のところはどうだろうか。 まず、ここで「名前空間」はmedium:と名前空間URI接頭辞のような形式になっているが、実際はプロパティや値と同じくユーザが任意に与えるラベルになる（後述のようにURIと結びつける方法があるとされているが、怪しげ）。dc:とかfoaf:といったよく使われるものは収斂していく可能性は高いものの、「Machine tags」と呼ぶにはちょっと弱い。が、まぁそこは「タグ」の世界だから、いいことにしよう。 少しまともなプロパティ

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と判定するのだ

GRDDL仕様の最初の公開草案が出ていよいよXHTMLの出番だと思っていた矢先に、バーナーズ=リーからReinventing HTMLなどという話が出てきてびっくり。W3CのHTMLに対する取り組みへの不満は各地で書かれているし、WHATなんていう分派がHTML 5を起草したりしているから、本家としても何とかしなければならんということだろう。しかし、新しいHTML部会を設立する（to charter a completely new HTML group）と個人ウェブログでいきなり宣言するのは異例で、かなり唐突な感じがする。 もちろんこれは、XHTMLに向かう動きを逆流させようということではない。新しいHTML部会は、現在のHTML WGを置き換えるのではなく、並行して設置されるのだという。XMLの方向へ一度に切り替えようとしたのでものごとが動かなかった（The attempt to ge

IE7がRSSフィードのXSLTを無視することは以前も書いたが、Firefox 2.0までやってくれるとは。RSSの普及に対応し、特別なスタイル指定がなくてもフィードを読めるようにするという趣旨は分からんでもないが、HTMLのブラウザが作者スタイルシートがあればそちらを優先するように、文書のスタイル指定は尊重するほうが望ましいのではないか。 IE7の場合は、インターネットオプションのContentsタブでFeedsの設定を開き、「Turn on feed reading veiw」のチェックを外せば普通にXSLTを適用して表示できる。それに対してFirefox 2.0のほうは、フィードリーダに何を使うかが選択できるだけで、XSLTを有効にするオプションは見あたらない。しかも、デフォルトのフィードリーダでは、RSSの名前空間の要素のみが表示されて、dc:dateなども無視されるというお粗末さ

電子メールの末尾に区切り行"-- "を置くと、それ以降を署名とみなすのは、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

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