RFC1614 日本語訳
1614 Network Access to Multimedia Information. C. Adie. May 1994. (Format: TXT=187253 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Adie Request for Comments: 1614 Edinburgh University Computing Service RARE Technical Report: 8 May 1994 Category: Informational
コメントを求めるワーキンググループC.エーディの要求をネットワークでつないでください: 1614年のエディンバラ大学のコンピューターサービスのまれな技術報告書: 1994年5月8日のカテゴリ: 情報
Network Access to Multimedia Information
マルチメディア情報へのネットワークアクセス
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This report summarises the requirements of research and academic network users for network access to multimedia information. It does this by investigating some of the projects planned or currently underway in the community. Existing information systems such as Gopher, WAIS and World-Wide Web are examined from the point of view of multimedia support, and some interesting hypermedia systems emerging from the research community are also studied. Relevant existing and developing standards in this area are discussed. The report identifies the gaps between the capabilities of currentlydeployed systems and the user requirements, and proposes further work centred on the World-Wide Web system to rectify this.
このレポートはマルチメディア情報へのネットワークアクセスのために研究とアカデミックなネットワーク利用者の要件について略言します。 それは、計画されたか現在共同体の進行中のプロジェクトのいくつかを調査することによって、これをします。 ゴーファーや、WAISやWorld Wide Webなどの既存情報システムはマルチメディアサポートの観点から調べられます、そして、また、研究団体から現れるいくつかのおもしろいハイパーメディアシステムが研究されます。 この領域の関連存在と展開している規格について議論します。 レポートは、currentlydeployedシステムの能力とユーザ要件のギャップを特定して、これを正すためにWWWシステムの上を集中させられたさらなる仕事を提案します。
The report is in some places very detailed, so it is preceded by an extended summary, which outlines the findings of the report.
レポートはしたがって、非常に詳細であることで、所々、拡張概要がそれに先行するということです。(概要はレポートの調査結果について概説します)。
Publication History
公表歴史
The first edition was released on 29 June 1993. This second edition contains minor changes, corrections and updates.
初版は1993年6月29日にリリースされました。 この第2版はマイナーチェンジ、修正、およびアップデートを含んでいます。
Table of Contents
目次
Acknowledgements 2
Disclaimer 2
Availability 3
0. Extended Summary 3
1. Introduction 10
1.1. Background 10
1.2. Terminology 11
2. User Requirements 13
2.1. Applications 13
2.2. Data Characteristics 18
承認2注意書き2の有用性3 0。 拡張概要3 1。 序論10 1.1。 バックグラウンド10 1.2。 用語11 2。 ユーザ要件13 2.1。 アプリケーション13 2.2。 データの特性18
Adie [Page 1] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[1ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
2.3. Requirements Definition 19
3. Existing Systems 24
3.1. Gopher 24
3.2. Wide Area Information Server 30
3.3. World-Wide Web 34
3.4. Evaluating Existing Tools 42
4. Research 47
4.1. Hyper-G 47
4.2. Microcosm 48
4.3. AthenaMuse 2 50
4.4. CEC Research Programmes 51
4.5. Other 53
5. Standards 55
5.1. Structuring Standards 55
5.2. Access Mechanisms 62
5.3. Other Standards 63
5.4. Trade Associations 66
6. Future Directions 68
6.1. General Comments on the State-of-the-Art 68
6.2. Quality of Service 70
6.3. Recommended Further Work 71
7. References 76
8. Security Considerations 79
9. Author's Address 79
2.3. 要件定義19 3。 既存のシステム24 3.1。 ゴーファー24 3.2。 広い領域情報サーバ30 3.3。 WWW34 3.4。 既存のツール42 4を評価します。 研究47 4.1。 超-G47、4.2 小宇宙48 4.3。 AthenaMuse、2 50 4.4。 CECは4.5にプログラム51について研究します。 もう一方53 5。 規格55 5.1。 規格55 5.2を構造化します。 メカニズム62 5.3にアクセスしてください。 他の規格63 5.4。 協会66 6を取り引きしてください。 将来の方向68 6.1。 一般は最先端の68に関して6.2にコメントします。 サービスの質70 6.3。 さらなるお勧めの仕事71 7。 参照76 8。 セキュリティ問題79 9。 作者のアドレス79
Acknowledgements
承認
The following people have (knowingly or unknowingly) helped in the preparation of this report: Tim Berners-Lee, John Dyer, Aydin Edguer, Anton Eliens, Tony Gibbons, Stewart Granger, Wendy Hall, Gary Hill, Brian Marquardt, Gunnar Moan, Michael Neuman, Ari Ollikainen, David Pullinger, John Smith, Edward Vielmetti, and Jane Williams. The useful role which NCSA's XMosaic information browser tool played in assembling the information on which this report was based should also be acknowledged - many thanks to its developers.
以下の人々はこのレポートの準備で助けました(故意にか知らずに): ティム・バーナーズ・リー、ジョンDyer、アイドゥンEdguer、アントンEliens、トニー・ギボンズ、スチュワート・グレンジャー、ウェンディーHall、ゲーリー・ヒル、ブライアン・マルクワルト、グナーMoan、マイケル・ヌーマン、アリOllikainen、デヴィッドPullinger、ジョン・スミス、エドワードVielmetti、およびジェーン・ウィリアムズまた、NCSAのXMosaic情報ブラウザツールがこのレポートが基づいた情報を組み立てる際に果たした役に立つ役割は承認されるべきです--開発者をありがとうございます。
All trademarks are hereby acknowledged as being the property of their respective owners.
すべての商標が彼らのそれぞれの所有者の資産であるとしてこれにより承認されます。
Disclaimer
注意書き
This report is based on information supplied to or obtained by Edinburgh University Computing Service (EUCS) in good faith. Neither EUCS nor RARE nor any of their staff may be held liable for any inaccuracies or omissions, or any loss or damage arising from or out of the use of this report.
このレポートは誠実に情報の供給されたかエディンバラ大学によって得られたコンピューターサービス(EUCS)に基づいています。 または、どちらもEUCSかRARE、彼らのスタッフのいずれもどんな誤り、省略、または使用かこのレポートの使用から起こるどんな滅失毀損にもあいやすく保たれるかもしれません。
Adie [Page 2] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[2ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
The opinions expressed in this report are personal opinions of the author. They do not necessarily represent the policy either of RARE or of ECUS.
このレポートに述べられた意見は作者の個人的な見解です。 彼らは必ずRAREかECUSの方針を表すというわけではありません。
Mention of a product in this report does not constitute endorsement either by EUCS or by RARE.
このレポートにおける、製品の言及はEUCSかRAREによる裏書きを構成しません。
Availability
有用性
This document is available in various forms (PostScript, text, Microsoft Word for Windows 2) by anonymous FTP through the following URL:
このドキュメントは以下のURLを通して公開FTPで様々なフォーム(ポストスクリプト、テキスト、Windows2のためのマイクロソフト・ワード)で利用可能です:
ftp://ftp.edinburgh.ac.uk/pub/mmaccess/
ftp://ftp.edinburgh.ac.uk/pub/mmaccess/
ftp://ftp.rare.nl/rare/pub/rtr/rtr8-rfc.../
ftp://ftp.rare.nl/rare/pub/rtr/rtr8-rfc.. 。/
Paper copies are available from the RARE Secretariat.
紙のコピーはRARE事務局から利用可能です。
0. Extended Summary
0. 拡張概要
Introduction
序論
This report is concerned with issues in the intersection of networked information retrieval, database and multimedia technologies. It aims to establish research and academic user requirements for network access to multimedia data, to look at existing systems which offer partial solutions, and to identify what needs to be done to satisfy the most pressing requirements.
このレポートはネットワークでつながれた情報検索、データベース、およびマルチメディア技術の交差点の問題に関係があります。 それは、マルチメディアデータへのネットワークアクセスのために研究とアカデミックなユーザ要件を証明して、部分的解決を提供する既存のシステムを見て、何が、最も緊急の要件を満たすためにする必要であるかを特定することを目指します。
User Requirements
ユーザ要件
There are a number of reasons why multimedia data may need to be accessed remotely (as opposed to physically distributing the data, e.g., on CD-ROM). These reasons centre on the cost of physical distribution, versus the timeliness of network distribution. Of course, there is a cost associated with network distribution, but this tends to be hidden from the end user.
マルチメディアデータが離れて(例えば、物理的にデータを分配することと対照的にCD-ROMの上で)アクセスされる必要があるかもしれない多くの理由があります。 これらの理由は物流の費用をネットワークによる配信のタイムリーさであるに対して集中させられます。 もちろん、ネットワークによる配信に関連している費用がありますが、これは、エンドユーザ隠される傾向があります。
User requirements have been determined by studying existing and proposed projects involving networked multimedia data. It has proved convenient to divide the applications into four classes according to their requirements: multimedia database applications, academic (particularly scientific) publishing applications, cal (computeraided learning), and general multimedia information services.
ユーザ要件は、ネットワークでつながれたマルチメディアデータにかかわる存在と提案されたプロジェクトを研究することによって、決定しました。 それらの要件に応じてアプリケーションを4つのクラスに分割するのが便利であると判明しました: マルチメディアデータベースアプリケーション、アカデミックな(特に科学的な)出版アプリケーション、cal(学習をcomputeraidedした)、および一般的なマルチメディア情報サービス。
Adie [Page 3] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[3ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Database applications typically involve large collections of monomedia (non-text) data with associated textual and numeric fields. They require a range of search and retrieval techniques.
データベースアプリケーションは関連原文と数字フィールドがある「単-メディア」(非テキスト)データの大きい収集に通常かかわります。 彼らはさまざまな検索と検索のテクニックを必要とします。
Publishing applications require a range of media types, hyperlinking, and the capability to access the same data using different access paradigms (search, browse, hierarchical, links). Authentication and charging facilities are required.
出版のアプリケーションはさまざまなメディアタイプ、ハイパーリンク、および異なったアクセスパラダイムを使用することで同じデータにアクセスする能力を必要とします(検索、階層的なブラウズはリンクされます)。 認証と充電施設が必要です。
Cal applications require sophisticated presentation and synchronisation capabilities, of the type found in existing multimedia authoring tools. Authentication and monitoring facilities are required.
カルアプリケーションは既存のマルチメディアオーサリングツールで見つけられたタイプの高性能のプレゼンテーションと連動能力を必要とします。 認証とモニターしている施設が必要です。
General multimedia information services include on-line documentation, campus-wide information systems, and other systems which don't conveniently fall into the preceding categories. Hyperlinking is perhaps the most common requirement in this area.
一般マルチメディア情報サービスはオンラインドキュメンテーション、キャンパス全体の情報システム、および便利に前のカテゴリにならない他のシステムを含んでいます。 ハイパーリンクは恐らくこの領域で最も一般的な要件です。
The analysis of these application areas allows a number of important user requirements to be identified:
これらの応用分野の分析は、多くの重要なユーザ要件が特定されるのを許容します:
o Support for the Apple Macintosh, UNIX and PC/MS Windows
environments.
o アップルマッキントッシュ、UNIX、およびPC/MS Windowsには、環境をサポートしてください。
o Support for a wide range of media types - text, image,
graphics and application-specific media being most
important, followed by video and sound.
o さまざまなメディアには、タイプをサポートしてください--テキスト(イメージ、グラフィックス、および最も重要なアプリケーション特有のメディア)は、ビデオと音で従いました。
o Support for hyperlinking, and for multiple access structures
to be built on the same underlying data.
o ハイパーリンクする、および複数のアクセスには、同じ基本的なデータで建設される構造を支えてください。
o Support for sophisticated synchronisation and presentation
facilities.
o 洗練された連動とプレゼンテーションには、施設をサポートしてください。
o Support for a range of database searching techniques.
o さまざまなデータベースには、探索がテクニックであるとサポートしてください。
o Support for user annotation of information, and for user-
controlled display of sequenced media.
o 情報のユーザ注釈、および配列されたメディアのユーザの制御ディスプレイのために、サポートします。
o Adequate responsiveness - the maximum time taken to retrieve
a node should not exceed 20s.
o 適切な反応性--ノードが検索された最大のわざわざは20年代を超えるべきではありません。
o Support for user authentication, a charging mechanism, and
monitoring facilities.
o ユーザー認証のサポート、充電メカニズム、およびモニターしている施設。
o The ability to execute scripts.
o スクリプトを作成する能力。
Adie [Page 4] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[4ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
o Support for mail-based access to multimedia documents, and
(where appropriate) for printing multimedia documents.
o そして、マルチメディアドキュメントへのメールベースのアクセスのサポート、(適切であるところ) 印刷マルチメディアドキュメントのために。
o Powerful, easy-to-use authoring tools.
o 強力、そして、使用しやすいオーサリングツール。
Existing Systems
既存のシステム
The main information retrieval systems in use on the Internet are Gopher, Wais, and the World-Wide Web. All work on a client-server paradigm, and all provide some degree of support for multimedia data.
インターネットで使用中の主要な情報情報検索システムは、ゴーファーと、Waisと、World Wide Webです。 すべてがクライアント/サーバパラダイムに取り組みます、そして、すべてがマルチメディアデータのサポートをいくらかの提供します。
Gopher presents the user with a hierarchical arrangement of nodes which are either directories (menus), leaf nodes (documents containing text or other media types), or search nodes (allowing some set of documents to be searched using keywords, possibly using WAIS). A range of media types is supported. Extensions currently being developed for Gopher (Gopher+) provide better support for multimedia data. Gopher has a very high penetration (there are over 1000 Gopher servers on the Internet), but it does not provide hyperlinks and is inflexibly hierarchical.
ゴーファーはディレクトリ(メニュー)、葉のノード(テキストを含むドキュメントか他のメディアタイプ)か検索ノード(ことによるとWAISを使用して、何らかのセットのドキュメントがキーワードを使用することで捜されるのを許容する)のどちらかであるノードの階層的配列をユーザに与えます。 さまざまなメディアタイプがサポートされます。 現在ゴーファー(ゴーファー+)のために発生する拡大はマルチメディアデータの、より良いサポートを提供します。 ゴーファーには非常に高い侵入(インターネットに1000のゴーファーサーバの上にある)がありますが、それは、ハイパーリンクを提供しないで、不変に階層的です。
Wais (Wide Area Information Server) allows users to search for documents in remote databases. Full-text indexing of the databases allows all documents containing particular (combinations of) words to be identified and retrieved. Non-text data (principally image data) can be handled, but indexing such documents is only performed on the document file name, severely limiting its usefulness. However, WAIS is ideally suited to text search applications.
Wais(広いArea情報Server)はユーザにリモートデータベースのドキュメントを検索させます。 データベースのインデックスがすべてを許容する全文が特定の状態で含有を記録する、(組み合わせ、)、特定されて、検索されるために、言い表します。 非テキストデータ(主にイメージデータ)を扱うことができますが、そのようなドキュメントに索引をつけるのがドキュメントファイル名に実行されるだけです、厳しく有用性を制限して。 しかしながら、WAISは理想的にテキスト検索アプリケーションに合っています。
World-Wide Web (WWW) is a large-scale distributed hypermedia system. The Web consists of nodes (also called documents) and links. Links are connections between documents: to follow a link, the user clicks on a highlighted word in the source document, which causes the linkedto document to be retrieved and displayed. A document can be one of a variety of media types, or it can be a search node in a similar sense to Gopher. The WWW addressing method means that WAIS and Gopher servers may also be accessed from (indeed, form part of) the Web. WWW has a smaller penetration than Gopher, but is growing faster. The Web technology is currently being revised to take better account of the needs of multimedia information.
WWW(WWW)は大規模な分配されたハイパーメディアシステムです。 ウェブはノード(また、ドキュメントと呼ばれる)とリンクから成ります。 リンクはドキュメントの間の接続です: リンクに続くように、ユーザはソースドキュメントの強調された単語をクリックします。(ソースドキュメントは、linkedtoドキュメントが検索されて、表示されることを引き起こします)。 ドキュメントはさまざまなメディアタイプのひとりであることができますかそれがゴーファーへの同様の意味で検索ノードであるかもしれません。 メソッドがまたWAISとゴーファーサーバがアクセスされるかもしれない手段であると扱うWWW、(本当に、フォームが離れている、)、ウェブ。 WWWはゴーファーより小さい侵入を持っていますが、伸びが早いです。 ウェブ技術は、現在、マルチメディア情報の必要性をより考慮に入れるために改訂することにされます。
These systems all go some way to meet the user requirements.
これらのシステムは遠くくユーザ要件を満たすためにすべて動いています。
o Support for multiple platforms and for a wide range of media
types (through "viewer" software external to the client
program) is good.
o 複数のプラットホームとさまざまなメディアタイプ(クライアントプログラムへの外部の「ビューアー」ソフトウェアを通した)のサポートは良いです。
o Only WWW has hyperlinks.
o WWWだけには、ハイパーリンクがあります。
Adie [Page 5] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[5ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
o There is little or no support for sophisticated presentation
and synchronisation requirements.
o 高性能のプレゼンテーションと連動要件のサポートがまずありません。
o Support for database querying tends to be limited to
"keyword" searches, but current developments in Gopher and
WWW should make more sophisticated queries possible.
o データベース質問のサポートは、「キーワード」検索に制限される傾向がありますが、ゴーファーとWWWでの現在の開発で、より洗練された質問は可能になるべきです。
o Some clients support user annotation of documents.
o ドキュメントの注釈をユーザにサポートするクライアントもいます。
o Response times for all three systems vary substantially
depending on the network distance between client and server,
and there is no support for isochronous data transfer.
o 実質的にクライアントとサーバの間のネットワーク距離によって、すべての3台のシステムのための応答時間は異なります、そして、同一時間のデータ転送のサポートが全くありません。
o There is little in the way of authentication, charging and
monitoring facilities, although these are planned for WWW.
o 施設を請求して、これらがWWWのために計画されますが、モニターして、少ししか認証の方法でありません。
o Scripting is not supported because of security issues
o スクリプティングは安全保障問題のためにサポートされません。
o WWW supports a mail responder.
o WWWはメール応答者をサポートします。
o The only system sufficiently complex to warrant an authoring
tool is WWW, which has editors to support its hypertext
markup language.
o オーサリングツールを保証できるくらい複雑な唯一のシステムがWWWです。(そのWWWはハイパーテキストマークアップ言語をサポートするエディタがいます)。
Research
研究
There are a number of research projects which are of significant interest.
多くの重要におもしろい研究計画があります。
Hyper-G is an ambitious distributed hypermedia research project at the University of Graz. It combines concepts of hypermedia, information retrieval systems and documentation systems with aspects of communication and collaboration, and computer-supported teaching and learning. Automatic generation of hyperlinks is supported, and there is a concept of generic structures which can exist in parallel with the hyperlink structure. Hyper-G is based on UNIX, and is in use as a CWIS at Graz. Gateways between Hyper-G and WWW exist.
超-Gはグラーツ大学の野心満々の分配されたハイパーメディア研究計画です。 それはコミュニケーションと共同の局面、コンピュータでサポートしている教育、および学習にハイパーメディア、情報検索システム、およびドキュメンテーション・システムの概念を結合します。 ハイパーリンクの自動生成はサポートされます、そして、ハイパーリンク構造と平行して存在できるジェネリック構造の概念があります。 超-Gは、UNIXに基づいていて、CWISとしてグラーツで使用中です。 Hyper-GとWWWの間のゲートウェイは存在しています。
Microcosm is a PC-based hypermedia system developed at the University of Southampton. It can be viewed as an integrating hypermedia framework - a layer on top of a range of existing applications which enables relationships between different documents to be established. Hyperlinks are maintained separately from the data. Networking support for Microcosm is currently under development, as are versions of Microcosm for the Apple Macintosh and for UNIX. Microcosm is currently being "commercialised".
小宇宙はサウサンプトン大学で開発されたPCベースのハイパーメディアシステムです。 統合しているハイパーメディアフレームワークとしてそれを見なすことができます--異なったドキュメントの間の関係が確立されるのを可能にするさまざまな既存のアプリケーションの上の層。 ハイパーリンクは別々にデータから維持されます。 アップルマッキントッシュとUNIXにおいて、Microcosmのネットワークサポートは現在、Microcosmのバージョンのように開発中です。 小宇宙は現在、「商業化されています」。
Adie [Page 6] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[6ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
AthenaMuse 2 is an ambitious distributed hypermedia authoring and presentation system under development by a university/industry consortium based at MIT. It will have good facilities for presentation and synchronisation of multimedia data, strong authoring support, and will include support for networking isochronous data. It will be a commercial product. Initial versions will support UNIX and X windows, with a PC/MS Windows version following. Apple Macintosh support has lower priority.
AthenaMuse2はMITに拠点を置く大学/産業共同体による開発中の野心満々の分配されたハイパーメディアオーサリングとプレゼンテーションシステムです。 それは、マルチメディアデータのプレゼンテーションと連動のための良い施設、強い書いているサポートを持って、同一時間のデータをネットワークでつなぐサポートを含むでしょう。 それは商品になるでしょう。 PC/MS Windowsバージョンが従っていて、初期のバージョンは、UNIXとXが窓であるとサポートするでしょう。 アップルのマッキントッシュサポートには、低優先度があります。
The "Xanadu" project is designing and building an "open, social hypermedia" distributed environment, but shows no sign of delivering anything after several years of work.
「ザナドゥ」プロジェクトは、「開いていて、社会的なハイパーメディア」分散環境を設計して、築き上げていますが、数年の仕事の後に何も提供する兆候を全く示していません。
The European Commission sponsors a number of peripherally relevant projects through its Esprit and RACE research programmes. These programmes tend to be oriented towards commercial markets, and are thus not directly relevant. An exception is the Esprit IDOMENEUS project, which brings together workers in the database, information retrieval and multimedia fields. It is recommended that RARE establish a liaison with this project.
欧州委員会は研究がプログラムするそのEspritとRACEを通して多くの周囲に関連しているプロジェクトを後援します。 これらのプログラムは、商業市場に向かって適応する傾向があって、その結果、直接関連していません。 例外はEsprit IDOMENEUSプロジェクトです。(そのプロジェクトはデータベース、情報検索、およびマルチメディア分野に労働者を集めます)。 RAREがこのプロジェクトとの連絡係を確立するのは、お勧めです。
There are a variety of other academic and commercial research projects which are also of interest. None of them are as directly relevant as those outlined above.
他のさまざまなまた、興味があるアカデミックで商業の研究計画があります。 それらのいずれも直接上に概説されたものほど関連していません。
Standards
規格
There are a number of existing and emerging standards for structuring hypermedia applications. Of these, the most important are SGML, HyTime, MHEG, ODA, PREMO and Acrobat. All bar the last are de jure standards, while Acrobat is a commercial product which is being proposed as a de facto standard.
多くの存在とハイパーメディアアプリケーションを構造化する規格として現れるのがあります。 これらにおいて、最も重要であるのは、SGMLと、HyTimeと、MHEGと、小田と、PREMOとAcrobatです。 すべてが禁じる、最終はデジュリスタンダードです、Acrobatがデファクトスタンダードとして提案されているa商品ですが。
SGML (Standard Generalized Markup Language) is a markup language for delimiting the logical and semantic content of text documents. Because of its flexibility, it has become an important tool in hypermedia systems. HyTime is an ISO standardised infrastructure for representing integrated, open hypermedia documents, and is based on SGML. HyTime has great expressive power, but is not optimised for run-time efficiency. It is recommended that future RARE work on networked hypermedia should take account of the importance of SGML and HyTime.
SGML(標準のGeneralized Markup Language)は、テキストドキュメントの論理的で意味の中身を区切るためのマークアップ言語です。 柔軟性のために、それはハイパーメディアシステムの重要なツールになりました。HyTimeはISOが統合していて、開いているハイパーメディアドキュメントを表すためにインフラストラクチャを標準化して、SGMLに基づいているということです。 HyTimeは、かなりの表現力を持っていますが、ランタイム効率のために最適化されません。 ネットワークでつながれたハイパーメディアに対する今後のRARE仕事がSGMLとHyTimeの重要性を考慮に入れるのは、お勧めです。
MHEG (Multimedia and Hypermedia information coding Experts Group) is a draft ISO standard for representing hypermedia applications in a platform-independent form. It uses an object-oriented approach, and is optimised for run-time efficiency. Full IS status for MHEG is expected in 1994. It is recommended that RARE keep a watching brief
MHEG(Experts Groupをコード化するマルチメディアとHypermedia情報)はプラットホームから独立しているフォームにハイパーメディアアプリケーションを表す草稿ISO規格です。 それは、オブジェクト指向アプローチを使用して、ランタイム効率のために最適化されます。 完全であるのは、MHEGのための状態が1994年に予想されるということです。 RAREが傍聴依頼を保管するのは、お勧めです。
Adie [Page 7] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[7ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
on MHEG.
MHEGに関して。
The ODA (Open Document Architecture) standard is being enhanced to incorporate multimedia and hypermedia features. However, interest in ODA is perceived to be decreasing, and it is recommended that ODA should not form a basis for further RARE work in networked hypermedia.
ODA(開いているDocument Architecture)規格は、マルチメディアとハイパーメディア機能を取り入れるために高められています。 しかしながら、ODAへの関心が減少していると知覚されて、ODAがネットワークでつながれたハイパーメディアにおけるさらなるRARE仕事の基礎を形成しないのは、お勧めです。
PREMO is a new work item in the ISO graphics standardisation community, which appears to overlap with MHEG and HyTime. It is not clear that the PREMO work, which is at a very early stage, is worthwhile in view of the existence of those standards.
PREMOはISOグラフィックス規格化共同体の新しい仕事項目です。(それは、MHEGとHyTimeに重なるように見えます)。 PREMO仕事(まさしくその初期段階に、ある)それらの規格の存在から見て価値があるのは、明確ではありません。
Acrobat PDF is a format for representing multimedia (printable) documents in a portable, revisable form. It is based on Postscript, and is being proposed by Adobe Inc (originators of Postscript) as an industry standard. RARE should maintain awareness of this technology in view of its potential impact on multimedia information systems.
アクロバットPDFは、携帯用の、そして、改訂可能なフォームにマルチメディアの(印刷可能)のドキュメントを表すための形式です。 それは、Postscriptに基づいていて、業界基準としてAdobe Inc(Postscriptの創始者)によって提案されています。 RAREはマルチメディア情報システムの上の可能性のある衝撃から見てこの技術の認識を維持するはずです。
There are various standards which have relevance to the way multimedia data is accessed across the network. Many of these have been described in a previous report [1]. Two further access protocols are the proposed multimedia extensions to SQL, and the Document Filing and Retrieval protocol. Neither of these are likely to have major significance for networked multimedia information systems.
マルチメディアデータがネットワークの向こう側にアクセスされるように関連性を持っている様々な規格があります。 これらの多くが予報[1]で説明されます。 さらなる2つのアクセス・プロトコルが、SQLへの提案されたマルチメディアエクステンションと、Document FilingとRetrievalプロトコルです。 これらのどちらもネットワークでつながれたマルチメディア情報システムのための主要な意味を持っていなさそうにはありません。
Other standards of importance include:
他の重要な規格は:
o MIME, a multimedia email standard which defines a range of
media types and encoding methods for those types which are
useful in a wider context.
o MIME、マルチメディアは、より広い関係で役に立つそういったタイプの人のためにさまざまなメディアタイプとコード化メソッドを定義する規格をメールします。
o AVIs (Audio-Visual Interactive services) and the associated
multimedia scripting language SMSL, which form a
standardisation initiative within CCITT (now ITU-TSS) to
specify interactive multimedia services which can be
provided across telephone/ISDN networks.
o AVI(オーディオに視覚のInteractiveサービス)と関連マルチメディアスクリプト言語SMSL。(そのSMSLは電話/ISDNネットワークの向こう側に提供できるインタラクティブ・マルチメディアサービスを指定するCCITT(現在のITU-TSS)の中の規格化イニシアチブを形成します)。
There are two important trade associations which are involved in standardisation work. The Interactive Multimedia Association (IMA) has a Compatibility Project which is developing a specification for platform-independent interactive multimedia systems, including networking aspects. A newly-formed group, the Multimedia Communications Forum (MMCF), plans to provide input to the standards bodies. It is recommended that RARE become an Observing Member of the MMCF. A third trade association - the Multimedia Communications Community of Interest - has also just been formed.
規格化仕事にかかわる2つの重要な産業団体があります。 インタラクティブ・マルチメディア協会(IMA)にはプラットホームから独立しているインタラクティブ・マルチメディアシステムのための仕様を開発しているCompatibility Projectがあります、局面をネットワークでつなぐのを含んでいて。 新たに形成されたグループ(Multimedia Communications Forum(MMCF))は、入力を標準化団体に提供するのを計画しています。 RAREがMMCFのObservingメンバーになるのは、お勧めです。 また、3番目の産業団体(InterestのMultimedia Communications Community)はちょうど形成されたところです。
Adie [Page 8] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[8ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Future Directions
将来の方向
Three common design approaches emerge from the variety of systems and standards analysed in this report. They can be described in terms of distinctions between different aspects of the system:
3つの一般的な設計手法がこのレポートで分析されたシステムと規格のバラエティーから出て来ます。 システムの異なった局面の区別でそれらについて説明できます:
o content is distinct from hyperstructure
o 内容は「超-構造」と異なっています。
o media type is distinct from media encoding
o メディアタイプはメディアコード化と異なっています。
o data is distinct from protocol
o データはプロトコルと異なっています。
Distributed hypermedia systems are emerging from the research/development phase into the experimental deployment phase. However, the existing global information systems (Gopher, WAIS and WWW) are still largely limited to the use of external viewers for nontextual data. The most significant mismatches between the capabilities of currently-deployed systems and user requirements are in the areas of presentation and quality of service (i.e., responsiveness).
分配されたハイパーメディアシステムは研究/開発段階から実験展開フェーズに出て来ています。 しかしながら、既存のグローバルな情報システム(ゴーファー、WAIS、およびWWW)はまだ外部ビューワのnontextualデータの使用に主に制限されています。 現在配布しているシステムとユーザ要件の能力の間の最も重要なミスマッチがプレゼンテーションとサービスの質(すなわち、反応性)の領域にあります。
Improving QOS is significantly more difficult than improving presentation capabilities, but there are a number of possible ways in which this could be addressed. Improving feedback to the user, greater multi-threading of applications, pre-fetching, caching, the use of alternative "views" of a node, and the use of isochronous data streams are all avenues which are worth exploring.
QOSを改良するのはプレゼンテーション能力を改良するよりかなり難しいのですが、これを扱うことができた多くの可能な方法があります。 ユーザにフィードバックを改良するアプリケーションの、よりすばらしいマルチスレッド化、プレ魅惑的です、キャッシュ、ノードの代替の「視点」の使用、および同一時間のデータ・ストリームの使用はすべて探検する価値がある大通りです。
In order to address these problems, it is recommended that RARE seek to adapt and enhance existing tools, rather than develop new ones.
これらのその問題を訴えるために、RAREが新しいものを開発するよりむしろ既存のツールを適合させて、高めようとするのは、お勧めです。
In particular, it is recommended that RARE select the World-Wide Web to concentrate its efforts on. The reasons for this choice revolve around the flexibility of the WWW design, the availability of hyperlinks, the existing effort which is already going into multimedia support in WWW, the fact that it is an integrating solution incorporating both WAIS and Gopher support, and its high rate of growth compared to Gopher (despite Gopher's wider deployment). Gopher is the main competitor to WWW, but its inflexibly hierarchical structure and the absence of hyperlinks make it difficult to use for highly-interactive multimedia applications.
RAREが主力を注ぐWWWを選択するのは、特に、お勧めです。 この選択の理由はWWWデザインの柔軟性を中心題目とします、ハイパーリンクの有用性、WWWで既にマルチメディアサポートに入っている既存の取り組み、それがゴーファー(ゴーファーの、より広い展開にもかかわらず)と比べて、WAISとゴーファーサポートとその高成長率の両方を取り入れる統合ソリューションであるという事実。 ゴーファーはWWWへの主な競合相手ですが、不変に階層的な構造とハイパーリンクの欠如で、それは非常に対話的なマルチメディアアプリケーションに使用するのが難しくなります。
It is recommended that RARE should invite proposals for and subsequently commission work to:
それがお勧めである、そのRAREは提案を招待するはずであり、次にコミッションは以下のことのために扱います。
o Develop conversion tools from commercial multimedia
authoring packages to WWW, and accompanying authoring
guidelines.
o WWW、および商業マルチメディア書いているパッケージから付随の書いているガイドラインまで変換ツールを開発してください。
Adie [Page 9] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[9ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
o Implement and evaluate the most promising ways of overcoming
the QOS problem.
o QOS問題を克服する最も有望な方法を実装して、評価してください。
o Implement a specific user project using these tools, to
validate that the facilities being developed are truly
relevant to real applications.
o これらのツールを使用して、特定のユーザプロジェクトを実装してください、そして、それを有効にするために、本当に、開発される施設は実際のアプリケーションに関連しています。
o Use the experience gained to inform and influence the
development of the WWW technology.
o WWW技術の開発を知らせて、影響を及ぼすために行われた経験を使用してください。
o Contribute to the development of PC/MS Windows and Apple
Macintosh WWW clients, particularly in the multimedia data
handling area.
o 特にマルチメディアデータハンドリング領域でPC/MS WindowsとアップルマッキントッシュWWWの開発にクライアントを寄付してください。
It is noted that the rapid growth of WWW may in the future lead to problems through the implementation of multiple, uncoordinated and mutually incompatible add-on features. To guard against this trend, it may be appropriate for RARE, in coordination with CERN and other interested parties such as NCSA, to:
WWWの急速な成長が将来複数の、そして、非調整されて互いに両立しないアドオンの特徴の実装を通して問題を引き起こすかもしれないことに注意されます。 RAREに、この傾向に用心するなら、以下のことのためにNCSAなどのCERNと他の利害関係者と共にコーディネートで適切であるかもしれません。
o Encourage the formation of a consortium to coordinate WWW
technical development.
o 共同体の構成がWWWの技術的な開発を調整するよう奨励してください。
1. Introduction
1. 序論
1.1. Background
1.1. バックグラウンド
This study was inspired by the realisation that while some aspects of distributed multimedia technology are being actively introduced into the European research community (for instance, audiovisual conferencing, through the MICE project), other aspects are receiving less attention. In particular, one category in which there seems to be relatively little activity is providing solutions to ease remote access to multimedia resources (for instance, accessing stored audio/video clips or images, or indeed entire multimedia applications, across the network). Few commercial products address this, and the relevance of existing standards in this area is unclear.
分散型マルチメディア技術のいくつかの局面が活発にヨーロッパの研究団体(例えば、MICEプロジェクトを通した視聴覚の会議)に紹介されている間他の局面が、より少ない配慮を受けているという認識でこの研究は奮い立たせられました。 特に、比較的少ない活動があるように思える1つのカテゴリが、マルチメディアリソースに遠隔アクセスを緩和するために解決法を提供しています(例えば、アクセスはオーディオ/ビデオクリップ、イメージ、または本当に全体のマルチメディア応用を保存しました、ネットワークの向こう側に)。 わずかな商品しかこれを扱いません、そして、この領域における、既存の規格の関連性は不明瞭です。
Of the 50 or so research projects documented in the recent RARE distributed multimedia survey [1], only about six have a direct relevance to this application area. Where stated in the survey, the main research effort in these projects is often directed towards the "difficult" problems, such as the transfer of isochronous data and the design and implementation of object-oriented multimedia databases, rather than towards user-oriented issues.
最近のRARE分散型マルチメディア調査[1]で記録されたおよそ50の研究計画では、およそ6だけがこのアプリケーション部にダイレクト関連性を持っています。 調査で述べられているところでは、これらのプロジェクトにおける主な研究取り組みがしばしば「難しい」問題に向けられます、同一時間のデータの転送や利用者志向問題に向かってというよりむしろオブジェクト指向マルチメディアデータベースの設計と実装のように。
Adie [Page 10] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[10ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
This report is concerned with practical issues in the intersection of networked information retrieval, database and multimedia technologies. It aims to establish actual user requirements in this area, to look at existing systems which offer partial solutions, and to identify what additional work needs to be done to satisfy the most pressing requirements.
このレポートはネットワークでつながれた情報検索、データベース、およびマルチメディア技術の交差点の実用的な問題に関係があります。 それは、実施している者要件をこの領域に証明して、部分的解決を提供する既存のシステムを見て、どんな追加仕事が、最も緊急の要件を満たすためにする必要であるかを特定することを目指します。
1.2. Terminology
1.2. 用語
In order to discuss multimedia information systems, we need a consistent terminology. The vocabulary defined below embodies some of the concepts of the Dexter hypertext reference model [2]. This model is sufficiently general to be useful for describing most of the facilities and requirements of the multimedia information systems described in this report. (However, the Dexter model does not describe searchable index objects - it is not a database reference model.)
マルチメディア情報システムについて議論するために、私たちは一貫した用語を必要とします。 以下で定義されたボキャブラリーはデクスターハイパーテキスト規範モデル[2]の概念のいくつかを具体化します。 このモデルはこのレポートで説明されたマルチメディア情報システムの施設と要件の大部分について説明することの役に立つことができるくらい一般的です。 (しかしながら、デクスターモデルは検索可能な索引オブジェクトについて説明しません--それはデータベース規範モデルではありません。)
anchor An identified portion of a node. E.g., in a text
node, an anchor might be a string of one or more
adjacent characters, while in an image node it
might be a rectangular area of the image.
アンカーAnはノードの一部を特定しました。 例えば、テキストノードでは、アンカーは一連の1つ以上の隣接しているキャラクタであるかもしれません、それがイメージノードのイメージの長方形エリアであるかもしれませんが。
composite node A node containing data of multiple media types.
マルチメディアに関するデータを含む合成ノードAノードがタイプします。
document Often used loosely as a synonym for node.
ノードに同義語として緩く使用されるOftenを記録してください。
hyperdocument We refer to a collection of related nodes,
linked internally with hyperlinks, as a
"hyperdocument". Examples are a database of
medical images and associated text; a module
from a suite of teaching material; or an article
in a scientific journal. A hyperdocument may
contain hyperlinks to other data which exists in
internally with hyperlinks, as a
"hyperdocument". Examples are a other
hyperdocuments, but can be viewed as largely
self-contained. It is a highlevel "unit of
authoring", but is not necessarily perceived as
a distinct unit by a reader (although it may be
so perceived, particularly if it contains few
hyperlinks to outside entities).
hyperdocument Weは内部的にハイパーリンクにリンクされた関連するノードの収集を"「超-ドキュメント」"と呼びます。 例は医学のイメージと関連テキストに関するデータベースです。 教材の一組からのモジュール。 または、科学雑誌の記事。 「超-ドキュメント」は"「超-ドキュメント」"として中にハイパーリンクで内部的に存在する他のデータにハイパーリンクを含むかもしれません。 例を他の「超-ドキュメント」ですが、主に自己充足的であるとして見なすことができます。 それは、highlevel「オーサリングのユニット」ですが、必ず異なったユニットとして読者によって知覚されるというわけではありません(そうするかもしれませんが、そうになってください知覚されて、特に実体の外にわずかなハイパーリンクしか含んでいないなら)。
hyperlink Set of one or more source anchors and one or
more target anchors. Also known simply as a
"link".
1人以上のソースのアンカーと1個以上の目標のハイパーリンクSetは投錨します。 また、単に「リンク」として、知られています。
Adie [Page 11] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[11ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
isochronous (adjective) Describes a continuous flow of data which
is required to be delivered by the network under
critical time constraints.
同一時間の(形容詞)は重要な時間規制でネットワークによって提供されるのに必要であるデータの連続した流れについて説明します。
leaf node A node which contains no source anchors.
ソースのアンカーを全く含まない葉のノードAノード。
media type An attribute of data which describes the general
nature of its expected presentation. The value
of this attribute could be one of the following
(not exhaustive) list:
メディアは予想されたプレゼンテーションの一般的な本質について説明するデータのAn属性をタイプします。 この属性の値は以下の(徹底的でない)リストの1つであるかもしれません:
o Text
o テキスト
o Sound
o 音
o Image (e.g., a "photograph")
o イメージ(例えば、「写真」)
o Graphics (e.g., a "drawing")
o グラフィックス(例えば、「図面」)
o Animation (i.e., moving graphics)
o アニメーション(すなわち、感動的なグラフィックス)
o Movie (i.e., moving image)
o 映画(すなわち、動画)
monomedia (adjective) Said of data which is all of the same media
type.
「単-メディア」(形容詞)は同じメディアタイプのすべてであるデータについて言いました。
multimedia (adjective) Said of data which contains different media
types. This definition is stricter than general
usage, where "multimedia" is often used as a
generic term for non-textual data, and where it
may even be used as a noun.
マルチメディア(形容詞)は異なったメディアタイプを含むデータについて言いました。 この定義は一般的な用法より厳しいです。そこでは、「マルチメディア」が非原文のデータに総称としてしばしば使用されて、それは名詞として使用さえされるかもしれません。
physical media Magnetic or optical storage. Not to be confused
with media type!
物理的なメディアMagneticか光記憶装置。 メディアに混乱しないように、タイプしてください!
[simple] node A monomedia object which may be retrieved and
displayed as a single unit.
単一の単位として検索されて、表示されるかもしれない[簡単]のノードA「単-メディア」オブジェクト。
source anchor An anchor which may be "actioned" by the user,
causing the node(s) containing the target
anchor(s) in the same hyperlink to be retrieved
and displayed. This process is called
"traversing the link".
ソースアンカーAnは投錨します(ユーザは"actionedする"であるかもしれません)、同じハイパーリンクに目標アンカーを含むノードが検索されて、表示されることを引き起こして。 このプロセスは「リンクを横断します。」と呼ばれます。
target anchor an anchor forming part of a hyperlink, whose
containing node is retrieved and displayed when
the hyperlink is traversed.
目標がハイパーリンクの一部を形成するアンカーを据えつけて、ハイパーリンクを横断するとき、だれがノードを含むかを検索して、表示します。
Adie [Page 12] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[12ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
2. User Requirements
2. ユーザ要件
User requirements in an area such as networking, which is subject to rapid technological change, are sometimes difficult to identify. To an extent, technology leads applications, and users will exploit what is possible.
急速な技術変化を被りやすいネットワークなどの領域のユーザ要件は特定するのが時々難しいです。 程度まで、技術はアプリケーションを導きます、そして、ユーザは可能なことを利用するでしょう。
2.1. Applications
2.1. アプリケーション
Awareness of the range of networked multimedia applications which are currently being envisaged by computer users in the academic and research community leads to a better understanding of the technical requirements. This section outlines some projects which require remote access to multimedia information across research networks, and which are currently either at a preliminary stage or underway. The projects are divided into broad categories according to their characteristics.
現在アカデミック、そして、研究共同体のコンピュータユーザによって考えられているネットワークでつながれたマルチメディア応用の範囲の認識は技術的要求事項の、より良い理解に通じます。 このセクションは研究ネットワークの向こう側にマルチメディア情報に遠隔アクセスを必要として、現在、準備している段階のどちらかであるか、または進行中であるいくつかのプロジェクトについて概説します。 それらの特性に応じて、プロジェクトは広いカテゴリに分割されます。
Multimedia Databases
マルチメディアデータベース
Here are several examples of multimedia projects which have a "database" character.
ここに、「データベース」キャラクタがあるマルチメディアプロジェクトに関するいくつかの例があります。
The Peirce Telecommunity Project
ピアスTelecommunityプロジェクト
This project centres on the construction of a multimedia (text and
image) database of the works of the American philosopher Peirce,
together with tools to process the data and to make it available
over the Internet. A sub-project at Brown University focuses on
adapting existing client/server network tools for this purpose.
The requirements for network access include facilities for
structured viewing, intelligent retrieval, navigation, linking,
and annotation, as well as for domainspecific processing.
このプロジェクトは、アメリカ人の哲学者の作品に関するマルチメディア(テキストとイメージ)データベースの工事のときにデータを処理して、インターネットの上でそれを利用可能にするようにツールと共にピアスを集中させます。 ブラウン大学のサブプロジェクトは、このために既存のクライアント/サーバネットワークツールを適合させるのは焦点を合わせます。 ネットワークアクセスのための要件は構造化された見る、知的な検索、ナビゲーション、リンク、および注釈のための施設を含んでいます、よくdomainspecific処理のように。
Museum Object Databases
博物館オブジェクトデータベース
The RAMA (Remote Access to Museum Archives) project is funded
under the EEC RACE II programme. Its objective is to develop a
system which allows museums to make multimedia information about
their exhibits and archived material available over an ISDN
network. The requirements capture and technical architecture
design phases are now complete, and a prototype system will be
delivered in June 1993 to link the Ashmolean Museum (Oxford, GB),
the Musee d'Orsay (Paris, FR) and the Museum Archeological
National (Madrid, ES). Image data is the main media type of
interest, although video and sound may also play a part.
ラマ(博物館アーカイブへのリモートAccess)プロジェクトにEEC RACE IIプログラムで資金を供給します。 目的は博物館がそれらの展示品に関するマルチメディア情報を作ることができるシステムとISDNネットワークの上で利用可能な格納された材料を発生することです。 要件捕獲とテクニカル・アーキテクチャ設計段階は現在完全です、そして、プロトタイプ装置は、1993年6月にアシュモーリアン博物館(オックスフォード、GB)、オルセー美術館(パリ、FR)、および博物館Archeological National(マドリード、ES)をリンクするために提供されるでしょう。 また、ビデオと音は役を務めるかもしれませんが、イメージデータは興味がある主なメディアタイプです。
Adie [Page 13] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[13ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
The Bristol Biomedical Videodisk Project
ブリストルの生物医学ビデオディスクプロジェクト
The Bristol Biomedical Videodisc is a collection of Medical,
Veterinary and Dental images. The collection holds some 24,000
still images and is continuously growing. Textual information
regarding the images is included as part of the database and this
can be searched on any keyword, number or other data type, or a
combination of any of these. The images are currently delivered
in analogue form on a videodisc, but many institutions are unable
to afford the cost of videodisc players. Investigations into
making this image and text database available across the network
are underway.
ブリストルBiomedical VideodiscはMedical、Veterinary、およびDentalイメージの収集です。 収集は、およそ2万4000の静止画像を保持して、絶え間なく成長しています。 イメージに関する文字情報は、これらのどれかのどんなキーワード、数、他のデータ型、または組み合わせのときにもデータベースとこの一部を捜すことができるので、含まれています。 イメージは現在、ビデオディスクのアナログフォームで提供されますが、多くの団体はビデオディスクプレーヤーの費用を都合することができません。 このイメージとテキストデータベースをネットワークの向こう側に利用可能にすることへの調査は進行中です。
ArchiGopher
ArchiGopher
ArchiGopher is a Gopher server at the College of Architecture,
University of Michigan, dedicated to the dissemination of
architectural knowledge. Presently in its infancy, ArchiGopher is
intended to become a multimedia resource for all architecture
faculty and students world-wide. Some of the available or planned
resources are:
ArchiGopherはArchitectureの大学、建築知識の普及に捧げられたミシガン大学のゴーファーサーバです。 現在始まったばかり、ArchiGopherが世界中ですべてのアーキテクチャ教授陣と学生へのマルチメディアリソースになることを意図します。 利用可能であるか計画されたリソースのいくつかは以下の通りです。
o The College's image bank.
o 大学のイメージ銀行。
o The CAD group's collection of computer models (already
started).
o CADグループのコンピュータの収集はモデル化されます(既に始められます)。
o The Doctoral Program's recent dissertation proposals and
abstracts.
o Doctoral Programの最近の論文提案と要約。
o Example archive of Kandinsky paintings.
o カンディンスキー絵の例のアーカイブ。
o Images of 3D CAD projects.
o 3D CADのイメージズは突出しています。
The principal media type in ArchiGopher is image. Files are
stored in both TIFF and GIF format.
ArchiGopherの主要なメディアタイプはイメージです。 ファイルはTIFFとGIF形式の両方に保存されます。
Vatican Library Exhibit
バチカン市国図書館展示品
In January 1993, the US Library of Congress mounted an electronic
version of the exhibition ROME REBORN: THE VATICAN LIBRARY AND
RENAISSANCE CULTURE. The exhibition was subsequently processed by
the University of Virginia Library. The text files were broken
into individual captions associated directly with each image and a
WAIS-searchable version of the object index generated. This has
been made available on Gopher by the University of Virginia
Library.
1993年1月に、米国議会図書館は展示会ROME REBORNの電子版を取り付けました: バチカン市国ライブラリとルネッサンス文化。 展示会は次に、バージニア大学図書館によって処理されました。 直接各イメージに関連している個々の見出しとオブジェクトインデックスのWAIS探せるバージョンはテキストファイルに発生していた状態で細かく分けられました。 これをバージニア大学図書館のそばでゴーファーで利用可能にしました。
Adie [Page 14] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[14ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
This project is particularly interesting, as it demonstrates some
limitations of the Gopher system. The principal media types are
image and text, and it is difficult to associate a caption with
its image - each must be fetched separately, and using the XMosaic
or xgopher client software it is not possible to tell which menu
entry is the image and which the caption. (This may be a
consequence of how the data has been configured for the Gopher
server; if so, a requirement for better publishing tools may be
indicated.) Furthermore, searching the object index will result
in a Gopher menu containing references to catalogue entries for
relevant exhibits, but not to the online images of the exhibits
themselves, which severely limits the usefulness of the index.
ゴーファーシステムのいくつかの限界を示すので、このプロジェクトは特におもしろいです。 そして、見出しをイメージに関連づけるのは難しいです--主要なメディアタイプがイメージとテキストであり、別々にそれぞれをとって来なければならなくて、XMosaicかxgopherクライアントソフトウェアを使用して、どのメニュー項目がイメージであるかを言うのが可能でない、どれ、見出し。 (これはデータがゴーファーサーバのためにどう構成されたかに関する結果であるかもしれません; そうだとすれば、より良い出版ツールのための要件は示されるかもしれません。) その上、オブジェクトインデックスを捜すのは、関連展示品のためのエントリーをカタログに載せるために参照を含むゴーファーメニューとなりますが、展示品自体のオンラインイメージとなるというわけではないでしょう、厳しくインデックスの有用性を制限するどれ。
It is interesting to note that during the preparation of this
report, the Vatican Exhibition has been mounted on the WorldWide
Web (WWW). The hypermedia presentation on the Web is very much
more attractive to use than the Gopher version.
このレポートの準備の間バチカン市国ExhibitionがWorld Wide Web(WWW)に取り付けられていることに注意するのはおもしろいです。 ウェブにおけるハイパーメディアプレゼンテーションは、使用するためにゴーファーバージョンより非常にはるかに魅力的です。
Jukebox
ジュークボックス
Jukebox is a project supported by the EEC libraries program. The
project aims to evaluate a pilot service providing library users
with on-line access to a database of digital sound recordings.
The database will support multi-user access and use suitable
storage media to make available sound recordings in a compressed
format. Users will access the service with a personal computer
connected to a telematic network.
ジュークボックスはEECライブラリプログラムでサポートされたプロジェクトです。 プロジェクトは、デジタル録音に関するデータベースへのオンラインアクセスを図書館の利用者に提供するパイロットサービスを評価することを目指します。 データベースは、圧縮形式における利用可能な録音をするのにマルチユーザにアクセスをサポートして、適当な記憶媒体を使用するでしょう。 パーソナルコンピュータがtelematicネットワークに接続される状態で、ユーザはサービスにアクセスするでしょう。
Scientific Publishing
科学的出版
There are several refereed electronic academic journals presently distributed on the Internet. These tend to be text-only journals, and have not really addressed the issues of delivering and manipulating non-text data.
現在インターネットで配布されているいくつかの仲裁された電子学術誌があります。 これらは、テキストのみジャーナルである傾向があって、本当に非テキストデータを提供して、操る問題を扱っていません。
Many scientific publishers have plans for electronic publishing of existing academic journals and conference proceedings, either on physical media or on the network. The Journal of Biological Chemistry is now published on CD-ROM, for instance. Some publishers view CD-ROM as an interim step to the ultimate goal of making journals available on-line on the Internet.
多くの科学的出版社には、既存の学術誌の電子出版のためのプランと物理的なメディアかネットワークに関する会議の議事録があります。 Biological ChemistryのJournalは現在、例えば、CD-ROMの上で発行されます。 インターネットでオンラインでジャーナルを利用可能にするという究極の目標への中間の段階としてCD-ROMを見なす出版社もあります。
The main types of non-text data which are envisaged are:
考えられる主なタイプに関する非テキストデータは以下の通りです。
o Images. In many cases, image data (a microphotograph, say)
is central to an article. Software which recognises that
the text may be of secondary importance to the image is
required.
o 像を描きます。 多くの場合、イメージデータ(たとえば、顕微写真)は記事に主要です。 テキストがセカンダリにイメージに重要であるかもしれないと認めるソフトウェアが必要です。
Adie [Page 15] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[15ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
o Application-specific data. The ChemLab and MoleculeLab
applications are widely used, and the integration of
corresponding data types with journal articles will enhance
readers' ability to visualise molecular structures.
Similarly, mathematics appearing in scientific papers could
be represented in a form suitable for processing by
applications such as Mathematica. Mathematical content
could then become a much more interactive and dynamic aspect
of research publications.
o アプリケーション特有のデータ。 ChemLabとMoleculeLabアプリケーションは広く使用されます、そして、雑誌の記事がある対応するデータ型の統合は分子構造を想像する読者の能力を高めるでしょう。 同様に、処理に適したフォームにマテマテイカなどのアプリケーションで学術論文に現れる数学は表すことができるでしょう。 そして、数学の内容は研究刊行物のはるかに対話的でダイナミックな局面になることができました。
o Tabular data. The ability for a reader to extract tabular
data from a research paper, to produce a graphical
representation, to subset the data, and to further process
it in a number of different ways, is viewed as an essential
part of scientific electronic publishing.
o 表データ。 読者が研究報告から表データを抜粋する能力は、グラフ表示、部分集合へのデータを作り出して、さらに多くの異なった方法でそれを処理するために科学的電子出版の不可欠の部分として見なされます。
o Movies. The American Astronomical Society regularly
publishes videos to go with its academic journals.
Electronic publishing can improve on this "hard copy"
publishing by integrating video data much more closely with
the source article.
o 映画。 全米天文学会は、学術誌を伴うために定期的にビデオを発行します。 電子出版は、はるかに密接にソース記事とビデオ・データを統合することによって発行しながら、この「ハードコピー」を改良できます。
o Sound. There is perhaps slightly less demand for audio
information in scientific publishing, but the requirement
does exist in particular specialities (such as acoustics and
zoology journals).
o 音。 科学的出版にはオーディオ情報の、より少ない要求が恐らくわずかにありますが、要件は特定の専門(音響学や動物学ジャーナルなどの)で存在しています。
Access to academic journals using at least four different paradigms is envisaged. Hierarchical access, perhaps using a traditional journal/volume/issue/article model, is perhaps the most obvious. Keyword searching (or full-text indexing) will be required. Browsing is another useful and often underestimated access model - to support browsing it is essential that "eye-catching" data (unlikely to be textual) is prominently accessible. The final method of access is perhaps the most important - the use of interactive viewing tools. Such tools would enable navigation of hypermedia links within and between articles, with gateways to special-purpose applications as described above. The use of these disparate access methods implies more than one structure being applied to the same underlying data.
少なくとも4つの異なったパラダイムを使用する学術誌へのアクセスは考えられます。 恐らく伝統的なジャーナル/ボリューム/問題/記事モデルを使用して、階層的なアクセスは恐らく最も明白です。 キーワードの探すこと(または、全文インデックス)が必要でしょう。 ブラウジングは別の役に立ってしばしば過小評価されたアクセスモデルです--ブラウジングをサポートするために、「人目を惹いた」データ(原文でありそうにない)が顕著にアクセス可能であることは、不可欠です。 アクセスの最終的なメソッドは恐らく最も重要です--ツールを見るインタラクティブの使用。 そのようなツールは上で説明される専用アプリケーションへのゲートウェイで記事と記事とのハイパーメディアリンクのナビゲーションを可能にするでしょう。 これらの異種のアクセス法の使用は同じ基本的なデータに適用される1つ以上の構造を含意します。
Standards, particularly SGML, are becoming important to publishers, and it is clear that the SGML-based HyTime standard will be a front runner in providing the kind of hypermedia facilities which are being envisaged. However, progress towards a common SGML Document Type Definition (DTD) for scientific articles, even within individual publishing houses and for text-only documents, is slow.
規格(特にSGML)は出版社に重要になっています、そして、SGMLベースのHyTime規格が考えられているハイパーメディア施設の種類を提供する際に優勢に立っている候補者になるのは、明確です。 しかしながら、科学的記事、個々の出版社、さらにおよびテキストのみドキュメントさえのための一般的なSGML Document Type Definition(DTD)に向かった進歩は遅いです。
Adie [Page 16] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[16ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
A specific initiative involving interested parties will be required to formalise detailed requirements and to pilot standards in this area. A preliminary demonstrator project, funded by publishers and by the British Library Research and Development Department, involves making about 30 sample scientific articles available over the SuperJANET network, using a range of different software products. The demonstrator project is being managed by IOP Publishing and is being carried out at Edinburgh University Computing Service.
利害関係者にかかわる特定のイニシアチブが、詳細な要件を正式にして、この領域で規格を操縦するのに必要でしょう。 出版社と英国図書館Researchと技術部によって資金を供給された予備のデモンストレータープロジェクトは、およそ30のサンプルをSuperJANETネットワークの上で利用可能な科学的記事にすることを伴います、さまざまな異なったソフトウェア・プロダクトを使用して。 デモンストレータープロジェクトが、IOP出版で経営されていて、エディンバラ大学コンピューターサービスで行われています。
Existing tools, particularly WAIS and WWW, are relevant, but adequate security and charging mechanisms are required if commercial publishers are to use them. Many research groups are now making the text of preprints and published research papers available on Gopher servers.
既存のツール(特にWAISとWWW)は、関連していますが、商業出版社がそれらを使用するつもりであるなら、十分な安全性と充電メカニズムが必要です。 多くの研究グループが今、前印刷と発行された研究論文の原本をゴーファーサーバで利用可能にしています。
It is interesting to note that the proceedings of the Multimedia 93 conference run by the ACM will be published electronically (on CD ROM), using a multimedia document format designed specifically for the event.
ACMによって経営されていたMultimedia93会議の議事が電子的(CD-ROMの上で)に発行されることに注意するのはおもしろいです、特にイベントのために設計されたマルチメディアドキュメント・フォーマットを使用して。
Computer-aided Learning
コンピュータ利用学習
The ready availability of user-friendly multimedia authoring tools such as AuthorWare Professional, Asymmetrix Multimedia Toolbook, Macromind Director and many more, has stimulated much interest in multimedia for computer-aided learning applications within the user community. Sophisticated interactive multimedia courseware applications are being developed in many disparate subjects throughout the European academic community. Users are now beginning to ask network technologists, "how can I make my multimedia application available to others across the network?".
AuthorWare Professional(Asymmetrix Multimedia Toolbook、Macromindディレクター、およびずっと多く)は刺激となっている多くにユーザーコミュニティの中でコンピュータ支援学習応用のためのマルチメディアに関心があらせるユーザフレンドリーなマルチメディアオーサリングツールの持ち合わせの有用性。 精巧なインタラクティブ・マルチメディアコースウェアアプリケーションはヨーロッパの学界中の多くの異種の対象で開発されています。 ユーザは、現在、「私はどうしたらマルチメディア応用をネットワークの向こう側に他のものにとって利用可能にすることができますか?」とネットワーク科学技術者に尋ね始めています。
There is considerable interest in using the network to enhance delivery of multimedia teaching materials - for instance to allow students to take courses remotely (distance learning) and for their learning process to be supported, monitored and assessed remotely.
マルチメディア教材の配送を機能アップするのにネットワークを使用することへの相当な興味があります--例えば、学生が取るのを許容するのが(通信教育)と彼らの離れてサポートしている、モニターされた、評価されるべき学習過程のために離れて勢いよく流れます。
The requirements which flow from this type of network application include the ability to identify and authenticate the students using the material, to monitor their progress, and to supply on-line assessment exercises for the student to complete. Multimedia authoring tools allow very attractive presentation environments to be created, which encourages learning; this is viewed as essential by course developers. Easy-to-use authoring tools (preferably existing commercial ones) are also essential.
このタイプのネットワーク応用から流れる要件は材料を使用することで学生を特定して、認証して、彼らの進歩をモニターして、学生が終了するオンライン査定運動を供給する能力を含んでいます。 どの督励が学んで、マルチメディアオーサリングツールは、非常に魅力的なプレゼンテーション環境が作成されるのを許容します。 これは同じくらい不可欠の状態でコース開発者によって見られます。 また、使用しやすいオーサリングツール(望ましくは既存の商業もの)も不可欠です。
Finally, some learning applications involve simulations - examples include meteorological modelling and economic simulations. Network
最終的に、いくつかの学習応用がシミュレーションにかかわります--例は気象学のモデル化と経済シミュレーションを含んでいます。 ネットワーク
Adie [Page 17] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[17ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
delivery of teaching materials should cope with this requirement (perhaps by acknowledging that executable scripts are just another media type).
教材の配送はこの要件(恐らく実行可能なスクリプトがただのメディアタイプであると認めるのによる)を切り抜けるべきです。
General Information Services
総合案内サービス
There are many other possible uses of multimedia data in networked information servers which don't conveniently fall into any of the above categories. Some examples are given below.
便利に上のカテゴリのいずれにもならないネットワークでつながれた情報サーバにおける、マルチメディアデータの他の多くの可能な用途があります。 いくつかの例が以下に出されます。
o On-line documentation. Manuals and instruction books often
rely heavily on pictorial information, and are enhanced by
dynamic media types (sound, video). The ability to access
centrally-held manuals across a network makes it much easier
to keep the information up-to-date.
o オンラインドキュメンテーション。 マニュアルと説明書は、大いに絵の情報をしばしば当てにして、ダイナミックなメディアタイプ(音、ビデオ)によって高められます。 ネットワークの向こう側に中心で保持されたマニュアルにアクセスする能力で、情報を最新に保つのははるかに簡単になります。
o Campus-wide information systems (CWIS) are an important
growth area. The opportunities for enhancing such a
service with multimedia data (e.g., maps) is obvious.
o キャンパス全体の情報システム(CWIS)は重要な成長地域です。 マルチメディアデータ(例えば、地図)でそのようなサービスを機能アップする機会は明白です。
o Multimedia news bulletins (e.g., the Internet Talk Radio,
which is sound only).
o マルチメディアニュース放送(例えば、インターネットTalk Radio専用)。(Talk Radioは健全です)。
o Product information (the multimedia equivalent of paper
advertising matter).
o 商品案内(紙の広告郵便物のマルチメディア同等物)。
o Consumer systems - e.g., tourist information servers. The
utility of such systems in an academic/research environment
is perhaps questionable, but it is likely that such systems
will address problems which will also be met in this
environment. We should be prepared to learn from such
projects.
o 消費者システム--例えば、旅行者情報サーバ。 アカデミックな/研究環境におけるそのようなシステムのユーティリティは恐らく疑わしいのですが、そのようなシステムがまた、この環境で満たされるその問題を訴えるのは、ありそうです。 私たちはそのようなプロジェクトから学ぶ用意ができているべきです。
2.2. Data Characteristics
2.2. データの特性
Some of the characteristics which make data more appropriate for network publication rather than publication on physical media are listed below.
物理的なメディアでデータを公表よりむしろネットワーク公表にはさらに適切にする特性のいくつかが以下に記載されています。
o The data may change frequently.
o データは頻繁に変化するかもしれません。
o Implementing corrections and improvements to the data is
very much easier.
o 修正とデータへの改良を実装するのはたいへん簡単です。
o It is more readily available to the data user - no
purchase/delivery cycle need exist.
o データユーザには、それは容易により利用可能です--購買/供給サイクルは全く存在する必要はありません。
Adie [Page 18] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[18ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
o Publication on physical media may not be cost-effective for
very large volumes of data. (Of course, there is a cost in
networking the data as well, but the research/academic user
is normally insulated from this.)
o データの非常に大きいボリュームにおいて、物理的なメディアに関する公表は費用対効果に優れていないかもしれません。 (もちろん、また、データをネットワークでつなぐのにおいて費用がありますが、通常、研究/アカデミックなユーザはこれから隔離されます。)
o Access for large user communities can be established without
requiring each user to purchase a potentially expensive
physical media peripheral (such as a laser disk player).
This is particularly helpful in classroom situations.
o 各ユーザが潜在的に高価な物理的なメディア周辺機器(レーザー・ディスクプレーヤーなどの)を購入する必要でない、大きいユーザーコミュニティへのアクセスを確立できます。 これは教室状況で特に役立っています。
o It may require less effort from the data publisher to make
data available over a network, rather than set up a manual
mechanism for distributing physical media.
o 物理的なメディアを配布するために手動のメカニズムをセットアップするよりむしろデータをネットワークの上で利用可能にするのがデータ出版社からさらに少ない取り組みを必要とするかもしれません。
o If related data from many different sources is to be
published, it may be more efficient to leave the data in
situ, and simply publish the network addresses of the data.
o 多くのさまざまな原因からの関連するデータが発行されることであるなら、元の位置にデータを残して、単にデータのネットワーク・アドレスを発表するのは、より効率的であるかもしれません。
There are counter-reasons which may make physical media distribution more appropriate:
物理的なメディア分配をより適切にするかもしれないカウンタ理由があります:
o Easier to charge for. (However, charging mechanisms do
exist in some network information systems. It may be that
potential information providers need to be made more aware
of this.)
o 課金するのは、より簡単です。 しかしながら、充電メカニズムはいくつかのネットワーク情報システムに存在しています。(多分、潜在的情報提供者は、これをより意識しているのに作られている必要があります。)
o Easier to deter or prevent copyright infringement, using
traditional copy-protection techniques.
o 伝統的なコピー保護のテクニックを使用する著作権侵害を思いとどまらせるか、または防ぐのが、より簡単です。
2.3. Requirements Definition
2.3. 要件定義
From studying the applications described in the preceding section, and from discussions with the people involved with the applications, it is possible to draw up a list of general requirements which a distributed multimedia information system for the academic and research community should satisfy. These requirements are informally described in the following subsections. The descriptions are necessarily informal and incomplete: every individual application will have its own detailed requirements, which would take a great deal of effort to determine (and indeed some of the requirements may not become apparent until the application is into its development phase).
アプリケーションが先行するセクションで説明した研究と、アプリケーションにかかわる人々との議論ので、アカデミック、そして、研究共同体の分散型マルチメディア情報システムが満たすはずである一般的な要件のリストを作成するのは可能です。 これらの要件は以下の小区分で非公式に説明されます。 記述は、必ず非公式であって、不完全です: あらゆる個々のアプリケーションには、それ自身の詳細な要件があるでしょう(本当に、開発段階には利用があるまで、要件のいくつかが明らかにならないかもしれません)。(要件は決定する多くの取り組みを取るでしょう)。
Platforms
プラットホーム
It is clear that the European academic community, in common with other such communities, requires support for three main platforms: UNIX, Apple Macintosh, and PC/Windows. For multimedia client/server
ヨーロッパの学界が他のそのような共同体と共用して3個の主なプラットホームに支持を要するのは、明確です: UNIX、アップルマッキントッシュ、およびPC/Windows。 マルチメディアクライアント/サーバのために
Adie [Page 19] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[19ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
systems, the latter two are less appropriate as server platforms, but client support for all three is vital. UNIX will be most often used as the server platform.
システムであり、後者の2はサーバプラットホームとしてそれほど適切ではありませんが、すべての3のクライアントサポートは重大です。 UNIXはサーバプラットホームとしてたいてい使用されるでしょう。
There are other systems, such as VAX/VMS, which are also important in some sectors.
VAX/VMSなどの他のシステムがあります。(また、VAX/VMSもいくつかのセクターで重要です)。
Media Types
メディアタイプ
Unsurprisingly, all applications require text data to be supported as a basic media type. Image and graphic media types are next in importance, followed by "application-specific" data (such as tabular scientific data, mathematical equations, chemical data types, etc). Sound and video media types are becoming more important as users discover how these can enhance applications.
当然ながら、すべてのアプリケーションが、テキストデータが基本的なメディアタイプとしてサポートされるのを必要とします。 イメージとグラフィックメディアタイプは「アプリケーション特有」のデータ(表科学的データ、数学の方程式、化学データ型などの)があとに続いた重要性で次です。 ユーザが、これらがどうしたらアプリケーションを機能アップできるかを発見するとき、音とビデオメディアタイプは、より重要になっています。
Many different encodings are possible for each media type (e.g., image data can be encoded as TIFF, PCX, GIF, PICT and many more). An information system should not constrain the type of encoding used, and should ideally offer either a range of alternative encodings, or conversion facilities between the stored encoding and an encoding suitable for display by the client workstation.
それぞれのメディアタイプに、多くの異なったencodingsが可能です(TIFF、PCX、GIF、PICT、およびずっと多くとして例えばイメージデータをコード化できます)。 情報システムは、使用されるコード化のタイプを抑制するべきでなくて、クライアントワークステーションで理想的にさまざまな代替のencodingsか変換施設のどちらかを保存されたコード化とディスプレイに適したコード化の間に提供するはずです。
Hyperlinks
ハイパーリンク
It is clear that many applications require their users to be able to navigate through the information base according to relationships determined by the information provider - in other words, hyperlinks. Academic publishing, CAL, on-line documentation and CWIS systems all require this capability. The user should be able, by some action such as clicking on a highlighted word in a text node or on a button, to cause another node or nodes to be retrieved and displayed.
言い換えれば、多くのアプリケーションが、情報提供者で決定している関係に従って彼らのユーザが情報ベースを通ってナビゲートできるのを必要とするのは、明確です、ハイパーリンク。 学術出版、CAL、オンラインドキュメンテーション、およびCWISシステムはすべて、この能力を必要とします。 ユーザはできるべきです、別のノードかノードが検索されて、表示されることを引き起こすためにテキストノードかボタンに関する強調された単語をクリックなどなどの何らかの動作で。
Some "hypermedia" systems are in fact simply hypertext, in that they require the source anchor of a hyperlink to be in a text node. A true hypermedia system allows hyperlinks to have their source anchors in nodes of any media type. This allows a user to click the mouse on a component of a diagram or on part of a video sequence to cause one or more related nodes to be retrieved and displayed.
事実上、いくつかの「ハイパーメディア」システムが単にハイパーテキストです、テキストノードにあるようにソースのアンカーにハイパーリンクを要求するので。 正しいハイパーメディアシステムで、どんなメディアのノードの彼らのソースのアンカーもハイパーリンクでタイプできます。 これで、ユーザが1つを引き起こすためにダイヤグラムの部品の上、または、ビデオ系列の一部の上をマウスをクリックできますか、または以上は、検索して、表示するためにノードについて話しました。
Some hypermedia systems allow target anchors of a hyperlinks to be finer-grained than a whole node - e.g., the target anchor could be a word or a paragraph within a text document. Without such a capability, it is necessary for target nodes to be quite small if precision is required in a hyperlink. This may be difficult to manage, and fine-grained target anchors are therefore better.
いくつかのハイパーメディアシステムが、全体のノードよりハイパーリンクの目標アンカーがさらにきめ細かに粒状であることを許容します--例えば、目標アンカーは、テキストドキュメントの中の単語かパラグラフであるかもしれません。 そのような能力がなければ、精度がハイパーリンクで必要であるなら、目標ノードがかなり小さいのが必要です。 これは管理するのが難しいかもしれません、そして、したがって、きめ細かに粒状の目標アンカーは、より良いです。
Adie [Page 20] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[20ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Additional structure above or orthogonal to the underlying hyperlinked data is required in some applications. This allows the same (generally non-textual) data to be used in several different applications, or the implementation of different access paradigms.
基本的なハイパーリンクしたデータと上の、または、直交した追加構造が使用目的によっては必要です。 これは、同じ(一般に非原文)のデータがいくつかの異なったアプリケーション、または異なったアクセスパラダイムの実装に使用されるのを許容します。
Presentation
プレゼンテーション
Related information of different media types must be capable of synchronised display. Commercial multimedia authoring packages provide many different ways of presenting, synchronising and interacting with media elements. Some of these are summarised below.
異なったメディアタイプの関連情報は連動したディスプレイができなければなりません。 商業マルチメディア書いているパッケージは提示と、連動とメディア要素と対話する多くの異なった方法を提供します。 これらの或るものについて以下に略言します。
o Backdrops. An application may present all its visual
information against a single background bitmap - e.g.,
a CAL application might use a background image of an open
textbook, with graphics, text and video data all presented
on the open pages of the book.
o 背景。 アプリケーションは単一のバックグラウンドビットマップに対してすべての視覚情報を提示するかもしれません--例えば、CALアプリケーションは開いている教科書に関する背景画像を使用するかもしれません、本の開いているページにすべて提示されたグラフィックス、テキスト、およびビデオ・データで。
o Buttons. A "button" can be defined as an explicitly-
delimited area of the display, within which a mouse click
will cause an action to occur. Typically, the action will
be (or can be modelled as) a hyperlink traversal.
Applications use different styles of button - some may use
"tabs" as in a notebook, or perhaps "bookmarks" in
conjunction with the open textbook backdrop mentioned above.
Others may use plain buttons in a style conforming to the
conventions of the host platform, or may simply highlight a
word or phrase in a text display to indicate it is "active".
o ボタン。 ディスプレイの明らかに区切られた領域と「ボタン」を定義できます。(マウスクリックで、そこでは、動作が起こるでしょう)。 動作は通常、(または、モデル化できます)ハイパーリンク縦断になるでしょう。 アプリケーションは異なったスタイルのボタンを使用します--何かは前記のように使用がノートのように「タブで移動する」か、または恐らく開いている教科書に関連して「ブックマークを追加する」という背景がそうするかもしれません。 他のものは、ホストプラットホームのコンベンションに従うスタイルに明瞭なボタンを使用するか、またはそれが「アクティブであること」を示すためにテキストディスプレイで単に言葉か句を強調するかもしれません。
o Synchronisation in space. When two or more nodes are
presented together (e.g., because a link with more than one
target anchor has been traversed), the author of the
hyperdocument may wish to specify that they be presented in
a spatially-related way. This may involve: x/y
synchronisation - e.g., a video node being displayed
immediately above its text caption; it may involve
contextual synchronisation - e.g., an image being displayed in
a specific location within a text node; or it may involve z-
axis synchronisation as well - for instance a text node
containing a simple title being displayed on top of an
image, with the text background being transparent so that
the image shows through.
o スペースでの連動。 2つ以上のノードが一緒に提示されるとき(例えば、1人以上の目標アンカーとのリンクが横断されたので)、「超-ドキュメント」の作者は、それらが空間的に関連の方法で提示されると指定したがっているかもしれません。 これは以下にかかわるかもしれません。 x/y連動--例えばテキスト見出しのすぐ上に表示されるビデオノード。 それは文脈上の連動にかかわるかもしれません--例えばテキストノードの中に特定の位置に表示されるイメージ または、また、z軸の連動にかかわるかもしれません--例えば、テキストバックグラウンドがイメージが透けて見えるくらい透明な状態でイメージの上に表示される簡単なタイトルを含むテキストノード。
o Synchronisation in time. Isochronous data may require
synchronisation - the obvious case being audio and video
tracks (where these are held separately). Other examples
are: the synchronisation of an automatically-scrolling text
panel to a video clip (for subtitling); or to an audio clip
o 時間内にの連動。 同一時間のデータは連動を必要とするかもしれません--オーディオとビデオ道(これらが別々に保持されるところ)である明白なケース。 他の例は以下の通りです。 ビデオクリップ(字幕をつける)への自動的にスクロールしているテキストパネルの連動。 または、オーディオに、切り取ってください。
Adie [Page 21] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[21ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
(e.g., a translation); or synchronising an animation to an
explanatory audio track.
(例えば、翻訳)。 または、連動して、説明しているオーディオへのアニメーションは追跡されます。
Searching
探すこと
Database-type applications require varying degrees of sophistication in retrieval techniques. For applications addressed in this report, non-text nodes form the major data of interest. Such nodes have associated descriptions, which may be plain text, or may be structured into fields. Users need to be able to search the descriptions, obtain a list of "hits", and select nodes from that list to display. Searching requirements vary from simple keyword searching, via full-text indexing (with or without Boolean combinations of search words), to full SQL-style database retrieval languages.
データベースタイプアプリケーションは、度合いを変えるのを検索のテクニックによる洗練を要求します。 このレポートで扱われたアプリケーションのために、非テキストノードは興味がある主要なデータを形成します。 ノードが持っているそのようなものは、記述を関連づけるか、または分野に構造化されるかもしれません。(記述はプレーンテキストであるかもしれません)。 記述を捜して、「ヒット」のリストを得て、それからのノードを選択できるユーザの必要性は、表示するために記載します。 探す要件は簡単なキーワードの探すのと異なります、全文インデックス(探索語のブール組み合わせのあるなしにかかわらず)を通して、完全なSQLスタイルデータベース利用言語に。
Interaction
相互作用
The user must be able to annotate documents retrieved from the information server. The annotations may be stored locally. Similarly, the user may wish to add his own (locally-held) hyperlinks to documents. (Actual modification of documents in the information system itself, or shared annotations to documents - i.e., the information system as a CSCW environment - is viewed as separate issue which this report does not address.)
ユーザは情報サーバから検索されたドキュメントを注釈できなければなりません。注釈は局所的に保存されるかもしれません。 同様に、ユーザは、彼自身の(局所的に、保持する)がドキュメントにハイパーリンクすると言い足したがっているかもしれません。 (情報システム自体における、ドキュメントの実際の変更、またはドキュメントへの共有された注釈(すなわち、CSCW環境としての情報システム)がこのレポートが扱わない別個問題として見なされます。)
If an information provider has included contact details (such as a mail address) in a document, it should be possible for the reader to invoke a program (such as a mailer) which initiates communication with the author.
情報提供者がドキュメントで詳細な連絡先(郵便の宛先などの)を入れたなら、読者が作者とのコミュニケーションを開始するプログラム(郵送者などの)を呼び出すのは、可能であるべきです。
In some applications, it may make sense for a user to be able to specify a region of interest in an image or movie clip, and to request a more detailed view of (or other information about) that region.
使用目的によっては、イメージか映画のクリップで興味がある領域を指定して、より詳細な視点を要求できるのがユーザのために理解できるかもしれない、(他の情報、)、その領域。
Some applications require a sequence of images to be presented under control of the user. For instance, a three-dimensional microscopic structure could be represented as a sequence of images taken with the microscope focused on a different plane for each image. For display, the user could control which image was displayed using some kind of slider control, giving the illusion of focusing a microscope. (This particular example has been taken from the Theseus project at John Moore's University, Liverpool, GB.)
いくつかのアプリケーションが、イメージの系列がユーザのコントロールの下で提示されるのを必要とします。 例えば、顕微鏡で取られたイメージの系列が各イメージのために異なった飛行機に焦点を合わせたとき、立体的な微視的構造を表すことができました。 ディスプレイのために、ユーザは、どのイメージがある種のスライダーコントロールを使用することで表示されたかを制御できました、顕微鏡の焦点を合わせる幻想を与えて。 (ジョン・ムーアの大学、リバプール、GBでテーセウスプロジェクトからこの特定の例を取りました。)
Adie [Page 22] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[22ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Quality of Service
サービスの質
Research has shown [3] that user toleration of delay in computer systems depends on user perception of the nature of the requested action. If the user believes that no computation is required, tolerable delays are of the order of 0.2s. If the user believes the action he or she has requested the computer to perform is "difficult" - for instance a computation of some form - then a tolerable delay is of the order of 2s. Users tend to give up waiting for a response after about 20s. Networked multimedia information systems must be able to provide this level of responsiveness.
研究は、[3] コンピュータ・システムの遅れのユーザ信教の自由が要求された動作の本質のユーザ認知によるのを示しました。 ユーザが、計算は全く必要でないと信じているなら、許容できる遅れが0.2の注文のものです。 ユーザが、その人が、コンピュータが実行するよう要求した動作が「難しい」と(例えば、何らかの形式の計算)信じているなら、許容できる遅れは2の注文のものです。 ユーザは、20年代頃の後に応答を待つのをやめる傾向があります。 ネットワークでつながれたマルチメディア情報システムはこのレベルの反応性を提供できなければなりません。
Management
管理
In order to support applications involving real-money information services (e.g., academic publishing) and learning/assessment applications, there must be a reliable and secure access control mechanism. A simple password is unlikely to suffice - Kerberos authentication procedures are a possibility.
現金情報サービス(例えば、学術出版)にかかわるアプリケーションと学習/査定がアプリケーションであるとサポートするために、信頼できて安全なアクセス管理機構があるに違いありません。 簡単なパスワードは十分でありそうにはありません--ケルベロス認証手順は可能性です。
Users must be able to determine the charge for an item before retrieving it (assuming that pay-per-item will be a common paradigm alternatives such as pay-per-call, pay-per-duration are also possible). Access records must be kept by the information server for charging purposes.
それを検索する前に、ユーザは項目のための充電を決定できなければなりません(また、1項目あたりの賃金が1呼び出しあたりの賃金などの一般的なパラダイム代替手段になると仮定する1持続時間あたりの賃金も可能です)。 充電目的のために情報サーバでアクセス記録を保たなければなりません。
Learning applications have similar requirements, except that the purpose here is not to charge for information retrieved, but to monitor and perhaps assess a student's progress.
学習応用には、同様の要件があります、検索された情報に課金するのではなく、学生の進歩をモニターして、恐らく評価するのを除いてここの目的がことである。
Scripting
スクリプティング
Many authoring packages provide scripting languages. In most cases, these languages are used to manage the presentation environment and control navigation within the hypermedia document. There are other, declarative rather than procedural, methods for achieving this, so scripting of this type is not necessarily a requirement. However, some application areas require executable scripts for other purposes (e.g., simulations in CAL applications). Care in providing such a facility is required, because of the potential for abuse (the possibility of "trojan" scripts). However, there is work going on to produce "safe" scripting languages - an example is "safe tcl", being developed by Borenstein and Ousterhout (contact ouster@cs.berkeley.edu).
多くの書いているパッケージがスクリプト言語を提供します。 多くの場合、これらの言語は、ハイパーメディアドキュメントの中でプレゼンテーション環境とコントロールナビゲーションを管理するのに使用されます。 これを達成するための他の、そして、手続き上であるというよりむしろ宣言的なメソッドがあるので、このタイプのスクリプティングは必ず要件であるというわけではありません。 しかしながら、いくつかの応用分野が他の目的(例えば、CALアプリケーションにおけるシミュレーション)のために実行可能なスクリプトを必要とします。 そのような施設を提供することにおける注意が乱用("trojan"スクリプトの可能性)の可能性のために必要です。 しかしながら、「安全な」スクリプト言語を生産し続ける仕事があります--例は「安全なtcl」です、BorensteinとOusterhoutによって開発されて、ことです( ouster@cs.berkeley.edu に連絡してください)。
Adie [Page 23] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[23ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Bytestream Format
Bytestream形式
For the easy transfer and handling of a hyperdocument, it must be capable of being encoded into a bytestream form, in such a way that the structure of the document is preserved and it can be decoded without loss of information.
「超-ドキュメント」の簡単な転送と取り扱いにおいて、bytestreamフォームにコード化できなければなりません、ドキュメントの構造を保存して、情報の損失なしでそれを解読できるような方法で。
This facility makes it possible for such documents to be supplied to a user over electronic mail, in such a way that he or she can browse them at his or her own site. This may be appropriate where the user does not have a direct connection to the Internet. It will also be useful for printing the hyperdocument.
この施設でそのようなドキュメントをユーザに提供するのは電子メールの上で可能になります、その人が自己のサイトでそれらをブラウズできるような方法で。 これはインターネットにはユーザがダイレクト接続がいないところで適切であるかもしれません。 また、それも「超-ドキュメント」を印刷することの役に立ちます。
Authoring
オーサリング
It is essential that a multimedia information system should have adequate authoring tools which make it easy to prepare and publish hypermedia information. Such tools need similar power to existing commercial multimedia authoring software for stand-alone multimedia applications.
マルチメディア情報システムにはハイパーメディアインフォメーションを準備して、発表するのを簡単にする適切なオーサリングツールがあるはずであるのは、不可欠です。 そのようなツールは既存の商業マルチメディアオーサリングソフトへの同様のパワーをスタンドアロンのマルチメディア応用に必要とします。
3. Existing Systems
3. 既存のシステム
This chapter describes some existing distributed information systems in sufficient detail to reveal how they handle multimedia data, and analyses how well they meet the requirements outlined in the preceding chapter.
本章はそれらがどうマルチメディアデータを扱うかを明らかにすることができるくらいの詳細、および彼らが先の章に概説された必要条件をよく、満たす分析でいくつかの既存の分配された情報システムについて説明します。
3.1. Gopher
3.1. ゴーファー
The Internet Gopher is a distributed document delivery service. It allows a neophyte user to access various types of data residing on multiple hosts in a seamless fashion. This is accomplished by presenting the user with a hierarchical arrangement of nodes and by using a client-server communications model. The Gopher server accepts simple queries, and responds by sending the client a node (usually called a document in this context).
インターネットゴーファーは分配されたドキュメントデリバリ・サービスです。 それで、新改宗者ユーザは複数のホストの上にシームレスのファッションである様々なタイプに関するデータにアクセスできます。 これは、ノードの階層的配列をユーザに与えて、クライアント/サーバコミュニケーションモデルを使用することによって、達成されます。 ゴーファーサーバは、簡単な質問を受け入れて、ノード(通常、このような関係においてはドキュメントと呼ばれる)をクライアントに送ることによって、反応します。
Client software is available for a large number of systems, including:
クライアントソフトウェアは多くのシステム、包含に利用可能です:
o UNIX (character terminals)
o UNIX(文字端末)
o X windows
o X-windows
o Apple Macintosh
o アップルマッキントッシュ
o MS DOS
o MS-DOS
Adie [Page 24] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[24ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
o NeXT
o 次へ
o VM/CMS
o VM/cm
o VMS
o VMS
o OS/2
o OS/2
o MVS/XA
o MVS/XA
Servers are available for systems such as:
サーバは以下などのシステムに利用可能です。
o UNIX
o UNIX
o VMS
o VMS
o Apple Macintosh
o アップルマッキントッシュ
o VM/CMS
o VM/cm
o MVS
o MVS
o MS DOS
o MS-DOS
Gopher was developed at the University of Minnesota.
ゴーファーはミネソタ大学で開発されました。
Gopher User Image
ゴーファーユーザイメージ
A Gopher client offers an interface into "gopherspace", which appears to the user as a hierarchy of menus and document nodes, similar in some ways to a file system hierarchy of directories and files. Selecting an entry from a menu node causes a further menu to appear, or causes a document to be retrieved and displayed.
ゴーファークライアントはメニューとドキュメントノードの階層構造としてユーザにとって現れる"gopherspace"にインタフェースを提供します、ある点ではディレクトリとファイルのファイルシステム階層構造と同様です。 メニューノードからエントリーを選択するのは、さらなるメニューが現れることを引き起こすか、またはドキュメントが検索されて、表示されることを引き起こします。
As well as "ordinary" document nodes, Gopher has "search nodes" when one of these is selected from a menu, the user is prompted for one or more words to search on. The result of the search is a "virtual" menu, containing entries for document nodes (within some subset of gopherspace) which match the search. A special type of Gopher search server called "veronica" provides access to a database of all directory nodes in gopherspace. This allows a user to construct a virtual menu of all Gopher menu items containing a particular word. WAIS databases may also be located at Gopher search nodes, since some Gopher servers understand the format of WAIS index files.
これらの1つがメニューから選択されるとき、ゴーファーには、「普通」のドキュメントノードと同様に、「検索ノード」があって、ユーザは探す1つ以上の単語のためにうながされます。 調査結果は「仮想」のメニューです、検索に合っているドキュメントノード(gopherspaceの何らかの部分集合の中の)のためのエントリーを含んでいて。 「クワガタソウ属の植物」と呼ばれる特別なタイプのゴーファー検索サーバはgopherspaceのすべてのディレクトリノードに関するデータベースへのアクセスを提供します。 これで、ユーザは特定の単語を含むすべてのゴーファーメニュー項目の仮想のメニューを構成できます。 また、WAISデータベースはゴーファー検索ノードに位置するかもしれません、いくつかのゴーファーサーバがWAIS索引ファイルの形式を理解しているので。
Adie [Page 25] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[25ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Gopher Protocol
ゴーファープロトコル
Gopher uses a client-server paradigm. The Gopher protocol runs over a reliable data stream service, typically TCP, and is fully defined in RFC 1436. The following paragraphs give an overview which is sufficient for understanding how multimedia data is handled in Gopher.
ゴーファーはクライアント/サーバパラダイムを使用します。 ゴーファープロトコルは、信頼できるデータ・ストリームサービス、通常TCPをひいて、RFC1436で完全に定義されます。 以下のパラグラフはマルチメディアデータがゴーファーでどのように扱われるかを理解するのに十分な概要を与えます。
A Gopher client opens a TCP connection to a Gopher server (defined by machine name and TCP port number), and sends a line of text known as the "selector" to request information from the server. The server responds with a block of data, and then closes the connection. No state is retained by the server. A null (empty) selector tells the Gopher server to return its "root" menu node, containing pointers to other information in gopherspace.
ゴーファークライアントは、ゴーファーサーバ(マシン名とTCPポートナンバーで、定義される)にTCP接続を開いて、サーバから情報を要求するために「セレクタ」として知られているテキスト行を送ります。サーバは、1ブロックのデータで応じて、次に、接続を終えます。 状態は全くサーバによって保有されません。ヌル(空の)のセレクタは、「根」メニューノードを返すようにゴーファーサーバに言います、gopherspaceの他の情報に指針を含んでいて。
A menu is returned from a Gopher server as a sequence of lines of text, each corresponding to one entry in the menu. Each line (which is sometimes called a "Gopher reference") contains the following data, which can be used by the client software to retrieve and display the corresponding node in gopherspace.
テキストの系列の系列としてゴーファーサーバからメニューを返します、それぞれメニューにおける1つのエントリーに対応しています。 各系列(時々「ゴーファー参照」と呼ばれる)は以下のデータを含んでいます。gopherspaceの対応するノードを(データはクライアントソフトウェアによって使用されて、)検索して、表示できます。
o A single character which identifies the type of the node.
Possible values of this type ID are given below.
o ノードのタイプを特定する単独のキャラクタ。 このタイプIDの可能な値を以下に与えます。
o A human-readable string which is used by the client software
when it displays the menu entry to the user.
o ユーザにメニュー項目を表示するときクライアントソフトウェアによって使用される人間読み込み可能なストリング。
o The selector which should be used by client software to
retrieve the node. It is treated as opaque by the client
software.
o クライアントソフトウェアによって使用される、ノードを検索するべきであるセレクタ。 それはクライアントソフトウェアによって不透明なものとして扱われます。
o The domain name of the host on which the node is held.
o ノードが保持されるホストのドメイン名。
o The port number to use for the TCP connection.
o TCP接続に使用するポートナンバー。
A document node is sent by a Gopher server simply as lines of text terminated by a dot on a line by itself, or as raw binary data, with the end of the data indicated by the server closing the TCP connection. The choice depends on the type of node.
単にテキストの系列がそれ自体か、生のバイナリ・データとして系列でドットで終わったようにゴーファーサーバでドキュメントノードを送ります、データの終わりがTCP接続を終えるサーバによって示されている状態で。 この選択はノードのタイプ次第です。
The currently-defined type IDs are as follows:
現在定義されたタイプIDは以下の通りです:
0 Node is a file.
0ノードはファイルです。
1 Node is a directory.
1つのノードがディレクトリです。
2 Node is a CSO phone book server.
2ノードはCSO電話帳サーバです。
Adie [Page 26] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[26ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
3 Error.
3 誤り。
4 Node is a BinHexed Macintosh file.
4ノードはBinHexedマッキントッシュファイルです。
5 Node is DOS binary archive of some sort.
5ノードはある種のDOSの2進のアーカイブです。
6 Node is a UNIX uuencoded file.
6ノードはUNIXがファイルをuuencodedしたということです。
7 Node is a search server.
7ノードは検索サーバです。
8 Node points to a text-based telnet session.
8ノードはテキストベースのtelnetセッションまで指します。
9 Node is a binary file.
9ノードはバイナリーファイルです。
T Node points to a TN3270 connection.
TノードはTN3270接続を示します。
Some experimental IDs are also in use:
また、いくつかの実験IDも使用中です:
s Node contains -law sound data.
sノードは法の音のデータを含みます。
g Node contains GIF data.
gノードはGIFデータを含みます。
M Node contains MIME data.
MノードはMIMEデータを含みます。
h Node contains HTML data.
hノードはHTMLデータを含みます。
I Node contains image data of some kind.
I Nodeはある種のイメージデータを含んでいます。
i In-line text type.
i In-系列テキストタイプ。
The process for defining new data types and corresponding IDs is not clear.
新しいデータ型と対応するIDを定義するためのプロセスは明確ではありません。
Gopher+ Protocol
ゴーファー+プロトコル
The Gopher+ protocol is an extension of the Gopher protocol. Gopher+ is defined informally in [4]. It is designed to be downwards compatible with the original protocol, so that old Gopher clients may access Gopher+ servers (without being able to take advantage of the new facilities), and Gopher+ clients may access old Gopher servers. Gopher+ is still at the experimental stage, and is liable to change.
ゴーファー+プロトコルはゴーファープロトコルの拡大です。 ゴーファー+は[4]で非公式に定義されます。 設計されていて、ゴーファークライアントがそのように、下向きに、その老人というオリジナルのプロトコルと互換性があるので、ことになるように、ゴーファー+サーバ(新しい設備を利用できることのない)にアクセスするかもしれなくて、ゴーファー+クライアントが古いゴーファーサーバにアクセスするかもしれないということです。 ゴーファー+は、まだ試作段階であって、変化しやすいです。
The most important new feature is the introduction of "attributes" associated with individual nodes. The client may retrieve the attributes of a node instead of the node contents. Attributes defined so far include:
最も重要な新機能は個々のノードに関連している「属性」の導入です。 クライアントはノードコンテンツの代わりにノードの属性を検索するかもしれません。 今までのところ定義されている属性は:
Adie [Page 27] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[27ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
INFO Contains the Gopher reference of the node.
Mandatory.
ゴーファーが参照をつけるノードのINFO Contains。 義務的。
ADMIN Contains administrative information, including
the mail address of the server administrator and
the last-modified date of the node. Mandatory.
サーバアドミニストレータの郵便の宛先とノードの最後変更された期日を含むADMIN Contains管理情報。 義務的。
VIEWS Contains a list of one or more "view
descriptors", each of which describes an
alternate view of the node. For instance, an
image node may contain a TIFF view, a GIF view,
a JPEG view, etc. The client software (or the
user) may choose which view to retrieve. The
size of the view is also (optionally) available
in this attribute. The Gopher+ Attribute
Registry (see below) defines the permitted view
types.
1「視点記述子」のVIEWS Contains aリスト。それはそれぞれノードの代替の視点について説明します。 例えば、イメージノードはTIFF視点、GIF視点、JPEG視点などを含むかもしれません。 クライアントソフトウェア(または、ユーザ)は、どの視点を検索したらよいかを選ぶかもしれません。 また、視点のサイズも(任意に)この属性で有効です。 ゴーファー+属性Registry(以下を見る)は受入れられた視点タイプを定義します。
ABSTRACT This attribute contains a short description of
the item. It may also include a Gopher
reference to a longer abstract, held in a
separate Gopher node.
抽象的なThis属性は項目の短い記述を含んでいます。 また、それは別々のゴーファーノードに保持されたより長い要約のゴーファー指示するものを含むかもしれません。
ASK This attribute is used for the interactive query
extension. The interactive query facility in
Gopher+ is used to obtain information from a
user before retrieving the contents of a node.
The client fetches the ASK attribute, which
contains a list of questions for the user. His
or her responses to those questions are sent
along with the selector to the server, which
then returns the contents of the node. This
facility could be used as a very simple way of
querying a database, for instance. Using the
interactive query facility to supply a password
for access control purposes is not a good idea -
there are too many opportunities for
masquerading.
ASK This属性は対話的な質問拡大に使用されます。 ゴーファー+の対話的な質問能力は、ノードのコンテンツを検索する前にユーザから情報を得るのに使用されます。 クライアントはASK属性をとって来ます。(それは、ユーザのための質問のリストを含みます)。 セレクタと共にノードのコンテンツがその時戻るサーバにそれらの質問へのその人の応答を送ります。 例えばデータベースについて質問する非常に簡単な方法としてこの施設を使用できました。 アクセス管理目的のためのパスワードを提供するのに対話的な質問施設を使用するのは、名案ではありません--仮装するあまりに多くの機会があります。
The University of Minnesota maintains a registry of Gopher+ attribute types. For the VIEWS attribute, the registry contains a list of permitted view types. Note that these view types have a similar function to the type identifier described in the preceding section.
ミネソタ大学はゴーファー+属性タイプの登録を維持します。 VIEWS属性のために、登録は受入れられた視点タイプのリストを含んでいます。 これらの視点タイプが先行するセクションで説明されたタイプ識別子に同様の機能を持っていることに注意してください。
The general format of a Gopher+ view descriptor is:
ゴーファー+視点記述子の一般形式は以下の通りです。
xxx/yyy zzz: <nnnK>
xxx/yyyグーグーグー: <nnnK>。
Adie [Page 28] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[28ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
where xxx is a general type-of-information advisory, yyy is what information format you need understand to interpret this information, zzz is a language advisory (coded using POSIX definitions), and nnn is the approximate size in bytes. Possible values for xxx include text, file, image, audio, video, terminal.
xxxが一般的なタイプの情報状況報告であるところでは、yyyはあなたが必要とするすべての情報形式がこの情報を解釈するのを分かるということです、そして、グーグーグーは言語状況報告(POSIX定義を使用することで、コード化される)です、そして、nnnはバイトで表現される大体のサイズです。 xxxに、可能な値はテキスト、ファイル、イメージ、オーディオ、ビデオ、端末を含んでいます。
(It now appears that the University of Minnesota Gopher Team accepts the need to be consistent in the use of type/encoding attributes with the MIME specification. The Gopher+ Type Registry may thus eventually disappear, together with the set of xxx/yyy values it currently contains.)
(今、ミネソタ大学ゴーファーTeamが、必要性がMIME仕様があるタイプ/コード化属性の使用で一貫していると受け入れるように見えます。 その結果、ゴーファー+タイプRegistryは結局、それが現在含むxxx/yyy値のセットと共に見えなくなるかもしれません。)
No view descriptors for directory nodes are currently registered.
ディレクトリノードのための記述子が現在登録されるのは、視点ではありません。
In order to make use of the information available in attributes, it is necessary to fetch the attributes before fetching the contents of a node. Gopher+ provides a way of fetching the attributes for each entry in a menu at the same time as the menu is retrieved. This saves having to establish two successive TCP connections to fetch a single document, at the expense of some additional client software complexity.
属性で利用可能な情報を利用するために、ノードのコンテンツをとって来る前に属性をとって来るのが必要です。 +がメニューと同時にメニューにおける各エントリーに属性をとって来る方法を提供するゴーファーは検索されます。 これはただ一つのドキュメントをとって来るために2つの連続したTCP接続を証明するために有を貯蓄します、何らかの追加クライアントソフトウェアの複雑さを犠牲にして。
Gopher Publishing
ゴーファー出版
The procedure for making data available using the Unix Gopher server "gopherd" is very straightforward. The hierarchical nature of the Unix file system closely matches the Gopher concept of menus and documents. The gopherd program exploits this - Unix directories are represented as Gopher menu nodes, and Unix files as Gopher document nodes. The names of directories and files are the entries in Gopher menus. This can lead to awkward file names containing spaces, so gopherd provides an aliasing mechanism (the \.cap directory) to get round this.
Unixゴーファーサーバ"gopherd"を使用することでデータを利用可能にするための手順は非常に簡単です。 Unixファイルシステムの階層的な本質は密接にメニューとドキュメントのゴーファー概念に合っています。 gopherdプログラムはこれを利用します--unixディレクトリはゴーファーメニューノード、およびゴーファードキュメントノードとしてのUnixファイルとして表されます。 ディレクトリとファイルの名前はゴーファーメニューでエントリーです。 これが空間を含む厄介なファイル名に通じることができるので、gopherdはこれを動かせるために、エイリアシングメカニズム(\.capディレクトリ)を提供します。
To represent menu entries pointing to Gopher nodes on other servers, special "link" files (starting with a dot) are used.
他のサーバのゴーファーノードを示すメニュー項目を表すために、特別な「リンク」ファイル(ドットから始まる)は使用されています。
The type ID for a document node is determined from the extension of its Unix filename. If a client requests a file containing a shell script, the script is executed and the output returned to the client.
ドキュメントノードのためのタイプIDはUnixファイル名の拡大によって断固としています。 クライアントがシェルスクリプトを含むファイルを要求するなら、スクリプトは作成されました、そして、出力はクライアントに戻りました。
The Gopher+ version of gopherd is similar, but the .cap directory is replaced by a configuration file gopherd.conf. This file is used to specify administration attributes, and the mapping between filename extensions and view descriptors. Some limited access control (based on the client's IP address/domain name) is also provided by the Gopher+ version of gopherd.
gopherdのゴーファー+バージョンは同様ですが、.capディレクトリを構成ファイルgopherd.confに取り替えます。 このファイルは、ファイル名拡大と視点記述子の間で管理属性、およびマッピングを指定するのに使用されます。 また、gopherdのゴーファー+バージョンは何らかの限られたアクセス制御(クライアントのIPアドレス/ドメイン名に基づいている)を提供します。
Adie [Page 29] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[29ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Published Non-text Data
発行された非テキストデータ
There is already some useful non-text data published on Gopher almost exclusively image data. See for example the Vatican Library Exhibition at the University of Virginia Library, the ArchiGopher at the University of Michigan, the weather machine at the University of Illinois. Some of these are described in the User Requirements chapter of this report.
既に、データがゴーファーで専ら発行した何らかの役に立つ非テキストイメージデータがあります。 バージニア大学図書館で例えば、バチカン市国図書館Exhibitionを見てください、ミシガン大学のArchiGopher、イリノイ大学の気象マシン。 これらの或るものはこのレポートのUser Requirements章で説明されます。
There seem to be rather fewer sound archives in gopherspace, but interested users may access the Edinburgh University Computing Service Gopher server on gopher.ed.ac.uk, where the Testing Area contains 20 or 30 short audio files in Sun audio format. Note - the availability of this archive is not guaranteed.
かなり少ない録音資料室がgopherspaceであるように思えますが、関心があるユーザはgopher.ed.ac.ukでエディンバラ大学コンピューターサービスゴーファーサーバにアクセスするかもしれません。そこでは、Testing AreaがSunオーディオ形式に20か30少ないオーディオファイルを含みます。 注意--このアーカイブの有用性は保証されません。
Advantages
利点
The main factor in favour of Gopher is its widespread penetration. There are over 1000 Gopher servers world-wide. This popularity is due in part to the ease of setting up a Gopher server and making information available on it, particularly on a Unix platform.
ゴーファーを支持して主な要因は広範囲の侵入です。 1000以上のゴーファーサーバが世界中にあります。 この人気はゴーファーサーバをセットアップして、情報をそれで利用可能にする容易さの一部ためです、特にUnixプラットホームで。
Limitations
制限
It is unfortunate that the relatively well-defined MIME types were not adopted in Gopher+. As mentioned above, this may yet happen, although there appear to be reasons for keeping the set of MIME types small whereas Gopher requires a wide range of types to offer to clients. The latest word is that the MIME registry will be expanded to include the types which the Gopher+ developers want.
比較的明確なMIMEの種類が+ . 前記のようにゴーファーAsに採用されなかったのが、不幸である、MIMEの種類のセットを小さく維持する理由はあるように見えますが、ゴーファーはクライアントに提供するタイプの広範囲を必要としますが、これはやがて、起こるかもしれません。 最新の単語はMIME登録がゴーファー+開発者が欲しいタイプを含むように広げられるということです。
Gopher is inflexibly hierarchical in nature. Hypertext or hypermedia it is not - links to other nodes from within document nodes are not possible. There is a suggestion in the Gopher+ specification that alternate views of directory nodes could be used to provide some kind of hypermedia capability, but this does not yet exist, and it is unlikely that it could be made to work as easily as the WWW hypertext model.
ゴーファーは現実に不変に階層的です。 それは、ハイパーテキストかハイパーメディアではありません--ドキュメントノードからの他のノードへのリンクは可能ではありません。 これはまだ存在していません、そして、ある種のハイパーメディア能力を提供するのにディレクトリノードの代替の視点を使用できたというゴーファー+仕様に基づく提案がありますが、WWWハイパーテキストモデルと同じくらい容易に働かされることができたのはありそうもないです。
There is no access control at the user level - anyone can retrieve anything on a Gopher server. There is no provision for charging for information.
アクセス制御が全くユーザレベルにありません--だれでもゴーファーサーバで何でも検索できます。情報に課金することへの支給が全くありません。
3.2. Wide Area Information Server
3.2. 広い領域情報サーバ
The Wide Area Information Server (WAIS) system allows users to search for and retrieve information from databases anywhere on the Internet. WAIS uses a client-server paradigm, and client and server software is
Wide Area情報Server(WAIS)システムで、ユーザは、インターネットでどこでもデータベースからの情報を検索して、検索します。 WAISはクライアント/サーバパラダイム、およびクライアントを使用します、そして、サーバソフトウェアは使用します。
Adie [Page 30] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[30ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
available for a wide range of platforms. Client applications are able to retrieve text or other media documents stored on the servers, by specifying keywords. The server software searches a full-text index of the documents, and returns a list of documents containing the keywords (ranked according to a heuristic algorithm). The client may then request the server to send a copy of any of the documents found. Relevant documents can be fed back to a server to refine the search. Successful searches can be automatically re-run, to alert the user when new information becomes available.
プラットホーム広範囲のクライアントアプリケーションがドキュメントがサーバに保存したテキストか他のメディアを検索できるキーワードを指定することによって、利用可能です。 サーバソフトウェアは、ドキュメントの全文インデックスを捜して、キーワードを含むドキュメントのリストを返します(発見しているアルゴリズムによると、格付けされます)。 そして、クライアントは、見つけられたドキュメントのどれかのコピーを送るようサーバに要求するかもしれません。 関連ドキュメントは、検索を洗練するためにサーバを提供であって戻しできます。 自動的に成功した捜索を再放送できて、新情報であるときに、ユーザを警告するのは利用可能になります。
WAIS was developed by Thinking Machines Corporation of Cambridge, Massachusetts, in collaboration with Apple Computer Inc., Dow Jones and company, and KPMG Peat Marwick. The WAIS software has been made freely available; however Thinking Machines has announced that they will stop support for their publicly-distributed WAIS as of version 8b5.1. Future support and development of the publicly-distributed WAIS has been taken over by CNIDR (Clearinghouse for Networked Information Discovery and Retrieval) in the USA. Future CNIDR releases will be called FreeWAIS. A new company, WAIS Inc, has been formed by Thinking Machines to take over commercial exploitation of the Thinking Machines WAIS software.
WAISはケンブリッジ(マサチューセッツ)のシンキング・マシンズ社によって開発されました、アップルコンピーター社、ダウ・ジョーンズ、および会社との共同、およびKPMGピートマーウィックで。 自由にWAISソフトウェアを利用可能にしました。 しかしながら、シンキング・マシンズ社は、彼らがバージョン8b5.1付けでそれらの公的に分配されたWAISのサポートを止めると発表しました。 公的に分配されたWAISの今後のサポートと開発は米国のCNIDR(Networked情報のディスカバリーとRetrievalのための情報センター)によって引き継がれました。 今後のCNIDRリリースはFreeWAISと呼ばれるでしょう。 新しい会社(WAIS Inc)は、シンキング・マシンズ社WAISソフトウェアの商売人の搾取を引き継ぐためにシンキング・マシンズ社によって形成されました。
WAIS server software is available for the following platforms:
WAISサーバソフトウェアは以下のプラットホームに利用可能です:
o UNIX
o UNIX
o VAX/VMS
o バックス/VMS
Client software is available for the following platforms:
クライアントソフトウェアは以下のプラットホームに利用可能です:
o UNIX (versions for X, Motif, Open Look, Sun View)
o UNIX(Xのためのバージョン、モチーフ、開いている外観、Sun視点)
o NeXT
o 次へ
o Macintosh
o マッキントッシュ
o MS DOS
o MS-DOS
o MS Windows
o MS Windows
o VAX/VMS
o バックス/VMS
There are currently over 400 WAIS databases available on the Internet. WAIS is also the basis of some commercial information services on private networks.
現在、インターネットで利用可能な400以上のWAISデータベースがあります。 また、WAISは私設のネットワークにおけるいくつかの商用情報サービスの基礎です。
Adie [Page 31] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[31ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
WAIS User Image
WAISユーザイメージ
In order to ask a question, the user must first select one or more databases in which to look for the answer. (The list of all available databases is available from a number of well-known sites.) The next step is to enter one or more keywords as the basis of the search. The search will return a list of documents (the "result set") which contain any of the keywords. Each document is given a ranking (a number between 1 and 1000) which indicates how relevant to the user's question the server believes the document to be. The size of each document is also shown in the list. The user may limit the size of the result set - the default limit is typically 40 documents.
質問するために、ユーザは最初に、答えを探す1つ以上のデータベースを選択しなければなりません。 (すべての利用可能なデータベースのリストは多くのよく知られるサイトから利用可能です。) 次のステップは検索の基礎として1つ以上のキーワードを入力することです。 検索はキーワードのいずれも含むドキュメント(「結果セット」)のリストを返すでしょう。 サーバが、ユーザの質問にどれくらい関連することへのドキュメントは信じているかを示すランキング(1と1000の間の数)を各ドキュメントに与えます。 また、それぞれのドキュメントのサイズはリストに示されます。 ユーザは結果セットのサイズを制限するかもしれません--通常、デフォルト限界は40通のドキュメントです。
The user may then choose to retrieve and display one or more documents from the list. Alternatively, he or she may designate one or more documents in the list as "relevant", and perform another search to find "more documents like this". This is called "relevance feedback".
そして、ユーザは、リストから1通以上のドキュメントを検索して、表示するのを選ぶかもしれません。 あるいはまた、その人は、リストの「関連する」としての1通以上のドキュメントを指定して、「このような、より多くのドキュメント」を見つけるために別の検索を実行するかもしれません。 これは「関連フィードバック」と呼ばれます。
The user may retrieve general information about the database, and may examine the catalogue of all documents in the database. There is also a "database of databases", which may be searched to identify WAIS databases which may be relevant to a subject.
ユーザは、データベースに関して一般情報を検索して、データベースですべてのドキュメントに関するカタログを調べるかもしれません。 また、「データベースに関するデータベース」があります。(それは、対象に関連するかもしれないWAISデータベースを特定するために捜されるかもしれません)。
WAIS Protocol
WAISプロトコル
The user interface (client) talks to the server using an extended version of a standard ANSI protocol called Z39.50. This is now aligned with the ISO SR (Search and Retrieval) protocol for bibliographic (library) applications, which is part of OSI. The present WAIS protocol does not utilise a full OSI stack - APDUs are transferred directly over a TCP/IP connection. The WAIS protocol is described in [5].
標準のANSIプロトコルの拡張版を使用するサーバへのユーザーインタフェース(クライアント)会談は、Z39.50と呼びました。 これは現在、図書目録の(ライブラリ)アプリケーションのためのISO SR(検索とRetrieval)プロトコルに並べられます。(それは、OSIの一部です)。 現在のWAISプロトコルは完全なOSIスタックを利用しません--TCP/IP接続の直接上にAPDUsを移します。 WAISプロトコルは[5]で説明されます。
WAIS does not, at this time, implement the full Z39.50-1992 specification - in particular, WAIS does not permit Boolean searches (e.g., "find all documents containing 'chalk' and 'cheese' but not 'green'"). However, Boolean search capability is being added to the FreeWAIS implementation. There are facilities in the Z39.50 protocol for access control and charging, but these are not currently implemented in WAIS.
WAISは、このとき、完全なZ39.50-1992が仕様であると実装しません--特に、WAISは論理演算検索(例えば、「すべてのドキュメントが'緑色'ではなく'チョーク'を含んで、'チーズ'であることがわかる」)を可能にしません。 しかしながら、論理演算検索能力はFreeWAIS実装に加えられています。 アクセスコントロールと充電のためのZ39.50プロトコルには施設がありますが、これらは現在、WAISで実装されません。
The WAIS extensions to Z39.50 are mainly to provide the relevance feedback capability.
Z39.50へのWAIS拡張子は主に関連フィードバック能力を提供することです。
Note that the Z39.50 protocol is not stateless - the result set may in some circumstances be retained by the server for the user to further refine or refer to. However, the subset of Z39.50 used by
Z39.50プロトコルが状態がなくないことに注意してください--結果セットはいくつかの事情でユーザがさらに洗練するか、または示すサーバによって保有されるかもしれません。 しかしながら、Z39.50の部分集合は使用しました。
Adie [Page 32] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[32ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
current WAIS implementations mean that server implementations may be stateless.
現在のWAIS実装は、サーバ実装が状態がないかもしれないことを意味します。
Document type is determined by the server from information in the database index (see below), and is sent to the client as part of the result set.
ドキュメントタイプはサーバでデータベースインデックス(以下を見る)の情報から決定して、結果の一部がセットしたので、クライアントに送ります。
WAIS Publishing
WAIS出版
The first step in preparing data for publishing in a WAIS database is to use the 'waisindex' utility. This takes a set of text files, and produces an index file which contains an occurrence list of words of three or more letters in every file. This index file is used by the WAIS server software to resolve search requests from clients.
WAISデータベースで発行するためにデータを準備することにおける第一歩は'waisindex'ユーティリティを使用することです。 これは、1セットのテキストファイルを取って、あらゆるファイルに3個以上の手紙の単語の発生リストを含む索引ファイルを作り出します。 この索引ファイルはWAISサーバソフトウェアによって使用されて、クライアントからの検索要求を決議します。
The 'waisindex' utility indexes files in a wide range of text formats, as well as postscript and image files in various encodings (only the file name is indexed for image files). Some of the text formats involve a file as being treated as a collection of documents for the purposes of WAIS access. Note that there appears to be no formal "registry of types" - just whatever the waisindex program supports. There is no distinction between media type and encoding format.
'waisindex'ユーティリティはさまざまなテキスト形式、および追伸のファイルと様々なencodingsのイメージ・ファイルに索引をつけます(ファイル名だけがイメージ・ファイルのために索引をつけられます)。 テキスト形式のいくつかがWAISアクセサリーの目的のためのドキュメントの収集として扱われるとしてファイルにかかわります。 どんな正式な「タイプの登録」もあるように見えないことに注意してください--ちょうどwaisindexプログラムがサポートすることなら何でも。 メディアタイプとコード化形式の間には、区別が全くありません。
Published Non-text Data
発行された非テキストデータ
There is relatively little non-text data available in WAIS databases.
WAISデータベースで利用可能な比較的小さい非テキストデータがあります。
o URL=wais://quake.think.com:210/CM-images is a database of
TIFF images from the Connection Machine.
o URL=wais://quake.think.com: CM210/イメージはConnection MachineからのTIFFイメージに関するデータベースです。
o URL=wais://mpcc3.rpms.ac.uk:210/home/images/pathology/RPMS-
pathology is a database of histo-pathological images and
documentation on mammalian endocrine tissue.
o URL=wais://mpcc3.rpms.ac.uk: 210/ホーム/イメージ/病理学/RPMS病理学は哺乳類の内分泌組織に関するhisto病理学的なイメージとドキュメンテーションに関するデータベースです。
o URL=wais://starhawk.jpl.nasa.gov:210/pio contains GIF images
from NASA planetary probe missions, together with their
captions. The presence of the caption index information
makes it difficult to construct a search which returns
images in the result set increasing the maximum result set
size may help.
o URL=wais://starhawk.jpl.nasa.gov: 210/pioはそれらの見出しと共にNASAの惑星の徹底的調査任務からのGIFイメージを含んでいます。 見出しインデックス情報の存在で、サイズが助けるかもしれない最大の結果セットを増強するように設定された結果におけるイメージを返す検索を構成するのは難しくなります。
Advantages
利点
WAIS is ideally suited for its intended purpose of searching databases of textual information on the basis of keywords. It appears to have the potential to satisfy the requirements of some of the "database" category of applications mentioned in Chapter 1.
WAISは理想的にキーワードに基づいて文字情報に関するデータベースを捜す本来の目的に合っています。 それは第1章で参照されたアプリケーションの「データベース」カテゴリのいくつかの要件を満たす可能性を持っているように見えます。
Adie [Page 33] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[33ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Limitations
制限
WAIS is not (and does not pretend to be) a general-purpose information system, as Gopher and WWW are. WAIS does not have hyperlinking, and offers a purely flat structure.
WAISはゴーファーとWWWのように(そして、架空でなく、します)汎用情報システムではありません。 WAISはハイパーリンクを持たないで、純粋に平坦な構造を提供します。
A limitation which is particularly apparent is the way that the current version of FreeWAIS indexes non-text files - using only the filename! However, it does seem that simply changing the indexing program to allow a list of keywords to be attached to non-text files would suffice to allow sensible indexing of non-text data. The commercial (WAIS Inc) version of WAIS allows several files to be associated together for indexing and retrieval purposes. Furthermode, the UCSF Centre for Knowlege Management is modifying the FreeWAIS code to support the indexing of multiple content types. The document returned by WAIS will be an HTML document containing pointers to the multimedia data. Contact dcmartin@library.ucsf.edu for further information.
特に明らかな制限はファイル名だけを使用して、FreeWAISの最新版が非テキストファイルに索引をつける方法です! しかしながら、キーワードのリストが非テキストファイルに添付されるのを許容するために単にインデックスプログラムを変えるのが非テキストデータの分別があるインデックスを許すために十分であるように思えます。 WAISの商業(WAIS Inc)バージョンは、いくつかのファイルがインデックスと検索目的のために一緒に関連しているのを許容します。 Furthermode、Knowlege ManagementのためのUCSF Centreは複数のcontent typeのインデックスをサポートするようにFreeWAISコードを変更しています。 WAISによって返されたドキュメントはマルチメディアデータに指針を含むHTMLドキュメントになるでしょう。 詳細のために dcmartin@library.ucsf.edu に連絡してください。
WAIS is not a fully-featured query/response protocol such as SQL. It has no concept of fields, or numeric data types.
WAISはSQLなどの完全に特集された質問/応答プロトコルではありません。 それには、分野、または数値データ型の概念が全くありません。
It appears to be impossible to retrieve a document from its catalogue entry in many of the existing databases.
既存のデータベースの多くにおけるカタログエントリーからドキュメントを検索するのが不可能であるように見えます。
3.3. World-Wide Web
3.3. WWW
The World-Wide Web project (also known as WWW or W3), started and driven by CERN, is a large-scale distributed hypertext system. It uses the standard client-server paradigm, with client "browser" software responsible for fetching and displaying data. Originally aimed at the High Energy Physics community, it has spread to other areas.
CERNによって始められて、追い立てられたWWWプロジェクト(また、WWWかW3として、知られている)は大規模な分配されたハイパーテキスト・システムです。 クライアント「ブラウザ」ソフトウェアが原因となっていた状態で、それは、データをとって来て、表示するのに標準のクライアント/サーバパラダイムを使用します。 High Energy Physics共同体が元々向けられて、それは他の領域に広まりました。
Browser software is available for a large number of systems including:
利用可能であることで、:ブラウザー・ソフトウェアは多くのシステムに利用可能です。
o Line-mode dumb terminal.
o ライン・モードダム端末。
o Terminal with Curses support
o Cursesサポートで、端末です。
o Macintosh
o マッキントッシュ
o X/Motif
o X/モチーフ
o X11
o X11
o PC/MS Windows
o PC/MS Windows
Adie [Page 34] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[34ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
o NeXT
o 次へ
There is server software available for:
利用可能なサーバソフトウェアが以下のためにあります。
o VM mainframes.
o VMメインフレーム。
o UNIX
o UNIX
o Macintosh
o マッキントッシュ
o VMS
o VMS
WWW User Image
WWWユーザイメージ
The WWW world consists of nodes (usually called documents) and links. Links are connections between documents: to follow a link, a reader clicks with a mouse on a word in the source document, which causes the linked-to document to be retrieved and displayed. (On systems without a mouse, the user types a number instead.)
WWW世界はノード(通常、ドキュメントと呼ばれる)とリンクから成ります。 リンクはドキュメントの間の接続です: リンクに続くように、読者はソースドキュメントの単語でマウスを理解します。(ソースドキュメントは、つないでいるドキュメントが検索されて、表示されることを引き起こします)。 (マウスのいないシステムで、ユーザは代わりに数をタイプします。)
Indexes are special documents which, rather than being read, may be searched. To search an index, a reader supplies keywords (or other search criteria). The result of a search is a "virtual" document containing links to the documents found. All documents, whether real, virtual or indexes, look similar to the reader.
インデックスは読まれるよりむしろ捜されるかもしれない特別なドキュメントです。 インデックスを捜すために、読者はキーワード(または、他の検索評価基準)を提供します。 検索の結果は見つけられたドキュメントへのリンクを含む「仮想」のドキュメントです。 すべてが本当であって、仮想であるか否かに関係なく、記録するか、索引をつけて、または同様に見える、読者。
The WWW addressing mechanism means that an interface to Gopher and anonymous FTP information sources may be established, in a way which is transparent to the user. Thus, the whole of gopherspace is part of the Web. Transparent gateways to other systems, including Hyper-G and WAIS, are also available.
WWWアドレシングメカニズムは、ゴーファーと公開FTP情報源へのインタフェースが設置されるかもしれないことを意味します、ユーザにとって、見え透いた方法で。 したがって、gopherspaceの全体がウェブの一部です。 また、Hyper-GとWAISを含む他のシステムへの透明なゲートウェイも利用可能です。
URL
URL
All nodes on the Web are addressed using the "Universal [or Uniform] Resource Locator" (URL) syntax, defined in [6]. This is an Internet Draft produced by the IETF URL Working Group.
ウェブのすべてのノードが、[6]で定義された「普遍的で[一定]のリソースロケータ」(URL)構文を使用することで扱われます。 これはIETF URL作業部会によって生産されたインターネットDraftです。
A URL is a name for an object (which may be a document or an index) on the Internet. It has the general form:
URLはインターネットのオブジェクト(ドキュメントかインデックスであるかもしれない)のための名前です。 それには、一般的なフォームがあります:
<scheme> : <path> [ # <anchorid> ]
<体系>: <経路>。[#<anchorid>]
The <scheme> identifies an access protocol or method for the object. Some of the schemes are HTTP (the native WWW protocol), anonymous FTP, Andrew file system, news, WAIS, Gopher. The <path> component locates the document in a way significant for the access method.
<体系>はオブジェクトのためにアクセス・プロトコルかメソッドを特定します。 体系のいくつかがHTTP(固有のWWWプロトコル)、公開FTP、アンドリューファイルシステム、ニュース、WAIS、ゴーファーです。 <経路>の部品はアクセス法には、ある意味で重要なドキュメントの場所を見つけます。
Adie [Page 35] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[35ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Thus for instance for anonymous FTP, the path includes the fully qualified domain name of the host on which the document resides, and the directory and file name under which it may be found. For some schemes, the <path> may include a search string (or combination of strings) which is used to address a "virtual" object formed by searching an index of some kind. The HTTP, WAIS and Gopher schemes can use search strings, which usually follow the rest of the path, separated from it by a ?.
したがって、例えば、公開FTPのために、経路はそれが見つけられるかもしれないドキュメントがあるホストの完全修飾ドメイン名、ディレクトリ、およびファイル名を含んでいます。 いくつかの体系のために、<経路>はある種のインデックスを捜すことによって形成された「仮想」のオブジェクトを扱うのに使用される検索ストリング(または、ストリングの組み合わせ)を含むかもしれません。 HTTP、WAIS、およびゴーファー体系は検索ストリングを使用できますか?(通常、ストリングはaによってそれと切り離された経路の残りに続きます)。
The optional <anchorid> is used for addressing within an object. Its interpretation is not defined in the URL specification.
任意の<anchorid>はオブジェクトの中のアドレシングに使用されます。 解釈はURL仕様に基づき定義されません。
"Partial" URLs may be specified. These are used within a document on the Web to refer to another "nearby" document - for instance to a document in another file on the same machine. Certain parts of the URL (e.g., the scheme and machine name) may be omitted, according to well-defined rules. This makes it much easier to move groups of documents around, while maintaining the links within and between them.
「部分的な」URLは指定されるかもしれません。 これらは別の「近い」ドキュメントを参照するのにウェブのドキュメントの中に使用されます--例えば同じマシンの上の別のファイルのドキュメントに。 明確な規則に従って、URL(例えば、体系とマシン名)のある部分は省略されるかもしれません。 これで、それらとそれらとのリンクを維持している間、周囲でドキュメントのグループを動かすのははるかに簡単になります。
A URL locates one and only one object on the Internet. However, more than one URL may point to the same object. Given two URLs, it is not in general possible to determine whether they refer to the same object. Furthermore, there is no guarantee that a single URL will refer to the same object at different times (the object may change incrementally, or it may be completely replaced with something different, or it may indeed be removed).
URLは唯一無二の1個のオブジェクトのインターネットに場所を見つけます。 しかしながら、1つ以上のURLが同じオブジェクトを示すかもしれません。 一般に、2つのURLを考えて、それは考えません。彼らが同じオブジェクトについて言及するかどうか決定するのにおいて、可能です。 その上、ただ一つのURLがいろいろな時間に同じオブジェクトについて言及するという(オブジェクトが増加して変化するかもしれませんか、それを何か異なったものに完全に取り替えるかもしれませんか、または本当に、それを移すかもしれません)保証が全くありません。
HTTP
HTTP
HTTP (HyperText Transfer Protocol) is the protocol employed between server and client. It is defined in [7]. The protocol is currently being revised (see the Future Developments section below), and will eventually be proposed as an Internet standard.
HTTP(HyperText Transferプロトコル)はサーバとクライアントの間で使われたプロトコルです。 それは[7]で定義されます。 プロトコルは、現在、改訂されていて(下のFuture Developments部を見ます)、結局、インターネット標準として提案されるでしょう。
The original protocol is extremely simple, and requires only a reliable connection-oriented transport service, typically TCP/IP.
オリジナルのプロトコルは、非常に簡単であり、信頼できる接続指向の輸送サービスだけ、通常TCP/IPを必要とします。
The client establishes a connection with the server, and sends a request containing the word GET, a space, and the partial URL of the node to be retrieved, terminated by CR LF. The server responds with the node contents, comprising a text document in the Hypertext Markup Language (HTML). The end of the contents is indicated by the server closing the connection.
クライアントは、サーバで取引関係を築いて、GET(スペース、および検索されるべきノードの部分的なURL)がCR LFで終わったという単語を含む要求を送ります。 ハイパーテキストマークアップランゲージ(HTML)でテキストドキュメントを包括して、サーバはノードコンテンツで反応します。 コンテンツの終わりは接続を終えるサーバによって示されます。
Adie [Page 36] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[36ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
HTML
HTML
HTML (HyperText Markup Language) is the way in which text documents must be structured if they are to contain links to other documents. Non-HTML text documents may of course be made available on the Web, but they may not contain links to other documents (i.e., they are leaf nodes), and they will be displayed by browsers without formatting, probably using a fixed-width font. Like HTTP, HTML is also undergoing enhancement, but the original version is defined in [7], and is being submitted as an Internet draft.
HTML(ハイパーテキスト・マークアップ言語)は他のドキュメントへのリンクを含むつもりであるならテキストドキュメントを構造化しなければならない方法です。 他のドキュメントへのリンクを含まないかもしれません、そして、(すなわち、それらは葉のノードです)もちろん非HTMLテキストドキュメントをウェブで利用可能にするかもしれませんが、ブラウザは形式なしでそれらを表示するでしょう、たぶん固定ピッチフォントを使用して。 また、HTTPのように、HTMLが増進を受けていますが、オリジナルバージョンを[7]で定義して、インターネット草稿として提出しています。
HTML is an application of SGML (Standard Generalized Markup Language). It defines a range of useful tags for indicating a node title, paragraph boundaries, headings of several different levels, highlighting, lists, etc. Anchors are represented using an <A> tag.
HTMLはSGML(標準のGeneralized Markup Language)のアプリケーションです。 それはノードタイトル、パラグラフ限界、いくつかの異なったレベルに関する見出し、ハイライト、リストなどを示すためのさまざまな役に立つタグを定義します。 アンカーは、<A>タグを使用することで代理をされます。
For instance, here is an example of HTML containing an anchor:
例えば、ここに、アンカーを含んで、HTMLに関する例があります:
The HTTP protocol implements the WWW <A NAME=13 HREF="../../Administration/DataModel.html">data model</A> .
「HTTPプロトコルは、WWW<AがNAME=13 HREF=であると実装します。」/../Administration/DataModel.html「>データモデル</A>。」
The location of the anchor is the text "data model". It is a source anchor, with a target given by the URL in the HREF attribute, so the text would appear highlighted in some way in a client's window, to indicate that clicking on it would cause a hyperlink to be traversed. It is also a target anchor, with an anchor ID given by the NAME attribute. A source anchor referring to this target would specify #13 at the end of the node's URL. Traversing a hyperlink to this node would cause the entire node to be retrieved, but the target anchor text would be displayed in some emphasised way - for instance if the retrieved text is displayed in a scrolling window, it might be positioned such that the target anchor appears at the top of the window.
アンカーの位置はテキスト「データモデル」です。 それはソースのアンカーです、テキストがそれをクリックするのにハイパーリンクを横断するのを示すためにクライアントの窓で強調されているように何らかの方法で見えてURLでHREF属性で目標を与えていて。 また、それはNAME属性でアンカーIDを与えている目標アンカーです。 この目標を示すソースのアンカーはノードのURLの端で#13、を指定するでしょう。 何らかの強調された方法で目標アンカーテキストを表示するでしょう--このノードにハイパーリンクを横断するのに全体のノードを検索するでしょうが、例えば、スクロールの窓に検索されたテキストを表示するなら、それを置くかもしれないので、目標アンカーは窓の先端に現れます。
Another attribute of the <A> element, TYPE, is also available, which is intended to describe the nature of the relationship modelled by the link. However, this is not in extensive use, and there appears to be no registry of the possible values of such types.
また、<A>要素の別の属性(TYPE)も利用可能である、どれが関係の本質について説明することを意図するかリンクのそばでモデル化されました。 しかしながら、これは大規模に使用中ではありません、そして、そのようなタイプの可能な値の登録が全くあるように見えません。
Future Developments
未来の発展
HTTP and HTML are currently being extended in a backward-compatible way to add multimedia facilities. [8] describes the HTTP2 protocol. The revised HTML is defined in [9]. Both documents are subject to change (and indeed the HTML2 specification has changed substantially during the preparation of this report).
HTTPとHTMLは現在、マルチメディア施設を加える後方コンパチブル方法で広げられています。 [8]はHTTP2プロトコルについて説明します。 改訂されたHTMLは[9]で定義されます。 ドキュメントを条件としている両方が変化します(本当に、HTML2仕様はこのレポートの準備の間、実質的に変化しています)。
Adie [Page 37] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[37ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
The revised HTML contains many enhancements which are useful for multimedia support. Some of the most relevant are listed below.
改訂されたHTMLはマルチメディアサポートの役に立つ多くの増進を含んでいます。 最も関連することの或るものは以下に記載されています。
o "Universal Resource Numbers" are a proposed system for
unique, timeless identifiers of network-accessible files
presently being designed by IETF Working Groups. URNs must
be distinguished from URLs, which contain information
sufficient to locate the document. URNs may be allocated to
nodes and may be represented in source anchors. This saves
client software from retrieving a copy of something it
already has - allowing sensible caching of large video
clips, for instance. The disadvantage is that when
something is changed and given a new URN, the source anchors
of all links which point to it must be changed (and the URNs
of these documents must therefore be changed, and so on).
Therefore, it makes sense to allocate URNs only to very
large documents which change rarely, and not to the
documents which reference them.
o 「普遍的なResource民数記」は現在IETF Working Groupsによって設計されるネットワークアクセス可能なファイルのユニークで、永遠の識別子の提案されたシステムです。 URLとURNsを区別しなければなりません。(URLはドキュメントの場所を見つけることができるくらいの情報を含みます)。 URNsはノードに割り当てられて、ソースのアンカーに表されるかもしれません。 例えば、大きいビデオクリップの分別があるキャッシュを許して、これは、検索からのクライアントソフトウェアがそれが既に持っている何かのコピーであると保存します。 不都合は何かは変えて、新しいURNを与えるとき、それを示すすべてのリンクのソースのアンカーを変えなければならないという(したがって、これらのドキュメントのURNsは変えて、とてもオンでなければなりません)ことです。 したがって、それはそれらを非常に大きいドキュメントだけにURNsを割り当てるドキュメント変えるのではなく、めったにどの参照を変えない感覚にします。
o The title of a destination document may be included as
anattribute of a source anchor. This allows a client to
display the title to the user before or during retrieval,
and also allows data which does not itself contain a title
(e.g., image data) to be given one.
o 目的地ドキュメントのタイトルはソースのアンカーのanattributeとして含まれるかもしれません。 これは、クライアントが検索の前か検索間、ユーザにタイトルを表示するのを許容して、また、それ自体をするというわけではないものをデータに許容します。与えられたものになるように、タイトル(例えば、イメージデータ)を含んでください。
o There is provision for in-line non-text data (e.g., images,
video, graphics, mathematical equations), which appears in
the samewindow as the main textual material in the node.
o 支給がインライン非テキストデータ(例えば、イメージ、ビデオ、グラフィックス、数学の方程式)のためにあります。(データは主な原文の材料としてノードにsamewindowに現れます)。
o The concept of the relationship expressed by a hyperlink is
expanded. Both source and target anchors may contain
relation attributes which point forwards and backwards
respectively. Possible relationships include "is an index
for", "is a glossary for", "annotates", "is a reply to", "is
embedded in", "is presented with". The last two are useful
for multimedia - for instance, the "embed" relationship
could cause a retrieved image to be fetched and embedded in
the display of a text node, and the "present" relationship
could cause a sound clip to be automatically retrieved and
presented along with a text node.
o ハイパーリンクによって言い表された関係の概念は広げられます。 ソースと目標アンカーの両方が前方に後方にそれぞれ指す関係属性を含むかもしれません。 可能な関係が含んでいる、「インデックスである、」、「用語集である、」、「注釈」、「aが答える、」、「中に埋め込まれてい」て、「与えます」。 最後の2はマルチメディアの役に立ちます--例えば、「埋め込み」関係は、検索されたイメージがテキストノードのディスプレイにとって来られて、埋め込まれていることを引き起こす場合があって、「現在」の関係は、サウンド・クリップがテキストノードと共に自動的に検索されて、提示されることを引き起こす場合がありました。
The HTTP2 protocol maintains the same stateless connect/request/response/close procedure as the current HTTP protocol. Data is transferred in MIME-shaped messages, allowing all MIME data formats (including HTML) to be used. As well as the GET operation, HTTP2 has operations such as:
プロトコルが同じように状態がなく維持するHTTP2は現在のHTTPプロトコルとして/要求/応答/近い手順を接続します。 すべてのMIMEデータ形式(HTMLを含んでいる)が使用されるのを許容して、MIME形をしているメッセージでデータを移します。 GET操作と同様に、HTTP2には、以下などの操作があります。
Adie [Page 38] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[38ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
HEAD Fetch attribute information about a node
(including the media type and encoding)
ノードのHEAD Fetch属性情報(メディアタイプとコード化を含んでいます)
CHECKOUT/CHECKIN/PUT/POST
チェックアウト/チェックイン/は/ポストを置きました。
These allow nodes to be checked out for updating
and checked back in again, and new nodes to be
created. New node data is supplied in MIME
shape with the request.
これらは、ノードがアップデートのために調べられて、再びチェックされるのを許容して、新しいノードが作成されるのを許容します。 新しいノードデータに要求をMIME形で提供します。
The request from the client can contain a list of formats which the client is prepared to accept, user identification, authorisation information (a placeholder at present), an account name to charge any costs to, and identification of the source anchor of the hyperlink through which the node was accessed.
クライアントからの要求はクライアントが受け入れる用意ができている形式のリストを含むことができます、ユーザ登録名、認可情報(現在のところのプレースホルダ)、ノードがアクセスされたハイパーリンクのソースのアンカーのどんなコスト、および識別も請求するアカウント名。
The response from the server may contain a range of useful attributes (e.g., date, cost, length - but only for non-text data). The server may redirect the query, indicating a new URL to use instead. It may also refuse the request because of authorisation failure or absence of a charge account in the request.
サーバからの応答がさまざまな役に立つ属性を含むかもしれない、(例えば、日付、費用、長さ、非テキストデータだけ、) 代わりに使用する新しいURLを示して、サーバは質問を向け直すかもしれません。 また、それは要求における、掛売りの認可失敗か欠如のために要求を拒否するかもしれません。
The protocol also contains a mechanism which is designed to allow the server to make an intelligent decision about the most appropriate format in which to return data, based on information supplied in the request by the client. This may for instance allow a powerful server to store the uncompressed bitmap of an image, but to compress it on request using an appropriate encoding, according to the decoding capabilities announced by the client.
また、プロトコルはサーバがデータを返す最も適切な形式に関する知的な決定をするのを許容するように設計されているメカニズムを含んでいます、クライアントによる要求で提供された情報に基づいて。 これで、例えば、強力なサーバはイメージの解凍されたビットマップを保存できるかもしれませんが、解読能力に従って適切なコード化を使用することで要求に応じてそれを圧縮するのはクライアントで発表しました。
An HTTP2 server and client are currently under test. Some HTML2 features are already fitted to the XMosaic browser.
HTTP2サーバとクライアントは現在、テストされています。 いくつかのHTML2の特徴が既にXMosaicブラウザに似合われています。
Mosaic
モザイク
The Mosaic project, located at the US National Centre for Supercomputing Applications (NCSA) at the University of Illinois, is developing a networked information system intended for wide-area distributed asynchronous collaboration and hypermedia-based information discovery and retrieval. Mosaic, which is specifically oriented towards scientific research workers, has adopted the World Wide Web as the core of the system, and the first Mosaic software to appear was the XMosaic WWW client for UNIX with X. Other clients of similar functionality are under development for the Apple Macintosh and the PC with Windows.
イリノイ大学にSupercomputing Applications(NCSA)のための米国National Centreに位置するモザイクプロジェクトは広い領域の分配された非同期な共同、ハイパーメディアベースの情報発見、および検索のために意図するネットワークでつながれた情報システムを開発しています。 モザイク(明確に科学的調査労働者に向かって適応する)はシステムのコアとしてWWWを採用しました、そして、現れる最初のモザイクソフトウェアはX.があるUNIXのためのXMosaic WWWクライアントでした。アップルマッキントッシュとPCにおいて、同様の機能性のOtherクライアントはWindowsと共に開発中です。
The capabilities of the XMosaic browser include:
XMosaicブラウザの能力は:
Adie [Page 39] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[39ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
o Support for NCSA's Data Management Facility (DMF) for
scientific data.
o NCSAのData Management Facilityには、科学的データのための(DMF)をサポートしてください。
o Support for transferring data with other NCSA tools such
asCollage, using NCSA's Data Transfer Mechanism (DTM).
o 他のNCSAがあるデータを移すには、NCSAのData Transfer Mechanism(DTM)を使用して、ツールがそのようなasCollageであるとサポートしてください。
o The ability to "check out" documents for revision, and to
check them back in again.
o 「チェックアウトする」能力は再び改正と、チェックにそれらを記録します。
o Local and remote annotation of Web documents.
o ウェブドキュメントの地方の、そして、リモートな注釈。
Future planned functionality includes:
将来の計画された機能性は:
o In-line non-text data (in addition to images).
o インライン非テキストデータ(イメージに加えた)。
o Information space graphical representation and control.
o 情報宇宙グラフ表示とコントロール。
o Hypermedia document editing.
o ハイパーメディアドキュメント編集。
o Information filtering.
o 情報フィルタリング。
NCSA intends to make the entire Mosaic system publicly available and distributable.
NCSAは全体のモザイクシステムを公的に利用可能で配置可能にするつもりです。
The XMosaic browser was used extensively for finding and retrieving information used to prepare this report.
XMosaicブラウザは、このレポートを作成するのに使用される情報を見つけて、検索するのに手広く使用されました。
Web Publishing
ウェブ出版
Making a web is as simple as writing a few SGML files which point to your existing data. Making it public involves running the FTP or HTTP daemon, and making at least one link into your web from another. In fact, any file available by anonymous FTP can be immediately linked into a web. The very small start-up effort is designed to allow small contributions.
ウェブを作るのはあなたの既存のデータを示すいくつかのSGMLファイルを書くのと同じくらい簡単です。 それを公共にするのはFTPかHTTPデーモンを実行して、別のものからあなたのウェブに少なくとも1個のリンクを作りかえることを伴います。 事実上、すぐに、公開FTPで利用可能などんなファイルもウェブにリンクできます。 非常に小さい始動取り組みは、少額の寄付を許容するように設計されています。
At the other end of the scale, large information providers may provide an HTTP server with full text or keyword indexing. This may allow access to a large existing database without changing the way that database is managed. Such gateways have already been made into Digital's VMS/Help, Technical University of Graz's "Hyper-G", and Thinking Machine's WAIS systems.
スケールのもう一方の端では、大きい情報提供者は全文かキーワードインデックスをHTTPサーバに提供するかもしれません。 データベースが管理される方法を変えないで、これは大きい既存のデータベースへのアクセスを許すかもしれません。 既にそのようなゲートウェイをVMS/ヘルプDigitalの、グラーツの「超-G」のTechnical大学、およびシンキングマシンのWAISシステムにしました。
There are a few editors which understand HTML - for instance on UNIX and on the NeXT platform.
HTMLを理解している数人のエディタがいます--例えばUNIXの上と、そして、NeXTプラットホームの上で。
Adie [Page 40] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[40ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Published non-text data
発行された非テキストデータ
See the multimedia demo node on:
以下でマルチメディアデモノードを見てください。
http://hoohoo.ncsa.uiuc.edu:80/mosaic-docs/multimedia.html
http://hoohoo.ncsa.uiuc.edu:80/mosaic-docs/multimedia.html
This contains links to images, sound, movies and postscript media types. The media type is determined by the filename extension in the URL specification of the target node. The (XMosaic) client uses this to invoke a separate program appropriate for displaying the media type, or in some cases it can be displayed embedded within the source document. The latter method uses an <IMG> tag, which is part of HTML2.
これはイメージ、音、映画、および追伸メディアタイプへのリンクを含んでいます。 メディアタイプは目標ノードのURL仕様に基づくファイル名拡大で決定します。 いくつかの場合、(XMosaic)クライアントがメディアタイプを表示するのに、適切な別々のプログラムを呼び出すのにこれを使用するか、またはソースドキュメントの中で埋め込まれていた状態でそれを表示できます。 後者のメソッドは<IMG>タグを使用します。(それは、HTML2の一部です)。
Advantages
利点
WWW is a hypertext system and its underlying technology is thus richer than Gopher. The use of SGML, which is of increasing importance in hypermedia systems, allows a great deal of expressiveness and structure, and enables text to be presented in an attractive way. The facilities for multimedia data in the extended versions of HTTP and HTML are excellent. It also seems that QOS and management issues identified in Chapter 2 are to some degree catered for in these extensions.
WWWがハイパーテキスト・システムであり、その結果、基本的な技術はゴーファーより豊かです。 SGMLの使用は、多くの表情の豊かさと構造を許容して、テキストが魅力的な方法で提示されるのを可能にします。(SGMLはハイパーメディアシステムで増加して重要です)。 HTTPとHTMLの拡張版のマルチメディアデータのための施設は素晴らしいです。 また、問題が第2章で特定したQOSと管理がこれらの拡大である程度満たされるように思えます。
Limitations
制限
There is no indication in the source anchor of the media type of the destination node, or of its size (this has been ruled out on the argument that the information is likely to degrade with time). It is necessary to perform a HEAD request (in HTTP2) to deduce this.
指示が全く目的地ノードのメディアタイプ、またはそのサイズのソースのアンカーにありません(これは情報が時間と共に退行しそうであるという主張のときに除外されました)。 これを推論するというHEAD要求(HTTP2の)を実行するのが必要です。
Link source anchors must be in text documents, so non-text nodes must be leaf nodes. However, with HTML2 using the <IMG> tag, an embedded bitmap may be used as a source anchor, and the position of the mouse click within the image is passed to the server, which can then choose to return a different document depending on where in the image the mouse was clicked.
リンクソースのアンカーがテキストドキュメントにいるに違いないので、非テキストノードは葉のノードであるに違いありません。 しかしながら、<IMG>タグを使用するHTML2と共に埋め込まれたビットマップはソースのアンカーとして使用されるかもしれません、そして、イメージの中のマウスクリックの位置はサーバに通過されます。(次に、それは、イメージで、マウスがクリックされたところによる異なったドキュメントを返すのを選ぶことができます)。
WWW is much less prevalent than Gopher, partly because of an (erroneous?) perception that setting up an HTTP server is more complex than setting up a Gopher server. There are only about 60 servers world-wide; however the growth in the use of WWW is much faster than the growth in the use of Gopher. The availability of sophisticated WWW clients such as XMosaic is fuelling this growth.
WWWはゴーファーよりあまり一般的ではありません、一部HTTPサーバをセットアップして、ゴーファーサーバをセットアップするより複雑な(誤る)?の知覚のために。およそ60のサーバしか世界中にありません。 しかしながら、WWWの使用における成長はゴーファーの使用における成長よりはるかに速いです。 XMosaicなどの洗練されたWWWクライアントの有用性はこの成長をあおっています。
Adie [Page 41] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[41ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
3.4. Evaluating Existing Tools
3.4. 既存のツールを評価します。
This section compares the capabilities of the Gopher, WAIS and WorldWide Web systems (abbreviated as GWW) to the informal requirements defined in section 2.3.
このセクションはゴーファー、WAIS、およびWorld Wide Webシステム(GWWが簡略化されている)の能力をセクション2.3で定義された非公式の要件にたとえます。
Platforms
プラットホーム
The table below gives the names of the most important client software for each of GWW on the three most important platforms of interest. WWW is the weakest, with clients for the Macintosh and the PC still under development. The main PC Gopher client is "PC Gopher III", which is a DOS program, not a Windows program.
以下のテーブルは興味がある最も重要な3個のプラットホームでそれぞれのGWWに、最も重要なクライアントソフトウェアの名前を与えます。 クライアントにとって、まだ開発中のマッキントッシュとPCに、WWWは最も弱いです。 主なPCゴーファークライアントはWindowsプログラムではなく、DOSプログラムである「PCゴーファーIII」です。
CLIENTS Gopher WAIS WWW
クライアントゴーファーWAIS WWW
Macintosh TurboGopher WAIStation (No name)
(beta version
available)
マッキントッシュTurboGopher WAIStation(名前がありません)(利用可能なベータバージョン)
PC with HGopher (two WAIS for Cello (beta
Windows others also Windows, WAIS version
available) Manager available),
Mosaic (beta due
3Q93)
HGopher(Cello(ベータWindows他のものWindowsも、利用可能なWAISバージョン)マネージャのための利用可能な2WAIS)があるPC、モザイク(ベータ支払われるべきもの3Q93)
UNIX with X Xgopher, XWAIS XMosaic
XMosaic
X Xgopher、XWAIS XMosaic XMosaicとのUNIX
At present, multimedia support in most of these clients (where it exists) is limited to the invocation of external "viewer" programs for particular media types. The exception is XMosaic, which supports in-line images in WWW documents.
現在のところ、これらのクライアント(それが存在するところ)の大部分でのマルチメディアサポートは特定のメディアタイプのために外部の「ビューアー」プログラムの実施に制限されます。 例外はXMosaicです。(そのXMosaicはWWWドキュメントのインラインイメージをサポートします)。
Media Types
メディアタイプ
The GWW tools can all handle multiple media types well.
GWWツールはすべて、マルチメディアタイプをよく扱うことができます。
o Text is very well supported by all three tools. WWW offers
facilities for displaying "richer" text, supporting
headings, lists, emphasised text etc., in a standardised way.
o テキストはすべての3つのツールによって非常によくサポートされます。 WWWは、標準化された方法で見出し、テキストの強調されたリストなどをサポートして、「より豊かな」テキストを表示するために施設を提供します。
o Image data is also well supported, using either external
viewers (e.g., the TurboGopher client software on a Macintosh
might invoke the JPEGView program to display an image); or
in-line display within a text document (WWW with XMosaic on
UNIX).
o また、イメージデータはよくサポートされます、外部ビューワを使用して(例えば、マッキントッシュの上のTurboGopherクライアントソフトウェアはイメージを表示するためにJPEGViewプログラムを呼び出すかもしれません)。 または、テキストドキュメント(UNIXの上にXMosaicがあるWWW)の中のインラインディスプレイ。
Adie [Page 42] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[42ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
o There is little direct support for application-specific
data, but most systems allow data of a nominated type to be
passed to an external viewer or editor program. This tends
to be a function of the client software rather than being
built in to the protocol or server. There has been
discussion in the WWW community about using TeX for
representing mathematical equations, and about providing
"panels" within a text document where a separate application
could render its application-specific data (or indeed any
data which can be represented spatially). This latter
suggestion fits well with the OLE (Object Linking and
Embedding) approach used in Microsoft Windows.
o アプリケーション特有のデータのダイレクトサポートがほとんどありませんが、ほとんどのシステムが、指名タイプに関するデータが外部ビューワか編集プログラムに渡されるのを許容します。 これは、プロトコルかサーバに建てられるよりむしろクライアントソフトウェアの機能である傾向があります。数学の方程式を表すのにTeXを使用して、別々のアプリケーションがアプリケーション特有のデータ(または、本当に空間的に表すことができるどんなデータも)を表すことができたテキストドキュメントの中に周囲で「パネル」を提供して、使用することに関して議論がWWW共同体にありました。 この後者の提案はマイクロソフトWindowsに使用されるOLE(オブジェクトLinkingとEmbedding)アプローチをよく与えます。
o Sound can be supported through the external "viewer"
concept. Some platforms don't have readily-available
"viewers" with "tape recorder"-style controls for replaying.
There is no single commonly-accepted sound encoding format.
o 外部の「ビューアー」概念を通して音をサポートすることができます。 いくつかのプラットホームには、容易に利用可能な「ビューアー」が再演するための「テープレコーダ」スタイルコントロールでありません。 どんなただ一つの一般的に受け入れられた音のコード化形式もありません。
o Video data can be handled using external viewers. MPEG and
QuickTime are the most common encodings.
o 外部ビューワを使用することでビデオ・データを扱うことができます。 MPEGとクイックタイムは最も一般的なencodingsです。
One essential capability of a client/server protocol is the ability for the client to determine the type of a node (and a list of available encodings) before downloading it. WAIS and Gopher transfer this information in the result set and menu respectively. WWW clients currently determine this information either from analysing the URL of a target node, or by the occurrence of the <IMG> tag. The new WWW HTTP2 protocol allows the media type and encoding of a node to be determined through a separate interaction with the server.
クライアント/サーバプロトコルの1つの不可欠の能力がそれをダウンロードする前にクライアントがノード(そして、利用可能なencodingsのリスト)のタイプを決心する能力です。 WAISとゴーファーはそれぞれ結果セットとメニューのこの情報を移します。 WWWクライアントは現在、目標ノードのURLを分析するか、または<IMG>タグの発生でこの情報を決定します。 新しいWWW HTTP2プロトコルは、ノードのメディアタイプとコード化がサーバとの別々の相互作用で決定するのを許容します。
The GWW systems all use different methods for expressing type and encoding. WAIS does not distinguish the encoding from the media type. WWW is moving to the MIME type/encoding system. Gopher does not distinguish type and encoding, but Gopher+ does, and is also moving to the MIME type/encoding system.
GWWシステムはすべて、タイプとコード化を言い表すのに異なったメソッドを使用します。 WAISはメディアタイプとコード化を区別しません。 WWWはMIMEの種類/コード化システムに移行しています。 ゴーファーがタイプとコード化を区別しませんが、ゴーファー+も、MIMEの種類/コード化システムにして、また、感動的です。
Hyperlinks
ハイパーリンク
Only the WWW system has hyperlinks. Source anchors may be text, images, or points within an image. Target anchors may be entire nodes of any media type, or points within (with HTTP2, portions of) text nodes.
WWWシステムだけには、ハイパーリンクがあります。 ソースのアンカーは、イメージの中のテキスト、イメージ、またはポイントであるかもしれません。 目標がどんなメディアの全体のノードもタイプ、またはポイントであったかもしれないなら中に据えつける、(HTTP2、部分、)、テキストノード。
Gopher+ could potentially be enhanced to include hyperlinks, but there seems to be no development effort going towards this - those who need hyperlinking are using WWW.
これに向かう開発努力は全くあるように思えません--ハイパーリンクを含むように潜在的にゴーファー+を高めることができましたが、ハイパーリンクする必要がある人がWWWを使用しています。
Adie [Page 43] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[43ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Gopher menus can be constructed to allow alternative views of gopherspace. For instance, a geographically-organised menu tree of gopherspace is in place, but a parallel subject-based menu tree could be added as an alternative way of access to the same data. (There are in fact moves to set this up.) Since WWW offers a superset of Gopher functionality, these comments also apply to the Web. In fact, the Web already has a rudimentary subject tree.
gopherspaceの代替の視点を許容するためにゴーファーメニューを構成できます。 例えば、gopherspaceの地理的に組織化されたメニュー木が適所にありますが、同じデータへのアクセスの代替の方法として平行な対象ベースのメニュー木を加えることができました。 (これをセットアップするために、事実上移動があります。) WWWがゴーファーの機能性のスーパーセットを提供するので、また、これらのコメントはウェブに適用されます。 事実上、ウェブには、初歩的な対象の木が既にあります。
In both Gopher and WWW, non-textual data may be used in different information structures without having to maintain more than one copy.
ゴーファーとWWWの両方では、コピー1部以上を維持する必要はなくて、非原文のデータは異なった情報構造で使用されるかもしれません。
Presentation
プレゼンテーション
There is little support in GWW for controlling the presentation of non-text data.
サポートが非テキストデータのプレゼンテーションを制御するためのGWWにほとんどありません。
o Backdrops are not supported by GWW.
o 背景はGWWによってサポートされません。
o Buttons are supported in a limited way - typically, a node
is retrieved by clicking on a highlighted text phrase, or on
an entry in a list. In XMosaic, bitmap images can be used
as buttons. However, there is no support for different
styles of button. Client software may have generic
navigation buttons (e.g., "Back", "Next", "Home") which are
always available and don't form part of a node.
o ボタンは限られた方法で支えられます--通常、ノードは強調されたテキスト句をクリックするか、またはリストにおけるエントリーのときに検索されます。 XMosaicでは、ボタンとしてビットマップイメージを使用できます。 しかしながら、異なったスタイルのボタンのサポートが全くありません。 クライアントソフトウェアには、ジェネリックナビゲーション・ボタン(例えば、「逆」、そして、「次」の「ホーム」)があるかもしれません(いつも利用可能であり、ノードの一部を形成しません)。
o Synchronisation in space is not supported by GWW, except
that WWW supports contextual synchronisation of images using
the <IMG> tag.
o WWWが<IMG>タグを使用することでイメージの文脈上の連動をサポートする以外に、スペースでの連動はGWWによってサポートされません。
o Synchronisation in time is not supported by GWW.
o 時間内にの連動はGWWによってサポートされません。
Searching
探すこと
WAIS supports keyword searching, and is very well suited for that task. The Gopher+ protocol could potentially support multimedia database querying applications through the ASK attribute, but there is as yet no server implementation which supports such database applications. In the WWW project, there are ongoing discussions on how best to extend HTML to cope with database query applications - an <INPUT> tag has been suggested - but no consensus has yet emerged.
WAISはキーワードの探すことをサポートして、そのタスクに非常によく合っています。 ゴーファー+プロトコルは、マルチメディアデータベース質問がASK属性を通したアプリケーションであると潜在的にサポートするかもしれませんが、まだ、そのようなデータベースアプリケーションをサポートするサーバ実装が全くありません。 WWWプロジェクトには、データベース質問アプリケーションに対処するためにHTMLを最もよく広げる方法の現在行われている議論がありますが(<INPUT>タグは示されました)、コンセンサスは全くまだ現れていません。
Both Gopher and WWW can make use of WAIS-type keyword searching: either by incorporating WAIS code into the server (enabling WAIS index files to be searched); or through WAIS gateways, which run searches on remote WAIS servers in response to queries from non-WAIS clients.
ゴーファーとWWWの両方がWAIS-タイプキーワードの探すことを利用できます: どちらかサーバ(WAIS索引ファイルが捜されるのを可能にする)にWAISコードを組み入れることによって。 または、どれが稼働しているかは非WAISクライアントからの質問に対応してリモートWAISサーバでWAISゲートウェイを通して、探されます。
Adie [Page 44] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[44ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Interaction
相互作用
XMosaic allows users to make text (or on some platforms, audio) annotations to any text node. The annotations appear at the end of the text display.. They are held locally - other users of the node do not see the annotations (but a recently added facility allows globally-visible annotations held on an "annotation server"). Text annotations may include hyperlinks to other nodes (provided the user knows how to use HTML). Other clients do not provide such facilities.
XMosaicはユーザにテキスト(またはいくつかのプラットホーム、オーディオに関して)注釈をどんなテキストノードにもさせます。 注釈はテキストディスプレイの終わりに現れます。 それらは局所的に保持されます--ノードの他のユーザは注釈を見ません(最近加えられた施設は「注釈サーバ」に保持されたグローバルに目に見える注釈を許容します)。 注釈が含むかもしれないテキストは他のノードにハイパーリンクします(ユーザがHTMLを使用する方法を知っているなら)。 他のクライアントはそのような施設を提供しません。
There is a move to add an "email" address notation to URL. This would allow WWW client software to invoke a mail program when a user selects an anchor with such a URL.
「メール」アドレス記法をURLに追加するために、移動があります。 ユーザがそのようなURLでアンカーを選ぶとき、これで、WWWクライアントソフトウェアはメールプログラムを呼び出すことができるでしょう。
There are plans to allow WWW users to delineate a rectangular area of interest within an image for use in an HTTP request.
WWWユーザがHTTP要求における使用のためのイメージの中で興味がある長方形エリアを図で表わすのを許容する計画があります。
There is no support in GWW clients for interacting with sequences of images in the way described in section 2.3.6.
サポートが全くセクション2.3.6で述べられた方法でイメージの系列と対話するためのGWWクライアントにありません。
Quality of Service
サービスの質
The user expectations for responsiveness mentioned in section 2.3.7 are difficult to meet with currently-deployed wide-area network (or even LAN) technology, particularly for voluminous multimedia data. None of the GWW systems currently exploit the emerging isochronous data transfer capabilities of protocols such as RTP and technologies such as ATM. None of them make serious attempts to alleviate the problem in other ways (except for WWW, which defines some mechanisms in HTTP2 for format negotiation based on size and available bandwidth considerations).
反応性が、.7はあうのが難しいとセクション2.3で言及したので、ユーザ期待は現在広域ネットワーク(または、LANさえ)技術を配布しました、特に多量のマルチメディアデータのために。 GWWシステムのいずれも現在、RTPなどのプロトコルとATMなどの技術の現れている同一時間のデータ転送能力を開発しません。 それらのいずれも他の方法(サイズに基づく形式交渉と利用可能な帯域幅問題のためにHTTP2のいくつかのメカニズムを定義するWWWを除いた)で問題を軽減する重大な試みをしません。
Management
管理
The following table shows the support for three key management facilities in the GWW systems. The first two facilities require support in the client/server protocol, the third requires support in the server, but depends on authentication being available.
以下のテーブルはGWWシステムの3つのかぎ管理施設のサポートを示しています。最初の2つの施設がクライアント/サーバプロトコルで支持を要して、3番目は、サーバで支持を要しますが、利用可能な認証によります。
Gopher WAIS WWW
ゴーファーWAIS WWW
Access control No No1 Yes, in
and HTTP2
authentication
コントロールノーNo1にアクセスしてください、はい、コネとHTTP2認証
Adie [Page 45] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[45ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Charging support No No Yes, in
HTTP2
HTTP2でいいえ、いいえ、はいとサポートに宣言します。
Monitoring for No No No
statistical and
assessment
purposes
いいえノー統計的、そして、査定目的でないモニター
Note:
以下に注意してください。
1. "Access-control-facility" is a feature of Z39.50 which is not used by the current WAIS implementations.
1. 「アクセス制御機能」は現在のWAIS実装によって使用されないZ39.50の特徴です。
Scripting Requirements
要件に原稿を書きます。
None of the GWW systems have facilities for the execution of scripts by the client, because of security issues (it would be too easy for a malicious "trojan" script to be executed). Gopher and WWW servers have the ability for a UNIX script to be run by the server, with the script output returned to the client. Scripting as understood in the context of stand-alone multimedia applications does not exist in GWW.
GWWシステムのいずれにはも、クライアントによるスクリプトの実行のための施設がありません、安全保障問題のために(悪意がある"trojan"スクリプトが作成されるのは、簡単過ぎるでしょう)。 ゴーファーとWWWサーバには、UNIXスクリプトがサーバによって実行される能力があります、スクリプト出力がクライアントに返されている状態で。 スタンドアロンのマルチメディア応用の文脈で理解されているスクリプティングはGWWに存在していません。
Bytestream Format
Bytestream形式
None of the three GWW systems use a bytestream format for interchanging collections of material. There has been some talk about setting up a system akin to the "Trickle" mail server, for retrieving single document nodes from GWW using mail. Such a system has been implemented for WWW.
3台のGWWシステムのいずれも、材料の収集を交換するのにbytestream形式を使用しません。 「細流」メールサーバと同様のシステムをセットアップすることに関する何らかの話がありました、メールを使用することでGWWからのただ一つのドキュメントノードを検索するために。 そのようなシステムはWWWのために導入されました。
Authoring tools
オーサリングツール
Gopher is sufficiently simple to set up that no special authoring tools are required. WAIS requires only an indexing program (as discussed in section 3.2) for preparing material for publication.
ゴーファーはどんな特別なオーサリングツールも上ではありませんが、必要であることで、設定するのは十分簡単です。 WAISは、公表のために材料を準備するためにインデックスプログラムだけを必要とします(セクション3.2で議論するように)。
WWW, because it uses a sophisticated authoring language (HTML), benefits from the availability of authoring tools. There are HTML editors for UNIX (using the tk toolkit) and the NeXT system. There are no authoring tools designed specifically for exploiting the multimedia capabilities of WWW, mainly because these capabilities are still evolving.
精巧な著者言語(HTML)を使用するので、WWWはオーサリングツールの有用性の利益を得ます。 UNIX(tkツールキットを使用する)とNeXTシステムのためのHTMLエディタがあります。 特にWWWのマルチメディア能力を開発するように設計されたオーサリングツールが全くありません、主にこれらの能力がまだ発展しているので。
Adie [Page 46] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[46ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
4. Research
4. 研究
This section describes some current research projects in the area of distributed hypermedia information systems.
このセクションは分配されたハイパーメディアインフォメーションシステムの領域のいくつかの現在の研究計画について説明します。
4.1. Hyper-G
4.1. 超-G
Hyper-G [10] is an ambitious distributed hypermedia research project at a number of institutes of the IIG (Institutes for Information- Processing Graz), the Computing and Information Services Centre of the Graz University of Technology, and the Austrian Computer Society. It is funded by the Austrian Ministry of Science. It combines concepts of hypermedia, information retrieval systems and documentation systems with aspects of communication and collaboration, and computer-supported teaching and learning.
超-G[10]はTechnologyのグラーツ大学のIIG(情報Processingグラーツの研究所)の多くの研究所、Computing、および情報Services Centreの野心満々の分配されたハイパーメディア研究計画と、オーストリアのコンピュータSocietyです。 それはScienceのオーストリアのMinistryによって資金を供給されます。 それはコミュニケーションと共同の局面、コンピュータでサポートしている教育、および学習にハイパーメディア、情報検索システム、およびドキュメンテーション・システムの概念を結合します。
Unlike WWW, Hyper-G supports bi-directional links. This enables users to see which other documents reference the one they are using, and also allows the system to avoid dangling pointers when a linkedto document is deleted. Another difference from WWW is that links are kept separately from their source and target nodes, to allow easy linking of read-only documents and for ease of link maintenance. In addition to manually defined links, Hyper-G supports automatic static and dynamic (i.e., view-time) generation and maintenance of links.
WWWと異なって、Hyper-Gは双方向のリンクを支えます。 これは、ユーザが、それらが使用していて、またlinkedtoドキュメントであるときに、指針をちらつかせるのを避けるのをシステムを許容するものがどの他のドキュメント参照であるかを削除されていた状態で考えるのを可能にします。 WWWからの別の違いはリンクがドキュメントとリンクメインテナンスの容易さのための書き込み禁止の簡単なリンクを許すために別々に彼らのソースと目標ノードから妨げられるということです。 手動で定義されたリンクに加えて、Hyper-Gはリンクの自動静的でダイナミックな(すなわち、視点時間)世代とメインテナンスをサポートします。
Hyper-G has a concept of generic "structures" - an additional layer of relationships imposed on (and orthogonal to) the web of documents and links. A document can be part of more than one structure, and structures may be hierarchically related. Types of structure include:
超-Gには、ジェネリック「構造」の概念があります--追加層の関係がでしゃばった、オン、そして、(直交する)、ドキュメントとリンクのウェブ。 ドキュメントは1つ以上の構造の一部であるかもしれません、そして、構造は階層的に関係づけられるかもしれません。 構造のタイプは:
o "Clusters" are a set of documents which are all
presentedtogether.
o 「クラスタ」はすべてpresentedtogetherである1セットのドキュメントです。
o "Collections" are unordered sets of documents or other
structures, and can be used as query domains or to construct
gopher-like menus.
o 「収集」は、ドキュメントか他の順不同の構造であり、リスのようなメニューについてドメインか構造物に質問するとき、使用できます。
o "Paths" are ordered sets of documents or structures, which
must be visited sequentially.
o 「経路」は、順序集合のドキュメントか構造です。(その構造を連続して訪問しなければなりません)。
One application of the structure concept is the provision of "guided tours" through the information space.
構造概念の1つのアプリケーションは情報スペースを通した「ガイド付きツアー」の支給です。
In addition to hypernavigation, the collection hierarchy and guided tours, another strategy for interaction with the system is the use of database queries. Two kinds of query are supported: keyword searching in a user-defined list of databases; and collection
「超-ナビゲーション」、収集階層構造、およびガイド付きツアーに加えて、システムとの相互作用のための別の戦略はデータベース質問の使用です。 2種類の質問はサポートされます: データベースのユーザによって定義されたリストにおけるキーワードの探すこと。 そして、収集
Adie [Page 47] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[47ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
specific form-filling queries. In the latter case, the answer to the query may appear dynamically as the form is filled out.
特定の用紙記入質問。 後者の場合では、書類が書き込まれるとき、質問の答えはダイナミックに現れるかもしれません。
Four modes of user identification are supported: "identified", where a userid is publicly associated through name and address information with a particular individual; "semi-identified", where a userid is associated by the system with an individual, but the user is only known to other users through a pseudonym; "anonymously identified", where the userid is not associated by the system with any individual; and "anonymous", where there is no userid (or a generic userid such as "guest"). Possible operations in the system depend on the user's mode of identification. Users may access the system in any desired mode, and switch to other modes only when necessary.
ユーザ登録名の4つのモードがサポートされます: ユーザIDが名前とアドレス情報を通して公的に特定の個人に関連づけられるところで「特定されます」。 「準特定されてい」て、個人とのシステム、しかし、ユーザは匿名を通してユーザIDによって交際されるところで他のユーザにとって知られているだけです。 ユーザIDがシステムによってどんな個人にも関連づけられないところで「匿名で特定されます」。 そして、「匿名であり」、そこのどこがユーザIDでないか(または、「ゲスト」などのジェネリックユーザID)。 システムにおける可能な操作はユーザの識別の方法に依存します。 必要であるときにだけ、ユーザは、どんな必要なモードでもシステムにアクセスして、他のモードに切り替わるかもしれません。
Hyper-G contains specific support for multilingual documents and document clusters. Users may specify an ordered list of preferred languages, for instance. There are plans to experiment with automatic translation programs.
超-Gは多言語ドキュメントとドキュメントクラスタの特定のサポートを含んでいます。 ユーザは例えば、都合のよい言語の規則正しいリストを指定するかもしれません。 自動翻訳プログラムを実験する計画があります。
Integration of other, external, systems such as WWW into Hyper-G in a seamless manner is possible.
シームレスの方法によるHyper-GへのWWWなどの他の、そして、外部のシステムの統合は可能です。
Hyper-G is in use as a CWIS within Graz Technical University. Client software is available for UNIX workstations from DEC, HP, SGI, and SUN. The system is still in an experimental state, but it has been used by about 200 students as part of a course on the social impact of information technology.
超-GはCWISとしてグラーツTechnical大学の中で使用中です。 クライアントソフトウェアは12月からのUnixワークステーションに利用可能です、HP、SGI、そして、日曜日に、システムがまだ実験状態にあります、しかし、それが情報技術の社会的な影響のコースの一部としておよそ200人の学生によって使用されました。
4.2. Microcosm
4.2. 小宇宙
Microcosm [11] is an open hypermedia system developed at the University of Southampton. It is implemented on the PC under MS Windows, and versions for the Apple Macintosh and for UNIX with X are under development.
小宇宙[11]はサウサンプトン大学で開発された開いているハイパーメディアシステムです。 それはMS Windowsの下のPCの上で実装されます、そして、アップルマッキントッシュとXがあるUNIXのためのバージョンは開発中です。
Microcosm consists of a number of autonomous processes which communicate with each other by a message-passing system. Information about hyperlinks between documents is stored in a link database, or "linkbase", and is not stored in the documents themselves. This has the advantages that:
小宇宙はメッセージ・パッシングシステムで互いにコミュニケートする多くの自治のプロセスから成ります。 ドキュメントの間のハイパーリンクに関する情報は、リンクデータベース、または"linkbase"に保存されて、ドキュメント自体に保存されません。 これには利点がある、それ:
o Links to and from read-only documents (perhaps stored on CD-
ROM) are possible.
o ドキュメントと書き込み禁止ドキュメント(恐らくCD ROMの上に保存される)からのリンクは可能です。
o Documents need undergo no conversion process to be imported
into the system - they can still be viewed and edited using
the original application which created them, without the
link information getting in the way.
o ドキュメントはシステムにインポートされるために変換の過程を全く経る必要はありません--それらを作成した原出願を使用することでまだそれらを見て、編集できます、リンク情報に邪魔をしないで。
Adie [Page 48] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[48ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
o It is as easy to establish links to and from non-text
documents as text documents.
o それはドキュメントと非テキストドキュメントからのテキストが記録するのと同じくらい設立しやすいリンクです。
In Microcosm, the user interacts with a "viewer" program for a particular media type. Such programs may be specifically written for use with Microcosm (about 10 such viewers have been written for a number of common media types and encodings); or they may be a program adapted for use with Microcosm (the programmability of Microsoft Word for Windows has allowed it to be so adapted); or it may even be a program with no knowledge of Microcosm.
Microcosmでは、ユーザは特定のメディアタイプのために「ビューアー」プログラムと対話します。 そのようなプログラムはMicrocosmとの使用のために明確に書かれているかもしれません(そのようなおよそ10人のビューアーが多くの一般的なメディアタイプとencodingsのために書かれています)。 または、それらはMicrocosmとの使用のために適合させられたプログラムであるかもしれません(Windowsのためのマイクロソフト・ワードのプログラマビリティは、それがそのように適合させられるのを許容しました)。 または、それはMicrocosmに関する知識がなければプログラムでさえあるかもしれません。
The user selects an object (e.g., a piece of text) in the viewer, and requests Microcosm to perform an action with the object - typically to follow a link to another document. This may involve executing another viewer to display the target document.
ユーザは、別のドキュメントへのリンクに続くように通常ビューアーでオブジェクト(例えば、1つのテキスト)を選択して、オブジェクトで動作を実行するようMicrocosmに要求します。 これは、目標ドキュメントを表示するために別のビューアーを処刑することを伴うかもしれません。
Microcosm link source anchors may be specific (denoting a unique point in a particular document), local (denoting any occurrence of a particular object in a particular document) or generic (denoting any occurrence of an object in any document). Target anchors may specify specific objects within a document. Other link styles are textretrieval links (looking up a full-text index , as WAIS does), and relevance links to a set of documents using similar vocabulary to the source document (again, similar to WAIS's relevance feedback).
小宇宙リンクソースのアンカーが特定であるかもしれなく(特定のドキュメントのユニークなポイントを指示します)、ローカルは、(特定のドキュメントにおける、特定のオブジェクトのどんな発生も指示します)かジェネリック(どんなドキュメントでも、オブジェクトのどんな発生も指示する)です。 目標アンカーはドキュメントの中に特定のオブジェクトを指定するかもしれません。 他のリンクスタイルがtextretrievalリンク(WAISが調べるように全文インデックスを調べる)と、同様のボキャブラリーをソースドキュメントに使用する1セットのドキュメントへの関連性リンクである、(再び、WAISの関連フィードバックと同様である、)
Links may be created by readers as well as by authors. Dynamically computed links may be added to the permanent linkbase for later use. A history of link traversal is maintained, and "guided tours" may be established through the system which allow the reader to stray from and return to the tour.
リンクは読者と作者によって作成されるかもしれません。 ダイナミックに計算されたリンクは後の使用のために永久的なlinkbaseに加えられるかもしれません。 リンク縦断の歴史は維持されます、そして、「ガイド付きツアー」はシステムを通して設立されるかもしれません(読者からツアーにはぐれて、戻らせます)。
Microcosm viewers operate by sending messages to the Microcosm system. In MS Windows, these messages are transferred using DDE (Dynamic Data Exchange); in the Apple Macintosh version Apple Events are used, and sockets are used on UNIX. For viewers which are not Microcosm aware, the user must transfer the selected object to the system clipboard before being able to follow a link from it.
小宇宙ビューアーは、Microcosmシステムにメッセージを送ることによって、働いています。 MS Windowsでは、これらのメッセージはDDE(ダイナミックなData Exchange)を使用することでわたっています。 アップルマッキントッシュバージョンでは、アップルEventsは使用されています、そして、ソケットはUNIXの上で使用されます。 Microcosm意識していないビューアーに関しては、それからリンクに続くことができる前に、ユーザは選択されたオブジェクトをシステムクリップボードに移さなければなりません。
Networking support in Microcosm is currently under development. Components of Microcosm may be distributed to multiple machines there is not necessarily a concept of "client" and "server".
Microcosmでサポートをネットワークでつなぐのは現在、開発中です。 Microcosmの部品は必ず「クライアント」と「サーバ」の概念ではなく、ある複数のマシンに分配されるかもしれません。
There are problems with the Microcosm approach, common to systems which maintain link information separately from documents, and which use external viewers.
Microcosmアプローチに関する問題があります、別々にドキュメントからリンク情報を維持して、外部ビューワを使用するシステムに共通です。
Adie [Page 49] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[49ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
o Documents move and change, thus invalidating links.
Microcosm datestamps links to help to detect (but not
correct) such problems.
o ドキュメントは移行して、変化して、その結果、リンクを無効にします。 小宇宙datestampsが検出する助けにリンクする、(正しくない)、そのような問題。
o It is not always clear what links are available to be
followed from a document, since the viewer program is
unaware of the contents of the linkbase.
o ドキュメントから続かれるのはどんなリンクが利用可能であるかがいつも明確であるというわけではありません、ビューアープログラムがlinkbaseのコンテンツに気づかないので。
o It is not always possible to indicate the object within a
document which is the target anchor of a link. Many viewers
automatically show the start of the document (e.g., a word
processor), or perhaps the entire document (e.g., a picture
viewer). The user has no way of knowing which part of the
target document the link just followed points to.
o リンクの目標アンカーであるドキュメントの中にオブジェクトを示すのはいつも可能であるというわけではありません。 多くのビューアーが自動的に、ドキュメントの始まり(例えば、ワードプロセッサ)、または恐らく全体のドキュメント(例えば、画像ビューアー)を見せています。 ユーザには、ただ続かれるリンクが目標ドキュメントのどの部分に指すかを知る方法が全くありません。
Microcosm may be viewed as an integrating hypermedia framework - a layer on top of a range of existing applications which enables relationships between different documents to be established.
小宇宙は統合しているハイパーメディアフレームワークとして見なされるかもしれません--異なったドキュメントの間の関係が確立されるのを可能にするさまざまな既存のアプリケーションの上の層。
Microcosm is currently being "commercialised".
小宇宙は現在、「商業化されています」。
4.3. AthenaMuse 2
4.3. AthenaMuse2
AthenaMuse 2 (AM2) is an ambitious distributed hypermedia authoring and presentation system under development by the AthenaMuse Software Consortium based at MIT. It is based on the earlier AM1 system developed as part of MIT's Project Athena. The first version of AM2 is scheduled for January 1994, and will be "pre-commercial software", with a fully-commercialised version due about 6 months later. Both the educational and commercial sectors are the intended market. The system will initially be based on X and UNIX workstations, but PC/Windows will also be supported in a second phase. Apple Macintosh support has a lower priority.
AthenaMuse2(AM2)はMITに基づくAthenaMuse Software Consortiumによる開発中の野心満々の分配されたハイパーメディアオーサリングとプレゼンテーションシステムです。 それはMITのProjectアテーナーの一部として開発された以前のAM1システムに基づいています。 AM2の最初のバージョンは、1994年1月に予定されて、「プレ商用ソフトウェア」でしょう、およそ6カ月後に予定されている完全に商業化しているバージョンで。 両方の教育的で商業のセクターは意図している市場です。 システムは初めは、XとUnixワークステーションに基づくでしょうが、また、PC/Windowsは2番目のフェーズでサポートされるでしょう。 アップルのマッキントッシュサポートには、低優先度があります。
The specifications of AM2 are available in [12]. Some of the key points are:
AM2の仕様は[12]で利用可能です。 要所のいくつかは以下の通りです。
o AM2 will support import and export of application from and
tostandard forms. The project is watching standards such as
HyTime, MHEG and ODA.
o サポートがアプリケーションをインポートして、エクスポートするAM2意志とtostandardは形成されます。プロジェクトはHyTimeや、MHEGやODAなどの規格を見ています。
o Several "application themes", or frequently-occurring
collections of functionality, are viewed as useful. These
are as follows:
o 数個の「アプリケーションテーマ」、または機能性の頻繁に起こっている収集が役に立つと見なされます。 これらは以下の通りです:
Application Theme Interactive?
Presentation of multimedia data No
Exploration of a rich multimedia Yes
アプリケーションテーマインタラクティブ? プレゼンテーション、豊かなマルチメディアのマルチメディアデータノーExploration、はい。
Adie [Page 50] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[50ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
environment
Simulation of a real-world scenario Partially
Communication of real-time No
information to the user
Authoring Yes
Annotation of material Yes
ユーザAuthoringへのリアルタイムのいいえ情報の本当の世界シナリオPartially Communicationの環境Simulation、はい、材料のAnnotation、はい。
o "Interface templates" allow a multimedia application to make
use of a common format for presenting a range of content.
This is similar to the "backdrop" concept mentioned in
section 2.3.4.
o 「インタフェーステンプレート」で、マルチメディア応用はさまざまな内容を提示するための一般的な形式を利用できます。 これはセクション2.3.4で言及した「背景」概念と同様です。
o A range of link types will be supported.
o さまざまなリンク型がサポートされるでしょう。
o Media content editors and interface/application editors for
structuring will be provided. A third class of editor, the
"hypermedia notebook", will allow readers to excerpt and
annotate media from AM2 applications.
o 構造のためのメディアコンテンツ編集者とインタフェース/アプリケーションエディタを提供するでしょう。 「ハイパーメディアノート」という3番目のクラスのエディタは、読者にAM2アプリケーションからメディアを抜粋して、注釈させるでしょう。
The project is developing multimedia network services, including the transmission of digital video, using a client-server paradigm.
プロジェクトは、クライアント/サーバパラダイムを使用することでデジタルビデオのトランスミッションを含むマルチメディアネットワーク・サービスを開発しています。
4.4. CEC Research Programmes
4.4. CEC研究プログラム
Some of the research programmes sponsored by the Commission for the European Community (CEC) contain apparently relevant projects. [1] has further details of some of these projects.
ヨーロッパ共同体(CEC)のために委員会によって後援された研究プログラムのいくつかが明らかに関連しているプロジェクトを含んでいます。 [1]には、これらのプロジェクトのいくつかの詳細があります。
RACE programme
RACEプログラム
The RACE programme is outlined in [13], which should be consulted for further information about the projects described below. The RACE programme targets the industrial, commercial and domestic sectors, and results are not necessarily directly applicable to the research and academic community. RACE project numbers are given.
RACEプログラムは[13]に概説されています。([13]は以下で説明されたプロジェクトに関する詳細のために相談されるべきです)。 RACEプログラムは産業の、そして、商業の、そして、国内のセクターを狙います、そして、結果は必ず直接研究と学界に適切ではありません。 RACEプロジェクト番号を与えます。
RACE Phase I projects, which have mostly completed:
RACE Phase Iは突出していて、完成されて、どれがほとんどそうしたか:
R1038 MCPR - Multimedia Communication, Processing and
Representation. This project developed a demonstrator
multimedia system with communications capability for travel
agents.
R1038 MCPR--マルチメディア通信、処理、および表現。 このプロジェクトはコミュニケーション能力でデモンストレーターマルチメディア・システムを旅行代理店に開発しました。
R1061 DIMPE - Distributed Integrated Multimedia Publishing
Environment. The project designed and implemented interim
services for compound document handling, and defined a
distributed publishing architecture.
R1061 DIMPE--環境を発行する分配された統合マルチメディア。 プロジェクトは、コンパウンドドキュメント取り扱いのための当座のサービスを設計して、実装して、分配された出版アーキテクチャを定義しました。
Adie [Page 51] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[51ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
R1078 European Museums Network. This project aimed to demonstrate
interactive navigation through a pool of multimedia museum
objects, using ISDN as the communications network.
R1078のヨーロッパの博物館ネットワーク。 通信網としてISDNを使用して、このプロジェクトは、マルチメディア博物館オブジェクトのプールを通って対話的なナビゲーションを示すことを目指しました。
RACE Phase II projects:
RACE Phase IIは突出しています:
R2008 EuroBridge.
R2008 EuroBridge。
Aims to demonstrate multi-point multimedia applications
running over DQDB, FDDI and ATM test networks.
DQDB、FDDI、およびATMをひくマルチポイントマルチメディア応用を実施説明する目的はネットワークをテストします。
R2043 RAMA - Remote Access to Museum Archives
R2043ラマ--博物館アーカイブへの遠隔アクセス
This project follows on from R1078.
これはR1078からの進行中の尾行を映し出します。
R2060 CIO - Coordination, Implementation and Operation of
Multimedia Services.
R2060 CIO--マルチメディアサービスのコーディネート、実装、および操作。
One aspect of this project is JVTOS - a "Joint Viewing and
Teleoperation Service". This aims to integrate standard
multimedia applications running on a range of heterogeneous
machines into a cooperative working environment, allowing
individuals to view and interact with multimedia data on
colleague's machines.
このプロジェクトの1つの局面がJVTOSです--「共同見るのと遠隔操作サービス。」 これは、さまざまな異種のマシンで協力的な作業環境に動きながら標準のマルチメディア応用を統合することを目指します、個人が同僚のマシンに関するマルチメディアデータと見て、対話するのを許容して。
ESPRIT Programme
エスプリプログラム
The ESPRIT research programme is outlined in [14], which should be consulted for further information about the projects listed below. ESPRIT project numbers are given.
ESPRIT研究プログラムは[14]に概説されています。([14]は以下に記載されたプロジェクトに関する詳細のために相談されるべきです)。 ESPRITプロジェクト番号を与えます。
28 MULTOS - A Multimedia Filing System
28MULTOS--マルチメディアファイリングシステム
This project, which ran from 1985 to 1990, developed a
client/server system for filing and retrieval of multimedia
documents using the ODA interchange format standard (ODIF).
このプロジェクト(1985年から1990まで経営していた)を、マルチメディアドキュメントのファイリングと検索のためにODA置き換え形式規格(ODIF)を使用することでクライアント/サーバーシステムを開発しました。
5252 HYTEA - HyperText Authoring
5252HYTEA--ハイパーテキストオーサリング
This project, which runs from 1991 to 1994, aims to develop
a set of authoring tools for large and complex hypermedia
applications.
このプロジェクト(1991年から1994まで経営している)を、大きくて複雑なハイパーメディアアプリケーションのための1セットのオーサリングツールを開発することを目指します。
5398 SHAPE - Second Generation Hypermedia Application Project
5398年の形--二世ハイパーメディアアプリケーションプロジェクト
This project is developing a portable software environment
comparable to a CASE tool intended to facilitate the
realisation of complex hypermedia applications.
このプロジェクトは複雑なハイパーメディアアプリケーションの現金化を容易にすることを意図するCASEツールに匹敵する携帯用のソフトウェア環境を開発しています。
Adie [Page 52] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[52ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
5633 HYTECH - Hypertextual and Hypermedial Technical
Documentation This project, which ran from 1990-1991, was to
assess the feasibility of hypermedia technology and to
devise needed extensions to it in order to support
applications dealing with technical documentation
management.
5633HYTECH--HypertextualとHypermedial Technical Documentation Thisプロジェクト(1990年から1991年までの間、経営していた)を、技術的な文書管理と取り引きするアプリケーションをサポートするためにハイパーメディア技術に関する実現の可能性を評価して、必要な拡大についてそれに工夫することになっていました。
6586 PEGASUS - Distributed Multimedia Operating System for the
1990s This project is aimed at the design of an operating
system architecture for scalable distributed multimedia
systems and the development of a validating prototype, the
design and implementation of a distributed complex-object
service and a global name service, the development of
mechanisms for the creation, communication and rendering of
fully digital multimedia documents in real time and in a
distributed fashion, and the design and implementation of an
application for the system: a digital TV director.
6586PEGASUS--1990年代のThisプロジェクトのための分配されたMultimedia Operating Systemはスケーラブルな分散型マルチメディアシステムのためのオペレーティングシステムアーキテクチャのデザインと有効にするプロトタイプの開発を目的とされます; 分配された複雑なオブジェクトサービスの、そして、グローバル名サービスの設計と実装、リアルタイムでの完全にデジタルのマルチメディアドキュメントの作成と、コミュニケーションとレンダリングと分配されたファッションにおける、メカニズムの開発、およびシステムのためのアプリケーションの設計と実装: デジタルテレビディレクター。
6606 IDOMENEUS - Information and Data on Open Media for Networks
of Users. This project, which started January 1993, brings
together workers in the database, information retrieval,
networking and hypermedia research communities in the
development of an "ultimate information machine". It "will
coordinate and improve European efforts in the development
of next-generation information environments capable of
maintaining and communicating a largely extended class of
information on an open set of media". Because of the close
match between the subject of the IDOMENEUS project and the
RARE WG-IMM, it is recommended that RARE establish a liaison
with this project.
6606IDOMENEUS--ユーザのネットワークのための開いているメディアに関する情報とデータ。 このプロジェクト(1993年1月に始まった)は「究極の情報マシン」の開発におけるデータベース、情報検索、ネットワーク、およびハイパーメディア研究団体に労働者を集めます。 それは「1つのオープン・セットのメディアの大幅に拡張しているクラスの情報を保守して、コミュニケートできる次世代環境情報の開発におけるヨーロッパの取り組みを調整して、改良するでしょう」。 IDOMENEUSプロジェクトの対象とRARE WG-IMMの間の互角の試合のために、RAREがこのプロジェクトとの連絡係を確立するのは、お勧めです。
4.5. Other
4.5. 他
Some other research projects of less immediate relevance are listed below. Some of these projects are described further in [1].
それほど即座でない関連性のある他の研究計画は以下に記載されています。 これらのプロジェクトのいくつかが[1]で、より詳しく説明されます。
o Xanadu is a project to develop an "open, social hypermedia"
distributed database server, incorporating CSCW features.
It has been in existance for many years and has been funded
by a number of companies. The current status of this
project is not known, and although iminent availability of
alpha-test versions has been announced more than once, no
software has been delivered.
o CSCW機能を取り入れて、ザナドゥは「開いていて、社会的なハイパーメディア」分散データベースサーバを開発するプロジェクトです。 それは、何年間もexistanceにあって、多くの会社によって資金を供給されました。 このプロジェクトの現在の状態は知られていません、そして、アルファテストバージョンのiminentの有用性は一度よりもう少し発表されましたが、ソフトウェアは全く提供されていません。
o CMIFed [15] is an editing and presentation environment for
portable hypermedia documents being developed at CWI,
Amsterdam, NL. It is based on the "Amsterdam Model" of
o CMIFed[15]はCWI、アムステルダムNLで開発される携帯用のハイパーメディアドキュメントのための編集とプレゼンテーション環境です。 それは「アムステルダムモデル」に基づいています。
Adie [Page 53] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[53ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
hypermedia [16], which is an extension of the Dexter
hypertext reference model incorporating "channels" for media
delivery and synchronisation constraints.
ハイパーメディア[16]。(そのハイパーメディアはメディア配送と連動規制のための「チャンネル」を取り入れているデクスターハイパーテキスト規範モデルの拡大です)。
o Deja Vu [17] is a proposed "intelligent" distributed
hypermedia application framework. It is intended as a
vehicle for research in the areas of: hypermedia systems,
object-oriented programming, distributed logic programming,
and intelligent information systems. Proposed techniques
for use in the Deja Vu framework include "inferential
links", defined automatically according to predefined rules.
A scripting language for use both by information providers
and users is planned. This project is at a very early
(proposal) stage, and as yet relatively little software has
been developed. Deja Vu is intended principally as a
research framework rather than as a service tool.
o Deja Vu[17]は提案された「知的な」分配されたハイパーメディアアプリケーションフレームワークです。 それは以下の領域での調査のための手段として意図します。 ハイパーメディアシステム(オブジェクト指向プログラミング)は論理プログラム、および知的な情報システムを広げました。Deja Vuフレームワークにおける使用のための提案されたテクニックは事前に定義された規則に従って自動的に定義された「推論に基づいているリンク」を含んでいます。 情報提供者とユーザによる使用のためにスクリプト言語は計画されています。 このプロジェクトは非常に早めの(提案)段階であります、そして、まだ比較的少ないソフトウェアが開発されました。 Deja Vuは主にサービスツールとしてというよりむしろ研究フレームワークとして意図します。
o Demon is a project at Bellcore, US, investigating the
network requirements of near-term residential multimedia
services. The project is designing and implementing an
experimental application which serves the needs of casual
multimedia users.
o 短期間の住宅のマルチメディアサービスのネットワーク要件を調査して、悪霊はBellcore、米国のプロジェクトです。 プロジェクトは、カジュアルなマルチメディアユーザの必要性に役立つ実験用アプリケーションを、設計して、実装しています。
o InfoNote is a distributed, multiuser hypermedia system from
Japan, implemented on a NEC EWS4800 running UNIX and X.
InfoNote has an editor which can create Japanese texts,
figures, and raster images. The same windows are used both
for editors and browsers. The functionality of the window
can be changed at any time if data is not write-protected.
o InfoNoteはNEC EWS4800の実行しているUNIXの上で実装された日本からの分配されたマルチユーザハイパーメディアシステムです、そして、X.InfoNoteには、和文、数字、およびラスター・イメージを作成できるエディタがいます。 同じ窓はエディタとブラウザに使用されます。 データをライト・プロテクトしないなら、いつでも、窓の機能性を変えることができます。
o MADE - Multimedia Application Demonstration Environment - is
a project at British Telecom's research laboratory which
centres on the use of the developing MHEG standard to access
a multimedia object server. The server platform is a Sun
SPARCstation with an object-oriented database package
(ONTOS). Audio, video, text and graphical media types are
covered. The University of Kent is working on a sub-
project: "Multi-user Indexing in a Distributed Multimedia
Database".
o MADE(マルチメディアApplication Demonstration Environment)は開発の使用のときにマルチメディア対象物サーバにアクセスするためにMHEG規格を集中させるブリティッシュ・テレコムの研究所のプロジェクトです。サーバプラットホームはオブジェクト指向データベースパッケージ(ONTOS)があるSun SPARCstationです。 オーディオ、ビデオ、テキスト、およびグラフィカルなメディアタイプは含まれています。 ケント大学はサブプロジェクトに取り組んでいます: 「分散型マルチメディアデータベースで索引をつけるマルチユーザ。」
o Zenith aimed to establish a set of principles to assist
designers and developers of object management systems
intended for distributed multimedia design environments.
The project implemented a prototype generalised multimedia
object management system.
o 天頂は、デザイナーを補助するために1セットの本質を確立することを目指しました、そして、オブジェクト管理システムの開発者は分散型マルチメディアのためにデザイン環境を意図しました。 プロトタイプであると実装されたプロジェクトはマルチメディア対象物マネージメントシステムを一般化しました。
Adie [Page 54] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[54ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
5. Standards
5. 規格
5.1. Structuring Standards
5.1. 規格を構造化します。
This section describes some of the important standards for providing hyperstructure to multimedia data.
このセクションはマルチメディアデータに「超-構造」を提供する重要な規格のいくつかについて説明します。
SGML
SGML
SGML (Standard Generalized Markup Language - ISO 8879) is a metalanguage for defining markup notations for text. SGML is used to write Document Type Definitions or DTDs, to which individual document instances must conform. It finds application in a wide and increasing range of text processing applications.
SGML(標準のGeneralized Markup Language--ISO8879)は、テキストのためにマーク付け記法を定義するためのメタ言語です。 SGMLは、Document Type DefinitionsかDTDを書くのに使用されます。(個々の文献インスタンスはDTDに従わなければなりません)。 それは広くて増加する範囲のテキスト処理アプリケーションにおける法則を見つけます。
The relevance of SGML to distributed hypermedia systems is surprisingly high, mainly because of the great expressive power of SGML, and its ability to handle non-textual data using "external entities" and "notations".
分配されたハイパーメディアシステムへのSGMLの関連性は驚くほど高いです、主にSGMLのかなりの表現力、および「外部実体」と「記法」を使用することで非原文のデータを扱うその性能のために。
o The World-Wide Web is an SGML application with its own DTD.
o WWWはそれ自身のDTDとのSGMLアプリケーションです。
o The important HyTime hypermedia structuring standard (see
below) is based on SGML.
o 規格(以下を見る)を構造化する重要なHyTimeハイパーメディアはSGMLに基づいています。
o The forthcoming MHEG hypermedia structuring standard (see
below) has an SGML encoding.
o SGMLがコード化されて、規格(以下を見る)を構造化する今度のMHEGハイパーメディアはそうしました。
o SGML has been used in research hypermedia systems - for
example Microcosm.
o SGMLは研究ハイパーメディアシステムで使用されました--例えば、Microcosm。
o SGML is used in some commercial hypermedia systems - for
example DynaText.
o SGMLはいくつかの市販のハイパーメディアシステムで使用されます--例えば、DynaText。
o SGML is of increasing importance for academic publishing
houses.
o SGMLは学術出版家に重要性を増強するものです。
It was interesting to note that at a recent (CEC-sponsored) workshop on Hypertext and Hypermedia standards, most of the speakers were conversant with and supportive of the use of SGML for such systems.
スピーカーの大部分がハイパーテキストとHypermedia規格に関する最近(CECで後援された)のワークショップでは、SGMLのそのようなシステムの使用を詳しくて、支持していたことに注意するのがおもしろかったです。
A related standard which may become important for SGML on networks is SDIF (SGML Data Interchange Format - ISO 9069). This standard specifies how an SGML document, which may exist in a number of separate files of different media types, may be encoded using ASN.1 into a single bytestream. The entity structure is preserved, so that the bytestream may be decoded by the recipient into the same set of files.
ネットワークでSGMLに重要になるかもしれない関連する規格はSDIF(SGML Data Interchange Format--ISO9069)です。 この規格はSGMLドキュメント(異なったメディアタイプの多くの別々のファイルに存在するかもしれない)が単一のbytestreamにASN.1を使用することでどうコード化されるかもしれないかを指定します。 実体構造は保存されます、受取人が同じセットのファイルの中にbytestreamを解読できるように。
Adie [Page 55] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[55ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
HyTime
HyTime
HyTime (Hypermedia/Time-Based Structuring Language) is a standardised infrastructure for the representation of integrated, open hypermedia documents. It was developed principally by ANSI committee X3V1.8M, and was subsequently adopted by ISO and published as ISO 10744.
HyTime(ベースのハイパーメディア/時間Structuring Language)は統合していて、開いているハイパーメディアドキュメントの表現のための標準化されたインフラストラクチャです。 それは、主にANSI委員会のX3V1.8Mによって開発されて、次に、ISOによって採用されて、ISO10744として発行されました。
HyTime is based on SGML. It is not itself an SGML DTD, but provides
constructs and guidelines ("architectural forms") for making DTDs for
describing Hypermedia documents. For instance, the Standard Music
Description Language (SMDL: ISO/IEC Committee Draft 10743) defines a
(meta-)DTD which is an application of HyTime. In fact, HyTime
started as an attempt to produce a markup scheme for music publishing
purposes.
HyTimeはSGMLに基づいています。 それは、Hypermediaについて説明するためのDTDをドキュメントにするのにそれ自体でSGML DTDではありませんが、構造物とガイドラインを提供します(「建築フォーム」)。 例えば、Standard Music記述Language(SMDL: ISO/IEC委員会草案10743)はHyTimeのアプリケーションである(メタ)DTDを定義します。 事実上、HyTimeは音楽出版目的のためのマーク付け体系を作成する試みを始めました。
HyTime specifies how certain concepts common to all hypermedia documents can be represented using SGML. These concepts include:
HyTimeはSGMLを使用することでどうすべてのハイパーメディアドキュメントに共通のある概念を表すことができるかを指定します。 これらの概念は:
o association of objects within documents with hyperlinks
o ハイパーリンクがあるドキュメントの中のオブジェクトの協会
o placement and interrelation of objects in space and time
o スペースと時間のオブジェクトのプレースメントと相互関係
o logical structure of the document
o ドキュメントの論理構造
o inclusion of non-textual data in the document
o ドキュメントでの非原文のデータの包含
An "object" in HyTime is part of a document, and is unrestricted in form - it may be video, audio, text, a program, graphics, etc. The terminology used in HyTime (and in this section) thus differs slightly from the terminology used in the rest of this report. A HyTime object corresponds roughly to a node as defined in section 1.2, and a HyTime document is a hyperdocument in the terminology of this report.
HyTimeにおける「オブジェクト」は、ドキュメントの一部であり、フォームで無制限です--それはビデオ、オーディオ、テキスト、プログラム、グラフィックスであるかもしれませんなど。 HyTime(そしてこのセクションで)にこのようにして使用される用語はこのレポートの残りに使用される用語と若干異なります。 HyTimeオブジェクトはセクション1.2で定義されるようにおよそノードに対応しています、そして、HyTimeドキュメントはこのレポートの用語の「超-ドキュメント」です。
HyTime consists of six modules, which are very briefly and selectively described below:
HyTimeは6つのモジュールから成ります:(モジュールは以下で非常に簡潔に選択的に説明されます)。
o Base module. This provides facilities required by other
modules, including a lexical model for describing element
contents; facilities for identifying policies for coping
with changes to a document, or traversing a link ("activity
tracking"); and the ability to define "container entities"
which can hold multiple data objects. This last was added
to the HyTime standard at a late stage, at the instigation
of Apple Computers Inc, as a "hook" for their Bento
specification [18].
o モジュールを基礎づけてください。 これは要素コンテンツについて説明するための語彙モデルを含む他のモジュールによって必要とされた施設を提供します。 対処するための方針を特定するための施設はドキュメント、またはリンクを横断するのに(「活動追跡」)変化します。 そして、複数のデータ・オブジェクトを持つことができる「コンテナ実体」を定義する能力。 これは最後に後期の標準のHyTimeに追加されました、アップルコンピュータIncの扇動のときに、それらのBento仕様[18]のための「フック」として。
Adie [Page 56] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[56ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
o Measurement module. This allows for an object to be located
in time and/or space (which HyTime treats equivalently), or
any other domain which can be represented by a finite
coordinate space, within a bounding box called an "event",
defined by a set of coordinate points. Coordinates may be
expressed in any units (predefined units include
femtoseconds, fortnights, millenia, angstroms, Northern feet
and lightyears!).
o 測定モジュール。 これは、オブジェクトが時間、そして/または、スペース(HyTimeが同等に扱う)、または有限コーディネートしているスペースで表すことができるいかなる他のドメインにも位置するのを許容します、1セットのコーディネートしている先によって定義された「イベント」と呼ばれる制限箱の中に。 座標はどんなユニットにも表されるかもしれません(事前に定義されたユニットはフェムト秒、2週間、millenia、オングストローム、北足、およびlightyears!を含んでいます)。
o Location Address module. In addition to the fundamental
ability of SGML to identify and refer to elements, this
module provides a special "named location address"
architectural form which can be used to refer indirectly to
data which spans elements, or which is located in external
entities. Data may also be addressed indirectly through the
use of "queries", which return addresses of objects within
some domain which have properties matching the query. A
"HyQ" notation is provided for defining the query.
o 位置のAddressモジュール。 SGMLが要素を特定して、示す基本的な能力に加えて、このモジュールは間接的に要素を測るデータを示すのに使用できるか、または外部実体で位置している特別な「命名された位置のアドレス」建築フォームを提供します。 また、データは間接的に「質問」、何らかのドメインの中の質問に合っている特性を持っているオブジェクトのどの返送先の使用で扱われるかもしれないか。 "HyQ"記法は、質問を定義しながら、備えられます。
o Hyperlinks module. Two basic types of hyperlink are
defined: the contextual link (clink) has two anchors, one of
which is embedded in a document to explicitly denote the
anchor location; and the independent link (ilink) which may
have more than two anchors, and which does not require the
anchors to be embedded in the document. ilinks thus allow
hyperlink information to be maintained separately from
document content.
o ハイパーリンクモジュール。 ハイパーリンクの2人の基本型が定義されます: 明らかにアンカー位置を指示するためにドキュメントに埋め込まれている(かちんという音)が1歳の2人のアンカーがいる文脈上のリンク。 そして、2人以上のアンカーがいるかもしれなくて、アンカーがその結果. 「不-インク」が、ハイパーリンク情報が別々にドキュメント内容から保守されるのを許容するドキュメントに埋め込まれているのを必要としない独立しているリンク(ilink)。
o Scheduling module. This specifies how events in a source
finite coordinate space (FCS) are to be mapped onto a target
FCS. For instance, events on a time axis could be projected
onto a spatial axis for graphical display purposes, or a
"virtual" time axis as used in music could be projected onto
a physical time axis.
o モジュールの計画をします。 これは目標FCSに写像されるソースの有限コーディネートしているスペース(FCS)のイベントがことである方法を指定します。 例えば、グラフィカルなディスプレイ目的のための空間的な軸に時間軸の上のイベントを映し出すことができましたか、または音楽で使用される「仮想」の時間軸は物理的な時間軸に映し出すことができました。
o Rendition module. This allows for individual objects to be
modified before rendition, in an object-specific way. One
example is modification of colours in image so that it can
be displayed using the currently-selected colour map on a
graphics terminal, or changing the volume of an audio
channel according to a user's requirements.
o 表現モジュール。 これは、個々のオブジェクトが表現の前にオブジェクト特有の方法で変更されるのを許容します。 1つの例は、イメージで、グラフィックス端末で現在選択された色の地図を使用するか、またはユーザの要件に従って音声チャンネルの量を変えながらそれを表示できるための色の変更です。
It is not envisaged that a hypermedia application would need to use the entire range of HyTime facilities. An application designer is able to choose appropriate HyTime architectural forms, and to add application-specific constraints to them. The designer may also of course use non-HyTime SGML elements and attributes, but these aspects of the application can't be understood by a "HyTime engine". Even in
ハイパーメディアアプリケーションが、全体の範囲のHyTime施設を使用する必要であるのが考えられません。 アプリケーション設計者は、適切なHyTime建築フォームを選んで、アプリケーション特有の規制をそれらに加えることができます。 また、デザイナーはもちろん非HyTime SGML要素と属性を使用するかもしれませんが、「HyTimeエンジン」にアプリケーションのこれらの局面を解釈できません。 同等
Adie [Page 57] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[57ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
the absence of a HyTime engine, the HyTime architectural forms provide a useful base of ideas from which a hypermedia system designer may wish to work.
HyTimeエンジンの不在、HyTimeの建築フォームはハイパーメディアシステム設計者が働きたがっているかもしれない考えの役に立つベースを供給します。
The role of a HyTime engine is not specified in the standard, but essentially it is a (sub)program which recognises HyTime constructs in document instances and performs application-independent processing on them. For instance, it could interact with multimedia network servers to resolve and access hyperlink anchors. A commercial HyTime engine (HyMinder) is under development by TechnoTeacher in the US, and the Interactive Multimedia Group at the University of Massachusetts - Lowell (contact lrutledg@cs.ulowell.edu) is also working on a HyTime engine (HyOctane).
HyTimeエンジンの役割は規格では指定されませんが、本質的にはそれはドキュメントインスタンスでHyTime構造物を認識して、アプリケーションから独立している処理をそれらに実行する(潜水艦)プログラムです。 例えば、それは決議するマルチメディアネットワークサーバとアクセスハイパーリンクアンカーと対話するかもしれません。 市販のHyTimeエンジン(HyMinder)は米国のTechnoTeacher、およびマサチューセッツ大学のInteractive Multimedia Groupによる開発中です--また、ローウェル(接触 lrutledg@cs.ulowell.edu )はHyTimeエンジン(HyOctane)に働いています。
The Davenport group (a loose consortium of interested companies and individuals) is producing a series of standards on hypermedia which further constrain the HyTime architectural forms. One example is the SOFABED module [19], which standardises the representation of certain kinds of navigational information - tables of contents, indexes and glossaries.
ハイパーメディアの一連の規格を生産して、どれがさらに建築していた状態でHyTimeを抑制するかは形成されます。ダヴェンポートグループ(関心がある会社と個人のゆるい共同体)は1つの例が、ある種類のナビゲーション上の情報の表現を標準化するSOFABEDモジュール[19]です--コンテンツ、インデックス、および用語集のテーブルということです。
HyTime was envisaged as an interchange format rather than as a format for directly-executable hypermedia applications. It is therefore very expressive, but may be difficult to optimise for run-time efficiency.
HyTimeは直接実行可能なハイパーメディアアプリケーションのための形式としてというよりむしろ置き換え形式として考えられました。 したがって、非常に表現していますが、ランタイムのときに効率を最適化するのは、難しいかもしれません。
An attempt has been made [20] to adapt the hyperlink structure in WWW's existing HTML DTD to comply with HyTime's clink architectural form. This requires changes to WWW document instances as well as to browser software, and in the absence of any immediate benefit it has found little favour with the WWW community. However, it is possible that HTML2 will use some aspects of HyTime.
試みはHyTimeのかちんという音の建築フォームに従うためにWWWの既存のHTML DTDでハイパーリンク構造を適合させる人工の[20]です。 これはブラウザー・ソフトウェア、どんな即座の利益およびがないときまた、それが少ししかWWW共同体に喜ばないのが見つけられたWWWドキュメントインスタンスへの変化を必要とします。 しかしながら、HTML2がHyTimeのいくつかの局面を使用するのは、可能です。
It is recommended that any further RARE work on networked hypermedia should take account of the importance of SGML and HyTime.
ネットワークでつながれたハイパーメディアに対するどんなさらなるRARE仕事もSGMLとHyTimeの重要性を考慮に入れるのは、お勧めです。
MHEG
MHEG
MHEG stands for the Multimedia and Hypermedia information coding Experts Group, also known as ISO/IEC JTC1/SC29/WG12 (it used to come under SC2). This group is developing a standard "Coded Representation of Multimedia and Hypermedia Information Objects" (ISO CD 13522, or CCITT T.171), commonly called MHEG. The standard is to be published in two parts - part 1 being the base notation, representing objects using ASN.1, and part 2 being an alternate notation which uses SGML. Part 1 has nearly (June 1993) achieved CD status, and is intended to reach full IS in 1994. Part 2 is intended to reach the CD stage in late 1993.
MHEGはExperts Groupをコード化して、またISO/IEC JTC1/SC29/WG12として知られている(それは以前はよくSC2に該当していました)MultimediaとHypermedia情報を表します。 このグループは一般的にMHEGと呼ばれる標準の「マルチメディアとハイパーメディアインフォメーションオブジェクトのコード値」(ISO CD13522、またはCCITT T.171)を開発しています。 規格は2つの部品で発行されることです--ASN.1を使用することでオブジェクトを表して、基数表記法である第1部、およびSGMLを使用する代替の記法である第2部。 第1部は、CD状態をほとんど獲得して(1993年6月)、意図して、1994年に、いっぱいに達するのがあるということです。 第2部が1993年後半にCDステージに達することを意図します。
Adie [Page 58] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[58ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
MHEG is suited to interactive hypermedia applications such as on-line textbooks and encyclopaedia. It is also suited for many of the interactive multimedia applications currently available (in platformspecific form) on CD-ROM. MHEG could for instance be used as the data structuring standard for a future home entertainment interactive multimedia appliance. Telecommunications operators are interested in MHEG for providing interactive multimedia services across ISDN.
MHEGはオンライン教科書や百科事典などの対話的なハイパーメディアアプリケーションに合っています。 また、それはCD-ROMにおける現在利用可能な(platformspecificフォームの)インタラクティブ・マルチメディアアプリケーションの多くに合っています。 例えば、将来のホーム・エンターテインメントインタラクティブ・マルチメディア器具の規格を構造化するデータとしてMHEGを使用できました。 テレコミュニケーションオペレータはISDNの向こう側にインタラクティブ・マルチメディアサービスを提供するためのMHEGに興味を持っています。
To address such markets, MHEG represents objects in a non-revisable form, and is therefore unsuitable as an input format for hypermedia authoring applications: its place is perhaps more as an output format for such tools. MHEG is thus not a multimedia document processing format - instead it provides rules for the structure of multimedia objects which permits the objects to be represented in a convenient "final" form with the aim of direct presentation.
MHEGは、そのような市場に演説するためには、非改訂可能フォームにオブジェクトを表して、したがって、ハイパーメディアオーサリングアプリケーションのための入力フォーマットとして不適当です: さらに恐らくそのようなツールのための出力形式として場所があります。 その結果、MHEGはマルチメディア文書処理形式ではありません--代わりに、それはオブジェクトが便利な「最終的な」フォームに直接表示の目的で表されるのを可能にするマルチメディア対象物の構造に規則を供給します。
The MHEG draft standard is expressed in object-oriented terms. The main object classes are outlined briefly below.
MHEG草稿規格はオブジェクト指向用語で言い表されます。主なオブジェクトのクラスは簡潔に以下に概説されています。
o Content class. A content object contains the encoded
(monomedia) information to be presented, along with
attributes which identify the type of information and the
encoding method, and mediaspecific attributes such as fonts
used, sampling rate, image size, etc.
o 満足しているクラス。 満足しているオブジェクトは提示されるコード化された(「単-メディア」)情報を含んでいます、情報の種類とコード化メソッドを特定して、使用されるフォント、標本抽出率、画像寸法などの属性をmediaspecificする属性と共に
o Selection class and Modification class. The user may
interact with MHEG objects which inherit interactive
behaviour from these classes. (The MHEG object model
supports multiple inheritance.)
o 選択のクラスとModificationのクラス。 ユーザはこれらのクラスから対話的なふるまいを引き継ぐMHEGオブジェクトと対話するかもしれません。 (MHEGオブジェクト・モデルは複数の継承をサポートします。)
o Action class. Two types of action may be applied to
objects: projection, which controls how objects are
rendered; and status actions which affect the state of
objects.
o 動作のクラス。 2つのタイプの動作はオブジェクトに適用されるかもしれません: 映像、どのコントロールがレンダリングされるかどのようにが、反対する。 そして、オブジェクトの状態に影響する状態動作。
o Link class. MHEG hyperlinks connect a "start" object with
one or more "end" objects. Links consist of a set of
conditions relating to the state of the start object, and a
set of actions which are carried out when these conditions
are satisfied. Links also define the spatio-temporal
relationships between objects.
o クラスをリンクしてください。 MHEGハイパーリンクは1個以上の「終わり」オブジェクトに「始め」オブジェクトを接続します。 リンクはスタートオブジェクトの状態に関連する1セットの状態、およびこれらの状態が満たされているとき行われる1セットの機能から成ります。 また、リンクはオブジェクトの間のspatio時の関係を定義します。
o Script class. Script objects are used to describe more
complex interobject linkages (e.g., multiple-source links).
MHEG does not define a scripting language - instead it
provides a formalism for encapsulating scripts which may be
executed by an external program (see SMSL below).
o スクリプトのクラス。 スクリプトオブジェクトは、より複雑なinterobjectリンケージについて説明するのに使用されます(例えば、複数のソースがリンクします)。 MHEGはスクリプト言語を定義しません--代わりに、それは外部プログラムで作成されるかもしれないスクリプトをカプセル化するのに形式を提供します(以下のSMSLを見てください)。
Adie [Page 59] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[59ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
o Composite class. Related objects may be grouped together
into a single composite object (recursively). The
relationships between content objects within a composite
object are determined by link and script objects which also
are members of the composite object.
o クラスを合成してください。 関連オブジェクトは単一の合成オブジェクト(再帰的である)に一緒に分類されるかもしれません。 合成オブジェクトの中の満足しているオブジェクトの間の関係はまた、合成オブジェクトのメンバーであるリンクとスクリプトオブジェクトで決定します。
o Descriptor class. Descriptor objects contain general
information about sets of interchanged objects, so that a
target system can ensure it has adequate resources to run
the hypermedia application represented by the object set.
o 記述子のクラス。 記述子オブジェクトは交換されたオブジェクトのセットに関して一般情報を含んでいます、目標システムが、オブジェクトセットによって表されたハイパーメディアアプリケーションを実行するためにそれには適切なリソースがあるのを確実にすることができるように。
The relationship between HyTime and MHEG has not yet been fully established. One possible relationship [21] is that an MHEG application could be the output of a compilation process which used an equivalent HyTime document as input. This approach would benefit both from the expressive power of HyTime and the run-time efficiency of MHEG. However, it has yet to be shown that this is feasible, since the capabilities of HyTime and MHEG do not completely overlap.
HyTimeとMHEGとの関係はまだ完全に確立されるというわけではありませんでした。 関係[21]がMHEGアプリケーションが入力されるように同等なHyTimeドキュメントを使用した編集プロセスの出力であるかもしれないということであることが可能な1つ。 このアプローチはHyTimeの表現力とMHEGのランタイム効率から利益を得るでしょう。 しかしながら、これが可能であることがまだ示されていません、HyTimeとMHEGの能力が完全に重なるというわけではないので。
There seems to be relatively little interest in or awareness of MHEG within the Internet community, which is only just beginning to be aware of HyTime. In view of the draft nature of the MHEG standard, this report recommends that RARE should not invest substantial effort in MHEG at this time. However, particularly in view of the interest in it shown by PTTs, a watching brief should be kept on MHEG, as it may well be relevant in the future.
MHEGの比較的少ない関心か認識がインターネットコミュニティの中であるように思えます。ただ、インターネットコミュニティはHyTimeを意識してい始めているだけです。 MHEG規格の草稿本質から見て、このレポートは、RAREがこのときかなりの取り組みをMHEGに注ぎ込むはずがないことを勧めます。 しかしながら、特にそれにPTTによって示された関心から見て、傍聴依頼はMHEGの上に保管されるべきです、それが将来たぶん関連しているだろうというとき。
ODA
ODA
The Open Document Architecture standard (ODA - ISO 8613 or T.140) is a compound document interchange format designed for transferring documents between open systems. It is able to represent documents in both a formatted form and a processable (i.e., revisable) form, thus allowing both the content and the printed appearance of the document to be unambiguously transferred.
オープンDocument Architecture規格(ODA--ISO8613かT.140)はオープンシステムの間にドキュメントを移すように設計されたコンパウンドドキュメント置き換え形式です。フォーマットされたフォームと「プロセス-可能」な(すなわち、改訂可能な)用紙の両方にドキュメントを表すことができます、その結果、内容とドキュメントの印刷された外観の両方が明白に移されるのを許容します。
In addition to text data, ODA supports graphics and image data. A revised version to be published in 1993 will support colour. Future developments include support for audio content (underway) and video content (planned). An interface to MHEG is also planned.
テキストデータに加えて、ODAはグラフィックスとイメージデータをサポートします。 1993年に発行されるべき改訂版は色をサポートするでしょう。 未来の発展はオーディオ内容(進行中の)とビデオ内容(計画されている)のサポートを含んでいます。 また、MHEGへのインタフェースは計画されています。
ODA differs from SGML in that the former concerns itself with the physical appearance of the document, while SGML deliberately avoids doing so. SGML concerns itself with semantic markup, and can be used to describe a wide range of data and document architectures. ODA has a more limited concept of a document.
ODAは前者がドキュメントの物理的な外観に携わるという点においてSGMLと異なっています、SGMLが、故意にそうするのを避けますが。 SGMLは、意味マーク付けに携わって、さまざまなデータと文書体系について説明するのに使用できます。 ODAには、ドキュメントの、より限られた概念があります。
Adie [Page 60] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[60ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Hypermedia extensions to ODA (HyperODA) are underway. The extensions will support:
ODA(HyperODA)へのハイパーメディア拡大は進行中です。 拡大は以下をサポートするでしょう。
o References to data held externally to the document (similar
to SGML's external entities?).
o データの参照は外部的にドキュメント(SGMLの外部実体と同様の?)に成立しました。
o Non-linear structures, using contextual and independent
hyperlinks based on the HyTime model.
o HyTimeモデルに基づく文脈上の、そして、独立しているハイパーリンクを使用する非線形の構造。
o Temporal relationships between document components (e.g.,
sequential, parallel, cyclic, duration, start delay).
o ドキュメントの部品(例えば、連続して、平行で、周期的な持続時間、スタート遅れ)の間の時の関係。
HyperODA is not being developed in competition to HyTime or MHEG its purpose is to add hypermedia features to ODA rather than to be a completely general framework for hypermedia applications.
HyperODAがHyTimeへの競争で開発されていないか、または目的があるMHEGはハイパーメディアアプリケーションのための完全に一般的なフレームワークであるよりむしろハイパーメディア機能をODAに追加します。
Bearing in mind that:
それを覚えておきます:
o the HyperODA extensions are still under development;
o HyperODA拡張子はまだ開発中です。
o in some senses ODA can be seen as a competitor to SGML,
which has greater presence in the hypermedia world;
o ある意味でODAをSGMLに競争相手と考えることができます。(それは、ハイパーメディア世界によりすばらしい存在を持っています)。
o there seems to be a lack of enthusiasm for ODA in the
Internet community (the IETF WG on piloting ODA has
disbanded);
o ODAに対する熱意の不足はインターネットコミュニティであるように思えます(ODAを操縦するときのIETF WGは解散しました)。
o Adobe's newly-released Acrobat technology (described below)
will have a significant effect on the marketplace;
o Adobeの新たにリリースされたAcrobat技術(以下で、説明される)は重要な影響を市場に与えるでしょう。
this report recommends that ODA should not form a basis for investment in networked hypermedia technology by RARE.
このレポートは、ODAがRAREでネットワークでつながれたハイパーメディア技術への投資の基礎を形成するべきでないことを勧めます。
PREMO
PREMO
PREMO (Presentation Environment for Multimedia Objects) is a new work item in ISO/IEC JTC1/SC24 (the graphics standards subcommittee). An initial draft [22] exists, and the schedule calls for a CD by June 1994, a DIS by June 1995, and the final IS by June 1996.
PREMO(Multimedia ObjectsのためのプレゼンテーションEnvironment)はISO/IEC JTC1/SC24(グラフィックス標準小委員会)の新しい仕事項目です。 初期の草稿[22]は存在しています、そして、スケジュールは1994年6月までにCDを求めます、1995年6月までにDIS、そして、決勝が1996年6月までにあります。
PREMO addresses the construction of, presentation of, and interaction with multimedia objects. It specifies techniques for creating audiovisual interactive single and multiple media applications. It is consistent with the principles of the Computer Graphics Reference Model (CGRM, ISO 11072), and is defined in object-oriented terms.
PREMOが工事を扱う、マルチメディア対象物とのプレゼンテーション、および相互作用。 それは単一の状態で視聴覚のインタラクティブを作成するためのテクニックとマルチメディアアプリケーションを指定します。 それは、コンピュータGraphics Reference Model(CGRM、ISO11072)の本質と一致していて、オブジェクト指向用語で定義されます。
It is not clear how PREMO relates to HyTime and MHEG. Although these standards are listed in section 2 (References) of the initial draft,
PREMOがどのようにHyTimeとMHEGに関連するかは、明確ではありません。 初期の草稿のセクション2(参照)でこれらの規格は記載されていますが
Adie [Page 61] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[61ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
they appear not to be mentioned in the text. The wisdom of developing what appears to be yet another structuring standard for multimedia data is doubtful.
彼らは、テキストで言及されないように見えます。 マルチメディアデータの規格を構造化しながらしかし、別のものであるように見えることを開発する知恵は疑わしいです。
The PREMO work is not sufficiently advanced to permit a judgement of its usefulness in satisfying the requirements under discussion.
PREMO仕事は議論で要件を満たすことにおける、有用性の判断を可能にするくらいには進められません。
Acrobat
アクロバット
Adobe, Inc. has introduced a new format called Acrobat PDF, which it is putting forward as a potential de facto standard for portable document representation. Based on the Postscript page description language, Acrobat PDF is also designed to represent the printed appearance of a document (which may include graphics and images as well as text. Unlike postscript however, Acrobat PDF allows data to be extracted from the document. It is thus a revisable format. It includes support for annotations, hypertext links, bookmarks and structured documents in markup languages such as SGML. PDF files can represent both the logical and the formatting structure of the document.
Adobe Inc.はそれが携帯用のドキュメント表現のための潜在的デファクトスタンダードとして進めているAcrobat PDFと呼ばれる新しい形式を導入しました。 Postscriptページ記述言語に基づいて、また、Acrobat PDFは、ドキュメントの印刷された外観を表すように設計されています。どれがテキストと同様にグラフィックスとイメージを含むかもしれないか。しかしながら、追伸と異なって、Acrobat PDFは、データがドキュメントから抜粋されるのを許容します。その結果、それは改訂可能形式です。それはSGMLなどのマークアップ言語に注釈、ハイパーテキストリンク、ブックマーク、および構造化されたドキュメントのサポートを含んでいます。(PDFファイルは論理的とドキュメントの形式構造の両方を表すことができます。
Acrobat PFD thus appears to offer very similar functionality to ODA. Adobe's successful Postscript de facto standard profoundly influenced information technology - it is possible that if successful, Acrobat PDF will be almost as important. RARE should be aware of this technology and its potential impact on multimedia information systems.
その結果、アクロバットPFDは、非常に同様の機能性をODAに提供するように見えます。 AdobeのうまくいっているPostscriptデファクトスタンダードは情報技術に深く影響を及ぼしました--うまくいくと、Acrobat PDFがほとんど同じくらい重要であることは、可能です。 RAREはマルチメディア情報システムの上でこの技術とその可能性のある衝撃を意識しているべきです。
5.2. Access Mechanisms
5.2. アクセス機構
This section describes some standards which are useful in providing network access to multimedia data. Of course, there are many multimedia transport protocols, which this report does not attempt to describe (see [1] for further information). The protocols mentioned below are search/retrieve protocols which were not mentioned in [1].
このセクションはいくつかのマルチメディアデータへのネットワークアクセスを提供する際に役に立つ規格について説明します。 もちろん、トランスポート・プロトコル(このレポートはする)が説明するのを試みない多くのマルチメディアがあります(詳細のための[1]を見てください)。 以下に言及されたプロトコルは検索/がプロトコルを検索するということです([1]で言及されませんでした)。
Multimedia Extensions to SQL
SQLへのマルチメディアエクステンション
A new work item in ISO (ISO/IEC JTC1 N2265) to extend the SQL standard to include multimedia data is expected to be approved shortly. Initially this work will concentrate on developing a framework, and on free text data. Support for non-text data will be added later, using a separate part of the standard for each media type.
まもなくマルチメディアデータを含むようにSQL規格を広げるISO(ISO/IEC JTC1 N2265)の新しい仕事項目が承認されると予想されます。 初めは、この仕事はフレームワークを開発することと、そして、無料のテキストデータに集中するでしょう。 それぞれのメディアタイプの規格の別々の部分を使用して、非テキストデータのサポートは後で加えられるでしょう。
The expected timescale for this standardisation work is lengthy (part 1 - the framework - is targeted for completion in 1996).
この規格化仕事のための予想されたスケールは長いです(第1部(フレームワーク)は1996年の完成のために狙います)。
Adie [Page 62] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[62ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
There are suggestions that this standard could be used as a query language in conjunction with the HyQ query component of the HyTime standard.
照会言語としてHyTime規格のHyQ質問の部品に関連してこの規格を使用できたという提案があります。
DFR
DFR
DFR is the Document Filing and Retrieval system, specified in ISO 10166-1 and ISO 10166-2. It is intended for office automation applications, and falls within the Distributed Office Applications (DOA) model of ISO 10031-1. DFR has design similarities to the ISO Directory and to the X.400 Message Store, and it is likewise part of OSI.
DFRはISO10166-1とISO10166-2で指定されたDocument FilingとRetrievalシステムです。 それは、オフィス・オートメーションアプリケーションのために意図して、ISO10031-1のDistributedオフィスApplications(DOA)モデルの中で低下します。 DFRはISOディレクトリと、そして、X.400 Messageストアにデザインの類似性を持っています、そして、それは同様にOSIの一部です。
DFR defines a Document Store, which provides a service to a DFR User over an OSI protocol stack incorporating ROSE (and optionally RTSE). A document in the Document Store may have a number of attributes associated with it, including pointers to related documents. There is support for multiple versions of the same document, and for hierarchical groups of documents. The access protocol supports searching for documents based on their attributes. DFR itself does not restrict the content of documents in any way, but the natural partner to DFR is the ODA standard for document content.
DFRがDocumentストアを定義する、(任意に、RTSE)。ストアはローズを取り入れるOSIプロトコル・スタックの上のDFR Userに対するサービスを提供します。 Documentストアのドキュメントには、関連するドキュメントに指針を含むそれに関連している多くの属性があるかもしれません。 サポートが同じドキュメントの複数のバージョン、およびドキュメントの階層的なグループのためにあります。 アクセス・プロトコルはそれらの属性に基づくドキュメントの探すことをサポートします。 DFR自身は何らかの方法でドキュメントの中身を制限しませんが、DFRの生まれながらのパートナーはドキュメント内容における、標準のODAです。
It is not clear that DFR offers significantly more useful functionality than is available from other, simpler access protocols already in use on the Internet.
DFRがインターネットで既に使用中の他の、そして、より簡単なアクセス・プロトコルから利用可能であるよりかなり役に立つ機能性を提供するのは、明確ではありません。
5.3. Other Standards
5.3. 他の規格
This section briefly describes other standards in this area and discusses their relevance.
このセクションは、この領域で簡潔に他の規格について説明して、それらの関連性について論じます。
MIME
MIME
MIME (Multipurpose Internet Mail Extensions) is a mechanism for transferring multimedia information in an RFC822 mail message. STD 11, RFC 822 defines a message representation protocol which specifies considerable detail about message headers, but which leaves the message content as flat ASCII text. RFC 1341 redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. Because RFC 822 said very little about message content, RFC 1341 is largely orthogonal to (rather than a revision of) RFC 822.
MIME(マルチパーパスインターネットメールエクステンション)は、RFC822メール・メッセージのマルチメディア情報を移すためのメカニズムです。 STD11、RFC822はメッセージヘッダーの周りでかなりの詳細を指定しますが、平坦なASCIIテキストとしてメッセージ内容を残すメッセージ表現プロトコルを定義します。 RFC1341は、複合原文の、そして、非原文のメッセージ本体が情報の損失なしで表されて、交換されるのを許容するためにメッセージ本体の書式を再定義します。 RFC822がほとんど1341が主に直交しているメッセージ内容、RFCに関して言わなかった、(改正よりむしろ、)、RFC822
MIME provides facilities to include multiple objects in a single message, to represent text in character sets other than US-ASCII, to represent formatted multi-font text messages, to represent non textual material such as images and audio fragments, and generally to
MIMEは米国-ASCIIを除いた文字集合におけるテキストを表して、フォーマットされたマルチフォントテキスト・メッセージを表して、イメージやオーディオ断片などの非原文の材料を表すただ一つのメッセージに一般に、倍数が反対するインクルードに便宜を与えます。
Adie [Page 63] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[63ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
facilitate later extensions defining new types of Internet mail for use by co-operating mail agents. It does not define any structure to allow relationships between body parts within a message to be expressed.
協力関係を持っているメールエージェントによる使用のために新しいタイプに関するインターネット・メールを定義する後の拡大を容易にしてください。 それは、言い表されるべきメッセージの中の身体の部分の間の関係を許容するために少しの構造も定義しません。
For the purposes of the requirements considered by this report, the relevance of MIME is that it separates media type from media encoding, and that it defines a procedure for registering values of these attributes.
このレポートによって考えられた要件の目的のために、MIMEの関連性はメディアコード化とメディアタイプを切り離して、これらの属性の値を示すための手順を定義するということです。
The MIME construct of chief interest is the "Content-Type" field. This contains a MIME "type" and "subtype", and any "parameters" which further qualify the subtype. The register of MIME content-types is maintained by the Internet Assigned Numbers Authority (IANA). Content types defined in the MIME standard itself include:
主要に関心のMIME構造物は「コンテントタイプ」分野です。 これはMIME「タイプ」、"「副-タイプ」"、およびさらに「副-タイプ」に資格を与えるどんな「パラメタ」も含んでいます。 MIME content typeに関するレジスタはインターネットAssigned民数記Authority(IANA)によって維持されます。 MIME規格自体で定義されたcontent typeは:
Adie [Page 64] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[64ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Type Subtype Parameters Meaning
Subtypeパラメタ意味をタイプしてください。
text plain charset Plain text
テキストの明瞭なcharset Plainテキスト
richtext charset Text with SGML-like
markup for
representing
formatting.
形式を表すためのSGMLのようなマーク付けがあるrichtext charset Text。
image jpeg JPEG File Interchange
Format
イメージjpeg JPEG File Interchange Format
gif Graphics Interchange
Format
gif Graphics Interchange Format
audio basic 8-bit -law 8kHz PCM
encoding
8kHzのオーディオの基本的な8ビットの法のPCMコード化
video mpeg
ビデオmpeg
application ODA profile Open Document
(used (Document Architecture
for Application document.
application Profile)
-specific
data)
アプリケーションODAプロフィールオープンDocument(中古(ApplicationドキュメントアプリケーションProfileのためのドキュメントArchitecture)の特定のデータ)
octet- name (e.g., General binary data
stream filename); such as an arbitrary
type (for binary file.
human
recipient),
etc.
八重奏(例えば、一般バイナリ・データストリームファイル名)を命名してください。 任意のタイプ(バイナリーファイル人間の受取人のための)などのように
postscript Document in
postscript.
追伸の追伸Document。
Private experimental values of types and subtypes starting with X may be used between consenting adults without registration with IANA.
Xがあるタイプと血液型亜型始めの個人的な実験値は同意成人の間でIANAとの登録なしで使用されるかもしれません。
MIME also defines a "Content-Transfer-Encoding" field, which is used to specify an invertible mapping between the "native" encoding of a media type and a representation that may be readily exchanged using 7bit mail transfer protocols.
また、MIMEは「満足している転送コード化」分野を定義します。(それは、メディアタイプの「ネイティブ」のコード化と7ビットのメール転送プロトコルを使用することで容易に交換されるかもしれない表現の間のinvertibleマッピングを指定するのに使用されます)。
WWW's HTTP2 protocol makes use of MIME media type and encoding attributes, and also uses MIME's message format for retrieving data
WWWのHTTP2プロトコルは、データを検索するためにMIMEメディアタイプと属性をコード化して、また、用途をコード化することの使用をMIMEのメッセージ・フォーマットにします。
Adie [Page 65] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[65ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
from the server. It is the first MIME application to utilise the 8bit Content-Transfer-Encoding, which essentially means no encoding.
サーバから. それは8ビットのContent転送コード化を利用する最初のMIMEアプリケーションです。(本質的には、コード化はコード化することを意味しません)。
SMSL
SMSL
SMSL is the Standard Multimedia Scripting Language. It is a proposed new work item for ISO/IEC JTC1/SC18/WG8 (HyTime) and JTC1/SC29/WG12 (MHEG). The functional requirements are expected to be completed in 1994, and the coding scheme completed in 1995.
SMSLはStandard Multimedia Scripting Languageです。 それはISO/IEC JTC1/SC18/WG8(HyTime)とJTC1/SC29/WG12(MHEG)のための提案された新しい仕事項目です。 機能条件書は1994年に完成していて1995年に完成したコード構成であると予想されます。
SMSL is designed as an open language with a similar purpose to existing vendor-specific scripting languages such as Macromind's "Lingo", Kaleida's "Script/X", and Gain's "GEL". The intention is to offer an intermediate open multimedia scripting language which could be used both for interchange purposes, and for controlling the presentation of HyTime or MHEG multimedia structures. Several different approaches to defining SMSL have been suggested, including using the ANDF (Architecture-Neutral Distribution Format) approach, and basing SMSL on SGML or on the Scheme language.
SMSLは開いている言語として同様の目的でMacromindの「言語」(Kaleidaのもの「スクリプト/X」、およびGainの「ゲル」)などの既存のベンダー特有のスクリプト言語に設計されています。 意志は置き換え目的と、HyTimeかMHEGマルチメディア構造のプレゼンテーションを制御するのに使用できた中間的開いているマルチメディアスクリプト言語を提供することです。 SMSLを定義することへのいくつかの異なるアプローチが示されました、ANDF(アーキテクチャ中立のDistribution Format)アプローチを使用して、SMSLをSGML、または、Scheme言語に基礎づけるのを含んでいて。
The SMSL work is not sufficiently advanced to permit a judgement of its usefulness in satisfying the requirements under discussion. However, it is interesting to note that despite the descriptive power of HyTime and MHEG, there is still perceived to be a role for procedural scripting.
SMSL仕事は議論で要件を満たすことにおける、有用性の判断を可能にするくらいには進められません。 しかしながら、HyTimeとMHEGの描写的であるパワーにもかかわらず、手続き上のスクリプティングのための役割があるとまだ知覚されていることに注意するのはおもしろいです。
AVIs
AVI
The CCITT is defining a set of Audio Visual Interactive Services (AVIs), intended for offering to domestic and business consumers over a national network (e.g., by PTTs). These services will be specified as T.17x recommendations, and will include MHEG. These services would also make use of the SMSL work.
CCITTは全国的なネットワーク(例えば、PTTによる)の上で1セットの申し出るためにドメスティックな状態で意図するAudio Visual Interactive Services(AVI)と企業消費者を定義しています。 これらのサービスは、T.17x推薦として指定されて、MHEGを含むでしょう。 また、これらのサービスはSMSL仕事を利用するでしょう。
Insufficient information is available about this area to allow its relevance to be judged.
不十分な情報は関連性が判断されるのを許容するこの領域に関して利用可能です。
5.4. Trade Associations
5.4. 産業団体
This section mentions some trade associations which are involved in standards making in the multimedia area.
このセクションはマルチメディア領域での規格作成にかかわるいくつかの産業団体について言及します。
Interactive Multimedia Association
インタラクティブ・マルチメディア協会
The Interactive Multimedia Association (IMA) is an international trade association with over 250 members, representing a wide spectrum of multimedia industry players. Members include Apple, Microsoft, MIT CECI (the developers of AthenaMuse 2), 3DO, and many other
インタラクティブ・マルチメディア協会(IMA)は250人以上のメンバーとの国際貿易仲間です、マルチメディア業界のプレーヤーの広いスペクトルを表して。 メンバーはアップル、マイクロソフト、MIT CECI(AthenaMuse2の開発者)、スリーディーオー、および多くを別に入れます。
Adie [Page 66] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[66ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
important market actors.
重要な市場の俳優。
In 1989, the IMA initiated a "Compatibility Project", tasked with developing technical solutions to the cross-platform compatibility problem. The Project has published two important documents:
1989年に、IMAはクロスプラットフォーム互換性の問題の展開している技術的解決法で仕事を課された「互換性プロジェクト」を開始しました。 Projectは2つの重要書類を発表しました:
o "Recommended Practices for Multimedia Portability" [23]
outlines a specification for a common interface to be used
by interactive video delivery systems. It has been adopted
by the US Military as part of Military Standard 1379.
o 「Multimedia Portabilityのためのお勧めのPractices」[23]は、一般的なインタフェースが双方向テレビ配送システムによって使用されるために仕様を概説します。それはMilitary Standard1379の一部として米国Militaryによって採用されました。
o "Recommended Practices for Enhancing Digital Audio
Compatibility in Multimedia Systems" [24] defines four
standard digital audio data types and four sampling rates
(from low-end -law 8kHz mono encoding, up through ADPCM
modes to CD-quality 44kHz 16-bit stereo).
o 「Multimedia SystemsのEnhancingデジタル・オーディオCompatibilityのためのお勧めのPractices」[24]は4つの標準のデジタル・オーディオデータ型と4つの標本抽出率(法8kHzのローエンドモノタイプコード化から44kHzのCD品質の16ビットのステレオへのADPCMモードによる)を定義します。
Work is continuing to produce further recommendations on other issues.
仕事は他の問題でさらなる推薦状を起こし続けていることです。
The Compatibility Project has now initiated a procurement process by publishing three Request for Technology (RFT) documents, defining the requirements of a platform-independent interactive multimedia system, including networking requirements. The RFTs cover "Multimedia System Services", a "Scripting Language for Interactive Multimedia Titles", and "Multimedia Data Exchange". An "Architecture Reference Model" for cross-platform desktop and distributed multimedia systems provides the framework for these RFTs, which are pragmatic documents outlining the technical requirements for time-based media handling in detail. Note that relatively little is said about non-time-based data.
Compatibility Projectは現在Technology(RFT)ドキュメントのために3Requestを発行することによって、調達プロセスを開始しました、プラットホームから独立しているインタラクティブ・マルチメディアシステムの要件を定義して、要件をネットワークでつなぐのを含んでいて。 RFTsは「マルチメディア・システムサービス」、「インタラクティブ・マルチメディアタイトルのためのスクリプト用の言語」、および「マルチメディアデータ交換」をカバーしています。 クロスプラットフォームデスクトップと分散型マルチメディアシステムのための「アーキテクチャ規範モデル」はこれらのRFTsにフレームワークを供給します。(RFTsは詳細に時間ベースのメディア取り扱いのための技術的要求事項について概説する実践的なドキュメントです)。 注意が比較的少ししかそんなにありません。非時間ベースのデータに関して、言われています。
A first reading of the Multimedia Data Exchange RFT reveals that the Apple Bento standard [18] and the Microsoft/IBM RIFF format [25] both influenced the development of this document. The selected system may well be based on one or both of these technologies.
Multimedia Data Exchange RFTの最初の読みは、アップルBento規格[18]とマイクロソフト/IBM RIFF形式[25]がともにこのドキュメントの開発に影響を及ぼしたのを明らかにします。 選択されたシステムはたぶんこれらの技術の1か両方に基づくでしょう。
A joint response to the Multimedia System Services RFT has been received from HP, IBM and Sun. Two responses to the Scripting Languages RFT have been received - from Kaleida (Script-X) and Gain Technology (GEL). Two partial responses to the Multimedia Data Exchange RFT have been received from Apple (Bento) and Avid (Open Media Framework).
HP、IBMからMultimedia System Services RFTへの共同応答を受けました、そして、日曜日に、Scripting Languages RFTへのTwo応答はKaleida(スクリプトX)とGain Technology(GEL)から受け取られています。 アップル(Bento)とAvid(開いているMedia Framework)からMultimedia Data Exchange RFTへの2つの部分応答を受けました。
Responses to the RFTs are currently being analysed by the IMA, and the result will be announced in November 1993. The specifications which will eventually result from this process will be important for future commercial multimedia products. It is important that the
RFTsへの応答は現在IMAによって分析されています、そして、結果は1993年11月に発表されるでしょう。 結局このプロセスから生じる仕様は将来の商業マルチメディア機器に重要になるでしょう。 それが重要である、それ
Adie [Page 67] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[67ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
community keep a watching brief on the IMA Compatibility Project and its possible implications for distributed multimedia applications on the Internet.
共同体は分散型マルチメディアアプリケーションのためにインターネットにIMA Compatibility Projectの上の傍聴依頼とその関与の可能性を保管します。
Multimedia Communications Forum
マルチメディア通信フォーラム
The Multi-Media [sic] Communications Forum (MMCF) is a recently formed (June 1993) trade consortium whose initial members include IBM, National Semiconductor, Apple, Siemens and AT&T. Intended to complement the work of the IMA, the MMCF plans to develop guidelines and recommendations for the industry to help ensure "end-to-end network interconnectivity of multimedia applications, workstations and devices". They also plan to provide input to standards bodies.
Multi-メディア[原文のまま]コミュニケーションForum(MMCF)は初期のメンバーがIBM、ナショナル・セミコンダクター、アップル、シーメンス、およびAT&Tを含んでいる最近形成された(1993年6月)貿易共同体です。 IMA、ガイドラインを開発するMMCF計画、および産業が「マルチメディア応用、ワークステーション、およびデバイスの終わりから終わりへのネットワーク相互接続性」を確実にするのを助けるという推薦の仕事の補足となるつもりでした。 また、彼らは、入力を標準化団体に提供するのを計画しています。
It is still too early to say whether this forum will succeed. If the IMA Compatibility Project specifications, when they are published, leave networking issues open, then MMCF could have an important role to play. It is recommended that RARE consider becoming an Observing
このフォーラムが成功するかどうか言うのはまだ早過ぎます。 それらが発行されるとき、IMA Compatibility Project仕様がネットワーク問題を開いた状態でおくなら、MMCFには、果たす重要な役割があるかもしれません。 RAREが、Observingになると考えるのは、お勧めです。
Member ($350 US pa), entitling it to attend general and annual MMCF meetings (but not committee meetings), and to receive minutes and other general papers (but not working documents); with the prospect of becoming an Auditing Member ($1200 US pa) later if relevant.
それが一般的で例年のMMCFミーティング(しかし、委員会でない)に出席して、分間受信される権利を与えるメンバー(350ドルの米国pa)と他の一般的な書類(ドキュメントを扱いませんが)。 Auditingメンバー(1200ドルの米国pa)になるという見通しが、より遅いのですが、関連していた状態で。
Multimedia Communications Community of Interest
マルチメディア通信利益共同体
This is a very new organisation formed at a meeting in France in June 1993. Its charter is to promote the use of applications which let people in different locations view documents, images, graphics and full-motion video on a PC screen. The remit includes CSCW aspects. Members of the organisation include IBM, Intel, Northern Telecom, Telstra (Australia), BT, France Telecom and DB Telekom. The companies plan field trials of multimedia services in 1Q94.
これは1993年6月にフランスでミーティングで形成された非常に新しい機構です。 特許はPCスクリーンで別の場所視点ドキュメントの人々、イメージ、グラフィックス、およびフルモーション・ビデオをさせるアプリケーションの使用を促進することです。 CSCW局面をインクルードに送金してください。 機構のメンバーはIBM、インテル、ノーザン・テレコム、テルストラ(オーストラリア)、BT、フランステレコム、およびDB Telekomを入れます。 会社は1Q94でのマルチメディアサービスの実地試験を計画しています。
6. Future Directions
6. 将来の方向
6.1. General Comments on the State-of-the-Art
6.1. 最先端の概評
Distributed hypermedia systems are now emerging from the research phase into the experimental deployment stage. Every project team (and standards committee), almost without exception, hopes for their system to become the de facto standard for hypermedia.
分配されたハイパーメディアシステムは現在、研究フェーズから実験展開ステージに出て来ています。 あらゆるプロジェクト・チーム(そして、規格委員会)が、ほとんど例外なしでそれらのシステムがハイパーメディアのためのデファクトスタンダードになることを望んでいます。
As we've seen, Gopher and WWW already offer multimedia capability, but they are still largely oriented to the use of external viewers for non-text nodes. This "unintegrated" approach is in contrast to typical stand-alone multimedia applications, where the presentation of related information in different media is tightly integrated. The
私たちが見たように、ゴーファーとWWWは既にマルチメディア能力を提供しますが、それらはまだ外部ビューワの非テキストノードの使用に主に適応しています。 この"非統合"のアプローチは典型的なスタンドアロンのマルチメディア応用と対照的になっています。そこでは、異なったメディアにおける、関連する情報のプレゼンテーションがしっかり統合しています。 The
Adie [Page 68] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[68ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
in-line image feature of XMosaic and the new version of HTML currently under development may represent the start of a move towards greater integration of different media in such distributed hypermedia systems.
XMosaicのインライン画像特徴と現在開発中のHTMLの新しいバージョンはそのような分配されたハイパーメディアシステムにおける、異なったメディアの、より大きい統合に向かって移動の始まりを表すかもしれません。
Three important factors in the design of distributed hypermedia systems appear to emerge from the preceding chapters of this report. They can each be formulated in terms of distinctions between two aspects of the system.
分配されたハイパーメディアシステムの設計における3つの重要な要素がこのレポートの先の章から出て来るように見えます。 システムの2つの局面の区別でそれぞれそれらを定式化できます。
o A common and apparently fruitful approach to hypermedia
systems is to distinguish the content from the
hyperstructure. Standards work clearly distinguishes
between these concepts, with standards such as MPEG, JPEG,
G.72x, etc, for content; and HyTime or MHEG for structure.
Currently-deployed systems also make this distinction, most
obviously in Gopher, where the structure/content split maps
onto the server filesystem's directory/file split. In a
similar way, the ability to maintain hyperlink information
separately from data is perceived in hypermedia research
circles as a "good thing". Research systems such as
Microcosm and Hyper-G do this, and HyTime with its ilink
element also supports it. WWW does not support this, but
requires link anchors to be edited into source data. There
are problems with this approach, however - see the section
on Microcosm for details.
o ハイパーメディアシステムへの一般的で明らかに実り多いアプローチは「超-構造」と内容を区別することです。 標準化作業は内容のために明確にMPEG、JPEG、G.72xなどの規格があるこれらの概念を見分けます。 構造へのHyTimeかMHEG。 また、現在配布しているシステムはこの区別をします、明らかなゴーファーにおける大部分、構造/内容が地図をサーバファイルシステムのディレクトリ/ファイル分裂に分けたところで。 同様の方法で、別々にデータからハイパーリンク情報を保守する能力は「良いもの」としてハイパーメディア研究円の形で知覚されます。 MicrocosmやHyper-Gなどのリサーチシステムはこれをします、そして、また、ilink要素があるHyTimeはそれをサポートします。 WWWは、これをサポートしませんが、リンクアンカーがソースデータに編集されるのを必要とします。 しかしながら、このアプローチに関する問題があります--詳細に関してMicrocosmの上のセクションを見てください。
o A useful approach to content is to distinguish the media
type from the media encoding. The MIME standard (used by
HTTP2) illustrates how this can be done, and Gopher+ employs
a similar system.
o 内容への役に立つアプローチはメディアコード化とメディアタイプを区別することです。 MIME規格(HTTP2によって使用される)は、どうしたらこれができるかを例証します、そして、ゴーファー+雇用は同様のシステムを例証します。
o The distinction between data and protocol is also important
for some systems. WWW for instance has clearly separate
protocol (HTTP) and data (HTML) specifications. However,
Gopher+ is specified without making this distinction. (The
original Gopher system is very simple and arguably has no
need for such separation.)
o また、いくつかのシステムに、データとプロトコルの区別も重要です。例えば、WWWには、別々のプロトコル(HTTP)とデータ(HTML)仕様が明確にあります。 しかしながら、この区別をしないで、ゴーファー+は指定されます。 (オリジナルのゴーファーシステムは、非常に簡単であり、論証上そのような分離の必要性を全く持っていません。)
The most significant mismatches between the capabilities of currentlydeployed systems and user requirements are in the areas of presentation and quality of service. Adding flexibility in presentation capabilities to WWW or Gopher should be possible without any major change to the protocols (although it may require changes to data formats). Such capabilities could result from the progress towards greater integration of media types presaged above. However, improving QOS is significantly more difficult, as it may require changes at a more fundamental level. The following section outlines
currentlydeployedシステムとユーザ要件の能力の間の最も重要なミスマッチがプレゼンテーションとサービスの質の領域にあります。 WWWかゴーファーへのプレゼンテーション能力における柔軟性を加えるのはプロトコルへの少しも大きな変化なしで可能であるべきです(データ形式に釣り銭がいるかもしれませんが)。 そのような能力は上で前兆となられたメディアタイプの、より大きい統合に向かって進歩から生じるかもしれません。 しかしながら、QOSを改良するのは、より基本的なレベルで釣り銭がいるかもしれないようにかなり難しいです。 以下のセクションアウトライン
Adie [Page 69] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[69ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
some possible solutions to this problem.
この問題へのいくつかの可能な解決。
6.2. Quality of Service
6.2. サービスの質
Meeting the responsiveness requirement is certainly the key factor for the acceptance of networked multimedia information systems in the user community. To reiterate the requirement given in a previous section:
確かに、反応性必要条件を満たすのは、ユーザーコミュニティでのネットワークでつながれたマルチメディア情報システムの承認のための主要因です。 前項で与えられた要件を繰り返すために:
o For simple actions such as "next page", tolerable delays are
of the order of 0.2s.
o 「次のページ」などの単純アクションのために、許容できる遅れは0.2の注文のものです。
o For more complex actions such as "search for documents
containing this word", then a tolerable delay is of the
order of 2s.
o そして、「この単語を含むドキュメントの検索」などの、より複雑な動きのために、許容できる遅れは2の注文のものです。
o Users tend to give up waiting for a response after about
20s.
o ユーザは、20年代頃の後に応答を待つのをやめる傾向があります。
There are several methods which may alleviate the problem of poor responsiveness (or cause the user to revise his or her expectations of responsiveness!), some of which are described below.
それの或るものが以下で説明される貧しい反応性(ユーザが反応性へのその人の期待を改訂することを引き起こしてください!)の問題を軽減するかもしれないいくつかのメソッドがあります。
1. Give clues that fetching a particular item might be time-
consuming - simply quoting the size (and/or location) may be
sufficient. WAIS and some Gopher clients already quote the
size.
1. サイズ(そして/または、位置)が十分であるかもしれないことを単に引用して、特定の項目をとって来るのが、時間であるかもしれないという手がかりを消費しているのに与えてください。 WAISとゴーファークライアントの中には既にサイズを引用する人もいます。
2. Display a "progress" indicator while fetching data.
2. データをとって来ている間、「進歩」インディケータを表示してください。
3. Allow the user to interact with other, previously fetched
information while waiting for data to be retrieved. The
inability to do this is an annoying limitation of XMosaic.
It can be difficult to implement, except on a multi-threaded
operating system such as OS/2 or Windows NT.
3. データが検索されるのを待っている間、他の、そして、以前にとって来られた情報とユーザと対話させてください。 これをできないことはXMosaicの煩わしい限界です。 それはOS/2かWindows NTなどのマルチスレッド化されたオペレーティングシステムを除いて、実装するのが難しい場合があります。
4. Allow several fetches to be performed in parallel. Again,
multithreading support makes this easier. This technique is
less likely to be useful if all the nodes being requested
come from the same server.
5. Pre-fetch information which the client software believes the
user will wish to see next. This requires some "hints" in
the data about which nodes might be good candidates for pre-
fetching.
4. いくつかのフェッチが平行で実行させられてください。 一方、サポートをマルチスレッド化するのに、これは、より簡単になります。 要求されているすべてのノードが同じサーバ5から来るなら、このテクニックはそれほど役に立つ傾向がありません。 クライアントソフトウェアが、ユーザが次に見たくなると信じている情報をあらかじめとって来てください。 これはノードがプレのとって来ることの良い候補であるかもしれないデータにおけるいくつかの「ヒント」を必要とします。
6. Cache information locally. The use of Universal Resource
Numbers (see the section on WWW) is relevant for managing
this.
6. 局所的に情報をキャッシュしてください。 これを管理するのにおいて、Universal Resource民数記(WWWの上のセクションを見る)の使用は関連しています。
Adie [Page 70] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[70ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
7. Where multiple copies of the same information are held in
different network locations, fetch the "nearest" copy. This
is sometimes known as "anycasting", and is a more general
case of local caching. The proposed URN-to-URL resolution
service [26] could be used to support this.
7. 同じ情報の複本が異なったネットワークの位置に保持されるところでは、“nearest"コピーをとって来てください。 これは、"anycastingする"であるとして時々知られていて、地方のキャッシュの、より一般的なそうです。 これをサポートするのにURNからURLへの提案された解決サービス[26]を使用できました。
8. When retrieving a document, the client should be able to
display the first part of the document to the user. The
user can then start to read the document while the system is
still downloading it. Alternatively, the user may decide
that the document is not relevant and abort the retrieval.
8. ドキュメントを検索するとき、クライアントはドキュメントの最初の部分をユーザに表示できるべきです。 そして、ユーザは、システムがまだそれをダウンロードしている間、ドキュメントを読み始めることができます。 あるいはまた、ユーザは、ドキュメントが関連していないと決めて、検索を中止するかもしれません。
9. Offer multiple views of image or video data at different
resolutions and therefore sizes. This enables the user to
select a balance between speed of retrieval and data
quality. Gopher+ and HTML2 both support this.
9. 異なった解決としたがって、サイズでイメージに関する複数の意見かビデオ・データを提供してください。 これは、ユーザが検索の速度とデータの品質の間のバランスを選択するのを可能にします。 ゴーファーの+とHTML2はともにこれをサポートします。
10. Future high-speed networks and protocols (ATM, RTP) will
allow real-time display of isochronous data. Information
systems should be able to take advantage of this.
10. 将来の高速ネットワークとプロトコル(ATM、RTP)は同一時間のデータのリアルタイムのディスプレイを許容するでしょう。 情報システムはこれを利用できるべきです。
A useful description of the problem is given in [27]. This paper rightly contends that the view, held by many hypermedia researchers and implementors, that the network is simply a transparent data highway which needs no special consideration in application design, is wrong. It is argued that:
[27]で問題の役に立つ記述を与えます。 この紙は、ネットワークが単にアプリケーション設計における特別の配慮を全く必要としない透明なデータハイウェイであるという多くのハイパーメディア研究者と作成者によって保持された眺めが間違っていると正しく主張します。 以下のことと主張されます。
"the very same structural characteristics that may make
a multimedia document appealing to the end user are the
characteristics that are extremely helpful during
dynamic network performance optimisation".
「エンドユーザの好みに合うマルチメディアドキュメントを作るかもしれない全く同じ構造的な特性はダイナミックなネットワーク性能最適化の間に非常に役立っている特性です。」
This is a particularly relevant statement considered in the light of suggestion 5 above.
これは提案5の見地から上で考えられた特に関連している声明です。
6.3. Recommended Further Work
6.3. さらなるお勧めの仕事
To meet the needs of applications such as those described in section 2.1, the community must seek where possible to adapt and enhance existing tools, not to build new ones. There is now an opportunity for RARE to stimulate and encourage this process of adaptation and enhancement, and the following subsections outline a strategy for this.
セクション2.1で説明されたものなどのアプリケーションの需要を満たすために、共同体は新しいものを築き上げるのではなく、既存のツールを適合させて、高めるのにおいて可能であるところで探されなければなりません。 現在、RAREが適合と増進のこのプロセスを刺激して、奨励する機会があります、そして、以下の小区分はこれのために戦略を概説します。
Adie [Page 71] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[71ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Selecting a System
システムを選択します。
In order to have the greatest effect, RARE should concentrate its efforts on only one of the existing tools. Candidate technologies are those already outlined: Gopher, WWW, WAIS, Hyper-G, Microcosm and AthenaMuse 2.
最もすばらしい効果を持つために、RAREは既存のツールの1つだけで主力を注ぐはずです。 候補技術は既に概説されたものです: ゴーファー、WWW、WAIS、超-G、小宇宙、およびAthenaMuse2。
It is recommended that RARE should select the World-Wide Web to concentrate its efforts on. The reasons for this decision are as follows.
RAREが主力を注ぐWWWを選択するはずであるのは、お勧めです。 この決定の理由は以下の通りです。
o Flexibility. The rich yet straightforward design of WWW,
with its clearly separable components (HTML, URL and HTTP),
means that it is a very flexible basis on which to develop
distributed multimedia applications.
o 柔軟性。 明確に分離できるコンポーネント(HTML、URL、およびHTTP)で、WWWの豊かな、しかし、簡単なデザインは、それが分散型マルチメディアアプリケーションを開発する非常にフレキシブルな基礎であることを意味します。
o Existing efforts. The WWW implementor community is already
discussing and designing extensions to HTML (HTML2),
intended (among other things) to support multimedia. There
is clearly much interest in this area, and RARE efforts
could complement existing work.
o 既存の取り組み。 WWW作成者社会は、既にマルチメディアをサポートすることを意図する(特に)HTML(HTML2)に、拡大について議論して、設計しています。 大きな関心がこの領域に明確にあります、そして、RARE取り組みは既存の仕事の補足となるかもしれません。
o Hyperlinks. A clear requirement of many applications is the
availability of hyperlinking, which WWW supports well.
o ハイパーリンク。 多くのアプリケーションの明確な要件はハイパーリンクする有用性です。(WWWはその有用性をよくサポートします)。
o Integrated solution. Because WAIS, Gopher and Hyper-G (as
well as anonymous FTP servers) may all be accessed from Web
clients, WWW serves as an important integrating tool for
information services. It is important that distributed
multimedia applications, which require extensive support in
the client software, should be based on a technology "close
to" such integrated clients.
o 統合ソリューション。 WAIS、ゴーファー、およびHyper-G(公開FTPサーバと同様に)がウェブクライアントからすべてアクセスされるかもしれないので、WWWは情報サービスのための重要な統合ツールとして機能します。 分散型マルチメディアアプリケーション(クライアントソフトウェアにおける大規模な支持を必要とする)がそのような統合クライアント「近く」で技術に基づいているのは、重要です。
o Penetration and growth. Although Gopher far surpasses WWW
in the number of servers available, the rate of growth in
WWW usage is greater than that of Gopher. There is an
increasing realisation in the community that Gopher is over-
simplistic for many purposes, and a corresponding increase
in interest in WWW.
o 侵入と成長。 ゴーファーである、遠くに凌ぐ、サーバの有効な数におけるWWW、WWW用法による成長率はゴーファーのものより大きいです。 ゴーファーが多くの目的のために過剰安易であるという共同体での増加する認識、およびWWWへの関心の対応する増加があります。
o Attention to QOS issues. There is already an awareness in
the WWW community of the need for achieving an appropriate
QOS, and a mechanism has already been proposed in HTTP2 to
alleviate the problem.
o QOS問題に関する注意。 認識が適切なQOSを達成する必要性のWWW共同体に既にあります、そして、メカニズムは、問題を軽減するためにHTTP2で既に提案されました。
o Standardisation. The WWW team is taking standardisation of
the existing WWW system components seriously. The URL
format has already been published as an Internet draft (and
o 規格化。 WWWチームは真剣に既存のWWWシステムの部品の規格化を受け止めています。 そしてURL形式がインターネット草稿として既に発行された、(。
Adie [Page 72] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[72ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
has been adopted as an important component of the proposed
Internet integrated information infrastructure), and the
current version of HTML is about to follow suit. The use of
SGML as the basis of HTML complies with the perceived
importance of SGML for hypermedia in general (and also fits
in with RARE's approach of adopting appropriate open
standards).
提案されたインターネットの重要なコンポーネントが情報インフラストラクチャを統合したので採用された、)、HTMLの最新版は先例に従おうとしています。 HTMLの基礎としてのSGMLの使用は一般に(そして、また、RAREの適切なオープンスタンダードを採用するアプローチに適応する)、ハイパーメディアのためにSGMLの知覚された重要性に従います。
o Software status. CERN has recently placed the WWW code
developed by it into the public domain. This is unlike all
the other candidate technologies, which all have
restrictions on who can do what with the code. In the case
of Gopher, these restrictions are already causing some
commercial users to look at other options.
o ソフトウェア状態。 CERNは最近、公共の場でそれによって開発されるWWWコードを置きました。 これは他のすべての候補技術すべて、と異なっています。そこには、だれがコードなどの理由でできるかに関する制限があります。 ゴーファーの場合では、これらの制限で、何人かの営利的ユーザが既に別の選択肢を見ています。
WWW has two significant disadvantages, both of which are being alleviated:
WWWには、2回の重要な損失があります:その両方が軽減されています。
o Restricted choice of client software. At present, Apple
Macintosh and PC/MS Windows clients are available in beta
form only. By contrast, there are more than one well-tested
Gopher clients available for these platforms.
o クライアントソフトウェアの選択を制限しました。 現在のところ、アップルマッキントッシュとPC/MS Windowsクライアントはベータフォームだけで手があいています。 対照的に、これらのプラットホームに手があいている1人以上のよくテストされたゴーファークライアントがいます。
However, other WWW clients for the Mac and MS Windows are in
the pipeline.
しかしながら、MacとMS Windowsのための他のWWWクライアントはパイプラインにいます。
o There is a perception in the community that making
information available over HTTP is difficult, and that it
must be put into HTML.
o 知覚が情報をHTTPの上で利用可能にして、難しい共同体にあります、そして、HTMLにそれを入れなければなりません。
However, it is possible to put plain-text, non-HTML
documents onto the Web. Such documents of course cannot
contain links.
しかしながら、それはウェブへのプレーンテキストを置くのにおいて可能で、非HTMLのドキュメントです。 そのようなドキュメントはもちろんリンクを含むことができません。
Furthermore, WYSIWYG HTML text editors are available, to
ease the pain of writing HTML.
その上、WYSIWYG HTMLテキストエディタは、HTMLを書く痛みを緩和するために利用可能です。
The main disadvantages of the other systems are:
他のシステムの主な難点は以下の通りです。
o Gopher is designed for simplicity, and therefore lacks the
flexibility of WWW. In particular its structure is too
inflexibly hierarchical and it does not have hyperlinks.
Its main advantage is its very heavy penetration. However,
because of the WWW approach to accessing data using other
protocols, all of gopherspace is part of the Web. Any Web
client should be able to be a gopher client too.
o ゴーファーは、簡単さのために設計されていて、したがって、WWWの柔軟性を欠いています。特に、構造はあまり不変に階層的です、そして、それには、ハイパーリンクがありません。 主な利点は非常に重い侵入です。 しかしながら、他のプロトコルを使用することでデータにアクセスすることへのWWWアプローチのために、gopherspaceのすべてがウェブの一部です。 どんなウェブクライアントもまた、リスクライアントであることをできるべきです。
Adie [Page 73] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[73ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
It is neither envisaged that Gopher will go away, nor that
it won't be used for multimedia data. However, Gopher is
unlikely to be used for more sophisticated multimedia
applications such as academic publishing, interactive
multimedia databases and CAL, because of the above-mentioned
limitations.
ゴーファーが遠ざかって、それがマルチメディアデータに使用されないのがどちらも考えられません。 しかしながら、学術出版や、インタラクティブ・マルチメディアデータベースやCALなどの、より精巧なマルチメディア応用にゴーファーは使用されそうにはありません、上記の制限のために。
o WAIS is a specialised tool, and will certainly form part of
the overall solution, particularly for database-type
applications. It is not a general solution for distributed
hypermedia applications.
o WAISは専門化しているツールであり、確かに、特にデータベースタイプアプリケーションのために総合的なソリューションの一部を形成するでしょう。 それは分配されたハイパーメディアアプリケーションの一般解ではありません。
o AthenaMuse 2 is commercially-oriented: it is clear that
academic and research users will have to pay to use the
software. Its level of use is thus very unlikely to be as
great as publiclyavailable systems such as WWW. Moreover,
it does not support all the required platforms.
o AthenaMuse2は商業的に指向です: アカデミック、そして、研究ユーザが、ソフトウェアを使用するのを支払わなければならないのは、明確です。 その結果、使用のレベルはWWWなどのpubliclyavailableシステムより非常に同じくらいすばらしそうにはありません。そのうえ、それはすべての必要なプラットホームをサポートするというわけではありません。
o Microcosm network support is still in early stages, limited
at present to the PC/Windows platform. If it can be shown
to perform adequately over a network, if it is capable of
scaling to global levels, and if the advantages of
maintaining link information separately from documents are
found clearly to outweigh the consequent difficulties, it
may become important in the future. Microcosm's authors need
to ensure that the commercialisation of Microcosm does not
hinder its adoption by the academic community.
o まだPC/Windowsプラットホームが現在のところ制限されている初期段階に、小宇宙ネットワークサポートがあります。 ネットワークの上で適切に働くためにそれを示すことができて、それがグローバルなレベルに比例できて、別々にドキュメントからリンク情報を維持する利点が結果の困難を重いように明確に見つけられるなら、それは将来、重要になるかもしれません。 小宇宙の作者は、Microcosmの商業化が学界による採用を妨げないのを保証する必要があります。
o Hyper-G is more difficult to dismiss. It is still in a
relatively early stage of development, but appears to have
many of the necessary features. Its main disadvantages are:
(a) the lack of penetration outside the University of Graz -
the author is aware of only one other site using it; and (b)
it is currently limited to UNIX only. The author believes
that, given WWW's head start in terms of deployment, and the
current progress in adding multimedia facilities to it, WWW
stands a much better chance than Hyper-G of being accepted
as the de facto standard for distributed multimedia
applications on the Internet.
o 超-Gは棄却するのが、より難しいです。 それがまだaにある、比較的、開発の初期段階、必要な特徴の多くを持っているように見えます。 主な損失は以下の通りです。 (a) グラーツ大学の外の溶込み不良--作者は他の1つのサイトだけがそれを使用するのを意識しています。 (b) そして、それは現在、UNIXだけに制限されます。 作者は、展開によるWWWの有利なスタート、およびマルチメディア施設をそれに加えることにおける現在の進歩を考えて、WWWには分散型マルチメディアアプリケーションのためのデファクトスタンダードとしてインターネットに認められるHyper-Gよりはるかに良い見込みがあると信じています。
Directions for RARE
方向、まれ
Earlier in this report, it was noted that the most important areas where effort was needed were (a) provision of facilities for the integrated presentation of multimedia data (including synchronisation issues); and (b) ensuring adequate responsiveness.
より早く、このレポートでは、取り組みが必要であった最も重要な領域がマルチメディアデータの統合プレゼンテーションのための施設の(a)支給(連動問題を含んでいて)であると述べられました。 (b) そして、適切な反応性を確実にすること。
Adie [Page 74] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[74ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
Bearing this in mind, it is recommended that RARE should invite proposals and (subject to funding being available) subsequently commission work to:
これを覚えておいて、RAREが提案を招待するはずであるのが、お勧めであり、次に(利用可能な基金を条件とした)コミッションは以下のことのために働いています。
1. Develop conversion tools from commercial authoring packages
to WWW, and establish authoring guidelines for authors who
wish to use the conversion tools. This is a significant and
high-profile development aimed at enabling sophisticated
multimedia applications to run over the network. (Authoring
guidelines will be necessary to enable authors to fit in
with the Web's way of doing things, and to document features
of the authoring package which should be avoided because of
conversion difficulties.)
1. 商業書いているパッケージからWWWまで変換ツールを開発してください、そして、変換ツールを使用したがっている作者のために書いているガイドラインを確立してください。 これは重要で高姿勢の高度なマルチメディアアプリケーションがネットワークをひくのを可能にするのを目的とされた開発です。 (書いているガイドラインは作者がウェブの物事のやり方と、移行の難易で避けられるべきである書いているパッケージのドキュメント機能にうまくはめ込むのを可能にするために必要になるでしょう。)
2. Implement and evaluate the most promising ways of overcoming
the QOS problem. This is an essential task without which
interactive distributed multimedia applications cannot
become a reality. Some possibilities have already been
outlined in the preceding chapter.
2. QOS問題を克服する最も有望な方法を実装して、評価してください。 これは不可欠のタスクです対話的な分散型マルチメディアアプリケーションが現実のものになることができない。 いくつかの可能性が先の章に既に概説されています。
3. Implement a specific user project using these tools, in
order to validate that the facilities being developed are
truly relevant to actual user requirements. It may be that
partner funding from the selected user project would be
appropriate.
3. これらのツールを使用して、特定のユーザプロジェクトを実装してください、そして、本当に、開発される施設は、それを有効にするために実施している者要件に関連しています。 多分、選択されたユーザープロジェクトからのパートナー基金は適切でしょう。
4. Use the experience gained from 1, 2 and 3 to inform and
influence the further development of HTML2 and HTTP2 to
ensure that they provide the required facilities.
4. 知らせて、HTML2とHTTP2のさらなる開発が、彼らが必要な施設を提供するのを保証するのに影響を及ぼすために1、2、および3から行われた経験を使用してください。
5. Contribute to the development of the WWW clients
(particularly the Apple Macintosh and PC/MS Windows clients)
in terms of their multimedia data handling facilities.
5. 彼らのマルチメディアデータハンドリング施設に関してWWWクライアント(特にアップルマッキントッシュとPC/MS Windowsクライアント)の進化に貢献してください。
Although it is strictly speaking outside the remit of this report (since it is not specifically concerned with multimedia data), it is noted that the rapid growth of WWW may in the future lead to problems through the implementation of multiple, uncoordinated and mutually incompatible add-on features. To guard against this trend, it may be appropriate for RARE, in coordination with CERN and other interested parties such as NCSA, to:
厳密に言うと、それが外である、このレポートを送金してください、そして、(それは明確にマルチメディアデータに関係がないので)WWWの急速な成長が将来複数の、そして、非調整されて互いに両立しないアドオンの特徴の実装を通して問題を引き起こすかもしれないことに注意されます。 RAREに、この傾向に用心するなら、以下のことのためにNCSAなどのCERNと他の利害関係者と共にコーディネートで適切であるかもしれません。
6. Encourage the formation of a consortium to coordinate WWW
technical development (protocol enhancements, etc).
6. 共同体の構成がWWWの技術的な開発(プロトコル増進など)を調整するよう奨励してください。
Adie [Page 75] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[75ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
7. References
7. 参照
[1] "A Survey of Distributed Multimedia Research,
Standards and Products", ed. C. Adie, January 1993
(RARE Technical Report 5).
URL=ftp://ftp.ed.ac.uk/pub/mmsurvey/
[1] 「分散型マルチメディア研究、規格、および製品の調査」、教育。 C。 1993(まれな技術報告書5)年1月のエーディ。 URL= ftp://ftp.ed.ac.uk/pub/mmsurvey/
[2] "The Dexter Hypertext Reference Model", F. Halasz and
M. Schwartz, NIST Hypertext Standardisation Workshop,
January 1990.
1990年1月の[2] 「デクスターハイパーテキスト規範モデル」(F.ハラスとM.シュワルツ)NISTハイパーテキスト規格化ワークショップ。
[3] "Response Time and Display Rate in Human Performance
with Computers", B. Shneiderman, Comp. Surveys 16,
1984.
[3] 「応答時間とディスプレイはコンピュータで人間のパフォーマンスで評価する」B.Shneiderman、コンピュータ。 調査16、1984。
[4] "Gopher+: Proposed Enhancements to the Internet
Gopher Protocol", B. Alberti, F. Anklesaria, P. Linder,
M. McCahill, D. Torrey, Summer 1992.
URL=gopher://boombox.micro.umn.edu:70/11/gopher/gop
her_protocol/Gopher%2b
[4]、「ゴーファー+:」 「インターネットゴーファープロトコルへの提案された増進」、B.アルベルティ、F.Anklesaria、P.ランデール、M.McCahill、D.トーリー、1992年夏。 URL=リス://boombox.micro.umn.edu: 70/11/リス/gopは彼女の_プロトコル/ゴーファー%2bです。
[5] "WAIS Interface Protocol", F. Davies, B. Kahle, H.
Morris, J. Salem, T. Shen, R. Wang, J. Sui and M.
Grinbaum, April 1990.
URL=ftp://quake.think.com/wais/doc/protspec.txt
[5] 「WAISはプロトコルを連結します」、F.デイヴィース、B.カーレ、H.モリス、J.礼拝堂、T.シン、J.スイとM.Grinbaum、R.ワング、1990年4月。 URL= ftp://quake.think.com/wais/doc/protspec.txt
[6] "Uniform Resource Locators", T. Berners-Lee, March
1993. URL=ftp://info.cern.ch/pub/ietf/url4.ps
[6]「Uniform Resource Locator」、T.バーナーズ・リー、1993年3月。 URL= ftp://info.cern.ch/pub/ietf/url4.ps
[7] "The HTTP Protocol as Implemented in W3", T. Berners-
Lee, January 1992.
URL=ftp://info.cern.ch/pub/www/doc/http.txt
[7] 「1992年1月にT.Berners W3"、リーで実装されるHTTPプロトコル。」 URL= ftp://info.cern.ch/pub/www/doc/http.txt
[8] "Protocol for the Retrieval and Manipulation of
Textual and Hypermedia Information", T. Berners-Lee,
1993. URL=ftp://info.cern.ch/pub/www/doc/httpspec.ps
[8] 「原文の検索と操作とハイパーメディアインフォメーションには、議定書を作ってください」、T.バーナーズ・リー、1993 URL= ftp://info.cern.ch/pub/www/doc/httpspec.ps
[9] "Hypertext Markup Language (HTML)", T Berners-Lee,
March 1993. URL=ftp://info.cern.ch/pub/www/doc/html-
spec.ps
[9] 「ハイパーテキストマークアップランゲージ(HTML)」、Tバーナーズ・リー、1993年3月。 URL= ftp://info.cern.ch/pub/www/doc/html- spec.ps
[10] "Hyper-G: A Universal Hypermedia System", F. Kappe and
N. Sherbakov, March 1992. URL=ftp://iicm.tu-
graz.ac.at/pub/HyperG/doc/report333.txt.Z
[10]、「超-G:」 「普遍的なハイパーメディアシステム」とF.KappeとN.Sherbakov、1992年3月。 URL= ftp://iicm.tu- graz.ac.at/パブ/HyperG/doc/report333.txt.Z
Adie [Page 76] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[76ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
[11] "Towards an Integrated Information Environment with
Open Hypermedia Systems", H. Davis, W. Hall, I. Heath,
G. Hill, Proceedings of the ACM Conference on
Hypertext, Milan 1992, p181-190.
[11] 「開いているハイパーメディアシステムがある統合環境情報」、H.デイヴィス、W.Hall、I.Heath、G.ヒル(ハイパーテキストのACMコンファレンスのProceedings、ミラノ1992p181-190)。
[12] "The AthenaMuse 2 Functional Specification", L.
Bolduc, J. Culbert T. Harada, J. Harward, E.
Schlusselberg, May 1992.
URL=ftp://ceci.mit.edu/pub/AM2/funcspec.txt.Z
[12] 「AthenaMuse2の機能的な仕様」(L.Bolduc、J.カルバート・T.原田、J.Harward、E.Schlusselberg)は1992がそうするかもしれません。 URL= ftp://ceci.mit.edu/pub/AM2/funcspec.txt.Z
[13] "Research and Technology Development in Advanced
Communications Technologies in Europe: RACE '92",
CEC, March 1992. Available from:
raco@postman.dg13.cec.be
[13] 「研究と技術開発はヨーロッパの通信技術を中に進めました」。 「92年の競走をしてください」、CEC、3月1992日 利用可能: raco@postman.dg13.cec.be
[14] "Esprit Programme Synopses", CEC, October 1992. In
seven volumes. Available from
esprit_order_mailbox@eurokom.ie
[14] 「エスプリプログラム構文」、CEC、1992年10月。 7本のボリュームで。 esprit_order_mailbox@eurokom.ie から、利用可能です。
[15] "CMIFed: A Presentation Environment for Portable
Hypermedia Documents", G. van Rossum, J. Jansen, K. S.
Mullender, D. C. A. Bulterman, Amsterdam 1993 (also
presented at ACM Multimedia 93 conference).
URL=ftp://ftp.cwi.nl/pub/CWIreports/CST/CSR9305.ps.Z
[15]、「CMIFed:」 「Portable Hypermedia DocumentsのためのPresentation Environment」、G.はロスム、J.ヤンセン、K.S.Mullender、D.C.A.Bulterman、アムステルダム1993(また、ACM Multimedia93会議では、提示される)をバンに積みます。 URL= ftp://ftp.cwi.nl/pub/CWIreports/CST/CSR9305.ps.Z
[16] "The Amsterdam Hypermedia Model: extending hypertext
to support real multimedia", L. Hardman, D. C. A.
Bulterman, G. van Rossum, Amsterdam 1993
URL=ftp://ftp.cwi.nl/pub/CWIreports/CST/CSR9306.ps.Z
[16] 「アムステルダムハイパーメディアはモデル化します」。 「本当のマルチメディアをサポートするためにハイパーテキストを広げてい」て、L.ハードマン、D.C.A.Bulterman、G.はロスムをバンに積んで、1993年のアムステルダムURLは ftp://ftp.cwi.nl/pub/CWIreports/CST/CSR9306.ps.Z と等しいです。
[17] "Deja-Vu Distributed Hypermedia Application
Framework", A. Eliens.
URL=ftp://ftp.cs.vu.nl/eliens/Deja-Vu-proposal.ps
[17] 「デジャヴの分配されたハイパーメディアアプリケーションフレームワーク」、A.Eliens。 URL= ftp://ftp.cs.vu.nl/eliens/Deja-Vu-proposal.ps
[18] "Bento Specification", J. Harris and I. Ruben, Apple
Computer Inc, August 1992.
URL=ftp://ftp.apple.com/apple/standards/Bento_1.0d4.1
[18] 「Bento仕様」とJ.ハリスとI.ルーベン、アップル・コンピューターInc、1992年8月。 URL= ftp://ftp.apple.com/apple/standards/Bento_1.0d4.1
[19] "Davenport Advisory Standard for Hypermedia (DASH),
Module I: Standard Open Formal Architecture for
Browsable Hypermedia Documents (SOFABED)", ed S. R.
Newcomb and V. T. Newcomb.
URL=ftp://sgml1.ex.ac.uk/davenport/sofabed.0.9.6.ps.Z
[19]、「ハイパーメディア(ダッシュ)、モジュールIの大型ソファーの顧問規格:、」 教育の「Browsableハイパーメディアドキュメント(SOFABED)のための標準の開いているホルマール構造」、S.R.ニューカム、およびV.T.ニューカム。 URL= ftp://sgml1.ex.ac.uk/davenport/sofabed.0.9.6.ps.Z
[20] Article in comp.text.sgml newsgroup, 24 May 1993, by
Eliot Kimber (drmacro@vnet.ibm.com).
URL=ftp://ftp.ifi.uio.no/SGML/comp.text.sgml/by.msg
id/19930524.152345.29@almaden.ibm.com
[20] comp.text.sgmlニュースグループにおける記事、エリオットKimberによる1993年5月24日( drmacro@vnet.ibm.com )。 URL= ftp://ftp.ifi.uio.no/SGML/comp.text.sgml/by.msg id/19930524.152345.29@almaden.ibm.com
Adie [Page 77] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[77ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
[21] "Emerging Hypermedia Standards" B. Markey, Multimedia
for Now and the Future (Usenix Conference
Proceedings), June 1991.
[21] 「現れているハイパーメディア規格」B.マーキーと当分間のマルチメディアと未来(Usenix会議の議事録)、1991年6月。
[22] "Initial Draft PREMO (Presentation Environment for
Multimedia Objects", ISO/IEC JTC1/SC24 N847, November
1992.
[22]、「草稿PREMOに頭文字をつけてください、(マルチメディアのためのプレゼンテーション環境が反対する、」、ISO/IEC JTC1/SC24 N847、11月1992日
[23] "Recommended Practices for Multimedia Portability",
Release 1.1 October 1990, Interactive Multimedia
Association, 3 Church Circle, Suite 800, Annapolis,
MD 21401-1993, USA.
「習慣はマルチメディアの移植性のために推薦された」[23]、リリース1990年10月1.1日、インタラクティブ・マルチメディア協会、3が円、スイート800、アナポリス、MD21401-1993、米国を教会に案内します。
[24] "Recommended Practices for Enhancing Digital Audio
Compatability in Multimedia Systems", Release 3.00
1992, Interactive Multimedia Association, 3 Church
Circle, Suite 800, Annapolis, MD 21401-1993, USA.
[24] 「マルチメディア・システムでデジタル・オーディオCompatabilityを高めるための推奨案」、リリース3.00 1992、インタラクティブ・マルチメディア協会、3は円、スイート800、アナポリス、MD21401-1993、米国を教会に案内します。
[25] "RIFF Tagged File Format", Microsoft Inc, 1992.
[25] 「リフのタグ付けをされたファイル形式」、マイクロソフトInc、1992。
[26] "A Vision of an Integrated Internet Information
Service", C. Weider and P. Deutsch, March 1993,
Work in Progress.
[26] 「統合インターネット情報サービスのビジョン」とC.ワイダーとP. ドイツ語、1993年3月は進行中で働いています。
[27] "Delivering Interactive Multimedia Documents over
Networks", S. Loeb, IEEE Communications Magazine, May
1992.
[27] 「インタラクティブ・マルチメディアドキュメントをネットワークの上に提供し」て、S.ローブ(IEEEコミュニケーション雑誌)は1992を提供します。
[28] "A Status Report on Networked Information Retrieval:
Tools and Groups", ed. J. Foster, G. Brett and P.
Deutsch, March 1993.
URL=ftp://mailbase.ac.uk/pub/nir/nir.status.report
[28]、「ネットワークでつながれた情報検索に関する現状報告:」 「道具とGroups」、教育。 J。 フォスターとG.ブレットとP. ドイツ語、1993年3月。 URL= ftp://mailbase.ac.uk/pub/nir/nir.status.report
Adie [Page 78] RFC 1614 Network Access to Multimedia Information May 1994
エーディ[78ページ]RFC1614は1994年5月にマルチメディア情報へのアクセスをネットワークでつなぎます。
8. Security Considerations
8. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
9. Author's Address
9. 作者のアドレス
Chris Adie Edinburgh University Computing Service University Library George Square Edinburgh EH8 9LJ United Kingdom
クリスエーディエディンバラ大学Computing Service大学図書館ジョージ・スクエアエディンバラEH8 9LJイギリス
Phone: +44 31 650 3363 Fax: +44 31 662 4809 EMail: C.J.Adie@edinburgh.ac.uk
以下に電話をしてください。 +44 31 650 3363Fax: +44 31 662 4809はメールされます: C.J.Adie@edinburgh.ac.uk
Adie [Page 79]
エーディ[79ページ]
一覧
スポンサーリンク
