セマンティック Web 技術と次世代電子政府での活用方法に関する調査研究

調査報告書

付録３

MIReG メタデータ要素セット
オリジナルドキュメント： Draft v0.1 January 2002
The MIReG Metadata element Set.
目次

１. はしがきと背景 .............................................................................................................. 2
１.１
改版履歴 ............................................................................................................. 2
１.２
本文書について................................................................................................... 2
１.３
MMES メタデータ基本方針 ............................................................................... 2
１.４
必要性 ................................................................................................................. 3
１.５
ネーム空間.......................................................................................................... 3
２. AUDIENCE.................................................................................................................... 5
３. CONTRIBUTOR ............................................................................................................ 5
４. COVERAGE ................................................................................................................... 7
５. CREATOR ......................................................................................................................9
６. DATE ............................................................................................................................ 10
７. DESCRIPTION ............................................................................................................ 12
８. DISPOSAL ................................................................................................................... 13
９. FORMAT ...................................................................................................................... 14
１０. INDENTIFIER ......................................................................................................... 15
１１. LANGUAGE ............................................................................................................. 16
１２. LOCATION............................................................................................................... 17
１３. RESERVATION ........................................................................................................ 17
１４. PUBLISHER ............................................................................................................ 17
１５. RELATION ............................................................................................................... 18
１６. RIGHTS .................................................................................................................... 20
１７. SOURCE................................................................................................................... 23
１８. SUBJECT ................................................................................................................. 23
１９. TITLE ....................................................................................................................... 25
２０. TYPE.........................................................................................................................27

1

１.はしがきと背景
１.１
v.0.0
v.0.1

１.２

改版履歴
2001-08-13
DC-GOV により近くなるように更新。MIReG 諮問委員会のメンバに 2002-01
配布
IDA TAC を通して国のメタデータ代表者に配布。
MIReG 諮問委員会のメンバに配布

本文書について本書は標準の EU メタデータセットである、MIReG Metadata Element Set(MIMES)の最初のドラフトであり、最大のインプットを得るために EU 内やそれ以外にできる限り広く配布されるべきである。
最終の MIMES はポリシーステートメントや使用ガイドを含む MIReG Metadata
Framework の部分を形作る。
国または EU の執行部で、メタデータの使用を標準化する努力が EU やその他の国々でなされている。EU 執行部におけるメタデータの協同や調整は MIReG 諮問気委員会で
行 わ れ て い る 。 MIReG プ ロ グ ラ ム の 設 立 と 目 的 に つ い て の 情 報 は
http://europa.eu.int/ISPO/ida/ を参照のこと。
MIMES を Dublin Core に基づかせる決定があるため、本作業に関わる者は EU 内や国際的な点での最大限の標準化を必要だと感じている。MIReG 諮問委員会は Dublin
Core Metadata Initiative(DCMI)や Government Working Group(DC-Gov)と協力して、拡張子を世界中の政府が使用するための Dublin Core へ開発している。これらの拡張子
は DC 基本方針の厳しい制約内で開発されており、MIReG メタデータ要素セットをヨーロッパ諸国の政府に合うように設定しようとする場合、追加を行う必要があったことは明らかであった。
コメントを求む！
より詳細な情報が必要であり、決定もまだ下していないため、特定の情報提供を望む。
テキストはボールドイタリック体で。
要素使用を説明した例や、見直しも歓迎する。

１.３

MMES メタデータ基本方針

独立で有るべし：ソフトウェア、アプリケーションもしくはプロジェクトベースであってはならない、しかし、任意の媒体中に存在する任意の情報を検索し、且つ、記録管理を可能にするよう柔軟でなければならない。
利用方法が単純であるべし：リソース記述を行う人が初心者であったとしても、標準は迅速に利用できるものでなくてはならない。
他の EC 標準と政策とに準拠すべし。
国際標準に準拠すべし：メタデータ標準は、国際標準とシステムを反映したもので在るべきである。もしも、国際標準が適切なものであり、かつ、随時更新されているならば、MIReG
Metadata Element の中に取り込まれるべきである。この場合、多くの国に指示される国際2

標準が優先する。すなわち、適切な国際標準は EU 標準より優先し、EU 標準は英国標準に優先する。
安定しているべし：標準の変更は、それを使っている総ての情報システムに対し非常な努力と時間と資源とを消費させる。それ故、MMES は、現在のニーズのみならず、将来のニーズに対応できる柔軟性を要求される。
拡張可能であるべし：既存セットで要求を満たさないことが明らかになった時点で、追加エレメントの見直しが可能でなければならない。拡張性と安定性とのバランスが必要である。
経済的であり、貨幣価値を生じること。
包含的であるべし：多くの既存のメタデータスキームを考慮し、既存のプロダクトの再開発を最小化すること。これは、相互互換性を最大化することとバランスをとること。何故なら、相互互換性の実現においては、総ての情報資源記述の間で共通の一貫性を必要とするので。
上記総て：情報検索と情報管理とが、EC の国民や、政府、又は執行部が必要とするものと
するため。

１.４

必要性

すべての要素は必要性のレベルに分けられている。そのレベルとは。
必須：当該要素は値がなければならない。
もし適用可能なら必須：情報が利用可能である場合、当該要素には値がなければならない。
推奨：データが、与えられた資源に対して適切である場合、値が与えられるべきである。
オプショナル：データが、与えられた資源に対して適切である場合、値が与えられるべきである。
必要性は全体として要素に適用する。値は、該当しない要素か、複数の詳細項目に付加することができる。

１.５

ネーム空間

XML ネーム空間は URI 参照で識別されている名前の集合であり、要素タイプや属性名として XML 文書内で使用されている。一意にメタデータ項を識別するための XML ネーム
空間の使用によって、メタデータ用語はアプリケーションで明白に使用され、共有された
セマンティックの可能性を広げている。ネーム空間についての詳細は Dublin Core のウェ
ブサイト www.dublincore.org をお勧めする。
XML によって、さまざまなネーム空間から要素や詳細項目を取り出すことが可能である。
以下は DCMI Usage Board の前の現在における提案からのものである。
もし承諾されれば、
MIReG Metadata Framework の一部となる。
Dublin Core Metadata Element Set Version 1.1[DCMES]を構成する DCMI 要素すべてに関しては、
http://purl.org/dc/elements/1.1/を使用すること。
DC-Gov を含む DCMI 要素と DCMI クオリファイヤ（上記の Dublin Core Metadata
Element Set Version 1.1 で定義している要素以外）に関しては、
http://purl.org/dc/terms/を使用すること。
3

DCMI Type Vocabulary [DCMI-TYPE]で定義している DCMI 用語用のネーム空間の URI
はhttp://purl.org/dc/dcmitype/
MIReG ネーム空間をセットアップして本文書に述べている追加の要素と詳細項目についての情報を含む必要がある。また、参加国や参加政府の求める追加の要素と詳細項目を保存することもできるべきである。
当該ネーム空間の場所と管理エージェントは今、決まろうとしている。

4

２.AUDIENCE
当該資源の利用者のカテゴリ。
必要性：オプショナル
反復性：有り本要素は次のように使われる。
・ 資源のレベル又は焦点を示す。
・ 意図した視聴者に合致したアイテムの検索のために、更なる選択、または、絞込みを可能にする。
ある資源の視聴者は、当該資源の最終受取人(例えば、生徒や受講者)、もしくは、当該資源のアクセスを仲介する者(例えば、先生や講師)であるかもしれない。
仲介者の詳細項目とは、後者を示す。
詳細項目は、教育分野に特化した組織により通常利用されることを想定している。そうであるが、健康及び社会サービスと言った他の領域でも意味がある。
例えば、もしも、当該資源が、社会保険受取人の情報を有しているならば、最終的な視聴者がサービスの受益者であるが、しかし、これに対するアクセスは、しばしばソシアルワーカにより仲介される。
もしも、実際値が当該要素から得られるべきであるならは、符号化スキームが必要である。
色々な教育分野用の符号化スキームが利用可能で、そして、間違いなく他のドメインの物が存在する。例えば、健康分野。我々は、これらを識別し、リスト化する必要がある。そして、必要ならば、EU 政府スキームを開発する。
詳細項目
Mediator

当該資源をアクセスするとき仲介するもの。

例
AUDIENCE: Head Teachers
AUDIENCE: Students MEDIAOR: Teachers
対応
Dublin Core
AGLS
NGDF
GILS

Audience (DC-ed 拡張子)
Audience

３.CONTRIBUTOR
当該資源の内容に対するコントリビューションの責任実体
必要性：もし、適用可能なら
反復性：有り5Contributor の例としては、人間または組織がある。
一般的に、Contributor の名前は、実体を指し示すのに用いられる。
“creator”要素に入っていない、当該資源の内容を作るのに重要な役割を果たした総ての人
もしくは組織を含む、
例：
CONTRIBUTOR: Photographs by ESA Media Relations, Paris. enquiries@esa.int
CONTRIBUTOR: Edited by Jacques Hansen, Ministeré de l’Agriculture at de la peche

For minutes drafted by a minutes secretary but for which responsibility forcontent belongs with the Chair of the meeting. (The Char will be entered in
the Creator Field)
書記局により作成された議事録案の為、また、議長に帰するべき内容に関し責任を負う為。(議長が誰かは、Creator フィールドで示される。)
CONTRIBUTOR: Drafted by Lars LØkke Knundsen Association of Country Councils.
Denmark IIK@arf dk
符号化スキーム：
対応
Dublin Core
AGLS
NGDF
GILS

Contributor
Contributor
Contributor

6

４.COVERAGE
当該資源の内容が、カバーする期間と場所
必要性：推奨
反復性：有り本要素は、特定の場所もしくは時刻に関する情報を検索し、特定するのに非常に有用である。データは通常、より範囲の広い Coverage より詳細項目の一つに絞られる。ほとんどの目的には基本的である時間的詳細項目と空間的詳細項目で十分であり、空間的参照などのような詳細項目は無視することができる。地図や特定の地域特有の統計は、より詳細な地
理的詳細項目から得るものがある。
‘Spatial’は、管轄区域、町、(New York 市の)独立区、選挙区、地域など。
もしも、当該資源が、複数の地域や期間をカバーするのならば、それらを表す為、本要素は繰り返し使用される。
セパレータとして、代替利用されることもある。(最初の例を参照)
正確な場所を特定できるよう充分に詳細化されているべきである。例、”Paris, Texas, USA”とは対照的に”Paris, France”
詳細項目‘Spatial referencing by coordinates(座標空間)’が用いられる時、関連する詳細項目の総てが記述されているべきである。
‘System of spatial referencing by coordinates(座標空間システム)’は、使用するスキームを指定する。例、’Irish National Grid’または’Latitude and Longitude’.
この場合、常に四つの座標値が必要である。
もしも、複数の座標空間システムで表す事に意味があるならば、この詳細項目は、繰り返し使用される。例、the Irish National Grid references 及び Latitude and Longitude.
‘Temporal’は、当該資源の内容によってカバーされる期間を示す。それは、その作成日や発行日ではない。その日付は、標準の W3C 形式のものであるべきである。例、yyy-mm-dd.
カバーする時間を正確に表すことが重要であり、それらを表すため他の詳細項目が用いられる。例、統計値または地理情報
詳細項目：
SpatialTemporal

郵便番号
ユニーク属性参照番号
座標空間

座標空間システム
長方形領域の範囲
座標の西境界
座標の東境界
座標の北境界
座標の南境界

空間単位
開始日
終了日
データ取り込み期間
データ取り込み日の状態
データ取り込み開始日
7データ取り込み終了日
例：
二都物語の場合、COVERAGE.SPATIAL: Brussels, Belgium
COVERAGE.SPATIAL: Stockholm, Sweden
上記における順番の場合
COVERAGE.SPATIAL: Brussels, Belgium; Stockholm, Sweden
COVERAGE. SPATIAL. SPATIAL REFERENCING BY COODINATES.SYSTEM OFSPATIAL REFERENCING BY COORDINATES: British national Grid WEST
BOUNDING CO-ORDINATE: 100 EAST BOUNDING CO-ORDINATE: 700 NORTH
BOUNDING CO-ORDINATE: 1300 SOUTH BOUNDING CO-ORDINATE: 100
郡単位で全アイルランドを対象にした統計集合の場合
COVERAGE.SPATIAL: Ireland SPATIAL UNIT: Country
2000 年 3 月 13 日から 2001 年 3 月 13 日の間に発生した事件の資料の場合
COVERAGE.TEPORAL: 2000-03-13/2001-03-13
1950 年代にパリで起きた事件の資料検索の場合
COVERAGE.TEPORAL: 1950/1960
COVERAGE.SPATIAL: Paris, France
2003 年及び 2004 年にポルトガル、テキサスの General Directorate が徴収する、2002 年
及び 2003 年の納税［所得］申告の場合。
COVERAGE.TEPORAL.BEGINNING DATE: 2002-04-01 END DATE: 2003-03-31
START DATE OF CAPTURE: 2003-08-01 END DATE OF CAPTURE: 2004-04-01
符号化スキーム: include
空間の場合
DCMI Point: 地理座標を用いて空間中の点を示す。
http://dublincore.org/documents/dcmi-point/
DCMI box: 地理上の制限により、空間における範囲を示す。
http://dublincore.org/documents/dcmi-box/
国名を表すため ISO 3166 コードを用いる。
http://www.din.de/gremien/nas/nabd/iso3166ma/codlstpl/index.html
TGN The Getty Thesaurus of Geographic Names
http://shiva.pub.getty.edu/tgn_browser/
ISO19115
http://www.anzlic.org.au/sadi/metaiso.htm#iso
時間の場合
W3C DTF
http://www.w3.org/TR/NOTE-datetime
DCMI Period: 時間間隔の制限仕様
http://dublincore.org/documents/dcmi-period/8

対応
Dublin CoreAGLS

Coverage 詳細項目：Spatial, Temporal
Coverage 詳細項目：Spatial, Temporal；
管轄区域；郵便番号
地理的な拡張；詳細項目 座標空間：座標空間システム；西側座標；
東側座標；北側座標；南側座標；郵便番号の地区番号；国番号；管理
領域番号；取り込み期間；取り込み開始日の状態；取り込み開始日；
取り込み終了日の状態；取り込み終了日；更新頻度
空間ドメイン；場所；場所キーワードのシソーラス；場所キーワード；
座標との連動；西側座標；東側座標；北側座標；南側座標；期間；開始日；終了日；期間のテキスト表示、期間の区分け

NGDF

GILS

５.CREATOR
当該資源の内容を作るに当たって、最も責任を有する実体。
必要性：必須
反復性：有りCreator の例としては、人あるいは組織がある。一般的に、Creator の名前は、実体を示すのに用いられるべきである。その代表者はしばしば法律上の責任や義務を負い、また、監査を行う場合、人名が必要となる。
作成した組織が解散したり、作成者が異動しても、当該資源を追跡できるようにする為、完全な組織の階層構造を含んでいても良い、例えば、本部、部、課、チームなど。
場合によっては、Creator は人を表すのではなく、職名を表す方が良い。
可能ならば、連絡方法を記述した方が良い、特に、Creator が出版社や配布者と異なる場合、記述する事が望ましい。もし、可能ならば、個人的に用いている電子メールアドレスより、部門代表的に用いている電子メールアドレスを記述するのが望ましい。何故なら、その方が変更の可能性が少ない。
例、info@sip.etat.lu や registrator@primeminister.ministry.se
頭字語は利用者に分からないかも知れないので、組織の正式名称を用いるべきである。または、用語集にリンクするとか説明文を付ける必要がある。
詳細項目
Owner

Contact

本質的に必要か、もしくは、当該資源の内容に責任を有している人または、組織を記録しておくのに助けになる場合、使う。
本項目は、監査する時、もしくは、法律的、または、公式目的のために必要である。
当該資源の内容について、更に詳細な情報を必要とする場合、連絡を取るべき個人または組織。この項目はここにあるべきか、それとも当該資源自身の一部であるべきか？ メタデータが別々のメタデータに置かれようとする場
合、検索可能な情報のためには、この項目は必要ではないが、重要ではある。
例、
内容に関する一義的責任は副本部長にあり、ポリシーに関する責任は組織全体にあり、問い合わせ先として、エキスパートの人がいる場合、
9

CREATOR: Assistant Director; Technology Strategy Team, Office of the e-Envoy,
Cabinet Office ukgovtalk@e-envoy.gov.uk OWNER: Office of the e-Envoy, Cabinet Office,130 Wilton Road, London SW1V 1LQ, info@e-envoy.gov.uk CONTACT: Interoperability
Strategist, Technology Strategy Team, Office of the e-Envoy, Cabinet Office london, UK
ukgovtalk@e-envoy.gov.uk
書記局により作成された議事録案の為、また、議長にとどまる内容に関し責任を負う場合,(書記局が誰かは、Creator フィールドで示される。)
CREATOR: David Aurvig, Chair Association of County Councils, Denmark dba@arf.dk
外部の顧問によって準備された資源の場合,
CREATOR: Palle Greve, Greve consultancy, pgconsultancy@goto.dk OWNER: Ministryof Information Technology and Research, Denmark fsk@fsk.dk
対応
Dublin Core
AGLS
NGDF
GILS

CreatorCreatorOriginator
Originator

６.DATE
当該資源に関し、ある出来事を表す日付
必要性：必須
反復性：有りデータは世界中の人々が認識することのできる形式で表示される必要がある。そして、コンピュータのソフトウェアで解釈できるのものである必要がある。W3C 形式を使用すれば、正確な検索ができ、年や月、日付がはっきりする。形式が yyy-mm-dd 場合、yyy が年で、
mm が月で、dd が日である。
時間も必要である場合、Thh:mm を付加する。hh 時間を示す（24 時間を使用して）mm は分を示す。国際時間帯を使用してのこの表記法についての詳細は
http://www.w3.org/TR/NOTE-datetime.
に掲載している。
Date フィールドは、当該資源にある情報ではなく、情報資源自身に相当する日付のことを示す。例えば、18 世紀の行政事務についての文書には、Coverage に 18 世紀 を、Ｄａｔｅに公表されている日付を入力する。
詳細項目
Acquired

定義：当該資源が組織に受信された日
コメント：ある局から別の局へ提出されると、当該資源の性質はその内容を変更せずに、変更を行うことができる。（例、立法手続きなど）
例：法律文書が審議のために提出された日（議会で当該資源が取得された日）と（許可の提出または、受け取りによって）当該資源が採用された日は同じではない。
10

Available

CreatedCut-off date
Declared
ClosedIssuedModified
Updating
frequency

Valid

これには e-mail を受信した日時が含まれる。
定義：当該資源が利用可能になる予定、または利用可能になった日（しばしば範囲の場合もある。）
コメント：完成した資源が内部的に使用可能になるとこ の詳細項目 は使用され るべきか？そして、資源が公に利用可能になるとIssued が使用されるべきか？この区別は重要か？混乱を招くのか？
定義：当該資源作成日
コメント：リソースの本版が作成・完成した日、または当該資源を集合の一部として格納する機能が確立された日。例えば、フォルダ
作成日、追加される文書用に利用可能になった日時から、Web サイトや Web サイトの一部の作成日。
これには e-mail を送信した日時が含まれる。
定義：当該資源が新しく部分に分かれる普通の日。例、会計年度のはじまりなど、
定義：当該資源が宣言され、ファイルされ、公的な記録として登録された日。
定義：集合の一部としてリソースが格納される機能が無効になった日。例、フォルダを閉じた日。
定義：当該資源を正式に発行（例、公表など）をした日。
コメント：当該資源が公的に利用可能になった日または、利用可能になる予定の日。
これには、発行日やリリース日も含まれる。
Available 配下の質問を参照のこと。
定義：当該資源が変更された日。
定義：どのくらいの頻度で当該資源が更新されるか。特にデータベース関連。
コメント： 本詳細項目の値は幅のある要素と は 合 わ な い た め 、 こ れ は Dublin Core
‘dumb down’基本方針
http://dublincore.org/resources/faq/#dumd
ownと矛盾する。つまり’daily’は日ではない。
オプション：Description にこの情報が含まれる。
定義：資源の有効日（しばしば範囲の場合がある）
コメント：これには参考文献に関するコメン
トを受け取るのを終える日が含まれる例
承認され、2002 年 12 月 2 日に編集者に送られたが、翌日の朝 11 時まで公表できないプレ
スリリースの場合。
DATE.CREATED: 2002-1202 ISSUED: 2002-12-03 T11:00
111997 年 7 月 3 日に受信した e-mail の場合。
DATE.ACOUIRED: 1997-07-03
DATE.DECLARED: 1996-07-28 CLOSED: 1998-03-16
会計年度の最後に置き換えられるスプレッドシートの場合。
DATE.CUT-OFF DATE: 2004-03-30
地方のバスルートの夏季時刻表
DATE.VALID: 2003-05-01/2003-10-31
2000 年 1 月 6 日に立ち上げたホームページの場合。
DATE.ISSUED: 2000-01-06
同じホームページが編集され、5 月以降のものを示す場合。
DATE.MODIFIED: 2000-05-01
2002 年 2 月 2 日に作成され、チーム全員が読み、公的なプログラムが完成するまで保存されるリソースの場合。その後、2002 年 3 月 3 日に公表され、2002 年 6 月 3 日まで審議のために開放された。
DATE.CREATED: 2002-02-02
DATE.AVAILABLE: 2001-02-28
DATE.ISSUED: 2002-03-03
DATE.VALID: 2002-06-03
毎日更新されるデータベースの場合。これで、利用者は、データベース自身はもともと数年前に作成されているが、データベースに保存されている情報は現在のものであると知ることができる。
DATE.CREATED: 1996-03
DATE.UPDATING FREQUENCY: Daily
符号化スキーム
W3CDTF 詳細についてはhttp://www.w3.org/TR/NOTE-datetune
ISO8601
対応
Dublin Core
AGLS
MGDF
GILS

を参照のことDate 詳細項目;Created; Valid; Available;
Issued; Modified
Date 詳細項目; created; modified; valid;issued
発行日; 発行日
構造化された; 原文の発行日

７.DESCRIPTION
当該資源に含まれる情報の記述
12

必要性：オプショナル
反復性：有り
記述では以下のことをカバーする。
主題へのアプローチ（例、批判、説明、入門者用のガイド）
資源の作成理由（例、知らせたり、コメントを促したりするためのもの）
参照されるグループと組織カバーされるイベント
鍵となるフィールド（データベース）または章のリスト
その他有用な情報
ヒント・ 表題の下に各自が記述を持つヒットの長いリスト内の記述を書いてみる。
最初の行はすぐに目に入る可能性が高い。
・ 一番大事な部分を最初にして、完結性を維持する。
・ 他の場所にもある情報を複写しようとしない。
（例、Title 要素, Coverage 要素、Subject
要素の中で）
詳細項目
Table of contents
Abstract

当該資源の内容のサブユニットのリスト
当該資源の内容の概要

例
DESCRIPTION:

EU 委員会が個々の機関にソフトウェア購入の責任を譲渡する推奨。
これには費用便益分析や例が含まれる。
DESCRIPTION: ヨーロッパの地方議会の常務委員会のメンバーリスト。
これには連絡先の詳細や委員会での役割が含まれる。
DESCRIPTION: ホームスクールの導入目的を説明する、両親へのリーフレット。
これは 1999 年 9 月から公立の小学校で必須である。
DESCRIPTION: 君主からのスピーチは 23003 年の政府の計画となる。女王は毎年 9 月の第三火曜日に、政府を代表してスピーチを行う。政府の役員を含む上院、下院の議員はハーグの Binnenhof にある Riddeizaal に召集されそのスピーチを聞く。
DESCRIPTION.TABLEOFCONTENTS: 改版履歴/はじめに/必要性/ネーム空間/一般基本
方針/要素

対応
Dublin Core
AGLS
NGDF
GILS

Description
Description
Abstract
Abstract

８.DISPOSAL
当該要素の保持と処理
13必要性：オプショナル
反復性：有りこれは、必要とされた後には維持されないが、それ以前には処分されないということを保証し、資源をコントロールし続けるのに必要な要素である。
ウェブマスタが Web ページが時代遅れになる前に簡単に探し、組織の記録室に送ることができるように、すべての Web ページが Review 日を含むことを推奨する。
詳細項目、‘Conditions’と’Action’は長期間の記録管理を目的として使用される。
詳細項目
Review
Conditions
Action
Review details

当該資源を保存する必要性を決定するためにレビューを行う日
当該資源が商業目的で維持されるための期間を決める特定のイ
ベント後の特定の期間
Condition に達成したらとる行動。
レビューを行う人とレビューを決定の詳細。

例
DISPOSAL.CONDITIONS:

プログラムの完成の 5 年後ACTION：国の公記録に移行されるまで保存最終の報告は 2003 年 8 月に発行される と記述している Web ページの場合。
DISPOSAL.REVIEW: 2003-08-01
上記の情報は所有者に適時警告するため使用される。所有者はその文書を 最終報告は遅れている。2003 年の終わりに利用可能となる と更新し、読み込み用にメタデータを変更する。
DISPOSAL. REVIEW: 2003-10-20
符号化スキームは以下を含む
ActionUK Public Record Office リスト：
（レビューと更なる処分、破棄、Public Record
Office に移行されるまで保存される。）
対応
Dublin Core
AGLS
NGDF
GILS

９.FORMAT
資源の物理的な形式
必要性：推奨
反復性：有りRelation 要素を使用して当該資源が代替形式で利用可能であると述べる。
14

詳細項目
ExtentMedium

当該資源のサイズや保持期間
当該資源の物質的、または、物理的媒体

例
その他の追加資料がある旅行ガイドの場合。
FORMAT: 地図が挿入してある本
データベースの場合。
FORMAT: Database EXETENT: 345+kb MEDIUM: Access 97
HTML の Web ページの場合。
FORMAT: Text MEDIUM: html
符号化スキーム
媒体
IMT: 当該資源のインターネット媒体のタイプ
http://www.isi.edu/in-notes/iana/assignments/media-types /media-types
対応
Dublin Core
AGLS
NGDF
GILS

Format 詳細項目 Extent; Medium
FormatPresentation Type; Supply Media; Data format
Medium (Availability の詳細項目)

１０.INDENTIFIER
与えられた文脈内の当該資源への明確な参照。
必要性：もし、適用可能なら
反復性：有り識別子は特定の資源を検索するのに非常に有用である。また、正しい版を持っていることを確認したり、他の場所にある当該資源を参照するための速記としても有用である。（例えば’Relation’を参照のこと）
推奨されている一番よいプラクティスは正式な識別システムに従った文字列や番号を使用して当該資源を特定することである。変更が伴うので URL を使用するには注意が必要である。
特に URL を使用することが実践的でない場合は、資源のための一意の識別子を検索することはいつも可能ではない。例には簡単に識別できる必要のあるフォームやリーフレットがある。これらには割り当てられたコード（例、英国の所得申告のフォーム用の SA100）があるが、このコードは全体的にはめったに一意であることはない。（SA100 は複葉機であり、増幅器であり、キッチンのスケールであり、船舶のアンテナであり、ブロードバンドのサービスユニットであり、電話の呼び出し ID ユニットであり、Simon Hraser 大学のカナダ
15社会学のコースであり、オタワのバス停であり、MP3 プレーヤーであり、、）
例
組織内で使用されるフォルダの場合。
IDENTIFIER: DTR/CA/NATS/2000-8769B
IDENTIFIER: [ISBN] 87-89245-94-4
IDENTIFIER: [URI] http://europa.eu.int/ISPO/ida/
IDENTIFIER: [URN]DK-67-12345
符号化スキームは以下を含む
ISBN, ISSN, URI http://www.ietf.org/rfc/rfc2396.txt, URN
対応
Dublin Core
AGLS
NGDF
GILS

Identifier
Identifier
Identifier
スケジュール番号（Schedule number）

１１.LANGUAGE
当該資源のデータの言語。
必要性：必須
反復性：有り言語コードを使用すると、言語要素の入力が簡素化する。ほとんどの利用者は関連するコドをすぐ覚えるだろう。システムのほとんどは設定可能なので、言語の名前が完全に表示され、より使いやすい。
例
ドイツ語で書かれた資源の場合。
LANGUAGE: Deu
ウェールズ語とスペイン語で書かれた資源の場合。
LANGUAGE: Cym
LANGUAGE: Spa
ポルトガル語で書かれた資源のポーランド語訳の場合（現本であるポルトガル版にリンクするため、’Relation’を使用する。）
LANGUAGE: Pol
符号化スキームISO 639-2/B http://www.loc.gov/standards/iso639-21/
対応
Dublin Core
AGLS

Language
Language
16

NGDF
GILS

Language
資源の Language （Language of resource）

１２.LOCATION
当該資源の物理的な場所
必要性：オプショナル
反復性：有りこれは主に、物理的な形式に保存されている項目のために使用される。
また、物理媒体、例えば磁器テープや CD―ROM などに保存された電子資源にも役に立つ。
例
LOCATION:LOCATION:LOCATION:Storeroom 16, box 38
Library, Hansard Room, disc 1874B
Acme Storage facilities, Berlin

対応
Dublin Core
AGLS
NGDF
GILS

１３.RESERVATION
記録の永久保存を補助するのに必要なデータ
必要性：オプショナル
反復性：有り本要素は、MosReq 仕様、または、作成中の UK Public Records Office の Preservation(保存) メタデータ標準などのローカルのイニシアチブに非常に依存している。特に、公的な記録の長期的な保存を管理する際に使用され、これから 10 年間または 100 年間電子ファイ
ルを読み込んだり、解釈したりするのに必要な情報をすべて含んでいる。
例
Dublin Core
AGLS
NGDF
GILS

Preservation 履歴（Preservation history）

１４.PUBLISHER

17

当該資源を利用可能にする責任実体。
必要性：もし、適用可能なら
反復性：有りPublisher はここでは最も柔軟な感覚で使用されているので、ハードコピー版は利用できな
いが、Web サイトに情報資源を置く組織は Publisher であるということができる。
Publisher は普通、当該資源に含まれている情報を再発行するための許可を得たり、異なる形式のコピーを得る利用者が連絡をとる必要のある個人や組織である。
Publisher には情報に関する法的な責任があるので、名前づけられているべきである。
例
PUBLISHER:
si@si.sk

Danish State Information Service, Kingkurren 10, 2300 KØbenhavn S.,

PUBLISHER: The Stationery Office, St Crispins, Duke Street, Norwich, NR3 IPD.
Telephone 0870 600 5522. Facsimile 0870 600 5533. E-mail esupport@theso.co.uk
PUBLISHER:EUR-OP, Luxembourg. info-info-opoce@cec.eu.int

符号化スキーム
対応
Dublin Core
AGLS
NGDF
GILS

Publisher
Publisher
Supplier
Distributor

１５.RELATION
関連する資源への参照
必要性：オプショナル
反復性：有り推奨されている一番よいプラクティスは正式な識別システムに従った文字列や番号を使用して当該資源を参照することである。つまり、参照された資源の Identifier など。
クオリファイヤを使用している場合、最も適用可能であるものを使用すること。特に Type
要素と連携して使用される場合は Relation を使用して相互に関係するオブジェクトの検索をカスケート表示にできる。複数の部分や、同じ資源の異なる版や複数の形式で利用可能な項目をリンクするのにも非常に重要である。
詳細項目
IsPartOf

記述されている資源は参照されている資源の物理的または論理的部分である。
18

HasPart
IsVersionOf

HasVersion
IsFormatOf

HasFormat

References

IsReferencedBy

IsRequiredBy

Requires

IsReplacedBy
Replaces
SequenceNo

記述されている資源には物理的に、または論理的に参照されている資源が含まれている。
記述されている資源は参照されている資源のバージョンや版または翻案物である。
バージョンの変更は形式の相違ではなく、内容の名詞的変更を示す。
記述されている資源にはバージョンや版、翻案、すなわち参照されている資源がある。
記述されている資源は参照されている資源と同じ知的内容であるが、異なる形式で表示されている。
記述されている資源は、異なる形式で表示されている同じ知的内容である参照されている資源より先に存在する。
記述されている資源は、参照されている資源を引用、またはそうでない場合は参照されている資源を指し示す。
記述されている資源は、参照されている資源によって参照されているか、そうでない場合は指し示されている。
記述されている資源は、その機能やデリバ
リ、または内容の一貫性を支援するために参照されている資源が必要である。
記述されている資源は、その機能やデリバ
リ、または内容の一貫性を支援するために参照されている資源が必要である。
記述されている資源は、参照されている資源にとってかわられる。
記述されている資源は、参照されている資源と入れ替わっている
所属する順序での当該資源の割り当て番号
コメント：本詳細項目の値は幅のある要素とは合わないため、これは Dublin Core ‘dumb
down’基本方針
http://dublincore.org/resources/faq/#dumd
ownと矛盾する。つまり、 7 は資源ではない。
オプション：他の場所にこの情報はあるのか？
もしあるなら、どこに？

例
関連するプレスリリースの発行場合。
RELATION: Press release No.13/2001-20 November 2001
http://annualreport.emcdda.org/en/press/index.html#main
RELATION.REPLACES
更新されたポリシー文書の場合。
19

RELATION.ISVERSIONOF:
特定の号のファイルと一緒に分類されたフォルダの場合。
RELATION.HASPART: DAA/FIN37/22/2002/LBR2001-08-13
RELATION.HASPART: DAA/FIN37/22/2002/LBR2001-08-14
RELATION.HASPART: DAA/FIN37/22/2002/LBR2001-08-17
RELATION.HASPART: DAA/FIN37/22/2002/LBR2002-01-12
上記フォルダの一部を構成する文書の場合。
RELATION.ISPARTOF: DAA/FIN37/22/2002
Information Management’シリーズの 7 番目の文書の場合。
RELATION.ISPARTOF: Information management series SEQUENCENO:7
統計値の集合を解釈するがその値をリストしない資源の場合。
RELATION.REQUIERES: [ISBN]398762342X
ハードコピー可能な HTML 文書の場合。
RELATION.ISFORMOF: [ISMN]0711504083
符号化スキームには以下が含まれる。
URI
ISSN
ISBN
対応
Dublin Core

AGLS

NGDF
GILS

Relation詳
細項
目IsPartOf/HasPart;
IsVersionOf/HasVersion;
IsFormatOf/HasFormat;
References/IsReferencedBy;
IsRequiredBy/Requires;
IsReplacedBy/Replaces
Relation詳
細項
目:IsPartOf/HasPart;
IsVersionOf/HasVersion;
IsFormatOf/HasFormat;
References/IsReferencedBy;
IsBasedOn/IsBasisFor;
IsRequiredBy/Requires; IsReplacedBy/Replaces
Dataset 関連; 追加情報源
クロスリファレンス 詳細項目: クロスリファレンスタイトル;
クロスリファレンスの関係;
クロスリファレンス繋がり; 繋がり; 繋がりのタイプ

１６.RIGHTS
当該資源にある権利についての情報。
必要性：オプショナル
反復性：有り
当該資源を表示、コピー、再頒布、再発行する権利、または、当該資源のすべて、または20

一部を使用する利用者の権利を示す。
一般的に、Rights 要素は当該資源の権利管理ステートメントを含むか、そういった情報を提供するサービスを参照する。Rights 情報は当該資源へのアクセスに関しての知的所有権
や、関連する権利、保護手段の作成、その他の法で決められた義務や制約を網羅している。
Access Rights は European Parliament , Council and Commission の 文 書（
http://europa.eu.int/eur-lex/en/lif/dat/2001/en301R1049.html）のRegulation(EC)NO1049/2001 などのような当該資源への公的アクセスを制御する法律やその他の原則を示している。Access Rights は当該資源への公的、または、その他のアクセスを提供する組織をもつ権利を制限したり（例、プライバシーに関する法律など）、当該資源を利用可能にするため組織をもつことを強制することがある（例、情報の自由に関する法律など）。
可能であれば、権利作成についての詳細を提供する資源リンクを提供する。
例、ステートメント Crown copyright’はそれが何を意味しているのかを説明しているサイ
トwww.hmso.gov.uk/copyhome.htm にリンクすべきである。
Security Classification があたえられていない場合、部門ごとの記録に関しては当該資源が分類されていないと仮定される。
詳細項目
Securityclassification
Previous security
classification
Security
Classification date

Descriptor
Folder/record caveat
Codeword
Electronic signatureauthentication

正式なセキュリティ状況を示している当該資源に割り当てられた分類
現在の状況より前の正式なセキュリティ状況を示している当該資源に割り当てられた分類
前回の分類が変更された日。

変更日も有効である。
オプション（以下の例を参照のこと）
1. 付 加 的 な 詳 細 項 目 と し て のSecurityClassificationChangeDate これは DC’dumb down’基
本方針 http://dublincore.org/resources/faq/#dumbdownに違反する。
2. セキュリティ値に日付情報を追加する。例、’Secret, changed
2001-12-28’または、’Top secret, review on 2003-07-09’など。これは日付で検索可能だが、分類から日付を離すのは難しい。−公やその他のグループにその一つを見て欲しいと思うかもしれない。
3. Date 要素の詳細項目の一部として Security Classification
Change を追加する。当該資源の分類に変更が複数あり、関連するデータを分割する場合は、このことによって、混乱を招くことがある。
4. メタデータに変更日を含めてはいけない。
資産の感度の性質とそれに従ったアクセス制限の必要性を示す。
保護された特定の資源への参照のためのセキュリティ保護を提供するために使用される用語。
記録や電子証明に添付される電子署名の有効性に関するデータ

21

OwnerBusiness groupaccess permission
Username access lists
Circulation list
Time validity

Access rights

Copyright

当該資源へのアクセス権利を与える責任を持つ名前のついた個
人や組織
当該資源へのアクセスが制限された定義済みのチームやグルー
プ
当該資源へのアクセスを許可された人のリスト
e-mail の’to’フィールドや’copy’フィールドに名前があり、文書が配布されるあて先となる個人や組織の名前。
現在のアクセス制御が無効となる日。
Security calcification change date と同じ問題。同じ解決策が適用。例、セキュリティ値に有効なデータを追加する。例えば、’classied, valid until 2003-07-09’
個人がアクセスしなければならない法律やその他の権利、または、当該資源へのアクセスを開放したり、提供するために、管理者の権利を制限する法律やその他の権利
当該資源のすべて、またはいずれかの使用や再利用に関する法的な所有権や権利を示すステートメントと識別子

例
最初に Top Secret であると分類された項目で、4 月 17 日に分類が Secret に変更し、レビ
ュー期間の為、その６ヶ月後の場合。
オプション 1
RIGHTS.SECURITY
CLASSFICATION:
SecretPREVIOUSSECURITY
CLASSIFICATION:
Top
secret
SECURITY
CLASSIFICATIONCHANGEDATE :2002-04-17
オプション 2
RIGHTS.SECURITY CLASSFICATION:
2002-10-17
PREVIOUS SECURITY CLASSIFICATION:

Secretchanged

2002-04-17

Review

Top secret reviewed 2002-04-17

オプション 3
RIGHTS.SECURITY CLASSFICATION:
Secret PREVIOUS SECURITY
CLASSIFICATION: Top secret
DATE SECURITY CLASSIFICATIONCHANGE: 2002-04-17
RIGHT.COPYRIGHT: European Communities, 1995-2001
http://europa.eu.int/geninfo/copyright en.htm
符号化スキーム
スキームの符号化は所有する組織のニーズや手続きに従って使用されるべきである。
対応
Dublin Core
AGLS
NGDF
GILS

RightsAvailability: Rights
アクセス制御;アクセス制御; 詳細項目: 一般のアクセス制御; security 分類
管理22

１７.SOURCE
現行の資源が取り出された資源への参照。
必要性：オプショナル
反復性：有り現行のリソースは、全体、または、一部の Source 資源から取り出されるかもしれない。推奨されている一番よいプラクティスは正式な識別システムに従った文字列や番号を使用して Source 資源を参照することである。つまりそれは Identifier である。
Relation 要素にこのデータを入れる方が適切な場合は、Source を使用してはいけない。つまり、Relation の’ISVersionOf ’詳細項目を使用する方がより正確である場合がある。
例
SOURCE: Figures derived from Ｗired in Whitehall survey by the Committee ofDepartmental Librarians 1998 http://www.aslib.co.uk/proceedings/2001/jan/03.html
SOURCE:

photographs from La Biblioteca Nacional http://www/bne.es/esp/

符号化スキームには以下が含まれている。
URI
対応
Dublin Core
AGLS
NGDF
GILS

SourceSourceデータの Source （Source of data）

１８.SUBJECT
当該資源の主題の問題を示すキーワードやフレーズ
必要性：必須
反復性：有りSubject は重要な検索ツールである。本要素の内容に考えが多く入るほど、利用者が自分に必要なものを正確に検索する可能性が増える。
本要素は、Type などではなく、資源の主題を記述する。例、当該資源が map の場合、’Maps’
を主題と考えてはいけない。その代わり、当該資源が mapmaking (地図作成)や cartography（地図製作法） など、map について、であれば、’Maps’を使用する。
コントロールされていない語彙が利用可能な場合は、資格のない要素を使用するのみである。また、利用者が当該資源を検索するのに役立つ短縮形や、複数形、スペルの変形など
23

には本要素が使用されることがある。
一般的な用語を含まず、最も特定した用語を使用することで、情報過多になるのを防ぐことができる。例えば、ある人が、健康に関する政府の総体的な政策をカバーしている Web
サイトを探している場合、その人は主題の用語として’健康（health）’を使用して検索しなければならない。利用者が出くわしたリストがビタミン過剰摂取による長期的な影響や、バルセロナの医者不足などといった特別な健康の問題に関する項目であった場合、どうしようもない。
Web サイトのキーワードを設定する場合、全サイトではなく、問題となるページを記述している用語を選択する。このことによって、利用者は探している情報に直接行くことができるし、ローカルな検索エンジンを使用してサイトナビゲーションもできる。
詳細項目
Category

KeywordProcess
Identifier
Programme

Project規定されたリストからの幅広い主題カテゴリ。
コメント：これは、利用者が非常に幅広い用語（例えば、健康や環境など）用語のリストからより意味を狭くしたカテゴリ（例えば、個人の健康管理、水資源など）を使用してブラウズできるようにするためのものである。また、
電子メタデータベースや印刷されたカタログに使用して、主題項目の下に項目を表示するのに役立つ。コントロールされたリストから用語を選択することが大切である。
当該資源の主題問題をできる限り特定して、記述するために使用される言葉や用語。コントロールされた語彙やリストから選択することが望ましい。
認識されたリストからの識別子を使用して、特定のサービスや処理を示す。
付録 B の例を参照のこと。
当該資源が直接的に関係しているより幅広いポリシープログラム。
コメント：’programme’の正式な定義や、’project’との相違は何かと言うことを正式に定義したものではない。一般的な規則では、programme は完成す
るのに何年もかかる政府の幅広いポリシープログラムのことである。例,
電子政府など。Project とはより大きな Programme を作る、より特定された管理可能な部分のことである。何が Programme で、何が Project であるかと言うことについて、チームの人や全組織の人と意見を一致させるのに有用である。主に、特定の Project や Programme に所属するすべての項目を検索するのに使用されることに注意。Objective を考える。 あなたや利用者に特別重要では場合、この二つを使用してはならない。
本外資源が直接関連している特定の project.
‘Programme’の下のコメントを参照のこと。

例
改革の大きなプログラムの概略を記しているオーストリアの政策文書の場合。
SUBJECT.CATEGORY: Government
SUBJECT.KEYWORD: European Union enlargement; Policy;E equality
SUBJECT.PROGRAMME: Coalition Programme
SUBJECT.CATEGORY: Crime/crime reduction; Young people
SUBJECT.KEYWORD:
Young offenders; Criminals; repeat
reduction; Zero tolerance; electronic tagging

24

offenders;Crime

SUBJECT. PROGRAMME: Intensive Supervision and Surveillance Programme
SUBJECT.PROJECT: Electronic tagging
さまざまな社会活動のグループが取り扱っている個人の健康管理を探す文書シリーズの一つの場合。
SUBJECT.CATEGORY: Private health care; Ethnic Minorities
SUBJECT. KEYWORD: Private health care; Vietnamese; Somali
海外旅行をする国民へのアドバイスを掲載している Web サイトの場合。
SUBJECT.CATEGORY: Tourism
SUBJECT. KEYWORD: Foreign travel; Safety; British embassies; consulates; Traveladvice
建築許可の申請用紙を案内している Web ページの場合。
SUBJECT.CATEGORY: Town&Country Planning
SUBJECT.PROCESS IDENTIFIER: PL030A
符号化スキームは以下を含んでいる。
Categories UK government Category List. これは、www.govtalk.gov.ukで参照できる。
Process Identifier
CUPID www.leap.gov.uk
対応
Dublin Core
AGLS
NGDF
GILS

Subject
Subject
Keywords
コントロールされていない主題用語: 詳細項目 コントロール
されていない用語
コントロールされている主題索引; 詳細項目 主題シソーラ
ス; コントロールされている主題用語; コントロールされている用語

１９.TITLE
当該資源に与えられた名前。
必要性：必須
反復性：有りTitle は当該資源が一般的に知られている名前であるべきである。Title が存在しない場合は作成する必要がある。独創的で人の気を引くようなものである、というよりは、簡潔で意
味あるものにすること。
Alternative title は当該資源の正式な title の替わりとして使用される title のフォームを追加する。それには省略や翻訳も含まれる。一般の人が理解できないと思う名前で資源が正式に、又は内部的に知られている場合、その名前に追加したり、意味ある名前を付けることをお勧めする。

25

リストについて考える。項目が同じ title を持つものの中の一つである場合、言語やバージ
ョン番号、状態（例、’draft’ 審議のための草案）や日付などの値を追加する。そうすれば、リストに表示される場合、必要なものを簡単に探すことができる。（例を参照）。この要素
が文書の正式な title の一環ではない場合、Title 要素に本情報を含めるのは問題なのか？
Title は文章の状態で書くべきである。そうしたほうが見た目にも分かりやすい。
当該資源が電子文書を含む電子 フォルダ(folder)’である場合、普通のフォルダ名をつけること。
詳細項目
Alternative title
例
TITLE:

当該資源の正式な title の替わりとして使用される title のフォーム

New health Strategy

非公式の表題で一般的に知られている報告の場合。
TITLE:The Stephen Lawrence inquiry: report of an inquiry by Sir William
Macpherson of Cluny ALTERNATIVE TITLE: the Macpherson report
非公式で報知的ではない主題をもつ e-mail の場合。
TITLE: Software demo thursday ALTERNATIVE TITLE: Zitwik application data
Q. 非公式な e-mail 主題をまったく使用せず、いつも意味ある表題を作るほうがいいのか？
多くの人にとっては明らかに意味のない表題であっても、利用者は風変わりな表題の
e-mail を思い出し、探すことがある。
部門の Web サイトのホームページの場合。
TITLE:
Official website of the belgian federal services for the Environment
ALTERNATIVE
Site officiel des services fédérauz belges pour l’environnement
TITLE:ALTERNATIVETITLE: Officiele website voor de federale diensten voor het Leefmilieu
同じ表題の項目のシリーズだが、異なる言語で、毎年版が変わる場合。’Tax return guidance’という項目の長いリストより、これのほうがより有用である。
TITLE: Tax Return guidance 2002/03 German
TITLE: Tax Return guidance 2002/03 Vietnamese
TITLE: Tax Return guidance 2002/03 Croatian
TITLE: Tax Return guidance 2002/03 French
TITLE: Tax Return guidance 2003/04 German
TITLE: Tax Return guidance 2003/04 Vietnamese
TITLE: Tax Return guidance 2003/04 Croatian
TITLE: Tax Return guidance 2003/04 French
符号化スキーム
対応
Dublin Core

Title
26

AGLS
NGDF
GILS

Title
Title, Alternative title
フォルダ title; 文書 title

２０.TYPE
当該資源の内容の性質と様式
必要性：オプショナル
反復性：有り本要素は Format 要素と混同すべきではない。Format は、作成したり、読み込んだり、編集したりするソフトウェアアプリケーションなどを含む資源の物理的な形式を指す。Type
は資源の内容を指す。
公式の記録や文書はより大きな集合の一部として存在することがある。Type はそういった場合に、どのレベルの資源かを示したり、表したりするために使用されるべきである。ス
キームの符号化を使用すべきである。MoReq 仕様 http://europa.eu.int/ISPO/ida)に含まれる階層の情報が、いつ符号化スキームを設定するのかということについて参照することをお勧めする。MoReq の集合レベルの例には記録やフォルダ、ファイル、ボリュームがある。
シリーズの資源の位置を述べたり、どの集合の一部であるのかを指定するためには、
Relation 要素に識別子を追加する。
推奨されている一番よいプラクティスは、より特定の用語と同じように、DCMI タイプからの関係する用語を含めることである。
詳細項目
Aggregation level

当該資源の階層内でのレベルや位置。当該資源がより大きな資源や集合の部分である範囲を示す。

例
TYPE: [DCMI-TYPE] Text
TYPE: Annual report(DCMI タイプの符号化スキームから’text’を、ドラフト MIReG 文書タイプのリストから’annual report’を取り出す。)
TYPE: [DCMI-TYPE] Collection AGGREGATION LEVEL: Folder（DCMI タイプの符号化スキームから’collection’を、MoReq 仕様に記述されている階層レベルから’folder’を取り出す。）
符号化スキームは以下を含んでいる。
DCMI タ イ プ ： http://dublincore.org/documents/dcmi-type-vocabulary/ (Collection,
Dataset, Event, Image, Interactive resource, Physical object, Service, Softwre, Sound,
Text)

27

対応
Dublin Core
AGLS
NGDF
GILS

Type
Type
Type
Type

参考１
タイプ
Act of Parliament（国会制定法）
Advertisement（広告）Agenda（議事録）
Article（記事）Annual report（年次報告書）
Atlas（地図帳）
Briefing note（要約）Budget（予算）Call for expressions of interest（関心度の要請）
Call for tenders（世話をする人の要請）
Call for papers（書類の要請）

Job advertisement（求人広告）を参照

その他のイベントの会議用、または、印刷
発行物

Case notes（ドル）Conference proceedings（会議の手続き）
Conference programme（会議計画）
Consultation paper（審議書）
Expression of interest（関心度）
FAQ
よくある質問Form（フォーム）
General note（一般注意事項）
Green paper（緑書）
特別なタイプの審議書
Guidelines（ガイドライン）
Home page（ホームページ）
Job advertisement（求人広告）
Job description（職務記述書）
Instructions（説明書）
Index（索引）
例えば、Web サイト A−Z のリスト
Letter（手紙）Manual（マニュアル）
Instructions（説明書）の方がよい
Map（地図）Ministerial correspondence（政府内の通信）News & events（ニュース＆イベント）
Newsletter（ニュースレター）
Policy framework（政策枠組み）
PQ
質問とその答えが含まれている
Presentation（プレゼンテーション）
Press release（プレスリリース）
Procedure note（手続きの覚書）
または、作業説明
Project evaluation（プロジェクト評価）
Project exception report28

（プロジェクト例外レポート）
Project initiation document（プロジェクト開始レポート）
Project plan（プロジェクト計画）
Project risk register（プロジェクトの危険登録）
Project terms of reference（プロジェクトの委託条件）
Report（レポート）
Specification（仕様書）
Speech（スピーチ）
Statistics（統計）Statutory Instrument（規則）Strategy document（戦略文書）
Submission（提出）
Terms of reference（委託条件）
Web page（Web ページ）

Home page（ホームページ）、Site map（サイトマップ）、List/index（リスト・索引）も参照のことWeb サイトやイントラネットのWeb サイトやイントラネットのための

Search page（検索ページ）
Site map（サイトマップ）
White paper（白書）

29

参考２

プロセス識別子リストの例（断片）

LEAP CUPID LIST(顧客の一意のプロセス識別子)
社会事業
65 歳以上の人への援助やサービス
65 歳以上の人へ社会事業からの援助を用意する。
65 歳以上の人への社会事業からの援助の追加や変更を申請する。3
65 歳以上の人への社会事業からの援助を申請する。1
65 歳以上の人へ、社会事業からの援助を照会する。2
65 歳以上の人への介護のために、社会事業からの援助を用意する。
65 歳以上の人への介護のために、社会事業からの援助の追加や変更を申請する。6
65 歳以上の人への介護のために、社会事業からの援助を申請する。4
65 歳以上の人への介護のために、社会事業からの援助を照会する。565 歳以上の人から受けた、援助に関する不満や問題報告。
65 歳以上の依頼者に社会事業が連絡を取れない場合、呼び出し人に取るべき行動について知らせる。865 歳以上の人から受けた、社会事業へからのサービスについての不満。765 歳以上の人に対して、社会事業からの援助への支払い選択についてたずねる。
65 歳以上の人への社会事業からの直接支払いを申請する。1065 歳以上の人に対して、社会事業からの援助への直接支払いについてたずねる。965 歳以上の人のホームヘルパーに息抜きケアを要請する。
65 歳以上の人ための息抜きケアを申請する。1165 歳以上の人の分担介護を申請する。1265 歳以上の人の息抜きケアの変更についてたずねる。1465 歳以上の人への社会保護を受け、支援されている住宅について理解する。1365 歳以上の人のために、居住看護を探す。
65 歳以上の人のために、ホスピスケアを探す。1865 歳以上の人のために、長期の居住看護を探す。1765 歳以上の人のために、社会保護を受けた住宅を探す。1565 歳以上の人のために、短期の居住看護を探す。1665 歳以上の人のために、デイクラブや、デイセンターへ行く。
65 歳以上の人のために、デイセンターの部屋を申請する。1965 歳以上の人のために、デイクラブの部屋を申請する。20
目の不自由な大人への援助を用意する。
目の不自由な大人のために、社会事業からの直接支払いを申請する。343
障害のある人のために家を改造する。
在宅できるように自宅を改造する。
セラピストからの協力の追加や変更を申請する。26
セラピストの協力を申請する。25
家を少し改造する。21体の状態に合わせて家を改造する。22
自宅を改造するためにアドバイスを受ける。23
このリストについての詳細はhttp://www.;eap.gov.uk を参照のこと。

30