Lost in the JISC Information Environment
The Resource Discovery iKit [1] is the result of a recently completed project to produce an information kit for tools and reports related to resource discovery created by JISC-funded projects and services. Created by the Centre for Digital Library Research at the University of Strathclyde, the iKit has exploited the Centre’s expertise in the area of digital libraries to create a dynamic retrieval system which uses multi-faceted control vocabularies to allow researchers and developers a quick and easy interface for the discovery and retrieval of a comprehensive range of quality-assessed resources. The production of such controlled vocabularies has entailed a high-level analysis of both the language and technologies used by the JISC community.
Given the iKit’s brief to describe resource discovery tools, this taxonomic and technological analysis has required particularly close examination of the JISC Information Environment 2 and its underlying documentation, authored in large part by Andy Powell. This documentation, along with the near ubiquitous IE architecture diagram, provided this author, as project officer for the iKit project, with an excellent orientation in the scope and purpose of current JISC research into resource discovery. Such close scrutiny, however, means the author is perhaps well placed to offer, in turn, a high-level view of the design of the IE, its underlying architecture, and the way in which such attempts to describe and document an essentially ephemeral concept in specific language has perhaps led to misunderstanding or confusion over the extent to which, in philosophical terms, the IE has existence.
Figure 1: JISC Information Environment Architecture [3]
In particular, the author seeks answers to the following questions which occurred during his work with the IE:
- What is the purpose of the IE, what are the particular problems it was originally envisioned to address?
- Is it possible, or even necessary to attempt, to define the IE in a holistic way; is it rather a mere description of the possible ways a number of independent technological services and processes might interact in a process of resource discovery, retrieval and use?
- To what extent was/is the IE intended to be prescriptive or descriptive, what is the importance of this distinction?
- What problems or issues have arisen as a result of lack of clarity in these questions?
What Is It For?: The Purpose of the IE
What were the particular problems the IE was envisioned to address? That this is not a simple question to answer is indicated by the words of Peter Brophy, leader of the EDNER project which sought to evaluate the IE and its forerunner, the DNER, from 2000 to 2004: “We realised … that it was critical to try to elucidate exactly what the DNER was or was aiming to be – and we found that the answer was by no means straightforward. Exactly the same concern can be expressed about the current IE.” [4]
As said, the IE was built upon work done on the Distributed National Electronic Resource (DNER), described by Andy Powell and Liz Lyon as “a JISC-funded, managed, heterogeneous collection of information resources and services … of particular value to the further and higher education communities”. They go on to advise that the IE was envisioned to implement a “set of networked services that allows people to discover, access, use and publish resources within the DNER” [5]. Over time the term DNER fell from favour and the IE term is now effectively used to describe all work done in this area.
The need for work in this area was made clear by the JISC Information Environment: Development Strategy 2001-2005 [6]. This document described the fragmented nature of online services providing digital resources at that time, and the consequent requirement for users to “navigate a complex set of different websites with different search interfaces” and “lack of mediation to provide vital signposts to explain context and relevance to the user”. It was recognised that these constituted barriers to the take-up of digital resources by the HE/FE community. Hence, the IE was, at root, proposed as a way to bring integration and coherence to the use of digital resources in order to encourage take-up among users. It is against this core aim that the IE must be understood.
Even at this early stage however, it was acknowledged that complete homogeneity within the IE was impossible. Two intractable factors were recognised by the IE strategy document: (1) that digital resources are “inherently distributed”, i.e. that it is necessarily the case that they are delivered by multiple service providers, and (2) that “users do not all want to access information in the same way but will require a diverse range of views of resources in order to satisfy their needs” [7].
Thus while content provision is necessarily heterogeneous and distributed, users want diverse and personalisable services by which to access them. These factors are key: they motivate the need for the work done under the IE title. By showing total homogeneity to be impossible, however, they also remind us that the IE as an architecture can never be complete, that it is only an abstract conceptual model. There is a danger that in seeking to aid the understanding of work done in the area of resource discovery, access and use that we misunderstand the purpose of the IE model. It is an abstract model to aid understanding; it is not an architectural blueprint. That the architecture diagram provides such a visually striking, seemingly easily understood, sketch of this abstract model has perhaps propagated a fallacious sense of the degree to which the IE can be said to exist.
In short, the implicit investment of too much belief in the existence of the IE concept, and of authority in the IE diagram, might allow the JISC community to envisage that they are involved in the construction of something less nebulous, ephemeral, and disjointed than they would prefer to believe.
Can It Exist?: The Architecture of the IE
UKOLN’s 2001 study, The DNER Technical Architecture: scoping the information environment, was the first attempt to define the DNER as a technical architecture, with the intention to “underpin the development of the DNER as a managed collection of resources in an integrated information environment.” [8]. To this end, the authors developed a conceptual architectural model which split IE services into four broad classes of activity, namely:
- provision - the storage and delivery of content,
- fusion - the bringing together of metadata about content from multiple providers,
- presentation - interaction with the end-user, and
- infrastructure - shared services that support other activities
This basic conceptual division between services has persisted throughout the development of the Information Environment. From the start, however, the authors of this architecture sought to make it explicit that these broad conceptual distinctions were, to a greater or lesser extent, artificial:
Typically, services will not fall cleanly into these four categories. For example, portals are likely to engage in both presentation and fusion activities, content providers will engage in provision and presentation, etc. [9]
Building upon these four basic service distinctions, Andy Powell created the Information Environment architecture diagram in 2003 (see Figure 3 below). The diagram aimed to align various technical and conceptual service features with this four-faceted conceptual view of services. The result was an abstract architectural model which sought to aid visualisation of the ways in which services might interact.
Figure 3: IE architectural diagram (2003) [11]
It is important here to note that the author of the diagram, even upon its introduction, gave explicit caveats as to the amount of authority he believed ought to be invested in it. Thus, in separate instances, he states the diagram to be neither “intended to be definitive” [12], nor “intended to be a straightjacket into which all services must neatly fit” [13].
Prescription or Description? The Authority of the IE Architecture
Here, we might do well to ask a key question: Was the IE architectural diagram intended to be prescriptive or descriptive of the nature of the JISC IE? That is, did it seek to prescribe what was required to constitute an ‘information environment’ or to describe components which either already existed or were in the process of being created? This question is important because confusion between prescription and description exists implicitly in the use of the architecture metaphor. While architectural blueprints for a building will necessarily precede a building’s construction, we can also talk of the ‘architecture’ of an existing building, to mean its design and structural features. This duality of meaning must be made explicit to avoid conceptual drift in our use of that metaphor.
Where the IE architecture might be seen to be most prescriptive is in the area of shared infrastructure services. There, solid units of functionality are envisioned to be necessary to support the control of meta-metadata in the IE, in order to support a common information culture. Thus, the metadata schema registry will hold authority data on types of metadata used within the IE, etc. Even here, though, a descriptive rather than prescriptive nature is described by Powell:
The list of infrastructural services shown on the JISC IE architecture diagram … was not intended to be exhaustive. As the community and landscape evolves we can expect to see new shared services being developed, both within and without the JISC community. [14]
Problems and Issues: Getting Lost in the IE
The IE architecture was intended to be a working model, an aide to assist conceptualisation of an essentially abstract concept. We might ask, though, to what extent this mutability has been ignored as the clarity which the diagram sought to bring was valued too highly, and allowed it to fix in people’s minds. Powell, in a 2007 posting on his efoundations blog, reflected on time spent in meetings about JISC shared services:
My JISC IE architecture diagram has stood the test of time, but not without some problems. One problem is that the rigidity of the diagram doesn’t reflect the messiness of the real-world. The truth is that there are no service boxes like the ones on the diagram in [real life]. It’s a myth - a sometimes helpful myth, but still a myth. [15]
He argues that this becomes problematic when JISC funds programmes based on these labels, citing the Portals Programme as an example. He goes on to refer to an attempt to define the word registry which failed to produce a definition that couldn’t just as well be applied to the word catalogue, worrying that despite this, “JISC funds cataloguing activity (e.g. Intute) as though it was completely separate from, and different to, registry activity.” In a response to a blog posting by Brian Kelly, Powell continues this theme: “One of the problems with the diagram was that it mixed up conceptual bits of functionality with actual boxes on the network.” Continuing the theme of the diagram as not reflecting the “messiness” of the real world, he goes on to say:
It wasn’t particularly intended to - but perhaps I didn’t make that clear enough. To be honest, I probably didn’t even recognise that when the diagram was first developed … As a result, we (the JISC community) ended up taking the boxes and layers in the diagram perhaps too literally on occasion. [16]
So, for Powell, it is obvious that the key virtues of the architectural diagram (those which have made it so popular over time), i.e. its clarity and ability to be easily understood, might also have implicitly oversimplified a very complex area of research, and have made the IE seem too structured in nature. It is clear, then, that a note of caution might be timely, to remind ourselves within the JISC community that the JISC IE architecture diagram is not a blueprint in the architectural sense – to a certain extent, it is merely descriptive of a combination of actual technical features and abstract digital library functions.
To these problems, we might add the quite spectacular fall from favour of the ‘portal’ concept, as it has come to be seen as so universally applicable as to be almost meaningless. The iKit thesaurus still uses the term, as it is so ubiquitous within literature written about the IE as to be inescapable.
The provision layer, upon inspection, also proves problematic. While other areas of the diagram are carved up according to their technical function or service, the components of the provision layer are distinguished only by the origin of content (i.e., JISC-funded, institutional and external content providers). While this distinction might have important implications for issues such as intellectual property rights, is it really important enough to distinguish IE content provision in this way? Is it perhaps the case that provision was taken to be a mere vanishing point for the IE, and that those boxes are mere placeholders, existing for the purpose of symmetry? The iKit IE thesaurus, having to deal only with resource discovery outputs, thankfully did not attempt to define this area any further. It is suggested here, however, that this remains an open question.
Conclusion
The shape, scope, and eventual architecture of the IE should be determined only by the functional needs of end-users and institutions in UK HE/FE and by the limits of available technologies. There are two problems attendant upon Powell’s IE architectural model. Firstly, while it is very helpful, perhaps crucial, to present a structured and holistic view of the progress of research conducted under the IE concept, the diagram perhaps lends itself to the misinterpretation that it exists to act deterministically. As we have seen, this is not the case; the IE diagram assists but does not dictate the outcomes of IE research.
Secondly, there is also the danger that an impossible homogeneity might be implied. While it might provide consolation to the JISC community to be able to point towards a seminal diagram and say “we are building this”, especially given the essential ephememerality and necessary pragmatism in our area of research, this must not be allowed to skew perceptions of the (lack of) structure in what we do. The IE does not, can not, have existence. The term is a description of a set of interoperable services and technologies which have been created to enhance the resource discovery access and use for users in HE/FE; it exists to aid conceptualisation of this ephemeral subject. No more, no less.
Figure 4: A true JISC Information Environment architecture? [17]
References
- JISC Resource Discovery iKit http://cdlr.strath.ac.uk/rdinfokit/service/index.cfm
- JISC Information Environment http://www.jisc.ac.uk/whatwedo/themes/information_environment.aspx
- Figure 1 - “The JISC IE architecture diagram” in: Andy Powell (2005). A ‘service oriented’ view of the JISC Information Environment
http://www.ukoln.ac.uk/distributed-systems/jisc-ie/arch/soa/jisc-ie-soa.pdf - Brophy, P. (2005). The formative evaluation of the 5⁄99 Programme and its broader environment: the EDNER Project. VINE. 35(1⁄2), p. 106.
Available: http://www.emeraldinsight.com/. Accessed 20 May 2007. - Powell, A. and Lyon, L. (2002, March/April). The JISC Information Environment and Web services. Ariadne. Issue 3
http://www.ariadne.ac.uk/issue31/information-environments/. Accessed: 7 April 2008. - Grout, C. (2001). Information Environment Development Strategy 2001-2005.
Available: http://www.jisc.ac.uk/media/documents/themes/infoenvironment/ie_strategy.pdf Accessed 4 December 2007. - Ibid. p.4
- Powell, A. and Lyon, L. (2001). The DNER Technical Architecture: scoping the information environment. Bath: UKOLN, University of Bath.
Available: http://www.ukoln.ac.uk/distributed-systems/jisc-ie/arch/dner-arch.html. Accessed 7 Apr 2008. - Ibid.
- Figure 12 - “DNER service categories” in: Andy Powell & Liz Lyon (2001). The DNER Technical Architecture: scoping the information environment
http://www.ukoln.ac.uk/distributed-systems/jisc-ie/arch/dner-arch.html - Appears as http://www.ariadne.ac.uk/issue36/powell/large-original.html in: Andy Powell, Mapping the JISC IE service landscape, July 2003, Ariadne, Issue 36 http://www.ariadne.ac.uk/issue36/powell/
- Powell, A. (2005). A service oriented view of the JISC Information Environment. Pp. 3. Bath: UKOLN, University of Bath.
Available: http://www.ukoln.ac.uk/distributed-systems/jisc-ie/arch/soa/jisc-ie-soa.pdf. Accessed 7 April 2008. - Powell, A. (2003). Mapping the JISC IE service landscape. Ariadne. Issue 36. Available: http://www.ariadne.ac.uk/issue36/powell/. Accessed: 7 April 2008.
- Powell, A. (2005). The JISC Resource Discovery Landscape - a personal reflection on the JISC Information Environment and related activities. Pp. 22. UKOLN, University of Bath. Available: http://www.ukoln.ac.uk/distributed-systems/jisc-ie/arch/resource-discovery-review/. Accessed 7 Apr 2008.
- Powell, A. (2007). You sharin’? You askin’? Blog posting, July 02 2007.
Available: http://efoundations.typepad.com/efoundations/2007/07/you-sharin-you-.html Accessed 20 May 2008. - Powell, A. (2007). Comment on: From the DNER to Web 2.0 blog posting by Kelly, B.
Available: http://ukwebfocus.wordpress.com/2007/07/03/from-the-dner-to-web-20/#comments Accessed 20 May 2008. - Appears as slide no. 5 in: Andy Powell (2004). The JISC IE: shared, global or common services?. A presentation at: JISC Common Services Integration Meeting, 27 October 2004
http://www.ukoln.ac.uk/distributed-systems/jisc-ie/arch/presentations/jisc-frameworks-2004-10/intro_files/v3_document.htm