QA Focus Briefing Documents: Print All - General
[ Home Page - Surveys - Documents - Presentations - Search ]
This page is for printing out briefing papers on general issues. Note that unfortunately the internal links may not work.
A project's Web site address will provide, for many, the best means for finding out about the project, reading abouts its activities and using the facilities which the projects provides. It is therefore highly desirable that a project's Web site address remains stable. However there may be occasions when it is felt necessary to change a project's Web site address. This document provides advice on best practices which should help to minimise problems.
Ideally the entry point for project's Web site will be short and memorable. However this ideal is not always achievable. In practice we are likely to find that institutional or UKERNA guidelines on Web addresses preclude this option.
The entry point should be a simple domain name such as <http://www.project.ac.uk/> or a directory such as <http://www.university.ac.uk/depts/library/project/>. Avoid use of a file name such as <http://www.university.ac.uk/depts/library/project/index.html> as this makes the entry point longer and less memorable and can cause problems if the underlying technologies change.
If the address of a project Web site is determined by institutional policies, it is still desirable to avoid changing the address unnecessarily. However there may be reasons why a change to the address is needed.
Projects should consider potential changes to the Web site address before the initial launch and seek to avoid future changes or to minimise their effect. However if this is not possible the following advice is provided:
This information will give you an indication of the impact a change to your Web site address may have. If you intend to change the address you should:
It is advisable to check links prior to the change and afterwards, to ensure that no links are broken during the change. You should seek to ensure that links on your Web site go to the new address.
Instant messaging (IM) is growing in popularity as the Internet becomes more widely used in a social context. The popularity of IM in a social context is leading to consideration of its potential for work purposes in providing real time communications with colleagues and co-workers.
Popular IM applications include MSN Messenger, Yahoo Messenger and AOL Messenger [1]. In addition to these dedicated applications a number of Web-based services also provide instant messaging facilities within the Web site, such as YahooGroups [2]. The JISCMail list management service also provides a Web-based instant messaging facility [3].
Instant Messaging software can provide several benefits:
Instant messaging fans appreciate the immediacy of communications it provides, which can be particularly valuable when working on small-scale concrete tasks.
There is a need to be aware of potential problems which can be encountered when using instant messaging software:
Critics of instant messaging argue that, although IM may have a role to play for social purposes, for professional use email should be preferred.
Instant messaging may prove particularly useful when working with remote workers or if you are involved in project work with remote partners. However in order to make effective use of instant messaging tools there is a need to implement a policy governing its usage which addresses the problem areas described above.
As an example of a policy on use of instant messaging software see the policy produced for the QA Focus project [7] together with the QA Focus case study [8]. As an example of use of IM in an online meeting see the transcript and the accompanying guidelines at [9].
Audio and video applications are being increasingly used to support project working across distributed project teams. This document aims to give a brief description of audio and video tools which can be used to support such collaborative work within our institutions and to summarise the main challenges to be faced when considering their deployment across organisations.
The growth in broadband is leading to renewed interest in audio and video-conferencing systems. In the past such services often required use of specialist hardware and software. However tools are now being developed for home use. This briefing document explores some of the issues concerning use of such technologies within an institution.
The Skype Internet telephony system [1] is growing in popularity.
Skype is popular because it can provide free calls to other Skype users.
In addition Skype has potential for use in an academic context:
It should be noted, however, that Skype is a proprietary application and concerns over its use have been raised.
Instant Messaging clients such as MSN Messenger [2] also
provide audio and video capabilities. Such tools can raise expectations of student
users who may wish to use such tools for their own use.
It should be noted, however, that there are interoperability problems with such tools (e.g. both users may need to be running the latest version of the MS Windows operating system). In addition the management of user IDs and setting up areas for group discussions may be issues.
An alternative approach is use of software such as VRVS [3], an Access Grid application. This Web-based system provides managed access to virtual rooms, etc. VRVS is intended for use by GRID users and not be appropriate for certain uses. However it illustrates an alternative approach.
Issues which need to be addressed when considering use of such tools include
Podcasting has been described as "a method of publishing files to the internet, often allowing users to subscribe to a feed and receive new files automatically by subscription, usually at no cost." [1].
Podcasting is a relatively new phenomena becoming popular in late 2004. Some of the early adopters regard Podcasting as a democratising technology, allowing users to easily create and publish their own radio shows which can be easily accessed within the need for a broadcasting infrastructure. From a technical perspective, Podcasting is an application of the RSS 2.0 format [2]. RSS can be used to syndicate Web content, allowing Web resources to be automatically embedded in third party Web sites or processed by dedicated RSS viewers. The same approach is used by Podcasting, allowing audio files (typically in MP3 format) to be automatically processed by third party applications - however rather than embedding the content in Web pages, the audio files are transferred to a computer hard disk or to an MP3 player - such as an iPod.
The strength of Podcasting is the ease of use it provides rather than any radical new functionality. If, for example, you subscribe to a Podcast provided by the BBC, new episodes will appear automatically on your chosen device - you will not have to go to the BBC Web site to see if new files are available and then download them.
Note that providing MP3 files to be downloaded from Web sites is sometimes described as Podcasting, but the term strictly refers to automated distribution using RSS.
There are several potential applications for Podcasting in an educational context:
Although there is much interest in the potential for Podcasting, there are potential problem areas which will need to be considered:
It would be advisable to seek permission before making recordings or making recordings available as Podcasts.
It is advisable to gain experiences of Podcasting initially as a recipient, before seeking to create Podcasts. Details of Podcasting software is given at [3] and [4]. Note that support for Podcasts in iTunes v. 5 [5] has helped enhance the popularity of Podcasts. You should note that you do not need a portable MP3 player to listen to Podcasts - however the ability to listen to Podcasts while on the move is one of its strengths.
When creating a Podcast you first need to create your MP3 (or similar) audio file. Many recording tools are available, such as the open source Audacity software [6]. You may also wish to make use of audio editing software to edit files, include sound effects, etc.
You will then need to create the RSS file which accompanies your audio file, enabling users to subscribe to your recording and automate the download. An increasing number of Podcasting authoring tools and Web services are being developed [7] .
The e-Framework is an initiative by the UK's Joint Information Systems Committee (JISC), Australia's Department of Education, Science and Training (DEST) and partners to produce an evolving and sustainable, open standards based, service oriented technical framework to support the education and research communities.
The e-Framework supports a service oriented approach to developing and delivering education, research and management information systems. Such an approach maximises the flexibility and cost effectiveness with which systems can be deployed, both in an institutional context, nationally and internationally.
The e-Framework allows the community to document its requirements and processes in a coherent way, and to use these to derive a set of interoperable network services that conform to appropriate open standards. By documenting requirements, processes, services, protocol bindings and standards in the form of 'reference models' members of the community are better able to collaborate on the development of service components that meet their needs (both within the community and with commercial and other international partners). The 'e-Framework' also functions as a strategic planning tool for the e-Framework partners.
The initiative builds on the e-Learning Framework [1] and the JISC Information Environment [2] as well as other service oriented initiatives in the areas of scholarly information, research support and educational administration. A briefing paper that provides an overview of the e-Framework [3] and how the partners intend to use it can be found in the resources section [4].
The e-Framework Partnership intends to operate in accordance with the following guiding principles:
A service-oriented framework provides significant benefits to stakeholders including policy makers, managers, institutions, suppliers and developers and is a business driven approach for developing ICT infrastructure that encourages innovation by being agile and adaptive.
A service-oriented framework currently provides the best means of addressing systems integration issues within institutions, between institutions and across the domains within education and research.
The definition of services is driven by business requirements and processes. The factoring of the services is a key to the effectiveness of the framework.
A high level 'abstract' service definition should not duplicate or overlap another service. An abstract service definition is a description of a service that is independent of the language or platform that may be used to implement the service.
The e-Framework activities will strive for technical excellence and adoption of co-developed good practices.
Open standards are key to achieving integration between systems, institutions and between domains in the education and research communities. Open standards are defined for the e-Framework as those standards that are developed collaboratively through due process, are platform independent, vendor neutral, extensible, reusable, publicly accessible and not encumbered by royalties. In order to achieve impact open standards require international collaboration and consensus.
Framework. Collaboration between technical and domain experts, practitioners, developers and vendors will be essential to the evolution and uptake of the e-Framework approach. Capacity and capability will need to be developed
In order to support evolution of the e-Framework, results will be publicly available. Engagement with communities of use will be essential in the development of the e-Framework. Sustained international development of the e-Framework cannot be undertaken by a single organisation and collaboration between organisations is required. Where possible and appropriate, Open Intellectual Property licensing approaches (such as open source, Creative Commons, royalty free patent licences) will be adopted.
The e-Framework supports and promotes flexible deployment by institutions and facilitates incremental deployment and change. The e-Framework will accommodate both open source and proprietary implementations. Institutions will decide whether to use open or closed source implementations in deploying the e-Framework
The e-Framework's founding organisations, DEST and JISC, have devised a temporary model for the management of and engagement with the e-Framework designed to support the incubation and nurture of the e-Framework, throughout the critical early years of development. The governance and stewardship structures will be iteratively refined as part of the e-Framework work plan.
This document is a modified version of a document on "The e-Framework for Education and Research" published on the E-Framework Web site at <http://www.e-framework.org/about/> (version last modified on 2005-10-16 11:05 PM).
The document was originally written by Wilbert Kraan, CETIS and has been republished as a QA Focus briefing document. We are grateful to Wilbert for permission to reprint this document.
There are a wealth of services available on the Web. The high-profile examples are Amazon and Google APIs, which cover services as diverse as ISBN lookups, book cover image retrieval, Web search, spell-checking and geographical mapping, but many other services are available, performing all sorts of task from library access to instant price quotes and reviews for shopping sites. Some services perform a large and complex task, others perform a single task, and all speak different 'languages', from SOAP (Simple Object Access Protocol) to REST (Representational State Transfer).
For any given Web-based problem, there is an excellent possibility that a service is available that offers useful functionality. Unfortunately, finding these services is not always easy, but the process is greatly facilitated by using a service registry, designed to allow developers to register their services and for anybody, developer or end-user, to locate useful services. A service registry is an important part of any service-oriented architecture.
Various service registries already exist. The first major standard to appear was UDDI (Universal Description, Discovery and Integration), which was designed mostly with SOAP-based Web services in mind. UDDI was originally designed with the idea that there would be very few service registries needed - like the Yellow Pages, there would be one central source of information, which would be available from a number of places, but each one would offer the same content. Several other types of service registry exist, such as the JISC's IESR (Information Environment Service Registry) project [1], which focuses on improving resource discovery mechanisms for electronic resources, that is, to make it easier to find materials to support teaching, learning and research. This briefing paper focuses on UDDI, although it is important to realise that the original UDDI standard has now been replaced by UDDI v3 [2] and is no longer generally used as part of a centralised approach. Instead, many organisations use corporate UDDI servers that are not publicly accessible.
Why Use Service Registries?Service registries can be accessed in a number of ways. Most can be accessed via a Web interface, so if one is looking for a service or type of service, one can use a service registry like a typical search engine, entering keywords and reading textual descriptions of each service. However, many registries are designed to permit a second mode of use, where services are described in a machine-readable way. This means that, should one service become unavailable, the systems that were using that service can search the service registry for a second, compatible service that could be used in its place.
UDDI can be used in two ways, because it is both a service registry and a business registry. One can look up businesses or organisations in the business registry, or search for services by description or keyword - UDDI also supports a formal taxonomy system that can be used for formally classifying services. It is sometimes more effective to begin searching for a service by looking at known providers. When an appropriate service has been found, it can be used at once; the UDDI server provides not only the name and description of services, but also information about where the Web service can be found, what protocol should be used to communicate with it, and details of the functionality that it can provide. Adding new services to a UDDI service registry may be done either using a Web interface designed for administrative access, or through an API (application program interface). Each different type of service registry supports its own method or methods - for example, the IESR service registry provides a Web form through which services can be added, or an XML -based service submission function.
When adding data to any sort of service registry, it is important to ensure that the data is provided in the form recommended by the registry. Malformed entries will not be searchable, and may confuse other users. Equally, once you have listed a service in a service registry, remember that if the service is moved, shut down or altered, it will also be necessary to update the listing in the registry.
Service registries are an important part of the service-oriented Internet, automating and simplifying resource discovery. However, there is no single standard for service registries; as of today, each group has its own resource discovery strategy. Taking part in a service registry will generally lead to additional exposure for the listed services and resources, but does convey the additional responsibility of ensuring that listings remain up-to-date.
[ Home Page - Surveys - Documents - Presentations - Search ]
Web page by Emma Tonkin of UKOLN.
Last Modified 6-August-2012
Email comments to webmaster@ukoln.ac.uk