はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
ちょっとしたメモ - Tim Brayのurn:tag:スキーム案
Tim Brayが2月1日の記事「Tag Scheme?」で、URNのNIDとして"tag"を導入し、urn:tag:というスキームで「タグ」を識別するというアイデアを示した。これを受けて、コメント欄などでちょっとした議論が展開されている。もともとはAtomフィードのcategory要素のscheme属性のために使おうというものだったようだが、タグ文字列がそのままURIに対応することになるので、面白いと同時に危うい面も併せ持つURNだ。 コメント欄に出ている意見は、概ね次のような感じ。 わざわざ新しいURNを登録しなくても、http:で同じことができる、あるいはURNでは参照を辿れないからhttp:の方がよい。 タグあるいはカテゴリを一意に示すには、WikipediaのページURIを利用すればよいではないか。 タグをURIで表すとき、geo:lat=...のような「マシン・タグ」との関係を
HTTP Vocabulary in RDFのWorking Draft第1版が公開
HTTP Vocabulary in RDF - W3C Working Draft この草案では、HTTPとURI関係のボキャブラリ（RDFクラス）が定義されている。 HTTPのボキャブラリ（http://www.w3.org/2006/http#）にはhttp:GetRequestやhttp:PostRequestをはじめ、http:Responseなど、HTTP1.1（RFC2616）で定義されているリソースが網羅されている。今後RDFでHTTP上のやりとりを記述する場合は、このボキャブラリを使用することになるだろう。 なお、RFC2616およびRFC4229で定義されていない独自のヘッダーフィールドに関してはhttp:additionalHeaderプロパティを使用して表現することになる。この場合、フィールドの内容はRFC822に従う必要があり（X-などの名前を付けるなど）、専用の
RFC 3986 - Uniform Resource Identifier (URI): 一般的構文
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
高木浩光＠自宅の日記 - 最高裁判所が電話してというので電話した
■ 最高裁判所が電話してというので電話した ボツネタ日記の「新しい裁判所のＨＰにリンクを貼ったときは，その旨を電話で連絡しなければならないようです。」というエントリを見て、裁判所Webサイトがリニューアルしたのを知った。 リニューアルした裁判所Webサイトには新たにプライバシーポリシーのページができていたのだが、その内容に誤りがあるため、それについてメモをとった。 裁判所Webサイトにリンクしたときは電話で連絡するよう留意せよとのことなので、出勤前の朝10時ごろ、指定されている最高裁判所事務総局広報課の番号に電話した。 私: 内線XXXXお願いします。 裁: はいお待ちください。……。ただいまお話し中です。 私: そう……ですか。 裁: 見学ですか？ 私: いえ違います。 裁: 少々お待ちください。 ………… 裁: はいもしもし。 私: 裁判所Webサイトにリンクを設置しました。その場合電
URI? URI-reference? -- nulog > 2005 > 09 > 17
IRC ネタ。RFC2396 ではフラグメントを含まないのが URI らしい (フラグメント含むのは URI 参照。なんで区別があるのかは知らん) のだけど、みんな (誰) が知っているとおり、HTML の a 要素 href 属性にはデータ型が URI にも関わらずフラグメント書いたりしちゃってるわけで、しかも XMLSchema の anyURI 型も例にフラグメント含めたやつを書いていたりしちゃってるわけで、てんで意味不明だよボケと突っ込みたいところだけど、その RFC2396 を RFC3986 が上書きした (今年の一月) らしく、ちゃんとフラグメントつけても URI って言えるみたいです。よかったよかった。 該当部分を抜粋する。 URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] URI = scheme
変わらないURIこそがクール - 徒書
クールなURIは変わらないとはよく言われますが、この文章、そしてその題名の意味するところは、最も重要なのは変わらないことであるということだと思うのです。つまり言い換えれば、「変わらないURIこそがクールである」ということであり。 クールなURIは変わらないの後半部分ではURIの設計について述べられていますが、これはあくまで、これから作るウェブページやシステムについて、どんなURIにするかをあらかじめ考えるための指針であり、目的のための手段だと思うのです。目的はやはり「URIを変えないため」であって、これこそがクールであるために欠かせないものです。 クールなURIは変わらないを読んで、「そんなこと言われても、もう".html"とか"/cgi-bin/"が入ったURIでサイトを作ってしまったのにどうしたらいいのか」と嘆く人もいるかもしれません。しかし解決法は簡単で、ただURIを変えなければよい
drry @-> MultiViews のための拡張子戦争が終結
このエントリで書かれている内容は、今となっては時代遅れで陳腐な廃れた内容です。真に受けず、十分にご注意ください。 Trackback で送信される permalink から拡張子を抜く方法に終止符が打たれた。 これまでのおさらいだ。読み飛ばそう。Apache の MultiViews を利用して URI から拡張子 (e.g.: .html .php ) を除去する場合、Movable Type では各テンプレートで MTEntryPermalink を用いずに permalink URI を出力させる工夫をしてきた。サイト内に関してはそれで完結するが、対外に向けて送信され、システマティックにリンクを生成する trackback において送信される permalink URI には拡張子が付いてしまう。そこで私はこれまで、trackback で送信される permalink URI に小細
yohei-y:weblog: 良い URI の設計
URI は綺麗であるべき、と常々思っているんですが、よいページを発見しました。 Michael Eakes のこのエントリです。 Tanya Rabourn がリストアップしている文献一覧からエッセンスをまとめてくれています。 曰く、よく設計された URI とは 変らない(don't change) 人間が推測可能(are human guessable) 論理的(ファイルシステムを反映する必用がない) (are logical (no need to mirror a filesystem)) サイト構造をビジュアライズするのに役立つ(help visualize the site structure) 短い(are short) 小文字を使う(use lowercase) 予期されない記号を使わない(don't use unexpected punctuation) 問合せパラメータな
＠IT：DNS Tips：Punycodeって小さなコード？
Punycode（“ピュニコード”と発音）はRFC 3492で定義されるUnicodeの符号化方式の1つで、国際化ドメイン名（Internationalized Domain Name： IDN）を従来のASCIIドメイン名と互換性のある形式（ASCII Compatible Encoding）で表現するために考案されたものです。 インターネットではUnicodeの符号化方式としてRFC 2279で定義される8bit符号化方式のUTF-8を採用するのが一般的ですが、DNSは7bit符号化方式のASCIIを前提としており、IDNでは下位互換性を保つためにPunycodeが採用されています。 なお、PunycodeはPuny（小さな）とCodeを組み合わせた造語で、 Punycodeの考案者が以下の理由で名付けました。 Unicodeの符号化方式でありUnicodeと韻を踏んでいる Punyc
ＩＳＢＮ規格改定のお知らせ
ISBNコード 日本図書コード 書籍JANコード ご利用手引き ダウンロードはこちら Services available services ISBNコードの取得 ISBNコードの新規・追加発行 書籍JANコードの追加 登録出版者の照会 I発行された出版者記号情報を照会 ISBNコードの検算 チェックディジットを確認 登録情報の変更 メールアドレス、 担当者、住所、 電話番号等の変更 よくあるご質問 FAQ 当センターについて 日本図書コード管理センターとは ISBNコードとは More Services 12月 22,2017 Front はコメントを受け付けていません。 お知らせ 2020.09.24 重要なお知らせ 9月25日(金)から30日(水)まで棚卸業務のため、新規出版者登録を停止いたします。 新規登録のお申し込みが9月24日(木)以降になった場合、コードの 発行が10月1日以
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://afewurls.com/
http://rails.office.drecom.jp/takiuchi/archive/112
shortText.com - Post information. Share it.
The data: URI kitchen
search.cpan.org: 莉洛 / WWW-Shorten-KUSO-0.1
Zovirl Industries
(http スキーム
専門家は個人の責任で情報発信するな - void GraphicWizardsLair( void ); //