|
このページは転職・就職類義語辞典が 2006年 12月 01日 06時00分46秒 にクロールしたキャッシュ情報です。
|
検索キーワード＝ 転職 就職 再就職 ハローワーク インターンシップ
優先キーワード＝ 転職 就職 再就職 ハローワーク インターンシップ
[ 96] 総務省(情報公開)
[引用サイト] http://www.soumu.go.jp/menu_06/jyouhou_koukai/index.html
「行政機関の保有する情報の公開に関する法律」（平成１１年５月１４日法律第４２号）に基づき、誰でも、総務省が保有する行政文書の開示を請求することができます。
行政機関の保有する情報の公開に関する法律（平成１１年５月１４日法律第４２号。以下「情報公開法」といいます。）に基づき、行政機関の保有する情報の一層の公開を図ることを第一次的な目的とし、政府の保有するその諸活動を国民に説明する責務が全うされるようにするとともに、国民の的確な理解と批判の下にある公正で民主的な行政の推進に資することを高次な目的とし、国民のみなさまに行政文書を開示する制度です。
職員が職務上作成・取得した文書、図面、電磁的記録で職員が組織的に用いるものとして、行政機関が保有しているものが対象となります（これを「行政文書」といいます。）。
ただし､書籍等の市販物や､博物館､公文書館その他これに類する機関において､一般の閲覧に供するために特別の管理がされている歴史的資料等は除かれます｡
開示請求の対象となる行政文書は、行政文書ファイル管理簿を作成して、一般の閲覧に供することとされています。
情報公開法では、開示請求があったときは行政機関の長は、不開示情報が記録されている場合を除き、行政文書を開示しなければならないこととされています。
５ 審議・検討等に関する情報で、意志決定の中立性等を不当に害する、不当に国民の間に混乱を生じさせるおそれがある情報
行政文書開示請求書（DOC､PDF､記載例（PDF))に必要事項を記入して、１件につき、開示請求手数料（PDF）として ３００円分の収入印紙を貼付の上、開示請求窓口に提出してください。（開示請求窓口で直接現金でお支払いいただくことも可能です。）
郵送による請求もできます。郵送による場合は、文書の行き違いを防ぐため、封筒に「情報公開請求関係」と朱書きしていただきますようお願いいたします。
電子政府の総合窓口（e-Gov（イーガブ））から請求手続ができます。当該ページの記載に従って操作をしてください。オンラインによる請求の場合の開示請求手数料は１件につき２００円となります。
開示請求手数料及び開示実施手数料の納付は、財務省の歳入金納付システムを利用したオンラインによる電子納付の他、印紙又は現金による方法でも可能です。
ただし、印紙による場合は開示請求書又は開示の実施方法等申出書の控えに印紙を貼付し、開示請求窓口に郵送するか、持参していただく必要があります。また、現金による場合は開示請求書又は開示の実施方法等申出書の控えを開示請求窓口に持参していただき、直接現金でお支払いいただく必要があります。
本省の所有する行政文書の開示請求窓口として、本庁舎２階に「情報公開閲覧室」(PDF)を設置しています。
なお、各地方支分部局、施設等機関の保有する行政文書の開示請求については、各機関(PDF)でそれぞれ受け付けておりますので、当該機関等までお気軽にご相談ください。
開示するかどうかの決定は、原則として、請求のあった日から３０日以内に行い、 書面により通知します。（オンラインにより請求された場合はオンラインでも通知します。なお、請求されたその場で直ちに公開することはできませんのでご注意ください。）
事務処理上困難である等の理由により、この期間内に決定できないときは、開示決定等の期限を延長する旨、延長後の期間等を通知します。
開示決定の通知を受けた方は、開示の実施方法を選択し、通知のあった日から３０日以内に「開示の実施方法等申出書」を情報公開窓口に提出して、開示の実施を申し出てください（開示請求をオンラインで行われた方は、「開示の実施方法等申出書」の提出もオンラインで行うことができます。）。
なお、写しの送付を希望される場合には、開示実施手数料のほかに、送付に要する費用（郵便切手等）が必要になります（開示請求をオンラインで行われた方は、電子納付の方法により、送付に要する費用を納付することができます。）。
開示実施手数料の額は、行政機関の保有する情報の公開に関する法律施行令（平成１２年２月１６日政令第４１号）別表第１（PDF）を参照して下さい。
不服申立てがあった場合には、原則として、行政機関は情報公開・個人情報保護審査会に諮問した上で、不服申立てに対する決定を行います。
また、行政事件訴訟法に基づき、国を被告として決定の取消しを求める訴訟を提起することもできます。
|
[ 97] RSS(RDF Site Summary)によるサイト情報の要約と公開
[引用サイト] http://www.kanzaki.com/docs/sw/rss.html
メタデータ/RDFの応用として利用されているXMLフォーマットの代表として、RSS (RDF Site Summary) があげられます。共通の書式でドキュメントの見出し、要約などのリストを提供することで、サイトの更新情報などを効率的に公開できます。また、サイト情報以外にもさまざまなメタデータ公開のためのコンテナとしての可能性を秘めており、積極的に活用するとウェブ上の情報共有の新しい姿が見えてきそうです。
RSS (RDF Site Summary) は、サイトの概要をメタデータとして簡潔に記述するXMLフォーマットです。1999年にRSS 0.9が登場して以来、さまざまな議論や変遷を経てきていますが、本稿ではRSS 1.0（RDFとXML名前空間に基づき、拡張性と「メタデータ配信」の可能性を持つ）を紹介していきます。
上記のリストで、要素型名の後ろに?のあるものはオプション、+のあるものは1回以上の繰り返しを示します（ここではRSS 1.0の最小限の構成要素のみを取り上げています。全要素のリストは、後ほど示します。なお本稿では、デフォルト名前空間がRSS、rdf:はRDFの名前空間接頭辞を示すものとして扱います）。
以下、当サイトが「コントラバスの話」と「ごく簡単なHTMLの説明」という2つのリソースを持つことを示すRSSを記述する例を考えながら、RSSの要素型と構文を簡単に説明していきましょう。
RSSはもともと「チャンネル」情報を提供するために開発されたので、基本情報はchannel要素に記述します。この要素はRDFのDescription要素と同様に主語ノードを表す役割を持ち、rdf:about属性でチャンネルのURI（通常このRSS自身のURI）を示します。channelの内容となる要素は次のものです。これらは、このチャンネルの「プロパティ」に相当します。
RSSでサマリー対象とするサイトのURI。ホームページや新着ページのURIが一般的だが、特定のページやセクションのサマリーをチャンネルとする場合はそのURI
チャンネルのロゴなどがある場合に記述。イメージのURIをrdf:resource属性で示し、さらに具体的内容をrdf:RDF直下のimage要素に記述する
channelに続くitem要素で記述するリソースの目次に相当。リソースのURIをrdf:li要素のrdf:resource属性で示し、これらをitem要素と対応させる
チャンネルと共に検索用のフォームなどを送る場合に使う。古いRSSとの互換性のために残されているが、あまり使われない
これらの要素を使って、当サイトのチャンネルを記述してみます。このRSSは、http://www.kanzaki.com/info/rss.rdfでアクセスできるものとします。とりあえずimage要素とtextinput要素は使いません。
items要素はRDFのリストとなるので、rdf:Seq、rdf:liといったタグを用いてRDFのコンテナモデルとして表現することに注意してください。この目次に示したリソースについて、次のitem要素で見出しや要約を記述していきます。
channelのitems要素で目次として示したリソース（記事、文書など）それぞれについて、item要素で具体的に内容を説明します。それぞれがリソースを記述するので、rdf:about属性で対象URI（主語）を示します。このURIは、対応する目次項目（rdf:li要素）のrdf:resource属性値（URI）と一致させなければなりません。
item要素内では次の要素を用いてリソースを記述します。これらは、各リソースの「プロパティ」という訳です。
RSS 1.0ではitem要素の数は1つ以上で上限はありませんが、RSS 0.9との互換性を考えるならば、15までにしておくことが推奨されています。文字数に関する推奨も、後方互換性のためです。
これらの制約は近い将来取り除かれる方向で検討されており、あまり気にする必要はありません。ただし、description要素に日記やblog記事の全文を記載すると、コンパクトなサマリーを期待する読者には歓迎されないかも知れないので、description要素は短くとどめ、全文は後述するContentモジュールのcontent:encoded要素に記述すると良いでしょう。
ここまでで取り上げた要素を組み合わせることで、サイトを紹介するための基本的なRSSを作成できます。必要な名前空間宣言を持つルート要素を加え、全体を構成してみましょう。目次（rdf:li要素）のrdf:resource属性で示したURIが、それぞれのitem要素のrdf:about属性値に対応していることを確認してください。
以上の簡単な要素を揃えるだけで、チャンネルを公開してサイトの情報を提供することができるようになります。この手軽さが、RSSが幅広く支持されている大きな要因です（RSSの公開などについては、末尾の「RSSの実際の利用」セクション参照）。
デフォルトはutf-8とされています。正しく文字コード情報を提供すればどんな符号化方法でも良いはずですが、一部のRSS処理ソフト（のXMLパーサ）は、utf-8でないと正しく働かないことがあるようです。
ファイルとして保存する場合の拡張子は、.rdfもしくは.xmlが推奨されており、前者がより望ましいとされています。
現時点ではapplication/xmlとなっていますが、[RFC3023]で示されるXMLのメディアタイプが確定したら、それに従うこととされています。
ここまでで取り上げなかったものも含め、RSS 1.0を構成する要素全体をツリーとして示しておきます。各要素の出現順序もこの通りに定められていますは特に定められていません。（以下のimage要素、textinput要素はあまり使われません。むしろ日付などの要素を取り込むためのモジュールの方が重要です）。
image要素はサイトのロゴなどの画像を示すために用います。扱いはitem要素と同様ですが、複数を指定することはできません。具体的には、channel内のimage要素でrdf:resource属性を使って画像の存在を示し、channel要素の次にimage要素を置いてtitle,link,urlの各要素を記述します。
image要素でrdf:about属性を用いるのも、item要素の場合と同様です。title要素は、一般に画像の代替テキストとして扱われます。また、linkは画像をアンカーとしてリンクを設定する場合のリンク先となり、画像自身のURIはurl要素に記述します。
チャンネルの最後に、検索などのためのフォームを付け加えることを想定しています。フィールドを一つしか送ることができないため、柔軟性に乏しく、RSS1.0では“RSS0.9との互換性のために残されている”となっています。一般にtitle要素を（チャンネル受信側で生成する）フォームの見出し、description要素をラベル、link要素をaction属性の値として用います。他の要素にないname要素は、テキスト入力データの名前（input要素のname属性）となります。
[例3]のXML構文をRDFモデルとして表現すると、channel要素のrdf:about属性で示したリソースを主語として連鎖的に叙述するRDFのグラフを描くことができます。
グラフを見ると明らかなように、このRDF(RSS)が記述するステートメントの主語は、それぞれのrdf:about属性が示すリソースです。「サイトのサマリーを示すメタデータ」なのだから主語（channel要素のrdf:about属性の値）はサイトそのもののURIを用いるべきという気がするかも知れません。しかしRSSは「チャンネル」を記述するものなので（主語リソースはchannelクラスのインスタンス）、RDFとしてはチャンネルすなわちRSS自身が主語になります。
要約対象となるサイトは、主語チャンネルからlinkプロパティによってそのURIを示されていますが、これはただのリテラルであり、RDFとしてリンク先リソースを示すかたちになっていません。古いRSSの書式と整合性を取るためにこうなっているわけですが、やはりサイトもリソースとして示す方が意味が（エージェントなどにとって）明確でRDFとしては望ましい構文だったはずだと言えるでしょう。なお、rdf:aboutとlinkを巡る背景は別文書RSS 1.0のchannel要素のrdf:aboutを参照。
channel要素内で目次としてrdf:resource属性でリソースを示し、同じものをitem要素でまたrdf:about属性として示すのは冗長に感じられるかも知れません。これはRDFの構造化モデルで説明したような、ステートメントの目的語が別のステートメントの主語となる文の一例です。[例3]の構文は、次のようにしてchannel内のitems要素にitem要素の記述を直接埋め込んでも、RDFのモデルとしては等価で、[図1]と同じグラフが得られます。
[例3]のようにitem要素をchannel要素の外に出すほうが、それぞれのリソースを記述するという意味が（人間がXMLを読み書きする時には）分かりやすいかもしれません。それにその方がRSS 0.9の構文に近いので、互換性のためもあってitem要素がchannel要素の外に出されているのでしょう。[例6]はRDFモデルとしては同等ですが、構文が異なるので、RSSアプリケーションがうまく処理できるとは限りません。もっともchannel要素内にitem要素が含まれるという形は、逆にRSS 0.91のモデルに近いので、そのまま処理できてしまうことも多いと思いますが。
また、item要素内のlink要素はrdf:about属性と重複していて蛇足なのですが、rdf:aboutはこのアイテム（コンテンツ）を識別するためのID、linkはハイパーリンクのURLを示し、理屈の上では異なるURIとなることもあり得ます。とはいえ、通常は両者は同じと考えられるので、やはりRSS 0.9との互換性としての意味合いが大きいのでしょう。
RSS 1.0はXML名前空間を利用した拡張性を重要な特徴としています。名前空間を宣言してCreative CommonsやFOAFといったポピュラーな語彙、あるいは独自の要素型を追加することもできます。より高い相互運用性のために、RSS-DEV Working Groupで拡張語彙の標準「モジュール」を定めています[RSSMOD]。
現在一般に利用されるのは、Dublin CoreモジュールとSyndicationモジュールの2つです。RSSを利用するプログラムの多くは、これらのモジュールを理解します。また、blogの人気に伴いContentなどほかのモジュールも広まりつつあるようです。
コンテナとしてのRSS：RSS1.0の拡張性利用し、さまざまなメタデータの公開・配信のための「コンテナ」として応用することができます。例えばFOAFとRSSを用いた画像メタデータやRDFカレンダーなど。この可能性については、また改めて検討します。
標準的なメタデータ記述要素として用いられるDublin CoreのDCMESを利用するモジュールです。
使い方は簡単です。ルート要素のタグに名前空間の宣言 xmlns:dc="http://purl.org/dc/elements/1.1/" を加え、DCMESのプロパティを使って作者や更新日付などの情報を記述します。名前空間の接頭辞をdc:とすること、これらは第2レベル（rdf:RDF要素の直接の子供）であるchannel, image, item, textinput各要素の直接の子供として（つまりプロパティ要素として）のみ使用することがモジュールで定義されています。またDCMESの修飾子はいまのところサポートされていません。
このモジュールは、チャンネル自身やそこで記述するリソースの更新日を示すのに特に有益です。ニュースヘッドラインなどの情報は、日時の情報がとても重要なので、それを共通の語彙を用いて明記できるメリットは大きいでしょう。dc:dateの形式はYYYY-MM-DDThh:mmを用います[W3CDTF]。
dc:subjectを用いてコンテンツの分野や分類を示すのもよく使われる方法です（SharpeaderやNewsGlueなどいくつかのRSSリーダーでは、Subject/分類として一覧に表示してくれるようです）。また、RSS0.91ではチャンネルのlanguage要素が必須だったので、これに代わるものとしてdc:languageを使うこともあります。
米国製blogツールのテンプレートをそのまま使って、日本語コンテンツなのに言語情報をen-USなどとしないよう注意してください。xml宣言のencodingをutf-8にしたままShift_JISのRSSを送り出している例もよく見かけます。
シンジケーションとはニュースの記事などを配信（配給）するサービスのことです。ウェブ上でも、ニュースサイトなどが最新のヘッドラインを「チャンネル」という形で配信することがありますが、この手段としてRSSが広く使われています。
「配信」といっても、RSSのようなウェブ上のリソースの場合は、基本的はプッシュ型ではなく利用者が情報をチェックしに行かなければなりません。その際、どんな頻度で情報が更新されているかが分かると都合がよいため、Syndicationモジュールの語彙を用いて更新予定を示します。
updatePeriodと関連づけ、その期間中に何度更新されるかを示します。たとえば、updatePeriodがdailyでupdateFrequencyが2ならば、1日2回更新するという意味です。省略時は 1 とみなされます。
上記の要素から次回更新予定時を計算するための基準を示します。一般には、前回の更新日時をYYYY-MM-DDThh:mmの形式[W3CDTF]で示します。
このように記述してあると、“この「チャンネル」は毎日更新されているので、毎日チェックしてください”ということを意味します。
XHTMLによるマーク付けなどを含めた、コンテンツをそのまま配信するためのモジュールです。ウェブログツールのRSSテンプレートに含まれていたりするので、最近見かけるようになってきました。提案当時の構文と、改訂された構文がありますが、新しい方だけを取り上げておきます。
マークアップ記号を実体参照に置き換えるか、CDATAセクションとして、コンテンツそのものを記述します。
提案当時は複数のフォーマットのコンテンツを使い分けることなどを想定していましたが、実質的に使われているのは改訂仕様のcontent:encoded要素のみです。
Contentモジュールに対応するビューアで表示すると、次のような具合になります（img要素などを埋め込む場合、パスを絶対URIにしておかないとうまくいきません。xml:base属性を使ってもいいはずですが、必ずしも対応していないようです）。当サイトのRSS Feed Readerは、この要素を折り畳んで表示します（例：音楽雑記帖RSS）。
実際のマークアップなどをそのまま扱う場合、次に述べるセキュリティの配慮が重要です。また、CDATAセクションやエスケープ（<など）を使って、ただのテキストでしかないはずの要素をマークアップを含む（子要素がある）ように扱わせるのは、エラーの温床となる危険性もあり、大きな問題を孕むと指摘されていることも注意してください[WALSH]。
Trackbackモジュール：ウェブログなどのシステムでよく使われるトラックバックに関するURIを、記事のメタデータとしてRSSのアイテムに記述するための語彙です。このモジュールについては「RSSとトラックバック」で簡単に検討しています。
Annotationモジュール：記事が参照したりコメントしたりしている相手のURLを記述するreferenceという語彙を定義しています。このモジュールについては上記「RSSとトラックバック」内の「RSS 1.0のannotationモジュール」でごく簡単に説明しています。
Eventモジュール：イベントの開始日時、終了日時、場所などをRSSで配信しようというモジュールです。シンプルで使いやすいものの、構文上若干問題があるので、RDFicalを使う方がよさそう。RDFical（RDFカレンダー）のページで、Eventモジュールも少し取り上げています。
Taxonomyモジュール：チャンネルのアイテムを分類する（トピックを示す）ために使います。dc:subjectと似ていますが、taxonomyではキーワードを文字列ではなくURIで示します。メモ帖のRSSのtaxonomyモジュールで、少し取り上げています。
RSSのような分散型のアプリケーションでは、セキュリティに対する配慮が欠かせません。RSSの利用方法は、ほとんどの場合読みとりのみだと考えられるので、それほど重大な問題はなさそうですが、RSSを処理してブラウザなどに表示させる場合、ごく一般的なCGIと同等の注意は必要です。
表示要素内にHTMLのタグや特殊文字が含まれている場合の処理。特にscript要素などが勝手に働かないよう、エスケープ処理をする
link要素、rdf:about属性値などに、javascript:スキームのような特殊なURIが記述されている場合のチェック
RSS1.0の仕様では、urlおよびlink要素で許されるスキームはhttp:、https:、ftp:（textinput要素ではこれに加えてmailto:）に限るとしていますので、これに合わせたチェックをするのも良いでしょう。javascript:に関しては、Kevin A. Burtonによって仕様書にセキュリティの章を追加する提案が出されています[BURTON]。
RSSは、実際にはどんな具合に利用されているのでしょうか。最近では新しい情報をRSSとして提供するサイトが増えてきており、それを読むための「Feed Reader」プログラムもいくつか提供されています。また、簡単なスクリプトで自分のサイトのRSSを自動生成して公開することも可能です。
日本で配布されているRSSファイル -- 精力的にRSSを収集し、埋め込み用スクリプトも配布。頑張れ！
My Portal -- （2002-03でサービスを終了したそうですが、関連記事とリンクが残されています）
主要なサイトが公開しているRSSを取り込んで、自分用のディレクトリ（ポータル）をつくるのもいいでしょう。現在提供されているRSSをいくつかあげてみます（RSSそのものはXMLなので、ブラウザで見てもそれほど読みやすくはありません）。現状はRSS 0.9/0.91/1.0が混在しています。
多くのウェブログツールは、テンプレートを使ってRSS生成の設定ができます。また、更新が頻繁なサイトは自動化しないとRSS生成が面倒になってしまうと思いますが、たまに更新するものについてRSSを提供したり、試しにRSSを自作してみようという場合には、テーブルに必要な要素を記述することでRSSを生成してくれる次のようなツールが便利です。
これらのRSSはXSLTも指定していますので、対応ブラウザ（IE5など）であれば、当サイトの新しい情報を効率的にご覧いただくのに便利です。
多くのRSSリーダーは、定期的にフィードをチェックして取得できるようになっていますが、プログラムによってはLast-Modifiedヘッダなどを考慮せずに毎回GETをかけていくものがあるので、利用にあたっては設定に注意してください。こうしたツールで頻繁に巡回すると、相手のサーバーに負担をかけてしまいます（各アイテムのリンク先コンテンツまで毎回全部GETするツールなど、もってのほかです）。
アイコンは、RDFによって記述されたリソース（RSS 1.0など）を示すために、Dave Beckettによって提供されているシンボルです。画像に埋め込まれたメタデータをそのまま保持することを条件に、自由に利用できます。お気に召したら、ご自身のサイトにコピーの上ご利用ください。なお、形式をGIFに変換することは認められていません。
最初のRSSは、Netscape社が自社のポータルMy Netscapeに「チャンネル」を登録するための手段として1999年3月に開発・公開した、バージョン0.9と呼ばれるものです[NS-RELEASE]。これはもともとRDFベース (つまりRDF Site Summary) で、基本的には見出し一覧を配信するためのものでした[RSS09]。1999年7月には、概要を記述するdescriptionなど、UserLandのScriptingNews規格から10以上の要素型を取り入れたRSS 0.91が登場します[RSS091]。見出しだけでなく要約、格付け、著作権、更新日付などさまざまな情報も加えたサイトサマリーを提供できるところからRich Site Summaryと呼ばれ、何割かのコンテンツプロバイダはこの新しいフォーマットを採用しました。ただしRSS 0.91では、RDFはチャンネル作成者にとって複雑だとして、ルート要素をrssとする独自のXMLに変更されています。
その後Netscape社はRSSから手を引きますが、サイトサマリーを提供する枠組みとしてのRSSへの要望はむしろ高まり、これに独自の要素型を加味して用いるユーザーも出現するなど、混乱の様相を見せてきました。そこで、
という新しい規格が、改めてRDFに基づくものとして開発者のグループ（RSS-DEVワーキンググループ）で検討されました。この成果として2000年12月に提案されたのがRSS 1.0です[RSS10]。RSS 0.9およびRSS 0.91も依然として用いられていますが、本稿ではRSS 1.0をこれから注目すべき規格と位置づけ、紹介しています。
RDFや名前空間が複雑であるとして、RSS 0.91を拡張したRSS 0.92/0.93を提案するコミュニティもあり、その延長として、2002年8月にRSS 2.0なるものが出てきました（これはRSS 1.0の発展形ではなく、RSS 0.91/0.92 etc.にあれこれ付け足しをしたものですが、一部名前空間を使うようになっています）。それならいっそ、古き良き電子メールスタイルのテキストで単純なRSS 3.0をつくったらというブラックユーモアが出たり[SWARTZ]、逆にRSSを乗り越えて新しいフォーマットをつくろうというAtomのような試みも行われています。
RSS 0.9/1.0はヘッドラインなどの「メタデータ」を扱うことに主眼をおいているのに対し、RSS 2.0やEchoは、RSSを「コンテンツ配信」の手段に拡張しようという考え方で、同床異夢的なところがあります。当サイトは、「メタデータ」配信の可能性、標準やほかの規格との親和性、および拡張性という点から、RSS 1.0を推奨します。なお、RSSの歴史と概要についてはAndrew KingのThe Evolution of RSS[KING]、MCFやCDFまで遡った経緯とRSS 0.91/1.0の論争の背景についてはDan BrickleyのHistorical debt[BRICKLEY]などを参照してください。
〔注意〕サイト要約のフォーマットRSSとメタデータ記述の枠組みRDFを混同しないでください。RSS⊂RDFでもRSS⊃RDFでも、ましてRSS＝RDFでもありません。
|
戻る
|