日本十進分類とリンクするデータ
他の情報と組み合わせるときは個々に明示が必要 属性（著者）と値（小田島雄志）だけでは、他の情報と組み合わせた時に混乱する 対象を加えた3つの要素による情報記述 対象＝主語、属性（関係）＝述語、値＝目的語のトリプルを用いて記述 主語と目的語で表されるものをノード（節点）とし、述語（関係）のアークで結んだグラフとして表現できる グラフは共通のノードを繋いで広げていくことができる＝複雑な情報を表現できる 複雑な情報も単純なトリプルに分解して扱うことができる グローバルなつながり グローバルな識別子 単語だけでは表記の揺れや同名があり、情報の同定、区別が難しい 「小田島雄志」と「小田島，雄志」、いろいろな「ロミオとジュリエット」など 主語、述語、目的語をURIで表して曖昧さを取り除く コンピュータで直接処理できるデータ（文字列）はURIで指し示すことなくそのまま（リテラル）で扱う URIによる識別
映画のメタデータとリンクするデータ
データモデリングと実体 属性―値対としてのデータ記述 フラットな表によるデータの記述 実体の関係としてのデータモデル 独立した存在として情報を付与できるものを実体（entity）と捉える。実体は属性（attribute）を持つことができる。 データを実体間の関連（relation）として捉える（ERモデル） 目録データの中の実体 目録データにおいて実体として捉えられるもの 監督、原作、製作会社、配給などは実体と考えられる 映画そのものも実体だけれど、目録データのどこに？ 製作年月日などは実体？ FRBRがとらえる実体 FRBRの実体のグループと関係 FRBR＝書誌レコード（データモデル）機能要件の検討結果 書籍だけでなく、映画を含む多くの作品表現モデルから参照されている 作品に関連するグループ1、エージェントのグループ2、主題などのグループ3で構成 グループ1には作品、表現形、体現形、アイ
図書館目録からLinked Dataへ
データモデリングと実体 属性―値対としてのデータ記述 フラットな表によるデータの記述 実体の関係としてのデータモデル 独立した存在として情報を付与できるものを実体（entity）と捉える。実体は属性（attribute）を持つことができる。 データを実体間の関連（relation）として捉える（ERモデル） 書誌における実体 書誌データにおいて実体として捉えられるもの 著者、訳者、出版者、出版地などは実体と考えられる 本そのものも実体だけれど、書誌データのどこに？ 分類などは実体？ 典拠における実体 典拠概念と実在する実体 標目やノート、ソースなどから構成される典拠概念（実体） 標目によって示されている実在物（人物、場所、時代…） 標目ID00444960が表す実体は… FRBRの実体関係分析 タスクと実体の分析 FRBRでは4タスク（発見、識別、選択、取得）を念頭に実体分析： 情報利用者
MLAとリンクするデータ 各国図書館の書誌・典拠グラフを中心に
リンクするデータと書誌・典拠 リンクするデータ4原則 ものごとをURIで名前付けする これらの名前を調べて訪ねる（参照解決する）ことができるように、httpスキームのURIを使う 名前付けしたURIがたどられたら、有用な情報を返す ほかのURIへのリンクを加えて、より多くのものごとを見出せるようにする 各国図書館での原則1、2：ユリシーズの場合 国立国会図書館…http://iss.ndl.go.jp/books/R100000002-I000002510361-00 ドイツ国立図書館…http://d-nb.info/979821517 英国図書館…http://bnb.data.bl.uk/id/resource/015487226 フランス国立図書館…http://data.bnf.fr/ark:/12148/cb40939669f WorldCat…http://www.world
Javascript RDF/Turtle Parser
RDF/Turtleをパースして、トリプルをJavascript/JSONの配列として返します。Jim LeyのJavascript RDF Parserと同じフォーマットなので、少しの変更でその関数が利用できます。また、TurtleをJSON形式に変換することもできます。 Parses RDF/Turtle string and generates Javascript/JSON array of RDF triples, which is the same format as that of Jim Ley's Javascript RDF Parser. So you can use Jim's utilities with this output (need to add a few lines to his script so that it accepts calls from
ハイパーリンク -- ごく簡単なHTMLの説明
WWWでは、読者は文書のある部分から、関連するほかの文書・場所へ直接ジャンプし、関心を持ったトピックについて、「文書」の枠を超えて次々に渡り歩いていくことができます。このような機能を持つ文書をハイパーテキストと呼び、関連づけをすることを「リンクを張る」と言ったりします。HTMLではa要素を使って文中の語句や画像からリンクを形成します。 目次： アンカー要素 ほかの文書へのリンク 文書の特定の場所へのリンク 名前を付ける 名付けたフラグメントにリンクする 名前付けの注意点 同じファイルの指定箇所へのリンク フラグメント識別子に関する補足 取り上げる要素： a アンカー要素 本文中のリンク情報は アンカー要素（a要素タイプ）で表現します。アンカー（Anchor）とは「錨」のことですが、何かをつなぎとめるものという一般的な意味もあります。文書のある場所から別の場所（リソース）へのリンクを、文書と
Linked Data Browser
URIで指定されたRDFソースを取得し、グラフを基本URI毎に表形式で表示します。URIはこのブラウザで表示するリンクになるので、リンクするデータを辿って行くことができます（簡単な機能説明）。 This browser will fetch RDF source from specified URI, and describe its graph as tables, where object URIs will be hyper links via this browser so that you will be able to follow your nose. See an explanation. URI set nest level Some Linked Data Exampels MLA関連のデータ 夏目漱石 - Web NDLA Linked Data - LCSH Wea
リストの作成 -- ごく簡単なHTMLの説明
情報を見やすく整理して表現する方法として、リスト（一覧）はとても効果的です。HTMLでは、項目を列挙するul要素、順序を考慮して列挙するol要素、用語とその説明という定義型のリストを構成するdl要素の3つのリスト要素が用意されています。 目次： リストで情報を分かりやすく整理する 並列列挙リスト 順序付きリスト 定義型リスト リスト要素はブロックレベル リストの入れ子 取り上げる要素： ul ol li dl dt dd リストで情報を分かりやすく整理する 基本的には本文は見出しと段落だけで構成できるはずです。しかし、一連の並列される情報や、順序立ててステップを説明するような内容は、リストとして表現する方が分かりやすいことがあります。 一つの段落が長くなってしまう場合は、そこで述べようとしているポイントを箇条書きにすると、簡潔に表現することができます。また、複数の段落に分けて書いている内容
HTTPヘッダのメタ情報
ユーザエージェント（ブラウザ）がウェブサーバーからHTTPでリソースを取得するとき、HTTPメッセージのヘッダにいくつかのデータを付加することで、リソースに関する情報やユーザエージェントの機能、利用者の好みなどを伝えることができます。HTTPヘッダは、ウェブのリソースに関するメタ情報を提供する、最も確実で効率的な手段の一つです。 HTTPとヘッダ 応答ヘッダによるメタデータ MIMEタイプと文字コード情報 SSIと更新日付情報 コンテント・ネゴシエーション Multiviewsと言語ネゴシエーション ブラウザの言語設定 独自ヘッダの追加 参照文献 HTTPとヘッダ WWWでリソースを取得するとき、ほとんどの場合はHTTP (Hypertext Transfer Protocol) [RFC2616]に基づくメッセージの交換によってユーザエージェント（UA）とウェブサーバーがやり取りを行いま
RSSによるサイト情報の要約と公開
メタデータ/RDFの応用として利用されているXMLフォーマットの代表として、RSS (RDF Site Summary) があげられます。共通の書式でドキュメントの見出し、要約などのリストを提供することで、サイトの更新情報などを効率的に公開できます。 RSS 1.0の要素と構文 channel要素 item要素 シンプルなRSSの全体 RSS 1.0全要素のツリー RDFとして見た場合のRSS RSSのRDFモデル RDFモデルの補足説明 RSSの拡張/応用とモジュール Dublin Coreモジュール Syndicationモジュール Contentモジュール そのほかのモジュール RSSとセキュリティ RSSの実際の利用 RSSの歴史〔補足〕 参照文献 ※RDFの体系的な解説『RDF/OWL入門』を上梓しました。 RSS 1.0の要素と構文 RSS (RDF Site Summary)
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.
ちょっとしたメモ - JSONではじめるRDF/Turtle
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
日付の表記に関するノート
日付の表記方法は、文化的な背景の違い、また用途の違いによって様々なフォーマットがあります。多くの場合、特に断り無く使っても問題なく正しい日時を伝えることができますが、文脈や利用者の環境によっては、意外な落とし穴にはまることもあります。誤解なく、かつ効率的に処理しやすい日時表記方法としては、2001-08-02T10:35Zというスタイルの、ISO/W3Cフォーマットがあります。 文化と日付表記 日時表記の国際標準とW3Cノート W3Cの日時フォーマット XML Schemaの日時データ型 タイムスタンプのインターネット標準 そのほか広く用いられる日時の書式 ピリオド区切りによる日付 電子メール、HTTPヘッダなどの日時表記 継続期間の表記 ISO 8601の期間表記 Dublin Coreの期間表記 読みやすさと処理しやすさのバランス 参照文献 文化と日付表記 よく見かける日付の表記法とし
写真/画像とメタデータ -- EXIFを利用したJPEGとRDFの連動 (Image-metadata integration with Exif)
写真のようなイメージデータは、一般にはXHTMLのimg要素でウェブページに埋め込んで提供されますが、その場合、イメージの関連情報はXHTMLで別途記述されるだけで、画像ファイルが単独で参照されるとうまく伝わりません。両者をもっと有機的に融合させるため、Exifデータを抽出する、JPEGに直接RDFを埋め込むなど、画像とメタデータを結びつける方法を検討します。 Image data is generally provided as a part of an XHTML document. The description of the image, written in XHTML, is not reachable when the image itself is retrieved directly. In order to integrate the image and its des
Geo metadata - 位置に関するメタデータとその応用
ウェブ上の様々なリソースは、「位置」に関する情報と組み合わせることで、リアルな世界と結びつきます。緯度経度データをRDFやmeta要素として提供したり、そのデータを地図上に表現するなど、位置に関するメタデータを記述する方法とその応用について検討してみます。 This page is an introduction to RDF Geo vocabulary and its applications. Most parts are written in Japanese, but you'll find a short summary at the beginning of each section. 場所の表記とメタデータ RDF-IGのGeo vocabulary Geo vocabularyのクラス Geo vocabularyのプロパティ 位置情報の利用例 FOAFのbased_ne
リンクするデータ、できること、目指すこと
ネットワーク時代のデータ 1つの組織内のデータベース 比較的少数のコンピュータ 管理可能なサイズと質のデータ、整ったスキーマ 組織、領域を超えたデータ 多数のコンピュータ、あるいはクラウド 膨大で質も不明なデータの海、それぞれに異なるスキーマ データのウェブ 標準化、ガイドライン… みんなで同じ語彙、スキーマ？ → 無理 共通項を用意してマッピング → ある程度は機能するが情報が失われる 約束事が多いと破綻しやすい 緩やかなつながり：データのウェブ WWWは簡単で緩やかな文書のリンクで発展 記述の約束（HTML）は単純で非力。しかしだからこそ誰もが利用できた（「よいHTML」） データも簡単な約束でリンクすれば、さまざまな形での利用が可能 情報サイロ 情報サイロ、あるいは壁で遮られる社会ネット The problem with today's social networks is that
クリエイティブ・コモンズのメタデータ -- 著作権とライセンス記述の新しい形
著作物のより広く柔軟な提供を目指した新しいライセンスを提案するクリエイティブ・コモンズは、そのライセンス内容のメタデータをRDFで記述できるようにしています。クリエイティブ・コモンズの定義する語彙とその用法を簡単に紹介します。 クリエイティブ・コモンズとは C.C.ライセンスのオプション C.C.メタデータの語彙 C.C.メタデータの記述 C.C.メタデータ語彙を用いた拡張 参考文献 クリエイティブ・コモンズとは クリエイティブ・コモンズ（[Creative Commons]、以下C.C.と略記）は、知的創作物の“著作権”を尊重しつつ、その成果をより広く容易に利用するための新しい形を提唱する活動です。そのプロジェクトのひとつであるLicensing Project[CCLP]は、「一定の条件の下に創作物を自由に利用してよい」というライセンス（の組み合わせ）を用意し、作者が適当なライセンスを
リンクするデータ、未来へのリンク
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年に発足
ハンディがあっても利用できるページづくり：Webアクセシビリティについて
様々な環境に配慮して、どんなユーザーでも使いやすい方法で提供されている情報はアクセシビリティ (accessibility) が高いと言います。アクセシブルなコンテンツづくりとは、ウェブでのコミュニケーションに誰もが参加できるよう設計すること。情報の利用者であると同時に提供者でもある私たちは、常にこの点に配慮していきたいものです。 なぜアクセシビリティか コミュニケーションとしてのアクセシビリティ：WCAG 2.1 1. 全ての機能と情報が誰にとっても認識可能であること 2. 全ての機能は誰にでも操作可能であること 3. コンテンツの内容、および機能が誰にとっても理解可能であること 4. 将来にわたってコンテンツの力を最大限に発揮できる技術を用いること 元祖ガイドライン：WCAG 1.0 アクセシビリティのJIS規格（2004年初出時の情報） JISの改定：X 8341-3:2010と20
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
