📄 rfc1614.txt
字号:
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?". 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. NetworkAdie [Page 17] RFC 1614 Network Access to Multimedia Information May 1994 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 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 Multimedia news bulletins (e.g., the Internet Talk Radio, which is sound only). o Product information (the multimedia equivalent of paper advertising matter). 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.2.2. Data Characteristics 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 Implementing corrections and improvements to the data is very much easier. o It is more readily available to the data user - no purchase/delivery cycle need exist.Adie [Page 18] RFC 1614 Network Access to Multimedia Information May 1994 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 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 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 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. 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 Easier to deter or prevent copyright infringement, using traditional copy-protection techniques.2.3. Requirements Definition 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/serverAdie [Page 19] RFC 1614 Network Access to Multimedia Information May 1994 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. There are other systems, such as VAX/VMS, which are also important in some sectors. 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. 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. 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. 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 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 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 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 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 clipAdie [Page 21] RFC 1614 Network Access to Multimedia Information May 1994 (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. 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.) 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.)Adie [Page 22] RFC 1614 Network Access to Multimedia Information May 1994⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -