Technical Standards for the JISC IE (part 2)

Paul Walk — Tue, 27 Apr 2010 09:05:00 +0000

Which standards are relevant to the JISC IE today? The JISC IE Technical Standards document has not been updated for some years. If this sort of document is considered to be useful still, then it needs to be brought up to date. The rest of this post will consider the standards indicated in the original document and give suggestions for what might be added, changed or deprecated from this list. Comments are very welcome on this. For the sake of clarity, 'original document' means the Technical Standards document in its current revision which was last edited 16/05/2006. The standards listed in the original document were structured into functional grouping as below. We might not use exactly these groupings or names in future, but they seem to me to be sufficiently handy to use here: Web standards and file formats Standards listed:

HTTP 1.1,WAI,HTML/XHTML,CSS,DOM,URI,IMS Content Packaging Specification,METS

One of the easier groups perhaps, with standards such as HTTP 1.1 being so ubiquitous that it would be idle to argue against their importance to the JISC IE. The clear statement invoking 'must' and 'should' around the different levels of WAI compliance would seem to continue to be appropriate. The area which might need revision is the recommendation to use IMS Content Packaging or METS for packaging content into re-deployable objects. It could be argued that this sort of packaging, once seen as a clear path towards encouraging the re-use of content, is not perhaps such a priority in an environment which has begun to favour access to atomic content artefacts with a view to remixing at the point of need. Questions:

To what extent has aggregation superseded packaging?
Should standards such as Atom be referenced here?
Is it sensible to create a new section combining packaging and aggregation as related approaches

Distributed searching Standards listed:

Z39.50,SRW/SRU,Bath Profile,UK LOM Core,IMS Digital Repositories Specification,Dublin Core

Distributed searching, as an approach, has been somewhat deprecated in general terms in favour of the harvest and index approach used by search engines such as Google. However, in the more library-oriented parts of the JISC IE protocols such as Z39.50 are still widely used today. Attempts over the years to replace this with more 'modern' technologies have met with limited success although SRW and SRU have had some take-up. Similarly SOAP which underpins SRW is, in some quarters, being deprecated in favour of a more RESTful approach such as that offered by SRU. Questions:

should we be advocating the continued development of distributed searching?
is the recommendation: "all JISC IE content providers should support either a distributed search interface or a metadata harvesting interface." still good?

Metadata Harvesting News and alerting Context-sensitive linking Transactional services Authentication and authorisation Metadata usage guidelines NB. Standards = protocols, standards, specifications, application profiles etc. The IE might identify core standards, e.g.:

HTTP
XML
RDF
UTF-8

Important, generic standards:

RSS/Atom
Dublin Core

Important, domain-specific standards:

Bibliographic standards
DOI

Standards being developed within the IE, e.g.:

SWORD
SWAP etc.

One of the key conclusions emerging from our ongoing consultation with some of those who have been involved with the JISC Information Environment (JISC IE) since its early days is that the emphasis on interoperability through open standards was one of the key drivers which gave the programme direction and momentum. Giving focus to this emphasis on open standards was a web document, JISC Information Environment Technical Standards, which introduced itself thus:

This document provides a list of the key standards and protocols that make up the JISC IE technical architecture. 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.

These standards are intended to apply to all JISC IE service components listed in the JISC IE Glossary (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).

It has been suggested by more than one of those with whom we have consulted that this document was the most important of the several documents developed by UKOLN (primarily by Andy Powell) to technically inform what was then designated the JISC Information Environment Architecture. It gave those developing services in the JISC IE a touchstone, allowing them to validate that their work was in accordance with one of its over-arching principles. During our consultations, we have heard more than once that this document was more important than the perhaps more widely recognisable Technical Architecture diagram.

The document borrows the Internet Engineering Task Force (IETF) convention of using the words must, should and may (in a bold typeface) in a particular way to convey a more precise indication of the strength of recommendation or requirement being articulated. Nevertheless it has, for some, been unclear whether or not this document was intended to mandate or to advise on the use of technical standards in the JISC IE. Although the IETF convention was not applied to the document’s introduction, it seems reasonable to take the line that when the author said:

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.

we might reasonably interpret that use of the word ‘should’ in the IETF sense, to mean:

should – indicates that there may exist valid reasons not to treat this point of guidance as an absolute requirement, but the full implications should be understood and the case carefully weighed before it is disregarded

So, it is reasonable to argue that the JISC IE was, at a technical level, based on an identification of appropriate technical standards. We will assume that the provision & maintenance of such a document is still useful which means that, in looking forward to the future, two questions present themselves:

Should the document be ‘prescriptive’ or ‘descriptive’?
Which standards are relevant to the JISC IE today?

For this post, we’ll address the first of these questions – a second post, which will appear in a few days, will address the other.

Prescriptive or descriptive?

Should our ongoing identification and documentation of the next iteration of what we are now calling the JISC IE Technical Foundations take a prescriptive (‘must’) or descriptive (‘may’) approach to its treatment of technical standards?

It has been suggested that the original, somewhat prescriptive approach had the effect of embedding the belief of the importance of shared, open standards for interoperability into the culture of those developing services for the JISC IE. But it has also been suggested that this cultural acceptance has now been achieved and that developers can be trusted to assume the need for interoperability and, consequently, be given freedom to innovate where appropriate.

Is the importance of open standards now so widely accepted that we can assume that developers will make sensible choices, balancing the need for interoperability with the desire to innovate?

JISC IE: relevant content on this site

Technical Standards for the JISC IE (part 2)

Technical Standards for the JISC IE (part 1)