JISC Information EnvironmentTechnical StandardsVersion 1.1 |
  |
JISC Information EnvironmentTechnical StandardsVersion 1.1 |
|
This document provides a list of the key standards and protocols that make up the JISC IE technical architecture [1]. This document is intended primarily for developers, in order to provide them with a single point of reference to the main technologies that they should be using when working in the context of the JISC IE [2].
These standards are intended to apply to all JISC IE service components listed in the JISC IE Glossary [3] (portals, brokers, aggregators, content providers, subject gateways, authentication/authorisation services, service registries, user-preferences services, OpenURL resolvers, institutional profile services, metadata schema registries, terminology services or other shared infrastructure services).
The words must, should and may, when printed in bold text, have precise meanings in the context of this document:
This vocabulary is based on terminology used in Internet Engineering Task Force (IETF) documentation.
This section outlines some broad Web guidelines with which all JISC IE Web sites should comply. In this document, the phrase 'JISC IE Web sites' refers to all Web sites associated with JISC IE service components.
JISC IE Web sites must be delivered using HTTP 1.1 [4].
JISC IE Web sites should be accessible to all. All sites must achieve level A compliance with the The World Wide Web Consortium (W3C) Web Accessibility Initiative Recommendations (WAI) [5]. All sites should also achieve level AA compliance. This will ensure a high degree of usability for people with disabilities. Web sites should be accessible to a wide range of browsers and hardware devices (e.g. PDAs as well as PCs). Sites should be usable by browsers that support W3C recommendations such as HTML/XHTML [6], Cascading Stylesheets (CSS) [7] and Document Object Model (DOM) [8].
This document currently makes no specific recommendations about the file formats that should be used for various resource types (text, images, sounds, etc.). Such recommendations are made in the Standards and Guidelines to Build a National Resource [9] document (though it should be noted that this document is currently undergoing revision). However, sites should make use of open or de-facto standards whenever possible.
Every significant item that is made available through a JISC IE network service should be assigned a URI [10] that is reasonably persistent. This means that item URIs should not be expected to break for a period of 10-15 years after they have first been used. For this reason, JISC IE service components should not hardcode file format, server technology, service organisational structure or other information that is likely to change over a 10-15 year period into item URIs. If items become unavailable during that period, then the URI should resolve to a Web page that explains why the item is no longer available and what actions the end-user can take to obtain a copy of the item or similar resources. Furthermore, item URIs should not contain end-user-specific information, i.e. all item URIs should work for all end-users (albeit allowing for appropriate authentication challenges to be inserted into the process by which the URI is resolved).
Resources that comprise a collection of items that are packaged together for management or exchange purposes should be packaged using the IMS Content Packaging Specification [11] if they are 'learning objects' (i.e. resources are primarily intended for use in a learning and teaching context and that have a specific pedagogic aim) or the Metadata Encoding & Transmission Standard (METS) [12].
Where distributed searching is used within the JISC IE, service components must use either Z39.50 version 3 [13] or SRW/SRU version 1.1 [14].
All use of Z39.50 in the JISC IE must conform to Functional Area C Level 1 of the Bath Profile - release 2 [15]. Therefore, all JISC IE Z39.50 targets must be able to return simple Dublin Core [16] metadata records as search results, encoded according to the Bath Profile XML DTD. Service components that offer a Z39.50 target that is considered to be of value to the learning and teaching community should also consider returning metadata records that conform to the UK LOM Core [17] in line with the IMS Digital Repositories Specification [18] using the IEEE LOM XML schemas.
Service components that offer an SRW target must support the simple Dublin Core record format defined by the SRW DC XML schema. Service components that offer an SRW target that is considered to be of value to the learning and teaching community should also consider returning metadata records that conform to the UK LOM Core using the IEEE LOM XML schemas.
All JISC IE content providers should support either a distributed search interface or a metadata harvesting interface.
Where metadata harvesting is used within the JISC IE, service components must use the Open Archives Initiative Protocol for Metadata Harvesting version 2.0 [19].
All JISC IE service components that offer an OAI-PMH repository must support the simple Dublin Core record format ('oai_dc') defined by the OAI-PMH DC XML schema. Service components that offer an OAI-PMH repository that is considered to be of value to the learning and teaching community should also consider exposing metadata records that conform to the UK LOM Core in line with the IMS Digital Repositories Specification using the IEEE LOM XML schemas.
All JISC IE content providers should support either a distributed search interface or a metadata harvesting interface.
Where news channels are offered within the JISC IE, service components should use RDF Site Summary (RSS) 1.0 [20]. However, if necessary, service components may choose to use either RSS 0.91, RSS 0.92 or RSS 2.0 as alternatives to this format.
RSS channels must be made available using HTTP 1.1 and should be assigned an 'application/xml+rss' MIME type.
Alerting services within the JISC IE should be based on either RSS or email.
Where context-sensitive linking is used within the JISC IE, service components must use OpenURLs that conform to the OpenURL version 0.1 specification [21] or the OpenURL version 1.0 specification [22].
All JISC IE structured network services not covered by the specific cases listed above should be offered using the Simple Object Access Protocol (SOAP) version 1.2 [23] (or, in some cases, SOAP version 1.1). Alternatively, the use of HTTP 1.1 GET or POST requests to return XML [24] documents may be appropriate.
The preferred solution for access management within the JISC IE is for institutions and service providers to adopt SAML-compliant technologies via the UK Access Management Federation [25]. The JISC IE will also continue to support use of the Athens access management system [29] until July 2008 through the implementation of gateways allowing both Athens institutions and Athens Service Providers access to the Federation. Gateway requirements will be reviewed in 2008.
For Athens users, the IE permits an exception to be made for authentication that is used internally within an institution, e.g. for access to local resources within an institutional portal. An advantage of the distributed access management used in the UK Access Management Federation is that a participating institution's internal authentication can be used to enable access to both internal and external resources (a single sign-on).
All usage of Dublin Core metadata within the protocols listed above should conform to the Using Dublin Core document [26].
All significant collections and services made available within the JISC IE should be described according to the specifications being developed by the JISC IE Service Registry pilot project [27][28].
All JISC IE service components that require knowledge about available collections and services (e.g. portals, brokers and aggregators) should consider how they will make use of the JISC IE Service Registry at an appropriate point in the future.
$Id: intro.html,v 1.14 2005/10/19 11:04:25 lisap Exp $