グーテンベルクからグーグルへ
文学研究は何に基づいて行われるのか。モノとしての本か、あるいは情報としてのテキストか。人文学の研究はそもそも何を資料としてきたのか。また、今後は何を資料としていくのか。デジタルの「本」の氾濫は、文学研究の制度、ひいては、人文学研究の制度全体に根本から揺さぶりをかける。「グーグルブック検索」の問題は、たんに作家や出版社といった供給者側の問題にとどまらない。それは 「本」をいかに読むのか、使うのかという読者、利用者、研究者の側の問題でもある。（書籍カバーより） Japanese translation of From Gutenberg to Google: Electronic Representations of Literary Texts, Cambridge University Press, 2006. 書籍の概要 内容について 書籍の概要 カバー タイトル グーテンベルクからグー
セレクタで使用できる文字 - スタイルシートの基本 -- ごく簡単なHTMLの説明
HTMLは効率的に情報交換を行えるよう、文書の「構造」を記述することを目的にしています。そこに文字の色や形などの情報が混じってくると、せっかくの情報が不明確になってしまいます。 スタイルシートは、レイアウトを別の場所に定義しておき、それを構造に対して適用するという考え方です。いったん定義したスタイルは、複数の文書で共有できますから、全体のデザインに一貫性を持たせることができ、しかもメンテナンスがずっと容易になります。 目次： スタイルシート：文書の論理と表現を分離する カスケーディング・スタイルシート（CSS） スタイルの定義場所 クラス、idによる定義の局所化 文脈セレクタと一括設定 カスケーディングと継承 スタイルのタイプ指定 取り上げる要素： style スタイルシート：文書の論理と表現を分離する 本文とは別に表現ルールを設定するスタイルシートは、文書のメンテナンスを容易にし、また表
ごく簡単なHTMLの説明
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は画面をレイアウトするためではなく、文書を環境に依存せずに共有できるように記述するための約束です。そこを正
ちょっとしたメモ - HTML5＋Microdataへの全面移行
この春頃からMicrodataを試してみたりHTML5にかかわる機会が増えてきたので、いずれ実施しようと考えていたサイト全ページの書き換えを敢行しました。スタイルシートはごく一部を除いてほとんど従来のまま。ページ自身のメタデータほかの構造化データは、Schema.org語彙を中心にして表現しています。 Microdataの記述 今回使ったMicrodataの一部を紹介しておきます。Microdataは、文書内に記述されたものごとの特徴を表す名前-値の対（プロパティ）のグループをアイテムと呼び、基本単位として扱います。 アイテムと型 Microdataの場合、まず最初にアイテムの範囲（スコープ）をitemscope属性で示します。文書のメタデータを表現したいので、html要素にこの属性を加えて全体を一つのアイテムとします（itemscopeは真偽値属性で属性名のみを記述しますが、XHTML構
iCalendar spec: 4.8.5.4 Recurrence Rule
Basic Definition | Description| | Example Basic Definition Property NameRRULE PurposeThis property defines a rule or repeating pattern for recurring events, to-dos, or time zone definitions. Value TypeRECUR Property ParametersNon-standard property parameters can be specified on this property. ConformanceThis property can be specified one or more times in recurring "VEVENT", "VTODO" and "VJOURNAL"
リンクするデータ、できること、目指すこと
ネットワーク時代のデータ 1つの組織内のデータベース 比較的少数のコンピュータ 管理可能なサイズと質のデータ、整ったスキーマ 組織、領域を超えたデータ 多数のコンピュータ、あるいはクラウド 膨大で質も不明なデータの海、それぞれに異なるスキーマ データのウェブ 標準化、ガイドライン… みんなで同じ語彙、スキーマ？ → 無理 共通項を用意してマッピング → ある程度は機能するが情報が失われる 約束事が多いと破綻しやすい 緩やかなつながり：データのウェブ WWWは簡単で緩やかな文書のリンクで発展 記述の約束（HTML）は単純で非力。しかしだからこそ誰もが利用できた（「よいHTML」） データも簡単な約束でリンクすれば、さまざまな形での利用が可能 情報サイロ 情報サイロ、あるいは壁で遮られる社会ネット The problem with today's social networks is that
リンクするデータ、未来へのリンク
Long Live the Web ウェブとはユニバーサリティであり非集中である Tim Berners-LeeのScientific American 12月号の記事 これを実現する基本がURI。データにURIを与えて公開しよう SNSや囲い込みストアのようにリンクできないものはウェブを分断する （Illustration by John Hendrix） セマンティック・ウェブ URIによる識別とRDFのデータモデルをベースに、意味論などの重層的な技術階層 全体像は複雑すぎて簡単には使えない → 基本層だけでも現実的に利用できる バーナーズ＝リーのLinked Data WWWが文書のハイパーリンクで発展したように、データ共有もリンクで発展する URIを識別だけでなくリンク（参照解決可能）にも用いる Linked Dataの4原則を提案 リンクするデータの4原則 ものごとをURIで名前
リンクするデータの現状と展望
セマンティック・ウェブとリンクするデータ 多層に渡る技術群としてのセマンティック・ウェブ URIによる識別とRDFのデータモデル、意味論が基本 全体像は複雑すぎて簡単には使えない → 基本層だけでも現実的に利用できる リンクするデータ WWWが文書のハイパーリンクで発展したように、データ共有もリンクで発展する URIを識別だけでなくリンク（参照解決可能）にも用いる Linked Dataの4原則（バーナーズ＝リー） リンクする公開データ Linking Open Data（LOD）プロジェクト データのサイロからリンクする公開データへ 有益な公開データもそのデータセットで閉じている場合が多い URIとRDFを用いてリンクするデータになれば、ネットワーク効果が W3CのLODプロジェクトが2007年に発足
GETとPOSTの使い分け - フォームデータの送信 -- ごく簡単なHTMLの説明
ブラウザからのデータデータは、特別な形式でエンコードされて送信されることになっています。画面に表示されるフォームのコントロールで入力する以外にも、隠されたデータの情報を送ったり、フォームを使わずに送信するなど、いくつかの方法があります。 目次： 作者の設定したデータを送る データ送信とURLエンコード フォームから直接メール送信 エンコードのタイプとファイル送信 GETメソッドとPOSTメソッド GETを使って直接データを送る 作者の設定したデータを送る input要素などで用意する「コントロール」はユーザーがそれを操作してデータを入力するためのものです。しかし、場合によってはHTMLの制作者が指定したデータをプログラムに送信したい場合もあるでしょう。このようなデータはユーザーが操作する必要はなく、ユーザーの目に触れないほうが都合がよいものです。そのために、input要素のタイプの一つとし
Dublin Core（ダブリン・コア）: ウェブ資源メタデータの共通語彙
メタデータをコンピュータが理解して有益な情報とするには、その意味が共通の認識となっている語彙が必要です。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
RDFカレンダー -- iCalendarとRSSによるイベント情報の公開と活用
イベントや会議の開催日や場所などがメタデータとして公開されると、情報の検索や共有・連動が大きく進みます。iCalendarのような広く使われるカレンダー・フォーマットとRDF/RSSを結びつければ、公開イベント情報が様々な形で利用できるだけでなく、これらをそのままPIMツール取り込むことも可能です。この延長線上には、レストランや病院検索といったセマンティック・ウェブの紹介でお馴染みの応用も視野に入ってきます。 This page is an introduction to RDF version of iCalendar. Most parts are written in Japanese, but you'll find a short summary at the beginning of each section. イベント情報とカレンダー iCalendarの基本構造と語彙 iC
セマンティック・マイクロブログ
ソーシャルメディアとマイクロブログ SNSとソーシャルメディア SNS：個人のプロフィールや関心事などを（範囲を限定して）公開し社会的ネットワークを構成 ソーシャルメディア：社会ネットワークとコンテンツ・メッセージ共有の組み合わせ Ambient Intimacy（何気なくそこにあるような親しみ）の感覚 データの互換性、共有が課題 マイクロブログ（Microblogging） 限られた字数の最小限の＝気軽に書けるコンテンツ ゆるやかで手軽なコミュニケーション Why We Twitterの考察では、日常会話＋情報探索/共有 フットワークの軽さとモバイルとの相性 携帯端末からも簡単に読み書きできる → 発信する位置という新たなメタデータ マイクロブログのデータモデル コンテンツのモデル ポストの内容（本文） ポストのメタデータ（タグ、返信など） サービスによってさまざまな形態 ポスト本文中に
ちょっとしたメモ - W3Cの新HTML作業部会
昨年10月のバーナーズ＝リーのびっくり発言から約4カ月を経て、W3Cに新しいHTML作業部会が設置された。HTML4とXHTML1をベースに、新しい(X)HTML仕様を2010年を目標に策定していく。従来のHTML作業部会はXHTML2作業部会という扱いになる（HTMLとは違う狙いなので、名前を変えることも検討しているそうだ。そりゃ大いに結構）。 Charter（設立趣意書）によれば、この新作業部会は次のものを策定していく。 HTML4を発展させた、ウェブの文書とアプリケーションのセマンティクスを表現する言語 この言語をXMLによって記述（シリアル化）する拡張可能な形態 既存ブラウザの「クラシックHTML」パーサと互換性のある、XMLではない記述形態 この言語のためのDOMインターフェイス フォームその他のUIで用いるための、プログレッシブバー、メニューなどの共通部品 リンクづけられたメデ
RDFとメタデータの相互運用
（メタ）データ相互運用の課題 データモデルと名前の相互運用 どんなモデル（データ構造、スキーマ）を採用するか プロパティ（関係記述語彙）はどの程度詳細に設計すべきか、独自語彙か汎用語彙か 人物などの典拠、主題などの語彙（ノードの名前）をどうやって共有するか 記述対象をどのように識別するか（リソースの同一性） （※本稿では、最初の2つ、モデルとプロパティについて検討します） 相互運用のスコープ データの共有：統合レポジトリの構築や横断検索の実現 データの交換：AのデータをBが取り込みたいとき データ相互運用とRDF/OWL なぜRDF/OWLか 柔軟性：シンプルで柔軟なグラフ構造でさまざまなモデルを表現できる 意味論：グラフの意味論が定義されており、予備知識のないデータも共通の解釈ができる 語彙の連携：語彙間の関係を記述することができ、その関係を利用した基本的な推論ができる 識別と統合：UR
ちょっとしたメモ - FlickrのMachine tags
FlickrがMachine tagsを実装したというアナウンスがあり、某界隈で話題になっている。これは、従来のタグの書式を拡張して、medium:paint=oilという具合に「名前空間:プロパティ=値」というトリプルタグ（！）を用いてより詳細なタグ付けをし、API経由で処理できるようにするというものだ。一見「おぉ、これは」という感じだが、実際のところはどうだろうか。 まず、ここで「名前空間」はmedium:と名前空間URI接頭辞のような形式になっているが、実際はプロパティや値と同じくユーザが任意に与えるラベルになる（後述のようにURIと結びつける方法があるとされているが、怪しげ）。dc:とかfoaf:といったよく使われるものは収斂していく可能性は高いものの、「Machine tags」と呼ぶにはちょっと弱い。が、まぁそこは「タグ」の世界だから、いいことにしよう。 少しまともなプロパティ
タグとオントロジー
タグとは何か del.icio.usのWhat are tags?から ブックマークなどを整理したり後で思い出すために、自分で自由に与える1語の説明 タグは階層がなく自由なので、あてがいぶちの分類に無理に合わせる苦労がなく、扱いやすい ほかの人のタグと合わせて、関心事項についての協調型レポジトリを構築できる 統制されない自由なキーワード 手軽に利用でき、新しい現象もすぐタグにできる 既存の統制語彙では新しい動きに対応できない 一方、多数のユーザが与えるキーワードには、同義語、多義語が必然的に含まれる 体系化のないフラットな空間 階層ではなく、キーワードの組み合わせで詳細概念を柔軟に表現 一方、階層を利用したグループ化や関連概念の検索はできない 統計的なグループや関連付けはある程度可能 タグのかたち 対象、ユーザ、キーワードの3大要素 タグは、タグを与える対象、タグを与えるユーザ、タグに用い
Web 2.0からセマンティック・ウェブへ
“Web 2.0”の主張 Tim O'Reillyによれば プラットフォームとしてのウェブ（The Web As Platform） 集合知の利用（Harnessing Collective Intelligence） データが重要（Data is the Next Intel Inside） 商品としてのソフトからサービスとしてのソフトへ（End of the Software Release Cycle） ハッキングと連動が容易な軽量プログラミング（Lightweight Programming Models） PCに限定されない利用（Software Above the Level of a Single Device） Ajaxに代表されるリッチなUI（Rich User Experiences） （What Is Web 2.0 Design Patterns and Busin
ちょっとしたメモ - IE7、Firefox2でもRSS1.0にXSLTを適用させる
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と判定するのだ
ちょっとしたメモ - IE7もFirefox2もRSSを特別扱い
IE7がRSSフィードのXSLTを無視することは以前も書いたが、Firefox 2.0までやってくれるとは。RSSの普及に対応し、特別なスタイル指定がなくてもフィードを読めるようにするという趣旨は分からんでもないが、HTMLのブラウザが作者スタイルシートがあればそちらを優先するように、文書のスタイル指定は尊重するほうが望ましいのではないか。 IE7の場合は、インターネットオプションのContentsタブでFeedsの設定を開き、「Turn on feed reading veiw」のチェックを外せば普通にXSLTを適用して表示できる。それに対してFirefox 2.0のほうは、フィードリーダに何を使うかが選択できるだけで、XSLTを有効にするオプションは見あたらない。しかも、デフォルトのフィードリーダでは、RSSの名前空間の要素のみが表示されて、dc:dateなども無視されるというお粗末さ
クールなURIは変わらない -- Style Guide for Online Hypertext
クールなURIとは？ クールなURIとは変わらないもののこと。 どんなURIが変わってしまう？ URIは変わらない：人がそれを変更するのだ。 理屈の上では、人々がURIを変更するべき（もしくはドキュメントのメンテナンスをやめてしまう）理由は全くありません。しかし、現実には山ほど理由があります。 理論上では、ドメイン名空間の所有者はその空間を所有しており、したがってその中に含まれるURIも所有権を持ちます。ドメイン維持料が支払えない場合を除いて、その名前を保有し続けることを妨げるものはありません。そして理論上は、あなたのドメイン名のもとにあるURIは、完全にあなたの管理下にあり、望む限りそれを安定的に保つことができるのです。 ウェブからあるドキュメントが消えてしまう唯一の納得できる理由は、そのドメイン名を保持していた会社が廃業してしまうか、サーバーを維持できなくなったという場合ぐらいでしょう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
