サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
大そうじへの備え
www.kanzaki.com
HTML 4.0（それ以前にRFC2070）で導入されたlang属性、hreflang属性、およびXMLのxml:lang属性[1]は、「言語コード」を指定することで、ドキュメントで使用している言語を明示し、ブラウザの表示に加えてサーチエンジンや音声合成にも役立つような情報を提供します。ここで用いられる「言語コード」はURLの指定などに使われる「国コード」とは異なるもので、日本語は「JA」になります。混乱しやすいので、注意が必要です。 言語コード 国コード Charset ? 言語コード 日本のように国家と言語が（ほぼ）1対1で対応しているとあまり意識しませんが、一つの国で複数の公用語を持っているところもあれば、多くの国で使われる言語もあります。このため、「国コード」とは別に130以上の「言語コード」がISO 639によって定義されています。 主要なものを挙げると： 主な言語コード
分析と概念モデル：FY2017 多様なソースを集約するメタデータ語彙とは 博物館、公文書館、人文学、標本、放送番組など20近くのデータを分析 DC-NDLを拡張する？→図書館リソースと同じ精度で他領域まで拡張するのは困難 各分野の既存語彙を集める？→対応範囲が広すぎ複雑。つまみ食いで中途半端になりそう まず語彙を特定しない概念モデルから サンプルデータを分析し、記述に必要な要素を整理 記述語彙を特定せず、まず要素を表現するためのモデルを考える 提供しやすい×利用しやすい 提供者に負担をかけない＝事前マッピングなどを求めない 元データや現物へのアクセスを導く＝提供者、利用者双方にメリット マッピング開発からベータ版公開：FY2018 語彙を含めたスキーマの策定 複数語彙を候補に、概念モデルを記述できるかどうか検討 できれば語彙は少数に（膨大な名前空間宣言は不便） Schema.org＋独自語
利活用しやすいデータを考える 見つかるデータ 分かりやすい項目：領域を問わず適用でき、特別な知識なしに理解できる項目（キー） 一貫した名前：同じものは同じ名前（値）。典拠による識別、もしくは典拠へのリンク 無理のない記述：利用者のメンタルモデルに反しないシンプルな構造、膨張しない名前空間 活かせるデータ 訴求効果がある：表示用画像、地図、年表などで視覚化しやすい項目 探索と集約ができる：横断検索、キーワードや分類、正規化値など集約の手掛かり 付加価値を生む：データの分析、組み合せや予想外の発見、第三者による情報追加 辿れるデータ アクセス：より深い情報や現物につながる。その権利もわかる ソースと来歴：データのもとになった情報や作成者、更新時 リンクするデータ：URIを辿れる、外部情報とつながる、誰もが同様に言及できる ジャパンサーチ利活用スキーマ 共通記述情報とソース情報の分離 見つけやす
使いやすさと詳細な情報の両立 使いやすさ：発見タスクを容易にする いつ、どこ、だれ、なにをschema.org語彙で直接記述＝正規化値 名前の正規化と主要LODとのリンク SPARQLを知らなくても利用できるEasySPARQL 詳細なエンドポイント説明と（非公式）サポートページ 詳細な情報：識別、選択タスクを確実にする schema.orgによる記述に独自語彙での構造化記述を併置＝正規化＋元データの値 アクセス情報によるコンテンツへのアクセス（取得タスク） ソース情報による来歴の確認（つなぎ役へのリンク） 利活用スキーマメタデータ提供の流れ 各提供機関（→つなぎ役） 連携フォーマット（共通ラベル付与）→ジャパンサーチの通常検索 共通の正規化辞書＋データセットごとのマッピング定義 利活用スキーマのRDFデータ（API提供可のデータのみ） いつ：時間情報の正規化とEasySPARQL 多様な
ジャパンサーチ 非公式サポートページ for 利活用スキーマJapan Search unofficial support page ジャパンサーチの（主として利活用スキーマの）応用や活用に関する情報を順次掲載していきます。This is a personal introduction to Japan Search (JPS), the national integrated cross-sectoral metadata portal. ジャパンサーチ（のRDF）を使うUsing Japan Search RDF はじめてのジャパンサーチ利活用スキーマ (2019) SPARQLで使うジャパンサーチ利活用スキーマ (2020) ジャパンサーチ利活用スキーマとSPARQL (2023) ジャパンサーチSPARQLクエリ集 いろいろな利用のための材料やヒントSome resources t
「このような音ではない」という言葉が何を否定しているのかは、いろいろな捉え方がある。まず、直接的に3つの楽章を否定していくのは終楽章冒頭の低弦のレチタティーヴォだ。ノッテボームなどの研究によれば、ベートーベンのスケッチではこの器楽によるレチタティーヴォの旋律に歌詞が書き込まれている。スケッチの旋律はまだ未完成であるものの、最終的なレチタティーヴォと次のような対応関係がある： 1楽章が回顧されたあとのフレーズには「o nein, dieses nicht, etwas anderes gefälliges ist es was ich fordere（いや、これではいけない、もう少し違ったものを、快いものだ、私の求めているのは）」 2楽章の断片のあとでは「auch dieses nich, ist nicht besser, sondern nur etwas heiterer（これもだめだ
中世の詩歌集「カルミナ・ブラーナ」について調べたことのまとめと、カール・オルフ作曲のカルミナ・ブラーナで用いられた全詩を含む対訳および訳注です（配列は歌集順で、オルフでの曲順とは異なります）。 カルミナ・ブラーナの概要 対訳と訳注（抜粋） 真面目編 S.I/CB.17. O Fortuna, velut luna S.LXXVII/CB.16. Fortune plango vulnera S.CLXXII/CB.191. Estuans interius S.CCIII/CB.16*. Primitus producatur Pilatus 愛の歌編 S.37/CB.62. Dum Diane vitrea S.43/CB.70. Estatis florigero tempore S.50/CB.77. Si linguis angelicis loquar et humanis S.
イベントや会議の開催日や場所などがメタデータとして公開されると、情報の検索や共有・連動が大きく進みます。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
この例をもとに、HTMLのフォームを構成する要素を順番に説明していきます。この例のHTML全体は、本章の最後で改めて紹介します。 フォームの基本枠組み データを送信するためには「何を」「どこに」「どうやって」送るかを示さなければなりません。フォームはこのための手段を提供します。 HTMLのフォームは、データを入力するための手段（コントロールと呼びます）と、それに関するラベルや説明から構成されるひとまとまりのセクションです。「何を」送信するかを示すためにこのセクションの範囲を明示し、「どこに」「どうやって」送信するかを設定します。この枠組みを提供するのがform要素です。 form要素の構造 form要素タイプは2つの主要な属性を持ちます。ひとつは「どこに」、つまりデータを受け取るプログラムを指定するaction属性、もうひとつが「どうやって」、つまりデータの送信方法を指定するmethod属
HTMLは決して難しいものではありません。基本的なことがらなら、30分で概要を理解することだって可能です。そして、その基本だけで、十分ウェブページを書くことができるのです（ここでは、より広い可能性を持つXHTMLの書き方に準じて説明します）。 最初の準備 よいHTML HTMLの基本形 タグとは何か タイトルを決める 分かりやすい本文の構造 段落を示す 見出しをつける リストにして示す いろいろな情報の伝え方 リンクする 強調する 画像を表示する 作者情報 マーク付け言語と文字の情報 よいHTML せっかくHTMLの書き方を身につけるのですから、どうせなら「よい」HTMLを書けるようにしましょう。全ての学習と同じで、「よい」メソッドを身につけると、絶対に理解も早いしあとが楽になります。すぐにHTMLを書きたい人も、ちょっとだけ付き合ってください。 よいHTMLの条件 よい文章の条件の一つが
W3Cは「ウェブの可能性を最大限に引き出す」ために、技術的、社会的な側面から検討を行ない、その結果を標準情報（Technical Report: TR）として公開します。TRには、段階的な審議を経て勧告に至るものと、ノートとして参考に公開されるものがあります。 W3C勧告までの過程 草案（Working Draft） 最終草案（Last Call Working Draft） 勧告候補（Candidate Recommendation） 勧告案（Proposed Recommendation） W3C勧告（Recommendation） 勧告の修正・変更・解除 W3C Notes / Working Group Notes レファレンス この説明は主として2005年版のProcess Documentに基いています。2014年8月, 2015年9月, 2017年3月に改訂版が公開されており
日付の表記方法は、文化的な背景の違い、また用途の違いによって様々なフォーマットがあります。多くの場合、特に断り無く使っても問題なく正しい日時を伝えることができますが、文脈や利用者の環境によっては、意外な落とし穴にはまることもあります。誤解なく、かつ効率的に処理しやすい日時表記方法としては、2001-08-02T10:35Zというスタイルの、ISO/W3Cフォーマットがあります。 文化と日付表記 日時表記の国際標準とW3Cノート W3Cの日時フォーマット XML Schemaの日時データ型 タイムスタンプのインターネット標準 そのほか広く用いられる日時の書式 ピリオド区切りによる日付 電子メール、HTTPヘッダなどの日時表記 継続期間の表記 ISO 8601の期間表記 Dublin Coreの期間表記 読みやすさと処理しやすさのバランス 参照文献 文化と日付表記 よく見かける日付の表記法とし
こんにちは。音楽に関するいくつかのメモや、ウェブ上での情報の共有や活用に関する参考情報があります。 The English only TOC page also available. 音楽の話 ロジャー・ノリントンの話 交響曲に関するいくつかの情報 歌詞／テキストと音楽（レクイエム、ミサ曲、第九、大地の歌、ツァラトゥストラなど） NMLで聴いてメモした曲リスト 古いもの ... show 音楽雑記帖 コントラバスの話 インターネットやコンピュータの話 セマンティック・ウェブ (ジャパンサーチ非公式サポート、グラフ視覚化、画像注釈とIIIF、LD Browser) いくつかの講演スライドそして専門誌/論文誌記事など アクセシビリティおよびごく簡単なHTMLの説明 OWL語彙の実験・提案、その他いろんな試みの記録 古いもの ... show ちょっとしたメモ（主に2003～2008） ハイパー
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は画面をレイアウトするためではなく、文書を環境に依存せずに共有できるように記述するための約束です。そこを正
大きなテーブルは、音声読み上げで内容を聞いているとき、データが何を示す値であるかが混乱してきます。音声ブラウザは、th要素の内容やtd要素のheaders属性を利用して、補助的な情報を読者（聴取者）に伝える機能を持っています（WebSite DesignのVol.3で「音声ブラウザでもまだサポートされていない」と書いてしまいましたが、新しいバージョンはかなり対応が進んできました）。 音声ブラウザとth要素 長い見出し項目の省略形 セルの関係を示す属性 scope属性 headers属性 データの次元と軸 補足：テーブルsummary属性の読み上げ 音声ブラウザとth要素 表（テーブル）は、大量のデータを縦横の二次元に整理することで、視覚的に把握しやすくします。しかし、音声合成でテーブルを読み上げる場合、データは順番に一次元的に読み上げられるため、全体像を把握することが難しくなります。たとえ
コンピュータは主にアメリカで発達してきたため、未だにアルファベットや数字などの1バイト（7/8ビット）を基本単位として扱う前提で作られているものが中心です。そのなかで日本語のように多くの文字を必要とする言語は、1文字を表わすのに2バイト以上を要するため、いろいろな困難が伴います。特にインターネットを通じて様々な環境の情報を交換するにあたって、思わぬ問題に遭遇するケースが増えてきました。ここでは、こうしたことを考えるために必要な、日本語の文字コードに関する基本を整理しておきます。 JIS漢字コード（情報交換用符号化漢字集合） 区点コード JISコード（符号化方式） シフトJISコード EUCコード ASCIIとJISローマ字 Unicode 主要コード規格のまとめ 参考文献、リソース 文字化けしたメールの復元 | The Web KANZAKI ホームページ JIS漢字コード（情報交換用符号
間接記述としての注釈 直接プロパティでの記述 作品の解説→いつ誰が述べた解説か（メタプロパティ）を記述できない 間接的な記述によるメタプロパティ 関係をノード化し、主語を対象、目的語を内容とすることで、他のプロパティを追加できる 複数の記述を併合しても区別できる＝ウェブでの協業に不可欠 関係ノードを「注釈」と捉えることで間接記述モデルを汎用化できる 注釈モデルの標準化 WWWと注釈 2000年秋にW3CでAnnotea Projectがスタート 2009年には英米豪の大学や図書館を中心にOpen Annotation Web Annotation標準化 2017年にWeb Annotation Data Modelや語彙がW3C勧告に 注釈対象をtarget、内容をbodyとする間接記述モデル 写本デジタル化の問題意識 各大学や図書館の写本資料は それぞれがサイロ（相互運用性がない） アプ
クールなURIとは？ クールなURIとは変わらないもののこと。 どんなURIが変わってしまう？ URIは変わらない：人がそれを変更するのだ。 理屈の上では、人々がURIを変更するべき（もしくはドキュメントのメンテナンスをやめてしまう）理由は全くありません。しかし、現実には山ほど理由があります。 理論上では、ドメイン名空間の所有者はその空間を所有しており、したがってその中に含まれるURIも所有権を持ちます。ドメイン維持料が支払えない場合を除いて、その名前を保有し続けることを妨げるものはありません。そして理論上は、あなたのドメイン名のもとにあるURIは、完全にあなたの管理下にあり、望む限りそれを安定的に保つことができるのです。 ウェブからあるドキュメントが消えてしまう唯一の納得できる理由は、そのドメイン名を保持していた会社が廃業してしまうか、サーバーを維持できなくなったという場合ぐらいでしょう
第九の歌詞の音訳（ごろあわせ） 1985年2月17日の「5000人の第九」（国技館すみだ第九を歌う会）の参加者が歌詞の暗記用に考案し、朝日新聞などで紹介されて有名になった、第九の合唱テクストの「音訳」。作者は当時、上智大学文学部ドイツ文学科の2年生だった、吉井実奈子さん。 合唱テクスト音訳 風呂出で（フロイデ） 詩へ寝る（シエーネル） 月輝る（ゲッテル） 粉健（フンケン） とホテル（トホテル） 会う末（アウスエ） 理事（リージ） 生む（ウム） ビルベ（ヴィルベ） と（ト） ０点（レーテン） 夫追い得る（フオイエル） 取るん健（トゥルンケン） 貧無理死へ（ヒンムリッシェ） 台ん（ダイン） 入り人産む（ハイリヒトウム） 台寝（ダイネ） 津会うベル（ツアウベル） ビン出ん（ビンデン） 微出る（ヴィーデル） バス出い（ヴァスデイ） 詣で（モウデ） 酒取れん（シュトウレン） 下駄いると（ゲタイルト）
誰にも読みやすいコンテンツとするためには、文字色と背景色のコントラストをしっかり確保しなければなりません。これを客観的にチェックするため、色の明るさの差などを計算する仕組みを用意してみました。 色の組み合わせ検証 テストの手法 コントラストの計算 色覚偏位のシミュレーション 当サイトが独自に加えたコントラストの段階評価 コントラストと読みやすさの相関関係 色の組み合わせ検証 検証してみたい文字色と背景色の組み合わせを入力してみてください。色の指定には3桁もしくは6桁の16進数カラーコード、あるいは色名（CSS2の色名＋SVGの色名、計147色）およびrgb()の表現が使えます（初期値は、読みにくい例が入っています）。また、入力欄左ボックスから216色のパレットを呼び出して入力することもできます。文字色2、3は、複数の文字色の組み合わせを表示するためのオプションで、コントラストなどの計算は行
基本はカンバス 注釈としてのカンバス カンバスの拡張 マニフェストの役割 カンバスの並べ方 (1) カンバスの並べ方 (2) カンバスの並べ方 (3) マニフェスト設計のヒント 8分のLTのために作った短いスライドです。簡単な導入はIIIF：活用したい機能、拡張の可能性（LT）、応用などはIIIFマニフェストの調理法も参照してください。 基本はカンバス 共有カンバス（Shared Canvas） カンバス上に画像などを「描く」（motivation:painting） 縦横のサイズ（width、height）＝アスペクト比を持つ アスペクト比は画像の縦横比と一致させる → 不正確だと不具合の元 多くは1カンバスに1枚の画像だが、複数画像でもカンバスの一部にでも テキスト注釈はotherContentとして外部から与える（v2の場合） 注釈としてのカンバス Web Annotationモデル
JISコードとASCIIコードの対応関係を把握すると、文字化けの理屈（？）が少し分かりやすくなります。代表的な例をとりあげて、文字化けの解読法を探ります。 ※文字化けと文字コードの関連を詳しく解説した『プロフェッショナル電子メール』を上梓しました。 JISコードとASCII ESCの抜け落ちたJISコード なぜか8ビット目が追加された場合 部分的な欠落 解読の行き過ぎ JISとASCIIの対応表 JISコードとASCII 「日本語と文字コード」や「インターネット上でのJISメールについて」で述べたように、JISコードによる日本語メールのやりとりは、[ESC]文字と$Bや(Bなどの文字を組み合わせた「エスケープシーケンス」で、文字セットを切り替えています。この[ESC]文字が抜け落ちるのが、文字化けの原因の一つでした。 JISコードはASCIIコードと同じビットパターン（1と0の組み合わせ）
このページの一部の例リンクは、外部JSONを取得する時に混合コンテンツ問題が生じないよう、意図的にhttpスキームを用いています。 画像URI（拡張子.jpgなどで判定、もしくはforce as imageをチェック）を与えると、注釈作成ツールとして機能します。追加・作成した注釈は「Show JSON-LD」ボタンで表示して、適宜保存してください。auパラメータ（additonal uri）で注釈JSON-LDを与えると、最初のURI（uパラメータ）で取得した画像に注釈を追加し多重化できます（dual panelなら左右表示）。注釈はフォームから与えることも可能です。なおこのツールは当サイト専用ではなく、スクリプトなどをコピーしてどのサイトでも利用できます。 Note some of example links in this page intentionally use http sch
他の情報と組み合わせるときは個々に明示が必要 属性（著者）と値（小田島雄志）だけでは、他の情報と組み合わせた時に混乱する 対象を加えた3つの要素による情報記述 対象＝主語、属性（関係）＝述語、値＝目的語のトリプルを用いて記述 主語と目的語で表されるものをノード（節点）とし、述語（関係）のアークで結んだグラフとして表現できる グラフは共通のノードを繋いで広げていくことができる＝複雑な情報を表現できる 複雑な情報も単純なトリプルに分解して扱うことができる グローバルなつながり グローバルな識別子 単語だけでは表記の揺れや同名があり、情報の同定、区別が難しい 「小田島雄志」と「小田島，雄志」、いろいろな「ロミオとジュリエット」など 主語、述語、目的語をURIで表して曖昧さを取り除く コンピュータで直接処理できるデータ（文字列）はURIで指し示すことなくそのまま（リテラル）で扱う URIによる識別
データモデリングと実体 属性―値対としてのデータ記述 フラットな表によるデータの記述 実体の関係としてのデータモデル 独立した存在として情報を付与できるものを実体（entity）と捉える。実体は属性（attribute）を持つことができる。 データを実体間の関連（relation）として捉える（ERモデル） 目録データの中の実体 目録データにおいて実体として捉えられるもの 監督、原作、製作会社、配給などは実体と考えられる 映画そのものも実体だけれど、目録データのどこに？ 製作年月日などは実体？ FRBRがとらえる実体 FRBRの実体のグループと関係 FRBR＝書誌レコード（データモデル）機能要件の検討結果 書籍だけでなく、映画を含む多くの作品表現モデルから参照されている 作品に関連するグループ1、エージェントのグループ2、主題などのグループ3で構成 グループ1には作品、表現形、体現形、アイ
次のページ
このページを最初にブックマークしてみませんか？
『The Web KANZAKI -- Japan, music and computer』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く