セマンティックHTML? KISS!
Keep It Simple, Stupid ウェブの文書とデータ 人間が読むためのウェブ文書にはさまざまな情報が詰まっている コンピュータ（エージェント／処理ソフト）はHTMLから文書構造の大枠を把握して提示できるが、内容（データの意味）は基本的に関知しない コンピュータ処理用のデータは別途用意する？ 両方まとめて、シンプルにしよう！ HTML文書中のデータをコンピュータ処理も可能にする HTMLのシンプルさを生かすことが大切 しかしコンピュータにとっても明快でシンプルであること だからセマンティックHTML ウェブリソースの型と関係 ウェブ文書中のデータを明示するためには 文脈によらない識別（名前付け）：何が同じで何が異なるかを明確にする データはどんなタイプ（型）か：文書について？ あるいは文中の映画について？ データどうしの関係：この日付は映画の封切り日？ 映画を観た日？ ウェブ文
ARC2によるRDFグラフの視覚化: Turtle, Microdata, JSON-LD, RDF/XML, TriG
music & knowledge sharing RDFグラフの視覚化 Turtle, Microdata, JSON-LD, RDF/XML, TriGテキストエリアにTurtle、JSON-LD、RDF/XML、TriGもしくはMicrodataで記述したRDFを入力し、「グラフ描画」ボタンを選択してください。MicrodataはHTML断片でもかまいません。URIをコンパクトに描画したい場合は「URIを修飾名表記する」チェックを有効にしてください。 Input Turtle, Microdata, JSON-LD, RDF/XML or TriGserialized RDF in the textarea and select "Draw" button. Microdata can be a fragment HTML.
ちょっとしたメモ - 『セマンティックHTML/XHTML』例コードのテキストほか
『セマンティックHTML/XHTML』が発刊されたので、書籍に掲載している例コードのテキストデータを用意しました。書籍ホームページの関連情報セクションをご覧ください。また、巻末参照文献リストをリンク集の形にして掲載しました。 本書の例の多くはRDFaを用いていますが、RDFaによるデータの記述は、慣れないとどんなグラフが抽出されるのか分かりにくいかもしれません。また自分で記述してみるにしても、正しいグラフが得られるかどうかの確認が必要です。 書籍第14章ではRDFaからのグラフ抽出ツールやプログラムを紹介していますが、手軽に確認できるよう、グラフ視覚化ツールも用意しました。RDFaによるHTML文書全体を記述しなくても、HTML断片からの抽出も可能なので、書籍の例を少し書き換えながら試してみると、理解しやすいのではないかと思います。
ちょっとしたメモ - セマンティック・マーク付け本ようやく脱稿
さて、昨年夏から格闘していたセマンティック・マーク付けに関する本の原稿をようやく書き上げ、出版社に送りました。仮タイトルは『セマンティックHTML/XHTML』で、毎日コミュニケーションズから5月下旬に刊行予定です。5年ほど前から本の企画はありながら、なかなかまとめられずにいたのですが、昨年とあるプロジェクトが没になったのを機に、集中してこの本に取り組み、何とか脱稿にこぎつけました。 セマンティック・マーク付けとは、普通のウェブ文書の中に含まれるイベントや人物などの情報を、ソフトウェア・エージェントでも扱えるように明示することで、人間が読むための文書（文書のウェブ）を、同時にコンピュータにも処理できる情報（データのウェブ）にしようという試みです。何度か取り上げたGRDDLやマイクロフォーマットもその一種ですし、最近ではRDFaという仕様がW3C勧告になり、注目を集めています。この本は、そう
セマンティック・マイクロブログ
ソーシャルメディアとマイクロブログ SNSとソーシャルメディア SNS：個人のプロフィールや関心事などを（範囲を限定して）公開し社会的ネットワークを構成 ソーシャルメディア：社会ネットワークとコンテンツ・メッセージ共有の組み合わせ Ambient Intimacy（何気なくそこにあるような親しみ）の感覚 データの互換性、共有が課題 マイクロブログ（Microblogging） 限られた字数の最小限の＝気軽に書けるコンテンツ ゆるやかで手軽なコミュニケーション Why We Twitterの考察では、日常会話＋情報探索/共有 フットワークの軽さとモバイルとの相性 携帯端末からも簡単に読み書きできる → 発信する位置という新たなメタデータ マイクロブログのデータモデル コンテンツのモデル ポストの内容（本文） ポストのメタデータ（タグ、返信など） サービスによってさまざまな形態 ポスト本文中に
ちょっとしたメモ - FavikiとタグとDBpedia
先日登場した新しいブックマークサービス Faviki は、ユーザがタグを与えるときに、英語版Wikipediaに登録された語句を候補として提供することで、語彙のゆれ（同義語の問題）を解消しようという特徴を持つ。さらに、タグとWikipediaの連動により、多義語の問題（Operaは歌劇かブラウザか）をも解決する可能性を示す。UIも工夫されており、タグを巡る困難へのひとつの答えともいえる。 タグの共有 以前「タグとオントロジー」で検討したように、タグを広く共有するためには、同義語、多義語の問題を処理する必要がある。アプローチとしては、 従来のタグシステムを前提として、ユーザが自由に与えたタグから、統計的な手法を利用して共通項を見出していく方法と、 ユーザがタグを与える時点で、そのタグを共有可能なもの（統制されたもの）にする方法 が考えられた。Favikiの場合は、後者の立場で、与えられるタグ
ちょっとしたメモ - metaprofのブロックレベル要素処理を強化
metaprofをプロファイルに指定してGRDDLで処理するとき、ブロックレベル要素に接頭辞付@class属性値を用いると型付ノード要素を生成しますが、文書自身とこのノードをfoaf:topic以外のプロパティで結び付けたいという要望を見かけたので、対応してみました。@classに、プロパティをあらわす値を付け加えるだけで、任意のプロパティを利用できます。 要望であげられていた例を使うと、 （例） <dl class="prism.isTranslationOf foaf.Document"> <dt>Original Page</dt> <dd><a href="http://www.alistapart.com/articles/previewofhtml5" class="about">A List Apart: Articles: A Preview of HTML 5</a></
ちょっとしたメモ - metaprofと文書トピックの主語URI
XHTML文書の要素に一定の規則に基づいたクラス属性を与えているとき、文書プロファイルにmetaprofを用いればGRDDLでRDFグラフが簡単に抽出できるようになるが、これまでは文書のトピックにURIを付与することができなかった。これを改良する新しいルールを変換スタイルシート追加したので、とりあえずお知らせを。 従来のmetaprof（の変換スタイルシート）の規則は、ブロックレベル要素に大文字で始まるクラス属性値、もしくはdc.、foaf.などの特定の接頭辞をつけたクラス属性値を与えておけば、それを適当なRDFの型付要素に置き換えて、文書のトピックを構成していた。たとえば、 （例） <p class="foaf.Image"> <img src="http://..." alt="xxx" /> <span class="date">2007-10-05</span> by <span
ちょっとしたメモ - CSS2.1の勧告候補と検討事項リスト
CSS2.1がようやく（再度）勧告候補にこぎつけた。今度こそは草案差し戻しなどということなく進んでいくだろうが、テストケースや実装確認もあるので、年内はCRに留め置くということだ。このCSS2.1は、PDF版で405ページ。1998年のCSS2勧告は338ページだから、単純に分量だけでも2割増で、記述の修正なども含めると、実はかなり大きな違いがある。バグ修正やブラウザの実装に合わせただけのものではなく、よりモデルを厳密に定義したり詳しく説明しているので、CSSに関心がある人は、そろそろ2.1の内容を確認しておくのがよいかも。 今回の勧告候補は、昨年11月の草案をおおむね引き継いでおり、かなり安定しているといえるが、多少の修正や明確化もある。11月草案との違いが検討事項リストの形で示されているので、主なものを確認しておこう（以下、項目名の数字は検討事項番号、リンク先は検討事項リストの対応する
ちょっとしたメモ - 宿題：body要素内からのprofileもしくはGRDDL
「名前のウェブとXHTML文書のプロファイル」をお話したとき、「ウェブログサービスなどでhead要素に手を加えることができない場合、body内部でプロファイル指定（あるいはGRDDL呼び出し）をする方法はないのか」という質問をいただきました。その場では即答できず、宿題ということにさせていただいたので、GRDDL仕様の検討事項（issues）での状況と、他の規格を組み合わせる可能性について報告しておきます。一言でいうと、「GRDDLではその必要性は提起されているが、結論は先送り。“リソース群”についての記述を利用すれば可能かも」というところです。 GRDDLのissue-tx-elementと題された検討事項では、ちょうど上記の質問と同様に、「XHTMLの一部だけを編集できる環境でクリエイティブ・コモンズ・ライセンスをa要素に記述するとき、rel属性値はどうすればよいのか」という疑問から出発
ちょっとしたメモ - GRDDLがW3C勧告案に
日曜日に「名前のウェブとXHTML文書のプロファイル」と題して《profile属性をうまく使うとclass属性値が共有できて、しかもGRDDL経由でRDFが抽出できるよ》という話をしたら、まさにその翌日、当のGRDDL仕様がW3C勧告案となった。タイミングよいというか、何かいいことありそうな感じ（期待）。内容は5月の勧告候補とほぼ同じで、8月24日までのレビューを経ていよいよ勧告に進む。 勧告候補と比べて違っているのは、Appendix Bとして基底IRI/URIの扱いが詳しく記述されたところ。GRDDLは処理途中に中間的なRDFグラフを生成したりするので、最終的なグラフの基底IRIをどう扱うかを明確にしておく必要があった。また、XHTMLではあまり関係ないが、XML文書一般ではルートノード以外にもxml:baseが設定されることもあるため、このあたりも含めるとそれなりに複雑な話になる。
ちょっとしたメモ - GRDDLサポートツール2つ
2月に入ってGRDDLをサポートするツールが2つ立て続けに登場した。一つはRaptor RDF Parser Toolkit（Dave Beckettのアナウンス）、もう一つはJena GRDDL Reader（Jeremy Carrollのアナウンス）。いずれも、XHTMLプロファイルを通したスタイルシートの間接指定ができるようになっているところが大きい。 Raptorは、C#、Java、Perl、PHP、Rubyなどの言語から利用できるRDFパーサの高速ライブラリで、RDF/XML仕様のエディタ自らが作っている定評あるもの。GRDDLは昨年からサポートしていたが、今回スタイルシートの間接指定も処理できるようになった。手元で試してみたら、XML/RDF出力だとxml:baseがうまく出てこないものの、GRDDLの処理はきちんとできている。 JenaはJavaでRDFを処理するための定番ラ
評判のオントロジーとFOAF
パネルテーマ：オントロジーの作り方、使い方 語彙を作り、語彙を使ってインスタンスを記述 ウェブにおいては、軽量オントロジーを用いて分散記述するのが主流 分散しているデータをどう結びつけるかというモデル（語彙設計）が重要 ユーザの評価とmicroformats microformats：コミュニティの合意による半構造化 ウェブログなどに記述する内容を、XHTMLのclass属性を使って半構造化する 名前空間を用いず、コミュニティ内の合意によって語彙を区別 Wikiを用いた合議スタイルによる仕様構築 利用が比較的簡単で、ウェブログ用のプラグインなどツールも多数 ユーザの評価を半構造化するhReview hReview - microformats （2005年5月ごろ0.1登場、2007年1月時点でバージョン0.3） TechnoratiのReview Searchなどで利用 XHTMLのcl
タグとオントロジー
タグとは何か del.icio.usのWhat are tags?から ブックマークなどを整理したり後で思い出すために、自分で自由に与える1語の説明 タグは階層がなく自由なので、あてがいぶちの分類に無理に合わせる苦労がなく、扱いやすい ほかの人のタグと合わせて、関心事項についての協調型レポジトリを構築できる 統制されない自由なキーワード 手軽に利用でき、新しい現象もすぐタグにできる 既存の統制語彙では新しい動きに対応できない 一方、多数のユーザが与えるキーワードには、同義語、多義語が必然的に含まれる 体系化のないフラットな空間 階層ではなく、キーワードの組み合わせで詳細概念を柔軟に表現 一方、階層を利用したグループ化や関連概念の検索はできない 統計的なグループや関連付けはある程度可能 タグのかたち 対象、ユーザ、キーワードの3大要素 タグは、タグを与える対象、タグを与えるユーザ、タグに用い
ちょっとしたメモ - Flickr MapにGPS情報付き写真を組み込む
flickrがgeotaggingに対応したといったって、いちいち地図にドラッグ・ドロップしなくてはならないというのは不便だし、だいいち日本はまともな地図が表示されないのだから不正確であまり面白くない。と思っていたが、ExifのGPS情報を取り込む方法が分かってきたので、ようやく百数十枚の写真をFlickr Mapに表示させることができた。Exifを抽出してRDFファイルを作るより手軽だから、これからはflickrが位置情報画像ベースとしても使えるか。 新規にアップロードする写真については、アカウント設定のImport EXIF location dataというページでGPS情報の取り込みを有効にすればよい（不思議なことに、このページはアカウント設定のホームページからもMapヘルプページからもリンクされていないために、flickrのメニューを探しても簡単には見つからなかった）。以前の写真は
フォーマルで行こう
情報のかたちと理解 InformationはFormを持つ 情報を構成する枠組みを知る 情報を既存の知識と関連付ける エージェントに伝える形、ユーザに伝える形 ウェブの「型」を身につけよう 文学や芸術に“形式”があるように「フォーム」は重要 ウェブの「型」 → ユニバーサルアクセスとデータ共有・再利用 情報のかたちと名前 コンピュータと形式と名前 形式化：形（枠組み）に名前を与えて共有可能にする 形式化された情報はコンピュータ処理が可能 情報を抽出する、変換する、推論する… 名前とコンテクスト おーい、あれ持ってきて（完全にローカルコンテクスト） オペラが好きだ（コミュニティによる違い） 東京都中央区銀座1丁目（コンテクストに依存しない） 名前は共有できてはじめて意味がある ウェブページで使われる名前はどんなスコープで通じるか HTMLと情報のかたち 文書のかたちを示すマーク付け シンプル
Exif to RDF - a metadata extractor
URI of an Exif image Use XSLT to format output or, try some samples from Wikimedia commons: Common tiger male, Kumarakom, Kerala, India (or w/ XSLT): camera Canon EOS 80D (Wikimedia page) F1 Monaco Grand Prix, Monte Carlo, Monaco (or w/ XSLT): camera Canon EOS-1D X (Wikimedia page) Mt. Fuji from Fuji City (or w/ XSLT): camera Canon PowerShotA50 (Wikimedia page) Michelangelos David (or w/ XSLT): ca
ちょっとしたメモ - 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のリテラルとして矛盾無く記述できる（たとえばデータ型と言語タグの両方を持っていたり
ちょっとしたメモ - Microformatの先へ
"Web 2.0"やmicroformatに関心がある人は、昨日xml.comで公開されたUche Ogbujiの記事 Microformats in Context をぜひ読んでおこう。ここでは、microformatの可能性と限界、そしてその次のステップが、XMLの本質に照らして鮮明に描かれている。microformatは「インフォーマルな文脈における小さな島（コミュニティ）をうまくまとめる方向に目を向けている」が、それらの小さな島をつなぎ、集約するためには、もう少し先に進む必要がある。 Ucheの論点を大まかに列挙すると、次のようになる： microformatは新しい語彙を作るのではなくて、既存のよく普及したフォーマット（XHTML）を利用して情報を表現しようとするものだが、多くの場合、XHTMLの語彙の意味を拡大解釈し過ぎて、混乱を生む。 複数のmicroformatの間で語彙が
ちょっとしたメモ - 自分のURIを持とう：バーナーズ＝リー推奨版
あらゆる人に当てはまるURIの生成規則というのは、存在しない。しかし、人に関するデータがRDFで記述されていても、URIがないと外部から直接言及することができず、たいへん不便でもある。そこでバーナーズ＝リー親分が、Give yourself a URI にてご提言に及んだ。曰く、FOAFのURIを使って、その後ろにイニシャルなどのフラグメント識別子を加えればよいのだ、と。 FOAF文書の中に、自分を表すこのURIを付け加えるのは簡単だ。文書内ではFOAFのURIが基底となるので、foaf:Person要素にrdf:ID属性で識別子を与えるだけでよい。例えば、mkという識別子を使うなら次のような具合だ。 Leigh DoddsのFOAF-a-Maticは早速これを採用して、（ただしイニシャルの代わりに'me'という識別子で）FOAF作者にURIを与えるようになった。URI本体と、それにフラグ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
